Multi-Cloud Security Assessment

Identity and Access Management misconfigurations are the single most reliable initial foothold in cloud environments. We enumerate every role, policy, and trust relationship to identify escalation chains — from low-privilege service accounts to cloud administrator — using Pacu (AWS), AADInternals (Azure), and custom GCP tooling.

Public S3 buckets, Azure Blob containers with anonymous access, and GCS buckets with allUsers permissions remain among the most common critical findings we report. We enumerate every storage resource in scope, test access controls, cross-account policies, and object-level permissions, and verify whether sensitive data — credentials, backups, PII — is accessible without authentication.

Cloud instance metadata services expose temporary credentials, user data scripts, and configuration details to any process running on the host. IMDSv1 on EC2, Azure IMDS, and GCE metadata endpoints are all in scope. We test for SSRF-to-IMDS chains from web applications, container escapes that reach the host metadata service, and direct metadata abuse from compromised instances.

Organisations operating across multiple cloud providers often create implicit trust relationships between accounts and tenants — federation configurations, cross-cloud service integrations, shared identity providers. We map these relationships and test whether a compromise in one cloud environment can be leveraged to move laterally into another, or back into on-premises infrastructure through hybrid connectivity.

We enumerate cluster roles and role bindings to identify over-permissioned service accounts, wildcard verb grants, and escalation paths through impersonation, token creation, and secret access. ClusterRoleBinding misconfigurations that grant cluster-admin to non-administrative principals are consistently among our highest-severity findings.

Privileged containers, hostPath volume mounts, hostPID and hostNetwork settings, and misconfigured security contexts can all enable container breakout to the underlying node. We test each attack path applicable to your configuration — including abuse of container runtime sockets, kernel capabilities, and cgroup escapes — and validate whether node-level access provides a path to cloud credentials or adjacent workloads.

Kubernetes API servers should never be reachable from the internet without strong authentication. We test for unauthenticated access, certificate-based authentication weaknesses, bearer token exposure in CI/CD pipelines, and API server access from within the cluster network — including from compromised pods that should not have API access at all.

Pod Security Admission, OPA Gatekeeper, Kyverno, and similar admission controllers are only as effective as their policy definitions. We test whether existing policies can be bypassed through namespace labels, policy exceptions, or controller-specific escape techniques, and whether the admission controller itself is reachable and modifiable by workloads running in the cluster.

Kubernetes Secrets are base64-encoded, not encrypted, by default. We assess whether etcd encryption at rest is enabled, test access to Secrets objects through RBAC, and identify environment variable injection patterns in workload specifications that expose sensitive values to any process in the container. We also test integration with external secrets managers — AWS Secrets Manager, Azure Key Vault, GCP Secret Manager — for misconfigured access policies.

Managed Kubernetes services introduce cloud-provider-specific attack surfaces. EKS node IAM roles, AKS managed identity configurations, GKE Workload Identity bindings, and ECS task execution role permissions each present distinct escalation opportunities. We test the integration layer between your container platform and the underlying cloud IAM model — where the most impactful privilege escalation paths typically reside.

We review GitHub Actions workflow definitions for pull request trigger misconfigurations that allow untrusted code to access secrets, environment variable leakage through debug logging, and the use of third-party Actions without pinned commit SHAs. We also test for script injection vulnerabilities in workflow expressions and unauthorised use of workflow_dispatch triggers to exfiltrate repository secrets.

GitLab CI pipelines can expose protected variables to unprotected branches, allow merge request pipelines to access production secrets, and run jobs with Docker-in-Docker configurations that enable container escape. We assess your GitLab CI configuration for variable exposure, protected runner misconfiguration, and job token abuse that can pivot from one project's pipeline to another within the same GitLab instance.

Jenkins installations accumulate security debt over years of organic growth. We test for unauthenticated access to the Jenkins UI and script console, Groovy sandbox escapes that allow arbitrary code execution on the controller, agent-to-controller security model weaknesses, credential store access via the Jenkins API, and exposed build logs containing plaintext secrets. JNLP agent configurations and plugin vulnerabilities are also in scope.

Software supply chain attacks target the tools and dependencies your build pipeline trusts. We assess your dependency management practices — npm, pip, Maven, Go modules — for dependency confusion attack vectors, typosquatting exposure, and the use of packages with known compromised maintainer accounts. We also evaluate your container image supply chain: base image sources, image signing, and registry access controls that could allow an attacker to substitute a malicious image.

Hardcoded API keys, cloud credentials, and private certificates committed to source repositories remain a routine finding. We scan repository history — including deleted commits and branch history — and pipeline configuration files for exposed secrets, then trace each finding to its accessible blast radius: what cloud resources, third-party services, or internal systems does that credential reach?

Build artifacts — container images, packages, deployment bundles — must be verifiable from build to production. We test whether your artifact registry enforces signed image policies, whether unsigned or tampered images can be pushed and pulled by production systems, and whether registry access controls prevent lateral movement between development, staging, and production environments.

Lambda execution roles, Azure managed identities, and GCP service accounts attached to functions routinely accumulate permissions well beyond what the function requires. We enumerate each function's attached identity, map its effective permissions, and demonstrate whether those permissions enable privilege escalation — to S3 administration, Key Vault access, or cloud account-level control — from a function that an attacker can trigger through a public endpoint or injectable event source.

Database connection strings, API keys, and third-party service credentials are frequently passed to serverless functions as environment variables rather than retrieved from a secrets manager at runtime. We assess how function configuration is stored and accessed, test whether function environment variables are retrievable through logging services, error responses, or misconfigured function URLs, and verify that secrets at rest in function configuration are appropriately protected.

Serverless functions process events from S3 notifications, SQS queues, API Gateway requests, Pub/Sub messages, and dozens of other sources. When function code passes event data to downstream processes without validation — shell commands, database queries, template engines — event injection becomes viable. We test each trigger type in scope for injection vulnerabilities and assess whether attacker-controlled event sources can reach your function endpoints.

Lambda function URLs and Azure Function HTTP triggers exposed without authentication, API keys, or proper CORS configuration are directly exploitable. We test for unauthenticated function invocation, SSRF through function-proxied HTTP requests, and resource-based policy misconfigurations that allow cross-account or public invocation of functions intended for internal use only.

Azure AD Connect synchronises on-premises Active Directory identities to Entra ID. Misconfigured synchronisation accounts, pass-through authentication agents with excessive local privileges, and ADFS federation trust relationships can provide a pivot from cloud to on-premises — or allow on-premises compromise to propagate directly into your Azure tenant. We test hybrid identity configurations for both directions of attack.

Site-to-site VPNs, AWS Direct Connect, Azure ExpressRoute, and GCP Cloud Interconnect are frequently configured with overly broad routing tables that allow cloud resources to reach on-premises segments they have no business accessing. We map reachable network paths through your hybrid connectivity fabric and test whether cloud-resident workloads can reach on-premises services — and vice versa — beyond the intended scope.

Organisations running Active Directory domain controllers on cloud-hosted virtual machines inherit on-premises AD attack paths in their cloud environment. DCSync attacks, Kerberoasting, NTLM relay through cloud-hosted Windows workloads, and SMB lateral movement between cloud VMs and on-premises systems are all testable from a cloud-side initial foothold. We validate whether your cloud-to-AD segmentation is effective in practice, not just in theory.

SAML federation between on-premises identity providers and cloud service providers introduces trust that, when abused, can allow an attacker with access to the on-premises signing certificate to forge authentication tokens for any federated cloud identity — the Golden SAML attack. We test SAML federation configurations across AWS SSO, Azure ADFS integrations, and GCP Workforce Identity Federation for token forgery exposure and signing certificate protection.