GitGuardian Honeytoken Deploys Decoys to Catch Credential
GitGuardian's Honeytoken service uses decoy credentials deployed via MDM to detect credential harvesting in real time, alerting when stolen keys are
Credential harvesting malware has evolved to scan entire filesystems, validating stolen data within seconds. This speed makes traditional detection too slow, but creates an opportunity for deception-based alerts.
GitGuardian's Honeytoken service plants fake credentials on developer machines. When an attacker steals and tests one, it triggers an immediate incident alert. The service deploys decoys fleet-wide using existing mobile device management (MDM) tools, solving the scalability problem that hindered manual honeytoken placement.
How Modern Harvesters Enable Deception
Earlier infostealers targeted a short list of known locations like browser stores. Current families, such as Shai-Hulud, cast a wider net by secretly scanning the entire disk for anything resembling a credential. This broad search means they will inevitably pick up a strategically placed decoy.
The critical shift is in validation speed. A harvester now tests a stolen credential in seconds, not hours. "Initial compromise is no longer a window you get to investigate," the source states. The moment an attacker attempts to use the decoy is the alert, and it is the only moment early enough to stop further access.
Operationalizing Deception at Scale
While the concept of honeytokens is not new, manual deployment did not scale. Decoys would disappear as machines were reimaged, creating false security. GitGuardian integrated deployment into its Developer Endpoint Protection agent, which uses MDM to place and maintain decoys across thousands of machines automatically.
The dashboard shows which endpoints actually carry a decoy, and deleted decoys are replaced on the next sync. Research into actual stealer behavior informed the design, ensuring decoys are placed where harvesters actively look, such as in source code repositories, config files, and CI pipelines.
The Alert and the Infrastructure
When a honeytoken is used, GitGuardian raises an incident naming the specific machine and source file. The alert routes through the team's existing systems like email, Slack, or ServiceNow. "Nobody has to watch a new console," which reduces alert fatigue, as these alerts have a near-zero false-positive rate.
The current decoys are real AWS credentials issued from a GitGuardian-controlled account. Every API call against that key is logged, providing details on the attempt's timing and source. This infrastructure is kept separate from identifying marks to avoid detection by motivated attackers.
Extending Coverage Beyond AWS
The service is expanding to cover other credential types heavily targeted by recent worms, such as Kubernetes cluster access and package registry logins. These require building convincing decoys with backend infrastructure ready to recognize and log validation attempts.
Google Cloud and Azure credentials are a lower priority. "Our review of infostealer samples shows they are barely touched today," the report notes. The focus is on credential types where harvesting is actively occurring.
An Inherent Limit and Future Direction
Deception only detects use, not theft. A stolen decoy that is never used will not alert. Therefore, honeytokens are designed to work alongside credential discovery tools, which inventory exposed valid credentials for revocation.
Future development aims to place decoys in more environments like CI runners and Kubernetes clusters, and to support more credential types. The goal is to have detection waiting in the paths where AI coding tools and other trends are expanding the credential surface on developer machines.
