Whitehat-Team · Penetration Testing & Red Teaming

Wir greifen an, bevor es andere tun.

WebShield Security prüft Webanwendungen, APIs, Infrastruktur und Organisationen so, wie ein echter Angreifer es tun würde. Nur mit schriftlicher Beauftragung, in klar abgegrenztem Scope und mit einem Report, mit dem Ihr Team tatsächlich arbeiten kann.

Web & API Infrastruktur & Active Directory Red Teaming Continuous Testing
/ ausgangslage

Angreifer suchen nicht die schwerste Lücke. Sie nehmen die einfachste.

Die meisten Vorfälle beginnen nicht mit einem Zero-Day, sondern mit einem vergessenen System, einer falsch gesetzten Berechtigung oder einer Person, die auf einen Link geklickt hat. Genau dort schauen wir hin.

Beobachtung 01

Die Angriffsfläche wächst schneller als das Team

Cloud-Konten, SaaS-Tools, APIs und alte Systeme, von denen niemand mehr genau weiß, wer sie betreibt. Was nicht inventarisiert ist, wird auch nicht geschützt.

Beobachtung 02

Scanner finden nur, was sie kennen

Automatisierte Tools erkennen bekannte Muster. Logikfehler, verkettete Schwachstellen und fehlende Autorisierung zwischen Mandanten finden sie nicht. Menschen schon.

Beobachtung 03

Compliance ist nicht Sicherheit

Ein bestandenes Audit sagt, dass Prozesse dokumentiert sind. Es sagt nicht, ob jemand in zwei Tagen Domain-Admin wird. Das prüft nur ein realistischer Test.

/ leistungen

Vier Wege, Ihre Sicherheit ehrlich zu prüfen.

Vom fokussierten Test einer Anwendung bis zur Simulation eines gezielten Angriffs auf die gesamte Organisation. Der passende Umfang wird im Scoping festgelegt, nicht im Vertrieb.

01 / Web & API

Web Application & API Penetration Testing

Manuelle Prüfung von Webanwendungen, Single-Page-Apps und REST/GraphQL-APIs entlang OWASP WSTG und ASVS. Schwerpunkt auf Authentifizierung, Autorisierung, Geschäftslogik und Mandantentrennung.

Details ansehen →
02 / Infrastruktur

Netzwerk, Active Directory & Cloud

Externe und interne Infrastrukturtests, Active-Directory- und Entra-ID-Assessments sowie Konfigurationsprüfungen in AWS und Azure. Vom ersten Foothold bis zur Frage: Wie weit kommt man wirklich?

Details ansehen →
03 / Red Team

Red Teaming & Social Engineering

Zielorientierte Angriffssimulation über mehrere Wochen, orientiert an MITRE ATT&CK. Phishing, Initial Access, laterale Bewegung und Persistenz, abgestimmt mit einem kleinen Kreis Eingeweihter auf Ihrer Seite.

Details ansehen →
04 / Retainer

Continuous Testing & Retainer

Feste Testkapazität über das Jahr: Re-Tests nach Releases, Prüfung neuer Features vor dem Go-live, Angriffsflächen-Monitoring und ein Ansprechpartner, der Ihre Systeme bereits kennt.

Details ansehen →
/ ablauf

Vom Scoping bis zum bestätigten Fix.

