Interviewfragen zu OSCP

Eine SUID-root-Binärdatei läuft mit Root-Rechten, und wenn sie für alle beschreibbar ist, kann ein Angreifer sie ersetzen oder verändern, um beliebigen Code als root auszuführen — ein klassischer Pfad zur lokalen Rechteausweitung. Entfernen Sie das SUID-Bit, korrigieren Sie Eigentümer und Berechtigungen und untersuchen Sie, wie die Fehlkonfiguration entstanden ist, da sie auf eine Kompromittierung hindeuten kann. Das Verschlüsseln der Datei lässt den ausführbaren Pfad intakt, und das Umbenennen verschiebt das Problem nur, ohne die Ausweitung zu beseitigen. Keine dieser Optionen behebt die Ursache.

Die Rules of Engagement schließen DoS in Produktion meist aus, und ein ungeplanter Absturz verursacht echten Geschäftsschaden und kann den Auftrag nichtig machen. Prüfen Sie zuerst den Scope; ist ein destruktiver Proof of Concept nicht autorisiert, beweisen Sie die Schwachstelle mit sichereren Mitteln und dokumentieren Sie die wahrscheinliche Auswirkung klar. Den Exploit für einen Screenshot abzufeuern ist leichtsinnig. Ihn wiederholt für „Zuverlässigkeitsmetriken" auszuführen vervielfacht den Ausfall. Ihn stillschweigend zu überspringen verbirgt dem Kunden ein ernstes, ausnutzbares Risiko.

Professionelle Einsätze enden mit vollständiger Bereinigung und einem Artefakt-Inventar, damit keine neue Angriffsfläche zurückbleibt und die Umgebung des Kunden nicht getrübt wird. Shells oder Konten für den Kunden zum Finden liegenzulassen ist fahrlässig und gefährlich — ein echter Angreifer könnte sie wiederverwenden. Eine Hintertür „für nächstes Mal" zu behalten ist unethisch und wahrscheinlich illegal. Die eigenen Aktivitätslogs zu löschen zerstört die Audit-Spur, die der Kunde braucht, um den Test zu validieren und nachzuvollziehen, was Sie getan haben.

Es zählt die Auswirkung: Ein wiederverwendetes oder überprivilegiertes Dienstkonto, das Domänen-Admin oder kritische Systeme freischaltet, ist das relevante Finding — prüfen Sie also die Wiederverwendung und mappen Sie die Rechte und den Lateral-Movement-Pfad. Zuerst alle anderen Hashes zu knacken ist Beschäftigung, die das Wesentliche verzögert. Das Passwort des Dienstkontos zu ändern ist destruktiv, bricht die Produktion und warnt die Verteidiger. Eine aktive Anmeldeinformation im Klartext per E-Mail zu senden ist selbst eine Exposition und schlechte operative Sicherheit.

Eine aktive Intrusion zu entdecken ist ein Out-of-Band-Notfall: Die Rules of Engagement sollten einen Eskalationsweg definieren — lösen Sie ihn sofort aus, sichern Sie Beweise und vermeiden Sie es, einen laufenden Vorfall zu kontaminieren. Weiterzutesten kann den echten Angreifer stören oder genau die Beweise zerstören, die die Responder brauchen. Den Angreifer selbst zu entfernen liegt außerhalb des Scopes, ist riskant und kann ihn warnen. Bis zum Abschlussbericht zu warten könnte Tage anhaltender Datenpanne und Datenverlust bedeuten.

Beweisen Sie die Schwachstelle, ohne dem Kunden zu schaden oder seine Daten anzuhäufen: Zeigen Sie, dass Sie beliebige Daten über die DB-Version, das Schema oder eine einzelne anonymisierte Stichprobe lesen können, und hören Sie dann auf. Den gesamten PII-Datenbestand zu exfiltrieren erzeugt für beide Seiten eine Haftung zur Meldung von Datenpannen und zum Datenumgang. Eine Tabelle zu löschen ist destruktiv und geht weit über einen Proof of Concept hinaus. Die Datenbank zu verschlüsseln und ein Lösegeld zu fordern ist Erpressung, kein Test — eine Straftat, kein Finding.

