Marquis Software Solutions: Ransomware über eine SonicWall-Eintrittstür – und warum „Patch vorhanden“ nicht gleich „Risiko weg“ bedeutet
Wenn ein Dienstleister zur gemeinsamen Schwachstelle wird
Man kann sehr viel richtig machen und trotzdem gleichzeitig verlieren, wenn ein einziger Dienstleister zum Knotenpunkt für viele Organisationen wird. Genau das macht den Vorfall bei Marquis Software Solutions so relevant: Marquis ist ein Anbieter von Marketing-, Kommunikations- und datenbezogenen Services für Banken und Credit Unions. Wenn dort Ransomware einschlägt, entsteht kein „isolierter Incident“, sondern ein multiplikativer Schaden – weil Daten vieler Institute über einen zentralen Dienstleister laufen.
Und dann kommt der zweite, unangenehme Teil: Der Angriff soll nach öffentlich gewordenen Meldungen über eine SonicWall-Firewall/SSLVPN-Eintrittsfläche erfolgt sein. Also über eine Klasse von Systemen, die in Unternehmen oft als „solide Infrastruktur“ gilt, aber in der Praxis regelmäßig durch eine Mischung aus Patch-Lücken, Migrationsfehlern und Credential-Hygiene-Problemen kompromittiert wird.
Das Ergebnis ist ein Vorfall, der nicht nur als „Ransomware bei Vendor“ lesbar ist, sondern als Lehrstück über drei moderne Realitäten:
- Edge Devices sind weiterhin Premium-Ziele für Initial Access.
- Third-Party-Risk ist kein Compliance-Thema, sondern ein Betriebsrisiko.
- „Wir waren gepatcht“ schützt nicht, wenn Konfigurationen und Identitäten nicht mitgepflegt werden.
Was passiert ist – die belastbare Ereigniskette
Aus öffentlich bekannten Meldungen ergibt sich ein Ablauf, der in vielen Ransomware-Fällen typisch ist, aber hier durch die Lieferkettenwirkung besonders schwer wiegt:
Erkennung und Incident
- Marquis stellte am 14. August 2025 verdächtige Aktivitäten fest und ordnet den Vorfall als Ransomware-Angriff ein.
- In Benachrichtigungen an Behörden wird beschrieben, dass ein unautorisierter Akteur über eine SonicWall-Firewall in das Netzwerk gelangt sei.
Datenzugriff
- Marquis spricht davon, dass Angreifer „bestimmte Dateien“ aus Systemen entwendet haben könnten.
- Betroffene Datenarten werden in Berichten und Meldungen mit typischen Bank-/KYC-Identifikatoren beschrieben, darunter Namen, Adressen, Telefonnummern, Geburtsdaten, Social Security Numbers bzw. Taxpayer IDs sowie teils Finanzkontodetails.
Auswirkungen
- Die Liste der betroffenen Banken und Credit Unions wuchs über die Zeit; Berichte nennen über 70 betroffene Institute.
- Die Zahl betroffener Personen wurde in der öffentlichen Berichterstattung und in nachgelagerten Meldungen schrittweise höher beziffert (ein typisches Muster bei Third-Party-Incidents, weil die Zuordnung zu Dateninhabern und Meldepflichten zeitversetzt erfolgen).
Einordnung durch Dritte
- Reuters fasste den Vorfall als Ransomware-Angriff bei einem Fintech-Dienstleister zusammen, der Banken/Genossenschaften informiert und bei dem laut behördlicher Einreichung ein SonicWall-Vektor eine Rolle gespielt habe.
Warum dieser Angriff so lehrreich ist: „SonicWall“ ist selten nur ein Patch-Thema
Der Mythos: „Wir haben gepatcht, also sind wir sicher“
In der Praxis sind viele SonicWall-/SSLVPN-Incidents nicht das Ergebnis eines einzigen fehlenden Patches, sondern einer Kombination:
- Patch wurde verspätet eingespielt
- Konfiguration blieb riskant (z. B. unnötig exponierte Oberflächen)
- Identitäten wurden nicht sauber rotiert
- Migrationen haben Altlasten „mitgenommen“ (insbesondere lokale Accounts/Passwörter)
SonicWall selbst hat in einem Support-Hinweis (Gen 7 und neuer) auf eine Welle von SSLVPN-bezogener Threat Activity hingewiesen und dabei explizit den Zusammenhang beschrieben, dass bei Migrationen von Gen 6 zu Gen 7 lokale Passwörter übernommen und anschließend nicht zurückgesetzt wurden – obwohl genau das in früheren Guidance-Schritten als kritisch beschrieben wurde.
Der zweite Mythos: „Mit MFA ist das Risiko weg“
MFA ist wichtig, aber im Edge-/VPN-Kontext ist es nicht automatisch das Ende der Geschichte. Es gibt reale Kampagnen, in denen Angreifer MFA-Umgehungsstrategien nutzen, etwa über kompromittierte Seeds oder über bereits früher erlangte Zugangsdaten. Entscheidend ist deshalb nicht „MFA ja/nein“, sondern das Gesamtsystem aus:
- Exposure-Reduktion
- harte Zugangspfade (Zero-Trust-ähnliche Patterns)
- konsequente Credential-Rotation
- Monitoring und Anomalieerkennung
- schnelle Reaktion bei Verdacht
Der eigentliche Schaden: Der „Blast Radius“ der Lieferkette
Warum Banken hier doppelt betroffen sind
Auch wenn die Ransomware bei Marquis einschlug, trifft der Vorfall Banken und Credit Unions in zwei Dimensionen:
Datenrisiko
- Selbst selektive Datensätze (z. B. für Kommunikation oder CRM) reichen aus, um Identitätsbetrug und Social Engineering zu ermöglichen.
- Der Datentyp ist „hochwertig“: Name + Adresse + Geburtsdatum + SSN/TIN ist im US-Kontext ein starker Identitätskern.
Reaktionsrisiko
- Benachrichtigung und Support laufen über mehrere Parteien: Vendor → Bank → Kunde.
- Jede Verzögerung erzeugt Unsicherheit und öffnet Raum für Betrüger, die die Situation ausnutzen („Ihre Bank meldet einen Vorfall – bestätigen Sie hier …“).
- Institute müssen reagieren, obwohl sie technisch nicht der „Root“-Ort des Incidents sind.
Warum die Betroffenenzahlen in Wellen steigen
Bei Third-Party-Incidents ist es normal, dass Zahlen steigen und sich Listen betroffener Institute erweitern, weil:
- die forensische Zuordnung von Dateien zu Kunden/Instituten Zeit benötigt
- Meldepflichten je US-Bundesstaat unterschiedliche Fristen und Formate haben
- Dateninhaber teilweise selbst nachmelden, wenn sie interne Abgleiche abgeschlossen haben
Das ist kein PR-Spiel, sondern eine operative Realität. Professionell wird es dann, wenn Unternehmen frühzeitig so kommunizieren, dass „Updates“ erwartbar sind, ohne Vertrauen zu verlieren.
Was „hätte passieren können“ – ohne Spekulation, aber mit realistischer Threat-Logik
Bei Ransomware-Vorfällen ist die Kernfrage immer: Ging es „nur“ um Verschlüsselung, oder auch um Exfiltration und spätere Erpressung? In diesem Fall sprechen die veröffentlichten Formulierungen („bestimmte Dateien“) und die Art der Incident-Kommunikation dafür, dass das Risiko von Datenabfluss ernst genommen wird.
Realistische Missbrauchsmuster, die aus genau solchen Datenprofilen folgen, sind:
- Identitätsbetrug (Kontoeröffnungen, Kreditbetrug, synthetische Identitäten)
- zielgerichtetes Phishing im Bankkontext (hohe Glaubwürdigkeit durch echte Kundendaten)
- Account-Recovery-Angriffe bei Diensten, die PII als Verifikator nutzen
- Social Engineering gegen Bank-Support („Ich habe meine Nummer geändert…“)
- Follow-on-Fraud entlang typischer Lebensereignisse (Adressänderungen, neue Karten, neue Konten)
Die technische Ursache ist dabei fast zweitrangig. Entscheidend ist der Datentyp und die Ökosystemwirkung.
Was Unternehmen daraus konkret ableiten sollten
Technische Maßnahmen, die in der Realität den Unterschied machen
Edge-Exposure reduzieren
- SSLVPN/Managementflächen nur, wenn zwingend erforderlich
- Zugriff über restriktive IP-/Geo-Policies und starke Device-Controls, wo möglich
- „Virtual Office“- oder ähnliche Portale nicht unnötig öffentlich belassen
Credential-Hygiene als Pflichtprozess
- Nach Firewall-/Gateway-Migrationen: lokale Accounts und Passwörter verpflichtend zurücksetzen
- Keine langlebigen lokalen Admin-Konten ohne Rotation
- MFA ergänzen, aber nie als alleinigen Schutz betrachten
Monitoring speziell für Edge Devices
- Alarme auf ungewöhnliche Login-Muster, neue Regionen/IPs, untypische Zeitfenster
- Erkennung von „sprunghaften“ Konfigurationsänderungen
- schnelle IOC-Hunting-Routinen, sobald Vendor-Warnungen oder Threat-Activity-Hinweise erscheinen
Third-Party-Risk: Von Papier zu Kontrolle
Wenn ein Dienstleister Daten vieler Institute hält oder verarbeitet, braucht es mehr als Fragebögen:
- Datenminimierung: nur Felder übertragen, die wirklich benötigt werden
- Retention-Regeln: kurze Aufbewahrung, automatisierte Löschung, Nachweisbarkeit
- Segregation: mandantengetrennte Speicher- und Zugriffspfade
- Incident-SLAs: feste Fristen für Erstmeldung, Updates, IOC-Sharing, Forensik-Kooperation
- Testbare Controls: Nachweise zu Logging, Zugriffskontrollen, Key-/Credential-Management
