Inside an AI-Assisted Cloud Attack: Familiar Techniques at Unfamiliar Speed

Key Observations

This case study shows that AI-enabled attackers do not necessarily need novel malware or zero-days. The real shift is speed, scale, and orchestration: familiar cloud attack techniques were executed faster and across more surfaces than defenders could comfortably contain.

• The intrusion progressed from initial access to broad cloud compromise within approximately 72 hours.
  
• The threat actor repeatedly leveraged newly acquired credentials to restart discovery, secrets harvesting, persistence, and impact activities.
  
• Multiple artifacts suggested AI-assisted tooling, scripting, and operational support.
  
• The attack relied on familiar cloud techniques rather than novel malware or zero-days.
  
• The primary challenge for defenders was the speed and scale of execution rather than the novelty of the techniques.
  
• AI accelerated the attack, but its impact was amplified by gaps in visibility, monitoring, identity controls, and incident preparedness.

Executive Summary

Sygnia investigated a cloud intrusion in which a threat actor gained unauthorized access to an AWS-based environment and expanded across applications, cloud, source-control, CI/CD, and runtime services. The incident involved no novel malware and no zero-day exploit. Instead, the actor chained familiar cloud and application attack techniques, exploiting control gaps in secrets management, identity governance, deployment workflows, and cloud permissions.

What made the incident notable was the apparent use of AI as a force multiplier. Attacker-created scripts and structured reporting artifacts, highly parallel activity, and the execution of a broad playbook of cloud techniques in a compressed time frame all pointed to AI-assisted or agentic workflows accelerating reconnaissance, tooling, command structuring, and environment-specific adaptation. The significance was not that AI introduced new attack techniques, as every observed action mapped to long-established adversary behaviors, but that it reduced the time and effort required to operationalize those techniques across a complex environment. The defining factor was the gap between the pace of AI-assisted activity and the organization’s ability to convert available signals into containment. The intrusion left traces across cloud, identity, and application layers, but fragmented visibility, monitoring gaps, and the absence of predefined response procedures delayed detection and correlation.

The lesson is direct: prepare for AI-enabled threats before an incident and assume known weaknesses will be exploited faster and at greater scale. Resilience depends on strong identity security, eliminating exposed secrets, least privileged access across cloud and CI/CD environments, secure development and deployment processes, and predefined containment and recovery procedures that can be executed immediately, all supported by end-to-end visibility. AI strengthens defenders too, accelerating triage, log analysis, exposure mapping, detection engineering, and remediation planning, but only when built on reliable telemetry, clear ownership, and mature operational readiness.

1. Incident Overview

Cloud intrusions driven by exposed secrets, weak identity controls, and overly permissive access are not new. What is changing is how quickly they can be executed. AI lowered the barrier to understanding complex environments, generating working scripts, adapting techniques to specific services, and moving from initial access to operational impact at an unusually fast speed.

This investigation began with unauthorized activity in a large AWS-based environment. At first, it followed a familiar pattern: access through a weakness in an internet-facing application, discovery of exposed credentials, and expansion into cloud infrastructure. What stood out as the investigation progressed was scale and pace. The threat actor was not exploiting a single misconfiguration; they were chaining weaknesses across application services, AWS resources, source-control repositories, CI/CD workflows, runtime components, and data stores, while rapidly executing credential discovery, secrets harvesting, cloud enumeration, deployment-pipeline abuse, runtime modification, database access, and operational disruption.

Sygnia reviewed forensic logs alongside attacker-created artifacts – scripts, deployment-related modifications, and structured reporting, which were consistent with large language model assistance. Highly parallel activity, repeated infrastructure and user-agent characteristics, and the ability to execute a broad cloud-attack playbook in a compressed window reinforced the assessment that AI-assisted or agentic workflows played a role. The significance was not a new attack technique, but the speed, confidence, and concurrency with which an otherwise conventional operation moved: parallel activity across multiple identities and workstreams that would typically demand deeper cloud and offensive expertise.

2. Attack Path

The threat actor’s objective was financially motivated: to gain control over the victim’s cloud infrastructure and use that control as leverage for extortion.

