From Fake Recruiters to Hijacked AI Agents: Inside the $2 Billion Cloud IAM Attack Chain

A LinkedIn message from a recruiter. A coding test that looks routine. A package install that seems like part of any normal hiring process. Within minutes, every cloud credential on the developer’s machine is exfiltrated — GitHub personal access tokens, AWS keys, Azure service principals and more — and the adversary is operating inside your cloud environment.

No phishing email. No obvious malware alert. No clear forensic trail. For cloud security leaders and engineering managers, this emerging attack chain turns developer workstations and cloud identity and access management (IAM) into a multi-billion-dollar attack surface.

Recent research and incident reports from CrowdStrike, CISA, JFrog, Sysdig, Google Cloud and others show that adversaries have industrialized this pattern. They are using recruitment fraud and non-email channels to deliver trojanized packages, pivoting through stolen identities to cloud IAM, and ultimately targeting AI infrastructure. One adversary unit tracked by CrowdStrike has already been associated with more than $2 billion in cryptocurrency operations.

This article unpacks how that attack chain works, why traditional controls are missing it, and what you should validate in the next 30 days.

The New Entry Point: Recruitment Lures and Trojanized Packages

Security controls in most enterprises are still oriented around email-borne phishing and commodity malware. The campaigns now hitting developers and cloud IAM have deliberately stepped around that perimeter.

CrowdStrike Intelligence has documented adversary groups crafting highly tailored, employment-themed lures for specific industries and roles, particularly in fintech and cryptocurrency. The flow looks like a legitimate hiring process: outreach via LinkedIn or WhatsApp, a live conversation, then a coding assessment that requires installing a Python or npm package.

The difference is what happens during the install. The package contains malicious code that scans the developer’s environment for credentials — GitHub personal access tokens, cloud API keys for AWS, GCP and Azure, and other secrets — then exfiltrates them to attacker-controlled infrastructure. CISA’s advisory on a widespread npm supply chain compromise in 2025 describes this behavior at scale: packages that automatically searched for credentials during installation and sent them to external domains.

Critically, the delivery mechanisms have shifted:

• Packages are not arriving through classic typosquatting alone; they are being hand-delivered via chats and messaging apps.
• WhatsApp and similar platforms are now documented as primary initial compromise vectors in npm ecosystem attacks.
• Corporate email security never sees these messages or attachments, so it never has a chance to intervene.

In a late-2024 case at a European fintech firm described by CrowdStrike, trojanized Python packages delivered via recruitment lures led directly to cloud IAM manipulation and cryptocurrency diversion to adversary wallets.

The pattern is clear: developers are becoming high-value entry points, with their workstations serving as bridges between personal communication channels and corporate cloud environments.

Why Dependency Scanning Alone Fails

Most mature engineering organizations now have dependency scanning in place. These tools analyze package manifests and code for known vulnerabilities, suspicious patterns and supply chain risks. In many of the documented campaigns, that first control might work — the malicious package could be flagged if it matches known signatures or indicators.

But the current wave of attacks is exploiting what happens next: runtime behavior during installation and execution.

CISA’s npm advisory highlights packages that:

• Executed credential harvesting logic only when installed.
• Scanned local files and environment variables for cloud keys and tokens.
• Silently exfiltrated those credentials as part of the install process.

Static analysis and dependency scanning typically focus on the artifact itself, not the live behavior of the install process on the developer’s machine. That leaves a gap between “this package looks suspicious” and “this process is currently accessing sensitive credential stores and reaching out to unknown domains.”

As Shane Barney, CISO at Keeper Security, observed in an analysis of a recent cloud attack chain, the striking element is not a novel exploit but “how little resistance the environment offered once the attacker obtained legitimate access.” In other words, once credentials are stolen, the rest of the system often behaves as if nothing is wrong.

For security and engineering leaders, this raises a concrete control requirement: dependency scanning needs to be paired with runtime behavioral monitoring on developer workstations that can detect credentials being accessed and exfiltrated during package installation and related processes.

From Stolen Keys to Cloud Admin in Minutes

Once adversaries have valid cloud credentials, they frequently no longer need exploits or malware. They simply log in.

