Living off the Cloud: How Attackers Use Your Own AWS APIs Against You

Cloud Security

An attacker with AWS credentials does not need to deploy malware. Your own APIs are the malware. Five living-off-the-cloud patterns we see most, and how to detect each.

By Arjun Raghavan, Security & Systems Lead, BIPI · February 26, 2026 · 8 min read

Living-off-the-land — using built-in tools to attack instead of dropping malware — is a decade-old endpoint concept. The cloud equivalent is younger but already dominant in our incident-response casework. An attacker with AWS credentials does not need to deploy anything. AWS itself provides every primitive needed to enumerate, escalate, exfiltrate, and persist.

Below are the five patterns we see most. None of them ring traditional EDR alarms because nothing untrusted is executed; the attacker calls AWS APIs that your platform team also calls every day. Detection has to live where the API calls are logged.

Pattern 1: SSM RunCommand for code execution

AWS Systems Manager has a feature called RunCommand. It lets you execute shell commands on any EC2 instance with the SSM agent installed. From an attacker's perspective with the right IAM permission, it is a remote code execution primitive across every server that runs the SSM agent — which is most of them on modern AMIs.

Detection: every SSM RunCommand invocation logs to CloudTrail. Alert on RunCommand calls outside business hours, calls from IPs not in the platform-team allowlist, or calls targeting tagged-as-production instances from non-platform principals.

Pattern 2: S3 sync for exfiltration

Once the attacker can read S3 objects, exfiltration is a single API call: s3:GetObject. Better yet, s3:ListObjects + s3:CopyObject to a bucket the attacker controls. The data never leaves AWS's network until the attacker downloads it from their own bucket.

Detection: GuardDuty has a 'Trojan:S3/MaliciousIP' family that catches the obvious. The harder cases are when the attacker uses an EC2 instance inside your VPC to exfiltrate; the API call comes from a 'good' IP. CloudTrail data-events on S3 are the only reliable detection. Alert on s3:GetObject volume anomalies per principal.

Pattern 3: Lambda for persistence

An attacker with lambda:CreateFunction creates a Lambda that runs once a day and re-grants the attacker's persistence (re-adds an IAM user, re-injects an inbound security-group rule). The original compromise can be cleaned up; the Lambda re-establishes everything within 24 hours.

Detection: alert on every new Lambda created with permissions to modify IAM, EC2 security groups, or KMS keys. New functions in this category should be exceptional. Log the diff in the function's role for the next quarter.

Pattern 4: KMS for sneaky data destruction

Encrypted data is only as recoverable as its encryption key. An attacker with kms:ScheduleKeyDeletion + kms:DisableKey can render entire S3 buckets, EBS volumes, or RDS snapshots permanently unreadable on a 7-day delay. The data is not deleted — the key is — but the practical effect is the same.

Detection: kms:ScheduleKeyDeletion is the alert. There is rarely a legitimate reason to schedule key deletion outside an explicit decommissioning runbook. Alert immediately, escalate to the on-call security engineer.

Pattern 5: ConsoleSignIn from unusual context

If the attacker stole an IAM user's credentials with console access, they sign into the AWS console. This is logged as ConsoleSignIn. From there everything they do is technically legitimate; the only anomaly is the context (geo, time, browser).

Detection: enrich every ConsoleSignIn event with geo, ISP, and browser fingerprint. Alert on first sign-in from a new geo or ISP for any human user. False-positive rate is high (people travel) but each event takes 30 seconds to triage and catches real account takeover.

Preventive controls

• Service Control Policies (SCPs) restricting destructive APIs (kms:ScheduleKeyDeletion, ec2:TerminateInstances) to specific roles.
• IAM Access Analyzer regularly reporting principals with permissions never used; revoke unused.
• Required MFA for all human users; conditional access requiring MFA for sensitive APIs.
• VPC endpoint policies restricting S3 access to known buckets only; data exfiltration via copy-to-attacker-bucket fails because the destination is denied.
• GuardDuty enabled in every region with all features on. The detection coverage from GuardDuty alone catches a meaningful fraction of LOTL behaviour.

Closing

Living-off-the-cloud is the dominant attack pattern after credential theft in modern AWS environments. The defence is not endpoint security; it is API observability. Treat CloudTrail like the audit log it is, write rules for the five patterns above, and invest in the SCPs that stop the worst destructive APIs from being callable in the first place. The attacker is using your own platform; your detection has to live in the same place.

Read more field notes, explore our services, or get in touch at info@bipi.in. Privacy Policy · Terms.