Musterbericht für einen Fintech-Pentest | Vorschau des 68-seitigen PDFs

Projekt Meridian: eine fiktive Übung der Fintech AG mit drei kritischen Funktionen, drei Szenarien und zwölf Feststellungen. Alle Systeme, Beteiligten und Ergebnisse sind erfunden.

Das Team erlangt auf einem über das Internet erreichbaren Diagnosehost Befehlsausführung ohne Root-Rechte, greift auf CI zu und verwendet ein Service-Token, um eine Canary-Zahlung zu ändern. Die Zusammenfassung trennt diese nicht unterstützte Angriffskette von den Ergebnissen mit Unterstützung durch CRM und Wiederherstellung und benennt die wirksamen Kontrollen für Signierung, Kerndaten und unveränderliche Kopien.

Die Architektur verbindet Kundenkanäle, Identitäten und Lieferanten mit den Perimeter-, Betriebs- und Supportzonen. Zahlungen, digitale Konten und das Treasury hängen von Kerndaten, Erkennung und Wiederherstellung ab. Pfeile stellen logische Abhängigkeiten dar, keinen uneingeschränkten Netzwerkzugriff.

Das Team sendet eine wörtliche Command-Injection-Probe und erhält vom WAF den Status 403. Eine Unicode-escaped Variante erhält den Status 200 und gibt id-, hostname- und pwd-Ausgaben als svc_diag auf mb-diag-01 zurück. Beide HTTP-Austausche, Request-IDs und UTC-Zeitangaben werden als synthetische Belege dargestellt.

F-03 zeigt eine PATCH-Anfrage unter Verwendung der übernommenen Identität svc_pay_orch, die akzeptierte Änderung des Begünstigten auf MER-PAY-0042 und eine unabhängige Rücklesung. Der Dienst ändert den Canary-Entwurf, während eine separate Signaturberechtigung die Abwicklung verhindert.

F-06 beschreibt eine Wiederholung vom akzeptierten WAF-Request über CI bis zur Zahlungs-API. Ein Fall muss Host, Request, Artefakt, Principal und Zahlung verknüpfen; das Triage-Ziel beträgt 15 Minuten. Das Verfahren ist ausdrücklich als noch nicht ausgeführt gekennzeichnet; eine künftige Validierung wird nicht als bestandener Retest dargestellt.

Für drei Feststellungen sind Abschlussprüfungen dokumentiert: Command Injection, Sitzungswiderruf und Bereinigung. Neun sind noch offen; für Berechtigungsnachweise, Zahlungs- und Wiederherstellungsbefugnisse, Genehmigungsbindung, Segmentierung, Erkennung und unterstützende Kontrollen sind Termine festgelegt. Dies sind fiktive Ziele für Plattformen, keine gesetzlichen Behebungsfristen.

Die Zuordnung verknüpft geprüfte Ergebnisse mit Kontrollzielen, verantwortlichen Eigentümern, Verifikationsnachweisen und den Grenzen der Prüfung. Sie stellt keine regulatorische Zertifizierung in Aussicht.