Google Cloud’s Threat Horizons Report found that weak or missing credentials accounted for 47.1% of cloud security incidents in the first half of 2025, with misconfigurations contributing another 29.4%. Those ratios have remained stable across reporting periods, suggesting a chronic identity and configuration problem rather than a passing trend.

Recent research from Sysdig shows how fast attackers can capitalize on this. In a documented attack chain, compromised AWS credentials reached administrator-level privileges in eight minutes, moving across 19 IAM roles. Along the way, the intruder enumerated Amazon Bedrock AI models and disabled model invocation logging — all without deploying traditional malware.

The key ingredients in this pivot are:

• Over-privileged or misconfigured IAM roles that allow daisy-chaining of permissions.
• Lack of baselines for normal identity behavior, making rapid lateral movement invisible.
• Inadequate monitoring of role assumption patterns, especially in multi-account or multi-cloud setups.

Ram Varadarajan, CEO at Acalvio, has summarized the shift bluntly: breach speed is now measured in minutes, not days. Detecting and responding to these intrusions requires systems that can “reason and respond at the same speed as automated attackers.”

Identity threat detection and response (ITDR) has emerged to fill this gap by focusing on how identities behave inside cloud environments, not just whether they authenticate successfully. KuppingerCole’s 2025 Leadership Compass on ITDR notes that most identity breaches now originate from compromised non-human identities, yet ITDR deployment remains inconsistent across enterprises.

For cloud security leaders, the implication is clear: if you can’t see unusual role chaining, cross-account access and privilege escalation in near real time, your environment is likely exposed to the kind of eight-minute compromise Sysdig documented.

Why AI Gateways Don’t Close the Gap

As organizations build out AI platforms, many are deploying AI gateways to broker access to model endpoints and training pipelines. These systems are good at enforcing policy-based access control:

• Validating that tokens are present and not expired.
• Checking whether the calling identity has the right privileges for a particular endpoint.
• Applying rate limits and other guardrails defined by administrators.

What they largely do not do today is evaluate whether a given identity’s current behavior is consistent with its historical patterns.

Consider a developer who typically calls a code-completion model a couple of times a day. If the same identity suddenly starts enumerating every Bedrock model in the account and turns off logging first, an AI gateway will see only a valid token performing allowed operations. An ITDR system, by contrast, could recognize that as a behavioral anomaly in need of investigation.

CrowdStrike’s reporting on evolving adversary units underscores why this distinction matters. Intrusion operators are no longer simply stealing credentials; they are consciously targeting cloud IAM configurations — the same ones that underpin AI infrastructure access. These groups share tooling across units and deploy specialized malware for cloud environments, indicating that targeting IAM-anchored AI infrastructure is an established tactic, not an experiment.

Google Cloud’s office of the CISO has warned that boards now ask specifically about resilience to machine-speed attacks, and that securing both human and non-human identities is central to managing risks from non-deterministic AI systems. As long as AI gateways focus only on token validity and static entitlements, hijacked identities retain a straight path to sensitive models and data.

AI Agents as the New Blast Radius

The convergence of IAM abuse and AI is not hypothetical. It is already manifesting in the way autonomous agents and tool-using models are deployed.

OpenClaw, an open-source autonomous AI agent, provides a concrete case. The project reached around 180,000 GitHub stars in a week, fueled by enthusiasm for its ability to connect to email, messaging platforms, calendars and code execution environments through model context protocol (MCP) and direct integrations. Developers have been installing it on corporate machines without formal security review.

Cisco’s AI security research team has described OpenClaw as “groundbreaking” from a capability standpoint and “an absolute nightmare” from a security standpoint. The concern is straightforward: an agent with broad, legitimate access to operational systems becomes an extremely powerful pivot point when its controlling identity or prompt stream is compromised.

CrowdStrike CTO Elia Zaitsev has emphasized this in guidance to security teams, warning that a successful prompt injection against an AI agent is not just a data exposure risk. It can become “a potential foothold for automated lateral movement, where the compromised agent continues executing attacker objectives across infrastructure.”

In other words:

• The agent’s authorized access to APIs, databases and internal tools effectively becomes the attacker’s access.
• The attack chain no longer ends at the model endpoint; it extends to whatever the agent can touch.
• Because the agent’s actions are often expected to be autonomous and wide-reaching, abnormal behavior may be harder to distinguish without strong baselines.

