DLL side-loading and browser memory theft are scaling credential abuse

At a glance

What this is: This is a practical analysis of how DLL side-loading and browser memory scraping are being used to steal identity data and session material at scale.

Why it matters: It matters because browser-held credentials, cookies, and tokens now create identity exposure that sits between human IAM, NHI secrets handling, and session governance.

By the numbers:

• Between January 7 and January 20, 2026, roughly 277,800 hosts were compromised in this campaign.

👉 Read Keeper Security's analysis of DLL side-loading and browser memory theft

Context

DLL side-loading is a Windows execution weakness, but the governance problem is broader: attackers are using it to reach browser-held identity material, not just to run malware. Once malicious code lands through a trusted executable, it can intercept passwords, cookies, session tokens, card data, and wallet secrets while they are briefly present in memory.

That creates a control gap across identity programmes. Human access controls may protect login flows, NHI practices may focus on secret storage and rotation, and endpoint teams may look for files on disk, yet the theft happens in volatile browser memory during active use. For IAM and security architects, this is a session integrity and memory-protection problem as much as a malware problem.

Key questions

Q: How should security teams reduce the risk of browser session token theft?

A: Security teams should tighten token scope, shorten session lifetime where the business can tolerate it, and build fast revocation into identity operations. They should also assume token theft can bypass password resets, so incident playbooks must focus on invalidating active sessions and limiting what each token can reach.

Q: Why do DLL side-loading attacks remain effective against traditional endpoint controls?

A: They remain effective because the attack often starts inside a legitimate program and leaves little disk evidence. Traditional tools are good at file reputation and static signatures, but they are weaker against trusted executables that load malicious libraries and then steal identity data from memory during normal use.

Q: What do teams get wrong about protecting passwords and cookies in browsers?

A: Teams often treat stored credentials as the main problem, when the real exposure can occur during active use. Browsers must briefly decrypt secrets into memory for login and transaction flows, and attackers exploit that runtime window. Protection has to cover both storage and the moment of use.

Q: Who should own response when browser memory scraping exposes identity data?

A: Ownership should be shared across IAM, endpoint security, and incident response, because the stolen material can be both identity and device related. IAM must revoke sessions, endpoint teams must investigate process behaviour, and response teams must determine whether the theft reached passwords, tokens, card data, or wallet assets.

Technical breakdown

How DLL side-loading turns trusted software into an execution path

DLL side-loading works when a legitimate Windows application loads a malicious library because of how the operating system searches for dependencies. The user sees a normal program, but the attacker controls one of the components the program loads at runtime. That gives the payload trusted execution context, which helps it evade simple reputation checks and many signature-based detections. In the campaigns described, search-engine manipulation and deceptive downloads increase the chance that victims launch the wrong binary. The real risk is not the file alone, but the fact that trusted software becomes the carrier for untrusted code.

Practical implication: validate application load paths and block unsigned or unexpected DLLs in software that can reach browser or credential stores.

Browser memory scraping and session token theft

Browser memory scraping targets the short window when decrypted secrets exist in process memory for active use. Browsers must temporarily hold passwords, autofill values, cookies, and session tokens in plaintext or near-plaintext form so users can authenticate and transact. Attackers exploit that by injecting code into the browser process or by using infostealer malware that scans memory directly. Session tokens are especially valuable because they can bypass password resets and MFA prompts if the session is still valid. This is not classic credential theft from disk or a vault. It is runtime identity theft from the place where the browser is actively using the secret.

Practical implication: treat browser process memory as an identity protection surface and prioritize controls that reduce token exposure during active sessions.

Why legacy antivirus misses live-memory identity theft

Traditional antivirus is tuned for files, hashes, and disk artefacts, which is why memory-only theft often slips through. In these campaigns, the attacker chain is designed to leave little behind after execution, especially when the payload rides in a signed application and exfiltrates through bot-driven infrastructure. That means detection has to shift toward behavioural signals, process inspection, and memory-aware protections. It also means incident response can be weak if teams assume the absence of a suspicious file equals the absence of compromise. With live-memory attacks, the compromise can be complete even when forensic residue is thin.

Practical implication: add process and memory inspection to endpoint telemetry, and do not rely on file-based detection as the primary control.

Threat narrative

Attacker objective: The attacker wants live identity data and session material that can be reused immediately to hijack accounts, drain assets, and move laterally through other authenticated services.

