Detecting and preventing malicious activity in cloud environments can be tough. The first challenge is building one's world view of existing attacker tactics in cloud environments, which tend to be widely different from the on-premise world. The second challenge is prioritization: where to start? What tactics are attackers using in real-world, documented data breaches? Finally, reproducing cloud attacks quickly and easily is critical to shorten feedback loops, and allow defenders to experiment first-hand with what realistic offensive behavior looks like.
In January 2022, Datadog released Stratus Red Team, an open-source project to list and easily reproduce common attack techniques in the cloud. After 18 months, 12 external contributors and 58 releases, Stratus Red Team has gotten popular in the cloud security community. In this spotlight article, we talked with Christophe Tafani-Dereeper, author and maintainer of Stratus Red Team, and two major contributors of the project.
How did the idea of Stratus Red Team come to you?
Before joining Datadog, I've had the chance to work in a managed security operations center (SOC) and in the cloud security team of a tech company. In both these positions I was involved in threat detection work. One of the common challenges we faced was making attack techniques easily reproducible, so we could efficiently confirm that our detection pipelines were working as intended.
The idea of a project like Stratus Red Team started growing in my mind in early 2021. Atomic Red Team was (and still is) a great open-source project, but it's strongly aimed towards on-premise environments. Reproducing attack techniques in cloud environments also has unique challenges, such as handling pre-requisite infrastructure for an attack to even make sense.
Joining Datadog was a great opportunity for me to bring this project to life and share it with the community of cloud security practitioners.
How did the first version come to life?
I prototyped the first version of Stratus Red Team in early January 2022, while working from a chalet in Saas-Fee, in the Swiss Alps. While it was initially written in Python, I ended up rewriting it in Go for performance and stability reasons.
The first version we released at the end of January 2022 was focused on AWS attack techniques.
How did the community react to the release Stratus Red Team?
When we released Stratus Red Team, I was thrilled by the interest it gained from the community, reaching more than 500 GitHub stars in less than a week. But stars are a vanity metric: what felt more impactful was hearing from practitioners actively using it to better discover, understand and reproduce cloud-specific attack techniques in their environment.
We received our first major community contribution in June of the same year from Ryan Marcotte Cobb, who implemented support for Azure attack techniques. A few weeks later, Dakota Riley allowed Stratus Red Team to expand to Google Cloud as well.
I flew to Las Vegas in August to present the project at BlackHat Arsenal and the DEF CON Cloud Village. This was a great opportunity to meet with the community, gather first-hand feedback and find new contributors. In many ways, maintaining an open-source project is like building a commercial product: you need to know who your "customers" are, iterate fast and seek feedback frequently.
How do you build a community around an open-source project like Stratus Red Team?
In my mind, Stratus Red Team was to be a project for the community, by the community. We decided early on that it would be not only open source, but that we would actively foster a community around it: the value of any open-source project lies much more into its community than its actual source code.
"Community" can have additional meanings than just contributors; it's also about everyone producing content that helps others discover and apprehend the project and the problem space, such as a talk at BSides Portland, an interactive demo from SnapAttack, or a blog post from FalconForce.
Overall, people should feel welcome to ask questions, challenge design choices, or suggest new features. They should feel empowered to contribute when they want to, and it's our responsibility to set the right stage for that.
Finally, consistency is key. The community needs to feel that the project is active, and that it benefits from both bug fixes and new features. This motivates people to contribute, because they know their work will be valued and used by others.
What's next for Stratus Red Team?
We have recently released new attack techniques for Google Cloud. We'll continue adding more Google Cloud, Kubernetes and Azure attack techniques in priority. We're also working on adding support for additional platforms, such as Amazon EKS.
Stratus Red Team has a public roadmap that you can access here.
External contributions spotlight
How did you first learn about Stratus Red Team?
I learned about Stratus Red Team from a close colleague, who lurks in private internet communities focused on cloud security. They suggested that we take a closer look at Stratus Red Team because it fills a niche that other open source cloud security projects - such as Pacu and Cloudgoat - do not quite cover.
What do you use Stratus Red Team for?
Stratus Red Team serves two important purposes: to ensure that we have comprehensive detection coverage for known attacks and to validate that our detection engines are working as expected.
Stratus Red Team provides “reference implementations” of known attack techniques against popular cloud providers. The combination of infrastructure and attack automation in Stratus Red Team makes these techniques easily repeatable, so researchers and engineers can calibrate detection logic and engines based on the artifacts generated by each technique.
In my talk Threat-Driven Development from Dash 2022, I dug into how Secureworks used Stratus Red Team and Jupyter Notebooks for structured end-to-end detection testing of our XDR product.
What pushed you to contribute?
The first version of Stratus Red Team did not include support for automated attacks against Azure and many of our customers have workloads running there, so there were compelling reasons to extend its codebase. Since I was already comfortable interacting with the Azure SDK from Python and I also wanted to grow my Golang skills, it felt like a natural fit to write the Azure provider for Stratus Red Team.
The world runs on open source software. Contributing to Stratus Red Team was an opportunity and an attempt to “pay it forward” to the cloud security community.
What do you hope to see next for Stratus Red Team?
The value of Stratus Red Team grows with the number of attack techniques and cloud providers in its catalog. I would love to see the community rally behind an Azure AD provider, in particular.
I would also love to see more features in Stratus Red Team that help purple teamers collect artifacts such as per-detonation access keys, infrastructure naming conventions, and other machine-readable information to make it easier to drive Stratus Red Team from CI pipelines and testing harnesses.
How did you first learn about Stratus Red Team?
As with many things, I first read about it in Clint Giblers tl;dr sec newsletter. I had recently moved into a role defending cloud infrastructure (AWS, K8s, etc), so it was of particular interest to me.
What do you use Stratus Red Team for?
Currently my job is centered on preventing and detecting bad things in cloud and K8s environments. Stratus is an awesome starting point for that. It really lets you get into that “Purple Teaming” style of workflow, of using actual techniques as a starting point for writing and tuning detections. It's also great for demos, and verifying if your detection logic still works months after initially deploying it.
I do a bit of internal upskilling and training for members of my team, and I tend to use Stratus in that capacity too. The techniques documentation alone is awesome. Ive been able to get people started with developing detections by having them start with a Stratus technique detonation.
I also love how Stratus provides a “closer to the tech” alternative to something like MITRE ATT&CK for Cloud/Containers. In my role, I have to speak the ATT&CK language to other stakeholders, but having actually implemented sub-techniques is awesome.
What pushed you to contribute?
A number of different things. I already enjoy contributing and building tools, but I wanted to find something that I was both actively using in a professional manner, and would be impactful to the community. There is a good need for both documented and detonatable cloud based TTPs, which is exactly what Stratus provides. The majority of existing tooling in this space is around EDR/endpoint based TTPs. Stratus is a huge step for those of us in the cloud space tasked with detection.
I also wanted to exercise my Golang skills on a real world project.
What do you hope to see next for Stratus Red Team?
Very excited about the upcoming EKS platform. More techniques are always exciting as well!