Cloud Incident Readiness
Key logs for cloud incidents
Log ranking
CISOs and cloud security teams need to make choices, one of them is which logs they enable. Sometimes compliance is the reason for enabling a log and retaining it for a specific period. However, sometimes there are budget constraints and you cannot enable everything. In this blog we want to help you make the right decision. We will rank the relevant logs for each provider, from a cloud incident response perspective. One thing to keep in mind: no logs, no crime!
Must-Have 🔥 – Essential logs required for detecting, investigating, and responding to security incidents. These logs should be enabled and retained by default where possible.
Should-Have ✅ – Valuable logs that provide additional insights into cloud activity. They enhance security monitoring but may not be strictly necessary for every organization.
Nice-to-Have 📌 – Supplementary logs that can help with deeper analysis but are often not crucial for basic incident response.
Microsoft / Azure
Let's start with the Microsoft cloud, covering Entra ID, Microsoft 365 and Azure. In the Microsoft world, logs are generated on the tenant level mostly by Entra ID, additionally you will have Azure specific logging and also from resources within Azure. To further complicate it you also have Microsoft 365 services that record their activities in a separate log. The table below shows the major logs and some basic details:
Entra ID Audit logs
Logs changes and activities related to Entra ID resources.
✅
30
Entra ID Sign-in logs
Tracks sign-in attempts, including success and failure reasons.
✅
30
Unified Audit Log
Provides audit trails for multiple Microsoft 365 services.
✅
180
Azure Activity logs
Captures control-plane events within an Azure subscription.
✅
90
Storage audit logging
Records access and modifications to Azure Storage accounts.
❌
Varies
Netflow logging
Monitors network traffic flow for security and analysis.
❌
Varies
Microsoft Graph Activity Logs
Tracks API calls and activities within Microsoft Graph.
❌
Varies
Must-have
Entra ID Sign-in logs
Entra ID Audit logs
Azure Activity log
Unified Audit Log
Should-have
Microsoft Graph Activity Logs
Nice-to-have
Storage audit logging
Netflow logging
Other resource logs (e.g. Kubernetes logging, SQL logging).
Example case: Cryptomining
Let's go over an example case in Microsoft, where we supported a client that became victim of a crypto-mining case. The client was alerted due to a huge increase in the bill, which started the investigation. They engaged us to figure out how it was possible that someone spun up over 20 virtual machines with very high specs. The investigation started with figuring out who launched the virtual machines, we then used that information to determine what other actions were performed by this account. Of course we also performed analysis into sign-in events for this user and found out a suspicious VPN IP in the login events. Additionally, we performed analysis of a snapshot of the host to determine what mining software was used and which pool was used for the malicious activity. In the mindmap below we have mapped the logs to the main investigative questions:
AWS
Moving on to AWS, from a logging perspective it's a bit easier than Microsoft, because if you use any internal AWS IAM flavour it's part of the default logging.
CloudTrail Management Events
Logs management operations performed on AWS resources, such as IAM changes and API calls.
✅
90
GuardDuty Findings (when in use)
Detects and reports potential security threats using machine learning and anomaly detection.
✅
Unlimited
CloudTrail Data Events
Captures API operations on data resources, such as S3 object access and Lambda function executions.
❌
Varies
S3 Access logging
Records detailed access logs for Amazon S3 buckets to track read and write operations.
❌
Varies
Route53 DNS Logs
Monitors DNS query activity to detect unusual domain resolution patterns.
❌
Varies
Netflow Logging
Tracks network traffic flows to analyze communication patterns and detect anomalies.
❌
Varies
Load Balancer Logging
Captures HTTP/S request details and traffic patterns through AWS Elastic Load Balancer.
❌
Varies
Must-have
CloudTrail Management events
GuardDuty findings (when in use)
Should-have
CloudTrail Data events
S3 Access logging
Nice-to-have
Route53 DNS logs
Netflow logging
Load Balancer logging
Resource logs (e.g. EKS, ECS)
Example case: Ransomware in S3
In one of our cases we were engaged because a client found a ransom note in their S3 bucket. We were tasked with figuring out how the threat actor was able to get into the environment and what they had done to data and resources in the AWS environment. The first thing we did was checking what logs were configured on the S3 bucket in question, based on that information we were able to determine which user performed actions against this bucket. Through analysis of CloudTrail we were able to find various discovery actions against the S3 service and bucket in question. This was all done by an IAM key which we used to track down any other malicious actions performed by the threat actor. The below figure shows the logs you can (and should) use to answer the main investigative questions.
Google
We will cover both Google Cloud and Google Workspace in this category of logs. The table below describes the major logs for GC and GWS:
Admin Activity Logging
Tracks changes made to GC resources by users and service accounts.
✅
400
System Event Audit Logs
Captures system-level activities, such as VM restarts and automatic service actions.
✅
400
Policy Denied Audit Logs
Records access attempts blocked due to security policies or IAM restrictions.
✅
400
Google Workspace Login Logs
Monitors user sign-in activity across Google Workspace applications.
✅
180
Google Workspace Admin Logs
Logs administrative actions taken within Google Workspace.
✅
180
Google Workspace Drive Logs
Tracks file access, sharing, and modifications in Google Drive.
✅
180
Google Workspace Gmail Logs
Records email activity, including message delivery and security events.
✅
180
Data Access Audit Logs
Captures read operations on GC resources to monitor data access.
❌
Varies
Must-have
Admin Activity logging
System event audit logs
Policy Denied audit logs
Google Workspace Login logs
Google Workspace Admin logs
Google Workspace Drive logs
Google Workspace Gmail logs
Should-have
Data Access audit logs
Other Google Workspace services logging
Nice-to-have
Resource logs (e.g. Cloud Run, Kubernetes)
Example case: Data theft from Google Cloud Storage
Recently we worked on a case where a company used Google Cloud Storage buckets, as the storage back-end for an application hosted in Google Cloud. In this case the threat actor was able to extract a large amount of files. Our investigation started again with the files in question that were taken, we were able to determine that it was possible due to the fact that the files were publicly accessible. The investigation then led into if there was internal involvement or potentially someone misconfiguring this application and the associated storage. Last but not least we analyzed the Google Workspace logs to check for indication of compromise there. Let's see what logs we needed to answer the investigative questions:
Last updated