I recently finished Cybernetics, a large enterprise Active Directory lab. It spans several Windows domains, trust relationships, and Linux web servers across a segmented internal network.
This post is deliberately spoiler-free. No host names, no exploit chains, no flag locations, nothing that would rob you of the lab.
It was a fun and challenging lab, and what made it satisfying was that it rewarded two things far more than it rewarded clever one-shots. The first was persistence: the willingness to keep returning to the same problem for as long as it took. The second was tooling: the willingness to stop using tools the way they ship and start building what the problem in front of me actually needed. This post is about those two things, because they are what got me to the end.
Persistence was the actual difficulty
The honest version of how I cleared this lab is that I refused to put it down.
I started it in the back half of last year, got a long way in, and then stalled. Life happened, the remaining targets were genuinely hard, and the lab sat untouched for months. When I came back to it this year I had to re-enumerate things I had already owned, rebuild context I had lost, and pick up threads I had abandoned mid-thought. The final stretch ran from there to the day I finished. Start to finish, this was the better part of a year, not a weekend.
That gap taught me something the exploitation never did. The lab was not waiting to be beaten by a single good idea. It was waiting to be ground down. Most of the meaningful progress came after the point where it would have been completely reasonable to call it finished and move on. The last few objectives in particular only fell because I kept coming back to them with fresh eyes instead of accepting they were out of reach.
None of that is glamorous. There is no screenshot of “I thought about this for three weeks”. But persistence, not cleverness, is what the hardest parts of this lab actually rewarded.
Build the tool the problem needs
The other half of it was tooling, and this is the part I enjoyed most.
Over and over, the off-the-shelf approach got me to the door and no further. A public tool would almost work, or would work but get caught, or would assume an execution context I did not have. The progress came from treating those tools as raw material rather than finished products, and reshaping them until they fit the situation in front of me.
A few examples of the shape that took, kept abstract on purpose:
- In-memory by default. Anything written to disk on a watched host tended to get noticed, so the rule became that nothing touches disk if I can help it. Loaders ran in memory, common offensive tools were loaded reflectively rather than dropped as files, and on Linux payloads were launched straight from anonymous memory so there was nothing on the filesystem to find or quarantine. Once that was the default, the host’s defences mostly stopped being a factor.
- Adapting tools to load that way. Plenty of public tooling is not written to be pulled into a process reflectively. More than once the fix was to open the source and change it: adjusting entry points and exposing the right call so the thing could run in memory the way I needed, rather than the way its author intended.
- Escaping a constrained foothold. Initial execution often landed in a boxed-in, low-privilege context where a raw shell was a liability, not a capability. The real work was bootstrapping out of that into a durable, full-privilege operator channel without ever staging a file to do it.
- Making a callback come home. When a direct callback would not reach me, the fix was usually not a new exploit. It was relaying the traffic back through a foothold I already held, so the path existed even when the obvious route did not.
The mindset behind all of it is worth stating plainly, because it took me a while to internalise. “I have code execution” was never the objective. “I have a stable channel that survives, on a host I can return to, that does what I actually need” was the objective. The tooling existed to close that gap, and most of it had to be bent into shape by hand to do so.
Write down what didn’t work
The most underrated tool I used was a list of dead ends.
Big environments are full of plausible rabbit holes. A host looks like it should have more on it. A theory feels too clean to be wrong. So you search, and you search the same way again, and you search a third way that is really just the first way with a different coat of paint. Hours disappear into re-confirming a negative you already had. Over time, that waste compounds badly.
The discipline that saved me was recording negative results and respecting them. Once the evidence said a path was empty, I wrote down that it was empty and stopped re-running the same broad sweep hoping for a different answer. New theory, new search. Same theory, leave it alone. Some of my longest dead ends, the ones I sank days into, only stopped eating time once I wrote them down as closed and made myself believe it.
Paired with that was a preference for scoped, exact reads over broad recursive ones. Broad hunting feels productive because it generates output, but most of that output is noise, and on a watched host it is also exposure you don’t need. When I had a specific theory I checked the specific thing. When I didn’t have a theory, the answer was to go get a better one, not to spray the filesystem and hope.
Follow the integrations, don’t guess exploits
The cleanest progress I made never came from guessing at vulnerabilities. It came from following the environment’s own plumbing.
Real enterprises wire their systems together. Single sign-on trusts something. Automation reads from a secret store. A build system runs as something privileged and pulls config from somewhere. Those integrations exist to make the business work, and they are also a map. One system almost always knows how to talk to the next, and that trust is usually more reliable than any exploit you could throw at the door.
So when I was stuck, the better question was rarely “what is this host vulnerable to”. It was “what does this host already trust, and what does it talk to”. Chaining the environment’s own integrations, the sign-on, the secret stores, the automation, the config management, beat brute exploit-guessing almost every time. The boxes were trying to tell me how they fit together. The work was mostly listening.
I’m keeping this abstract, because the specific chain is exactly the kind of spoiler I promised not to hand out. The transferable point stands on its own: in an enterprise network, the integrations are the attack path. Map them before you start kicking doors.
A solved host isn’t necessarily solved
The last thing the lab taught me is the one I keep coming back to, and it ties both themes together.
You build heuristics because they work. “This kind of host is probably done.” “That sort of path is usually a dead end.” They are right often enough that you stop questioning them, and that is exactly the problem. A rule that is correct most of the time will quietly cost you the rest, and it will cost you at the worst possible moment, because you are no longer looking.
The final objective of the whole lab drove this home. It was on a host I had already counted as finished, in a place I had every reason to have checked and had talked myself out of. Finding it took no new exploit. It took going back to something I had mentally closed, with enough persistence left to question the assumption and enough tooling on hand to act on it the moment I did. The fix isn’t to throw out your heuristics, they are useful. It is to keep a little suspicion in reserve for the things you have already filed away as done.
Closing thoughts
Cybernetics was a great lab, and not because of the flashy parts, even though the flashy parts were a good time. It was great because of what it actually rewarded: showing up again and again over the better part of a year, and building the tooling each problem needed instead of hoping the tools I had would be enough.
None of that is lab-specific. The exploits change. The persistence to keep returning to a hard problem, and the habit of shaping your own tooling to fit it, are what carry over. The win, in the end, was never a single clever exploit. It was refusing to stop, and having built the things that made it cheap to act when the idea finally came.