The attack was adapted to the realities of a cloud environment where there is often no direct equivalent to an encryptor as seen in traditional on-premises ransomware incidents. Instead of relying on encryption, the threat actor sought to establish sufficient control over the environment to create leverage. Once this level of access was achieved, they could threaten to disrupt, disable, or destroy critical services, turning the infrastructure itself into the source of leverage.

This objective also explains the actor’s persistent behavior throughout the incident. The actor repeatedly attempted to maintain access wherever possible, creating or abusing additional footholds as they moved through the environment. In this context, persistence was not merely a backup access method; it was part of the leverage strategy. The more durable and distributed their access became, the more credible their ability to disrupt, damage, or influence the recovery process.

After obtaining an access key to one of the AWS accounts through weaknesses in an internet-facing application, the threat actor focused on four primary workstreams. Each time a new access key was obtained, the threat actor validated it and attempted to repeat many of the same activities from the newly available identity and permission scope. This created a recurring pattern: new access led to renewed enumeration, additional secrets collection, persistence attempts, data access, and impact-oriented activity.

• Secrets theft – The threat actor systematically searched for secrets and credentials across multiple layers of the environment. This included environment variables from ECS containers and EC2 instances, CI/CD runner environments for both GitHub and Bitbucket, plaintext secrets stored in S3 buckets, API keys from application databases, secrets stored in AWS Secrets Manager, and parameters stored in AWS Systems Manager Parameter Store.
  
• Backdoors and persistence – The threat actor created or attempted to create multiple mechanisms to maintain access to the AWS accounts and associated workloads. These included creating additional access keys and IAM users, establishing reverse shells on EC2 instances and ECS containers, modifying deployment files, and creating application users with elevated permissions.
  
• Data exfiltration – The threat actor also targeted the data layer. RDS databases were queried for user data, transaction information, and other potentially sensitive records. This activity showed that the actor was not only interested in infrastructure control, but also in identifying and extracting valuable business or sensitive data.
  
• Impact and pressure – To increase pressure on the client, the threat actor performed mostly reversible impact actions as a demonstration of capability. These included denying access to S3 buckets, limiting ECS services or containers to a maximum capacity of zero, creating ACL rules to block network access, and purging SQS queues. While many of these actions were reversible, they served as a clear showcase of force: the actor was demonstrating that they had the ability to disrupt critical cloud services and could escalate to more destructive actions if needed.

On-Demand Webinar

Inside a 72-Hour
AI-Assisted Cloud Attack

Watch the Replay

3. Where AI Changed the Equation

Each of the behaviors below translated into the same operational outcome: speed. The threat actor was able to move faster, cover more ground, maintain more context, and adapt to more surfaces than we typically observe in traditional intrusion activity.

• From attack path to attack waves – In many incidents, including advanced threat actor investigations, the attack path is relatively linear. The threat actor performs one set of actions to reach the next stage, and the investigation can often draw a clear line between phases: initial access, discovery, privilege escalation, lateral movement, data access, and impact.
  
  In this case, the activity did not progress as a clean sequence. It advanced in waves. Each newly obtained access key created another expansion point, triggering renewed enumeration, secrets collection, persistence attempts, data access, and impact-oriented activity. Some tasks repeated across identities and accounts, while others branched into new surfaces. The result was not a single attack path, but a series of overlapping attack waves spreading across the environment.
  
  
• Checklist execution – The threat actor did not stop after one or two successful techniques in each workstream. Across the campaign, the actor appeared to execute many of the standard actions an experienced cloud attacker would consider, such as permission discovery, secrets harvesting, credential abuse, persistence creation, database access, application-layer manipulation, and impact preparation.
  
  What stood out was not that each technique was novel, but that so many were attempted quickly and repeatedly across newly discovered surfaces. This pattern is consistent with AI-assisted or orchestrated execution, where known attack options can be generated, prioritized, and attempted with reduced human bottlenecks.
  
  
• Parallel execution – The threat actor operated with notable speed and concurrency. In one observed second, four different access keys belonging to four separate accounts were used from the same source IP address and the same user-agent, as demonstrated in Figure 1. This level of simultaneous activity, combined with shared client fingerprinting, is difficult to reconcile with a single manual workflow and is more consistent with automated, centrally orchestrated, and potentially agent-driven execution.