Die Autorisierung definiert den Auftrag: Tests außerhalb des vereinbarten Scopes sind potenziell illegal und verletzen die Rules of Engagement, egal wie verlockend das Ziel ist. Dokumentieren Sie, was Sie gesehen haben, stoppen Sie und holen Sie die schriftliche Freigabe des Kunden ein, bevor Sie weitermachen. Ausnutzen für „mehr Findings" rechtfertigt niemals unbefugten Zugriff. Heimliches Ausnutzen in der Annahme, nicht erwischt zu werden, ist sowohl unethisch als auch eine Straftat, und den Scope selbst zu erweitern entzieht dem Kunden seine informierte Einwilligung.

Es bestätigt XSS. Wenn alert() überhaupt ausgelöst hat, hat der Browser Ihr eingeschleustes JavaScript im Seitenkontext geparst und ausgeführt — das ist die Schwachstelle. Ein leeres Popup bedeutet nur, dass das übergebene String-Argument nicht wie erwartet angezeigt wurde (Anführungszeichen-Behandlung, Kodierung oder Kontext-Verstümmelung haben die Nachricht zerstört), nicht dass die Payload blockiert wird. Der Ausführungspunkt ist aktiv; von hier aus verfeinern Sie die Payload.

Nein. CORS ist keine Abwehr gegen CSRF — es lockert tatsächlich die Same-Origin-Policy, damit eine Seite Cross-Origin-Antworten lesen kann, die sie sonst nicht lesen dürfte. CSRF muss die Antwort nicht lesen; es genügt, dass der Browser des Opfers eine authentifizierte zustandsändernde Anfrage sendet. Die echten Abwehrmechanismen sind Anti-CSRF-Tokens, das SameSite-Cookie-Attribut und das Prüfen von Origin/Referer.

Gefiltert. Ein gefilterter Port verwirft das Paket still, sodass der Scanner keine Antwort erhält und auf ein Timeout warten muss — er erfährt nichts darüber, ob der Host überhaupt existiert, und der Scan wird drastisch verlangsamt. Ein geschlossener Port sendet ein TCP-RST zurück, das bestätigt, dass der Host lebt und antwortet, und liefert dem Angreifer so gratis Aufklärungswert.

Nicht von allein. HTTPS verhindert MITM nur, wenn die Zertifikatsvalidierung strikt erzwungen wird und der Client die Website von Anfang an über HTTPS erreicht. Wenn einer Rogue-CA vertraut wird (Unternehmens-Proxy, von Malware installierte Root), wenn der Nutzer Zertifikatswarnungen wegklickt oder wenn SSL-Stripping die Verbindung auf HTTP herabstuft, bevor TLS startet, kann ein Angreifer sich weiterhin dazwischensetzen.

Ein Disassembler wie Ghidra oder IDA liefert die vollständige statische Karte: Querverweise, dekompilierten Pseudocode und jeden Codepfad, ob er ausgeführt wird oder nicht. Ein Debugger wie x64dbg lässt Sie das Sample kontrolliert ausführen — Haltepunkte setzen, Register und Speicher prüfen, die Entschlüsselung beobachten und den Pfad verfolgen, den der Code mit echten Eingaben tatsächlich nimmt. Man liest Struktur und Absicht statisch, hängt dann den Debugger an, um aufzulösen, was die statische Analyse nicht kann: zur Laufzeit entschlüsselte Strings, dynamisch aufgelöste APIs, gepackte Payloads und welchen Zweig eine Bedingung nimmt. Beide zusammen schließen ihre gegenseitigen Lücken.

Prozessinjektion führt bösartigen Code in einem anderen Prozess aus, um sich zu verstecken und dessen Vertrauen zu erben. Die klassische Remote-Injektion reserviert Speicher in einem Ziel mit VirtualAllocEx, schreibt eine Payload per WriteProcessMemory und führt sie mit CreateRemoteThread aus. Varianten umfassen DLL-Injektion per LoadLibrary, Process Hollowing, das einen suspendierten legitimen Prozess aushängt und sein Image ersetzt, APC-Injektion, die Code in einen Thread einreiht, und reflektives oder manuell gemapptes Laden, das LoadLibrary ganz vermeidet. Man erkennt sie an den verräterischen API-Sequenzen, RWX-Speicher in einem normalerweise sauberen Prozess, Threads ohne Backing-Datei auf der Festplatte und Eltern-Kind-Anomalien.

Entpacken stellt den ursprünglichen Code wieder her, den der Packer verborgen hat. Für bekannte Packer nutzt du den passenden Unpacker oder einen Emulator. Für eigene Packer entpackst du manuell: Führe das Sample in einem Debugger aus, lass den Stub die Payload in den Speicher dekomprimieren, finde den Moment, in dem er zum ursprünglichen Entry Point springt (oft durch Breakpoint auf Speicher, der ausführbar wird, oder auf den Tail-Jump), dumpe dann das Prozess-Image aus dem Speicher und baue die Import Address Table mit einem Werkzeug wie Scylla oder PE-sieve wieder auf. Das Ergebnis ist eine lauffähige oder analysierbare PE, die die echte Payload enthält.

Der WSTG ist eine checklistengestützte Methodik, die eine App durch Testkategorien führt: Informationsbeschaffung, Konfiguration und Deployment, Identität und Authentifizierung, Autorisierung, Session-Management, Eingabevalidierung (Injection/XSS), Fehlerbehandlung, Kryptografie, Geschäftslogik und Client-seitig. Er bietet systematische Abdeckung mit stabilen Test-IDs, sodass Befunde reproduzierbar sind und nichts Offensichtliches übersprungen wird.

PTES definiert sieben Phasen: Pre-Engagement (Scope, Rules of Engagement, Autorisierung), Intelligence Gathering (OSINT, Aufklärung), Threat Modeling, Schwachstellenanalyse, Exploitation, Post-Exploitation (Pivoting, wertvolle Daten, Persistenz) und Reporting. Die Struktur macht Einsätze wiederholbar, vertretbar und an das Geschäftsrisiko gebunden statt an Ad-hoc-Hacking. Pre-Engagement und Reporting sind die Phasen, die Juniors unterschätzen.

Ein Pentest zielt auf breite Abdeckung — so viele Schwachstellen wie möglich in einem abgegrenzten Ziel finden. Ein Red Team ist zielgetriebene Adversary Emulation: ein Ziel wählen (z. B. die wertvollsten Daten erreichen), die TTPs eines bestimmten Bedrohungsakteurs emulieren, verdeckt bleiben, um Detektion und Reaktion zu testen, und lautes Scanning vermeiden. Red Teaming misst das blaue Team und die ganze Organisation, nicht nur das Asset; beide brauchen strenge Rules of Engagement und Autorisierung.

Beginnen Sie damit, das Bedrohungsmodell der App zu verstehen und wo sie nicht vertrauenswürdige Eingaben, Geheimnisse, Authentifizierung und Autorisierung verarbeitet. Nutzen Sie SAST zum breiten Scannen und DAST gegen die laufende App, behandeln Sie die Tool-Ausgabe aber als Hinweise, nicht als Befunde — sortieren Sie False Positives aus. Verwenden Sie dann die menschliche Zeit auf die wertvollen, kontextabhängigen Bereiche, die Tools verpassen: Autorisierungslogik, Geschäftslogik, Krypto-Nutzung und Vertrauensgrenzen. Verfolgen Sie den Datenfluss von der Source bis zum Sink.

Man beginnt mit einem vollständigen TCP-Portscan und enumeriert dann jeden offenen Dienst gründlich — Banner, Versionen, Standardanmeldedaten, anonymer Zugriff und Webinhalte — bevor man irgendeinen Exploit anrührt. Die meisten Maschinen fallen durch gründliche Enumerierung, nicht durch clevere Exploits, was den Kern der „try harder“-Haltung ausmacht.

Der Standard-nmap-Scan deckt nur die 1000 häufigsten Ports ab, also würde ein Dienst auf einem hohen Port komplett übersehen. Das effiziente Muster ist zuerst ein schneller SYN-Scan aller 65535 Ports, dann ein fokussierter Versions- und Standardskript-Scan nur gegen die als offen gefundenen Ports.

Enumeriere systematisch: prüfe sudo -l, SUID/SGID-Binaries, Cronjobs, die Kernel- und OS-Version, beschreibbare Dateien in privilegierten Pfaden, Capabilities und gespeicherte Anmeldedaten. Werkzeuge wie LinPEAS automatisieren den Durchlauf, aber du verifizierst jede Erkenntnis weiterhin anhand von GTFOBins oder einer bekannten Technik.

Bestimme den genauen Dienst und die Version, suche auf Exploit-DB oder mit searchsploit nach einem passenden PoC und lies dann den Code Zeile für Zeile, bevor du ihn ausführst — korrigiere die Ziel-IP, den Port und die Reverse-Shell-Adresse, generiere jeglichen Shellcode neu und verstehe, was er tut, damit er sich nicht gegen dich wenden kann.

Bestimme zuerst das Hash-Format (hashid oder Kontext), führe dann hashcat oder John mit dem korrekten Modus gegen eine Wortliste wie rockyou aus und wende Regeln an, um Kandidaten zu mutieren. Nutze das richtige Format-Flag (NTLM, sha512crypt, NetNTLMv2 usw.), damit das Werkzeug die Versuche genauso hasht wie das Ziel.

Nutze den kompromittierten Host als Relais in das unerreichbare Subnetz. Richte eine Portweiterleitung für einen einzelnen Dienst ein oder einen dynamischen SOCKS-Proxy (SSH -D oder chisel) und leite deine Werkzeuge mit proxychains darüber, damit deine Angreifer-Maschine interne Hosts über den Pivot erreicht.

Bei SMB enumerierst du Freigaben, prüfst auf anonymen/Null-Session-Zugriff, listest Benutzer auf und bestimmst die Version für bekannte CVEs. Bei SNMP probierst du Standard-Community-Strings wie „public“ und gehst die MIB durch, um Benutzernamen, laufende Prozesse, installierte Software und Netzwerkdetails zu extrahieren.

Man startet ein Pseudoterminal (meist python -c 'import pty; pty.spawn("/bin/bash")'), legt es mit Ctrl-Z in den Hintergrund, führt lokal stty raw -echo aus, holt es wieder in den Vordergrund und setzt TERM sowie die Zeilen-/Spaltenzahl zurück. Das ergibt ein vollständiges TTY mit Jobsteuerung, Tab-Vervollständigung und funktionierenden Editoren.

Bestimme den Stack aus Headern und Quellcode, dann brute-force Verzeichnisse und Dateien mit gobuster oder feroxbuster unter Nutzung einer guten Wortliste und relevanter Endungen. Suche nach Admin-Panels, Backups, Konfigurationsdateien und Upload-Punkten und prüfe virtuelle Hosts, wenn die Seite auf einen Hostnamen reagiert.

Enumeriere die aktuellen Privilegien (whoami /priv), fehlkonfigurierte Dienste (schwache Berechtigungen, ungequotete Dienstpfade), AlwaysInstallElevated, geplante Aufgaben, gespeicherte Anmeldedaten und fehlende Patches. WinPEAS oder PowerUp automatisieren den Durchlauf; Token-Privilegien-Missbrauch wie SeImpersonate ist ein häufiger, wertvoller Treffer.

