SECURITY18. Februar 2026

Heimlicher Datendiebstahl bedroht Banken: Ransomware verliert ihre Lautstärke – und gewinnt an Wirkung

Jan Schledzinski, msg, erklärt, dass Ransomware für Banken längst kein Verschlüsselungsproblem mehr ist. <q>msg
Jan Schledzinski, msg msg

Ransomware ist für Banken längst kein Verschlüsselungsproblem mehr. 2026 liegt das eigentliche Risiko im unbemerkten Abfluss und in der gezielten Manipulation hochsensibler Finanz- und Kundendaten. Wer nur Backups prüft, übersieht den eigentlichen Angriff.

von Jan Schledzinski, Lei­ter der Ab­tei­lung Di­gi­tal Fo­ren­sics & In­ci­dent Re­s­pon­se msg

Klassische Ransomware-Angriffe waren laut: Systeme verschlüsselt, Betrieb gestört, Lösegeldforderung sichtbar. In Bankenumgebungen funktioniert dieses Modell zunehmend schlechter. Reife Backup-Strategien, Notfallhandbücher und regulatorische Anforderungen haben die Erpressbarkeit reduziert.

Die Reaktion der Angreifer ist technisch konsequent: Ransomware wird zum Deckmantel.“

Der eigentliche Angriff findet davor statt – leise, langfristig und oft ohne unmittelbare monetäre Forderung. Ziel ist nicht mehr die Verfügbarkeit, sondern primär Vertraulichkeit und Integrität.
Für Banken ist das besonders kritisch: Zahlungsverkehrsdaten, KYC-Informationen, Meldewesen, Risikomodelle und interne Bewertungslogiken sind hochattraktive Ziele – für organisierte Cyberkriminalität ebenso wie für staatlich unterstützte Akteure.

Warum Banken besonders anfällig für stille Angriffe sind

Bank-IT zeichnet sich durch Eigenschaften aus, die heimliche Exfiltration begünstigen:
Hohe Datenkonzentration: Zahlungsströme, Kontoinformationen, Identitätsdaten.
Komplexe Schnittstellenlandschaften: Core Banking, SWIFT, SEPA, Meldewesen, externe Dienstleister.
Legacy-Systeme mit eingeschränkter Telemetrie.
Strenge Verfügbarkeitsanforderungen, die aggressive Sicherheitsmaßnahmen erschweren.

Jan Schledzinski, msg
Jan Schledzinski, msg <q>msg</q>Jan Schledzinski ist Lei­ter der Ab­tei­lung Di­gi­tal Fo­ren­sics & In­ci­dent Re­s­pon­se (DFIR) bei msg (Website). Er ver­fügt über mehr als 15 Jah­re Er­fah­rung in IT-Fo­ren­sik, In­ci­dent Re­s­pon­se und IT-Si­cher­heits­ana­ly­sen in Be­hör­den und Un­ter­neh­men. Vor sei­ner Tä­tig­keit in der Be­ra­tung war er IT-Kri­mi­na­list bei der Baye­ri­schen Po­li­zei so­wie tech­ni­scher Be­am­ter bei ver­schie­de­nen Si­cher­heits­be­hör­den. Sein Schwer­punkt liegt auf der Ana­ly­se kom­ple­xer Cy­ber­an­grif­fe, der Ent­wick­lung fo­ren­si­scher Me­tho­den und der Er­stel­lung ge­richts­fes­ter Gutachten.
Angreifer nutzen diese Struktur gezielt. Typische Angriffspfade beginnen mit kompromittierten Administratorzugängen, Service-Accounts oder Drittanbieter-Zugängen und enden nicht in der Verschlüsselung, sondern im monatelangen Abfluss kleiner Datenmengen, die in der Masse untergehen.

Technisch relevant: Wie heimlicher Datendiebstahl in Banknetzen aussieht

In der Praxis zeigen sich wiederkehrende Muster:
1. Living-off-the-Land
Exfiltration erfolgt über vorhandene Werkzeuge: Datenbank-Exports, legitime API-Aufrufe, interne Batch-Prozesse. Kein Malware-Signaturtreffer, kein Alarm.
2. Fragmentierte Datenabflüsse
Statt großer Datenpakete werden kontinuierlich kleine Volumina übertragen – häufig verschlüsselt, aber formal regelkonform.
3. Missbrauch von Melde- und Reportingprozessen
Daten, die ohnehin an Aufsichtsbehörden oder Clearingstellen gehen, werden vorab kopiert oder manipuliert.
4. Manipulation statt Lösegeld
Veränderung von Risikoparametern, Buchungslogiken oder Zeitreihen – mit Auswirkungen, die sich erst Wochen oder Monate später zeigen.