• Operational memory as a force multiplier – The key-hopping timeline showed more than speed (see Figure 2). It also highlighted the actor’s ability to maintain operational context across many credentials and workstreams. Each access key represented a different identity, permission set, and activity history. Rapidly switching between them while preserving task continuity requires effective state management: knowing which key belongs to which stream, what it can access, where it was already used, and when to reuse or abandon it.
  
  This kind of operational memory reduces a major source of friction for attackers. In this case, it enabled credential-level task management at scale and likely contributed directly to the speed and parallelism of the campaign.

• Rapid customization and adaptation – The threat actor repeatedly converted newly obtained access into tailored action. For each new access key, the actor appeared to quickly determine the associated permissions, reachable resources, and most valuable next steps.
  
  This was visible in the data layer, where the actor executed several hundred unique SQL queries across dozens of databases, rapidly enumerating schemas and identifying relevant data. It was also visible in the application layer, where the actor mapped relationships between SQS queues, vulnerable workers, payload injection points, and deployment-related files used to manage clusters.
  
  The pattern suggests rapid environment-specific adaptation rather than blind execution of a generic playbook. While not definitive proof of autonomous AI-agent activity, it is consistent with AI-assisted or orchestrated operations that can process context and customize actions at speed.
  
  
• Generated tooling at the point of need – Actor-created code and scripts showed indicators consistent with AI-assisted generation. This likely reduced the time required to build task-specific tooling for newly discovered surfaces. Instead of relying only on prebuilt tools, the actor appeared able to produce or adapt code as the operation unfolded.
  
  This matters because tooling usually creates friction. An operator must understand the surface, write or modify code, test it, handle errors, and then integrate it into the broader operation. In this case, the ability to generate or adapt tooling quickly appears to have compressed that cycle, contributing to the overall speed of the campaign.
  
  
• Using legitimate framing to guide or mask activity – Notably, multiple attacker-created artifacts were framed as part of a “pentest” or a “red team”. This framing appeared in branch names, commit messages, and other artifacts, including references suggesting the activity was approved by a non-existent CEO. There are several possible explanations for this language. It may have been intended to mislead investigators, provide plausible cover for the activity, or blend into legitimate-looking development workflows. Another possibility is that the actor used this framing to influence AI-assisted tooling, presenting the activity as an authorized penetration test in order to reduce refusal, increase compliance, or steer generated output toward offensive testing tasks. While this cannot be proven from the artifact names alone, the repeated “pentest” framing is consistent with an attempt to shape either human interpretation, AI behavior, or both.

4. Mapping the Activity to MITRE ATT&CK

To structure the findings, Sygnia mapped the observed activity to the MITRE ATT&CK® framework. ATT&CK is not an AI framework, and that is the point: every technique in this incident is one defenders have tracked for years. What changed was how these techniques were operationalized. Figure 5 follows the visual structure of Anthropic’s LLM ATT&CK Navigator¹, which mapped the AI-assisted activity of 832 banned accounts onto the same framework. Anthropic’s research showed that AI-assisted offensive activity concentrates heavily around execution, discovery, credential access, collection, and defense evasion. The intrusion investigated by Sygnia aligns closely with those findings, demonstrating how AI can accelerate and operationalize many of the same techniques.

The overlay is most concentrated in Execution, Discovery, Credential Access, and Collection. As mentioned in the earlier paragraphs, rather than deploying malware, in this incident the threat actor abused cloud-native primitives: scripting (T1059), cloud administration commands (T1651), container and serverless execution (T1609, T1648), and CI/CD pipeline abuse (T1677). Harvested credentials (T1552, T1528) acted as connective tissue, and discovery (T1087, T1580, T1619) re-ran on every newly obtained key. Even Defense Evasion, the largest tactic in Anthropic’s dataset, appeared here in cloud-native rather than endpoint form: modifying cloud compute infrastructure (T1578), blending in via valid accounts (T1078), and the “authorized red team / pentest” framing in attacker artifacts (Figures 3 and 4), aimed at misleading investigators and/or reducing refusals from AI tooling.

