Interviewfragen für Penetration Tester

Gar nicht — kryptografische Hashes sind Einwegfunktionen ohne Inverse. Einen Hash zu „cracken“ heißt, Kandidaten-Eingaben zu raten, jede zu hashen und zu vergleichen (Wörterbuch, Brute Force, Rainbow Tables), und genau deshalb nutzt man langsame, gesalzene Hashes für Passwörter. Es gibt keinen Schlüssel, der einen Hash „entschlüsselt“. Wenn sich etwas entschlüsseln lässt, wurde es verschlüsselt, nicht gehasht — und Base64 ist umkehrbare Kodierung, kein Hashing.

Nein. Der ganze Bereich 127.0.0.0/8 ist für Loopback reserviert, also lösen 127.0.0.2, 127.1.1.1 und so weiter alle zum lokalen Host auf. Das ist wichtig für SSRF und das Umgehen von Allow-Lists — ein Angreifer kann 127.0.0.2 oder andere Kodierungen nutzen, um eine naive Prüfung „127.0.0.1 blockieren“ zu umgehen — und für das Binden mehrerer lokaler Dienste. (In IPv6 ist Loopback die einzelne Adresse ::1.)

Nein. Eine MAC wird vom Hersteller vergeben (OUI plus Geräte-ID) und ist „eingebrannt“, aber praktisch jedes Betriebssystem erlaubt es, sie per Software zu überschreiben (macchanger, ip link set address). MAC-Adressen sind also fälschbar und dürfen nicht zur Authentifizierung dienen — MAC-Filterung ist schwach, und Smartphones randomisieren die MAC inzwischen aus Datenschutzgründen. „Dauerhaft und eindeutig“ ist der Irrtum.

Nein. POST trägt die Parameter einfach im Anfrage-Body statt in der URL; dieser Body ist Klartext und für jeden, der den Verkehr sieht, voll sichtbar, sofern kein HTTPS genutzt wird. POST ist vorzuziehen für zustandsändernde Aktionen und hält Parameter aus URLs, Logs und Verlauf heraus, bietet aber für sich keine Vertraulichkeit. Der Irrtum verwechselt „nicht in der URL” mit „verschlüsselt” — nur TLS verschlüsselt die Daten beider Methoden bei der Übertragung.

Fangfrage — es gibt keinen einzelnen traceroute-Port. Das klassische Unix-traceroute sendet UDP-Datagramme an hohe, unwahrscheinliche Ports ab etwa 33434 mit steigendem TTL; Windows tracert nutzt stattdessen ICMP Echo. Es funktioniert, indem es die ICMP-Time-Exceeded-Nachrichten liest, die Router beim Ablauf des TTL zurücksenden, nicht durch das Anvisieren eines reservierten Ports. Und ICMP selbst hat überhaupt keine Ports.

Wenn ein Angreifer eine serverseitig ausführbare Datei (oder HTML/SVG) in ein ausgeliefertes Verzeichnis hochladen kann, kann er Remote Code Execution oder Stored-XSS erreichen. Validieren Sie den echten Inhaltstyp, speichern Sie Uploads außerhalb des Web-Roots oder in einem nicht ausführenden Speicher, randomisieren Sie Dateinamen und liefern Sie sie so aus, dass sie weder ausgeführt noch als Markup interpretiert werden. Langsamere Seitenladezeiten und Speicherplatz sind Betriebsfragen, nicht das hier ausgenutzte Sicherheitsrisiko.

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.

Social-Engineering-Tests müssen innerhalb vereinbarter, ethischer Vorwände bleiben: realistisch genug, um nützlich zu sein, aber ohne Nötigung, ohne das Vortäuschen von Behörden und ohne das Ausnutzen persönlicher oder medizinischer Situationen. Ein generisches IT-Passwort-Reset, das in den Rules of Engagement vereinbart ist, ist zulässig. Sich als krankes Kind eines echten Mitarbeiters auszugeben oder jemandem mit Kündigung zu drohen verursacht echten psychischen Schaden. Sich als Strafverfolgungsbehörde auszugeben täuscht eine Behörde vor und ist selbst mit unterschriebenem Auftrag oft illegal.

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.

