Listen to this Post
Introduction:
Cloud investigations collapse when critical logs are missing due to disabled auditing or insufficient retention policies. As a Senior DFIR Specialist noted, the data you need is often “never there or already gone” because logging wasn’t enabled, retention was too short, or detection lagged behind attackers. Without proactive readiness, incident response becomes guesswork, not evidence-based analysis.
Learning Objectives:
- Enable and verify cloud-native logging (AWS CloudTrail, Azure Monitor, Google Cloud Audit Logs) for forensic readiness.
- Configure appropriate log retention aligned with organizational detection and response SLAs.
- Execute command-line and API-based checks to validate logging status across hybrid environments.
You Should Know
1. Enable Foundational Cloud Logging Before an Incident
Many services disable verbose logging by default. For AWS, CloudTrail must be explicitly turned on for management and data events. For Azure, Diagnostic Settings need to be linked to each resource. Google Cloud requires Audit Logs activation per service.
Step‑by‑step guide to verify and enable core logs:
- AWS (CloudTrail)
Check if a trail exists and logs are delivered to S3/CloudWatch:aws cloudtrail describe-trails aws cloudtrail get-trail-status --name <trail-name>
Enable a multi-region trail with management and data events:
aws cloudtrail create-trail --name forensic-trail --s3-bucket-name <bucket> --is-multi-region-trail --enable-log-file-validation aws cloudtrail start-logging --name forensic-trail
-
Azure (Monitor Diagnostic Settings)
Using Azure CLI to check diagnostic settings for a VM:az monitor diagnostic-settings list --resource <VM-ID>
Enable collection of all logs (Administrative, Security, Alert, etc.):
az monitor diagnostic-settings create --name "ForensicLogs" --resource <VM-ID> --logs '[{"category": "AuditLogs", "enabled": true}]' --workspace <LogAnalyticsWorkspaceID> -
Google Cloud (Audit Logs)
Verify audit config for a project:
gcloud logging sinks list gcloud logging sinks describe <sink-name>
Enable data access logs via IAM policy:
gcloud projects get-iam-policy <PROJECT_ID> > policy.yaml Edit policy.yaml to include "cloudaudit.googleapis.com" with DATA_READ/WRITE gcloud projects set-iam-policy <PROJECT_ID> policy.yaml
2. Align Retention Periods with Realistic Detection Delays
Default retention is often 30–90 days, but incidents may be discovered months later (e.g., via third‑party breach disclosures). DFIR requires at least 12–18 months for compliance and long‑term threat hunting.
Step‑by‑step guide to adjust retention across clouds and on‑prem:
- AWS CloudTrail + S3 lifecycle
Set S3 lifecycle policy to transition logs to Glacier after 90 days but delete after 365+ days:{ "Rules": [{ "Id": "LogRetention", "Status": "Enabled", "Prefix": "CloudTrail/", "Transitions": [{"Days": 90, "StorageClass": "GLACIER"}], "Expiration": {"Days": 400} }] } -
Azure Log Analytics Workspace
Check current retention:
az monitor log-analytics workspace show --workspace-name <name> --resource-group <rg> --query retentionInDays
Set to 730 days:
az monitor log-analytics workspace update --workspace-name <name> --resource-group <rg> --retention-time 730
- Windows Event Logs (on‑prem/VM)
Increase Security log size and retention using PowerShell:
wevtutil sl Security /ms:1048576 /rt:true /ab:true /ms = max size (bytes), /rt enable retention, /ab auto-backup
- Linux auditd
Configure audit.log rotation and keep for 1 year:
sudo sed -i 's/max_log_file_action=./max_log_file_action=keep_logs/' /etc/audit/auditd.conf sudo sed -i 's/num_logs=./num_logs=12/' /etc/audit/auditd.conf sudo systemctl restart auditd
- Verify That Critical Data Sources Are Actually Logging
Enabled != working. Attackers frequently disable logging or tamper with local logs before exfiltration. Centralized, immutable storage is essential.
Step‑by‑step verification with real‑time tests:
- Test AWS CloudTrail
Generate an API call and check within 5 minutes:aws s3 ls > /dev/null aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=ListBuckets --max-items 1
-
Test Azure Activity Log
Create a test resource deployment and query logs:
az deployment group create --resource-group <rg> --template-file test.json az monitor activity-log list --resource-group <rg> --max-events 1 --query "[bash].operationName"
- Test Google Cloud Audit Logs
Perform a read operation and retrieve via Logs Explorer:gcloud compute instances list gcloud logging read "protoPayload.methodName=compute.instances.list" --limit=1
-
Windows + Linux local log integrity
Use `Get-WinEvent` and `ausearch` to confirm recent entries:
Get-WinEvent -LogName Security -MaxEvents 1 | Format-List
sudo ausearch -m USER_LOGIN -ts recent
- Bridge Cloud Logging Gaps with API Security Monitoring
Cloud APIs are the new perimeter. Without API audit logs, you cannot trace credential misuse or data exfiltration via tokens. Enable API‑specific logging in addition to generic cloud trails.
Step‑by‑step guide to API security logging:
- AWS API Gateway – Enable CloudWatch logging for REST/HTTP APIs:
aws apigateway update-stage --rest-api-id <api-id> --stage-name prod --patch-operations op=replace,path=/accessLogSettings/destinationArn,value=arn:aws:logs:...
-
Azure API Management – Forward diagnostic logs to Log Analytics:
az apim diagnostic update --service-name <apim-name> --name application --logger-id <logger-id> --enabled true
-
OAuth2 / JWT token logging – Extract and log token issuance and validation from identity providers (Azure AD / Okta). Monitor for unusual token volumes.
5. Hardening Cloud Against Forensic Blind Spots
Prevent attackers from deleting logs by enabling immutability and MFA on log storage.
Step‑by‑step hardening commands:
- AWS S3 Object Lock (prevent log deletion/modification):
aws s3api put-object-lock-configuration --bucket <log-bucket> --object-lock-configuration 'ObjectLockEnabled="Enabled",Rule={DefaultRetention={Mode="GOVERNANCE",Days=365}}' -
Azure Blob immutable storage:
az storage container immutability-policy create --account-name <sa> --container-name logs --period 365 --allow-protected-append-writes true
-
Disable local log clearance on Linux – Restrict `systemctl stop rsyslog` and `auditctl -e 0` via capabilities:
sudo setcap cap_dac_read_search,cap_sys_admin=ep /usr/sbin/rsyslogd (example hardening, use with caution) Better: monitor for service stops using osquery
6. Incident Response: Hunting for Gaps in Retrospect
When logs are missing, use alternative artifacts: cloud flow logs, VPC traffic mirrors, EBS snapshots, memory dumps, and API call remnants from third‑party security tools.
Step‑by‑step for partial visibility:
- AWS VPC Flow Logs – If enabled, reconstruct network connections even if instance logs are gone:
aws logs filter-log-events --log-group-name <flow-log-group> --filter-pattern "REJECT" --start-time <epoch>
-
Azure Network Watcher – Retrieve NSG flow logs to identify lateral movement:
az network watcher flow-log show --nsg <nsg-name> --resource-group <rg> --query "enabled"
-
Forensic acquisition of ephemeral storage – On GCP, snapshot a disk before VM deletion:
gcloud compute disks snapshot <disk-name> --snapshot-names forensic-snapshot --zone <zone>
7. Automate Logging Readiness Checks
Build a script that runs weekly to validate logging status, retention settings, and log delivery.
Example Linux/bash readiness scanner (save as `cloud_forensic_check.sh`):
!/bin/bash AWS check aws cloudtrail describe-trails --query 'trailList[bash].IsMultiRegionTrail' --output text aws logs describe-log-groups --log-group-name-prefix /aws/cloudtrail --query 'logGroups[bash].retentionInDays' Linux auditd check if systemctl is-active auditd; then echo "auditd active"; else echo "FAIL: auditd not running"; fi Windows via PS (run under pwsh) pwsh -c "Get-WinEvent -ListLog Security | Select-Object MaximumSizeInBytes, IsEnabled"
Schedule via cron or Jenkins to generate daily reports.
What Undercode Say
- Logging is an incident response prerequisite, not an optional add‑on – enabling it after a breach is impossible; treat logging as critical infrastructure.
- Retention must exceed detection latency – if your average dwell time is 6 months, 90‑day retention is a forensic disaster waiting to happen.
- Centralized, immutable log storage defeats tampering – attackers who compromise a host will delete local logs; push everything to a separate, write‑once bucket or SIEM.
The DFIR insight shared by the specialist rings painfully true: most cloud investigations fail not because of sophisticated evasion, but because the evidence was never collected. Budget and operational excuses vanish the moment a breach is confirmed. Organizations must shift left on logging – enable, verify, and extend retention before the alert fires. Automated readiness checks, API audit trails, and immutable storage are the new baseline. Without them, your incident response is just theatre.
Prediction:
By 2027, cyber insurance policies will mandate minimum cloud logging retention (e.g., 365 days) and enforce immutable audit trails. Failure to comply will void breach coverage. Simultaneously, AI‑driven log analysis will become standard for detecting logging gaps in real time, automatically generating forensic readiness scores and remediation playbooks. The gap between proactive logging and reactive forensics will widen, separating resilient organizations from those that pay ransoms without ever understanding the root cause.
▶️ Related Video (88% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Nadia Meichtry – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
