Connecting the Cloud-Dots: Constructing a Knowledge Layer from Autonomous Attack Simulation

Connecting the Cloud-Dots: Constructing a Knowledge Layer from Autonomous Attack Simulation

Speakers: Itay Gabbay, CTO & Co-founder, Brava Security

Conference: fwd:cloudsec Europe 2025

YouTube: https://www.youtube.com/watch?v=Yn9g4u9dbvE

Overview

Itay Gabbay, CTO and co-founder of Brava Security, introduced CloudDots, an open-source research system that uses AI-driven autonomous agents to simulate cloud attacks across AWS, Azure, and GCP, capture the resulting telemetry, and build a knowledge base mapping every cloud event to the specific attack techniques that trigger it. The tool addresses a fundamental problem in cloud detection engineering: without knowing exactly what an attack looks like in your logs, defenders are reduced to guesswork. CloudDots provides the empirical mapping — complete with MITRE ATT&CK alignment, timing characteristics, and signal fidelity scores — that turns cloud detection from art into engineering.

Background

▶ Watch: The problem: cloud detection engineering is guesswork due to vague documentat... (2:00)

Cloud detection engineering suffers from several compounding problems. Cloud provider documentation is fragmentary and vague, with rare services lacking any mapping to what their API calls mean from a security perspective. MITRE ATT&CK mapping for cloud is incomplete, and even documented events may not behave as expected. Defenders writing detections must guess how an attack will manifest in telemetry — reading incident reports, simulating attacks manually, and hoping the signals they build detections for are actually triggered.

The underlying question is: what if defenders could know beforehand exactly how every attack looks in every cloud telemetry source? CloudDots was built to answer this, originating from Brava Security's internal need for training data — specifically, identifying which of the tens of thousands of cloud log events actually matter for security, so their attack simulation models could focus on the ones with real signal.

Key Findings

▶ Watch: Full attack graph example — agent enumerates IAM roles and builds persistence... (6:00)

Tens of thousands of undocumented APIs. CloudDots discovered a large number of APIs across all three major cloud providers that are functional but absent from any official documentation. These APIs actually work and can be called, but defenders cannot find them in any reference material.

Documented APIs that generate no logs. Conversely, many APIs that are well-documented and expected to generate telemetry simply do not produce any log entries in CloudTrail, Azure Audit Log, or equivalent sources. This creates dangerous blind spots where attackers can operate without generating detectable signals.

Signal fidelity varies dramatically across events. Not all events are created equal for detection purposes:

• AWS AssumeRole fires almost every second in production accounts — writing a detection solely on AssumeRole without context (the full graph chain of related calls) produces unmanageable noise.
• GCP Service Account Key creation fires rarely and is associated with most attack simulations — every occurrence warrants investigation.
• Azure read operations from the console (viewing resource properties, enumerating roles/users, exploring Key Vaults) generate no audit log entries at all, creating a significant reconnaissance blind spot.

Timing characteristics differ by source. The latency between an action and its corresponding log entry varies significantly across different log sources and cloud providers, affecting real-time detection capabilities.

API throttling affects log generation. When the same operation is performed repeatedly in a short period, approximately 5% of the time the expected log entry is not generated — CloudTrail and equivalent services are not bulletproof in their coverage.

Technical Deep Dive