Warum klassische Security-Kontrollen versagen

Firewalls, EDR und SIEM erkennen primär Abweichungen vom Normalzustand. Moderne Angriffe vermeiden genau diese Abweichung. Für Banken bedeutet das:
Netzwerkverkehr ist formal legitim
Benutzerverhalten entspricht Rollenmodellen
Prozesse laufen innerhalb genehmigter Zeitfenster
Ein Angriff bleibt unsichtbar, solange kein forensischer Blick auf Datenflüsse, Speicher und Prozesskontexte erfolgt.

Was Banken technisch anders machen müssen

1. Datenfluss-basierte Anomalieerkennung
Nicht „wer greift zu“, sondern welche Daten bewegen sich wohin, wann und warum. Besonders kritisch: Reporting- und Exportprozesse.
2. Speicher- und Prozessforensik als Frühwarnsystem
Memory-Analysen zeigen persistente Zugriffe, Credential-Missbrauch und versteckte Prozesse, lange bevor Logs auffällig werden.
3. Integritätsüberwachung statt reiner Verfügbarkeit
Hash-basierte Prüfungen kritischer Datenbestände (z. B. Risikomodelle, Buchungstabellen) müssen kontinuierlich erfolgen.
4. Incident Response unter regulatorischen Bedingungen testen
Tabletop-Exercises reichen nicht. Banken müssen forensisch belastbare Szenarien üben: Datenabfluss ohne Verschlüsselung, stille Manipulation, verzögerte Entdeckung.

Fazit: Warum Ransomware 2026 vor allem ein Integritätsproblem ist

Für Banken ist Ransomware kein Betriebsunterbrechungsrisiko mehr, sondern ein strategisches Vertrauensrisiko. Wer Angriffe nur dann ernst nimmt, wenn Systeme verschlüsselt sind, reagiert zu spät.

Die entscheidende Frage lautet nicht mehr „Können wir wiederherstellen?“, sondern „Können wir beweisen, dass unsere Daten noch korrekt sind?“

Einordnung aus Sicht von msg

Mit Inkrafttreten von DORA verschiebt sich der Schwerpunkt im Umgang mit Ransomware in Banken und Versicherungen deutlich: Weg von der reinen Wiederanlauffähigkeit, hin zur nachweisbaren Kontrolle über Datenflüsse, Systemzustände und Integrität. Aus msg-Sicht zeigen aktuelle Prüfungen und Incident-Response-Einsätze, dass viele Institute zwar über belastbare Backup- und Krisenpläne verfügen, jedoch keine ausreichende technische Transparenz über schleichende Datenabflüsse und langfristige Kompromittierungen besitzen.

DORA fordert explizit die Fähigkeit, ICT-bezogene Vorfälle technisch nachvollziehbar zu analysieren, Auswirkungen auf Daten, Prozesse und Finanzstabilität zu bewerten und diese Erkenntnisse revisionssicher zu dokumentieren.“

In komplexen Bank-IT-Landschaften mit Core-Banking-Systemen, Zahlungsverkehrsplattformen, Meldewesen und angebundenen IKT-Drittdienstleistern ist dies ohne forensische Tiefenanalyse kaum leistbar. Klassische Log- und SIEM-Ansätze erfassen legitime, aber missbräuchlich genutzte Prozesse nur unzureichend.

Aus technischer Sicht erfordert DORA daher eine Erweiterung bestehender Sicherheitsarchitekturen um kontinuierliche Integritätsprüfungen, speicher- und prozessbasierte Analysen sowie eine enge Verzahnung von Detection, Forensik und Incident Response. Nur wenn Institute in der Lage sind, stille Angriffe technisch zu erkennen und deren Auswirkungen belastbar zu bewerten, können sie den Anforderungen an Resilienz, Meldepflichten und aufsichtsrechtliche Nachvollziehbarkeit gerecht werden. Jan Schledzinski, msg

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert