← Back to blog

Cloud Post-Exploitation from a Compromised Host: 48 BOFs for AWS, Azure, GCP, and Kubernetes

· Krait Team · 7 min read

You’ve landed on a developer’s workstation. The host itself is interesting — local credentials, browser sessions, SSH keys — but the real target is the cloud infrastructure the developer accesses daily. AWS credentials in ~/.aws/credentials. Azure CLI tokens in the MSAL cache. Kubernetes configs in ~/.kube/config. Environment variables from a deployment script that ran last week.

Traditional red team methodology treats cloud exploitation as a separate phase. You exfiltrate the credentials, pivot to your own machine, install the cloud provider’s CLI, and work from there. This creates operational risk: the credentials are now on your infrastructure, the API calls originate from your IP address, and the behavioral pattern — a developer’s credentials suddenly used from an IP in a different country — triggers every cloud-native anomaly detection system worth its license fee.

Krait’s cloud BOFs execute cloud API calls directly from the compromised host, using the host’s existing credentials and network path. The API calls originate from an IP address that’s already in the cloud provider’s access logs for that identity. No credential exfiltration. No behavioral anomaly. The cloud activity looks like the developer doing their job.

The Credential Chain

Every cloud BOF starts with credential discovery. The credential chain follows the same priority order that the cloud provider’s own SDK uses:

Environment variables — AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY, AZURE_CLIENT_ID/AZURE_CLIENT_SECRET. The fastest path. Developers set these for local testing, CI/CD pipelines leave them in runner environments, and deployment scripts export them into the session.

IMDS — the Instance Metadata Service. Every EC2 instance, Azure VM, and GKE node exposes a metadata endpoint at a link-local address that returns temporary credentials for the instance’s IAM role. These credentials rotate automatically, require no configuration, and grant whatever permissions the instance role has. IMDS is the most common credential source on cloud-hosted infrastructure. Krait’s IMDS discovery handles both IMDSv1 (a single GET request) and IMDSv2 (PUT for a session token, then GET with the token as a header) — some environments enforce v2, which blocks the simpler v1 path.

Credential files — ~/.aws/credentials, ~/.aws/config with SSO sessions, Azure MSAL token caches, Kubernetes service account tokens mounted at well-known paths. These files persist on disk and often contain long-lived credentials.

Process memory — credentials loaded by running applications. A developer’s IDE, a running deployment script, or a background sync process may hold credentials that aren’t written to disk.

The BOFs try these sources in order and use the first valid credential they find. The operator doesn’t need to know where the credentials are — the BOF handles the discovery.

Signing Requests

Cloud APIs don’t accept raw HTTP requests with a credential header. AWS uses SigV4 — a signing algorithm that creates a canonical request string from the HTTP method, path, query parameters, headers, and payload hash, then signs it with a derived key. Every AWS API call requires this signature. Azure uses OAuth2 bearer tokens. Kubernetes uses service account JWTs or client certificates.

Krait’s AWS BOFs implement SigV4 signing entirely in the BOF code. The BOF builds the canonical request, derives the signing key from the secret access key and the request date, computes the HMAC-SHA256 signature, and constructs the Authorization header. No external library, no AWS SDK, no CLI installation required.

This is the single biggest reason cloud post-exploitation belongs in BOFs rather than in operator-side tooling. The signing happens on the compromised host using credentials that never leave the host. The API call originates from the host’s IP address with the host’s network path. CloudTrail logs show the same source IP they’ve always seen for that identity.

What the BOFs Cover

The 48 cloud BOFs span five providers and follow the post-exploitation workflow: discover credentials, enumerate what the identity can access, then exploit the most valuable resources.

AWS (15 BOFs). Credential discovery (IMDS, environment, credential files, SSO caches, process memory). Identity enumeration (sts:GetCallerIdentity — the cloud equivalent of whoami). IAM role enumeration and assumption for privilege escalation. Resource access: S3 bucket listing and object download, EC2 instance enumeration, Lambda function listing and invocation, Secrets Manager secret retrieval, SSM Parameter Store reading. Lateral movement: SSM command execution on other EC2 instances, EC2 Instance Connect for SSH key injection (push a temporary public key and SSH in within the 60-second validity window), and Lambda invocation for code execution in the cloud environment.