One signal the framework cannot record proved to be the defining one. In a single observed second, four access keys from four different accounts were used from the same source (Figure 1), a pattern that is very hard to explain as manual activity and points to automated, AI-orchestrated execution. Every individual action in this intrusion maps to an ATT&CK ID, but the orchestration behavior that made it dangerous, parallel workstreams, repeated execution across credentials, and machine-speed chaining, has none. Figure 5 should therefore be read in two ways: as a map of familiar techniques, and as a record of how fast they were chained together.

5. Remediation Insights for AI-Enabled Attacks

The threat actors’ primary advantage was operational, not technical. They used AI to accelerate decision-making, automate reconnaissance, analyze exposed data, identify opportunities, and pursue multiple attack paths at once. The defensive challenge was therefore not only to detect and contain malicious activity, but to operate at a pace that could match or exceed the threat actor.

Adapt Incident Response for AI-Enabled Threats

Traditional incident response often relies on the assumption that attacker progression will generate enough observable signals for defenders to investigate and contain activity before access materially expands across the environment. The observed attack pattern challenged this assumption. Forensic traces showed rapid, repeated activity consistent with automated or AI-assisted workflows for credential harvesting, permission analysis, vulnerability discovery, and attack-path mapping, allowing the intrusion to progress across multiple stages in a compressed time frame.

Defenders should therefore shift from a strictly linear response model to a momentum-based response model. In AI-assisted incidents, the priority is not to wait for complete visibility before acting, but to reduce the attacker’s ability to continue converting access into impact. Investigation and containment should run in parallel, with early actions focused on limiting blast radius across the areas most likely to be chained together: identity, cloud control planes, source-control, CI/CD, runtime environments, and data access. The goal is to interrupt adversary momentum while preserving enough visibility to continue scoping the incident and validating eradication. This requires predefined decision points, clear authority to execute containment, and response playbooks that can be applied broadly and adjusted as the investigation matures.

Organizational Readiness Remains a Critical Success Factor

Although the attack leveraged AI to accelerate offensive operations, many remediation challenges originated from gaps in operational readiness, visibility, and security maturity rather than from the attack techniques themselves. This observation is consistent with findings from Sygnia’s CISO Survey 2026, which found that 73% of 600 surveyed senior IT security decision-makers believe their organizations would not be fully prepared to respond to a serious cyberattack if one occurred tomorrow.

The most significant obstacles to rapid response included:

• Limited familiarity with the environment and asset landscape including crown jewels and critical assets.
• Incomplete visibility into systems, identities, and dependencies.
• Lack of predefined containment playbooks.
• Partial deployment of security controls.
• Limited automation of response activities.

These challenges increased the time required to assess impact, implement containment measures, and execute eradication activities.

Prioritize Broad Containment Over Precision

The attack highlighted the importance of limiting an adversary’s ability to communicate, authenticate, and move throughout the environment. Network restrictions should therefore be among the first containment actions implemented.

Recommended containment measures include:

• Restrict cloud management access through IP allowlisting and permit access only from trusted corporate locations.
• Disable remote access VPN connectivity until containment activities are completed.
• Restrict outbound internet connectivity for workloads, servers, and cloud resources to approved destinations only.
• Apply firewall policies and network access control lists (ACLs) to block communication with known malicious infrastructure and restrict access to unintentionally exposed assets.
• Enforce IP restrictions on source code repositories and development platforms.
• Ensure that all application traffic is routed through web application firewalls (WAFs).
• Implement network segmentation and isolation controls to limit lateral movement opportunities.

These controls reduce the attack surface and limit the ability of the AI-enhanced adversary to maintain command-and-control (C2) communications, pivot across environments, and establish additional persistence mechanisms.

Assume Credential Exposure and Rotate Secrets Aggressively

Credential theft and secrets harvesting were among the most impactful capabilities enabled by AI during the attack. Once credentials were obtained, the adversary was able to rapidly identify accessible resources, discover privilege escalation opportunities, and obtain additional secrets.

Organizations should therefore assume that exposed credentials will be leveraged immediately and at scale.
Recommended actions include:

