Low-and-slow Credential Harvesting

A campaign style that limits volume to reduce detection and extend dwell time. Instead of blasting many targets, attackers selectively expose only a fraction of traffic, which makes the operation harder to spot with tools tuned for noisy phishing or bulk abuse.

Expanded Definition

Low-and-slow credential harvesting is an attacker operating pattern, not a separate class of credential. It describes how an adversary selectively probes a small number of accounts, endpoints, or authentication flows over time to avoid rate limits, anomaly scoring, and alert thresholds. In NHI environments, that usually means service accounts, API keys, OAuth tokens, workload identities, or secrets buried in logs and pipelines. The technique aligns with the broader non-human identity risk landscape described in the OWASP Non-Human Identity Top 10, even though no single standard governs this term yet. Definitions vary across vendors, but the security meaning is consistent: the attacker values dwell time and stealth more than speed.

This pattern is often confused with ordinary password spraying or bulk phishing, but the difference is operational cadence and signal suppression. It may involve sparse API calls, delayed retries, limited target rotation, and careful reuse of compromised access paths to avoid triggering NIST SP 800-63 Digital Identity Guidelines style assurance expectations. The most common misapplication is treating it as generic credential stuffing, which occurs when defenders assume high-volume login failures are required for detection.

Examples and Use Cases

Implementing detection for this pattern rigorously often introduces more telemetry, tuning, and correlation work, requiring organisations to weigh earlier warning against greater analytical overhead.

• A threat actor tests a single cloud access key every few hours from rotating infrastructure, keeping traffic below alert thresholds while checking whether the key can reach storage or build systems.
• A campaign quietly enumerates exposed tokens in application logs, then uses only one token at a time to validate scope and privilege before moving laterally.
• An attacker exploits a compromised CI/CD secret, but spaces out usage to avoid the burst patterns commonly seen in the CI/CD pipeline exploitation case study.
• Security teams reviewing the Secret Sprawl Challenge use sparse-access detection to spot one-off secret use from unusual hosts rather than repeated failures.
• Analysts compare low-frequency requests against baseline behaviour in cloud and identity logs, then confirm whether the pattern matches credential access guidance in NIST SP 800-53 Rev 5 Security and Privacy Controls.

Why It Matters in NHI Security

Low-and-slow harvesting is dangerous because NHI environments often assume that abuse will look noisy. If access to a token, certificate, or service account is used sparingly, defenders may not notice until the credential is replayed in a privileged workflow or chained into a larger intrusion. NHIMG research shows that 23.7% of organisations still share secrets through insecure methods such as email or messaging applications, which increases the pool of credentials available for this style of campaign, and only 19.6% express strong confidence in securely managing workload identities in the first place. Those conditions create ideal hunting ground for stealthy collection and delayed misuse. The Guide to the Secret Sprawl Challenge and the Ultimate Guide to NHIs — Static vs Dynamic Secrets both reinforce why static credentials are especially exposed to this behaviour. Organisational detection also benefits from the event-driven logging and identity assurance concepts reflected in OWASP and NIST guidance. Organisations typically encounter the impact only after a dormant credential is used in a real intrusion path, at which point low-and-slow harvesting becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• Why do fixed traffic rules miss low-and-slow attacks?
• What do security teams get wrong about low-and-slow application probing?
• What do security teams get wrong about low-and-slow login attacks?
• What breaks when group membership updates are slow in a credential system?