Want to see Spyderbat in action?
If you are not familiar with the KIKrr Platform's World Hacker Games, this is an 'MMA-style' match to test security products in a live cyber range. During the one hour live match, a Red team fights to 'p0wn' the server(s) while the Blue team must discover and block them.
In round two of KIKrr vs Spyderbat, the range consisted of a Kubernetes orchestrated container environment. The KIKrr Red Team used the very recently discovered 'Silent Bob' exploit on a vulnerable Jupyter-Lab server to gain access to a shell in a container. Silent Bob is dubbed a 'cloud worm' due to its aggressive ability to spread to vulnerable Docker and Jupyter containers. The exploit is currently in use in a campaign by TeamTNT to power their botnet for mining cryptocurrency.
The use of Silent Bob was a great strategic decision by the KIKrr Red Team. Would Spyderbat recognize a brand new exploit?
Within a couple minutes of the attack, the Spyderbat Blue Team saw a high-scoring trace appear on their dashboard.
Drilling into the trace, the Spyderbat Blue Team saw the current progress of the attack:
The Spydertrace captured the early activity of the Red Team, finding a vulnerable Jupyter server and successfully running the Silent Bob exploit, they had access to a shell inside the container.
Clicking on the details of the process, Spyderbat Blue Team could see that the runtime behaviors were flagged for two reasons:
- The wget and chmod processes are suspicious and linked to known MITRE ATT&CK techniques.
- The ls, wget, and chmod processes, as well as the outbound connection on port 443, are violating the Guardian policy for the container's workload behavior.
Fighting fire with fire - while the KIKrr Red Team strategized to used a recently discovered exploit in their attack, the Spyderbat Blue Team used the Guardian key capability to automatically learn Jupyter-Lab's normal workload behaviors and recognize deviations.
However, the KIKrr Red Team wasn't done. They had downloaded a custom C2 server, 'DISASTROUS_SAMOVAR', designed to create its own container to hide backdoor communications and let them continue their attack.
What the KIKrr team had not realized is that Spyderbat leverages eBPF to ensure every process and network activity is recorded and analyzed.
The communications and subsequent command-line activity of the KIKrr Red Team is captured, tracked in real-time by Spyderbat Blue Team.
However, the KIKrr Red Team worked quickly in their attempt to p0wn the system. In less than 5 minutes they setup their C2 server, backdoor communication, and had downloaded their cryptomining program. Were they going to be successful in owning the system?
Foiled again by Spyderbat! The Guardian policy invoked an automated action to kill the pod, subsequently killing the Red Team's backdoor. Kubernetes will re-create the pod and container back in a clean state, giving the Spyderbat Blue Team time to resolve the vulnerability or keep the container off-line until it can be resolved.
Interested in learning more:
Watch the full replay of the World Hacker Games
Want to see Spyderbat in action?
