HTB Academy bei 55%: Was ein Backend-Dev auf der anderen Seite lernt

March 22, 2026Seit ein paar Wochen sitze ich abends vor Hack The Box Academy. Nicht weil ich Pentester werden will. Sondern weil ich verstehen will, wie jemand meine Systeme angreift. Ich bin Backend-Entwickler. Ich baue APIs, designe Datenmodelle, schreibe Authentifizierungs-Flows. Und bis vor kurzem dachte ich, dass ich weiß, was "sicher" bedeutet. Prepared Statements, bcrypt, HTTPS -- die üblichen Verdächtigen. Was mir gefehlt hat: die Perspektive dessen, der versucht, da durchzukommen. HTB Academy gibt mir genau das. Systematisch, strukturiert, hands-on. Und es verändert, wie ich Code schreibe.

Warum HTB Academy und nicht YouTube

Pentesting-Content gibt es überall. Das Problem: Die meisten Tutorials zeigen dir, wie du ein CTF löst. Nicht, wie du die Methodik verstehst. HTB Academy ist anders, weil es einen strukturierten Pfad gibt -- vom Grundverständnis bis zur Zertifizierung (CPTS/CBBH). Ich habe mich für den Penetration Tester Path entschieden. Nicht weil ich vorhabe, als Pentester zu arbeiten, sondern weil ich als Entwickler verstehen will, was ein guter Pentester tut -- und warum er die Dinge findet, die ich übersehen habe.

Wo ich stehe: 55%

Der Path ist in Module aufgeteilt. Mein aktueller Stand: | Modul | Status | |-------|--------| | Using Academy Effectively | Abgeschlossen | | Background & Preparation | Abgeschlossen | | Penetration Testing Phases -- Assessment Specific Stages | 2/6 Sections | | Penetration Testing Phases -- Project Closeout | Offen | | Preparing for Real-World Pentests | Offen | Die ersten beiden Module sind Grundlagen -- wie die Academy funktioniert, welches Mindset man braucht, wie ein professioneller Pentest aufgebaut ist. Klingt trocken, war es aber nicht.

Der Mindset-Shift: Defender wird Attacker

Das Wichtigste, was ich aus den ersten Modulen mitgenommen habe, ist kein Tool und kein Exploit. Es ist ein Perspektivwechsel. Als Entwickler denkst du: "Wie mache ich das sicher?" Als Pentester denkst du: "Was hat der Entwickler vergessen?" Das klingt ähnlich, ist aber fundamental anders. Als Dev denkst du in dem, was du gebaut hast. Als Angreifer denkst du in dem, was fehlt. Die Lücke zwischen "implementiert" und "sicher" ist oft riesig. Ein Beispiel aus meinem eigenen Code: Ich hatte einen API-Endpoint, der User-Daten zurückgibt. Authentifizierung? Ja. Authorization? Ja, per Middleware. Aber der Endpoint hat die User-ID aus dem Request-Body genommen, nicht aus dem JWT. Klassischer IDOR. Ich hätte das nie gefunden, wenn ich nicht angefangen hätte, meine eigenen Endpoints wie ein Angreifer zu betrachten.

Was "Background & Preparation" wirklich bedeutet

Modul 2 heißt "Background & Preparation" und ich hatte erwartet, dass es langweilig wird. Stattdessen war es der Teil, der mein Verständnis von Pentesting am meisten verändert hat.

Pentesting ist kein Hacking

Die wichtigste Lektion: Ein professioneller Penetrationstest ist ein strukturierter Prozess mit klaren Phasen, Scope-Definitionen und Reporting-Standards. Das hat nichts mit dem Hollywood-Bild von jemandem im Hoodie zu tun, der in der Nacht Firewalls knackt. Die Phasen:

Pre-Engagement -- Scope definieren, Rules of Engagement, was darf getestet werden
Information Gathering -- Reconnaissance, OSINT, Attack Surface Mapping
Vulnerability Assessment -- Systematisch Schwachstellen identifizieren
Exploitation -- Schwachstellen tatsächlich ausnutzen (mit Erlaubnis)
Post-Exploitation -- Was kann ein Angreifer nach dem initialen Zugang tun
Reporting -- Das Ergebnis so aufbereiten, dass Devs es fixen können

Als Entwickler fand ich besonders die Phasen 1 und 6 augenöffnend. Phase 1, weil ich verstanden habe, wie wichtig der Scope ist -- ein Pentest ohne klaren Scope ist wie ein Code-Review ohne Codebase. Und Phase 6, weil ich jetzt weiß, warum die meisten Pentest-Reports für Entwickler nutzlos sind: Sie beschreiben das Problem, aber nicht den Fix.

