AWS CloudTrail is a service that records all AWS API calls made in your account — providing an audit trail of who did what, when, and from where.

CloudTrail logs include:

• Management events: Control plane operations (create/modify/delete resources, IAM changes, console sign-ins) — enabled by default
• Data events: Data plane operations (S3 GetObject/PutObject, Lambda invocations, DynamoDB operations) — opt-in, high volume
• Insights events: Unusual API call rate or error rate patterns — anomaly detection

Each event record contains: who (IAM user/role/root), what (API action), when (timestamp), where (source IP, region), what resource, and the response.

Default retention: 90 days in CloudTrail console. For long-term retention, configure a Trail to deliver to S3 (with optional S3 Glacier lifecycle for cheap archival).

Aspect	CloudTrail	CloudWatch
Purpose	API audit — management plane	Operational monitoring — metrics + logs
What it captures	Who called which AWS API, when, from where	Application logs, metrics, custom data
Primary use	Security forensics, compliance, detecting IAM abuse	Performance monitoring, alerting, custom dashboards
Default on?	Yes (management events)	Metrics yes; logs must be configured
Example	"User Alice deleted S3 bucket at 3am from IP 1.2.3.4"	"Lambda function errored 50 times in 5 minutes"

CloudWatch can receive CloudTrail events as metric filters (e.g., alert when root account is used). They complement each other.

• Azure Monitor: The foundational monitoring platform for Azure — collects metrics and logs from Azure resources, VMs, applications, and custom sources. Provides Alerts, Dashboards, Log Analytics workspace (Kusto/KQL queries), Application Insights, and VM Insights. It's an operational monitoring tool — not a SIEM.
• Microsoft Sentinel: A cloud-native SIEM and SOAR platform built on top of Azure Monitor's Log Analytics. It adds security-specific capabilities: Analytics rules for threat detection, Security incidents, Playbooks (SOAR automation), UEBA, Threat Intelligence, Watchlists, and 200+ data connectors.

Relationship: Sentinel uses a Log Analytics workspace as its backend data store. Azure Monitor sends logs TO the workspace. Sentinel then queries and analyses those logs for threats.

Microsoft Sentinel is Azure's cloud-native SIEM (Security Information and Event Management) and SOAR (Security Orchestration, Automation and Response) platform. Key components:

• Data connectors: 200+ connectors to ingest logs from AWS, GCP, Azure, M365, Syslog, CEF, custom APIs
• Log Analytics workspace: The underlying data store — all logs are ingested here and queried with KQL
• Analytics rules: KQL-based scheduled rules that run on ingested data and create Incidents when matched
• Incidents: Correlated groups of Alerts with severity, assignee, and investigation tools
• Workbooks: Interactive dashboards/reports built with KQL
• Playbooks: Logic Apps triggered by incidents for automated response (notify, block IP, disable user)
• UEBA: User and Entity Behaviour Analytics — baselines normal behaviour and flags anomalies
• Threat Intelligence: Integration with MISP, TI platforms, Microsoft TI — auto-enriches alerts with IOC context
• Watchlists: CSV-based reference lists (e.g., list of VIPs, known bad IPs) used in KQL queries

AWS GuardDuty is a managed threat detection service that uses machine learning, anomaly detection, and integrated threat intelligence to identify malicious activity in your AWS account.

How it works:

• Ingests CloudTrail (management + S3 data events), VPC Flow Logs, DNS query logs, and EKS audit logs
• No agents required — reads logs from the AWS backend, zero performance impact
• Correlates with threat intel (known malicious IPs, Tor exit nodes, crypto mining domains, malware C2)
• Uses ML to establish baselines and detect anomalies (unusual API calls, unexpected regions)

Finding categories: UnauthorizedAccess, Recon, Trojan, Backdoor, CryptoCurrency, Policy, Stealth, PenTest, Exfiltration, Initial Access, PrivilegeEscalation.

Findings are sent to Security Hub, EventBridge, and an S3 bucket. EventBridge can trigger Lambda for auto-response.