Ein nützlicher Bericht treibt die Behebung an: nach Geschäftsrisiko (Wahrscheinlichkeit × Auswirkung) priorisieren, die Exploit-Ketten hervorheben, die zu kritischer Kompromittierung führen, und für jedes Finding umsetzbare Fixes geben. Alphabetische Sortierung begräbt das Wichtige unter dem, was zufällig mit „A" beginnt. Längster Text zuerst belohnt Wortfülle statt Schwere. Die niedrigen wegzulassen verbirgt echtes Risiko und die Muster, die der Kunde für Defense-in-Depth braucht, und hinterlässt ein falsch beruhigendes Bild.

IMDS ist ein link-lokaler Endpunkt (169.254.169.254), der einer Instanz ihre Metadaten liefert, einschließlich temporärer Anmeldedaten für ihre angehängte IAM-Rolle. SSRF kann den Server dazu bringen, diese URL abzurufen und diese Anmeldedaten zu leaken. IMDSv2 verlangt ein PUT, um ein kurzlebiges Session-Token zu erhalten, setzt ein standardmäßiges IP-TTL/Hop-Limit von 1 und lehnt Anfragen mit bestimmten Headern ab — sodass ein einfaches SSRF-GET es nicht mehr erreichen kann.

Die klassischen Fehler sind öffentliche ACLs oder Bucket-Richtlinien, die anonymen Zugriff oder Zugriff für alle AWS-Benutzer erlauben, zu weit gefasste Principals oder Wildcard-Aktionen, fehlende Standardverschlüsselung und fehlendes Logging. Man verhindert sie, indem man Block Public Access auf Kontoebene aktiviert, IAM-/Bucket-Richtlinien nach dem Prinzip der geringsten Rechte einsetzt, Standardverschlüsselung und TLS erzwingt und Zugriffs-Logging sowie Config-Regeln einschaltet, um Abweichungen zu erkennen.

RSA ist ein asymmetrischer Algorithmus, der Daten verschlüsselt oder digitale Signaturen mit einem Schlüsselpaar erstellt. Diffie-Hellman ist ein Schlüsselaustauschprotokoll, mit dem zwei Parteien über einen öffentlichen Kanal ein gemeinsames Geheimnis ableiten, ohne es je zu übertragen. Sie lösen verschiedene Probleme: RSA beweist Identität und kann Schlüssel einpacken; DH handelt einen Sitzungsschlüssel aus, und seine flüchtige Variante bietet Forward Secrecy.

Ein HMAC ist ein schlüsselbasierter Nachrichtenauthentifizierungscode: Er hasht die Nachricht zusammen mit einem geheimen Schlüssel über eine verschachtelte Konstruktion (innerer und äußerer Hash mit schlüsselabgeleiteten Pads). Er beweist sowohl Integrität (die Nachricht wurde nicht verändert) als auch Authentizität (sie stammt von jemandem mit dem Schlüssel). Ein einfacher Hash beweist keines von beiden, da ihn jeder neu berechnen kann; HMAC widersteht zudem Length-Extension-Angriffen.

Ein JWT besteht aus drei base64url-Teilen – Header, Payload (Claims) und Signatur – durch Punkte verbunden. Der Server signiert Header und Payload mit einem Geheimnis oder privaten Schlüssel und verifiziert diese Signatur bei jeder Anfrage, um den Claims ohne serverseitigen Sitzungszustand zu vertrauen. Fallstricke: alg=none akzeptieren, RS256-zu-HS256-Schlüsselverwechslung, Ablauf/Aussteller/Zielgruppe nicht zu validieren, Geheimnisse in die lesbare Payload zu legen und keinen Widerrufsweg zu haben.

Kerberos stützt sich auf ein vertrauenswürdiges Key Distribution Center (KDC). Der Client authentifiziert sich einmal beim Authentication Server und erhält ein mit dem Schlüssel des KDC verschlüsseltes Ticket-Granting-Ticket (TGT). Um einen Dienst zu erreichen, legt er das TGT dem Ticket-Granting-Service vor und erhält ein mit dem Schlüssel dieses Dienstes verschlüsseltes Service-Ticket. Der Dienst entschlüsselt es und vertraut ihm. Passwörter durchqueren nie das Netz, und Tickets sind zeitlich begrenzt.

