2026-07-15 · PRAXIS · Das Team von Offensive Technology

Warum jedes Engagement mit einer Unterschrift beginnt

Es gibt genau eine Sache, die einen Penetrationstest von einer Computerkriminalität unterscheidet, und das sind nicht Fähigkeiten, Tools oder Absichten. Es ist die Autorisierung. Derselbe Befehl, der gegen denselben Server ausgeführt wird, ist am Dienstag eine professionelle Dienstleistung und am Mittwoch eine Straftat, und der einzige Unterschied ist ein Stück Papier.

Bevor wir also irgendetwas anfassen, bringen wir diese Vereinbarung in Ordnung. Hier ist, was das in der Praxis tatsächlich bedeutet und warum wir darauf selbst dann nicht verzichten, wenn ein Kunde es eilig hat.

Eigentum vor Zugriff

Die erste Frage lautet nicht "Was möchten Sie testen lassen?", sondern "Können Sie nachweisen, dass Sie die Kontrolle darüber haben?". Jeder kann eine Domain in ein Formular eingeben. Das bedeutet nicht, dass sie ihm gehört, und falls nicht, bringt ein Test uns beide mit dem Gesetz in Konflikt.

Wir verifizieren das also. In der Regel bedeutet das, dass Sie ein Token in einem für uns auslesbaren DNS-Record platzieren oder von einer E-Mail-Adresse der Domain selbst bestätigen. Das dauert wenige Minuten und ist nicht verhandelbar. Wenn Sie die Kontrolle über das Ziel nicht nachweisen können, kommt kein Engagement zustande.

Wir verlassen uns auch nicht allein auf eine Unterschrift. Wir verlangen eine schriftliche Autorisierung von einer benannten Person und wollen dennoch den technischen Nachweis dahinter sehen. Denn eine Unterschrift auf dem falschen Briefkopf ist genau der Grund, warum ein Tester am Ende auf das falsche Ziel angesetzt wird.

Der Scope ist ein Zaun, keine Empfehlung

Sobald die Eigentumsverhältnisse geklärt sind, halten wir exakt fest, was im Scope liegt und was nicht: welche Hosts, welche Anwendungen, welche Techniken und welche explizit ausgeschlossen sind. Dieses Dokument ist der Zaun. Wir bleiben darin, selbst wenn direkt außerhalb etwas Interessantes klar erreichbar ist.

• Die Assets, die wir anfassen dürfen, namentlich aufgelistet.
• Die von Ihnen genehmigten Techniken sowie alle, die Sie ausgeschlossen haben.
• Zeitfenster, damit die Tests weder Ihr Team noch Ihre Kunden überraschen.
• Ein benannter Ansprechpartner, der das Ganze mit einer einzigen Nachricht stoppen kann.

Dasselbe Dokument regelt zwei Dinge, die man gerne vergisst, bis sie wichtig werden. Erstens die Umgebung: Testen wir die Produktion, wo ein schwerer Request echte Kunden beeinträchtigen kann, oder eine gespiegelte Staging-Umgebung? Beide Optionen sind valide, aber die Entscheidung muss bewusst getroffen und nicht erst mitten im Test entdeckt werden. Zweitens die Abbruchbedingung: Wer kann den Test stoppen, wie erreicht er uns und was passiert mit bereits erlangtem Zugriff, falls das geschieht? Dies ist eine unterzeichnete Pre-Engagement-Vereinbarung, kein unverbindliches Verständnis. Wenn sie gut gemacht ist, muss niemand unter Druck improvisieren.

Wenn das Ziel nicht vollständig Ihnen gehört

Eine Domain zu besitzen bedeutet nicht, dass einem auch alles gehört, worauf sie verweist. Genau hier laufen gut gemeinte Scopes schief. Ein typisches Beispiel: Ein Kunde listet app.clientco.com als im Scope auf. Wir prüfen das und stellen fest, dass es ein CNAME auf eine Drittanbieter-SaaS-Plattform ist, die der Kunde zwar nutzt, aber nicht betreibt. Er kontrolliert den DNS-Namen, nicht jedoch die Server dahinter. Das Testen dieses Hosts bedeutet das Testen des Anbieters, der keinerlei Zustimmung gegeben hat. Er fällt also aus dem Scope heraus, oder der Kunde holt zuerst die schriftliche Genehmigung des Anbieters ein.

