What Is Credential Harvesting? The Attack That Bypasses Your Password Manager

Credential harvesting is a broad category. Most people associate it with phishing: a fake login page, a spoofed email, an employee who enters their password somewhere they shouldn't. That's real, it's common, and it's worth defending against.

This article focuses on a different variant — one that gets less attention in SMB security discussions. Automated infrastructure credential harvesting targets the backend keys your systems use to communicate with each other: database connection strings, cloud access keys, API tokens. It doesn't require anyone to click anything. And your existing phishing defenses don't cover it.

Here's what it is, which businesses have real exposure, and the questions worth raising with your IT team.

---

What Is Credential Harvesting?

Credential harvesting refers to techniques attackers use to collect authentication credentials in bulk. It's a broad category that includes several distinct approaches:

• Phishing and domain spoofing — Fake login pages and spoofed emails that trick employees into entering their passwords. This remains the most prevalent method and is what most security awareness training addresses.
• Infostealer malware — Malicious software installed on an endpoint that harvests saved browser credentials, session cookies, and stored passwords from the device. Infostealers extracted 1.8 billion credentials in the first half of 2025 alone (Flashpoint, 2025) and are widely available as a service.
• MFA fatigue / prompt bombing — Attackers who already have a user's password flood their MFA app with approval requests until the user accepts one out of frustration. This bypasses MFA without breaking any cryptography.
• Session hijacking — Rather than stealing passwords at all, infostealers and adversary-in-the-middle proxy tools steal active browser session cookies. A valid session token lets an attacker access an account as if they were already logged in — bypassing MFA entirely, because the authentication already happened.
• Automated infrastructure scanning — Tools that probe servers, code repositories, and configuration files for machine-to-machine credentials: cloud access keys, database connection strings, API tokens. No employee interaction required.

The first four methods target people. User training, phishing-resistant MFA, and endpoint security are the right defenses for them. The fifth — infrastructure scanning — targets your systems, and requires a different response entirely. If phishing is picking someone's pocket, infrastructure harvesting is finding a spare key left under the doormat: no confrontation, no victim, no immediate sign that anything happened.

The credentials targeted in the backend variant are not in your password manager. They are machine-to-machine credentials — the key your website uses to connect to its database, the access token your cloud infrastructure uses to authenticate between services, the API key that lets your CRM talk to your accounting software. These live in configuration files on servers, not in any vault your team manages.

Password managers protect what your team types. They don't protect what your systems use to talk to each other.

---

What Types of Credentials Do Attackers Target?

The credentials at risk in a harvesting attack are backend infrastructure keys — cloud account credentials, database connection strings, and third-party API tokens — rather than the login passwords your team uses day to day.

Because these are machine-to-machine credentials, they sit outside the scope of employee password managers. The most commonly targeted credential types include:

• Cloud account access keys — IAM credentials that authenticate to AWS, Google Cloud, or Azure. With these, someone outside your organization can provision resources, access stored data, and run workloads charged to your account.
• Database connection credentials — The username and password your website uses to read from and write to your database. With direct database access, an attacker can retrieve customer records without interacting with your website's front end at all.
• SSH private keys — Cryptographic keys that authenticate direct command-line access to servers. These are often used to move between systems once initial access is established.
• Payment processor API keys — Credentials for services like Stripe or Braintree. A compromised API key can expose customer payment data or allow unauthorized refund activity, depending on the key's permissions.
• Code repository tokens — Access tokens for GitHub, GitLab, or Bitbucket. These give read access to your codebase, which frequently contains additional credentials that haven't been removed from the code itself.
• Kubernetes service account tokens — In containerized environments, these tokens control access to running application workloads and can be used to extract configuration data or deploy changes.
• AI platform API keys — API credentials for services like OpenAI are increasingly targeted. A stolen key can be used to run inference jobs or consume compute quotas billed to your account.

Once credentials are obtained, they tend to be used in one of three ways:

