Security operations · 3 MIN READ · ANDY RODGER · JAN 17, 2024 · TAGS: Cloud security / MDR
These new resources make it easier to know which API calls are associated with different MITRE ATT&CK tactics in Microsoft Azure and Kubernetes environments.
Cloud and cloud security are huge. Precedence Research valued the global cloud computing market at over $500 billion for 2023 and expects it to top $1.6 trillion by 2030. The Microsoft Azure cloud is the second largest in the world.
It’s no coincidence that cybercrime in the cloud is also huge. A 2022 Thales/451 Research report found that 45% of businesses experienced a cloud-based data breach or failed audit in the previous 12 months, “up 5% from the previous year.”
Kubernetes (k8s) is a big deal, too, and it’s getting bigger every day. According to Research and Markets, the global Kubernetes market stood at $1.8 billion in 2022 and is expected to grow to $7.8 billion by the end of the decade. Over half of Fortune 100s and 78% of small and medium-sized organizations have already adopted it to manage containerized applications.
However, one study found that 78% of k8s clusters have medium-to-high security concerns, and in a 2023 Red Hat survey, 37% of participants said they experienced revenue or customer losses resulting from a container/Kubernetes security incident.
In the cyber world, market heft and growth make you a target, and when you’re a target you get to deal with aggressive, innovative hackers. To help, we’re launching two new mind maps—these cheat sheets, which address security for Azure and Kubernetes environments, follow on toolkits we’ve released for Amazon Web Services (AWS) and Google Cloud Platform (GCP).
Security challenges
Microsoft notes a number of common security threats in Azure, including access token abuse and leakage, lateral movement from compromised workloads, and credential theft.
Security teams and developers are also learning—often the hard way—that k8s can be a very different kind of animal. Safeguarding your organization requires a new skill set.
We’ve mapped the Azure and Kubernetes services where these tactics often originate along with the API calls and actions they make to execute on these techniques, and as a bonus, we’re throwing in some of our own tips and tricks for you to use when investigating an incident that’s related to any of these tactics.
The mind maps examine nine areas of MITRE ATT&CK activity:
- Initial access: Regardless of the environment, step one is getting in and establishing a foothold. And, if you’re using k8s or Azure (or maybe both), there’s a good chance your crown jewels (or the path to them) exists in your infrastructure.
- Persistence: Once attackers get in the door, they’ll want a reliable way to return whenever they want.
- Privilege escalation: Deeper access into your environment allows attackers to unlock systems or data that are typically locked down.
- Credential access: Depending on the attacker’s goals, this might mean access to sensitive data or permissions.
- Discovery: When attackers first access to your environment, they know very little about it. So they need to better understand how it’s laid out.
- Collection: Privileged access lets attackers gather sensitive information.
- Exfiltration: You have it. They want it.
- Lateral movement: Discovering, collecting, and exfiltrating valuable information requires the ability to move around freely.
- Impact: Most cyberattackers are motivated by money. This often manifests as ransomware or crypto mining, especially in Kubernetes environments.
For each MITRE ATT&CK tactic, we not only tell you why attackers do it, we also detail the ways they execute it; indicate what to look for (including a list of very specific API calls); and provide handy investigation tips and tricks.
For instance, if you’re looking for privilege escalation in a Kubernetes environment:
– When debugging permissions, “kubectl auth –can-i” allows you to see the effective permissions for you or any user you are authorized to impersonate.
– The Kubernetes audit log includes RBAC decisions for the logged event. This can help you understand why a request was allowed or denied by tracing a log back to the role and role-binding definitions in your cluster.
And for an initial access investigation in Azure, we recommend you:
Review the source of authentication, user-agent strings, and credentials used to access the Azure environment. Investigate the authenticating user’s normal location. Check for any geo-impossible authentications, suspicious IP addresses, or anomalous authentication behavior.
We hope you find these mind maps/cheat sheets/toolkits, which reflect the behavior our security operations center sees every day, to be useful. We welcome comments and suggestions, and if you’d like to talk, hit us up.