Kein Test beginnt ohne schriftliche Autorisierung, und keiner endet mit einem PDF, das im Ordner verschwindet. Fünf Phasen, jede mit klarem Ergebnis.

  1. 01

    Scoping

    Welche Systeme, welche Ziele, welche Grenzen? Wir klären Umfang, Testfenster, Ansprechpartner und was auf keinen Fall passieren darf.

    Ergebnis: Scope-Dokument und Angebot mit Festpreis
  2. 02

    Autorisierung & Rules of Engagement

    Schriftliche Beauftragung, Notfallkontakte auf beiden Seiten, Umgang mit gefundenen Daten, Eskalationsweg bei kritischen Funden. Ohne diesen Schritt wird nicht getestet.

    Ergebnis: Unterschriebene Rules of Engagement
  3. 03

    Test

    Manuelle Prüfung, ergänzt durch eigene Tooling-Pipelines. Kritische Funde melden wir sofort, nicht erst im Bericht.

    Ergebnis: Laufende Statusmeldungen, Sofortmeldung bei Critical
  4. 04

    Report & Abschlussgespräch

    Management Summary, technische Findings mit CVSS-4.0-Bewertung, Reproduktionsschritte und konkrete Empfehlungen. Im Abschlussgespräch gehen wir jedes Finding mit Ihrem Team durch.

    Ergebnis: Report, Findings-Export, Abschlussgespräch
  5. 05

    Re-Test

    Nach der Behebung prüfen wir jedes Finding erneut und bestätigen den Fix schriftlich. Erst dann ist das Engagement abgeschlossen.

    Ergebnis: Re-Test-Bericht mit Status je Finding
/ ergebnis

Was Sie am Ende in der Hand haben.

Ein Report ist nur so gut wie die Entscheidung, die er ermöglicht. Deshalb schreiben wir für zwei Leser gleichzeitig: die Geschäftsführung und die Person, die den Fix einbaut.

01
Management SummaryAuf einer Seite: Gesamtrisiko, die drei wichtigsten Maßnahmen, Vergleich zum Vorjahr, falls vorhanden.
02
Technische FindingsJe Finding: Schweregrad nach CVSS 4.0, betroffene Komponente, Reproduktionsschritte, Nachweis, Empfehlung, Referenzen (CWE, OWASP).
03
AngriffspfadWie sich einzelne Schwachstellen verketten lassen. Denn ein Medium plus ein Medium ist oft ein Critical.
04
Findings-ExportMaschinenlesbar für Jira, GitLab oder Ihr Ticketsystem. Kein Abtippen aus dem PDF.
05
Re-Test-NachweisNach der Behebung: Status je Finding, bestätigt durch erneute Prüfung.
finding-2024-0173.md · anonymisiert
# F-03 · Broken Object Level Authorization
Schweregrad   High · CVSS 4.0: 8.1
Komponente   api-gateway · /api/v2/invoices/{id}
CWE          CWE-639 · OWASP API1:2023

## Beschreibung
Der Endpunkt prüft die Session, aber nicht, ob die
angeforderte Rechnung zum angemeldeten Mandanten gehört.
Durch Hochzählen der ID sind fremde Rechnungen abrufbar.

## Reproduktion
1. Login als Testkonto A, Rechnung 4711 anlegen
2. Login als Testkonto B
3. GET /api/v2/invoices/4711  →  200 OK (erwartet: 403)

## Empfehlung
Objektbezogene Autorisierung serverseitig erzwingen
(tenant_id aus Session, nicht aus Request). Zusätzlich
nicht-sequenzielle IDs (UUIDv7) und Audit-Log für 403.

Status       behoben · Re-Test bestanden
/ haltung

Whitehat heißt: Regeln vor Ergebnissen.

Ein guter Angriffstest lebt davon, dass beide Seiten wissen, was passiert. Wir arbeiten nach festen Prinzipien, die in jedem Vertrag stehen und die wir auch dann einhalten, wenn es den Test einfacher machen würde, sie zu ignorieren.

Nur mit schriftlicher Beauftragung durch den Systemeigentümer. Keine Tests auf Zuruf, keine „kleinen Blicke“.
Scope ist Scope. Was nicht drinsteht, wird nicht angefasst. Wenn wir etwas außerhalb sehen, melden wir es und warten.
Keine Exfiltration echter Kundendaten. Nachweise werden mit Testkonten und minimalen Belegen geführt.
Kritische Funde gehen sofort an Ihren Notfallkontakt, nicht erst mit dem Report.
Alle Testdaten werden nach Abschluss und Re-Test nachweislich gelöscht.

