3 Lessons Learned from Simulating Attacks in the Cloud

While it doesn’t seem that long ago, the security industry did not really start pivoting into cloud pentesting until about ten years ago. As the space matured, we gained more efficiencies through automating attacks with tooling. In 2018, NetSPI released the MicroBurst toolset to help automate these attacks, and we still continue to make updates to this day. The tooling has certainly helped us become more efficient in our pentests, and has been a source for highlighting new attacks that the NetSPI team (and the cloud pentesting industry) have come up with. 

As we have continued to see developments in the attack space, we noticed a significant lack of detections in most environments. During many Azure cloud pentest report readout meetings, we often found that the client’s SOC team had zero detections around our actions. This lack of visibility has helped push organizations to improve on their logging capabilities in the cloud. While the logs are definitely there, the detections are still catching up. 

As teams have matured over the last decade, we’ve seen a significant uplift in cloud logging and alerting efforts. The introduction of Microsoft’s Sentinel and the increased log ingestion support from additional SIEM vendors, has continued to push the industry towards better logging and detection capabilities. Keep in mind that while much progress has been made, your SIEM is only as good as the rules that you have configured. This is where Breach and Attack Simulation as a Service can step in to test your detective controls and give you additional visibility into activities in your cloud. 

Having completed countless cloud assessments over the last decade, we have seen a few commonalities around detection and alerting, and are sharing the highlights here.

Lesson 1: Cloud platform logging is not enough.

While cloud logging has come a long way, the default logs only provide a part of the detection picture. In order to properly detect an attack in the cloud, you may need multiple layers of log sources (EDR, Application Logs, etc.).

Example: Azure Virtual Machine Run Command Logging

As an example, let’s look at the data sources needed to fully detect an attacker using the Azure “Run Command” APIs to run operating system commands on a virtual machine.

• Azure Activity Logs – The “Run Command on Virtual Machine” event using the “Microsoft.Compute/virtualMachines/runCommand/action” action
  • Logs that a command was issued on the VM 
• Script Execution – The execution of code via the interpreter (e.g. PowerShell, WMI, Windows EID 4104, etc.)
  • Logs the execution of scripting code, potentially the commands
• Azure VM File Monitoring – The executed commands are stored in the “C:\Packages\Plugins\Microsoft.CPlat.Core.RunCommandWindows” directory for Windows VMs. Linux VMs will have extension data in the “/var/lib/waagent” directory.
  • Temporarily logs the executed commands in local files

From this situation, we can see that the Azure Activity Logs only show part of the overall command execution picture. Without PowerShell logging or Virtual Machine file monitoring, a defender is only able to see that a user used the “Run Command” functionality, not the command that was run, or the result from the command. To improve on this, defenders can collect additional data points (and test their detections) to help clarify the details of the event.

Lesson 2: The right logs need to be enabled and going to the right places.

Managing cloud logs at scale can be difficult. How are you supposed to know which Azure diagnostic settings logs are going to help you detect an attack? 

We have found that many organizations do not have the logs that they need. As noted above, the default cloud logs only provide part of the picture, and additional logs can be costly. Not only do you have to pay for the ability to capture the logs, you also have to pay for the storage and processing of them.

Example: Entra ID Logging 

We have had multiple clients that use a third-party identity provider (IDP) as their primary IDP. Since they may not see a need for it, they typically do not want to pay for the higher tier Entra ID (P1) license. Additionally, the limited logs that they have, do not make it into the SIEM. This results in very little visibility into Entra ID events, which could allow an attacker to take undetected actions in Entra ID. 

It’s important to ensure all applicable data sources are being reviewed and tested. Even the ones you might not think are applicable.

Lesson 3: Cloud attack paths are rarely a single step.

I think this is common sense for most defenders, but there seems to be a misconception that cloud actions are very atomic, and therefore easier to detect. The simple act of reading a file from a Storage Account Blob Container may seem like a singular event, but let’s look at all the actions that are taken to read a file from the Azure Portal.

Example: Storage Account File Read

• List the storage account resources 
• List the containers within a Storage Account 
• List the files within a container
  • Typically involves generating a SAS token or listing Storage Account keys 
• Accessing the actual file 
  • Diagnostic settings logs for file reads 

As we can see, there are multiple potential data points that result from the reading of a single file in the portal. By limiting your detections to just one of these data points, you run the risk of missing the full attack, or potentially generating a multitude of false positives. While not every little action in the cloud will create an event, it’s important to have detections that look at the full chain of events, and it’s important to test those detections.

Where Breach and Attack Simulation Fits into Your Cloud Security

Take charge of your cloud security today by staying ahead of potential threats and strengthening your defenses for the future. Conducting  BAS exercises will pressure test your detective controls by mimicking real-world cloud attacks. This will help you uncover misconfigurations and validate that your detection rules are operating as intended.   

Final Thoughts

Hopefully, these lessons have provided some useful insights into how cloud attacks are being seen, and what you can do to strengthen your defenses. To further help organizations address these challenges with cloud security, our research team recently built a series of Breach and Attack Simulation tests (plays) that are based on these type of examples. The plays are easy to automate, so you can validate and improve the effectiveness of your detective controls within your Azure environment.