Infostealers vs RATs: What Each Takes and How Response Differs

Responders who treat every malware alert on an endpoint the same way either leave stolen sessions alive after an infostealer or leave an attacker inside the network after a remote access trojan. Infostealers and remote access trojans (RATs) both run on a user's device, both arrive through phishing, malvertising and fake software, and both end in identity compromise, but they behave very differently once they land. An infostealer grabs what it can in seconds and leaves; the damage happens later, somewhere else, when a buyer replays the credentials, cookies and keys. A RAT stays, and the operator works live through the device. This guide compares the two by threat model, architecture, what each takes, failure modes and controls, then shows why the first response move is revocation for one and eviction for the other. It is for SOC analysts, incident responders and identity teams. For the stealer economy and prevention in depth, see the Infostealer Threat Guide; for RAT families and behaviour, see the Remote Access Trojans (RATs) Guide.

Key takeaways

• The short answer is smash-and-grab versus persistence. An infostealer harvests browser passwords, session cookies, tokens and files in one pass and exfiltrates them; a RAT installs persistence and gives an operator an interactive channel for as long as it survives.
• With an infostealer, the device is not where the harm happens. The attack moves to your identity provider, SaaS tenants and cloud accounts, often days or months later, so cleaning the laptop does nothing about the stolen material.
• With a RAT, the device is the attacker's foothold. Every credential typed, every session opened and every network path reachable from that host is live attacker capability until the implant and any second foothold are removed.
• Response order differs. Infostealer: revoke sessions and rotate secrets first, then rebuild. RAT: isolate and scope first, then revoke and rotate in one coordinated move, because the operator can watch you reset passwords and steal the new ones.
• Non-human identity secrets decide the blast radius in both cases. Cloud access keys, personal access tokens, SSH keys and CLI token caches on developer machines are taken by stealers and used by RAT operators; short-lived, device-bound credentials limit both.

What each category is

• Infostealer: malware built to collect stored credentials and data and send them to a collection server. Microsoft's analysis of Lumma Stealer lists saved passwords, session cookies and autofill data from Chromium and Gecko browsers, cryptocurrency wallet files and extensions, VPN configuration files, email, FTP and Telegram client data, user documents and system profiling data, with the target list pulled from a configuration file on the command and control server so it can change. Microsoft's report describes evasion such as process hollowing into trusted processes but no persistence mechanism. Most stealers are sold as a service, and the stolen "logs" are sold on.
• Remote access trojan: malware or abused software that gives an operator ongoing, interactive control: remote shell, file transfer, keylogging, screen capture, webcam and microphone access, and the ability to load further tools. ATT&CK groups the abuse of legitimate remote tools under T1219 Remote Access Tools, with T1219.002 Remote Desktop Software; custom RAT families sit in the ATT&CK software catalogue. See the ATT&CK Remote Access Trojans Software Hub.
• The grey zone: some RATs include stealer modules, some stealers download further payloads, and access brokers turn stealer logs into RAT deployments. Classify by observed behaviour on the host (persistence, live sessions, repeated beaconing) rather than by the family name in the alert.

Side-by-side comparison

Threat model: what each defends against, and what it exploits

ATT&CK references are from ATT&CK v20.

Infostealer threat model

The stealer exploits one assumption: that a credential or session on a trusted device stays on that device. Saved browser passwords, cookies that already carry a completed MFA claim, refresh tokens cached by desktop apps and CLIs, cloud credential files and .env files are all readable by code running as the user. The buyer replays them with T1550.004 Web Session Cookie or signs in with valid accounts (T1078.004 Cloud Accounts for cloud tenants). MFA does not help once the cookie or token is stolen, because the authentication already happened. The Snowflake breach shows the slow-burn shape: infostealer credentials, some harvested years earlier on devices the victims did not own, were used against accounts without MFA or network restrictions.

RAT threat model

The RAT exploits the device's position: its network reach, its signed-in sessions and the user's habits. Because the operator acts from the user's own machine, many identity signals (known device, known IP, compliant device claim) look normal, and device-bound tokens do not stop an attacker who is using the bound device. CISA's advisory AA23-025A on legitimate remote monitoring and management software shows a related pattern: portable remote tools that run with user rights, need no installation or administrator rights and generally do not trigger antivirus, used for persistence and command and control and sometimes sold on to other groups.

Where they overlap

Both start with the same initial access: T1566 Phishing, T1189 Drive-by Compromise, cracked software and fake CAPTCHA "paste this command" pages (T1204.004 Malicious Copy and Paste). Microsoft's Lumma analysis lists all of these as delivery routes. Prevention controls at the front door therefore serve both; the split comes after execution.

Architecture in words

