Infostealer malware turns one infected laptop, often a personal or contractor device the organisation never sees, into a ready-made set of logins and live sessions for its cloud, SaaS and data platforms. This briefing is for board members, chief executives, chief financial and risk officers and audit committees who need to understand why stolen browser data has become a leading route into company systems, and what to ask management about it. It stays at board level: the technical detail of how infostealers work is in the Infostealer Threat Guide, and the operational response is in the Infostealer Logs Monitoring and Response Guide.
The risk in one paragraph
An infostealer is malware that collects saved passwords, browser cookies, session tokens and files from a device in one pass and sends them to criminals, who sell them as "logs". A log from one employee or contractor can contain working access to email, collaboration tools, cloud consoles, code repositories and data platforms. Session cookies matter most: a stolen live session lets an attacker continue as the user without knowing the password and without being asked for multi-factor authentication (MFA) again. The infection usually happens outside the company's control, on a home computer, a shared family device or a contractor laptop used for several clients. Nothing is "hacked" in the company's own systems, so traditional perimeter controls see a normal login. The defence is mostly identity hygiene: MFA everywhere, short-lived sessions bound to managed devices, credentials kept out of browsers, fast revocation, and monitoring for the organisation's own data appearing in criminal markets.
Why this is a board-level issue now
- Industrial scale: FBI and CISA advisory AA25-141B (May 2025) cites private-sector data showing more than 21,000 market listings selling LummaC2 logs between April and June 2024, a 71.7% increase on the same period in 2023. Microsoft reported identifying over 394,000 Windows computers infected with Lumma between 16 March and 16 May 2025.
- Proven route to mass data theft: in the Snowflake Breach 2024, Mandiant found that about 165 customer organisations were potentially exposed, that the attackers used credentials mainly stolen by infostealers on non-Snowflake systems, that at least 79.7% of the accounts used had prior credential exposure, and that some credentials had not been rotated for up to four years. The accounts had no MFA and no network allow lists. Mandiant found no evidence of a breach of Snowflake's own enterprise environment: these were customer-side credential controls.
- Third parties are the soft spot: Mandiant noted that in several investigations the initial infection was on contractor systems also used for gaming and pirated software, and a contractor laptop can hold access to several client organisations. In the Schneider Electric Jira Breach 2024, third-party threat research reporting linked the credentials the attacker claimed to use to an infostealer infection; treat that route as reported rather than officially confirmed.
- Takedowns do not remove the risk: in May 2025 a Microsoft court action, with the US Department of Justice, Europol's EC3 and Japan's JC3, led to about 2,300 Lumma domains being seized, suspended or blocked. Logs already sold remain valid until the organisation rotates the credentials and revokes the sessions.
Where the exposure sits
Directors do not need malware detail, but they should know which assets turn an infection into a business incident. The table is our summary, built on the sources above.
| What is stolen | What an attacker can do with it | The control that blunts it |
|---|---|---|
| Saved passwords for company apps | Log in where MFA is missing, including old or forgotten systems | MFA on every externally reachable login; no password storage in personal browsers |
| Session cookies and tokens | Continue a signed-in session, bypassing the password and MFA prompt (ATT&CK T1539, T1550.004) | Short session lifetimes, sessions bound to managed devices, revocation on exposure |
| Cloud, SaaS and data platform credentials | Bulk export of customer or company data, as in the Snowflake campaign | Network allow lists, phishing-resistant MFA, alerts on bulk exports |
| API keys, tokens and service account passwords saved on the device | Machine access that is rarely protected by MFA and rarely rotated | Secrets held in a vault, short-lived, owned and rotated; none in browsers or files |
| Crypto wallets, payment and personal data | Direct fraud against staff and the company | Separate privileged and personal use; staff guidance |
Where identity fits
Infostealer logs increasingly contain non-human credentials: personal access tokens, cloud keys, deployment tokens and the passwords of service and migration accounts that someone saved in a browser. These are often more valuable than a person's password because they bypass MFA, carry broad permissions and stay valid for years. Management should be able to show that every such credential has an owner, an expiry and a place in a vault, and that exposure triggers rotation, not just a password reset. See the Secrets Management Guide and the Service Account Security Guide.
Five questions for the board to ask
- Would we know if our credentials were for sale? Ask whether the organisation monitors infostealer logs and criminal markets for its domains, staff, contractors and customer-facing apps, and how quickly a finding reaches someone who can act.
- Is there any login that still works with a password alone? Ask for the list of systems reachable from the internet, including data platforms, legacy apps and third-party SaaS, that do not enforce MFA, and the plan and date to close each one.
- When a device is infected, do we kill the sessions as well as the passwords? Resetting a password does not end a stolen session everywhere. Ask whether the response playbook revokes sessions and refresh tokens and rotates every secret the device held.
- What can a contractor's personal laptop reach? Ask how third-party and contractor access is granted, whether unmanaged devices can reach sensitive systems, and whether contracts require notification of infections.
- Which machine credentials sit in browsers and files? Ask for a view of API keys, cloud keys and service account passwords outside the vault, their owners and their age.
What good looks like
- Identity: phishing-resistant MFA on email, identity provider, cloud consoles, code repositories and data platforms, with no password-only exceptions. See the Phishing-Resistant MFA Guide.
- Sessions: access to sensitive systems only from managed, compliant devices; session lifetimes set by risk; automatic revocation when exposure is found. See the Token and Session Security Guide.
- Endpoints: application allowlisting and separate accounts for privileged work, both recommended in advisory AA25-141B, plus endpoint detection on all company devices (our recommendation; the advisory notes LummaC2 is built to evade some endpoint tools).
- Browsers: company passwords kept in an approved password manager, not personal browser profiles; personal browser sync to work devices restricted.
- Third parties: contractor access through managed devices or controlled virtual desktops, time-limited and reviewed. See the Contractor Identity Lifecycle Guide.
- Response: a rehearsed playbook that treats an infostealer finding as a full credential and session compromise. See the Session Token Theft Response Playbook.
Where to invest first
| Priority (NHI Mgmt Group recommendation) | Investment | Why first |
|---|---|---|
| 1 | Close every password-only login to internet-facing systems, starting with data platforms and admin consoles | Removes the cheapest attack path seen in the Snowflake campaign |
| 2 | Infostealer exposure monitoring tied to an automated revoke and rotate workflow | Shortens the window between sale and use of a log |
| 3 | Device-bound access for sensitive systems, starting with administrators and contractors | Makes stolen sessions far less useful off the original device |
| 4 | Move machine credentials from browsers and files into a vault with expiry | Non-human credentials are the most durable items in a log |
Metrics
- Number of internet-facing systems that accept a password without MFA (target: zero, with dated exceptions).
- Median time from an infostealer exposure alert to session revocation and credential rotation (our suggested target: under 24 hours).
- Share of access to sensitive systems from managed devices.
- Number of machine credentials older than their rotation policy, and number found outside the vault.
- Exposure findings by source: employee, contractor, customer.
A 90-day plan
- Days 1 to 30: name an accountable executive; list every internet-facing login without MFA; start monitoring infostealer exposure for company domains; confirm the response playbook revokes sessions and rotates secrets, not only passwords.
- Days 31 to 60: enforce MFA on the highest-value gaps (data platforms, cloud consoles, code repositories); restrict contractor access to managed devices or virtual desktops; inventory machine credentials held outside the vault.
- Days 61 to 90: introduce device-bound access for administrators; set session lifetimes by risk; run a tabletop exercise based on an infected contractor laptop; report the metrics above to the board with targets.
Standards and references
- FBI and CISA: AA25-141B Threat Actors Deploy LummaC2 Malware to Exfiltrate Sensitive Data from Organizations
- Google Cloud (Mandiant): UNC5537 Targets Snowflake Customer Instances for Data Theft and Extortion
- Microsoft: Disrupting Lumma Stealer
- MITRE ATT&CK: Steal Web Session Cookie (T1539)
- MITRE ATT&CK: Credentials from Web Browsers (T1555.003)
- MITRE ATT&CK: Lumma Stealer (S1213)
How NHI Mgmt Group can help
We provide independent board briefings and assessments of the credentials infostealers target, including the API keys, tokens and service account passwords that sit outside the vault. Our NHI Foundation Level Training Course helps security and IAM teams govern those identities. Contact us to arrange a briefing.
Related NHI Mgmt Group resources: Infostealer Threat Guide · Infostealer Logs and Session Token Abuse Guide · Leaked Credential Response Playbook · Board Cyber Risk Reporting Guide