The orbital infrastructure graph: attack paths you can walk, in the browser and in VR

A pentest report is a list. A real attack is a path. The gap between those two shapes is where most infrastructure maps fail: they draw every asset as an equal box on a grid, colour a few of them red, and leave the reader to reconstruct in their head the one thing that matters, which asset an attacker reaches first and what it costs them to get to the data. We rebuilt the DarkMoon infrastructure map to close that gap. This post is the reasoning behind it, the attempts that did not work, and where we think this goes.

What was wrong with the old map

The first version was a top-down tree of rounded squares. It rendered, it was accurate, and it was almost useless for a non-specialist. Two problems dominated. First, the findings piled onto whichever node the crawler happened to anchor on, so one box carried sixty vulnerabilities and the rest looked clean, which is the opposite of the truth. Second, the layout said nothing about exposure: a database holding password hashes and a public marketing page sat at the same visual altitude.

We wanted a shape where position means something, where a glance answers three questions: what is exposed to the internet, what sits closest to the crown-jewel data, and which single path connects the two.

Why an orbital layout

We tried a force-directed graph (it drifts and never settles the same way twice, so nobody can point at the same asset twice in a demo), a layered OSI stack (accurate, unreadable), and a classic node-link tree (the one we were replacing). The layout that held up was concentric: three exposure rings around a centre.

• Outer ring, internet-facing. The entry surface an attacker actually reaches first.
• Middle ring, applications and services. What runs on top.
• Inner ring, data and secrets. The things a breach is actually about.

Distance from the centre is exposure. Distance travelled inward is the cost of an attack. Now the picture carries the argument on its own, before a single label is read.

Findings attached to the asset they concern

The layout only helps if the data underneath it is honest, so we made the attachment deterministic and server-side. Every finding is routed to the asset it actually concerns, by its endpoint and its substance, not by whichever node a crawler touched. A leak of password hashes through an API route is attached to the database, an exposed key to the key service, a config disclosure to the admin endpoint. Each node carries its own severity ring and a small count badge, and clicking it opens the real per-asset finding list. No asset is a pile, and no asset is silently empty when it should not be.

The attack path as the main character

On top of the static graph we trace the kill chain. Findings carry their MITRE ATT&CK technique, and we order them into tactics, from reconnaissance and initial access through credential access to impact, then walk the real edge graph from the internet-facing entry to each sensitive asset. The result is a red path you can follow node by node, with a guided narration in plain language: reachable from the internet, the web application authentication is too weak, the database exposes password hashes, the file directory leaks sensitive data. A reviewer who has never read a CVSS vector can still follow the story end to end.

Two containers, any browser, and a headset if you want one

The graph is a web scene. That is a deliberate distribution decision, not a rendering one. DarkMoon ships as Docker containers and the operator opens the result in a browser, so the visualisation has to live there too, with no native app to install and no vendor SDK to accept. Because it is built on WebXR, the same scene renders inside a VR headset straight from the browser: Meta Quest Browser, Wolvic, or desktop Chrome with a headset attached, over HTTPS, with no Meta or Apple SDK anywhere in the stack. If you have no headset, the 2D map is the whole product and the VR view is a bonus, not a dependency.

We think this matters beyond a demo. Standing inside your own attack surface, following the path an adversary would take, is a genuinely different way to reason about exposure than reading a table. It is early, and we are honest about that, but the direction is deliberate.

Our reading of where this goes

Autonomous testing produces more findings than a human can trace by hand, so the bottleneck moves from finding to understanding. The tools that win the next few years will be the ones that let a person reason about a machine-generated attack surface quickly and correctly, brief a non-expert in a minute, and review a proposed fix with the exploit path in front of them. A spatial, guided, browser-native and headset-ready map of the attack surface is our bet on that shape. It sits on top of the same engine that produced the findings, and on Pro the same finding leads to a remediation pull request that is reopened only after the original exploit no longer fires.

The 2D graph is the default everywhere. The VR view asks only for a WebXR browser and a secure context. The vision is simple: security you can see, and an attack path you can walk. See the full-screen demo and the longer write-up.