Aspect	SIEM (Sentinel/Splunk)	GuardDuty
Type	General-purpose log aggregation + detection	AWS-specific threat detection service
Data sources	Any log source (multi-cloud, on-prem, apps)	CloudTrail, VPC Flow, DNS, EKS only
Detection	Custom KQL/SPL rules + built-in rules	AWS-managed ML models + threat intel
Scope	Cross-platform correlation (AWS + Azure + endpoints)	AWS account only
SOAR	Built-in (Playbooks/Phantom)	Via EventBridge → Lambda (manual setup)
Cost	Per-GB ingested (expensive at scale)	Per-event analyzed (predictable, lower)

Best practice: Use GuardDuty for AWS-specific threat detection, forward findings to Sentinel/Splunk via connector for cross-platform correlation and SOAR automation.

Priority log sources for a cloud SOC:

• IAM/Identity logs: CloudTrail (AWS), Entra ID Sign-in Logs (Azure), Cloud Audit Logs (GCP) — detect credential compromise, privilege escalation, lateral movement
• Network flow logs: VPC Flow Logs (AWS), NSG Flow Logs (Azure), GCP VPC Flow Logs — detect exfiltration, C2 communication, lateral movement
• Management plane logs: CloudTrail, Azure Activity Log, GCP Admin Activity — detect configuration changes, resource creation
• Endpoint/VM logs: Windows Event Logs (4624, 4625, 4688, 4697), Linux auditd, Sysmon — detect malware execution, persistence
• Application logs: Web server access logs, application error logs — detect web attacks
• Storage access logs: S3 Server Access Logs, Azure Storage Analytics — detect data exfiltration from object storage
• DNS logs: Route 53 DNS query logs, Azure DNS — detect DNS tunneling, domain generation algorithms

Indicators of compromised IAM credentials in CloudTrail:

• Unusual source IP or geolocation: Login from a country/region never seen before; TOR exit node; known malicious IP (match against threat intel)
• Unusual time: API calls at 3am when the user normally works 9-5
• New API actions: User calling APIs they've never used (e.g., CreateUser, AttachUserPolicy, RunInstances in unusual region)
• Privilege escalation patterns: AttachUserPolicy, CreateLoginProfile, AddUserToGroup — attacker trying to escalate or persist
• Reconnaissance: ListUsers, ListRoles, GetAccountAuthorizationDetails, DescribeInstances — attacker mapping the environment
• Unusual resource creation: EC2 instances in never-used regions, large instances (p3 for crypto mining)
• API errors: AccessDenied errors across many services — attacker probing permissions

Detection approach: Build CloudWatch Metric Filters or Sentinel/Splunk analytics rules that alert on combinations of these signals from a single identity within a time window.

KQL (Kusto Query Language) is the query language used in Microsoft Sentinel, Azure Monitor Log Analytics, and Azure Data Explorer. It's a read-only query language designed for fast analysis of large log datasets.

Key operators:

• | where — filter rows (like SQL WHERE)
• | project — select columns (like SQL SELECT)
• | summarize — aggregate (like SQL GROUP BY)
• | join — join tables on a key
• | extend — add computed columns
• | render — visualize as chart/table

Example — detect failed sign-ins: SigninLogs | where ResultType != 0 | summarize FailCount=count() by UserPrincipalName, IPAddress | where FailCount > 10

SPL (Search Processing Language) is Splunk's query language for searching, analyzing, and visualizing machine-generated data.

Key SPL commands:

• search / keywords — filter events
• | stats count by field — aggregate and count
• | table field1 field2 — display columns
• | where field > value — conditional filter
• | eval newfield = expression — computed fields
• | rex field=_raw — extract fields with regex
• | lookup — join against a lookup table (like threat intel IOC list)

Example — brute force detection: index=aws sourcetype=cloudtrail eventName=ConsoleLogin | stats count by sourceIPAddress, userIdentity.userName | where count > 5

UEBA (User and Entity Behaviour Analytics) is a security capability that uses ML to establish baseline behaviour for users and entities (devices, services) and flags deviations as potential threats.

In Microsoft Sentinel UEBA:

• Builds a behavioural profile for each user/entity over a rolling time window
• Factors in: login times, locations, devices, applications accessed, data volumes, peer group comparison
• Generates entity pages: a unified view of all activity for a user/device across all connected data sources
• Creates anomaly alerts without needing pre-written rules — ML-driven
• Adds UEBA context to existing Analytics rule alerts (e.g., "this user's behaviour is unusual — peer group score: 98%")
• Helps detect insider threats: legitimate credentials used abnormally