Infostealer flow: loader runs, often injected into a trusted process; the stealer fetches its target configuration; it enumerates browser profiles, wallet extensions, application folders and file paths; it decrypts protected browser data using the user's own context; it packages the results with host details and posts them in chunks over HTTPS to the collection server; it may download a further payload. Microsoft describes Lumma using hard-coded tier 1 servers behind a proxy, with fallback addresses published on Steam profiles and Telegram channels. The log then enters a marketplace or a private buyer's queue, which is why stealer log monitoring is part of the defence. See the Infostealer Logs Monitoring and Response Guide.

RAT flow: dropper runs; the implant writes persistence (run keys, scheduled tasks, services or startup folder); it beacons to a controller on a timer, typically over web protocols (T1071.001); the operator issues commands, browses files, captures keystrokes and screens, pulls in tools and pivots, for example over T1021.001 Remote Desktop Protocol. When the remote capability comes from a legitimate RMM or remote desktop product, the "implant" is a signed binary and the controller is a commercial relay, which changes detection from malware signatures to software policy.

What each takes, with the NHI angle

Developer and administrator endpoints are the highest-value targets for both, because they hold machine credentials that outlive any user session. AWS documents long-term access keys as plaintext in the shared credentials file and recommends temporary credentials such as IAM roles instead. GitHub tokens can be given expiry dates, and GitHub revokes valid tokens pushed to public repositories, but a token copied from a laptop is not pushed anywhere public, so that safety net does not apply. See the Infostealer Logs and Session Token Abuse Guide and the Session Hijacking and Cookie Theft Guide.

Response steps: revocation versus eviction

Classify first. Ask three questions of the endpoint telemetry: is there persistence (new autostart, service, scheduled task, installed remote tool)? Is there repeated outbound connection to the same infrastructure after the initial execution? Has anyone interacted with the host remotely? Any "yes" means treat it as a RAT case, even if the alert named a stealer.

Infostealer case: revoke first

1. Contain the device: isolate it through EDR so a follow-on payload cannot run, but do not wait for forensics before acting on identity.
2. Revoke sessions: in Microsoft Entra ID, Revoke sessions (or Revoke-MgUserSignInSession) stops new tokens being issued; Microsoft notes existing access tokens last one hour by default and app-issued session cookies are not revoked by Entra, so sign the user out of each SaaS app that keeps its own sessions.
3. Reset and re-enrol: reset passwords, remove unknown MFA methods and OAuth grants, and check mailbox rules.
4. Rotate every NHI secret that was on the device: cloud keys, personal access tokens, SSH keys, API keys in config files and .env files. Review their activity from the infection date. See the Leaked Credential Response Playbook.
5. Hunt forward from the infection date: sign-in and API logs for reuse from new devices or networks, including sessions that predate your revocation.
6. Reimage and remove the cause: cracked software, local admin rights, personal browser profile sync.

RAT case: evict first, then revoke in one move

1. Isolate quietly and preserve evidence: network-isolate through EDR, capture memory and the persistence artefacts before rebooting, and record the controller addresses.
2. Scope the operator's reach: other hosts contacted, accounts used from the host, tools transferred, and any second foothold such as a new remote tool, a new account or a cloud identity created during the dwell time.
3. Plan a coordinated cut-over: agree the time to block controller infrastructure, disable created accounts, revoke sessions and rotate credentials together. Resetting passwords while the implant is live hands the new password to the keylogger.
4. Revoke and rotate from a clean device: administrators perform resets from a privileged access workstation, never from the affected host or from a host the operator reached.
5. Rebuild, do not clean: reimage the host and any lateral hosts; confirm absence of beaconing for an agreed period before closing.
6. Check for data theft: RAT dwell time often includes staged exfiltration, so assess notification duties as a data incident, not only a malware one.

The CircleCI breach illustrates why the boundary matters: malware on an engineer's laptop stole an SSO session already protected by two-factor authentication, and the session was used to reach production systems and customer secrets. For session-focused containment, see the Session Token Theft Response Playbook; for the overall process, see the Incident Response Guide.

Controls compared

Microsoft's Token Protection binds sign-in session tokens to the device for supported native apps and, in preview, selected browser access; Microsoft advises report-only mode, a pilot group and capture of interactive and non-interactive sign-in logs first. Chrome's Device Bound Session Credentials use a device key, held in hardware where available, to refresh short-lived cookies, so a stolen cookie stops working once it expires; Chrome notes malware present at registration may still extract keys. Both reduce stealer value and neither helps against a live RAT. See the Device-Bound Session Credentials (DBSC) Guide and the Application Allowlisting Guide.

Decision criteria and implementation order