Ein Pentest, der keine Findings liefert, war entweder zu kurz, zu eng oder zu bequem.

Wir sagen vorher, was in der geplanten Zeit realistisch prüfbar ist. Und hinterher, was wir nicht geschafft haben. Beides steht im Report.
/ team

Ein kleines Team. Bewusst ohne Gesichter.

Unsere Tester arbeiten aus guten Gründen nicht mit Namen und Foto im Netz: Wer Phishing-Kampagnen und Social Engineering für Kunden durchführt, sollte selbst nicht leicht zu recherchieren sein. Was Sie stattdessen bekommen: klare Rollen, feste Ansprechpartner und ein Vier-Augen-Prinzip bei jedem Report.

Lead Penetration Tester

Verantwortet Scoping, Testleitung und Qualität des Reports. Ihr Gegenüber im Abschlussgespräch.

Red Team Operator

Plant und führt Angriffssimulationen durch: Phishing-Infrastruktur, Initial Access, laterale Bewegung.

Cloud & Identity Specialist

Active Directory, Entra ID, AWS und Azure: Berechtigungsketten, Fehlkonfigurationen, Privilege Escalation.

Report & Quality Assurance

Prüft jedes Finding auf Reproduzierbarkeit und jede Empfehlung darauf, ob sie sich umsetzen lässt.

/ faq

Häufige Fragen vor der Anfrage.

Wie unterscheidet sich ein Pentest von einem Schwachstellenscan?
Ein Scan vergleicht Ihre Systeme mit einer Datenbank bekannter Schwachstellen. Ein Pentest wird von Menschen durchgeführt, die Funde verketten, Geschäftslogik verstehen und dort weitermachen, wo ein Scanner aufhört. Scans nutzen wir als Ausgangspunkt, nie als Ergebnis.
Kann ein Test unsere Produktion stören?
Das Risiko lässt sich nicht auf null bringen, aber steuern: Testfenster, Ausschluss von Denial-of-Service-Techniken, Absprache bei destruktiven Schritten und ein Notfallkontakt, der den Test jederzeit stoppen kann. All das steht in den Rules of Engagement.
Wie lange dauert ein Engagement?
Ein fokussierter Web- oder API-Test liegt typischerweise bei fünf bis fünfzehn Testtagen, ein interner Infrastrukturtest ähnlich, ein Red-Team-Engagement bei mehreren Wochen. Die genaue Dauer folgt aus dem Scoping, und wir sagen vorher, was in der Zeit realistisch ist.
Wann ist ein Start möglich?
Wir nehmen bewusst wenige Engagements parallel an. Neue Mandate planen wir zum Quartalsbeginn, das nächste freie Zeitfenster ist Q1 2027. Retainer-Kunden haben Vorrang bei Re-Tests und dringenden Prüfungen.
Was passiert mit den Daten, die Sie während des Tests sehen?
Wir greifen nur so weit zu, wie es für den Nachweis nötig ist, und arbeiten wo möglich mit Testkonten. Belege werden minimal gehalten und geschwärzt. Nach Abschluss und Re-Test löschen wir alle Testdaten und bestätigen das schriftlich.
Erhalten wir eine Bescheinigung für Kunden oder Auditoren?
Ja. Nach dem Re-Test stellen wir auf Wunsch ein Testat aus, das Umfang, Zeitraum, Methodik und den Status der Findings zusammenfasst, ohne technische Details preiszugeben. Es eignet sich für Kundenanfragen, ISO-27001-Audits oder TISAX.
/ anfrage

Wenn Sie wissen wollen, wie weit man wirklich kommt.

Wir prüfen jede Anfrage persönlich und nehmen nur Engagements an, bei denen Umfang, Timing und Zusammenarbeit passen. Nächstes freies Zeitfenster: Q1 2027.

Engagement anfragen