1. Entry begins with SEO poisoning or phishing that pushes victims toward a bogus download page offering familiar software.
2. Escalation occurs when the legitimate program side-loads a malicious DLL that launches a backdoor or infostealer under trusted execution.
3. Impact follows when the malware scrapes browser memory and exfiltrates passwords, cookies, card data, and wallet material for reuse or sale.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Browser memory theft is now an identity problem, not just an endpoint problem. The campaign logic in this article shows that attackers want live credentials and session artefacts, not only malware persistence. That shifts the governance question from device hygiene alone to how identity material is protected while it is actively being used. For practitioners, the implication is that browser session protection belongs in identity architecture, not only in endpoint tooling.

Memory-held credentials create a runtime exposure window that many IAM programmes do not model. Human IAM assumes users authenticate, then continue under a durable session. NHI governance often assumes secrets are stored, rotated, and monitored outside active execution. Browser memory scraping breaks both assumptions by taking identity material during the brief interval when it must be decrypted and usable. Practitioners need to recognise that active-use secrets are not equivalent to stored secrets.

Session tokens have become the practical unit of compromise for browser-based identity theft. Once an attacker steals an active token, the password is often irrelevant and MFA may never be challenged again during that session. That makes session governance, revocation speed, and token scope more operationally important than password complexity in this threat pattern. The implication is that identity teams should measure how quickly stolen sessions can be invalidated.

Endpoint protection gaps and identity gaps now overlap in the same attack chain. The same malware chain that evades disk-based detection can also reach passwords, cookies, and wallet keys before a user notices anything unusual. This is where NHI and human identity concerns converge, because the stolen artefacts can represent both person-bound and machine-bound access. Practitioners should treat memory-level theft as a shared control problem across IAM, PAM, and endpoint security.

Identity blast radius is defined by what a stolen session can reach before it is revoked. In campaigns like these, the damage is less about one account and more about the downstream services that trust that account or token. That turns rapid session invalidation, token scoping, and segmentation into blast-radius controls. The practical conclusion is that containment speed matters as much as initial prevention.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, and the confidence gap is wider than it is for human identities.
• For deeper NHI governance context, read Ultimate Guide to NHIs , Key Challenges and Risks for the control gaps that let identity material become reusable.

What this signals

Browser theft campaigns are a reminder that identity telemetry cannot stop at authentication logs. With 1 in 4 organisations already investing in dedicated NHI security capabilities, per The State of Non-Human Identity Security, practitioners should expect more scrutiny on how sessions, secrets, and browser-held credentials are governed across human and machine workflows.

Runtime identity exposure: the control boundary is shifting from secret storage to secret use, which means teams need to watch for memory-level theft as a distinct class of compromise. That has implications for PAM, session control, and endpoint inspection in the same programme.

For practitioners

• Harden browser execution paths Block unsigned DLL loading in user-facing applications, restrict search order hijacking, and remove local write access from directories commonly used for side-loading.
• Reduce session token value Shorten token lifetimes where feasible, scope sessions tightly to the required application, and make revocation fast enough to limit reuse after theft.
• Add memory-aware endpoint telemetry Use controls that inspect browser process behaviour, detect injection, and surface unusual access to memory regions that hold authentication material.
• Block deceptive download paths Train users to verify software sources, suppress risky search-result downloads, and route common software requests through approved distribution channels.

Key takeaways

• DLL side-loading and browser memory scraping turn trusted software and active sessions into identity theft mechanisms.
• The campaign scale shows that credential, cookie, and wallet theft can spread quickly when attackers combine social engineering with runtime abuse.
• The most effective containment controls are faster session invalidation, tighter token scope, and browser-aware memory protection.

Key terms

• DLL side-loading: A technique where a legitimate application loads a malicious library because of how Windows searches for DLL dependencies. The attacker borrows the trust of signed software to execute code, which can bypass simple reputation checks and make malicious activity look like normal program behaviour.
• Browser memory scraping: The act of reading sensitive data from a browser's process memory while it is temporarily decrypted for use. This can expose passwords, session cookies, payment data, and wallet material during active sessions, even when the data is otherwise protected at rest.
• Session token: A credential that proves an authenticated browser session is still valid. If stolen, it can let an attacker reuse a live session without knowing the password, which makes token scope, lifetime, and revocation speed central to identity defence.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Keeper Security: The rise of DLL side-loading cyber attacks and browser data theft. Read the original.