In Part I, I caught secrets by knowing the shape of secretsdump, of netexec, of hashcat. A reader could fairly ask: are you doing research, or are you writing regexes forever? They would be right. This part inverts the whole thing. You cannot enumerate every secret format in the world, and some secrets have no format at all, so stop trying. Keep only what is provably generic (dictionary words, numbers, dates, protocol constants) and tokenize the rest by default. I measure it live on HTB Shibuya through a full root chain, then across ten Active Directory machines, with no per-tool rules at all, and I situate it against the literature, which turns out to have a clear closest neighbor and a clear gap.
I want an AI agent that can do offensive and defensive security work without ever leaking a credential, a hostname, an IP or a domain to the model provider, and to keep that property no matter which provider sits behind the API. This is Part I of the research. It covers the threat model, the state of the art, the core mechanism (bidirectional tokenization with host-side resolution), and four experiments that run on real HackTheBox machines, including an autonomous agent that drives a real domain controller while seeing nothing but opaque tokens.
I come from offensive security and I have spent a lot of time on AI research, MCP, and vulnerability hunting. When Hack The Box shipped its Certified Offensive AI Expert, I jumped on it. This is a retex of the AI Red Teamer path and the certification, focused on how I prepared and the math behind the attacks, kept strictly within HTB’s disclosure rules.
The Hacker Recipes said remote SID History injection from Linux was impossible. pySIDHistory proves otherwise with two methods: DRSUAPI and DSInternals.