Loki Malware is a credential-stealing malware family that targets browsers, email clients and other applications to harvest stored secrets. It typically extracts passwords, cookies, autofill data and wallet-related information, then sends them to an attacker for reuse in account takeover, fraud or lateral movement.
What Loki Malware Does
Loki Malware is best understood as credential theft at scale: it is designed to pull stored passwords, session cookies, autofill data and related secrets from endpoint applications, then exfiltrate them for reuse. That makes it a direct enabler of account takeover, fraud and downstream lateral movement.
Because the payload is usually aimed at browsers and email clients, the real security problem is not only the initial infection. It is the trust in whatever secrets were already sitting on the device, including information that can bypass normal login friction.
Why Credential-Stealing Malware Is Dangerous
Credential-stealing malware is dangerous because it converts a single endpoint compromise into reusable access. Stolen cookies and session material can sometimes let an attacker bypass password resets, while harvested passwords can be tested against other internal systems, cloud services and third-party accounts.
The impact is amplified when users store secrets in browsers or desktop clients, because the malware does not need to defeat encryption in transit. It only needs local execution and sufficient access to read whatever the application has already cached or saved.
For defenders, this is why credential theft is treated as an identity problem as much as a malware problem. Controls such as account hygiene, session protection and least privilege matter because the stolen material often works beyond the original endpoint.
How Organisations Check Exposure
Exposure review starts with knowing which devices run affected software and which users rely on saved credentials, autofill or persistent email sessions. Teams should also look at whether endpoints can reach the internet freely, because exfiltration is usually the final step that turns local theft into usable attacker access.
Inventory should include high-value browser profiles, email clients, VPN access paths and any workstation used to reach privileged or administrative systems. If those systems hold long-lived secrets or active sessions, the blast radius of one infostealer infection can be much wider than the endpoint itself.
Vendor advisories and threat reporting help with prioritisation, but the practical question is always the same: where are secrets stored, and which accounts would still be valid if those secrets were copied today?
Detection, Containment and Recovery
Detection should focus on unusual credential access behaviour, suspicious browser data collection, unexpected archive or transfer activity, and signs that a compromised host is contacting attacker infrastructure. Endpoint detection tools are useful here, but only if they are tuned to surface credential access, browser theft and follow-on staging activity.
Once a host is suspected, containment needs to go beyond malware removal. Any passwords, session cookies, API keys, browser-saved secrets or email tokens that may have been exposed should be treated as compromised until proven otherwise, and adjacent accounts should be reviewed for reuse or privilege escalation.
Post-removal review should ask whether the attacker used the stolen material to access other systems, seed persistence, or abuse trusted sessions. If the malware reached a privileged workstation, the compromise review should be broader than one user account.
Risk and Threat Considerations
Loki-style infostealers are especially risky because they transform endpoint compromise into identity compromise. The attacker does not need to crack encryption or brute-force authentication if the endpoint itself already contains usable secrets.
Failure mechanism: Malware with local execution reads stored credentials, cookies or autofill data, then exfiltrates them for reuse in authenticated sessions or against other services.
Impact: The result can be account takeover, fraud, mailbox access, lateral movement and repeated compromise even after the original host is cleaned.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Credential theft directly depends on weak account and secret handling. |
| Recommendation — Harden account handling and revoke exposed credentials quickly after suspected infostealer activity. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | The malware steals passwords, cookies and other authenticators used for access. |
| Recommendation — Rotate and invalidate exposed authenticators and stored secret material after compromise. | ||
| MITRE ATT&CK | T1555 — Credentials from Password Stores | The term describes malware that steals stored browser and application secrets. |
| Recommendation — Map detections to credential-access techniques and hunt for password store abuse. | ||
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | It exfiltrates stored credentials, cookies and related secret material. |
| Recommendation — Reduce secret leakage by removing stored credentials and revoking exposed tokens promptly. | ||
Practitioner Guidance
Why practitioners should care: Treat infostealer events as secret-exposure events, not just malware events. If the infected system held browser-stored passwords, active sessions or synced credentials, the response should include credential and session revocation, not only endpoint cleanup.
What to watch for: Reused passwords, persistent browser sessions and unmanaged stored secrets are the conditions that let this family do the most damage. The smaller the number of reusable secrets on endpoints, the less useful the malware becomes.
Practitioner takeaway: The best defence is reducing what the endpoint can reveal, then assuming anything revealed has to be replaced.