▶ Watch: Signal fidelity comparison — AssumeRole (noisy), GCP Service Account Key (hig... (10:00)

CloudDots operates through an agentic AI system that functions like "three-year-old kids pushing all the buttons" — systematically exploring every possible action in a cloud environment and recording what happens.

Agent architecture:

1. Objective intake. The agent receives a high-level goal — "establish persistence," "exfiltrate data," or an exploratory directive.
2. Capability indexing. The agent inventories its available tools — native cloud APIs, Stratus Red Team, Pacu, and other attack simulation frameworks.
3. Posture assessment. The agent evaluates the sandbox cloud account's permissions and security posture to determine viable attack paths.
4. Attack graph generation. The agent constructs a low-level API call graph representing multiple possible paths to achieve the objective. For example, to establish persistence via IAM, it enumerates which roles to modify, which policies to attach, and which role assumptions to chain.
5. Execution. The agent executes the attack path in a sandbox environment.
6. Telemetry capture. All telemetry across all sources (CloudTrail, Security Hub, VPC Flow Logs, Azure Activity Log, GCP Cloud Audit Logs, application logs) is captured and correlated with the executed attack steps.
7. Knowledge base update. Each event is mapped to the attack that triggered it, the MITRE ATT&CK technique it corresponds to, the simulation tool used, timing characteristics, and an example event payload.

Knowledge base structure. For each event in the knowledge base, CloudDots provides:

• Source — the log source where the event appears.
• MITRE mapping — the ATT&CK technique(s) associated with the event.
• Incident correlation — which simulated attacks successfully triggered this event.
• Simulation method — whether Stratus, Pacu, or direct API calls were used.
• Example event — a sample payload showing what the event looks like in production.
• Conditions — specific conditions under which the log is or is not generated.
• Timing — latency between action and log appearance.

Open-source DSL. CloudDots includes an open-source package that standardizes a Domain-Specific Language (DSL) for defining cloud attacks in a structured, declarative format — enabling reproducible attack definitions that can be shared across the community.

Threat intel correlation. The platform includes a feature where defenders can paste a raw log entry and receive analysis mapping it to known attack techniques and MITRE classifications.

Demo / Proof of Concept

▶ Watch: Live demo of CloudDots knowledge base — browsing AWS undocumented events and ... (12:00)

Gabbay demonstrated the CloudDots web interface showing the knowledge base across AWS, Azure, and GCP. He navigated the AWS service listing, showing undocumented events and their attack correlations. The threat intel correlation feature (paste a log, get analysis) was attempted but failed due to venue Wi-Fi limitations. The open-source GitHub package for the attack DSL was announced as available.

Defensive Implications

▶ Watch: The paradigm shift: attackers use AI, defenders still use PDFs — this must ch... (16:00)

Coverage validation. Use CloudDots mappings to verify that your detection rules actually correspond to the events triggered by the attacks you want to detect. If your detection fires on an event that an actual attack doesn't generate, you have a false sense of security.

Signal prioritization. Not all events deserve equal detection investment. High-fidelity events (like GCP Service Account Key creation) should trigger immediate investigation, while low-fidelity events (like AWS AssumeRole) require context-enrichment before they provide detection value.

Blind spot identification. The Azure console read operation gap — where role enumeration, resource viewing, and Key Vault exploration generate no audit logs — requires alternative detection strategies. Organizations relying solely on Azure Audit Log for reconnaissance detection are effectively blind to console-based enumeration.

Detection testing. Simulate specific attack scenarios using CloudDots' agent and validate whether your existing detections fire correctly, produce too much noise, or miss the event entirely.

Data source validation. Before building detections, verify that the log source you're relying on actually generates entries for the API calls you expect. CloudDots' mapping of documented-but-silent APIs is a critical input to this process.

Key Takeaways

• Tens of thousands of cloud APIs are undocumented but functional across AWS, Azure, and GCP — defenders cannot detect what they don't know exists.
• Many documented APIs generate no telemetry in CloudTrail or equivalent services, creating silent attack paths.
• Signal fidelity varies dramatically: GCP Service Account Key creation warrants immediate investigation, while AWS AssumeRole requires contextual enrichment to be useful.
• Azure console read operations (role enumeration, Key Vault exploration) produce no audit log entries — a significant reconnaissance blind spot.
• CloudDots provides an empirical, agent-driven mapping between attacks and their telemetry signatures, turning cloud detection from guesswork into engineering.
• The open-source attack DSL and knowledge base are available on the Brava Security GitHub for community contribution.

About the Speaker(s)

Itay Gabbay is the CTO and co-founder of Brava Security. He has approximately 10 years of cloud security experience, later transitioning to AI security (breaking AI models) before combining both domains — using AI agents to autonomously simulate cloud attacks and build detection knowledge bases. This was his first presentation at fwd:cloudsec.