Beyond GuardDuty: how three-level behavioral detection catches what rules miss
AWS GuardDuty is a good product. It detects known malicious IP addresses, known cryptocurrency mining domains, known port scanning patterns, and a catalogue of documented attack signatures. If an attacker uses infrastructure that has appeared in threat feeds, GuardDuty will catch it.
The problem is that sophisticated attackers do not use infrastructure that appears in threat feeds. They use compromised legitimate accounts, new cloud instances with clean IP addresses, and legitimate cloud services as their command-and-control channel. They operate slowly enough to avoid rate-based anomaly rules. They escalate privileges incrementally — one permission at a time — over days or weeks.
Rule-based detection catches what you already know to look for. The question is how to catch what you do not.
The three-level detection architecture
Onam's CDR (Cloud Detection and Response) engine reads the audit logs your clouds already produce and judges them at three levels. Each level catches a different class of attacker behaviour, and together they cover gaps a single level leaves open.
| Level | Approach | What it catches |
|---|---|---|
| L1 | Detection rules over single events | Actions suspicious on their own: disabling logging, creating access keys for another user, known-bad indicators |
| L2 | Correlation scenarios across several events | Ordered steps by one actor within a time window — the shape of an attack no single event shows |
| L3 | Statistical behaviour baselines | An identity or account departing from its own recent history, even when no rule names the action |
L1 — single-event rules. The same idea as a cloud's built-in threat service, applied across seven clouds' audit logs — CloudTrail, Azure Activity Log, Google Cloud Audit Logs, OCI Audit, Alibaba Cloud ActionTrail, IBM Cloud Activity Tracker and Kubernetes audit logs — with one alert schema. Detections are mapped to MITRE ATT&CK techniques, so each alert says which phase of an attack it represents.
L2 — correlation scenarios. L2 reads the L1 findings for each actor and resource and matches them against scenarios: an ordered list of steps that must all occur within a time window. A role lookup, then an AssumeRole, then a new role created by a deployment stack is three ordinary events to L1. To L2 it is one scenario. On top of the scenarios, a sequence detector looks for four attack shapes in every supported cloud's own vocabulary: data exfiltration, identity pivot, secrets staging and compute hijack.
L3 — behaviour baselines. L3 keeps daily statistics per identity and per account — for example session counts, superuser counts and admin role grants — and compares today's value with the mean and spread of the recent window. A value well above that range, or activity where there was none before, raises a finding. It is statistics, not a black box: each L3 finding carries the metric, today's value, the historical mean and how far it departed.
How L2 and L3 catch what L1 misses: incremental privilege escalation
The canonical example of what single-event rules cannot detect is incremental privilege escalation. Here is a pattern that shows up in published cloud intrusion write-ups.
Day 1. The attacker gains access to a developer's AWS credentials — through phishing, or an access key committed to a public repository. The developer's account can read from S3 buckets and invoke Lambda functions. The attacker reads the environment: lists resources, describes IAM policies, maps the account structure. All of these are legitimate API operations. No threat-intelligence indicator fires.
Day 3. The attacker notices that the developer's role has iam:ListRolePolicies and uses it to map roles with elevated permissions. They find a CI/CD role that can deploy CloudFormation stacks, and call sts:AssumeRole to take it on — a call the developer legitimately makes for manual deployments.
Day 7. Using the CI/CD role, the attacker deploys a stack that creates a new IAM role with administrator access. The deployment looks like ordinary CI/CD activity.
At no point did a single event look malicious on its own. What gives the attack away is the order and the volume: discovery calls, then a role assumption, then an administrator role created by the assumed identity. That ordered chain is what an L2 scenario or the identity-pivot sequence is written to match, and an admin role grant or a jump in an identity's session count is what an L3 baseline is written to flag.
What a baseline needs
A baseline is only as good as its history. L3 compares each metric against a recent window of daily values and only judges a metric once enough days of history exist, so a brand-new identity or account is not flagged simply for having no past. The thresholds are set per baseline in the rule files — two or three standard deviations above the mean — rather than hidden inside a model.
MITRE ATT&CK mapping in CDR context
CDR detections are mapped to MITRE ATT&CK techniques. That matters for two reasons.
First, it puts the alert in attack-chain context. A single unusual API call from a new IP is low severity in isolation. The same identity showing Valid Accounts (T1078.004) followed by Cloud Infrastructure Discovery (T1580) tells a story, and the ATT&CK tagging makes that visible in the timeline without manual analysis.
Second, it connects detections to posture. Every detection is joined to posture and identity context from the Onam graph, so an alert on a role assumption arrives next to what that role can reach — and a confirmed exfiltration sequence is written back to the resource's security posture, where attack-path analysis can see it.
Multi-cloud coverage
An attacker who compromises one cloud's identity may use it to reach another — for example a secret in one provider's secrets manager that holds another provider's credentials. Onam applies the same three levels and the same four sequence shapes to every supported cloud's audit logs, in that cloud's own service vocabulary, and federation between clouds is modelled in the identity graph that attack paths walk. Each detection still belongs to the cloud whose log produced it; the graph is where the clouds meet.
What to expect in the first weeks
The first weeks of CDR are about tuning out operational noise.
First scans. L1 rules start producing findings as soon as logs are read. The most common early findings are not active threats — they are configuration patterns that look like threats: instances making repeated metadata calls, functions calling APIs across regions, CI/CD pipelines creating IAM roles during provisioning.
Tuning. Review the L1 noise and suppress legitimate patterns with a reason and an expiry date — suppression should not be permanent for a cloud detection rule. Aim for an alert volume a person can review every day.
Once history exists. L3 baselines begin judging metrics once enough daily history has built up. The first L3 findings typically flag maintenance windows, pipelines that run at unusual hours and identities with legitimate but irregular usage. Each needs a decision: suppress with a reason and expiry, investigate, or escalate.
CDR is not a "set it and forget it" product. It needs sustained analyst attention to tune and investigate. The return is coverage of attacker behaviour that single-event rules cannot see.
To see the three levels against your own audit logs, book a demo.