The Importance of CCDC Red Team Tooling
Hey all! I wanted to take a moment to point to a post by Alex Levinson on many of the recent tools he has been building for the CCDC Red Teams.
We’ve all take some huge steps to get around historic problems on the CCDC Red Team, some of which I will list here and how some of Alex’s solutions have upleveled us. Some of these old problems have been managing per team DNS, IP collisions, sharing notes, C2 servers getting blocked, and scripts being discovered, just to name a few. People “gaming the game” has been a problem in the past, for example watching network traffic and simply banning anomalous connections has been a very successful strategy in the CCDC world. We wanted to emulate more of an “Internet style environment”, where you had tons of IP addresses scanning you and banning edge traffic noise would no longer be a viable strategy. That’s why you see the invention of tools like DOOBY (a custom dhcp server), BORG (an army of headless vms), and MR.WIZZARD (an auto-nmap / ndiff service) that allow us to rapidly change IP addresses and issue commands from new, one-time ranges. Further GRID then removes our burden of constantly having to switch C2 servers, or initial payload hosting servers. This proxy layer created the perfect first layer of indirection we needed to simulate Internet proxies. In this way we could download tools or payloads and not compromise our implants C2 servers if the common or initial methods were discovered. Further, we could generate long lists of fallback C2 servers or even DGAs, requiring students to examine and understand the binaries beyond simply banning network connections.
Not only have these innovations removed previous blockers, but they’ve enabled better collaboration, something I’ve talked about in the past. With the creation of DOOBY we no longer had to maintain an annoying spreadsheet of who was reserving which IP addresses, but could still pull these lists at the end of the game. Further, all of these new backdoors and implants allowed us to host new team servers just in case previous persistence mechanisms failed us. Finally, my favorite part is that GOOBY allowed us to reuse and share code unlike ever before. Finally we could easily share functions, persistence methods, and C2 methods, across each other's projects, unlocking new turnkey features for our implants.
All that said, I highly encourage you to read his post and look at the many ways we’ve been innovating to get around previous limitations of the game. Keep in mind, these are only some of Alex's tools, Vyrus' tools, Lucas' tools, and my own tools, there are also all of the custom kits other CCDC Red Team members bring. I also believe this is the direction the NCCDC Red Team is heading, like Dave Cowen talks about in this year's debrief. I hope this makes many CCDC teams rethink their approach, especially if they’ve tried strategies that “game the game”, to take a deeper look at leveling up their incident response and reverse engineering skills. I’m going to end w/ an old presentation I gave, on the value of collaborative security infrastructure:
