Incident Response — Infostealer / Credential Dump
Devon, 31, freelance developer. A recruiter sent over a take-home project for a senior role. The README said npm install && npm test. Devon ran it without reading the dependency tree. Within seconds the fan spooled up. lsof -i showed a Node child process holding a TCP connection to an IP in a hosting range Devon did not recognise. Bitwarden was unlocked in the menu bar. A text file named phantom-seed.txt was sitting on the desktop from the last time Devon set up a wallet on this laptop and never cleaned up. The cursor is blinking. Every keystroke from this point forward is more data leaving the machine.
This page is the procedure for that exact situation. It is the dominant credential-theft pattern of 2026: a developer is targeted via a fake job interview, a “homework” repo, a Slack DM with a “quick reproducer,” or a typosquatted package, and an infostealer runs as the user inside the install hook. By the time the fan spins up, the secrets are already gone. The remaining minutes belong to whoever rotates faster.
Note the inversion from the standard checklist: the compromised machine is the LAST thing you touch. Devon’s instinct will be to start running clamscan and uninstalling the package. That instinct is wrong for this threat class. Run toward the rotation work first.
Why the generic IR steps are wrong here
Section titled “Why the generic IR steps are wrong here”The standard “disconnect → scan → update → uninstall → change passwords” sequence is correct for spyware that watches a device over time. It is CATASTROPHIC for an infostealer, where data is exfiltrated in the first 60 seconds. Scanning the box does not unsteal credentials. Speed of credential rotation matters more than malware removal.
A modern infostealer (Lumma, Vidar, RedLine, StealC, Atomic on macOS, the various Solana-targeted Node payloads of 2025–2026) is a one-shot grab. It enumerates browser profiles for cookies and saved passwords, walks the home directory for wallet files and .env files and SSH keys and config files for known tools, packages everything into a zip, and POSTs it to a drop server. Then it exits. There is no “remove the malware to stop the bleeding” because the bleeding stopped in under a minute. The blood is already in the bag.
What is still live is the attacker’s ability to USE what they grabbed. That window is hours to days, not seconds — they have to triage thousands of victims and pick the high-value ones. That window is yours to spend on rotation.
The two activities you actually need in parallel:
- A clean device doing rotation work. This is where you spend the next several hours.
- The compromised laptop, network-isolated, untouched, preserved as evidence for later imaging.
Anti-virus on the compromised host is irrelevant to the outcome. Do not let the urge to “do something on the laptop” pull you away from the rotation queue on the clean device.
Browser session / cookie theft — the silent next step
Section titled “Browser session / cookie theft — the silent next step”Infostealers dump browser cookies. With stolen session cookies, the attacker bypasses your password AND your MFA — they just paste the cookie into their browser and they ARE you. Changing the password does not invalidate existing sessions on most services. Each service needs explicit session revocation.
The cookie is the session. Most services treat a valid session cookie as proof of authentication AND of the second factor that produced it. So a stolen cookie is a password-plus-MFA bypass that lasts as long as the service’s session TTL — for many services, weeks. The attacker does not need your TOTP secret, your hardware key, or your SMS code. They paste the cookie and they are signed in as you, with your roles, your repos, your billing access.
This is why “change the password” is half the work. The other half is “revoke the sessions.” Walk the list below from the clean device.
| Service | Where to revoke sessions |
|---|---|
| myaccount.google.com/device-activity | |
| Microsoft | account.microsoft.com/devices → Sign out everywhere |
| Apple | iCloud.com → Account Settings → Sign out of unknown devices |
| GitHub | github.com/settings/sessions |
| GitLab | gitlab.com → Profile → Active Sessions |
| Discord | User Settings → Devices → Log out all known devices |
| Slack | Workspace → Profile → Account → Sign out other sessions |
| AWS | IAM → User → Security credentials → revoke sessions |
| GCP | Console → IAM & Admin → revoke service-account keys; security.google.com for user |
| Azure | portal.azure.com → Azure AD → revoke sessions |
| Cloudflare | dash.cloudflare.com → Profile → Active Sessions |
| npm | npmjs.com → Account → Tokens → revoke all + regenerate |
| PyPI | pypi.org → Account settings → API tokens → revoke + regenerate |
| Banking | Most US banks have “trusted devices” or “active sessions” in security settings |
A few items deserve special attention beyond the table.
OAuth tokens issued by your account to third-party apps are a parallel session surface. After revoking sessions on Google, Microsoft, GitHub, etc., also walk the connected-apps / authorized-apps page on each one and revoke anything you do not actively use. The attacker can mint long-lived API behavior through a forgotten OAuth grant the same way they can through a stolen cookie.
Browser-synced extensions are also persistence. If the attacker had time to install a malicious extension and it synced to your Chrome/Edge/Firefox profile, signing in fresh on a new machine will pull that extension down with you. Audit installed extensions before signing back in on any clean device, or sign in with sync disabled and review first.
Password-manager session: log out of every device that has your vault unlocked, rotate the master password, rotate the vault unlock secret (Bitwarden “master password hash” / 1Password “Secret Key”), and re-enrol your hardware key. The vault items are presumed exfiltrated — the priority is making sure new vault contents are not also exposed.
Crypto-specific recovery
Section titled “Crypto-specific recovery”Hot wallet seed exposure (MetaMask, Phantom, Trust Wallet, Rabby, Brave Wallet): treat seed as BURNED. Set up a NEW wallet on a hardware device. Move all assets to new addresses generated by the new hardware seed. Never re-use the compromised seed. Do not move the funds to another hot wallet “just for now” — the attacker may have automated draining bots watching the compromised addresses and will follow the funds across one hop if the next hop is also a hot wallet.
In Devon’s case the Phantom seed sat in plaintext on the desktop. That seed is gone. Every address ever derived from it is gone. The remaining SOL, every SPL token, every staking position, every NFT, every domain — all of it has to move, now, to addresses controlled by a hardware-generated seed. Speed matters more than tidiness; drain to one hardware address first, sort the portfolio later.
Token approvals (DeFi): even after moving funds, check token-approval pages — revoke.cash (multi-chain), etherscan.io “Token Approvals” (Ethereum), solscan.io (Solana). Revoke any allowances. Attackers wait for new deposits to drained-approval addresses to drain again. The approval is a standing permission for a contract to move your tokens; the attacker does not need your seed once they have a live approval.
Centralized exchanges (Coinbase, Kraken, Binance, Gemini): rotate password + 2FA (set up new TOTP, do not trust SMS), enable withdrawal whitelist with new addresses only, rotate API keys, set withdrawal delays where supported. SMS 2FA is independently compromised by the SIM-swap risk that piggybacks on credential dumps — use a TOTP app or a hardware key instead. If you trade via API, revoke and reissue every key, and IP-restrict the new keys if the exchange supports it.
NFT marketplaces: revoke OpenSea / Blur / Magic Eden delegations. NFT delegations are a quieter version of token approvals — a malicious operator contract can be granted the ability to transfer NFTs out of your wallet on your behalf, and that grant survives moving funds if you do not explicitly revoke it.
If you used WalletConnect to sign anything during compromise: assume those sessions are also compromised — disconnect all dApp connections. WalletConnect v2 sessions can persist for days and can be used to prompt signature requests that the attacker has scripted to look like legitimate dApp activity.
A note on “the funds are already gone” cases: if drainage happened before you finished rotating, immediately preserve transaction hashes, destination addresses, and timestamps. Receiving exchanges sometimes freeze incoming funds if reported within hours and the destination is a regulated venue. The window is short but not zero.
Supply-chain context
Section titled “Supply-chain context”This is the npm/PyPI/Docker-Hub/typosquat attack pattern. Cross-link to /cybersecurity/threats/supply-chain. Common indicators of malicious package: postinstall scripts, very new package (< 7 days), maintainer with no other packages, obfuscated install hook, name similar to a popular package (typosquat). Modern tooling helps catch these — Socket.dev, npm audit signatures, Snyk Open Source.
The “take-home interview” delivery is increasingly common because it bypasses every supply-chain control a developer has built up. The repo is private. There is no public download count to look suspicious. The dependency does not need to be on npm at all — it can be a git URL, a tarball URL, or a transitively pulled dep. The victim is socially primed to trust the source (“they want to hire me”) and primed to run code quickly (“they said the take-home should be < 2 hours”).
The defensive posture for next time:
- Run interview homework, untrusted reproducers, and one-off developer artifacts inside a dev container, a disposable VM, or a sandboxed user account with no access to your home directory, no browser profiles, and no wallet files.
- Disable lifecycle scripts by default:
npm config set ignore-scripts true. Re-enable per-project only when you have read the scripts. - Use a tool that flags supply-chain risk at install time — Socket, Snyk, OSV-Scanner, or
npm audit signaturesfor provenance. - Treat any repo from a recruiter the same as a pasted ZIP from a stranger. The recruiter being real does not make the repo safe.
Preserve evidence without spreading malware
Section titled “Preserve evidence without spreading malware”The pull is to grab the install logs, the suspicious file, the network capture, and start sharing them with people who can help. Do that carefully — handling artifacts wrong spreads the incident.
- DO NOT copy individual files off the disk to a USB stick or to cloud storage — risk of copying attacker persistence/payloads. A file you think is “just the package.json” can carry attacker-modified content, and a malicious file in your cloud sync folder will fan out to every other device on that sync.
- Image the WHOLE disk to an external drive using a forensic tool (dd, FTK Imager) BEFORE reinstalling. Encrypted image stays useful for later investigation. A whole-disk image at rest, encrypted, on a drive that is not plugged back into anything until a forensic analyst is ready, is the safe form.
- Capture process tree to USB before shutdown:
ps -ef > /Volumes/USB/ps.txt,ss -tnp > /Volumes/USB/ss.txt(Linux),lsof -i > /Volumes/USB/lsof.txt(macOS). These text dumps are safe to share — they are evidence, not executables. - Document the npm/PyPI package name, version, install timestamp. Also document: the repo URL the package came from, the recruiter’s contact info, the platform the interview was sourced through (LinkedIn, Wellfound, direct email), and the exact command you ran. This is what downstream defenders need to file a takedown.
If the laptop is also an employer-owned device, stop here and call the employer’s IR team — they have legal authority and tooling for evidence handling that you do not.
Reinstall — do not clean
Section titled “Reinstall — do not clean”There is no AV product that earns trust on a known-compromised host. Once an infostealer has run as your user, every persistence mechanism the attacker chose to deploy is at user privilege or higher, and “user privilege” includes your shell rc files, your launchd or systemd user units, your browser extensions, your IDE plugins, and any compiled binary the attacker dropped into ~/.local/bin or /usr/local/bin. A scanner that finds 4 of the 6 things they did still leaves you owned.
- Reinstall OS from CLEAN official media. Verify SHA-256. Pull the installer image on the clean device you have been doing the rotation work on, not on the compromised host.
- Do NOT restore from a backup taken AFTER the compromise (persistence may ride along). For Time Machine, Restic, Borg, or any image-based backup, restore from a snapshot taken BEFORE the install timestamp you documented earlier. If you do not have a pre-compromise backup, rebuild from source — your dotfiles repo, your password manager, your cloud-synced documents — rather than restore.
- Wipe and re-flash any external drives that touched the compromised machine. A USB drive that was mounted while the host was compromised is itself untrusted. Encrypted disk images created BEFORE compromise are fine; archive containers written DURING or AFTER compromise are not.
- Re-verify firmware (UEFI/BIOS) is current. Firmware persistence is rare for commodity infostealers but trivial to rule out by reflashing from the vendor’s signed update package.
After reinstall, set up the new host with the discipline you wish you had had: a dev container or VM for untrusted code, hardware-key MFA enforced everywhere, ignore-scripts on by default, and a password vault that re-locks aggressively.
Reporting
Section titled “Reporting”| Scenario | First call | Secondary | Legal/regulatory |
|---|---|---|---|
| Personal infostealer | None mandatory; consider FBI IC3 if loss is material | haveibeenpwned.com to check for emerging credential exposure | Crypto loss > $10k: IRS Form 4684 |
| Crypto theft | Receiving exchange compliance + FBI IC3 Virtual Asset Unit | Chainalysis-affiliated firms (some do free triage at material amounts) | FBI Virtual Asset Exploitation Unit |
| Work device | Your employer’s incident-response team FIRST. Do not investigate or remediate yourself if employer has an IR team. | Your team lead | Per employment contract |
| Open-source maintainer | Report malicious package to npm/PyPI security + GitHub | OpenSSF supply-chain incident channels | Notify downstream consumers |
| High-value individual / journalist / activist | Access Now Digital Security Helpline (24/7, free) | Citizen Lab if state-actor angle | — |
A few practical notes about the reporting columns. FBI IC3 is the right civilian intake in the US even for “small” cases — patterns aggregate, and a report you make today contributes to disruption work targeting the package author. For crypto, the receiving exchange is usually the highest-leverage call because regulated venues can freeze incoming funds if contacted within hours; the IC3 report is the slower, paper-trail counterpart.
For an employer device, do not run any of the rotation steps in this page on accounts owned by the employer until you have called their IR team. Your personal accounts on the same device are yours to rotate immediately; their cloud tenants, code-signing keys, and production credentials are theirs to handle, and acting first can both contaminate evidence and create employment exposure.
If you maintain a published package and your npm/PyPI/Docker Hub token may have leaked, notify the registry security teams first — they can revoke the token server-side and dust off the publishing pipeline before the attacker pushes a malicious version of YOUR package downstream to YOUR users. This is the supply-chain blast radius escalation and it is what turns a personal incident into a CVE.
Pivot to
Section titled “Pivot to”- /cybersecurity/threats/credential-theft — the broader category, including phishing kits and adversary-in-the-middle
- /cybersecurity/threats/supply-chain — how the malicious package got to your machine in the first place
- /cybersecurity/threats/malware — generic malware reference for the post-incident reinstall
- /cybersecurity/incident-response — general incident-response landing page
- /cybersecurity/incident-response/secure-after-compromise — the hardening checklist for the rebuilt host
Useful resources
Section titled “Useful resources”- haveibeenpwned.com — breach exposure check; subscribe email + domain alerts to catch future leaks early
- revoke.cash — multi-chain token approval revoker; sweep approvals after any wallet move
- socket.dev — npm/PyPI supply-chain scanning; catches postinstall hooks and obfuscation pre-install
- npm audit signatures — provenance verification for packages that publish signed releases
- OpenSSF supply-chain incident reporting — the right escalation path when a malicious package is live in a public registry