• Execute a broad password reset campaign for affected and potentially exposed accounts.
• Rotate all credentials, secrets, tokens, and cryptographic keys that may have been exposed or accessed by the threat actor. This includes, but is not limited to, cloud access keys, API keys, personal access tokens (PATs), SSH keys, service account credentials, application secrets, database credentials, CI/CD credentials, OAuth tokens, certificates, encryption keys, secrets stored in vaults and secrets-management platforms, and any other authentication or authorization mechanisms used across the environment.
• Prioritize credentials that provide external access or privileged access.
• Scan source code and infrastructure-as-code (IaC) repositories for embedded credentials.
• Restrict access to development repositories during containment activities.
• Implement automated secrets rotation wherever technically feasible.

The objective is not only to invalidate known compromised credentials, but also to reduce the likelihood that undiscovered credentials remain available for future exploitation.

Protect Identities as the Primary Security Boundary

Cloud and development environments increasingly rely on identities rather than network boundaries as the primary control mechanism. During the incident, the adversary leveraged AI-assisted capabilities to rapidly analyze identity relationships, privilege assignments, and trust relationships, enabling the identification of multiple paths for privilege escalation and access expansion across the environment. Protecting identities therefore became a critical containment and eradication objective.

To reduce identity exposure and limit the attacker’s ability to leverage AI-driven privilege discovery and expansion techniques, key response actions should include:

• Disable compromised identities immediately.
• Revoke active sessions and authentication tokens.
• Enforce multi-factor authentication (MFA) across administrative and externally accessible systems.
• Restrict privileged administration to dedicated administrative identities and hardened management workstations.
• Monitor privileged role assignments and administrative activity for unauthorized changes.

Secure the Software Development Ecosystem

The attack demonstrated that development environments represent highly attractive targets due to their concentration of credentials, deployment permissions, infrastructure definitions, and automation capabilities.

Immediate response actions should include:

• Suspend production deployments during active containment.
• Freeze pipeline modifications until integrity can be validated.
• Restrict repository access to essential personnel only.
• Review repositories for unauthorized modifications and malicious code changes.
• Validate software artifacts and deployment packages prior to release.
• Remove unauthorized code, scripts, and infrastructure modifications.
• Implement branch protection policies and mandatory code review requirements.
• Integrate SAST/SCA security controls into development pipelines.
• Restrict direct modification of production environments outside approved deployment workflows.

Enhance Visibility to Support Eradication

AI enabled the adversary to establish persistence and C2 connectivity across a large number of systems within a short period of time. As a result, eradication became significantly more challenging than in traditional attacks, requiring enhanced visibility across cloud environments, development platforms, identity systems, endpoints, and network infrastructure to support eradication efforts.

However, defenders should recognize that even extensive traditional monitoring may not identify all malicious modifications introduced during the attack. By accelerating reconnaissance, adaptation, and persistence deployment, AI-assisted adversaries can distribute malicious changes across a broad range of assets and technologies in a timeframe that exceeds the ability of human analysts to manually investigate and correlate activity. In this case, persistence mechanisms were embedded within multiple IaC templates, backdoored deployment scripts, container images, webhook redirections, reverse shells, and cloud storage repositories, where they could remain dormant for extended periods before being activated.

Organizations should therefore complement comprehensive telemetry collection with AI-assisted analytics capable of processing large volumes of security data, identifying anomalous patterns, correlating activity across disparate platforms, and highlighting persistence mechanisms that might otherwise remain undiscovered. As attackers increasingly use AI to expand their coverage and operate across multiple environments simultaneously, defenders must leverage AI to achieve comparable speed and scale in visibility, investigation, and eradication efforts.

Apply Defense-in-Depth to Counter AI-Driven Attack Waves

The attack progressed in multiple waves. Each wave leveraged newly discovered credentials, systems, and attack paths to expand access further into the environment.

This behavior demonstrates why defense-in-depth remains critical against AI-assisted adversaries. No single preventive control can be expected to block every attack path identified by an AI-enabled threat actor. A single missed detection or control failure may provide sufficient opportunity for the adversary to regain momentum and continue the attack.

Organizations should therefore implement layered security controls, increasing the likelihood that attacker activity will be detected and disrupted before it can propagate across the environment.

Automation as a Defensive Requirement

