# Credential Harvesting Explained: How Attackers Collect Secrets From Developer Machines > Source: > Published: 2026-09-03 13:45:11+00:00 **TL;DR:** Credential harvesting is the large-scale collection of valid credentials that lets attackers log in as legitimate users. Developer machines are an especially rich source: unlike phishing, the credentials already sit in plaintext on disk, so no one needs to be tricked. Case in point: credential abuse remains the single most pervasive technique across full breach chains. According to [Verizon's 2026 Data Breach Investigations Report](https://www.verizon.com/business/resources/reports/dbir/), credential abuse appears in 39% of breaches when investigators trace the full attack chain, not only the first step in the process. Most articles on the topic describe phishing attacks, where a fake login page tricks someone into entering a password. However, there is a second vector that matters more for engineering organizations: Credentials on developer machines. Said credentials include cloud keys in config files, tokens in shell history, SSH keys, and secrets cached by AI tools. Most of them sit in plain text, and are easy to steal. An attacker who gains access to one of these machines doesn't need to trick anyone. The credentials are there, waiting for them to harvest. This article is for anyone who wants to learn how credential harvesting works, why developer machines are at risk, how to find the credentials before attackers, and how to catch the harvest as it happens. Credential harvesting is the large-scale collection of login credentials, like usernames, passwords, API keys, authentication tokens, and session cookies. Attackers gather them to use or sell on the dark web. It's important to understand that attackers rarely target a single account. Instead, they aim to collect as many valid user credentials across an organization as possible. Doing so gives them the best chance to log in as a legitimate user and avoid the controls that keep other intruders out. To clarify, credential harvesting isn't one technique. It's the outcome of many techniques working together to access systems as legitimate users and steal sensitive data. Two quick distinctions: credential stuffing is the downstream step of replaying already-stolen credentials against login forms to see which still work, whereas harvesting is what fills that bucket in the first place. Attackers harvest credentials in a variety of ways. Examples include adversary-in-the-middle phishing kits that defeat basic multi-factor authentication, keyloggers, malicious browser extensions, and breach dumps traded on the dark web. All credential harvesting schemes sort into two broad vectors: The technique that matters most here is the adversary-in-the-middle (AitM) kit. It proxies a real login in real time and captures the session cookie after authentication, so it sidesteps multi-factor authentication (MFA) rather than trying to defeat it head-on. That turns MFA from a hard stop into a control attackers routinely work around, which is why this vector deserves more attention than the classic fake-login-page playbook. Device code phishing works along similar lines: instead of proxying a login, the attacker tricks the user into approving a legitimate device-authorization request, which hands over a fully authenticated session — again without ever capturing the password itself. It helps to separate how a victim is lured from how their credentials are actually captured. The distribution techniques — phishing emails, lookalike domains, and watering-hole sites — still rely on social engineering to get someone to a malicious site, and they remain common even though most organizations already blunt them. What varies is the exploitation technique used once the victim arrives. In classic phishing, a fake login page simply collects whatever is typed into it. AitM is an evolution of the same playbook rather than a break from it: the victim is still lured, usually by email, but the malicious site now proxies the real login to capture the session cookie after authentication. Because the delivery is unchanged, the same defenses apply — email security and awareness training, such as spotting suspicious senders and checking the real domain, work against AitM much as they do against classic phishing. What has genuinely shifted the balance is the endpoint, where credentials can be harvested with no user to trick at all. Malware, most often an infostealer, reads credentials on a device, like cloud credential caches, .env and config files, shell history, SSH keys, browser tokens, and AI tool caches. This malware doesn't make any phishing attempts or otherwise try to trick employees. It's arguably the purest form of credential harvesting because the malware simply reads what's on the device and reports back to the attacker. It's important to note that infostealers don't stop at usernames and passwords. They also grab session cookies and previously authenticated tokens, which enables attackers to skip the multi-factor authentication (MFA) step rather than trying to defeat it. For most attackers, this is a preferable approach to credential theft, and why it's gaining popularity. Security teams need to be aware and act. This is especially true for developer machines, where the density of valid credentials is highest. [A developer laptop accumulates valid, long-lived credentials](https://blog.gitguardian.com/laptop-as-credential-store/) across many predictable locations. Unfortunately, none of them live in repositories that standard code scanning can see. Because of this, when attackers gain access to developer machines, they can often view cloud keys in ~/.aws and similar directories, tokens in .npmrc and shell history, SSH keys, and secrets cached by AI coding tools. This last category is especially vulnerable. GitGuardian's own endpoint research found that [40% of high and critical secrets on developer laptops](https://blog.gitguardian.com/extending-our-mission-with-developer-endpoint-protection/) surface in AI tool directories and log files, i.e., locations no traditional scanner looks at. As you're likely aware, a single harvested cloud key or registry token can grant legitimately authorized access directly to production, with no further attack required. [That's what makes the developer machine such an attractive target](https://blog.gitguardian.com/perimeted-moved-to-laptop/). It not only contains the most secrets, but also the most sensitive information. Worse, the credentials on developer machines are often long-lived and rarely rotated. GitGuardian's 2026 State of Secrets Sprawl report found that [64% of secrets confirmed valid in 2022 were still valid in January 2026](https://blog.gitguardian.com/the-state-of-secrets-sprawl-2026/). In other words, a harvest from a developer machine is useful for years, not months. To make the two vectors concrete, here are three credential harvesting examples. On the machine, the harvesting tool is typically an infostealer, as mentioned earlier. An infostealer is usually lightweight malware designed to read the exact files where developers store credentials, then exfiltrate them. This is what most people mean when they search for credential-harvesting malware or tools built for the endpoint rather than the inbox. Put simply, once installed, the infostealer scans known credential locations, packages what it finds, and exfiltrates it. The output often ends up bundled and sold as stealer logs on dark web marketplaces, where other threat actors buy access to compromised accounts rather than harvesting data themselves. This isn't always the case, though. Attackers can also use the credentials themselves. Most organizations defend against credential-based attacks by preparing for phishing and other malicious behavior. Few of them inventory the harvestable credentials sitting on their devices. Because the read is hard to catch, you should reduce what's available to harvest, discover what's already there, and plant tripwires that fire when attackers take credentials, to defend against malicious software. To defend against credential harvesting, you must account for both vectors. For credential harvesting phishing, standard controls apply. For the endpoint harvest, the goal is to first leave less to harvest. Then, find what's already there, and get alerts as soon as attackers take credentials. If you take the above precautions, you'll detect harvest events, not only reduce what's available to take. If you're serious about how to prevent credential harvesting on your organization's developer machines, you need more than a single scanning tool. You need three separate layers to work together. Is this spyware running on developer laptops? No, and that distinction matters for adoption. This is credential discovery, not surveillance: ggshield runs locally and sends back only a hash and metadata, never the secret value or the source files, and it focuses on the high-risk locations where credentials accumulate. Browser token stores, for example, remain the job of your EDR and identity controls. The agent already runs on more than 600,000 developer machines. It is also not a separate console to babysit. Findings land in the same platform as your repository and CI secret scanning, so endpoint results deduplicate and prioritize alongside the alerts you already triage rather than starting a second queue. What good looks like here is measurable, not vague: growing coverage of the machines and locations that actually hold live credentials, and a shorter, tracked time-to-revoke once a finding is confirmed. Honeytokens make the harvest itself measurable too. Because a honeytoken has no legitimate use, a single deployment is a high-confidence signal with almost no false positives, and that alert routes straight to whoever owns incident response, so a silent harvest becomes a paged event. At the end of the day, our tool complements email security, EDR, secrets managers, and identity controls rather than replacing them. The goal is to find harvestable credentials and catch a harvest before an attacker can use what they collect. There are a few trends you need to know about to protect your organization's systems. These trends include commoditized harvesting, AI tools, and sessions. Credential harvesting is the bulk collection of valid credentials, and it remains one of the most consistent threats to both sensitive systems and critical systems. While phishing is common, developer machines offer a richer harvest, because cloud keys, tokens, and SSH keys sit in plaintext for infostealers to read. Defending against credential harvesting requires organizations to harden against phishing and, equally as important, leave less to harvest on the endpoint, discover what's already there before an attacker does, and plant honeytokens that fire the moment an attacker takes a credential. All of these strategies work best as a complement to the controls your security team already runs, not as a replacement for them. **What is credential harvesting?** Credential harvesting is the large-scale collection of valid credentials, such as usernames, passwords, API keys, and tokens, for use or resale by an attacker. The aim is volume, as the attacker tries to steal as many working credentials as possible across an organization, rather than one specific account. **How does credential harvesting work?** Common credential harvesting strategies work through two main vectors. The first tricks a person into entering credentials on a fake login page. The second deploys malware, usually an infostealer, to read credentials that already sit in plaintext on a device. The second vector requires zero deception. **What is the difference between credential harvesting and credential stuffing?** Credential harvesting collects the credentials. Credential stuffing replays already-stolen credentials against login forms to find ones that still work. Harvesting fills the bucket, while stuffing pours it out. **Is credential harvesting the same as phishing?** No. Phishing is one vector used to harvest credentials by tricking a person. Harvesting is the goal, and phishing is just one way to reach it. On developer machines, the credentials already sit on disk, so an attacker who can run code there, whether the malware arrived via phishing, a drive-by download, or a compromised dependency, can harvest them without tricking anyone into typing a password. **What are examples of credential harvesting?** A phishing kit serving a fake SaaS login page or an infostealer reading cloud keys and shell history from a developer laptop. Both attempt to exfiltrate sensitive information from legitimate organizations. **What is credential harvesting malware?** Credential harvesting malware is malware built to collect credentials from a device. Most malware of this type are infostealers. The malware reads files where developers store credentials, like cloud caches, config files, and browser storage, then exfiltrates them, either to package for sale as stealer logs or for personal use. **How do you prevent credential harvesting?** Defend both vectors. First, use phishing-resistant MFA and email filtering to guard against phishing. Then, for endpoints, reduce long-lived credentials, [discover secrets](https://blog.gitguardian.com/local-guardrails-for-secrets-security/) already on the machine, plant honeytokens that fire when an attacker takes a credential, and revoke what shouldn't be there. **How do you detect credential harvesting on an endpoint?** Detecting the file read itself is hard, which is why GitGuardian pairs endpoint discovery with honeytokens. Doing so places decoy credentials in the exact locations that harvesting tools look for them. As such, the system catches the harvest event the moment an attacker uses one of those decoy credentials, even if the original read went unnoticed.