Die Developer-Brücke

Genau hier liegt mein Vorteil. Ich kann beides: Die Schwachstelle finden UND den Fix schreiben. Nicht "JWT-Signatur wird nicht validiert" als Finding, sondern konkreter Code, der das Problem löst. Das ist der Grund, warum ich diesen Weg gehe.

Assessment Specific Stages -- wo es konkret wird

Modul 3 ist der Punkt, an dem man anfängt, tatsächlich Dinge zu tun. Die ersten zwei Sections, die ich abgeschlossen habe, behandeln die konkreten Schritte eines Assessments -- von der initialen Aufklärung bis zum aktiven Testing. Was mich hier am meisten beschäftigt hat: Wie viel ein Angreifer über ein System herausfinden kann, ohne es jemals direkt anzugreifen.

DNS-Records, Subdomains, Zertifikats-Transparenz-Logs
Technologie-Stack-Erkennung über HTTP-Header
Alte API-Versionen, die noch erreichbar sind
Vergessene Staging-Umgebungen

Als jemand, der selbst APIs deployed, war das ein Weckruf. Ich habe direkt danach meine eigenen Deployments geprüft. Spoiler: Mein Staging-Server war öffentlich erreichbar. Ist er jetzt nicht mehr.

Was sich in meinem Code verändert hat

Ich bin erst bei 55%, aber mein Code sieht schon anders aus. Nicht weil ich neue Frameworks nutze, sondern weil ich anders denke.

Vorher

Python

@app.get("/api/users/{user_id}")
async def get_user(user_id: int, db: Session = Depends(get_db)):
    user = db.query(User).filter(User.id == user_id).first()
    if not user:
        raise HTTPException(status_code=404, detail="User not found")
    return user

Nachher

Python

@app.get("/api/users/me")
async def get_user(current_user: User = Depends(get_current_user)):
    return UserResponse.model_validate(current_user)

Drei Änderungen, die ich jetzt automatisch mache:

Keine User-IDs in URLs -- Der Endpoint gibt dir DEINE Daten, nicht die von irgendjemandem
Response-Models -- Nie das ORM-Objekt direkt zurückgeben (sonst leaken interne Felder)
Auth aus dem Token -- Die Identität kommt aus dem JWT, nicht aus dem Request

Klingt offensichtlich? War es für mich nicht, bis ich selbst versucht habe, den alten Endpoint auszunutzen.

Der Weg zum CPTS

Mein Ziel ist die CPTS-Zertifizierung (Certified Penetration Testing Specialist) von Hack The Box. Nicht als Karrierewechsel, sondern als Validierung, dass ich die Angreifer-Seite wirklich verstehe. Was noch vor mir liegt:

4 Sections in Modul 3 -- der Kern des Assessment-Prozesses
Modul 4: Project Closeout -- Reporting, Dokumentation, Nachbereitung
Modul 5: Real-World Pentests -- von der Übung zur Praxis

Ich werde diesen Weg hier auf dem Blog dokumentieren. Nicht als Tutorial -- dafür gibt es HTB selbst. Sondern als Erfahrungsbericht eines Backend-Entwicklers, der lernt, seine eigene Arbeit aus der Perspektive eines Angreifers zu betrachten.

Für Entwickler, die überlegen anzufangen

Drei Dinge, die ich nach 55% sagen kann:

Du brauchst kein Vorwissen in Hacking. HTB Academy startet bei null. Wenn du Code schreiben kannst, kannst du Pentesting lernen. Du hast sogar einen Vorteil, weil du verstehst, was unter der Haube passiert.
Es macht dich zu einem besseren Entwickler. Nicht irgendwann, sofort. Nach den ersten Modulen siehst du deinen eigenen Code mit anderen Augen. Das allein ist es wert.
Fang an, bevor du "bereit" bist. Ich habe monatelang überlegt, ob ich die Zeit investieren soll. Jetzt ärgere ich mich, dass ich nicht früher angefangen habe.

Der Penetration Tester Path auf HTB Academy kostet kein Vermögen, und die Erkenntnisse fließen direkt in deine tägliche Arbeit zurück. Für mich ist es die beste Investition in meine Skills seit langem. Nächster Post: Was Modul 3 über aktive Exploitation lehrt -- und warum ich danach drei Endpoints in Produktion gepatcht habe.