Die gleiche Vorsicht gilt für Assets auf Shared Hosting oder hinter einem Shared CDN, wo eine einzige IP-Adresse Tausende unbeteiligter Mandanten bedienen kann, sowie für eine im Rahmen eines Deals erworbene Domain, deren Records noch auf die Infrastruktur des Verkäufers verweisen. Große Cloud-Anbieter veröffentlichen ebenfalls eigene Richtlinien für zulässige Tests, und bestimmte Aktivitäten, insbesondere Denial-of-Service- und Stresstests, erfordern selbst auf eigenen Ressourcen eine vorherige Ankündigung oder Genehmigung. Es zu entwirren, was Ihnen wirklich gehört, ist Teil des Mappings der externen Angriffsfläche, und das geschieht vor jedem Test, nicht währenddessen.

Das Gesetz hinter der Grenze

Der Grund, warum wir hier unnachgiebig sind, ist keine interne Richtlinie. Die meisten Länder behandeln den unbefugten Zugriff auf ein Computersystem als eigenständige Straftat. In den USA ist es der Computer Fraud and Abuse Act, im Vereinigten Königreich der Computer Misuse Act 1990, und in der gesamten Europäischen Union stellen die Mitgliedstaaten den illegalen Zugang auf Grundlage nationaler Gesetze zur Umsetzung der EU-Richtlinie über Angriffe auf Informationssysteme unter Strafe. Die Einzelheiten variieren je nach Rechtsraum, aber die Kernaussage ist dieselbe: Der Zugriff ohne Erlaubnis des Eigentümers ist die Straftat, und eine gute Absicht schützt nicht vor Strafe. Dies ist keine Rechtsberatung, und Ihr eigener Anwalt ist die richtige Person, um die für Sie geltenden Gesetze zu prüfen. Es erklärt schlichtweg, warum kein einziger Request rausgeht, bevor Autorisierung und Eigentum geklärt sind.

Warum wir beim bürokratischen Teil so streng sind

Kunden nehmen dies manchmal als Bürokratie wahr. Es ist das genaue Gegenteil. Eine klare Autorisierung erlaubt es uns, innerhalb des Zauns aggressiv vorzugehen, ohne dass sich eine der beiden Seiten Sorgen machen muss. Wenn die Grenzen schriftlich fixiert und unterzeichnet sind, können wir Angriffe konsequent verketten und reale Auswirkungen nachweisen, weil sich alle vorher darauf geeinigt haben, wo die Grenzen verlaufen.

Die Teams, die auf die Nase fallen, sind diejenigen, die den Scope als reine Formalität betrachtet haben. Wir betrachten ihn als das Fundament, denn genau das ist er.

Autorisierung zuerst: Kurze Antworten

Benötige ich eine schriftliche Autorisierung, um Systeme zu testen, die mir bereits gehören?

In der Praxis: ja. Eine schriftliche Autorisierung weist nach, dass Ihr eigenes Team den Test genehmigt hat. Das schützt Sie intern und sichert den ausführenden Pentester ab. Falls ein Teil der Umgebung auf einer Infrastruktur liegt, die Sie nicht vollständig kontrollieren, wie etwa eine Cloud-Plattform oder ein gehostetes SaaS-Produkt, benötigen Sie möglicherweise auch die Genehmigung dieses Anbieters. Holen Sie alles schriftlich ein, bevor irgendetwas ausgeführt wird.

Was ist ein Rules-of-Engagement-Dokument?

Es ist die schriftliche Vereinbarung, die den Test definiert: die genauen Ziele im Scope, die erlaubten und verbotenen Techniken, das Testfenster, die benannten Ansprechpartner auf beiden Seiten und die Bedingungen für einen Testabbruch. Es verwandelt ein vages "Testet uns mal" in eine verbindliche Grundlage für beide Seiten.

Ist es illegal, eine Website zu scannen, die mir nicht gehört?

Das kann es sein. Viele Rechtsordnungen stellen den unbefugten Zugriff auf Computersysteme unter Strafe, und die Grenze zwischen einem Scan und einem Zugriff liegt nicht immer dort, wo man sie vermutet. Ohne Autorisierung und den Nachweis, dass Sie das Ziel kontrollieren, sollten Sie keinerlei Werkzeuge darauf ansetzen. Dies ist keine Rechtsberatung; konsultieren Sie einen qualifizierten Anwalt für Ihre Rechtsordnung.

Wie überprüfen Sie, ob mir ein Ziel gehört, bevor Sie es testen?

In der Regel durch einen Record, den Sie im DNS des Ziels veröffentlichen, oder eine Antwort von einem Postfach der Domain selbst. Beides belegt die Kontrolle auf eine Weise, wie es ein Webformular nicht kann. Solange dieser Check nicht bestanden ist, kommt kein Engagement zustande.

Weiterführende Artikel

• Check, Scan oder vollständiger Pentest?
• So bereiten Sie sich auf Ihren ersten Penetrationstest vor
• Was OSCP, OSEP und CRTO tatsächlich beweisen