Thoughts on ISTS 11

Somewhere around the middle December, I was asked by my coworker Anthony (@_s1lentjudge) if I wanted to participate in RIT SPARSA’s Information Security Talent Search (ISTS) competition, which I had heard of but wasn’t entirely familiar with. I agreed, and spent some time in January and February preparing. I wasn’t able to do as much as much as I’d like, with project deadlines, my grad class, leisure activities and such, but I did spend some time trying to figure out what I was getting myself into. In a nutshell, the ISTS competition pits “blue teams”, each made up of five college students, against one another to defend a set of machines entrusted to them while attacking and gaining access to other team’s machines. All the while, a dedicated red team, made up of event sponsors and industry professionals, is also attempting to break into all of the blue team machines. My job, as part of the SUNY Institute of Technology team was to work the offensive, and complete items on the “bucket list” provided by the white team to score points. In addition, I would support the team in other ways that I could. Here are my thoughts from the competition.

The Good:
  • The night before the competition, Raphael Mudge (@armitagehacker) gave a presentation about Cobalt Strike and some advice on how to use it to score some access to machines early on. He kept referring to the “Penetration Testing Machines” as though they would be running some obscure system and I was worried that I would have Kali Linux available with all its related tools. Thankfully, once the competition started I found that we had two dedicated Kali machines.
  • For the most part, the environment set up by RIT SPARSA ran pretty well. I would have enjoyed a few less cables running under my chair but the machines they provided for vSphere and the network seemed to work while the competition was underway.
  • There was a number of things to accomplish, which helped keep things interesting. I really enjoyed the bucket list, since that gave teams a set of things to focus on after the initial access was obtained. Sure, it’s easy to just destroy the machine (and it happened quite a bit) but thinking about how to complete the challenges to score more points for the team was a nice addition. At one point, our asterisk binaries got wiped, but using access we had to another teams asterisk machine allowed us to exfil out the required binaries and get our machine back up and running without having to revert. Alternative to the attack/inject/defense checklist, there were lockpicking challenges, crypto and reversing challenges, and a new mobile security challenge that offered teams even more methods of gaining points than through service checks and injects alone. Honestly, there was more stuff to do during the competition than could realistically be completed.
The Bad:
  • I stated in “The Good” that the environment that was set up ran pretty well. This is true, except for one thing. The vSphere environment used was frustratingly slow for the first few hours of the competition. It took a solid few minutes to even open up a vsphere console window for the machines, and longer still to actually attempt to login. I gave up even trying to load Cobalt Strike after letting it sit for 15 minutes attempting to start up. It would also have been nice to have had the vmware tools already installed on the machines so that the werent limited to the default resolution (800×600?). One of the Kali machines got rebooted and it took nearly 30 minutes to accomplish. This did get better as time progressed but during a competition like this, the first moments are critical, and being unable to do anything set the teams up for failure from the beginning. This was especially the case since the red team had their own equipment and were informed of the default credentials for all machines during the briefing on the first night. In addition to that, the scoring engine seemed to have some trouble, so it was difficult to determine whether our services were compromised or actually working properly.
  • There were relatively few rules, which could be considered good I suppose, but it was tough to gauge what was in score or out of scope. Our vSphere creds were compromised at one point, and this was later determined to be against the rules but all too late for us. I have to give credit to the team that did this, since there was little we could to do combat it, except wait for the white team to reset it. I remember frantically switching ttys and CTRL-C’ing on one box to prevent one of our machine’s boot partition from being overwritten from /dev/urandom.
The Hilarious:
  • I loved the idea of compromising/reasoning with the red team to get control of your box back and I think that blue teams should use the same tactics with each other. The song and dance routines that the blue teams had to do to get access back to their domain controllers was quite enjoyable (See: 12, 3).
  • I also was quite amused by many of the tactics and techniques that were shown off during the event. From the nyan cat bootloader, to the IRC botnet, to the random wall conversations that were had with the red team on another teams box, it was highly amusing and helped alleviate some of the stress.
  • Raffi (@armitagehacker) was graciously donating shells from the many, many boxes he had access to which was great for completing some of the other challenges that we hadn’t finished yet. It was unfortunate that some of these were to our own machines 🙁
  • Lastly, the second day of competition seemed to bring out the most malicious in people. Boxes were going down left and right as teams were trying to knock each other out in hopes to score some extra service checks. There were so many casualties. We did our share of rm -rf’ing things, partially out of retaliation, and partially because it’s not something that you have the opportunity of doing too often. And you know what? It was kinda fun.