I break web applications to understand how they're built β and write up every technique in my own words.
If I can't explain why an attack lands without naming a tool, I don't consider it learned.
Injection
Authentication & session
Access control & logic
Tooling
Next up β Linux & Windows privilege escalation β Active Directory
Every one of those is the same question in different syntax: does the server trust a value I control?
| Attack | The assumption it breaks |
|---|---|
| SSTI | The server evaluates my input instead of displaying it |
| SQL / NoSQL | My input becomes part of the query instead of staying data |
| LDAP | I can close the filter and inject my own condition |
| ORM | The developer reached past the ORM into raw SQL |
| XXE | The parser will fetch whatever I point it at |
| JWT | The server trusts a token it should be verifying |
| IDOR | The reference is accepted, not authorised |
|
Attack techniques in my own words β the mechanism and the mistakes, not the answers. Plus the checklist I work through before opening a walkthrough. |
Exposure scanner in Python. Shows what's actually reachable from outside. On its first run it found an accidentally exposed Proxmox β which is why it exists. |
Proxmox lab: 22+ services, OPNsense segmentation, monitoring. Targets I'm allowed to break. |
The loop
- Solve it β hands-on, no walkthrough if I can avoid it
- Explain it from memory β closed notes. Recognition isn't recall.
- Write down what I got wrong β the misconception is the part that sticks
- Revisit on a schedule β spaced repetition, because knowledge decays
Every writeup follows that shape: when it applies Β· why it works Β· how to test it Β· what it looks like Β· how to fix it Β· what I got wrong.
The last section is the one I'd read first.
Background
Linux since my early twenties, first server and OPNsense firewall at 26, nine years in the trades β then all-in on security in December 2025. Currently training as an IT Systems Integration specialist (FISI, IHK).
I ran systems before I attacked them. That order helps: you reason about attack surface differently once you've had to keep something alive, patch it, and watch it fall over at 2am.
| Milestone | Target |
|---|---|
| eJPT | Q4 2026 |
| HackTheBox β OSCP preparation | 2027 |
| OSCP | 2028 |
| FISI β IT Systems Integration, IHK | until Q4 2027 |
π« borkadrian@proton.me
Learning in public. Everything here is my own work β anything borrowed is credited.
All testing on authorised targets only: my own lab, TryHackMe, HackTheBox, and intentionally vulnerable applications.