1. Cloud resource abuse — Spinning up compute instances to run cryptocurrency mining operations is a well-documented pattern. The account owner is typically unaware until an unexpectedly large bill arrives.
2. Data access — Using database or API credentials to retrieve and copy customer records, transaction history, or other stored data.
3. Maintaining access — Creating new credentials or access paths that remain valid even if the original compromise is discovered and the affected password is changed.

How attackers find these credentials: Automated scanners probe publicly exposed servers and code repositories for recognizable credential patterns. Tools like Mimikatz and LaZagne are used in post-compromise scenarios to dump credentials from running systems. For infrastructure keys specifically, tools scan for common patterns — AWS key prefixes, private key file signatures, connection string formats — across exposed services and public code repositories.

The hardcoding problem: One of the most common routes to credential exposure isn't a sophisticated attack — it's a developer pushing code to a public GitHub repository with credentials left in the file. According to GitGuardian's 2026 State of Secrets Sprawl report, 28.65 million new hardcoded secrets were added to public GitHub commits in 2025 alone — a 34% increase year over year. The report also found that AI-assisted code commits leak secrets at roughly twice the GitHub-wide baseline rate: developers using tools like Claude Code leaked secrets at 3.2% of commits versus the 1.5% baseline. The combination of faster code generation and less security experience among developers new to the field is accelerating exposure. No scanning tool required: the credentials are publicly visible to anyone who looks.

Recent context: In the first week of April 2026, Cisco Talos researchers confirmed a campaign exploiting CVE-2025-55182 (React2Shell), a vulnerability in Next.js web applications. According to reporting from The Hacker News and SecurityWeek, 766 hosts were confirmed breached via automated scanning — no employee interaction was required in any case.

On supply chain risk: When attackers obtain npm or pip registry tokens — the credentials used to publish software packages — the risk extends beyond the original victim. A stolen registry token can be used to publish a modified package update under a trusted name, which may then be installed by other organizations that depend on that package.

---

Who Is Most at Risk for Credential Harvesting?

Any business that uses cloud hosting, custom software integrations, or backend systems that communicate with each other has credentials stored somewhere. The meaningful question is whether those credentials are stored safely and whether anyone is monitoring them.

Lower complexity — A five-person professional services firm with a straightforward website and no custom integrations has a smaller set of credentials to manage. The relevant questions are basic: is someone watching the cloud account, and when were the access credentials last reviewed?

Higher complexity — A 30-person e-commerce operation with a developer-built storefront, a payment processor integration, a CRM connected to email marketing, and inventory software linked to shipping carriers has credentials in six or more locations. Each integration adds a credential that needs to be stored somewhere and maintained over time. The scope of review is different, but the questions are the same.

How your website is hosted is part of this picture — the same infrastructure decisions that affect performance and uptime also affect how credentials are stored and who can access them.

The businesses that tend to be caught off-guard are those in the middle: technically mature enough to have real integrations and cloud infrastructure, but without the in-house security function that larger organizations rely on. A company that brought in a developer a few years ago to build out integrations and then handed it off often has credentials sitting in configuration files on a server that hasn't been reviewed since.

---

5 Security Questions to Ask Your IT Provider

The following questions are intended for a conversation with your IT team, MSP, or the developer responsible for your infrastructure — not as tasks for you to implement directly. They're designed to give you a clear picture of where you stand.

1. Where do our websites and applications store connection credentials?

A capable IT provider should be able to answer this readily. If credentials are stored in plain configuration files on a server rather than in a dedicated secrets manager, that's worth addressing. If the answer is "I'm not sure," a basic audit is the right first step.

2. Who is explicitly responsible for patching our web frameworks and backend software?

The React2Shell campaign that compromised 766 hosts in April 2026 targeted an unpatched vulnerability in Next.js. Outdated software is the attack surface; patching closes it. The critical follow-up question is who owns that patch responsibility — developer, MSP, or internal IT. If it falls in a gap between them, it doesn't get done.

