Cyber Conquest @ DakotaCon 10.1

A purple team (offensive and defensive) cybersecurity competition that I designed, planned and lead a team to build.

Start: 2023/01

Competition Date: 2023/03/25

What is Cyber Conquest?

Cyber Conquest is a purple-team cybersecurity competition (that is, it combines both offensive and defensive skillsets) into one king-of-the-hill contest. Teams are tasked with defending their own infrastructure while attacking other team’s infrastructure to gain points. Defensive points are gained by keeping your services up and keeping other teams off your systems, and offensive points are gained by planting your flag on opponent’s systems. - Computer Club Wiki / Cyber Conquest website

For this year's competition I went with a DC comics/city theme. Each network had a network with 8 systems on it.

A few of the systems were on physical laptops that teams were given. These physical systems were controlling actual ICS like systems.

Atlantis was a Windows Server 2012 with a node based webapp which talked to a MCP2221 and controlled the mock water tower. The water tower had a small fountain pump pushing water into a cup. It would fill up to a water sensor and then turn off in 1 second cycles. This caused the water level to oscillate up and down but never overflow or empty. This system was scored using 2 water sensors, one at the bottom to make sure that there was water in the water tower and the other at the top to make sure that the tower was not overflowing.

• FT232H GPIO Breakout
• Water pump
• Water sensor

Thanks to pythondude325 for writing the webapp!

Metropolis was an Ubuntu 18.04 Server system that we loaded a desktop environment onto. It used a FT232H to control 2 neopixel strips to act like a traffic light. The light was controlled by a python/flask based webapp that allowed setting individual pixels as well as changing the 'microcode' that it was running which scheduled when and how the lights blink.

• MCP2221 GPIO Breakout
• Neopixel strip

Thanks to Doodleman360 for writing the front end of this webapp!

STAR Labs was a raspberry pi 3 with a motor controller hat. We were donated a large amount of old peristaltic pump²⁾ motors which I repurposed to spin a 3d printed windmill blade³⁾. I used a variable power supply to power the motor controller, allowing me to dynamically set the max speed to something reasonable. The controller for the windmill was a very simple python script that checked for a file called spinny_speed.avi⁴⁾ setting the speed accordingly, then outputted the power it had generated to buzzzt.exe⁵⁾. These files were then scored via an SMB share. I had initially intended this to be on windows to have a scored SMB share, but some last minute changes caused it to be on the Ubuntu box.

• Motor controller hat
• Pump motors

The virtual systems were hosted in the DSU IALab⁶⁾. There were two main competition networks, a 'Blue' network connecting all the teams' networks and a 'Red' network with the scoring engine as well as virtualized kali boxes and some laptops. Both networks were connected together through the DefSec Router where traffic could be monitored by white team. Each team had their own virtual network holding their router and a few virtual systems. Each of these networks had its associated vlan trunked to the competition room and split out to physical ports on a switch in the room. Each team then had a switch at their table to connect the laptops and raspberry PI, which was connected back to the main switch. Each team had two laptops which were scored and in scope (Atlantis and Metropolis) plugged directly into their team's switch. Each team also had two laptops which were on the competition wide ream team network. All of the team tables were arranged in a circle around a center table that had the actual physical systems (traffic lights, water towers, wind turbines). On the center table I had a scoring PI that used multiple MCP23008 GPIO expanders to get enough GPIO ports to support the 2 water sensors per team for scoring⁷⁾.

The most complicated system to wire was the water tower. It had a water sensor and a pump which was controlled via a relay. I wanted to make sure that teams could not just lower the speed of their pump and disable the controlling program, so I used a relay to ensure the pump speed was constant.

My original design for the wind turbine had it being controlled by a single relay. After testing it for a bit I thought that it would be cool to make it spin forwards or backwards so I added a second relay. This design however is very bad for the motor. When the 1 relay design shuts the motor off, it just disconnects it and it spins out on its own, however when the 2 relay design shuts the motor off, it shorts the contacts causing the motor to jerk to a stop which causes unnecessary wear and tear to the motor. This effect is even worse if instead of stopping it switches speed. Then the motor has power applied in the opposite direction forcing the motor to stop even more abruptly and potentially back driving too much power to the board and damaging something. The solution to this is to add a third relay that disconnects one lead on the motor for a short time as it changes state. The problem with doing something like that for a competition setup is that when a malicious team gains access to the system they could remove the safety code to keep it from jerking and force it to constantly switch directions fast and break the motor. After trying to solve this problem for a while I realized that there was actually a very easy solution all along of just switching to use an actual motor controller hat. The motor controller was actually designed to change motor speed meaning that if you gave it a really drastic speed change like full forward to full backward it would slow it down gently⁸⁾ and not cause as much thrashing.

I loved this project. It was very stressful and a lot of work but it is also one of the most enjoyable projects that I have worked on. I got to work with cyber security (intentionally making systems vulnerable), blinky lights, motors, wiring, networking and of course infrastructure setup! I enjoyed figuring out how to wire up all of the physical components and learning about how things like the FT232H and MCP23008 work.

One of the coolest things I learned about was Fritzing. It is a FOSS wiring diagram creator which is such an awesome piece of software. I really wish I had known about it for FIRST robotics in High School.

I realized that I need to work on planning things out ahead of time better. If I had been more organized and started things earlier it would have meant less stress and fewer very late nights.

I could not have done this without the support of my operations team. They have been tirelessly working alongside me the past two months to make this happen.

Everyone who helped with the initial soldering day where we soldered headers onto the GPIO breakout boards as well as the motor controller hats.

The amazing on campus faculty who helped with acquiring resources⁹⁾, 3d printing¹⁰⁾, and network infrastructure setup¹¹⁾.