Client und Server einigen sich in einem einzigen Roundtrip mittels ephemerem Diffie-Hellman (ECDHE) auf ein gemeinsames Geheimnis. Das ClientHello trägt die unterstützten Gruppen und einen Key Share; der Server antwortet mit seinem Key Share und Zertifikat, beide Seiten leiten dieselben Schlüssel ab, und Anwendungsdaten fließen sofort, mit Forward Secrecy als Standard.

Weder noch. ARP ist ein Layer-2-Protokoll (Sicherungsschicht), das direkt in einem Ethernet-Frame gekapselt wird und nicht in einem IP-Paket. Da es niemals über IP läuft, kann es weder TCP noch UDP verwenden — das sind Layer-4-Transporte, die IP darunter benötigen. Die Aufgabe von ARP besteht darin, eine bekannte IP-Adresse zur passenden MAC-Adresse im selben lokalen Netzsegment aufzulösen.

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.

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.

Fangfrage — ping verwendet keinen Port. Es läuft über ICMP, ein Layer-3-Protokoll, das direkt auf IP aufsitzt. Ports existieren nur in Layer-4-Protokollen wie TCP und UDP, daher hat ICMP (und somit ping) keinen. ICMP verwendet stattdessen Typ- und Code-Felder, z. B. Echo Request Typ 8 und Echo Reply Typ 0.

Drei. Der Client sendet ein SYN, der Server antwortet mit einem kombinierten SYN-ACK (ein Paket, das sowohl das SYN des Clients bestätigt als auch das eigene SYN des Servers sendet), und der Client schließt mit einem ACK ab. Der Trick ist, dass SYN-ACK ein einzelnes Paket ist, nicht zwei, sodass die Summe drei beträgt — genau das, was „Drei-Wege“ benennt.

Coordinated Vulnerability Disclosure ist ein Prozess, bei dem ein Forscher eine Schwachstelle privat an den Hersteller meldet, beide Seiten sich auf Behebung und Zeitplan einigen und Details erst veröffentlicht werden, sobald ein Fix verfügbar ist (oder eine vereinbarte Frist abläuft). Sie wägt die Zeit zum Patchen für Verteidiger gegen das Recht der Öffentlichkeit auf Information ab. Eine security.txt-Datei und eine klare Richtlinie machen das Melden reibungslos; Bug-Bounty-Programme fügen darauf strukturierte Belohnungen hinzu.

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.

Purple Teaming ist kollaborativ statt gegnerisch: Die rote Seite führt konkrete, vereinbarte TTPs aus (oft an MITRE ATT&CK ausgerichtet), während die blaue Seite ihre Telemetrie in Echtzeit beobachtet, um zu bestätigen, ob jede Technik geloggt, alarmiert und erkennbar ist. Sie messen die Detektionsabdeckung Technik für Technik, justieren Detektionen und schließen Lücken sofort, dann testen Sie erneut. Das Deliverable ist eine verbesserte, messbare Detektion — keine Liste, wer gewonnen hat.

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.

SSH nutzt TCP 22, HTTP TCP 80, HTTPS TCP 443, DNS den 53 (UDP und TCP), RDP TCP 3389 und SMB TCP 445. Die Well-Known-Ports zu kennen, erlaubt es, Scan-Ausgaben zu lesen, Firewall-Regeln zu schreiben und Alarme schnell zu triagieren — ein Dienst auf seinem erwarteten Port statt auf einem unerwarteten ist ein sofortiges Signal.

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 Schwachstellenscan ist eine automatisierte, in die Breite gehende Bestandsaufnahme potenzieller Schwächen, oft mit Fehlalarmen. Ein Penetrationstest ist menschengeführt: Er validiert Funde, verkettet sie und demonstriert durch tatsächliche Ausnutzung echte geschäftliche Auswirkungen.

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.

CSRF bringt den Browser eines angemeldeten Nutzers dazu, eine zustandsändernde Anfrage an eine Website zu senden, bei der er authentifiziert ist, und nutzt dabei aus, dass Cookies automatisch mitgesendet werden. Verhindert wird es mit Anti-CSRF-Tokens (ein geheimer Wert pro Sitzung, den der Angreifer weder lesen noch erraten kann) und dem SameSite-Cookie-Attribut, das verhindert, dass Cookies bei Cross-Site-Anfragen mitgeschickt werden.

Die OWASP Top 10 sind ein von der Community getragenes Bewusstseinsdokument, das die kritischsten Sicherheitsrisiken von Webanwendungen einstuft und alle paar Jahre auf Basis realer Daten aktualisiert wird. Es ist weder eine Checkliste noch ein Standard, sondern ein Ausgangspunkt — aktuelle Einträge sind unter anderem fehlerhafte Zugriffskontrolle (Nr. 1), kryptografische Fehler, Injection und unsicheres Design.

Prepared Statements senden zuerst die Abfragevorlage mit Platzhaltern an die Datenbank, sodass die Struktur feststeht, bevor irgendwelche Nutzerdaten eintreffen. Parameter werden danach als reine Daten gebunden und können niemals als SQL geparst werden — eine Eingabe wie ' OR 1=1 wird also als Zeichenkettenliteral behandelt, nicht als Code. Diese Trennung ist die kanonische, zuverlässige Lösung gegen Injection.

Die primäre Verteidigung ist kontextbezogene Ausgabecodierung — nicht vertrauenswürdige Daten genau für die Stelle codieren, an der sie landen (HTML-Körper, Attribut, JavaScript, URL). Kombiniere das mit sicheren DOM-APIs (textContent statt innerHTML), dem automatischen Escaping von Frameworks, Eingabevalidierung und einer Content-Security-Policy als Defense-in-Depth-Absicherung, die begrenzt, welche Skripte laufen dürfen.

Die Same-Origin Policy ist die Browser-Regel, dass ein Skript aus einem Origin (Schema + Host + Port) die Antworten eines anderen Origins nicht lesen kann, was authentifizierte Sitzungen schützt. CORS ist eine kontrollierte Lockerung: Ein Server gibt Access-Control-Allow-Origin-Header zurück, um bestimmten Origins ausdrücklich das Lesen seiner Antworten zu erlauben, und lockert so die SOP, statt sie zu umgehen.

HttpOnly verbirgt das Cookie vor JavaScript, sodass XSS es nicht über document.cookie stehlen kann. Secure stellt sicher, dass das Cookie nur über HTTPS gesendet wird, und blockiert das Abfangen im Netzwerk. SameSite steuert, ob das Cookie bei Cross-Site-Anfragen gesendet wird, und mildert CSRF ab. Zusammen härten sie Sitzungs-Cookies gegen die häufigsten Diebstahl- und Missbrauchswege.

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.

SSRF bringt einen Server dazu, HTTP- (oder andere) Anfragen an ein vom Angreifer gewähltes Ziel zu stellen, und missbraucht die Netzwerkposition des Servers, um interne Dienste hinter der Firewall zu erreichen. In der Cloud ist es besonders gravierend, weil der Instanz-Metadaten-Dienst (z. B. 169.254.169.254) IAM-Anmeldedaten zurückgeben kann und so ein SSRF zur Kompromittierung des Cloud-Kontos macht.

Jedes XSS schleust vom Angreifer kontrolliertes Skript in den Browser eines Opfers ein. Stored XSS speichert die Payload dauerhaft auf dem Server (z. B. einen Kommentar) und trifft jeden, der sie ansieht; Reflected XSS spiegelt die Payload in einer einzelnen Antwort vom Server zurück, meist über einen präparierten Link; DOM-basiertes XSS erreicht nie die Serverlogik — verwundbares clientseitiges JavaScript schreibt nicht vertrauenswürdige Eingaben in die Seite.

XXE missbraucht einen XML-Parser, der externe Entitäten auflöst, die in der DTD eines Dokuments definiert sind. Ein Angreifer deklariert eine Entität, die auf eine lokale Datei oder interne URL zeigt, und der Parser ruft sie ab — was Dateioffenlegung, SSRF und Dienstverweigerung ermöglicht. Die Lösung ist, DTD-Verarbeitung und externe Entitätsauflösung in der Parser-Konfiguration zu deaktivieren.