The speed and scale of the attacks made automation of remediation activities a necessity rather than an optimization. Manual response activities often cannot keep pace with machine-assisted adversaries. Organizations should therefore automate repetitive containment, detection, and response actions wherever possible.

High-value automation opportunities include:

• Network restriction deployment.
• Credential and secret rotation.
• Session revocation.
• Endpoint isolation.
• Cloud workload quarantine.
• Detection and alert enrichment.
• Response playbook execution.
• Validation of infrastructure configurations.

Automation is particularly valuable during the early stages of an attack, where reducing response time directly limits the AI-enabled adversary’s ability to expand access.

Leverage Infrastructure Rebuilds for Broadly Compromised Environments

In highly compromised development, staging, and testing environments, rebuilding infrastructure may be more effective than attempting complete eradication. IaC capabilities provide a mechanism to rapidly recover environments while reducing uncertainty regarding hidden persistence.

When business requirements allow, organizations should:

• Remove compromised non-production environments.
• Recreate environments from trusted IaC templates.
• Validate configurations before exposure.
• Apply hardening measures before workloads are reintroduced.
• Rebuild trust relationships and credentials following deployment.

This approach reduces the risk of residual persistence while accelerating recovery.

6. Conclusions

The attack demonstrated that artificial intelligence is transforming cyber operations not by introducing fundamentally new attack techniques, but by dramatically increasing the speed, scale, and effectiveness with which existing techniques can be executed. Throughout the incident, the observed activity relied primarily on well-known methods, including credential harvesting, permission analysis, exploitation of security misconfigurations, and abuse of development and cloud environments. The distinguishing factor was the actor’s ability to identify opportunities, process information, and execute actions across multiple parts of the environment at a pace that significantly compressed the traditional response window.

The incident also demonstrated that success against AI-enabled threats depends primarily on preparation rather than reactive deployment of defensive tools during an attack. Organizations that are well prepared can significantly reduce the effectiveness of an adversary’s speed and automation advantages. Effective preparation includes maintaining comprehensive visibility across assets and identities, strengthening identity security controls, securing cloud and development environments, implementing layered defensive controls, and automating critical detection and response processes. Sygnia supports these preparation efforts through proactive services such as security assessments, penetration testing, cloud and identity reviews, and tabletop exercises designed to improve organizational readiness before an incident occurs.

Equally important is the establishment of predefined containment procedures that can be executed immediately when malicious activity is identified. In an environment where attackers can rapidly discover credentials, identify additional attack paths, and expand access across interconnected systems, delays in containment can have a disproportionate impact on the outcome of an incident. Organizations must therefore focus on reducing response friction and enabling rapid execution of containment actions at scale.

This is where incident response experience becomes critical. Sygnia’s experience responding to a wide range of adversaries provides a deep understanding of attacker behavior, prioritization, and operational decision-making. During AI-assisted incidents, this perspective is especially important: response teams must quickly distinguish between activity that is merely noisy and activity that materially changes risk. Effective coordination, rapid prioritization, and decisive containment become essential to reducing attacker dwell time and limiting impact.

A notable observation from the incident is the growing asymmetry between offensive and defensive adoption of AI. Offensive actors can use AI not only to enhance individual tasks, but also to coordinate activity across multiple stages of the attack lifecycle. Reconnaissance, credential analysis, attack-path discovery, vulnerability identification, persistence attempts, and access expansion can be supported as part of a continuous and adaptive workflow. In contrast, many defensive teams still rely on isolated AI-enhanced capabilities embedded within individual security tools. While these tools may improve detection or analysis within a specific domain, defensive operations often remain fragmented across teams, technologies, and workflows, with critical response actions still dependent on manual coordination. As a result, attackers may be able to move through an environment faster than defenders can investigate, align stakeholders, approve actions, and execute containment.

As AI capabilities mature, the advantage in cyber defense will belong to organizations that transform security operations from isolated actions into an integrated, adaptive, coordinated capability. The challenge is no longer only detecting malicious activity. It is responding fast enough to contain an adversary that can use AI to accelerate decisions, automate repetition, and operate across complex environments at scale.

1. Anthropic, “Mapping AI-enabled cyber threats: Insights from the LLM ATT&CK Navigator,” June 3, 2026. ↩︎