Basilisk
BASILISK
[cases_index]REAL ENGAGEMENTS · ANONYMIZED

Before it became a headline, it became a fix.

Alle folgenden Fälle wurden unter NDA anonymisiert. Zahlen, Branche und Angriffsvektor sind echt — der Kundenname nicht.

200+
engagements delivered
4,500+
gemeldete ausnutzbare Schwachstellen
R$ 180M+
vermiedener potenzieller Schaden
sector
Fintech · Open Finance
vector
API misconfig + IDOR
fix
72h
case/01

Vollzugriff auf die Produktion über eine interne API ohne Authentifizierung

Ein Admin-Endpunkt lag durch eine Fehlkonfiguration des API-Gateways offen. Zusammen mit IDOR in den Überweisungsrouten erlaubte das den Zugriff auf jedes Konto. Gefunden an Tag 2 des Engagements.

impact avoided:R$ 48 Mio. an möglichen Transaktionen blockiert
sector
Healthtech · SaaS
vector
Cloud misconfig
fix
24h
case/02

1,2 Mio. Gesundheitsakten über einen Staging-S3-Bucket offengelegt

Der Staging-Bucket replizierte Produktionsdaten ohne Verschlüsselung und ohne Zugriffskontrolle. Behoben vor dem externen ISO-Audit.

impact avoided:DSGVO-Bußgeld vermieden · nicht meldepflichtiger Vorfall
sector
Industry · OT
vector
Segmentierung + veraltete Zugangsdaten
fix
2 weeks
case/03

Laterale Bewegung von der IT in die Produktionsanlage über ein veraltetes VPN

Red-Team-Engagement mit Phishing als Ausgangspunkt. Von einer Engineering-Workstation ins OT-Netz über ein VPN mit Standardzugangsdaten. Behoben mit Segmentierung, Jump Host und MFA.

impact avoided:Auf 8 Tage geschätzter Produktionsstillstand verhindert
sector
E-commerce · B2C
vector
XSS + Sitzung ohne Rotation
fix
96h
case/04

Angriffskette: XSS → Übernahme eines Admin-Kontos → Guthaben

Reflektiertes XSS auf der Suchseite in Verbindung mit einer zu großzügigen Cookie-Richtlinie ermöglichte den Diebstahl der Admin-Sitzung. Gefunden in einem regulären Pentest.

impact avoided:Betrug blockiert, geschätzt R$ 2,3 Mio. pro Monat

Warum hier jeder Fall anonymisiert ist

Den Namen eines Kunden neben der Lücke zu veröffentlichen, die er hatte, setzt ihn zweimal aus: einmal im Vorfall und einmal für immer. Vektor und Wirkung zu beschreiben lehrt etwas; das Opfer zu benennen ist bloß Schaufenster — und es verzerrt den Anreiz, denn wer die Veröffentlichung freigibt, ist dann das Unternehmen mit dem geringsten Verlustrisiko.

  • Name, Marke und jedes Detail, das das Unternehmen identifizierbar macht, bleiben draußen.
  • Der technische Vektor bleibt erhalten, denn er ist der Teil mit Wert für die Lesenden.
  • Nichts wird veröffentlicht, bevor die Behebung abgeschlossen und im Nachtest bestätigt ist.
  • Alles Material durchläuft die Freigabe des Kunden, bevor es öffentlicher Text wird.

Muster, die sich wiederholen

Andere Branchen, andere Architekturen — und doch ähneln sich die Wege, die funktionieren. Diese kommen am häufigsten vor, und ein Blick darauf lohnt sich, bevor irgendein Test beauftragt wird.

// eine Umgebung, die es nicht geben sollte

Testumgebung mit Produktionskopie, ein altes Verwaltungspanel, ein für eine Vorführung gestarteter und nie abgeschalteter Dienst. Meist fehlt sie im Inventar und steht deshalb außerhalb jeder Schutzmaßnahme, die für alles andere gilt.

// Autorisierung auf Objektebene

Das System prüft, ob Sie angemeldet sind, aber nicht, ob der Datensatz Ihnen gehört. Diese Lücke übersieht automatisiertes Werkzeug am häufigsten, weil die Anfrage völlig legitim aussieht.

// dauerhaft vorübergehende Berechtigung

Weitreichender Zugriff, erteilt, um eine Auslieferung freizumachen, mit dem Versprechen, ihn später zu straffen. Monate später ist er noch da — inzwischen vererbt an Leute, die nie wussten, dass sie ihn haben.

// ein Geheimnis am falschen Ort

Ein Schlüssel in einer exponierten Umgebungsvariable, Zugangsdaten in der Repository-Historie, ein Token in einer versionierten Konfigurationsdatei. Der kürzeste Weg hinein und der am leichtesten zu schließende.

// Vertrauen zwischen Systemen

Zwei Anwendungen, die sich über Netzposition oder ein geteiltes Geheimnis authentifizieren. Die schlechter geschützte zu kompromittieren liefert die besser geschützte gleich mit, und die Segmentierung, die das auffangen sollte, wurde selten geprüft.

// Erkennung, die niemanden erreicht

Das Ereignis wurde protokolliert, der Alarm ausgelöst — und landete in einer Warteschlange, die niemand liest. Technisch erkannt, praktisch unsichtbar: Der Unterschied zeigt sich erst in einer unangekündigten Übung.

Häufige Fragen

01Warum steht hier kein Kundenname?

Weil die Freigabe zur Veröffentlichung von denen käme, die am wenigsten zu verlieren haben, nicht von denen mit dem lehrreichsten Fall. Alles Material ist unter Vertraulichkeitsvereinbarung anonymisiert, und der technische Vektor — der nützliche Teil — bleibt erhalten.

02Stehen Sie in unserem Beschaffungsprozess als Referenz zur Verfügung?

Ja, mit Freigabe der Beteiligten. Für die meisten Prozesse entscheidet allerdings das Abschlussschreiben aus Ihrem eigenen Auftrag, ausgestellt nach dem Nachtest: Das ist unmittelbarer Nachweis statt der Einschätzung eines Dritten zu fremder Arbeit.

03Bedeutet ein ähnlicher Fall, dass unser Test genauso aussähe?

Nein. Der Weg hängt von Architektur, Integrationen und Entscheidungen ab, die erst in Ihrer Umgebung sichtbar werden. Die Fälle zeigen, was üblicherweise gefunden wird, kein Drehbuch, das sich wiederholt.

04Veröffentlichen Sie eine Lücke, bevor sie behoben ist?

Niemals. Nichts wird öffentlicher Text, bevor die Behebung abgeschlossen und im Nachtest bestätigt ist, und auch dann nur mit Freigabe. Dasselbe Kriterium gilt für eigene Forschung und steht in der Richtlinie zur verantwortungsvollen Offenlegung.

// kontakt

Bereit, Ihre Schwachstellen zu entdecken?

Erster Scoping-Call ist kostenlos und durch NDA abgedeckt. Innerhalb von 48 Stunden erhalten Sie technisches Angebot, Scope und Zeitplan. Keine Bürokratie.