We spent the weekend of August 6 to 9 in the Aerospace Village at the Las Vegas Convention Center, doing what we do best: turning cybersecurity for complex systems into something people can walk up to and experience firsthand. We brought a space CTF, two space arcade mini-games, and a working local AI pentest tool that anyone could take for a spin against a live practice range. What follows is a recap of how the weekend went, along with a closer look at the tool we were quietly the most excited to show.
Nebula Showdown: hacking to save the world, more or less
Nebula Showdown is our entry-level space cyber CTF, and the story is about as serious as it needs to be. The Nebula Syndicate is threatening to destroy historic monuments around the world with a space laser unless their demands are met. You join the Aurora Alliance, break into the Syndicate's systems, and deorbit the threat before it fires. The plot is really just a backdrop. What you are practicing underneath it is how to safeguard ground stations, communication links, and spacecraft.
We wanted this one open to anyone who wandered by. It started when the Village opened, and all you needed was a laptop, a few tools most people already know like Wireshark and Nmap, and an inquisitive mind. DEF CON wifi is always a gamble, so we ran the whole thing on an isolated local range inside the Village, which meant it worked whether the network cooperated or not. We designed it to take under an hour and scattered hints everywhere, because the whole thing was about fun and learning. We just wanted people to enjoy themselves and leave knowing a little more about space cybersecurity than they did when they sat down. Everyone who finished took home a prize.
What Nebula Showdown actually taught
The narrative is deliberately over-the-top, but the lessons underneath it are real, and they are the same ones we teach in our Cybersecurity Fundamentals for Space course and run into during actual ground-segment assessments. The CTF is built as a kill chain: reconnaissance, then credential recovery, then a foothold, then a weak authentication step, and finally a destructive command sent to a spacecraft. None of the individual steps are exotic, which is really the whole point. The techniques behind them are worth walking through.
You attack a satellite through the ground, not from space. Nobody in the CTF touched RF or orbital mechanics. The whole chain runs through ordinary ground-side IT, like a source-code repository, a remote login, and a mission-control web console. Space systems get compromised through unglamorous enterprise infrastructure, and that infrastructure is the most likely way in for one simple reason: access. The ground segment is the part an attacker can actually reach, which is exactly why it deserves to be defended as if the mission depends on it. It usually does.
Small mistakes compound into a lost spacecraft. Picture a secret left somewhere it shouldn't be, a password reused across systems, a flat network that answers every probe, an authentication endpoint with no brute-force protection, and a destructive command that anyone with API access could reach. With defense in depth in place, any one of those is recoverable on its own, but strung together they are enough to deorbit a satellite. The upside for defenders is that the same logic runs in reverse, so breaking any single link is enough to stop the whole chain.
Space is cyber-physical, and physical is irreversible. The finale of the CTF isn't stolen data, it's a real, unrecoverable, physical outcome. A database you can restore from a backup, but a satellite you have already deorbited is simply gone. That gap is what sets space and OT apart from ordinary IT, and it is why the heaviest mitigations belong around the commands that cause physical effects rather than around the perimeter.
Authorize commands, not just users. This is probably the sharpest lesson in the whole CTF. A safety-critical, irreversible command sits on the same interface, behind the same authorization, as a routine telemetry read. Once you can talk to mission control, that command is sitting right there with everything else. These are legitimate, needed commands, but they carry irreversible consequences, and reaching the interface should never be the same thing as being cleared to send one. Safety-critical operations need their own authorization on top of the session, with elevated roles, separate approval, and two-person integrity for the most consequential commands before anything irreversible runs.
Mission-control software is just software. The mission-control system in the CTF fails in thoroughly textbook ways: weak, guessable credentials, an authentication endpoint with no rate limiting, and operational details leaking out of a page that should have given nothing away. Calling something a space system is not a security property in itself. It still has to be patched, hardened, and monitored like anything else on the network.
The encouraging part underneath all of this is that defense in depth was never about building one perfect wall. Secret hygiene, unique credentials, network segmentation, rate-limited authentication, command-level authorization: any single one of them, done well, breaks the chain before it ever reaches the spacecraft.
And if you wanted, you could bring an AI operator with you
The part we were most curious to watch play out was this one. Any CTF participant who wanted to could test-drive Cubernaut, our local AI pentest tool, to help them find flags. We scoped it to the CTF range, then let people work the same space enterprise they had been attacking by hand, this time with an AI operator running alongside them.
We did this for a real reason. Keeping Cubernaut confined to the range, and only the range, is central to how the tool is built, and it turned out to be the clearest way to show what "operator-supervised" and "local by default" actually mean in practice. People stood there and watched an AI work a target on the range inside a boundary it could not cross, on a network that never left the room. It made the case better than any slide would have.
MOUSE Runner and Flappy Drone
For the folks who wanted to prove something a little faster, we brought two space arcade mini-games. In MOUSE Runner you see how high you can make a satellite jump, and in Flappy Drone you try to fly a drone through a field of aliens and rockets without wiping out early. Each day's top scores earned a prize. Mostly, though, the games were an excuse to pull people into the booth, get them mashing buttons, and get a conversation going about the serious work sitting behind the silly premise.
DEF CON 34 drew somewhere in the neighborhood of 26,000 people, and over the three days thousands of them found their way to our booth. We had mini-game high-score winners and CTF finishers all weekend, and a lot of the conversations followed the same arc: somebody wandered up to play something, and left knowing a bit more about space cybersecurity than when they walked over.
So what is Cubernaut
Most of the conversation about AI in offensive security fixates on the model, on which one you picked and how big or clever it happens to be. We think that is mostly the wrong argument to be having. A while back we wrote about why a well-built harness matters more than raw model size, and Cubernaut is essentially that argument shipped as a working tool.
Cubernaut is a local, operator-supervised AI pentest tool. It runs on models you control, on your own network, and it approaches a target the way a disciplined operator would: set the scope, run the tools each step calls for, record what it finds, verify the result, and repeat with whatever that turns up. Throughout all of that, the operator can see everything that happens, while the harness decides which tools are actually allowed to run.
Control comes before autonomy
The usual pitch for autonomous AI hacking tends to skip the part that matters most to anyone who does this for a living, which is what stops the thing from doing something stupid, or something outside the pentest rules of engagement or scope, in your name. Cubernaut was built around that question before anything else, and it is the reason we felt fine handing it to complete strangers at DEF CON.
- Scope is checked. The engagement has defined boundaries, and the tool stays inside them. At the con, that boundary was the CTF range.
- The operator controls any risky action. Anything with real consequence pauses and waits for a human to sign off, so nothing significant runs without the operator clearing it first.
- Local by default. Your targets, your findings, and your engagement data never leave your network to be processed on somebody else's cloud.
That last point carries more weight than it first appears to. Pentest data is some of the most sensitive material an organization produces, since it amounts to a detailed map of how to break in. Shipping it off to a third-party API for analysis should be a deliberate, considered choice, not a default quietly baked into whatever tool you happen to be using.
How one request runs through the loop
Cubernaut runs the same six-stage loop on every request, then repeats it with whatever new evidence the previous pass turned up.
- Scope. Set the boundaries, and decide what is in play and what is off-limits.
- Route. Pick the specialist. A single coordinator sends each phase to the right expert.
- Focus. Load the context that specialist actually needs, and leave out the rest.
- Act. Run the tools.
- Remember. Save the evidence, so every finding is recorded rather than just surfaced once and forgotten.
- Verify. Check the result, adjust, and report.
Then it loops, carrying the new evidence forward into the next pass. The loop isn't there to be fast for its own sake. Its real value is that each step stays small, observable, and checked before the next one is allowed to build on it. That is the practical difference between a tool that assists an operator and one that runs off on its own and does something nobody can reconstruct afterward.
One coordinator, the right expert for each phase
Hand a single model a "go hack this" prompt and, however capable it is, you get one actor trying to hold every phase in its head at once, with no clean line between which decision belonged to which part of the job. Cubernaut takes a different approach and routes each phase to a focused specialist. There are more than thirty of them, each scoped to a single job and spanning the work a real engagement runs through, from network, wireless, and RF, to web, APIs, and databases, to cloud and containers, to endpoints, mobile, and OT, to exploitation and reporting.
The coordinator picks whichever one fits the phase, hands it a typed contract describing the work, and takes the resulting evidence back. Cracking work goes to the cracking specialist, a PCAP goes to the one built for PCAPs, and no single component is ever expected to be good at all of it.
Because each specialist hands its evidence back to the coordinator, the phases chain naturally. A run might go from network enumeration, to the web console that turns up, to that console's API, to the database sitting behind it. Another might move from an OSINT-surfaced credential, to cracking, to a foothold in Active Directory, to pivoting across the domain. The chain is not scripted ahead of time. Each hand-off is decided by what the last specialist actually found.
How the operator and the harness split the work
Cubernaut is not a black box that quietly hands you a report at the end. The operator watches the coordinator work in real time, seeing the findings as they are recorded, the state transitions, the hand-offs from coordinator to specialist and back, the typed contract each specialist receives, and a live workspace of hosts, services, and credentials filling in as they are discovered.
The demo target we ran is a ground segment, and that choice was deliberate. In it, Cubernaut notes that one host is running SSH and HTTP, that another is exposing a YAMCS mission-control API, and that a ground-station admin credential has been recovered, then it scores each finding by severity and passes the JWT it found to the cracking specialist to decode. Ground stations, mission-control APIs, and space enterprises are the same systems our space cyber training and the IRON GALAXY range are built around, and the same ones Nebula Showdown had people attacking all weekend.
Where it fits
Cubernaut brings the same thinking to the offensive side that shapes our defensive work. Our Terrain Trace tool follows the same philosophy pointed in the other direction: a local, AI-assisted process with a human in the loop and the model held firmly in an assistant's role. It is the same conviction applied at both ends of an engagement. Keep the work local, keep the operator in charge, and make the AI earn its place by doing focused work that gets checked rather than being left to act unsupervised.
If we had to compress the whole weekend into a sentence, it would be this: the future of responsible, managed AI in offensive security looks less like a bigger model that you hand your secrets to, and more like a smaller, controlled system that stays on your network and does what you tell it, right in front of you.
If that is the way you would rather run AI on your own engagements, we want to hear from you. Get in touch to talk about what Cubernaut could do for your team.