There is no meaningful air gap between compute IAM and AI infrastructure IAM. When a developer’s cloud identity is hijacked at the start of the chain, the end state can include model weights, training data, inference endpoints and the full span of tools wired in through MCP or similar protocols.

Mapping the Three-Stage Attack Chain and Control Gaps

The emerging pattern can be broken down into three stages, each with a distinct control gap and concrete mitigations for security and engineering leaders to pursue.

1. Entry: Trojanized packages via non-email channels

• Technique: Adversaries use LinkedIn, WhatsApp and other personal channels to pose as recruiters and deliver malicious Python or npm packages, often wrapped in realistic hiring workflows.
• Gap: Email gateways never see the payload. Dependency scanners may flag known malicious packages but typically do not monitor for credential exfiltration during installation.
• Action: Implement runtime behavioral monitoring on developer workstations that can detect unusual access to credential stores and outbound connections during package installs and build steps. Treat developer endpoints as high-value assets, not generic desktops.

2. Pivot: Stolen credentials and invisible IAM lateral movement

• Technique: Attackers use harvested keys to assume roles, traverse accounts and escalate privileges, as seen in the European fintech case and the Sysdig-documented 19-role AWS traversal.
• Gap: Traditional perimeter and SIEM controls often lack visibility into fine-grained IAM behavior. Few organizations maintain robust behavioral baselines for identity usage across cloud environments.
• Action: Deploy or expand ITDR capabilities that model normal identity behavior, detect anomalies such as rapid role chaining or cross-environment pivots, and integrate with automated response workflows to contain compromised identities quickly.

3. Objective: AI infrastructure trusts authenticated but compromised identities

• Technique: Adversaries use valid tokens to reach AI models, disable logging where possible and, in agentic setups, direct tools and workflows toward attacker objectives.
• Gap: AI gateways verify authentication and authorization but generally do not evaluate behavior against historical norms or correlated IAM telemetry. Logging and monitoring can sometimes be disabled by the same identities being abused.
• Action: Introduce AI-specific access controls that tie model access to identity behavior profiles and enforce audit logging that cannot be disabled by application or user roles. Treat AI agents as sensitive service accounts and apply least privilege and continuous monitoring accordingly.

Jason Soroko, senior fellow at Sectigo, has argued that beneath the novelty of AI-enabled attacks lie familiar root causes: exposed valid credentials, often left in public storage like S3 buckets, and persistent gaps in security fundamentals. The sophistication of the adversary does not change the need for disciplined IAM hygiene and continuous monitoring.

30-Day Validation Plan for Cloud and AI Security Leaders

Given the speed and scale of these campaigns, CISOs and engineering leaders benefit from a focused, time-bound assessment. Over the next month, consider validating the following areas against your current stack.

1. Developer workstation controls

• Confirm whether runtime monitoring is in place on developer endpoints, specifically for package installation, build pipelines and local credential access.
• Review policies for installing unvetted packages received via personal channels (LinkedIn, WhatsApp, Telegram, etc.), and ensure developers understand the risk of recruitment-themed lures.
• Evaluate how secrets are stored on developer machines and whether access to them is logged and monitored.

2. Cloud IAM visibility and baselining

• Assess whether you have ITDR or equivalent tooling monitoring identity behavior across your cloud providers.
• Check if you can detect patterns analogous to the Sysdig case: rapid role traversal, sudden privilege escalation, new regions or services accessed by existing identities.
• Review configurations that allow identities to modify or disable logging and tighten them where possible.

3. AI gateway and agent security

• Inventory how identities (human and non-human) access your AI models and pipelines, and which of those have broad tool invocation capabilities.
• Determine whether your AI gateways or access brokers correlate requests with identity behavior baselines, or only validate tokens and entitlements.
• Review controls around autonomous agents like OpenClaw: where they are installed, what they can access, and how their actions are monitored.

Morgan Adamski of PwC has framed the challenge in operational terms: getting identity right — including AI agents — means controlling who can do what at machine speed. Alert fatigue and fragmented monitoring will not keep pace with multicloud sprawl and identity-centric attacks.

The perimeter is no longer where these battles are decided. For cloud IAM and AI infrastructure alike, identity — and its behavior — is the new front line.