August 2025

Just some thoughts on my experience at DEF CON 33 and my team placing first in the Embedded Systems Village CTF. My plan for August was to write about interesting events I have seen in WAFs recently, but I thought it would be good to share some recent CTF experiences.

Trip Debreif

I have never been to DEF CON before, and it was quite the experience for me. I did not go to explore the different villages and vendors, I went with the specific purpose of competing in and winning the Embedded Systems Village CTF with some of my Classmates from BYU. I did not get to go with them last year due to a work conflict, I was especially sad about this as some I participated in was being presented at DEF CON that year. The team I normally do CTFs with took second place in the Embedded Systems Village CTF that year, and were pretty bummed about it as it was a very close contest. This year I was able to attend with them, and after practicing hacking embedded systems for a summer, we were able to bring home a win

Winning aside, there were some very important things I learned from this contest.

Embedded System Security is Lacking

I wont go into detail about the devices used, but needless to say, embedded devices are a hot mess when it comes to security. We started off with network discovery scans to determine what was on the network, and how we could attack based on services that were exposed. Seeing Telnet open and running on devices that were manafactured in the last ten years makes me sad (But makes the hacker inside very very happy). If you are going to have embedded devices on your home network, like a smart thermostat, security camera, digital picture frame, and so on, it is probably a good idea to place them on their own network, seperate from important devices to reduce risk of compromise. A lot of home routers these days offer options like this.

Vendor Backdoors

Image source: Andreas Sfakianakis (@asfakian) via X

Some embedded devices had backdoors that were left by developers unintentionally, and in some cases, it was blatantly obvious that they were intentional. When reverse engineering firmware, hardcoded credentials were found, some in plaintext, some in base64, some hashed, and some xor'ed with a set value. In most cases it was very easy to retreive these hardcoded credentials without even touching the device, as we were able to get the most recent firmware off of the device vendors website.

Lots of Unnecessary Services

There are some things that just should not be enabled on an embedded device. When was the last time you SSHed into your smart thermostat? Or had to anonymously FTP files to or from your oscilloscope? Probably never. It would be a good idea to have these off by default, and they can be enabled in the managment interface for advanced users, as needed. I cannot imagine a single usecase where my parents would use FTP or SSH on an embedded device, so they should be disabled by default. I thought that disabling unnecessary services was a fundamental step in system hardening!

Pivoting Through a Network

We found a number of known vulnerabilities as well as zero days in the devices that we were hacking, and on some of the devices, we were able to root them and use them as pivot points into other networks Imagine this scenario. I'm sitting outside your corporate office in my rusted out 2001 corolla with a big wifi antenna on it and I connect to your guest wifi network. I see that on your guest network, there is a wifi enabled multifunction printer. I am able to connect to that printer, and take advantage of a known vulnerability, or a zero day, and root the printer. From that printer, I use proxychains to tunnel traffic from my attacking laptop, in the parking lot, through your network attached printer. I start scanning the network through the printer (If you ever see a large ammount of network traffic from a embedded devices, it is probably up to no good). I am able to find other deivces on that network, and pivot into other devices, and possibly your interal network. Sounds a little crazy, right? Well, this is the kind of situations we found ourselve in during the Embedded Systems Village CTF. And I am not going to lie, pivoting through a network using embedded devices was actually a lot easier than I thought it would be, and that is not a good thing.

Value of Good Teamwork and Communication

This CTF also reinforced the value of good communication and teamwork in cybersecurity. When we are not communicating and collaborating well, we do duplicate work without knowing, and people get frustrated when time is wased We saw this happen some on day one. We had a debrief at the end of the day, and determined that we needed to get way better at communicating with eachother. Day two, we got way better at communicating, and our productivity increased significantly. When we were communicating better, our collaboration increased. Ideas flowed freely. More flags were obtained. This experience has brought to light that I can improve on my communication, and in turn, that will increase the output from teamwork, as I have seen that communication and collaboration are positively correlated.