Hands-on lab: Full Kubernetes compromise, what will your SOC do about it? (Part 0)
Part 0: Introduction
A little bit of context
In a company, the Security Operations Center (SOC) has the tough duty of protecting the company’s assets, its users, and the data they manage. In traditional IT environments, it’s usually not a big issue and we’re in known territory. But what about those DevOps deploying their applications in always more and more complex infrastructure? Are we still doing good in monitoring & securing Cloud-based or containerized applications?
Lab scenario
Those are the questions our fictional company Kuby will have to answer as they are facing a critical security incident. The databases of the two applications deployed in their newly created Kubernetes cluster, Flasky and Treasure, were leaked in a well-known Russian forum called XSS.
What are we going to do?
In this lab, we’ll do everything. This article will be split in three parts and aims to bring you the full picture of a security event, from building the vulnerable infrastructure, exploiting it in our attack, and then responding to the incident in the most efficient way.
- Building Kuby infrastructure
We’ll use Terraform and Amazon EKS to deploy our Kubernetes cluster as code. A GitHub Actions CI/CD pipeline associated to the Flasky application will also be set up. - Attacking Kuby infrastructure
We’ll leverage a supply-chain attack that lead to a backdoor being planted within Flasky application. Misconfigurations will lead us to getting access to the CI/CD pipeline. After tampering it, we’ll set our goal to compromise the Treasure database. - Responding to Kuby incident
In this rich scenario, we’ll see what was triggered by AWS native alerting with GuardDuty. We’ll then collect relevant artifacts to try and get a full grasp of the kill chain, and discuss about what could have been improved.
Who is this lab for?
- Security lovers (offensive & defensive) who want to improve their skills on Cloud and containerized environments
- DevOps lovers who want to feel the benefits of a strong collaboration with their security team to detect and respond to attacks
How should I read it?
Anyway you want.
- If you’re focused on the defensive part, you can simply do the last part since the logs of this lab are made available
- If you’re focused on the offensive part, building this will provide you a realistic lab to run your own tests, apart from the scenario we’ll cover
- For both, you may use this as a basis to run your own coverage assessment within your company: how would have your SOC done in similar scenarios? Does your SOC have the right telemetry? Does your incident response have the right tooling? You can setup an EC2 Launch Template to install your EDR on worker nodes, etc.
