Last reviewed:
How to turn GuardDuty finding types into ATT&CK coverage language while keeping managed findings, CloudTrail evidence and SIEM rules separate.
GuardDuty finding types are named AWS managed detections. They describe suspicious behaviour observed by GuardDuty across supported data sources such as CloudTrail management events, VPC flow logs, DNS logs, EKS audit logs, S3 data events and runtime telemetry where the feature is enabled.
That makes a finding type useful evidence, but it is not the same thing as a SIEM rule. The finding already passed through AWS detection logic before the SOC sees it. A coverage map should record it as managed-finding evidence, then decide whether the team also needs a SIEM detection over CloudTrail or service logs.
The finding name gives the first clue. UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration points at credential misuse. Recon:IAMUser/MaliciousIPCaller.Custom points at suspicious API activity from a known bad or customer-defined IP list. Impact:S3/MaliciousIPCaller names suspicious S3 API activity. The ATT&CK technique depends on the behaviour in the finding, not the AWS severity alone.
A flat export of GuardDuty finding types is hard to review. Group findings by behaviour first: credential misuse, reconnaissance, persistence or privilege change, defence evasion, exfiltration and impact. Then map each group to ATT&CK techniques with an evidence label.
IAM findings often support T1078.004 Valid Accounts: Cloud Accounts when they show an IAM principal, access key or role session being used in an unusual or suspicious way. Discovery findings support T1087.004 only when the finding details show identity enumeration such as IAM users, roles, groups, access keys or permissions.
S3 discovery should stay in the resource lane. Bucket enumeration fits T1580 Cloud Infrastructure Discovery, while object listing fits T1619 Cloud Storage Object Discovery. S3 findings may also support Collection, Exfiltration or Impact, but only when the finding details say which bucket, API and actor were involved.
Do not treat posture-adjacent findings as proof of active technique coverage. A finding about anomalous behaviour may be a strong alert for an analyst, but a coverage report still needs to say whether it gives direct detection evidence or correlation context.
The main mapping mistake is to colour the ATT&CK cell green and lose the evidence trail. GuardDuty, CloudTrail and SIEM rules can all support the same technique, but they give the analyst different proof. The page or ticket should name which class of evidence backs the mapping.
Managed-finding evidence means GuardDuty raised a finding type with enough behavioural detail to support the technique. Audit-log evidence means the team can query the underlying AWS API event, usually in CloudTrail. SIEM-detection evidence means the team has its own rule logic, tuning notes and parser validation. Correlation context means the finding matters only with another signal.
That distinction keeps GuardDuty in the right role. It is a managed detection service, not a replacement for CloudTrail retention, incident triage or SIEM tuning. The strongest coverage rows often have both: GuardDuty for managed detection and CloudTrail or SIEM logic for tenant-specific review.
def guardduty_evidence_kind(finding):
if finding.type.startswith(('UnauthorizedAccess:IAMUser', 'CredentialAccess:IAMUser')):
return 'managed-finding:T1078.004'
if finding.type.startswith('Recon:IAMUser') and finding.has_iam_identity_enumeration:
return 'managed-finding:T1087.004'
if finding.type.startswith('Discovery:S3') and finding.api_name in {'ListBuckets', 'HeadBucket'}:
return 'managed-finding:T1580'
if finding.type.startswith('Discovery:S3') and finding.api_name in {'ListObjects', 'ListObjectsV2'}:
return 'managed-finding:T1619'
if finding.type.startswith(('Stealth:', 'DefenseEvasion:')):
return 'managed-finding:defence-evasion'
if finding.type.startswith(('Exfiltration:S3', 'Impact:S3')):
return 'managed-finding:review-s3-behaviour'
return 'correlation-context'
A usable mapping stores more than the finding type string. GuardDuty findings include account, region, resource, service, detector, severity and event timestamps. Many finding families also carry API, principal, network or S3 bucket details under service and resource fields. Those details decide whether the technique mapping is honest.
For IAM findings, preserve the principal ARN, access key id where present, API name, source IP address and user agent if GuardDuty provides them. For S3 findings, preserve the bucket ARN, API name, object prefix when present and caller context. For EKS or runtime findings, record whether the source is the managed finding alone or a log class your SIEM also collects.
Review the mapped technique against that field set. A finding that says a stolen access key called ListBuckets can support T1078.004 for credential abuse and T1580 for bucket enumeration. A finding that says the same access key called ListObjects can support T1619. A finding that says the same access key disabled logging points at defence evasion. The same principal can appear in all of them, but the behaviour changed.
GuardDuty finding types change as AWS adds services and detector logic. Treat the map as a review artefact, not a one-off spreadsheet. Review it when AWS publishes new finding families, when the account enables a new GuardDuty protection plan, or when an incident shows that a finding was present but the ATT&CK coverage report did not show it.
A sensible review asks four questions: which findings have no technique mapping, which mappings are only correlation context, which findings require a data source the tenant has not enabled, and which SIEM rules duplicate GuardDuty without adding tenant-specific logic. Those answers turn coverage work into backlog items instead of colour-coded theatre.
DCV helps by storing GuardDuty mappings beside the ATT&CK technique and evidence class. The point is not to claim that GuardDuty replaces the SIEM. The point is to show which attacker behaviours AWS already flags, which ones need CloudTrail or S3 event coverage, and which ones need customer-authored detection logic.