Einzeln legt SQLi Daten offen oder verändert sie und kann RCE erreichen; Stored XSS kapert Sitzungen im Browser der Opfer. Verkettet können Sie SQLi nutzen, um eine Stored-XSS-Payload zu platzieren, die in der Sitzung eines Admins ausgelöst wird, dessen Sitzung zu stehlen und zur vollständigen Anwendungskontrolle zu eskalieren.

Jeder authentifizierte Domänenbenutzer kann ein Kerberos-Service-Ticket (TGS) für jedes Konto mit einem SPN anfordern. Dieses Ticket ist mit dem NTLM-Passwort-Hash des Dienstkontos verschlüsselt, sodass Sie es extrahieren und das Passwort offline knacken — kein privilegierter Zugriff zu Beginn nötig, und es ist nahezu lautlos.

Passive Aufklärung sammelt Informationen, ohne direkt mit den Systemen des Ziels zu interagieren — OSINT, DNS-Einträge, Certificate Transparency. Aktive Aufklärung berührt das Ziel, etwa Portscans oder Banner-Grabbing, was lauter ist, aber mehr Details liefert.

Ein Pentest durchläuft Pre-Engagement (Scope und Einsatzregeln), Aufklärung, Scanning und Enumeration, Ausnutzung, Post-Exploitation und Reporting. Jede Phase speist die nächste, und im Reporting wird der Wert tatsächlich an den Kunden geliefert.

Pivoting verwandelt einen kompromittierten Host in ein Relais, damit Sie interne Segmente erreichen, zu denen Ihre Maschine nicht routen kann. Sie nutzen Port-Forwarding, einen SOCKS-Proxy über Ihren C2-Kanal (z. B. Chisel, SSH-Dynamic-Forwarding) oder agentenbasiertes Routing und führen dann Werkzeuge durch diesen Tunnel, um das nächste Subnetz anzugreifen.

Enumerieren Sie zuerst: aktuelle Rechte, sudo-Rechte, SUID/SGID-Binaries, Cron-Jobs, beschreibbare Dateien im PATH, Kernel-Version und gespeicherte Zugangsdaten. Nutzen Sie dann den einfachsten zuverlässigen Weg — oft eine fehlkonfigurierte sudo-Regel oder ein SUID-GTFOBin — bevor Sie zu einem Kernel-Exploit greifen.

Enumerieren Sie die Rechte des Kontos und die Fehlkonfigurationen des Hosts: Token-Privilegien wie SeImpersonate, Dienstpfade ohne Anführungszeichen, schwache Dienstberechtigungen, AlwaysInstallElevated und gespeicherte Zugangsdaten. Missbrauchen Sie dann das zuverlässigste — Token-Impersonation (Potato-Angriffe) ist ein gängiger Weg zu SYSTEM.

Eine Bind Shell öffnet einen lauschenden Port auf dem Ziel und wartet, dass Sie sich verbinden. Eine Reverse Shell lässt das Ziel ausgehend zu einem von Ihnen kontrollierten Listener verbinden. Reverse Shells gewinnen meist, weil ausgehender Verkehr eingehende Firewall-Regeln und NAT umgeht.

Ein guter Bericht bedient zwei Zielgruppen: eine Executive Summary, die das Geschäftsrisiko für die Führung einordnet, und detaillierte, reproduzierbare Funde mit Beweisen, präzisen Risikobewertungen und priorisierter Behebung für das technische Team. Der Bericht — nicht der Exploit — ist das Liefergut.

SQL-Injection erlaubt einer Angreifereingabe, eine Abfrage zu verändern. In-Band-Techniken geben Daten direkt zurück: Die UNION-basierte hängt ein UNION SELECT an, um zusätzliche Spalten zu ziehen, und die fehlerbasierte lässt Daten über Datenbank-Fehlermeldungen durchsickern. Wenn keine Ausgabe sichtbar ist, nutzen Angreifer blinde SQLi — die boolesche schließt Daten aus Unterschieden in Wahr/Falsch-Antworten, die zeitbasierte nutzt Verzögerungen wie SLEEP(), um Daten Bit für Bit zu lesen.