Where to invest first: if your incident history is dominated by account takeover with no prior endpoint alert, stealers (often on unmanaged or personal devices) are the likely source, so fund session revocation, device binding and stealer log monitoring. If you see hands-on-keyboard activity, unexplained remote tools or helpdesk-themed phishing, fund allowlisting, local admin removal and egress control first. Small organisations without full EDR coverage get most from SSO with phishing-resistant MFA, managed browsers, a tested revocation runbook and a ban on unsanctioned remote tools. Large organisations should add device-bound tokens for administrators and developers, short-lived machine credentials and a RAT eviction playbook rehearsed with the network team.

1. Weeks 0 to 4: write both runbooks with the classification questions above; inventory sanctioned remote tools; find long-term cloud keys and tokens on developer endpoints.
2. Weeks 4 to 8: test session revocation per major SaaS app with a test account and record which apps cannot be revoked centrally; block unsanctioned remote tools in audit mode first.
3. Months 2 to 6: enforce allowlisting and ASR rules by ring, rolling back a ring to audit rather than removing policy; pilot token protection in report-only mode.
4. Ongoing: migrate developer and pipeline credentials to federation; run a tabletop for each malware type each year. See the Remote monitoring and management (RMM) tool health check for sanctioned remote tooling.

Worked scenario

A developer installs a "free" build of a paid tool. Two outcomes are possible. Stealer variant: EDR shows a short-lived process reading the browser's login data and cookie stores and an HTTPS upload, then nothing. The responder isolates the laptop, revokes the developer's sessions, signs them out of the source control platform, cloud console and ticketing tool, rotates two cloud access keys and three personal access tokens found in the user profile, and hunts sign-ins from the infection time. Two days later a login attempt with the old token fails, confirming the theft and the value of rotating first. RAT variant: EDR shows a new run key, an unsigned binary beaconing every 60 seconds and an RDP session from the laptop to a build server. The responder isolates both hosts, captures memory, finds a new local account on the build server, and only then schedules a single cut-over: block the controller, delete the account, revoke sessions, rotate the pipeline credentials from a clean workstation and reimage both hosts.

Detection and measurement

• Endpoint: non-browser processes accessing browser credential and cookie files; DPAPI decryption by scripting or .NET processes (one of Microsoft's Lumma hunting patterns); RunMRU entries showing pasted commands; new autostart entries; execution of portable remote tools.
• Identity: session or refresh token use from a new device, ASN or country soon after an endpoint alert; impossible travel on the same session; sign-ins to apps outside SSO.
• Network: periodic beacons to the same destination; connections to remote access relays not on the sanctioned list.
• Cloud and code: API calls with access keys from new IPs; token use after the recorded rotation time.

Common failure patterns

• Cleaning the laptop and closing the ticket: the stolen cookies and keys are already elsewhere; without revocation the case is still open.
• Treating a password reset as revocation: refresh tokens and app session cookies can survive it, as Microsoft's revocation guidance makes clear.
• Resetting credentials while a RAT is live: the keylogger captures the new password and the operator learns they are detected.
• Forgetting machine credentials: responders rotate the user's password but not the cloud keys, tokens and SSH keys in the profile.
• Trusting the family name: classifying by signature label instead of behaviour leaves persistence from a "stealer" untouched.
• Allowing any remote tool: without a sanctioned list, a commercial remote desktop product is an undetected RAT.

Framework mapping

Practitioner checklist

• Add the three classification questions (persistence, repeated beaconing, remote interaction) to the malware triage runbook.
• Keep separate runbooks: revoke-first for stealers, isolate-scope-cut-over for RATs.
• Test session revocation in every major SaaS app and list those that need per-app sign-out.
• Inventory the NHI secrets held on developer and administrator endpoints and move them to short-lived federation.
• Maintain a sanctioned remote tool list and block all others by allowlisting and egress policy.
• Pilot device-bound tokens and sessions for high-risk users in report-only mode first.
• Monitor stealer logs for your domains, including personal and contractor devices.
• Perform credential resets for RAT cases only from a clean privileged workstation.

Standards and references

• CISA: AA23-025A Protecting Against Malicious Use of Remote Monitoring and Management Software
• MITRE ATT&CK: T1219 Remote Access Tools
• MITRE ATT&CK: T1539 Steal Web Session Cookie
• Microsoft Learn: Revoke user access in Microsoft Entra ID
• Microsoft Learn: Token protection in Microsoft Entra Conditional Access
• Microsoft Security: Lumma Stealer delivery techniques and capabilities
• Chrome for Developers: Device Bound Session Credentials
• AWS: Manage access keys for IAM users

Related NHI Mgmt Group resources: Infostealer Threat Guide, Remote Access Trojans (RATs) Guide, AsyncRAT, Remcos and njRAT Commodity RATs Guide, Global Token Revocation Guide, EDR Guide.