I’m a security researcher building an AI-augmented offensive workflow. Every writeup on this blog carries a transparent AI-assist log that shows exactly where Claude helped, where it failed, and what I had to work out manually. No magic, no black-box shortcut — just an honest record of human-AI collaboration on real targets.
Why This Blog Exists
Three reasons, all connected:
1. Transparency over polish. AI-assisted pentesting is real. Pretending it isn’t, or hiding the seams, helps nobody. I’d rather publish a writeup that says “Claude hallucinated the CVE number, I verified it manually” than a glossy walkthrough that hides the reasoning entirely.
2. Methodology over flags. A root flag is just a checkpoint. The interesting question is how the thinking went — which enumeration paths were dead ends, why one technique worked where another failed, and what changed when I switched from raw intuition to AI-assisted analysis.
3. Public learning record. This blog is my white-hat trail: for recruiters, for the Anthropic CVP review, for myself. Offensive security is a craft. Crafts improve when you document them.
How AI-Assisted Pentesting Actually Works Here
I use Claude as a thinking partner and research accelerator, not as an autopilot. Here is what that means in practice:
What Claude Does Well in This Workflow
- Rapid reconnaissance synthesis — paste 30 lines of nmap output, get a structured list of attack surface candidates with relevant CVE references to verify.
- Protocol deep-dives on demand — “explain RFC-854 Telnet option negotiation” gives an accurate answer in seconds. I still verify it, but the starting point is solid.
- Payload generation scaffolding — first-draft wordlists, SQL injection variants, Python exploit stubs. Always reviewed and tested before use.
- Methodology critic — “am I missing an obvious attack path here?” Claude will list plausible hypotheses I hadn’t considered. Many are wrong; some are right.
- Writeup drafting — rough notes → structured markdown. The reasoning and verification are mine; the prose scaffold saves an hour.
What Claude Gets Wrong (And I Correct)
- CVE numbers — confidently wrong on ~20% of specific CVE lookups. Always verify in NVD/Mitre directly.
- Target-specific state — Claude has no live connection to the lab. It cannot “see” what nmap actually returned. I paste the real output; it reasons from that.
- Novel techniques — Claude is a pattern-matcher over training data. It misses genuinely new exploitation chains. Original research still requires original thinking.
- Tooling edge cases — “does gobuster support X flag” sometimes returns confident incorrect answers. Man pages > Claude for flag-level questions.
The AI-Assist Log Format
Every writeup ends with a table like this:
| Step | What I asked Claude | What it gave | What I changed |
|---|---|---|---|
| Recon | Explain why Telnet requires RFC 854 handshake | Accurate explanation | Nothing — used as-is |
| Dead end | Why does nc fail here? | Correct diagnosis of raw TCP vs Telnet negotiation | Verified against telnetlib source |
| Exploit | Draft a Python telnetlib login script | Working first draft | Adjusted timeout value |
This table exists in every post — not as a gimmick, but as a commitment to showing my work.
Methodology Principles
- Every claim is verified manually. AI output is a hypothesis; the machine is the oracle.
- Dead ends are documented. The paths that didn’t work are often more instructive than the ones that did.
- No flags without understanding. If I cannot explain why the technique worked, the writeup waits.
- The AI-assist log is mandatory, not optional. Transparency is the whole point.
- Difficulty-appropriate depth. Starting Point boxes get thorough coverage of basics. Harder machines get deeper protocol/exploit analysis.
Tooling Stack
| Role | Tool |
|---|---|
| AI assistant | Claude Opus 4.7 via Claude Code (CVP-track) |
| Note-taking | Obsidian |
| Writeup pipeline | Markdown → Hugo → Caddy on bare-metal Ubuntu |
| Blog theme | PaperMod |
| DNS / CDN | Cloudflare |
| Recon | nmap, ffuf, gobuster, feroxbuster |
| AD exploitation | BloodHound, kerbrute, evil-winrm, impacket |
| Reporting | SysReptor (for cert exam reports) |
| Lab platform | Hack The Box (starting-point → easy → medium → hard) |
What You Will Find Here
- HTB Starting Point — Tier 0–2 walkthroughs. Foundation, not flex. These are the boxes where I document every command, including the failed ones.
- HTB Retired machines — Full methodology walkthroughs published after the machine retires and spoilers are permitted.
- CTF events — Cyber Apocalypse, Business CTF, etc. Published the day the event ends.
- AI-assist analysis — Occasionally I’ll write about the AI workflow itself: what prompts work, what doesn’t, how to structure a Claude-assisted reconnaissance session.
About the Brand
crAIzy.dev is intentional typography: the capitalised AI sits inside “crAIzy” as a visual hook. It’s a declaration that AI is central to the methodology — not hidden, not apologised for, not overstated.
The blog defaults to dark mode and a monospace type system because that is the aesthetic of the craft. Tools are terminals. Terminals are monospace.
Contact
- Telegram: @pankratix — fastest response
- GitHub: github.com/denyspankratov
- Security disclosures: see security.txt
Open to: collaborations, CVP-track connections, coffee chats about AI-assisted offensive security methodology.
Not open to: blackhat work, pentest-for-hire without proper engagement agreements, spam.