Machine credentials on the dark web: what infostealers steal

The dominant mental model for dark web monitoring is still built around one credential type: a human email address paired with a password, appearing in a paste, a combolist, or an infostealer log. That mental model treats infostealer credential theft as a password-rotation problem, and it is now incomplete. The same infostealer logs that spill employee credentials also carry API keys, OAuth tokens, session cookies, SSH private keys, and service account secrets scraped from developer workstations, CI/CD runners, and increasingly from agent-driven pipelines. A modern machine credentials dark web monitoring configuration has to watch for both categories, and treat each one differently.

For a broader view of what dark web monitoring actually catches inside a typical program, that scope is well covered elsewhere. This post is specifically about the second category, the non-human one, and what a human analyst does when it lands in the queue.

What infostealers actually harvest

When an infostealer executes on an infected endpoint, it does not discriminate by credential type. The malware reads whatever the operating system exposes to a user-level process: browser credential stores, session cookie files, VPN client profiles, wallet files, and any plaintext config on disk. It also reads environment variables and searches known configuration paths where developers and DevOps engineers store secrets. A single execution can return a bundle covering:

• Browser-saved passwords and session cookies. The category most dark web monitoring programs already alert on.
• VPN and RDP client credentials. Directly usable for perimeter access.
• API keys and personal access tokens for cloud providers, source control, and SaaS platforms, often pulled from shell history, .env files, and IDE settings.
• OAuth refresh tokens stored by developer CLIs and productivity tools.
• SSH private keys from ~/.ssh/ and other known paths.
• Service account secrets and CI/CD variables that happen to be resident on the machine.

The category of stolen api keys and tokens is not new. What is new is its volume and the speed at which it lands in the same log alongside a human password. An analyst looking at a full stealer log for a compromised developer sees browser-saved passwords, session cookies, VPN credentials, and then API keys, OAuth tokens, SSH private keys, and service account secrets sitting in the same directory of exfiltrated data. Treating that log as “a password problem” misses more than half of what it actually contains.

How stolen credentials reach the market

The window between endpoint infection and marketplace listing is short. Once a stealer completes its collection routine, the exfiltrated bundle is packaged and uploaded to the operator’s collection point, and from there flows into brokered marketplaces and Telegram channels where individual logs are commonly bought and resold within 24 to 48 hours. SpyCloud’s 2026 Annual Identity Exposure Report recovered 18.1 million exposed API keys and tokens from infostealer logs in 2025 alone, alongside 6.2 million credentials tied to AI tools, and framed the machine credential category as the fastest-growing segment of the infostealer economy.

Rotating the corresponding user password does very little for that machine credential exposure. The API key is still valid. The OAuth refresh token is still valid. The service account secret is still valid. Unless the monitoring program specifically catches those artefacts in the log and routes them into a separate response workflow, the harvest lands in a buyer’s hands untouched.

Developer workstations and CI/CD runners

Two host types disproportionately produce infostealer logs with high-value machine credentials: developer workstations and CI/CD runners. Both are environments where secrets are routinely resident in plaintext because that is what the tooling requires: local development against a cloud API, a pipeline job that needs to authenticate to a registry, an integration test that needs a scoped token.

Hudson Rock’s 2026 analyst briefing flagged a further shift. Malware is no longer only clicked by humans; it is being installed by autonomous agents that pull and execute packages during a build. When an agent runs a poisoned dependency or a malicious package, the host it runs on gets scraped the same way a developer’s laptop does, with the added feature that the runner may hold production-scoped credentials that a workstation would not.

The concrete failure mode is familiar to anyone who has read a recent cloud-breach postmortem. A developer laptop or a build runner is infected. The stealer reads the browser store and the environment, and packages a GitHub Actions token and an AWS access key alongside the browser-saved passwords. The full log appears on a broker marketplace inside 48 hours. A buyer validates the API key against the cloud provider and pivots into production. CTDefense analysts see this shape in their monitoring feeds, and it is the same one described in how CI/CD secrets become attack paths: the pipeline itself was not compromised, the credential holder was.

This is what CI/CD pipeline credential exposure looks like in practice: not a broken build system, but a legitimate token that reached a machine it should not have, and from that machine reached a market.

The gap in most DWM programs

Most dark web monitoring configurations are set up to watch for corporate email addresses and employee passwords. That is a defensible baseline, and it catches a large share of what infostealer logs contain. It does not catch machine credentials, because machine credentials do not carry a corporate email address as a selector. An AWS access key ID is an opaque string. A GitHub personal access token starts with a known prefix, but nothing in that prefix ties it to the target organisation on its own.

Answering the direct question, does dark web monitoring cover non-human identities: in most programs, no. Without explicit monitoring rules for API key formats, token prefixes, service account naming conventions, and the domain and repository names that appear alongside those secrets in a full log, non-human identity exposure in the same infostealer log simply does not fire an alert.

This is what a considered dark web monitoring program scope review has to include. It is also the question that turns up during ISO 27001 and NIS2 audits when an auditor asks how the organisation monitors credentials belonging to systems rather than to people. Introducing the term once for clarity: this is what a non-human identity (NHI) monitoring gap looks like in operational terms, and it is present in most programs today.

How analysts triage machine credentials

The response playbook for a machine credential alert is different from a password alert, and this is the part that lives outside a product screenshot. CTDefense analysts triage a stealer log with API keys or service account tokens in it along a different path from a log that only carries browser-saved employee passwords.

The password log gets routed to the identity team for a rotation and a session revocation, and the affected user is notified. The machine credential log gets routed to whoever owns the surrounding infrastructure, and the immediate questions are different:

• Which system holds this credential. An AWS access key belongs to an IAM user or a role assumption; the analyst has to identify the principal before the credential can be revoked cleanly.
• What did this credential permit. A password change is bounded by the user’s role. A machine credential’s blast radius depends on the policies attached to the principal, and those may be broader than the owner remembers.
• Was it used. Cloud provider and source-control audit logs are pulled to check for activity from unexpected source addresses in the window between the stealer’s collection date and the alert.
• What else was in the same log. A single stealer log usually covers one host. If that host held one machine credential, it probably held others. The triage extends to every secret the host was likely to touch.

None of these steps depends on the alert itself; they depend on the analyst knowing which questions to ask of which system, and doing that consistently across dozens of alerts a week.

Where this leaves mid-market tech and SaaS teams

CTDefense continues to run Dark Web Monitoring service programs for mid-market technology companies, SaaS platforms, and fintechs where API integrations and CI/CD pipelines are central to how the product ships. Similar organisations are encouraged to look at what their current monitoring is actually configured to watch for, and whether the machine credential category, service account tokens, API keys, OAuth refresh tokens, is explicitly in scope alongside the human credentials, or only implicitly hoped to be there. The programs that closed this gap did so because someone looked at the scope on paper next to a real stealer log and noticed the mismatch. The programs that have not, will, when a full log lands in a buyer’s hands.