When Attackers Don’t Break In, They Log In

For years, the working assumption of cloud security was simple: keep attackers out. Teams scanned for exposed servers, misconfigured storage buckets, and unpatched systems. Firewalls, endpoint agents, and network monitoring tools were built around one assumption: attackers would attempt to break into the environment. That assumption is now a liability. Today’s attackers rarely break in. Instead, they log in using stolen identities, developer credentials, CI/CD automation accounts, API tokens, and service identities, which have become the primary attack surface in modern cloud environments. When attackers obtain these identities, the infrastructure behind them is already unlocked.

The 2025 Nx supply chain compromise demonstrates this shift clearly. A malicious package inserted into the Nx ecosystem harvested credentials from developer systems and exposed thousands of secrets, including GitHub tokens, SSH keys, and cloud credentials, according to Kaspersky Security Research.
Those credentials allowed attackers to pivot from developer machines into repositories, CI/CD pipelines, and potentially cloud infrastructure. The Nx attack did not reveal a new vulnerability. It revealed a new target. Identity is now the true security perimeter of the cloud.

The Nx Supply Chain Compromise

Nx is a widely used JavaScript build system. Thousands of engineering teams depend on it to manage monorepos and large application codebases. On August 26, 2025, attackers exploited a vulnerability in the project’s release pipeline. By injecting malicious code into a GitHub Actions workflow, they were able to steal the npm publishing token used to release official Nx packages, as described in the Nx postmortem. Using that token, the attackers published modified versions of Nx packages to the npm registry. Developers installed these packages without suspicion, unknowingly executing a malicious post-install script embedded within the dependency.

The malware scanned the developer’s system for sensitive data such as:

• GitHub Personal Access Tokens
• npm authentication tokens
• SSH private keys
• API keys and cloud credentials
• environment variables containing secrets

The stolen data was then uploaded to attacker-controlled GitHub repositories, later documented in the GitHub Security Advisory. The malicious packages were live for only a few hours. That was enough. While the malicious code was incidental. The identities it collected were not.

The Real Target Developer Identities

Modern software development runs on developer identities. A typical workstation contains credentials used to access:

• internal Git repositories
• CI/CD automation pipelines
• cloud deployment systems
• internal APIs and services

For an attacker, a developer workstation is not an endpoint. It is a master key. Once malware executes on a developer machine, it gains access to a rich pool of credentials. GitHub tokens, SSH keys, and npm tokens can enable further access across the entire software development lifecycle, as observed by Kaspersky Security Research.

From there, attackers can begin exploring internal systems. Using compromised GitHub tokens, they can:

• access private repositories
• analyse CI/CD workflows
• identify automation accounts used for deployment
• extract additional secrets from configuration files

At this stage, the malware is irrelevant. The attacker has become, for all practical purposes, a legitimate user. That makes the activity extremely difficult to distinguish from normal operations.

CI/CD Pipelines A Hidden Identity Attack Surface

Modern development pipelines rely heavily on automated identities. CI/CD systems authenticate to cloud platforms using temporary credentials generated through trust relationships, with OpenID Connect often used in this architecture.

The authentication chain typically looks like this:

GitHub Actions

• OIDC authentication
• Cloud IAM role
• Temporary cloud credentials

This architecture was designed to improve security. What it also introduces is a powerful trust relationship. If attackers compromise the CI/CD identity itself, they can leverage the same authentication flow used by legitimate pipelines. In the Nx attack chain, stolen developer credentials could allow attackers to examine CI/CD workflows, identify automation accounts responsible for deployments, and authenticate to the cloud using the exact same trusted mechanisms used by the pipeline. No vulnerability required. Just identity.

The Privilege Escalation Problem

Initial access to cloud environments is rarely the attacker’s final objective. Once inside, they begin searching for opportunities to escalate privileges. Automation identities frequently prove to be the weakest link. CI/CD roles accumulate permissions the way organizations accumulate technical debt. Gradually and often invisibly. These roles may have privileges to create resources, deploy infrastructure, or modify configurations. In poorly configured environments, these roles may also have permissions to modify IAM identities. This creates a dangerous escalation path. A compromised automation role can deploy infrastructure templates that create new identities with full administrator privileges. The escalation chain may look like this:

Developer credential

• GitHub service identity
• CI/CD automation role
• OIDC authentication to cloud provider
• new administrator IAM role

Within minutes, an attacker holding a stolen developer token can hold the keys to the entire cloud.

Credential compromise → identity abuse → privilege escalation → cloud takeover.

Why Identity Driven Attacks Are Hard to Detect

-Traditional security tools were not built for this threat. Three structural gaps explain why.

1) Developer Environments Contain Many Secrets

Developer systems often contain dozens of credentials needed for development and deployment, including GitHub tokens, SSH keys, cloud access credentials, and API keys. When supply chain malware runs on these systems, it gains immediate access to a large number of live identities.

2) Automation Identities Often Have Excessive Privileges

CI/CD automation roles frequently accumulate permissions over time, often reaching privileges that allow an attacker to deploy infrastructure, modify policies, or create new identities. When compromised, these roles can become powerful escalation points.

3) Identity Activity Is Rarely Monitored

Many organizations collect authentication logs but lack the analytics needed to detect abnormal identity behavior. Identity-driven attacks generate signals such as:

• unusual login locations
• abnormal token usage
• unexpected role assumptions
• privilege escalation activity

Without identity-focused monitoring, these signals often go unnoticed.

Detection Opportunities Across the Attack Chain

Legitimate credentials do not make attackers invisible. Identity-driven attacks produce signals, but only teams actively looking for them will see them.

Endpoint Signals

During the initial compromise stage, unusual activity may appear on developer machines: Suspicious dependency installation scripts, filesystem searches targeting credential files, and developer tools accessing sensitive configuration directories. Any of these signals on a developer machine should be treated as a potential supply chain indicator.

Identity Signals

Once stolen credentials are put to use, abnormal authentication patterns often surface. Security teams should monitor for:
1) GitHub tokens used from unfamiliar locations
2) Service accounts performing unexpected actions
3) Abnormal CI/CD authentication activity
4) unusual OIDC role assumptions

These identity signals are often the earliest indicator that credentials have been compromised.

Cloud Control Plane Signals

If attackers successfully authenticate to cloud environments, their actions appear in infrastructure logs.

High risk indicators include:

• IAM role creation events
• administrator policy attachments
• infrastructure deployments modifying IAM permissions
• abnormal security token service activity

The window between first authentication and full privilege escalation can be very short. Speed of detection here is everything.

How Unosecur Detects Identity-Driven Attacks

You cannot defend what you cannot see. Modern cloud attacks demand visibility into identity activity across every layer, cloud platforms, developer ecosystems, and SaaS environments alike. The Unosecur platform provides Identity Threat Detection and Response capabilities designed to detect attacks targeting identities, credentials, sessions, and privileges. Read more on how Unosecur deals with these attacks here.

Key detection capabilities include:

• Detection of stolen credential usageUnosecur analyzes authentication patterns to identify anomalies such as unusual login locations, abnormal token usage, and suspicious API activity.
• Monitoring non-human identitiesAutomation identities, including service accounts, API tokens, and CI/CD roles, are continuously monitored to detect abnormal behavior.
• Privilege escalation detectionThe platform identifies high-risk events such as IAM role creation, administrator policy attachments, and identity permission changes.

By correlating these signals, Unosecur can detect identity-driven attacks before they reach full administrative access.

The Real Lesson of the Nx Attack

The Nx supply chain attack was not ultimately about malicious npm packages. It was about identity.

A compromised dependency enabled credential theft. Stolen credentials enabled identity abuse. Identity abuse enabled cloud privilege escalation. The path from a developer workstation to full cloud administrative access was short. This is not a future threat. It is the present one. The security perimeter is no longer the network or the server. It is identity. Organizations that continuously monitor identity activity, enforce least privilege access, and secure automation identities will be far better positioned to stop modern supply chain attacks.

Because in today’s cloud environments, the most dangerous attacker is not the one rattling the door but the one who already has the key.

‍