Introduction
Welcome back to our series on preparing for incidents in the cloud. Check out Part 1 if you want to know how to setup access in the various clouds for your teams. In this part we will talk about our favorite thing in the cloud... logging. For each of the big three providers, we will highlight what logs are relevant and why. Followed by insights from real life incident response cases.
Want to know if your organization is ready for an incident in the cloud? Let's talk.
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
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:
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.
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.
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:
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:
Conclusion
In this second post of preparing for cloud incidents we highlighted the major log sources across the big three cloud providers. What they are used for and how they can be applied to answer investigative questions in real life incident response cases.
It is important to keep in mind that your mileage may vary, meaning if your company relies on a specific cloud service, for example a database, the audit logging for that database is a must-have and more important than other logs we highlight.
From our cloud incident response experience, most companies miss at least one or more relevant logs. The worst time to find out you are missing logs is during an incident!
Coming up next..
In the final blog post of this series, we will discuss critical infrastructure you can setup before an incident or leverage during an incident.
Do you want to get an independent assessment of your cloud security state? Don't just trust on what the cloud providers tools ($$) tell you! Schedule a demo to get actionable insights based on our in-house developed assessment software. Built by practitioner for CISO's and decision makers that want to keep their clouds secure.
About Invictus Incident Response
We are an incident response company and we ❤️ the cloud and specialize in supporting organizations in preparing and responding to a cyber attack. We help our clients stay undefeated!
🆘 Incident Response support reach out to cert@invictus-ir.com or go to https://www.invictus-ir.com/24-7