DEF
DEF
Von außen wie ein Fremder.
Wir greifen Ihre Systeme kontrolliert an: von außen wie ein Unbekannter, von innen wie ein Mitarbeiter, dessen Zugang bereits in falschen Händen ist.
- Die Frage, die beantwortet wirdWas erreicht jemand, der von außen angreift - und was jemand, der bereits im Netz sitzt?
- Warum das zähltEin Schwachstellenscan meldet Theorie. Ein Pentest zeigt, welche Funde sich tatsächlich verketten lassen und wie weit sie führen.
- Was Sie danach habenJeden Fund mit nachvollziehbarem Reproduktionsweg, CVSS-Score, Management-Zusammenfassung und Re-Test.
Ein beauftragter Angriff auf Ihre eigenen Systeme. Wir suchen Schwachstellen und nutzen sie kontrolliert aus, um zu zeigen, wie weit jemand damit käme. Der Unterschied zum echten Angriff: Sie wissen davon, es ist schriftlich geregelt, und wir zerstören nichts.
Ein Scan ist eine automatische Liste möglicher Probleme – oft mit vielen Fehlalarmen. Ein Pentest prüft von Hand nach, was davon tatsächlich ausnutzbar ist. Ein Scan sagt „diese Tür könnte offen sein", ein Pentest geht hindurch.
Das beschreibt, wie viel wir vorher von Ihnen bekommen: nichts, einen normalen Benutzerzugang oder vollen Einblick. Welche Variante sinnvoll ist, hängt von Ihrer Frage ab – wir erklären das ausführlich auf der Grundlagenseite.
Eine international einheitliche Punkteskala von 0 bis 10 für die Schwere einer Schwachstelle. Damit ist „kritisch" nicht unsere Meinung, sondern eine nachvollziehbare Einstufung, die auch Ihre Versicherung oder Ihr Auditor kennt.
Die Nummer einer öffentlich bekannten Schwachstelle, etwa CVE-2024-1234. Öffentlich bekannt heißt: Es gibt eine Beschreibung, meist ein fertiges Angriffswerkzeug und fast immer ein Update, das die Lücke schließt. Systeme mit offenen CVEs werden nicht gezielt gesucht – sie werden automatisiert gefunden, oft innerhalb von Stunden nach der Veröffentlichung.
Der Schritt von „ich bin drin" zu „ich darf alles". Ein Angreifer landet fast nie sofort mit vollen Rechten im Netz, sondern auf einem gewöhnlichen Arbeitsplatzkonto. Interessant ist, wie viele Schritte von dort bis zum Administrator nötig sind – bei guter Trennung sind es viele, bei gewachsener Struktur oft zwei.
Von außen wie ein Fremder.
Ein Schwachstellenscan sagt Ihnen, was theoretisch offen ist. Ein Pentest sagt Ihnen, was davon jemand tatsächlich ausnutzen kann und wie weit er damit kommt. Wir liefern das Zweite.
- Technischer Bericht mit Reproduktionswegen
- Management-Zusammenfassung
- Priorisierte Maßnahmenliste
- Re-Test nach Umsetzung
Wie wir dabei arbeiten.
Scope
Ziele, Systeme, Zeitfenster und Ausschlüsse werden schriftlich festgelegt.
Aufklärung
Passive Recherche, danach aktive Erfassung der erreichbaren Angriffsfläche.
Ausnutzung
Kontrolliert und nachvollziehbar. Kein Test, der Ihren Betrieb gefährdet, ohne Absprache.
Bericht
Jeder Fund mit Reproduktionsweg, CVSS-Score und Maßnahme.
Wie das konkret aussieht.
Kein Verkaufstext, sondern das, was wir tatsächlich tun - mit den Techniken und Werkzeugen dahinter.
Extern: die Angriffsfläche, die Sie nicht kennen
Bei fast jeder Prüfung finden wir mindestens ein erreichbares System, von dem im Unternehmen niemand mehr wusste.
Der externe Test beginnt mit der Erfassung Ihrer tatsächlichen Angriffsfläche - und die ist meist größer als die bekannte Hauptdomain: Subdomains aus Certificate-Transparency-Logs, vergessene Staging-Systeme, Mailserver, VPN-Gateways und alles, was über Shodan oder Censys ohnehin bereits indiziert ist.
Anschließend prüfen wir jeden erreichbaren Dienst gezielt: veraltete Softwarestände mit bekannten CVEs, schwache Transportverschlüsselung, offene Administrationsoberflächen, Standardzugangsdaten und Konten ohne Zwei-Faktor-Anmeldung. Bei Webanwendungen folgen wir dem OWASP Testing Guide.
Ein eigener Block ist die E-Mail-Sicherheit. Wir prüfen, ob SPF, DKIM und DMARC so gesetzt sind, dass eine gefälschte Nachricht in Ihrem Namen tatsächlich abgewiesen wird. In der Praxis stehen die Einträge oft da, aber im Beobachtungsmodus – gefälschte Mails werden dann zwar gemeldet, aber trotzdem zugestellt. Für Betrugsmaschen wie den gefälschten Zahlungsauftrag ist das der entscheidende Unterschied.
Nicht alles, was technisch möglich ist, gehört in einen Test. Lastangriffe, die einen Dienst absichtlich lahmlegen, führen wir nicht durch. Bei Anmeldemasken arbeiten wir mit Bedacht, damit wir nicht reihenweise echte Benutzerkonten sperren und damit selbst einen Ausfall verursachen. Was ausgeschlossen bleibt, steht vorher in den Rules of Engagement – und zwar so konkret, dass es im Nachhinein keine Diskussion gibt.
Intern: der Weg zum Domänen-Administrator
Die Frage ist nicht, ob jemand ins Netz kommt. Die Frage ist, wie weit er von dort aus kommt.
Der interne Test geht von einem realistischen Ausgangspunkt aus: Ein Angreifer sitzt bereits im Netz - über eine Phishing-Mail, ein kompromittiertes Notebook oder eine offene Netzwerkdose.
In Active-Directory-Umgebungen prüfen wir die üblichen Eskalationspfade: Kerberoasting gegen Dienstkonten mit schwachen Passwörtern, AS-REP-Roasting bei Konten ohne Preauthentifizierung, unsichere ACL-Vererbungen, LLMNR- und NBT-NS-Vergiftung zur Erfassung von Hashes sowie Passwort-Wiederverwendung zwischen lokalen Administratorkonten.
Bevor es um Active Directory geht, prüfen wir das Netz selbst. Veraltete Namensauflösungsdienste wie LLMNR und NetBIOS beantworten Anfragen, die eigentlich ins Leere laufen sollten – ein Angreifer im selben Netz kann sich dazwischenschalten und Anmeldedaten abgreifen. Fehlt zusätzlich die SMB-Signierung, lassen sich diese Daten direkt weiterreichen. Beides sind Voreinstellungen aus einer anderen Zeit, die in vielen gewachsenen Netzen bis heute aktiv sind.
Ein wiederkehrender Fund sind Kennwörter, die überall gleich sind. Wenn das lokale Administratorkennwort auf jedem Arbeitsplatz identisch ist, genügt ein einziger kompromittierter Rechner, um auf allen anderen zu landen. Microsoft löst das mit LAPS, das für jedes Gerät ein eigenes, automatisch wechselndes Kennwort verwaltet. Wir prüfen, ob es im Einsatz ist – und ob wirklich alle Geräte erfasst sind oder nur die, die beim Einführen gerade liefen.
Technische Vertiefung
Ebenso relevant ist die Netzsegmentierung: Erreicht ein Arbeitsplatz im Bürobereich tatsächlich die Produktionssteuerung, die Kameraanlage oder die Verwaltungsserver? Häufig ist eine Trennung zwar geplant, in der Firewall-Regel aber durch eine historische Ausnahme wieder aufgehoben.
WLAN, Cloud und die Frage der Freigabe
Cloud-Tests haben eine Besonderheit: Nicht alles, was technisch geht, ist vertraglich erlaubt.
Beim WLAN prüfen wir die Authentifizierung. WPA2-PSK mit einem seit Jahren unveränderten Schlüssel ist in kleineren Betrieben der Regelfall. Bei WPA2-Enterprise achten wir darauf, ob Clients das Serverzertifikat wirklich validieren - andernfalls lässt sich mit einem nachgebauten Zugangspunkt der Anmeldeversuch abfangen. Gastnetze prüfen wir auf tatsächliche Trennung.
Azure, AWS und Microsoft 365 gehören zum Umfang, wenn sie Teil Ihrer Infrastruktur sind. Hier gelten die Nutzungsbedingungen des Anbieters: Manche Testarten sind ohne Voranmeldung zulässig, andere nicht. Wir klären das vorab und halten es in den Rules of Engagement fest.
Beim Gastnetz interessiert uns weniger die Verschlüsselung als die Trennung. Ein Gastzugang, der auf denselben Router zeigt und von dort das interne Netz erreicht, ist kein Gastnetz, sondern ein zweiter Name für dasselbe Netz. Ebenso prüfen wir, ob Geräte im Gastnetz einander sehen – in Wartebereichen, Studios und Schulen ist das der Normalfall und selten beabsichtigt.
In der Cloud verschiebt sich die Prüfung von Servern zu Identitäten und Berechtigungen. Typische Funde: App-Registrierungen mit weit mehr Rechten, als die Anwendung braucht, Zugriffstoken ohne Ablauf, Administratorrollen, die jemand für eine einmalige Aufgabe bekommen und nie wieder abgegeben hat, und Conditional-Access-Regeln mit so vielen Ausnahmen, dass die Regel faktisch nicht mehr greift. Nichts davon erzeugt einen Alarm – es fällt nur auf, wenn jemand gezielt nachsieht.
Was drin ist - und was ausdrücklich nicht.
Damit Sie vor der Beauftragung wissen, worauf Sie sich einlassen. Der genaue Zuschnitt entsteht im Erstgespräch.
Typischer Umfang
Ein klar abgegrenztes Ziel: eine Web-Anwendung, ein externer Perimeter oder ein internes Netzsegment. Kombinationen sind möglich, werden aber getrennt kalkuliert.
Dauer
Je nach Größe drei bis zehn Testtage. Der Bericht folgt innerhalb einer Woche nach Testende, kritische Funde erhalten Sie sofort im Portal.
Voraussetzung
Beauftragung, Rules of Engagement und - bei Cloud-Diensten - die Bestätigung, dass der jeweilige Anbieter den Test zulässt.
Nicht enthalten
Kein Denial-of-Service, keine Tests gegen Produktivsysteme ohne ausdrückliche Freigabe, keine Angriffe auf Systeme Dritter.
Ein Pentest ist eine Momentaufnahme. Er ersetzt weder ein laufendes Schwachstellenmanagement noch regelmäßiges Patchen - er zeigt, was ein Angreifer heute erreichen würde.
Was Kunden vorher wissen wollen.
Nein. Aggressive Tests, die einen Ausfall riskieren, stimmen wir vorher ausdrücklich ab. Der Normalfall ist ein kontrollierter Test im laufenden Betrieb.
Kommt auf die Frage an. Black-Box zeigt, was ein Außenstehender ohne Vorwissen erreicht. White-Box findet in der gleichen Zeit mehr, weil wir nicht erst suchen müssen, was Sie ohnehin schon wissen.
Ja - Azure, AWS und Microsoft 365 gehören zum Standardumfang, wenn sie Teil Ihrer Infrastruktur sind. Wir sagen vorab, was der jeweilige Cloud-Anbieter in seinen Nutzungsbedingungen ohne Voranmeldung erlaubt.
Ja, auf Wunsch. Standardmäßig liefern wir den aufbereiteten Bericht im Portal; Scan-Ausgaben und Beweise können Sie zusätzlich als Rohdaten herunterladen.
Ein externer Test einer überschaubaren Angriffsfläche ist in drei bis fünf Tagen erledigt, ein interner Test mit Active Directory eher in einer bis zwei Wochen. Dazu kommen Vorbereitung und Bericht. Realistisch liegen zwischen Beauftragung und Abschlussbericht vier bis sechs Wochen – die Findings sehen Sie allerdings ab dem ersten Tag im Portal und nicht erst am Ende.
Die dürfen wir nur mit dessen Wissen prüfen. Betreibt jemand anderer Ihren Server, Ihren Shop oder Ihre Telefonanlage, brauchen wir eine Freigabe dieses Anbieters – sonst prüfen wir fremde Infrastruktur ohne Auftrag. Wir sagen Ihnen vorab, welche Zustimmungen nötig sind, und formulieren die Anfrage auf Wunsch mit.
Was oft dazugehört.
Wir stehen im Serverraum.
Wir verschaffen uns Zutritt zu Ihrem Gebäude - mit denselben Mitteln wie ein echter Angreifer, aber mit Ihrer Unterschrift in der Tasche und einem Foto als Beleg.
Was ohnehin schon offenliegt.
Wir tragen zusammen, was über Ihr Unternehmen frei auffindbar ist, bevor es jemand anderer tut. Vollständig passiv - Ihre Systeme fassen wir dabei nicht an.
Der Moment der Entscheidung.
Technik lässt sich patchen, Menschen nicht. Wir trainieren die Entscheidung im Moment des Angriffs - messbar, wiederholbar und ohne jemanden vorzuführen.
Läuft es gerade schief? Dann rufen Sie an, nicht später.
Eine Lösegeldforderung am Bildschirm, ein Postfach, das plötzlich weiterleitet, ein Zugang, den niemand angelegt hat: In den ersten Stunden entscheidet sich, wie teuer der Vorfall wird.
Damit Sie wissen, woran Sie sind: DEF.S3C betreibt kein 24/7-SOC und keine dauerhafte Überwachung. Wir leisten Erstreaktion und Aufarbeitung innerhalb vereinbarter Zeitfenster.