Azure ARM (8 BOFs). Managed identity token acquisition from the metadata endpoint. Credential discovery across environment variables, CLI token caches, and service principal configs. Resource enumeration: VM listing, Key Vault access, Storage account enumeration, blob download. VM Run Command execution for lateral movement to other Azure VMs.

Entra ID (14 BOFs). User, group, and role enumeration via the Graph API. Service principal discovery. Conditional Access policy enumeration — knowing which policies exist tells the operator what authentication bypasses are worth attempting. Application secret listing and creation (adding a secret to an existing app registration is a persistence mechanism). OAuth2 permission grant enumeration. Directory role assignment. PIM (Privileged Identity Management) eligible role discovery — identifying which roles can be activated on-demand.

GCP (8 BOFs). Metadata server token theft — the GCP equivalent of IMDS credential acquisition. Credential file scanning across Application Default Credentials, service account key JSON files, and gcloud CLI configs. Identity validation (gcp-whoami returns project, service account email, and token scopes). Resource access: GCE instance enumeration across all zones, GCS bucket listing and object download, Secret Manager secret retrieval. IAM enumeration: service account listing and project IAM policy inspection.

Kubernetes (3 BOFs). Pod, service, and namespace enumeration. Secret dumping from the current namespace. RBAC role analysis to identify over-permissioned service accounts.

Cross-Platform

Every cloud BOF ships as both a Windows COFF object and a Linux/macOS shared object. The HTTP client code, JSON parsing, credential discovery, and API signing are written in portable C. The same aws-s3-ls BOF runs on a compromised Windows workstation, a Linux jump box, and a macOS developer laptop.

This matters because cloud credentials don’t live exclusively on one platform. A developer might use a MacBook with AWS credentials in ~/.aws/credentials. A CI/CD runner might be a Linux container with an instance role. A Windows workstation might have Azure CLI tokens in the MSAL cache. The BOFs work wherever the credentials are.

What This Changes

The traditional approach to cloud post-exploitation after compromising a host is: find credentials, exfiltrate them, use them from your own infrastructure. This approach creates three detection opportunities:

  1. The credential exfiltration itself — a file download or clipboard copy
  2. The behavioral anomaly — a known identity suddenly used from a new IP/geography
  3. The tooling fingerprint — AWS CLI or Boto3 from an IP that’s never used them before

Krait’s approach eliminates all three. Credentials never leave the host. API calls come from the expected IP address. The HTTP requests are raw API calls with no CLI or SDK user-agent string. CloudTrail, Azure Activity Log, and Kubernetes audit logs show activity from a known source with a known identity.

This doesn’t make cloud post-exploitation invisible. A developer whose credentials suddenly start enumerating every IAM role in the account is anomalous regardless of where the calls come from. Cloud-native UEBA (User and Entity Behavior Analytics) detects behavioral deviations, not source-IP changes. But removing the source-IP anomaly eliminates the easiest detection signal and forces the defender into behavioral analysis — which requires baseline data, tuned thresholds, and operational maturity that many organizations don’t have.

The Tradeoff

BOF-based cloud exploitation trades capability depth for operational stealth. The AWS CLI and Azure CLI offer hundreds of commands with rich output formatting, pagination, and error handling. A BOF covers one specific operation with minimal output formatting. The BOFs handle the most common post-exploitation actions — credential discovery, enumeration, resource access, lateral movement — but they don’t replace a full cloud toolkit for deep exploitation.

The intended workflow is: use BOFs for initial discovery and pivoting from the compromised host, then decide whether deeper cloud exploitation justifies the operational risk of exfiltrating credentials to a dedicated cloud attack platform. For many engagements, the BOFs cover everything needed. For cloud-focused assessments, they provide the initial foothold and enumeration that informs the next move.