Ran is an experimental offensive tool for Kubernetes clusters. It has two main objectives:

• enable quick (realistic) emulation of adversary techniques with predefined actions
• a collection for known attack vectors in Kubernetes (i.e. the implementation of the aforementioned actions)

The name is inspired by Rán, the Norse goddess of the sea (meaning 'plundering', 'theft' or 'robbery' in old Norse), who is associated with sea storms and drowned death. She is symbolized by a net, which she uses to ensnare and pull the unwary into the depths of the ocean.

❗ This tool is only intended for educational/demonstration purposes! Any other usage is not endorsed.

** ⚠️ Warning: This project is very early stage and highly experimental. Use at your own risk.**

In security, the cliche of the "attacker's advantage" is often cited:

an attacker has to be right once, but a defender has to be right all the time

This statement may be true for the initial access (IA) of an attack, but the script flips after the IA: defenders (theoretically) have full knowledge/visibility of the environment, while an attacker has to explore and learn about the environment first. This asymmetry is a huge advantage for the defender, which is often overlooked. The focus on just atomic detections of TTPs amplifies this misconception. Instead, when using at least micro emulations, where an adversary has to explore the environment, the defenders have more tools at their disposal.

Creating detections for environments is always very challenging. Maintaing these over time even more so. By viewing an environment through the lens of an adversary, different gaps or opportinities may arise. Using Ran, practicioners can explore the threats on their own environments and record all steps. Ran can export these tracked attacker steps into an AttackFlow, which is based on STIX 2. Some of the captured steps have observables linked, which can inform the managed detection rules.

Ran consists of 2 major components:

1. Actuator: responsible for executing or delegating the actions to C2 a framework
2. Planner/Reasoner: responsible for deciding what actions to execute and in what order

The actuator is responsible for executing the actions. It can be a simple command line tool, or a more complex C2 framework (e.g. Sliver, Caldera, etc.). The actuator is responsible for executing the actions and reporting the results back to the planner. The actuator is also responsible for tracking the executed actions and their results. This information is used to create an audit trail of the executed actions.

There are various approaches to planning and reasoning about actions. As this is an educational project, various approaches will explored:

1. No planner: the human operator decides on single tasks (classic atomic red teaming tool)
2. Imperative Plan: execute pre-defined plan/runbook (e.g. Mitre's Attack Flow)
3. "Classic" AI: commonly used in games and robotics
   • Behavior Trees
   • Classical planning
   • Hierarchical Task Network (HTN)
   • Goal-Oriented Action Planning (GOAP)
4. Modern AI: Reinforcement learning, Active Inference, Hybrid systems

Note: the evolutions are heavily inspired by book 📖 Artificial Intelligence: A Modern Approach

The case for planning and acting (especially in unknown environments) is well motivated in Mitre's 📄 Automated Adversary Emulation: A Case for Planning and Acting with Unknowns paper

TODO: provide clear instructions

Currently, Ran has only a very naive built-in C2 server, and only very basic support for Sliver. If Sliver is used as a C2 framework, Ran will act as a client. Therefore, follow the instructions to create a new operator configuration. Ran currently expects this configuration to be called sliver_cfg.json in the same directory as the binary. The sliver server can either run locally or on a remote system.

Ran is heavily inspired by similar tools in this domain, such as:

• Caldera
• Peirates
• Kubesploit
• kube-hunter
• kdigger
• MKAT
• kubeletmein
• CDK - Zero Dependency Container Penetration Toolkit
• red-kube
• kubestroyer
• Leonidas
• IceKube
• clusterfuck

• https://github.com/vulsio/go-exploitdb
• PEASS-ng
• go-pillage-registries
• amicontained
• dopwn
• botb
• MTKPI Multi Tool Kubernetes Pentest Image
• deepce
• ctrsploit

• https://github.com/danielsagi/kube-pod-escape
• https://github.com/aws-samples/hardeneks

• https://github.com/m0nad/Diamorphine/tree/master

• GTFOBins: list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems
• LOTTunnels: Living Off The Land Tunnels
• LOLC2
• LOLRMM

• Support K8s-related TTPs of Leonidas (atomic)
• Support K8s-related TTPs of Stratus Red Team (atomic)
• Track the executed TTPs (audit trail)
  • show Flow in UI
  • Export trail of executed TTP as Attack Flow

• support cleanup logic for every TTP
• Campaign reset functionality
• option to provide Attack Flow as a plan
• Support sliver as a C2 framework
  • add respective Procedures where necessary
• Derive produced Observable from the TTP execution and link it in the Attack Flow
• (Optional) Generate Sigma from STIX Observables?
• Support hierarchical TTPs: they use other TTPs as building blocks (akin to HTN)
  • e.g., Install implant could be -> generate implant + download binary + execute binary
• provide API to interact with Ran
• improve audit tracing
  • merge multiple (failed) attempts into 1 node?
  • Show key value in the title, to quickly differentiate same TTPs, but different objectives

• Map TTPs to D3FEND
• Simple Planning for a explicit goal
• Explore generation of attack trees
• MCP support for "Vibe kiddies" 🤖

• Behavior Tree execution
• Construct behavior tree from observed actions (trace -> Process Tree -> Behavior Tree)

Raesene KubeSecurity Lab
BishopFox's BadPods

For a comparison with other tools refer to the comparison