AWS has around 300 services, but most security research focuses on the same handful: S3, EC2, Lambda. The uncommon services, the ones nobody is watching, are where attackers find new paths to data. Rodrigo Montoro, Head of Threat Detection Research at Clavis Security, has over 22 years of experience in IT security and holds two patents in the detection field. In this episode, he shares his approach to proactive blue team research, explains why IAM conditional policies are the cheapest security win available, and breaks down the IMDSv1 vulnerability that still affects most AWS environments.
You can read the complete transcript of the episode here >
What is proactive blue team research and how does it differ from red teaming?
Traditional blue teams are reactive: attackers discover something, defenders create detections. Rodrigo flips this by making the blue team proactive, researching attack paths before adversaries find them.
His approach focuses on uncommon AWS services:
- Why uncommon services? With 300+ AWS services, CSPMs cover roughly 100. The remaining 200 have minimal security research, minimal documentation, and minimal monitoring. Attackers will eventually find paths through them.
- How he prioritizes: Map which services customers actually use (via CloudTrail event sources), then research services with PassRole actions (which indicate permission-related risks).
- The difference from red teaming: Red teaming tests known scenarios to validate defenses. Proactive blue team research discovers new attack paths to create detections before anyone exploits them.
The key insight: regardless of how an attacker enters, the actions they execute are logged the same way in CloudTrail. By understanding which actions are dangerous across uncommon services, you can build detections that catch novel attacks without knowing the specific entry vector.
How should organizations think about security during cloud architecture design?
Rodrigo recommends a three-part framework:
- Threat modeling first: Before using any new service, understand the attack paths. Where is your data? Where could an attacker come from? What is the path between point A and point B? This exercise reveals where to place prevention, guardrails, and detection.
- IAM conditional restrictions: For any permission with “write” or “permissions management” access level, add conditions. The simplest and most effective condition is IP-based restrictions (source VPC, VPN IPs, or specific CIDR ranges). If keys leak, attackers cannot use them from outside your trusted networks.
- Quick wins with CSPM: Run an open source CSPM tool to find misconfigurations. Many are trivial to fix and provide immediate security improvement.
The sports analogy captures it well: “Defense wins championships, offense wins games.” An attacker might get initial access, but if they cannot reach your data because of proper restrictions, you lose the game but win the championship.
Why are IAM conditional policies the most underused security control?
AWS has approximately 14,000 actions across 300 services, split into five access levels: read, list, tagging, permissions management, and write. Rodrigo argues that every action with permissions management or write access should have a conditional clause:
- IP-based conditions: Restrict high-impact actions to your VPN or bastion host IPs. If access keys leak, they are useless from outside your network.
- MFA conditions: Most organizations enable MFA for console login but forget that API keys bypass MFA entirely. You must add MFA conditions to IAM policies and use STS to get temporary credentials after MFA verification.
- The MFA gap: Users create access keys for Terraform or CLI usage. These keys have no MFA requirement by default. This is a massive blind spot that most organizations do not address.
The combination of IP restrictions and MFA conditions on high-impact permissions is what Rodrigo calls a “cheap, easy way to create protection.” Even if credentials are compromised, the attacker cannot use them without meeting the conditional requirements. This connects directly to AWS IAM best practices and the broader identity access management discipline.
What is the IMDSv1 vulnerability and how do you fix it?
The Instance Metadata Service (IMDS) at IP 169.254.169.254 exposes instance information including IAM role credentials. IMDSv1 allows simple HTTP GET requests to retrieve this data, making it exploitable via Server-Side Request Forgery (SSRF) attacks, as demonstrated in the Capital One breach.
IMDSv2 requires a token obtained through a PUT request with additional headers, making SSRF exploitation significantly harder. The problem: IMDSv2 is disabled by default.
How to fix it:
- Prevention (best approach): Create a Service Control Policy at the organization level that denies launching EC2 instances without IMDSv2 required. This prevents anyone from creating vulnerable instances.
- Detection: Monitor CloudTrail RunInstances events for the metadata version field. Alert when instances are created with IMDSv1 (token required = “optional”).
- Remediation: Use your CSPM to identify existing instances with IMDSv1 enabled and migrate them to IMDSv2.
Rodrigo sees no reason to use IMDSv1 over IMDSv2. The SCP approach is the strongest because it does not depend on individual teams remembering to configure it correctly. This is part of the broader pattern of AWS defaults that need changing to achieve actual security.
What is “The Full Truth of the AWS Shared Responsibility Model”?
Rodrigo’s research highlights a critical gap: AWS has released many security improvements over the years, but most are not enabled by default. This creates a false sense of security:
- S3 Block Public Access: Existed for years but was disabled by default. Only recently moving to enabled by default for new buckets.
- CloudTrail logging: Many services have logging disabled by default. You must explicitly enable it.
- IMDSv2: Available since 2019 but still optional by default.
- Security Hub, GuardDuty: Available but not automatically enabled.
The shared responsibility model is accurate: AWS secures the infrastructure, you secure your workloads. But the nuance Rodrigo emphasizes is that “secure by default” is largely a myth. Customers must actively understand what is not enabled and configure it themselves. Cloud can be more secure than on-premises because everything is API-based and controllable, but only if you understand and manage the defaults. The shared responsibility model requires active engagement, not passive trust.
How do you research and detect threats across 300 AWS services?
Rodrigo’s methodology for discovering new attack paths:
- Map service usage: Analyze CloudTrail logs to identify which services your organization actually uses. Focus detection efforts there first.
- Identify PassRole actions: Services with PassRole capabilities are inherently more dangerous because they involve permission delegation. Research from Rhino Security lists nearly 100 services with PassRole actions.
- Look for cross-service paths: Actions in one service can open network or permission paths to another. For example, GameLift has VPC peering actions that could potentially create cross-account network paths.
- Study the access levels: AWS categorizes every action by access level. Focus research on write and permissions management actions in uncommon services.
- Use CloudGoat for validation: Open source tools like CloudGoat help demonstrate attack paths to analysts and stakeholders who may not understand why a misconfiguration is dangerous.
The advice for practitioners: start an AWS account, set a budget alert, and click around. Read the documentation, then test practically. The best way to understand cloud security is hands-on experimentation with the services themselves.
