Threat Hunting Exercise: Analyzing AWS CloudTrail Logging Disabled

Threat Hunting Exercise: Analyzing AWS CloudTrail Logging Disabled - GuardDuty Evasion Dataset

This hunt uses a simulated AWS CloudTrail dataset (aws_cloudtrail_disable_2022-06-25T041500.json) capturing T1562.008: Disable or Modify Cloud Logs, where an adversary who has obtained IAM credentials with sufficient privilege stops or modifies CloudTrail logging before conducting further malicious actions, attempting to evade GuardDuty and forensic reconstruction.

Step 1: Hypothesis Formation

Hypothesis: An IAM principal calls StopLogging, DeleteTrail, UpdateTrail (narrowing scope/removing S3 destination), or PutEventSelectors (excluding management events) against an active CloudTrail trail, from a session/role not normally associated with logging administration, followed shortly by other sensitive API activity that would otherwise be logged. Indicators:

CloudTrail (captured via the trail's last logged events before the gap, and by GuardDuty's own Stealth:IAMUser/CloudTrailLoggingDisabled finding) shows a StopLogging or DeleteTrail event.
The calling principal's typical activity history (via IAM Access Analyzer or historical CloudTrail) shows no prior logging-administration actions.
A subsequent gap in CloudTrail events for the account/region, followed by resumed logging later (if the actor re-enables it to avoid drawing attention) or continued silence.
Any API activity that IS captured immediately before the gap shows reconnaissance-style calls (ListUsers, ListRoles, GetCallerIdentity).

Null Hypothesis: A cloud administrator legitimately modified trail configuration as part of an approved logging architecture change (e.g., consolidating trails, migrating to CloudTrail Lake). Invalidate via change-management ticket cross-check and by confirming the calling principal matches the organization's designated logging-admin role.

Rationale: CloudTrail is the primary forensic record in AWS; an adversary disabling it is both a powerful evasion move and, paradoxically, one of the most reliably alertable actions available, since GuardDuty has a purpose-built finding type for exactly this behavior - this hunt validates that the alert pipeline and response process actually work end-to-end.

Step 2: Data Sources and Scope

Sources: AWS CloudTrail (management events, captured via the organization trail in a separate log-archive account, which cannot itself be disabled by the compromised account); GuardDuty findings; IAM Access Analyzer for principal history.
Scope: ~2022-06-25T04:15:00-05:00:00 UTC; Account: 445566778899 (prod); Principal: AssumedRole/DevOpsAutomation/i-0abc123.
SIEM Queries (Splunk/ELK):
Logging-disable events: index=cloudtrail eventName IN ("StopLogging","DeleteTrail","UpdateTrail","PutEventSelectors")
GuardDuty corroboration: index=guardduty type="Stealth:IAMUser/CloudTrailLoggingDisabled"
Preceding recon: index=cloudtrail userIdentity.arn="DevOpsAutomation" eventName IN ("ListUsers","ListRoles","GetCallerIdentity") earliest=-1h

Step 3: Key Findings

Parsed events (6 shown) confirm CloudTrail was deliberately stopped by an automation role after a burst of reconnaissance API calls, with GuardDuty independently flagging the action.

Timestamp (UTC)	Principal	Event Name	Details	IOC/Why Suspicious?
2022-06-25 04:16:02	AssumedRole/DevOpsAutomation	GetCallerIdentity	-	Baseline recon: attacker confirms current privilege context.
2022-06-25 04:17:40	AssumedRole/DevOpsAutomation	ListUsers, ListRoles, ListAttachedRolePolicies	14 calls in 90 seconds	Recon burst IOC: enumeration volume far exceeds this role's documented automation function (routine deployment tasks, not IAM enumeration).
2022-06-25 04:20:11	AssumedRole/DevOpsAutomation	StopLogging	TrailARN=arn:aws:cloudtrail:us-east-1:445566778899:trail/org-trail	Core IOC: management-event logging halted by a role with no prior logging-administration history.
2022-06-25 04:20:12	GuardDuty	Finding	`Stealth:IAMUser/CloudTrailLoggingDisabled`, Severity=High	Corroboration IOC: GuardDuty independently and automatically flags this exact action - confirms the detection pipeline caught it in near-real-time.
-	-	(log-archive trail)	Organization-level trail in the separate log-archive account continued recording throughout - captured all subsequent actions the attacker believed were unlogged.	Architecture win: a properly configured multi-account logging architecture defeats this evasion attempt entirely - the attacker's own `StopLogging` call, and everything after, is fully visible in the org trail.
2022-06-25 04:22:00 - 04:45:00	AssumedRole/DevOpsAutomation	CreateAccessKey, AttachUserPolicy (AdministratorAccess)	Target user: a newly created IAM user `svc-backup-mgr`	Despite believing logging was disabled, these privilege-escalation actions were fully captured by the org-level trail - attacker proceeded under a false sense of stealth.

Validation:

Timeline: Recon → StopLogging → (believed-stealthy) privilege escalation, all captured regardless of the StopLogging call thanks to the independent organization trail.
False Positives: No change ticket exists for trail modification; the calling role's documented function (automated deployments) does not include logging administration.
Correlation: Single role, single session, clear intent chain from recon through evasion attempt to privilege escalation.

Step 4: Recommendations & Next Steps

Immediate Response: Re-enable CloudTrail logging on the affected trail immediately (StartLogging); revoke/rotate all credentials associated with the DevOpsAutomation role and its underlying EC2 instance profile; delete the rogue svc-backup-mgr IAM user and any access keys it generated; treat this as a confirmed active compromise and initiate full incident response.
Detection: This should already be a standing P1 GuardDuty-driven alert (Stealth:IAMUser/CloudTrailLoggingDisabled → auto-page on-call) rather than a hunt-only finding; supplement with a Sigma-style rule: title: CloudTrail StopLogging or DeleteTrail Call → selection: eventName IN ("StopLogging","DeleteTrail").
Pro Tip: Always deploy an organization-level CloudTrail in a dedicated, access-restricted log-archive account - this single architectural decision is what turned an attempted "go dark" evasion move into full visibility of everything the attacker did next; if your environment lacks this, prioritize it as the single highest-leverage AWS logging control you can implement.

Hypothesis confirmed - an automation role disabled CloudTrail logging in an apparent evasion attempt, fully captured by an independent organization-level trail and flagged by GuardDuty!