Penetrationstests mit von Hand validierten Befunden.
Ein Penetrationstest, den Menschen durchführen — mit manueller Ausnutzung, und jeder Befund wird reproduziert, bevor er in den Bericht kommt. Ziel ist nicht, aufzulisten, was verwundbar aussieht, sondern zu zeigen, was ein Angreifer mit dem anstellen kann, was heute exponiert ist.
Was ein Pentest beantwortet und ein Scanner nicht
Ein automatisches Werkzeug zeigt, was verwundbar aussieht. Ein Penetrationstest zeigt, was tatsächlich ausnutzbar ist und wie weit der Zugriff reicht. Der Unterschied entsteht durch Verkettung: Eine Autorisierungslücke, die für sich genommen als niedrig gälte, wird kritisch, sobald sie zu Daten führt, die dieser Nutzer nie berühren dürfte. Diesen Pfad baut kein Werkzeug allein — und es ist der Pfad, nicht die Einstufung, der die Priorität der Behebung verändert.
- Jeder Befund wird von Hand reproduziert, bevor er in den Bericht kommt: Rohausgabe eines Werkzeugs ist kein Ergebnis.
- Das Risiko wird über die Auswirkung auf Ihr Geschäft beschrieben, nicht allein über den generischen Wert einer öffentlichen Datenbank.
- Falschmeldungen erreichen Sie nicht — was wir nicht reproduzieren konnten, bleibt draußen.
- Der Ausnutzungspfad ist Schritt für Schritt dokumentiert, damit Ihr Team ihn nachvollziehen und die Behebung bestätigen kann.
What's included
Der folgende Umfang ist der Standard für ein typisches Engagement. Alles lässt sich im Scoping anpassen, kostenfrei.
- Authentifizierung, Sitzung und Passwortwiederherstellung
- Horizontale und vertikale Autorisierung je Objekt
- Injektion in Abfragen, Befehle und Vorlagen
- Geschäftslogik und umgehbare Abläufe
- Datei-Upload, -Verarbeitung und -Auslieferung
- Konfiguration von Headern, Cookies und CORS
- Aufzählbarkeit von Ressourcen und vorhersehbare Kennungen
- Zugriffskontrolle zwischen Konten und Mandanten
- Schemavalidierung und unerwartete Datentypen
- Grenzen für Rate, Kosten und automatisierten Missbrauch
- Authentifizierung zwischen Diensten und Rotation von Geheimnissen
- Übermäßige Datenpreisgabe in der Antwort
- Exponierte Randfläche und vergessene Dienste
- Versionen ohne Support und offene Patches
- Segmentierung zwischen Umgebungen und Netzen
- Vom Perimeter erreichbare interne Dienste
- TLS-Konfiguration und Datenverkehrsterminierung
- Laterale Bewegung ab einem Erstzugriff
- Identitätsanbieter und Föderationsabläufe
- Zweiter Faktor: Abdeckung, Umgehung und Wiederherstellung
- Geerbte Rechte und Rechteanhäufung
- Dienstkonten und Zugangsdaten im Code
- Sitzungen auf mehreren Geräten und Widerruf
- Registrierung und Onboarding neuer Nutzer
- Android- und iOS-Apps, einschließlich lokaler Speicherung
- Kommunikation der App mit der API und Zertifikatsbindung
- Manipulationsschutz und Verhalten auf einem kompromittierten Gerät
- Unternehmens-WLAN, Gästenetz und die Trennung dazwischen
- Lokale Infrastruktur und was sie in der Cloud erreicht
- Kioske, Terminals und gemeinsam genutzte Geräte
- Injektion: SQL, NoSQL, LDAP, Befehle und Vorlagen
- Authentifizierung, Autorisierung, IDOR und Rechteausweitung
- SSRF, XXE und unsichere Deserialisierung
- Fehler in Geschäftslogik und Zahlungsablauf
- XSS, CSRF und Clickjacking mit nachgewiesener Wirkung
- Schwache Kryptografie, vorhersehbare Token und fragile JWT
Modalities
adjustable to scopeBlackbox
Wir starten ohne privilegierte Informationen, in derselben Lage wie ein Angreifer von außen. Das misst, was Ihre Angriffsfläche einem Fremden preisgibt, und bringt regelmäßig Systeme zutage, von deren Exposition niemand wusste.
Greybox
Wir erhalten Zugangsdaten und einen Architekturüberblick. Diese Variante deckt in derselben Zeit die größte Fläche ab, weil der Aufwand in die Ausnutzung statt in die Aufklärung fließt — und hier zeigen sich Autorisierungsfehler.
Whitebox
Zugang zu Code, Konfiguration und Dokumentation. So werden Pfade erreichbar, die von außen selten sichtbar sind: Wettlaufsituationen, Fehlerbehandlung und sensible Logik unter mehreren Schichten.
Wann sich ein Pentest besonders lohnt
Das ist keine jährliche Pflichtübung. Es gibt Momente, in denen der Test mehr zurückgibt, als er kostet — weil sich die Angriffsfläche verändert hat oder weil jemand von außen gleich nachfragen wird.
Eine Neuentwicklung, ein neuer Identitätsanbieter oder eine Migration verschieben Annahmen, die niemand erneut prüft. Vorher zu testen ist günstiger, als es hinterher unter Echtlast zu entdecken.
Konzernverträge, Sicherheitsfragebögen und Beschaffungsprozesse verlangen regelmäßig einen unabhängigen Test. Der Bericht beantwortet das sachlich, ohne auf Selbstauskunft angewiesen zu sein.
Neues Team, neuer Dienst, neue Integration. Schnelles Wachstum erzeugt Fläche, die niemand vollständig kartiert hat, und Rechte, die vorübergehend vergeben und nie zurückgenommen wurden.
Alte interne Systeme, Verwaltungsoberflächen und Alt-Integrationen bleiben jahrelang außerhalb jedes Prüfumfangs — gerade weil sie als zu intern gelten, um zu beunruhigen.
How we conduct it
[pipeline]Umfang und Einsatzregeln
Bevor ein einziges Paket losgeht, halten wir schriftlich fest, was im Umfang liegt, was nicht, welche Zeitfenster erlaubt sind und wer benachrichtigt wird, wenn etwas vom Plan abweicht. Ebenso vereinbaren wir das Abbruchkriterium für kritische Befunde, damit ein schwerwiegender Fund Sie noch am selben Tag erreicht.
Aufklärung und Kartierung
Wir erfassen die tatsächliche Angriffsfläche: Domains, Subdomains, exponierte Dienste, Technologien, Einstiegspunkte und alles, was über die Umgebung bereits öffentlich ist. In dieser Phase tauchen Systeme außerhalb des Inventars auf — eine erreichbare Testumgebung, ein vergessenes Panel, ein für einen Versuch gestarteter Dienst, der nie abgeschaltet wurde.
Scan und Sichtung
Automatisierung gehört hierher, und nur hierher: Sie deckt Menge ab und liefert Kandidaten. Jedes Ergebnis durchläuft eine manuelle Sichtung, denn das meiste, was ein Werkzeug meldet, hält der Reproduktion nicht stand. Was übrig bleibt, wird zur Ausnutzungshypothese.
Manuelle Ausnutzung
Hier trennt sich der Test vom Scan. Wir verketten Schwachstellen, prüfen Geschäftslogik, versuchen Rechteausweitung und den Zugriff auf geschützte Daten — stets innerhalb der vereinbarten Regeln und ohne die Verfügbarkeit der Produktion anzutasten.
Nachnutzung und Reichweite
Die Tür zu finden genügt nicht: Es zählt, wohin sie führt. Wir messen die Reichweite eines Erstzugriffs, was sich davon lesen, ändern oder verstetigen lässt und ob ein weiteres System erreichbar wird. Diese Messung macht aus einer technischen Einstufung ein Geschäftsrisiko.
Bericht und Nachtest
Der Bericht enthält den reproduzierbaren Pfad, die Auswirkung und die empfohlene Behebung, wobei der Teil für die Leitung vom technischen Detail getrennt bleibt. Nach der Behebung testen wir die bearbeiteten Punkte erneut und halten fest, was geschlossen wurde — denn ein behobener Befund zählt erst, wenn jemand das bestätigt.
Öffentliche Referenzen hinter der Arbeit
Wir arbeiten auf offenen, anerkannten Methodiken. Das macht den Umfang zwischen Anbietern vergleichbar und erlaubt Ihrer Revision, die Abdeckung zu prüfen, ohne uns glauben zu müssen.
- OWASP WSTG
- Der OWASP-Leitfaden für Webanwendungstests gliedert die Abdeckung nach Kategorien — Authentifizierung, Sitzung, Autorisierung, Validierung, Geschäftslogik — und bildet die Grundlage, um Geprüftes nachzuweisen.
- OWASP API Security
- Die API-Risikoliste deckt ab, was klassische Webtests schlecht erfassen: Autorisierung auf Objektebene, übermäßige Datenpreisgabe und unbegrenzter Verbrauch.
- PTES
- Der Penetration Testing Execution Standard beschreibt die Phasen eines Tests, vom Vorgespräch bis zum Bericht, und bildet das Rückgrat des oben beschriebenen Ablaufs.
- MITRE ATT&CK
- Der Katalog gegnerischer Taktiken und Techniken benennt das Ausgeführte, sodass Ihr Verteidigungsteam jeden Schritt mit dem abgleichen kann, was die Erkennung gesehen — oder übersehen — hat.
- NIST SP 800-115
- Der technische NIST-Leitfaden zur Sicherheitsbewertung definiert Planung, Durchführung und Nachbereitung und ist die in Vertragsanforderungen meistzitierte Referenz.
- CVSS
- Die Bewertung vereinheitlicht die technische Schwere, geht aber nur als Eingangsgröße ein: Priorisiert wird nach der Auswirkung in Ihrem Kontext, im Klartext neben der Zahl beschrieben.
Deliverables
dual view · NDAZusammenfassung für die Leitung
Eine kurze Lesefassung für alle, die Budget und Priorität verantworten: was geprüft wurde, was echtes Risiko darstellt und wo eine Entscheidung nötig ist. Ohne Fachjargon, damit sie im Vorstand trägt.
Befunde mit vollständiger Reproduktion
Jeder Punkt enthält den Weg Schritt für Schritt, mit Anfrage, Antwort und Nachweis. Entwicklerinnen und Entwickler können ihn nachvollziehen, ohne nachzufragen und ohne auf die Testenden angewiesen zu sein.
Bewertung von Auswirkung und Priorität
Technische Schwere und Geschäftsauswirkung stehen getrennt, weil sie nicht immer zusammenfallen. Die vorgeschlagene Reihenfolge berücksichtigt den Behebungsaufwand, damit das Team nicht mit dem Teuersten und am wenigsten Dringenden beginnt.
Konkrete Behebungsempfehlung
Hinweise, die auf Ihren Code und Ihre Architektur zugeschnitten sind, kein aus der Dokumentation kopierter Absatz. Wo mehrere Wege bestehen, beschreibt der Bericht den jeweiligen Kompromiss.
Abgleich mit Ihrer Überwachung
Eine nach Technik gegliederte Übersicht des Durchgeführten, damit Ihr Erkennungsteam sie mit dem vergleichen kann, was Protokolle und Alarme erfasst haben. Sie zeigt oft ebenso viel wie die Schwachstellenliste.
Nachtest und Abschlussschreiben
Nach der Behebung prüfen wir die bearbeiteten Punkte erneut und halten den Endzustand fest. Das Schreiben dient Kunden, Partnern und Prüfern, die einen Nachweis über den geschlossenen Zyklus brauchen.
Frequently asked
Standardmäßig testen wir keine Verfügbarkeit. Denial of Service und jede Handlung mit hohem Risiko bleiben außerhalb des Umfangs, sofern nicht ausdrücklich mit vereinbartem Zeitfenster gewünscht. Könnte ein Test die Produktion treffen, verlagern wir ihn in eine gleichwertige Umgebung oder führen ihn im vereinbarten Fenster durch, mit durchgehend offener direkter Leitung.
Einen definierten Umfang, Testzugänge für jede Nutzerrolle und eine erreichbare technische Ansprechperson. Falls ein Schutz am Rand den Test blockieren könnte, entscheiden wir gemeinsam, ob er im Umfang liegt oder eine Ausnahme erhält: Den Schutz zu testen und die Anwendung zu testen sind verschiedene Ziele.
Der Scan vergleicht Gefundenes mit einer bekannten Datenbank und liefert eine Liste. Der Pentest versucht die Ausnutzung, verkettet Schwachstellen und misst die Reichweite des Zugriffs. Scannen ist günstig und taugt zur laufenden Beobachtung; der manuelle Test beantwortet, was die Liste nicht beantwortet — ob der Punkt in Ihrem Kontext ausnutzbar ist.
Ja. Die Zusammenfassung ist für nichttechnische Leser geschrieben und kann an Kunde, Partner oder Prüfer weitergegeben werden. Das technische Detail steht in einem eigenen Abschnitt, und das nach dem Nachtest ausgestellte Abschlussschreiben ist das Dokument, das in Beschaffungsprozessen üblicherweise als Nachweis akzeptiert wird.
Das hängt vom Risiko ab. Eine produktionsnahe Testumgebung ist vorzuziehen, wenn es sie gibt, weil sie schärfere Tests erlaubt. Existiert nur die Produktion — der häufigste Fall —, schränken wir zerstörende Handlungen ein, vereinbaren ein Zeitfenster und halten während der gesamten Durchführung einen Kanal offen.
Dann greift das zu Beginn vereinbarte Abbruchkriterium: Ein kritischer Befund wird sofort gemeldet, mit dem Minimum, das Sie zum Handeln brauchen, ohne den Abschlussbericht abzuwarten. Wenn es der Fall erfordert, pausiert die Durchführung bis zur Eindämmung.
Das hängt von Ihrer Änderungsrate ab. Eine Anwendung mit fortlaufender Auslieferung verändert ihre Fläche wöchentlich, und ein Jahrestest betrachtet ein System, das es so nicht mehr gibt. Verbreitet ist die Kombination aus regelmäßigem Test des Hauptumfangs und punktuellem Test bei jeder strukturellen Änderung — neue Integration, neuer Identitätsanbieter, neue Umgebung.