When Service Accounts Attack: How Identities are Weaponized

When organizations analyze identity-related breaches after the fact, the narrative often focuses on the human element: a phishing email, a stolen password, a compromised account. That framing is technically accurate but operationally misleading.

By the time a human credential was involved, the attacker had often already established persistence through something your IGA platform wasn't watching.

Look at the actual kill chains in the major identity breaches of the last three years. The entry point was frequently mundane: a long-lived OAuth refresh token with a broad scope.

A service account with administrative privileges and no owner on record. An API key committed to a repository months before anyone noticed.

The attacker didn't break your MFA. They used a credential that was never subject to it.

This article is about the mechanics of when service accounts attack: how attackers find and exploit NHIs, what the pattern looks like once it's in motion, and where the defensive gaps consistently appear.

How Attackers Find NHIs Before You Do

Non-human credential discovery is not sophisticated. That's what makes it scalable for attackers. The most common initial access vectors for NHI exploitation are:

Public Repository Exposure

API keys, connection strings, and service account credentials are committed to GitHub, GitLab, and Bitbucket every day. GitGuardian's research found nearly 24 million new leaked credentials on GitHub in a single year.

The more significant finding is that 70% of secrets leaked in 2022 were still valid years later. Organizations discover the leak. They don't always rotate the credential. The window of exposure extends far beyond the initial incident.

CI/CD Pipeline Credential Sprawl

Build and deployment pipelines require access to production environments. That access is typically provisioned as long-lived service credentials including environment variables, stored secrets, and pipeline configurations.

These credentials are often over-privileged because they were set up under pressure during initial deployment and never revisited. An attacker who can compromise a pipeline effectively inherits the access it was granted.

SaaS Integration Token Abuse

Modern enterprise environments run hundreds of SaaS applications. Most of them are connected to each other through OAuth integrations. Those grants were approved once, often by someone who is no longer in the organization, and persist indefinitely unless explicitly revoked. These grants often carry scopes far broader than the original use case required.

"The biggest SaaS breach of 2025 didn't start with a compromised employee account. It started with an OAuth token and ended with access to hundreds of downstream environments."

The Salesloft-Drift integration breach is the case study every security team should have internalized. Attackers compromised OAuth access and refresh tokens that were long-lived and broadly trusted.

Because the tokens themselves were valid, standard detection controls didn't fire. The blast radius, measured at roughly 10 times the scale of previous comparable incidents, came from the trusted relationship between integrated systems, not from any single compromised account.

The Attack Pattern: What Lateral Movement Looks Like Through NHIs

Once an attacker has a valid NHI credential, the operational playbook is well-established:

Establish persistence silently: Unlike human accounts, service accounts and API keys don't have session timeouts enforced by a conditional access policy. A valid token remains valid. The attacker can operate indefinitely without re-authenticating, and without triggering the authentication events that SIEM rules are often tuned to detect.

Enumerate permissions: The first question an attacker asks after gaining a foothold is what the compromised credential can do. Over-privileged service accounts, the ones that were granted broad access because it was easier than scoping correctly, provide the answer attackers want. One credential; access to multiple systems.

Move laterally via trusted connections: The most dangerous aspect of NHI-based lateral movement is that it exploits existing, trusted integration paths. An attacker operating through a legitimate service account or API key is traversing the same connections your legitimate automation uses. Detection requires behavioral analysis, not just credential validation. Most environments aren't running that analysis on machine identities.

Exfiltrate or escalate without malware: This is the characteristic that makes NHI-based attacks particularly difficult to detect and attribute. The 2026 NHI Reality Report put it plainly: NHI-based kill chains in 2025 operated through poor governance in frameworks, not advanced malware. No payload, no malicious binary. Just valid credentials doing things valid credentials are allowed to do.

The Governance Gaps Attackers Rely On

Across the NHI incidents of the last three years, the defensive failures cluster around a predictable set of gaps. These are not exotic weaknesses. They are the predictable consequences of building IAM programs for human identities and extending them imperfectly to machine credentials.

No ownership model: When a credential has no documented owner, no one is responsible for reviewing it, rotating it, or decommissioning it when it's no longer needed. Orphaned credentials accumulate. An IAM program that requires every service account to have a named owner and a review cadence closes this gap; most don't.

Long-lived credentials: Human passwords expire. Sessions time out. MFA adds friction. None of these controls apply to a static API key or a service account password that was set during initial configuration and never touched again. The move toward short-lived, dynamically issued credentials, a principle embedded in SPIFFE/SPIRE and modern workload identity architectures, directly addresses this, but most enterprise environments haven't made that transition.

Over-privileged scopes: The path of least resistance during integration setup is to grant broad access and scope down later. Later never comes. The result is a population of service accounts and tokens with permissions that far exceed what their actual function requires, representing significant blast radius if compromised.

No rotation cadence: Credential rotation is mandated for human passwords in most compliance frameworks. There is often no equivalent requirement for service account credentials, API keys, or OAuth tokens. The GitGuardian finding on multi-year credential validity isn't an anomaly. It's the operational reality of environments where rotation is manual, exception-based, and often triggered only by a breach.

What the Detection Gap Looks Like

Most enterprise detection capabilities have been built and tuned around human identity behavior. Login events, authentication failures, impossible travel, after-hours access: these signals make sense for user accounts and generate actionable alerts. For non-human identities, the same signals become noise.

A service account that authenticates ten thousand times a day is not behaving anomalously. That's normal operation.

Detecting abuse requires a different baseline: understanding what the credential should be doing and flagging deviations from that pattern, not flagging the behavior itself. That requires identity context that most SIEM deployments don't have for machine identities.

The detection gap is closing, but it's not closed. Until organizations treat NHIs as first-class identity principals with the same instrumentation and behavioral monitoring applied to human accounts, the gap will continue to produce incidents.

The Path Forward

The good news is that the attack patterns are well understood, and the defensive response is not exotic. It maps directly to the core disciplines of mature identity governance:

• Full inventory with documented ownership for every NHI in the environment
• Least-privilege scoping enforced at issuance and reviewed periodically
• Short-lived credential architectures that limit the utility of any single compromised secret
• Rotation cadences and automated enforcement rather than manual exception handling
• Detection tooling calibrated for machine identity behavior, not just human behavioral baselines

The organizations that have made meaningful progress on NHI security aren't running exotic tooling. They're applying the identity governance disciplines they already know to a population of identities that was previously outside the scope of their program.

What This Means for You

Need to strengthen your non-human identity governance? Our team is here to make it possible. Contact us now to discuss a custom roadmap.