Connect AWS to CYBRET.
CYBRET reads your AWS control plane and joins it to the application code running on top. The result is a single attack graph where an IAM trust policy, a Lambda environment variable, and a vulnerableGET /api/orders/:id handler are the same path.
The control plane, indexed.
Connecting AWS gives CYBRET an agentless read of the resources, identities and trust relationships that decide who can reach what. We do not pull workload memory, container filesystems, or customer data from S3. We pull the metadata that determines reachability and the audit trail that proves who used it.
- IAM: users, roles, customer-managed and inline policies, trust relationships, permissions boundaries, SCPs at the organization level, access analyzer findings.
- Network reachability: VPCs, subnets, route tables, NACLs, security groups, Transit Gateways, VPC peering, public ALB/NLB exposure, PrivateLink endpoints.
- Storage and data: S3 buckets with bucket policies, ACLs, block-public-access state, KMS key grants, RDS instances and parameter groups, Secrets Manager secret metadata.
- Compute: EC2 instances and instance profiles, Lambda functions including environment variables and triggers, ECS task definitions, EKS clusters and the IRSA bindings for service accounts.
- Telemetry: CloudTrail management and data events for runtime correlation, Config item history, GuardDuty findings (optional).
What we find in the first week.
These are paths CYBRET routinely surfaces on first-time AWS connects. They are not theoretical. They are the kind of finding the cloud-posture and SAST tools each see half of, and which CYBRET resolves into a single ranked path with a proof.
1. CI runner becomes cloud admin via OIDC trust
GitHub Actions OIDC trust → over-permissive IAM role with s3:* and iam:PassRole → S3 exfil from the production data lake.
A workflow on a public repository can assume an IAM role whose trust policy keys on token.actions.githubusercontent.com with a loose sub condition. CYBRET joins the GitHub OIDC subject claims to the AWS trust policy and shows you that any pull request author who can edit the workflow file can reach this role. The role's effective policy resolves to s3:GetObject on the bucket containing customer exports. The path is closed by tightening the sub condition and scoping the role.
2. Lambda environment variable leaks DB credentials, ALB exposes it
Public ALB → Lambda integration with DATABASE_URL in env → verbose error handler → credential disclosure to unauthenticated user.
The Lambda function is fronted by an internet-facing ALB. Its handler catches a generic exception and returns the stack trace, which on a DB connection failure includes the value ofprocess.env.DATABASE_URL. CYBRET reads the function code, recognises the credential pattern in the env block, traces the exception path, and confirms reachability from the ALB listener rule. The proof is a 200 response containing a redacted credential shape; remediation is to move the secret to AWS Secrets Manager and fix the error handler.
3. EC2 instance profile escalates to admin via PassRole
SSRF on an internal service → IMDSv1 metadata token → instance profile with iam:PassRole + lambda:CreateFunction → admin role assumed by attacker-created Lambda.
The instance profile lets the EC2 host create a Lambda and pass any role whose trust policy permits Lambda. One of those roles hasAdministratorAccess. CYBRET joins the SSRF sink in the application code with the metadata-service version on the instance, enumerates theiam:PassRole targets, and produces the chain. Closing the path requires either removing PassRole, scoping it to a specific role, or migrating to IMDSv2.
Read-only, agentless, fifteen minutes.
The base AWS integration is a cross-account IAM role with a read-only managed policy and a trust policy keyed on the CYBRET tenant principal and an external ID. There is nothing to install on workloads.
- Open the CYBRET console and go to Integrations → AWS.
- Click Connect AWS. Copy the generated CloudFormation template or Terraform module. Both create the same IAM role.
- Deploy in your management account. For organization-wide coverage use the included
StackSettemplate; for a single account, deploy to that account only. - Paste the resulting role ARN back into the CYBRET console. Choose accounts and regions in scope.
- Wait five to fifteen minutes for the first graph build. CYBRET enumerates IAM, network, and storage in parallel; the first reachable paths land in Exposure Intelligence as they resolve.
- Optional: enable the CloudTrail data-event subscription for runtime correlation, and the EKS audit-log forwarder for Kubernetes paths.
Disconnecting is symmetrical: delete the stack, revoke the role, and CYBRET stops ingesting at the next poll cycle. We never store AWS access keys.
Read-only by default. No agents.
The base role uses AWS managed SecurityAudit plus a small extension that grants iam:GenerateServiceLastAccessedDetails,iam:SimulatePrincipalPolicy, and theaccess-analyzer:* read actions. Nothing in the default scope permits a write operation on any resource. There is no agent on EC2, ECS, EKS, or Lambda. The integration runs entirely against AWS APIs from the CYBRET tenant in your VPC.
For runtime detection, an optional collector ingests CloudTrail and VPC Flow Logs into the customer-tenancy CYBRET deployment. The collector is read-only and cannot mutate AWS resources. Customers who cannot accept any cross-account role can run CYBRET in a self-managed configuration that uses an in-account IAM user with the same managed policy.
Where AWS data shows up in the platform.
Exposure Intelligence is the product that benefits most. The reachable-path engine joins your AWS identity and network graph with the application code, secrets in version control, and the OIDC trusts that make CI a privileged identity. AWS connect on day one means cloud-half paths populate immediately; the application half lights up as repositories connect.
Validation uses AWS context to generate proof-of-exploit. When CYBRET claims a Lambda environment variable is reachable, Validation issues the request against a sandboxed clone of the function and shows the leaked value, redacted. It will not run a destructive payload against production AWS resources; validation runs against safe handles or non-prod copies that the integration enumerates.
Runtime Detection uses CloudTrail and (optionally) VPC Flow Logs to confirm whether the path is being exercised. A signed S3 URL handed out by your application becomes a runtime event when it's actually requested by a non-customer principal; Runtime Detection is the layer that catches that and triggers the response playbook. AWS data alone does not power runtime detection; the integration is a contributor to it.
Questions security engineers actually ask.
How does authentication work?
A cross-account IAM role with a sts:ExternalId condition. CYBRET assumes the role from the customer’s tenant; we never receive long-lived AWS keys. Role names and external IDs are unique per tenant.
Where does the AWS data live?
Inside the CYBRET deployment in your VPC. We do not move AWS metadata to a SaaS multi-tenant backend. Customers in the EU run an EU-resident control plane; customers in the US run a US one. Aurora, OpenSearch, and Neo4j are deployed inside the customer tenancy by default.
Is it really agentless?
Yes for the AWS integration. There is no agent on EC2, ECS, EKS, or Lambda for the base reachability product. Runtime Detection is also agentless on AWS; it relies on CloudTrail and Flow Log subscriptions.
How do you handle AWS API rate limits?
CYBRET uses adaptive concurrency per service and respects the standard AWS retry envelope. Large organizations with hundreds of accounts run a regionally distributed enumerator. We have customers with 600+ accounts; first build completes inside a 24-hour window.
Multi-account and AWS Organizations?
Supported via StackSet at the org root. CYBRET can also enumerate Service Control Policies and reflect them in the reachable-path engine, so a path blocked by an SCP is not raised as an exposure.
GovCloud and air-gapped?
GovCloud is supported with a separate tenant. Fully air-gapped customers run CYBRET on-prem and connect to AWS through their own NAT or PrivateLink path; the same IAM model applies.
Connect AWS →
Fifteen minutes to first graph. The first reachable path usually lands inside the first hour. Pilot accounts get a ranked top-25 within 72 hours.
Connect AWSSee Exposure Intelligence