HADES
A digital twin of a network, the drones it flies, and the satellites it talks to—with trained adversaries already inside it.
Attackers Don’t Read Org Charts
Most organizations learn how an attacker moves through their network after the attacker has already done it. The network, the drone fleet, and the satellite ground segment are usually assessed by different tools and different teams, and their reports never meet. An adversary does not respect those boundaries. A stolen credential on a laptop can be the first step toward a ground control station—and from there, an aircraft.
Players never play the game as designed. Neither does the adversary.
Where It Came From
HADES grew out of World of Haiku, the game I led at Haiku. In that game, a network is a place: devices and file systems persist, scenarios are authored like content, and scripted characters have motives of their own. The JSON networks we added to Forge in 2024 are the direct ancestor of the HADES network schema.
In January 2026, I wrote a first prototype in Python that turned the game inside out. Instead of placing a student inside a simulated network, it placed threat-actor agents—each with its own motivations and playbook—against a digital twin of a real one. The adversary became the player. The platform today still starts from the network and the people in it, then stretches the same model out to drones and satellites.
Cyber First: The Network and the People in It
Everything in HADES starts from the network; the other domains plug into it.
- Network Builder. Every device, link, service, person, and credential in one digital twin. It imports Nessus and ACAS scans, BloodHound Active Directory data, firewall rules, AWS and Kubernetes authorization data, infrastructure-as-code, and Cursor on Target tracks, then merges them all into one topology.
- Threat actors. A catalog of more than 30 MITRE ATT&CK-aligned profiles. Each is a JSON file that combines goal-oriented action planning with a path ranking learned from the evidence of each run. One profile, APEX, has no preset objectives at all; it derives them from whatever network it is given.
- Attack paths. A graph neural network ranks every viable route by probability and impact, through Active Directory paths and CVE exposure. Attack replay shows how a run unfolded, and lateral movement is tracked host by host.
- People. Users have schedules and multi-factor authentication, and optional social-engineering attacks test how they respond—so a phished account sits on the same path as an unpatched server.
- What-if hardening. Change a control, run it against the trained adversarial agents, and measure the projected risk reduction before anything in production is touched.
Traffic is modeled, too. HADES samples each flow between two devices and says whether it was blocked or resolved, and what evidence that verdict rests on. A connection that exists in the topology is not treated as allowed until routing and firewall evidence back it up.
The output is the part people actually act on: kill-chain coverage against ATT&CK, side-by-side scenario comparison, and a one-click remediation list in priority order. Reports export as JSON or PowerPoint.
Then Drones: From the Network to the Aircraft
Drone networks deploy from a catalog into the same scenario: the vehicle type; its speed, altitude, and battery profile; its ground control station; and its radio links. So the question HADES asks is not only whether a drone can be jammed, but how far an adversary already inside the network can get. It tests signal jamming, GPS spoofing, and control takeover, and tracks how a threat escalates from one compromised ground link toward the whole fleet.
And when the picture needs to be somewhere else, HADES can publish its current operating picture to Anduril’s Lattice, through Anduril’s own Lattice SDK.
Onboard Autonomy
Since August 2026, I have also been taking HADES onto the aircraft itself. It plans a mission; checks it against energy, terrain, airspace, and recovery; executes it under single-use signed authority; watches it in flight with an independent monitor; and keeps signed evidence of what actually happened. The same software runs on the operator’s desktop and, headless, on an NXP NavQPlus companion computer beside the autopilot.
The rule is simple: the clever parts can propose, and only the execution path can act. Planners, analytics, Orca, and the interface cannot transmit to a vehicle. Every command passes seven independent checks, and every attempt ends one of two ways—in an effect verified by reading the mission back from the vehicle, or in a refusal that keeps its evidence.
An independent runtime-assurance monitor watches every vehicle. In software-in-the-loop fault injection, it commanded a return to launch 115 milliseconds after the GNSS fix dropped—32 times sooner than the autopilot’s own failsafe. Nine fault and attack classes each have a fail-closed response that is tested continuously.
The flight models are held to the same standard: predictions are frozen before the vehicle arms, then compared with what it actually flew.
Everything in this section is software-in-the-loop with the real ArduCopter autopilot, public PX4 flight logs, or a bench test on the companion computer. HADES has not yet flown a physical aircraft, and none of this is a certification.
Then Space: Orbits, Links, and Ground Stations
The same scenario reaches orbit. Satellites, ground stations, and relay nodes sit on a live globe, with link budgets, pass windows, and the handover gaps an attacker could use. HADES models the CCSDS protocol stacks, including AOS, TC, TM, Space Packet, and Proximity-1, and runs named threat actors against the space network to show which ATT&CK phases they reach and which controls stop them. GNSS degradation is modeled alongside, because the drones depend on it, too.
Orbits are propagated with the U.S. Space Force’s Astrodynamics Standards implementation of SGP4, and CCSDS transfer frames are encoded byte for byte, with a CRC-16 frame check.
Runs Where the Network Is
Everything runs on the user’s own machine. The machine learning runs locally on a custom tensor engine, and networks and results are stored locally, never uploaded. The Windows desktop application works without a network connection, so HADES can run inside a closed network. AI assistance uses local models that the user supplies. A limited web build covers the analysis.
Tested Against the Reference
Where HADES models physics, it answers to published reference software. Three models are conformance-tested against it: ITU-R P.2108 clutter loss, ITU-R P.528 air-ground propagation, and curvature-constrained flight geometry. The rest of the physics and effectiveness models draw on open literature.
Where It Stands
HADES has been in beta since October 2026. It is listed as a software product on the U.S. Army Air Marketplace, which launched in March 2026. Nine patent applications naming me as sole inventor are pending; none has been granted yet.
- patent applications pending
- 9
- inventor
- 1
- threat-actor profiles
- 30+
- runs in closed networks
- Offline