3. If a credential were compromised, how quickly would we know?

AWS GuardDuty, GCP Security Command Center, and Microsoft Defender for Cloud each include a 30-day free trial and detect anomalous credential use — the kind of unusual API activity that signals a compromise. Whether those tools are enabled and whether anyone reviews their alerts are two separate questions worth asking.

4. When were our cloud account credentials and access keys last rotated?

Many small businesses discover credentials that have been active for three or more years without review. An access key issued to a developer who left two years ago is still a valid key until someone explicitly revokes it. Rotation is a scheduled practice, not a one-time event.

5. What would happen to our business if someone accessed our cloud account for 24 hours?

This question is useful because it prompts a specific answer rather than a general one. If the answer involves customer data, financial systems, or critical operations, that's where security attention is most warranted. If the scope is more limited, the conversation still clarifies your risk profile and helps prioritize what to address first.

---

What Does Good Credential Security Look Like?

Well-secured credentials live in dedicated, access-controlled vaults — not buried in configuration files, hardcoded in application code, or shared in a Slack thread.

The right analogy: instead of leaving a spare key taped to the back of a door, you put all keys in a locked cabinet with a sign-in log. You know exactly which keys exist, who has access to each one, and when each key was last used or rotated.

In practice, this is what a secrets manager does. Options exist at every complexity level:

• Cloud-native — AWS Secrets Manager, GCP Secret Manager, and Azure Key Vault are built directly into the cloud platforms many businesses already use. Access to these tools is often already included in an existing subscription.
• Cross-platform — HashiCorp Vault (open-source, with a managed cloud version) works across multiple cloud environments and is better suited to businesses with mixed infrastructure.

For IT teams, the detection side is equally important: tools like TruffleHog, GitGuardian, and GitHub Advanced Security scan code repositories and configuration files for exposed credentials automatically — catching hardcoded secrets before attackers find them first.

A capable IT provider or MSP should be able to audit your credential storage and rotation practices in a single working session. If that conversation has never happened, the five questions above are how you start it.

For the full breach prevention picture beyond credentials, the 90-day breach prevention roadmap covers how a well-protected small business prioritizes limited security budgets.

---

What to Do If Your Credentials Are Exposed

If your IT team discovers that credentials have been compromised — or you receive a cloud bill for resources you didn't authorize — the response follows a clear sequence. Responding promptly reduces the window of potential misuse.

Step 1: Revoke the affected credentials at the provider level. Revocation is different from rotation. Rotation creates a new credential, but the old one remains valid until it expires or is explicitly disabled. Revocation disables the credential immediately. Your IT team should go directly to the relevant provider — AWS IAM, the GitHub token settings, the Stripe API dashboard — and disable the affected key before taking other steps.

Step 2: Review the access logs for the affected credential. AWS CloudTrail, Google Cloud Audit Logs, and Azure Activity Log record API calls made with each credential. Reviewing these logs for the period the credential was active helps establish what was accessed, what data may have been retrieved, and whether any new access paths were created. This review determines whether the incident is contained or whether additional steps — including breach notification — are required.

Step 3: Rotate related credentials in the same environment. Once the scope is understood, rotate any other credentials that were stored in the same location as the compromised key. Attackers who obtain one credential from a configuration file often look for others in the same environment. Rotating adjacent credentials closes that path.

---

Related Resources

• Secrets Hygiene Checklist for SMB DevOps — The technical implementation counterpart to this article: SSH key rotation, repository scanning, and secrets management for IT teams and MSPs.
• Best Password Manager for Small Business — What password managers protect, what they don't, and which tools work best for small business teams.
• Hosting Security Checklist for Small Business — How your web hosting decisions affect security posture, including where credentials live in a typical hosting setup.
• Small Business Breach Prevention Guide — The 90-day roadmap for building a defensible security baseline without a dedicated security team.
• Best Cybersecurity Software for Small Business — A broader look at the security tools worth investing in for businesses building out their security stack.