Crypto mining (cryptojacking) in cloud is a common attack where threat actors use compromised cloud accounts to mine cryptocurrency at the victim's expense. Detection signals:

• GuardDuty CryptoCurrency:EC2/BitcoinTool.B: EC2 instance making DNS queries or network connections to known crypto mining pools or software signatures
• VPC Flow Logs: Outbound connections to known mining pool domains/IPs (e.g., stratum+tcp:// on ports 3333, 4444, 14444)
• CloudWatch CPU metrics: EC2 instances running at sustained 90–100% CPU (GPU instances too if used for GPU mining)
• CloudTrail: Sudden deployment of many EC2 instances, especially GPU types (p3, g4) in unusual regions
• Cost anomaly: Sudden spike in AWS bill — Cost Anomaly Detection can alert on this
• Process-level (if agent): Known mining process names (xmrig, ethminer, nbminer) running on EC2

Response: Immediately terminate instances, revoke compromised credentials, trace back the initial access vector (usually stolen API key or SSRF).

Log immutability ensures audit logs cannot be deleted, modified, or overwritten after creation — critical for forensic integrity, compliance, and detecting attacker cover-up attempts.

AWS:

• CloudTrail log file validation: each log file is signed with a SHA-256 HMAC — tampering is detectable even if the file is modified
• S3 Object Lock (WORM — Write Once Read Many): prevents deletion or overwrite for a specified retention period; compliance mode can't be overridden even by root account
• SCP to deny s3:DeleteObject and cloudtrail:DeleteTrail across the organization

Azure:

• Azure immutable blob storage: time-based or legal hold retention policies on storage accounts containing logs
• Azure Monitor Log Analytics workspace data retention lock

GCP:

• Cloud Storage bucket lock (retention policy + locked bucket): prevents deletion of logs
• Cloud Audit Logs have tamper detection built in

An Analytics Rule in Sentinel is a scheduled detection that runs a KQL query against ingested log data on a defined schedule and creates an Incident (security alert) when the query returns results matching defined conditions.

Types of Analytics Rules:

• Scheduled: KQL query runs every X minutes/hours; create alerts if results exceed a threshold
• NRT (Near Real Time): Runs every minute — for high-urgency detections
• Microsoft Security: Auto-generates incidents from other Microsoft security products (Defender, Entra ID Protection)
• Anomaly: Built-in ML models from UEBA that generate alerts without KQL
• Fusion: ML-based correlation of multiple low-fidelity alerts into high-confidence multi-stage attack incidents

Each rule has: severity, MITRE ATT&CK tactic mapping, entity mapping (user, IP, host), alert grouping configuration, and can trigger a Playbook.

AWS EventBridge is a serverless event bus that routes events from AWS services (and custom applications) to target actions. In security:

• Event source: GuardDuty finding, Security Hub finding, CloudTrail API call, Config rule violation, Health event
• Rule: Pattern match on the event (e.g., GuardDuty finding severity ≥ HIGH and type contains "CryptoCurrency")
• Target: Lambda (custom remediation), SNS (notification), SQS, Step Functions, Systems Manager Automation

Security automation examples:

• GuardDuty CryptoCurrency finding → EventBridge → Lambda → terminate EC2 instance + revoke IAM credentials
• Config rule violation (public S3 bucket) → EventBridge → Lambda → call put_bucket_acl(private)
• CloudTrail root login → EventBridge → SNS → PagerDuty alert to on-call SOC
• Security Hub CRITICAL finding → EventBridge → JIRA ticket creation via Lambda

Alert fatigue occurs when security analysts are overwhelmed by a high volume of alerts — many of which are false positives — causing them to miss real threats, become desensitised, or burn out.

Causes: overly broad detection rules, ingesting too many low-quality log sources, no tuning, using default rules without customisation.

Reducing alert fatigue:

• Tune detection rules: Add suppression for known-good IPs, service accounts, scheduled tasks that trigger false positives
• Alert grouping/deduplication: Group related alerts into a single Incident (Sentinel Fusion, Splunk ESCU correlation)
• Risk-based alerting: Score each alert by asset value × severity × confidence; only page on high-risk combinations
• UEBA for context: Add behavioural context so analysts can quickly assess if an alert is anomalous for that user
• Auto-close low-fidelity alerts: Use ML to auto-close alerts that match historical false positive patterns
• Tier-based routing: Low-severity → ticketing system; Critical → immediate page + auto-response
• Regular review: Weekly false positive analysis; retire rules with >90% FP rate

GuardDuty finding types follow a naming convention: ThreatPurpose:ResourceTypeAffected/ThreatFamilyName

Three important examples:

• UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B — A console login from a previously unseen IP address or location, possibly using stolen credentials.
• CryptoCurrency:EC2/BitcoinTool.B — EC2 instance is communicating with a known bitcoin/crypto mining pool (pool domains/IPs). Indicates cryptojacking.
• Backdoor:EC2/C&CActivity.B!DNS — EC2 instance is making DNS queries to a known Command & Control domain. Indicates the instance may be part of a botnet or running malware.

Other notable types:

• Recon:IAMUser/MaliciousIPCaller — API calls from a known malicious IP
• PrivilegeEscalation:IAMUser/AdministrativePermissions — User attempting to grant themselves admin access
• Exfiltration:S3/ObjectRead.Unusual — Unusual pattern of S3 data read activity
• InitialAccess:IAMUser/AnomalousBehavior — First-ever API call from an IAM entity from a new region

Multi-layer detection approach:

• GuardDuty Exfiltration:S3/ObjectRead.Unusual: ML-based detection of unusual GetObject patterns (new IP, high volume, unusual time)
• S3 Server Access Logs: Enable per-bucket and alert on: large number of GetObject requests from external IPs, access from TOR exit nodes, non-corporate source IPs accessing sensitive buckets
• CloudTrail S3 Data Events: Enable for sensitive buckets; alert on: GetObject from unusual principal, GetObject before a DeleteObject (copy-then-delete), cross-account access by unknown accounts
• VPC Flow Logs: High-volume outbound traffic from VPC resources (if using VPC endpoints for S3 access); data transfer to unexpected external IPs
• AWS Macie: Auto-discovers PII/sensitive data in S3 and alerts on access patterns inconsistent with data classification
• Cost monitoring: Sudden spike in S3 data transfer costs — data transfer out is charged; large exfiltration = large bill spike

A Sentinel Playbook is an Azure Logic App workflow that automates security response actions, triggered by a Sentinel Incident or Alert. It's the SOAR component of Sentinel.

Common playbook actions:

• Send Teams/Slack/email notification to SOC analyst
• Create a ServiceNow/Jira ticket with alert details
• Block a malicious IP in Azure Firewall or NSG
• Disable a compromised Azure AD user account
• Revoke all active sessions for a suspicious user
• Enrich the incident with VirusTotal, Shodan, or threat intel lookups
• Add a user to a conditional access block policy
• Isolate a VM by removing it from its NSG and placing it in a quarantine NSG

Playbooks can be: fully automated (trigger → run → done) or require human approval (trigger → send Teams card → wait for analyst approve/deny → execute).

Multi-cloud log centralization architecture:

Option 1: Microsoft Sentinel as central SIEM

• AWS: AWS data connector (CloudTrail, GuardDuty, Security Hub via EventBridge → SQS → Sentinel connector)
• Azure: Native connectors (Activity Log, Entra ID, Defender for Cloud — one-click)
• GCP: GCP data connector (Pub/Sub → Log export → Sentinel connector)

Option 2: Splunk Cloud

• AWS: Splunk Add-on for AWS (S3-based CloudTrail, SQS for real-time, Kinesis)
• Azure: Splunk Add-on for Azure (Event Hub → Splunk)
• GCP: Splunk Add-on for GCP (Pub/Sub → Splunk)

Option 3: Centralized log aggregation tier first

• All clouds → centralized S3 bucket (cross-account) or Kafka/Kinesis → SIEM pull
• Better for normalization before SIEM ingestion; lower SIEM costs

Key challenges: volume/cost management, log normalization (different schemas), latency, access control for log data.