There's no shortage of offensive security material out there. HackTricks, GTFOBins, PayloadsAllTheThings, tool docs, cheat sheets, plus whatever's scattered across your own bookmarks and notes. If you already know the technique name, finding the syntax takes ten seconds.
The part that actually slows an engagement down is different. You land access. A cred works, a foothold lands, a web primitive hands you something you weren't expecting. Now you're staring at it, half typing a search query, trying to remember what that access is even good for.
That's the gap I built OpsecAtlas to close.
The reference doesn't know what you have. So I made it ask.
Every doc I'd used up to that point assumed I already knew what I was looking for. Fine for syntax lookup. Useless the moment you're standing in front of something new, trying to work out where it leads.
OpsecAtlas flips the starting point. Instead of a search bar waiting for a technique name, it starts from a state: what do you currently have.
Say it's low-priv domain creds. That's already a lot. From there you can enumerate the domain, hunt for Kerberoastable or AS-REP roastable accounts, check what the account you control can actually touch, map what's reachable. Each step opens the next set of options, and what you find changes what becomes relevant.
The atlas encodes that as routes. A state connects to the techniques that state actually unlocks, and those techniques produce new states that lead further in. It's not a flat technique list with a search box bolted on. Twelve starting points exist right now, from external access only to domain admin, each one routing through the techniques that actually apply at that point.
The question stops being "what page do I search for" and becomes "given what I have, what can I do." That second question is a lot closer to how an engagement actually plays out in your head.
So why not just keep using HackTricks
Fair question, worth answering directly instead of dancing around it.
HackTricks, GTFOBins, PayloadsAllTheThings are not going anywhere, and OpsecAtlas doesn't try to replace them. They're exhaustive, they're trusted, and for looking up a specific technique once you know its name, they're still the fastest thing available. OpsecAtlas even links out to them directly from its own reference library, because rebuilding that depth from scratch would be pointless.
What none of them do is tell you which of their thousands of pages is relevant to the access you're holding right now. That's the layer that was missing, and it's the only layer OpsecAtlas is trying to own. The copy-ready commands, the offline support, the engagement tooling, all of it exists to make that one layer usable mid-engagement instead of theoretical.
Worth being straight about the routing comparison too. WADComs already does state-to-command lookups, just scoped to Windows and AD. Arsenal already handles engagement variables well. Neither is trying to replace the other, and neither one puts state-first routing, variables, a pinboard, and a journal in the same offline pass across a whole engagement. That's the specific gap, not a claim that no piece of this exists anywhere else.
Commands that know your engagement
Knowing the next move is only half of it. You still have to swap in the target IP, the domain, the hash, fifteen times a session.
Engagement Variables handles that. Set your target IP, attacker IP, domain, DC, username, hash, listener port, once, and every command across the atlas with a matching placeholder fills itself in.
The important part is that it never touches the source. The authored command stays byte-exact in the corpus. Substitution happens purely at the display and copy layer, through a curated placeholder map. Turn variables off and you get exactly what was written, nothing silently swapped underneath you. For a command reference, that distinction isn't a nice-to-have. It's the difference between something you trust and something you double-check every single time.
Two more tools ride on the same context.
Loadout pins commands as you go instead of losing them across a pile of browser tabs. It keeps the raw command plus its source, applies your current variables, and exports the whole tray as a runnable shell script when you're done.
Journal logs hosts, creds, findings, and notes as you work, then exports a Markdown report skeleton at the end.
No accounts needed anywhere in that chain. It all sits in your browser.
Under the hood, it's still just Markdown
I didn't want to trade flexible for structured. The content is authored as plain Markdown files, same as any docs repo. A build pipeline parses that into a structured corpus, pulls prerequisites and outputs per technique, builds the state graph, precomputes the routes, and generates the search index. A static Astro and Preact frontend consumes the result.
Two things I wanted out of that setup. If technique A routes to technique B, there's an actual authored state connecting them, not a fuzzy "these seem similar" match. And fixing content is a Markdown diff, adding a technique is a pull request. It maintains like docs because it is docs.
Right now that's 97 techniques across 6 domains, essentials, network, web, Active Directory, Linux, and Windows, landing around 1,250 copy-ready commands. The number is fine, but it was never the point. A bigger pile of commands is still a pile if you have to reconstruct the path between them yourself mid-engagement. The routing is the actual product.
Offline, because the moments you need it are the moments you're offline
OpsecAtlas is a fully static PWA. Install it once, and the atlas, the search, and everything Engagement Variables, Loadout, and Journal touch keeps working with no connection. No accounts, no tracking, nothing calling home.
If you've done labs, OSCP-style exams, restricted VPN ranges, or engagements on networks where you genuinely don't want your tooling depending on an external service, you already know why that matters. The reference you reach for when things get uncertain shouldn't itself be one more thing that can go down.
Go break it
Live: opsecatlas.com
Source: github.com/msk3d0ut/opsec-atlas
The most useful feedback isn't "cool project." It's where the workflow breaks. A missing starting state, a route that leads somewhere with no operational sense, a command carrying a bad assumption, or a point where the real next move exists and the atlas just doesn't get you there. That's the feedback that actually makes it better.
Code is MIT, content is CC BY-SA 4.0. Use it only on things you own or are authorized to test.
If the atlas gets the next move wrong somewhere, I want to know exactly where.
Top comments (0)