Ransomware-Angriff in der AWS‑Cloud: Was tun im Krisenfall?

Ransomware‑Angriffe haben sich aus dem klassischen On‑Premise‑Umfeld längst in die Cloud verlagert. Wer 2026 in AWS produziert, verarbeitet seine personenbezogenen Daten regelmäßig in einer hochvernetzten Umgebung aus IAM‑Rollen, S3‑Buckets, RDS‑Datenbanken, Cognito‑User‑Pools, Secrets Manager und KMS‑Schlüsseln. Genau diese Bausteine sind heute die bevorzugten Angriffsziele organisierter Ransomware‑Gruppen. Der vorliegende Beitrag ordnet die aktuelle Bedrohungslage anhand realer, öffentlich dokumentierter Fälle ein, beleuchtet die rechtliche Lage rund um Lösegeldzahlungen, fasst die zwingenden datenschutzrechtlichen Meldepflichten zusammen und zeigt, warum spezialisierte anwaltliche Begleitung im Ernstfall den Unterschied zwischen kontrolliertem Krisenmanagement und Eskalation ausmacht.

Amazon Web Services Basiswissen

Bei IAM-Rollen, S3-Buckets und RDS-Datenbanken handelt es sich um drei grundlegende Kernkomponenten von Amazon Web Services (AWS), die zusammen die Säulen für Sicherheit, Speicherung und Datenverwaltung in der Cloud bilden. Eine IAM-Rolle ist ein Sicherheitswerkzeug zur Rechtevergabe, das Anwendungen oder Diensten temporäre, passwortlose Zugriffsrechte erteilt. Ein S3-Bucket fungiert als extrem skalierbarer, virtueller Container für die Speicherung unstrukturierter Daten wie Bilder, Videos oder Backups. RDS-Datenbanken bieten wiederum eine vollständig verwaltete Umgebung für relationale SQL-Datenbanken, bei der AWS administrative Aufgaben wie Updates und Backups automatisch übernimmt. Im Zusammenspiel ermöglicht dieses Trio eine sichere und effiziente Infrastruktur, bei der beispielsweise eine Anwendung dank ihrer IAM-Rolle Daten aus der RDS-Datenbank verarbeitet und Backups automatisiert im S3-Bucket ablegt.

Cloud‑Ransomware 2025/2026: Eine andere Mechanik als der klassische Verschlüsselungstrojaner

Anders als bei klassischer Ransomware, die einzelne Endgeräte oder File‑Server verschlüsselt, gewinnen Angreifer in der AWS‑Cloud regelmäßig zunächst Zugriff auf langlebige IAM‑Access‑Keys oder kompromittierte IAM‑Rollen. Aus diesen Zugängen heraus erfolgt eine systematische Inventarisierung der gesamten Cloud‑Umgebung – EC2‑Instanzen, EBS‑Volumes und Snapshots, RDS‑Datenbanken, Secrets Manager, S3‑Buckets, IAM‑Rollen, Service‑Quotas. Erst danach beginnen die eigentlichen schadensträchtigen Aktionen: Datenexfiltration, Verschlüsselung mit angreifereigenen Schlüsseln, Löschung von Backups und Etablierung persistenter Hintertüren. Das BSI und das BKA sehen in solchen Multi‑Stage‑Angriffen die derzeit gefährlichste Kategorie von Cybercrime gegen Unternehmen.

Echte Fälle von Ransomware-Angriffen auf AWS

Crimson Collective gegen Red Hat (September/Oktober 2025)

Der bislang prominenteste, von Rapid7 forensisch dokumentierte Fall einer AWS‑zentrierten Ransomware‑Operation ist die Aktivität der Gruppe „Crimson Collective“. Die Gruppe verschaffte sich Zugang über kompromittierte langlebige Access Keys und nutzte die daran hängenden IAM‑Rechte, um neue IAM‑User anzulegen, Privilegien durch das Anhängen von Policies zu eskalieren und anschließend systematisch Recon zu betreiben.

Zur Auffindung von Zugangsschlüsseln in öffentlich zugänglichen Quellen setzte die Gruppe das Open‑Source‑Tool TruffleHog ein. Im Anschluss wurden Daten aus AWS‑Diensten – allen voran RDS – exfiltriert und Erpressungsschreiben unter Missbrauch von AWS Simple Email Service direkt aus der kompromittierten Umgebung an die Opfer versandt. Die Gruppe bekannte sich zum Angriff auf Red Hat, bei dem nach eigenen Angaben rund 570 Gigabyte aus tausenden privaten GitLab‑Repositories abgegriffen worden sein sollen.

Codefinger: Ransomware durch SSE‑C in Amazon S3

Anfang 2025 dokumentierten mehrere Sicherheitsforscher die Aktivitäten der Gruppe „Codefinger“. Das Vorgehen ist methodisch hochinteressant, weil es ohne klassische Schadsoftware auskommt: Über kompromittierte IAM‑Rollen‑Credentials – häufig aus geleakten Code‑Repositories – verschaffen sich die Angreifer Schreibzugriff auf S3‑Buckets und verschlüsseln die dort liegenden Objekte mit serverseitiger Verschlüsselung über kundenseitig bereitgestellte Schlüssel (SSE‑C). Da AWS in diesem Modus den Schlüssel selbst nicht speichert, ist eine Wiederherstellung ohne Mitwirkung des Angreifers technisch ausgeschlossen. Das Opfer hat keine Möglichkeit, AWS um Hilfe zu bitten – der Schlüssel existiert in der gesamten AWS‑Welt schlicht nicht.

Variantenreichtum besteht zudem über importiertes externes Schlüsselmaterial in AWS KMS: Hier setzen die Angreifer den Ablauf des Schlüsselmaterials beliebig kurz an und löschen es anschließend, sodass die verschlüsselten Daten dauerhaft unzugänglich werden. Trend Micro und Pwned Labs haben diese Angriffsvarianten 2025 ausführlich dokumentiert.

AWS Cognito als wachsende Angriffsfläche

Der Identitätsdienst Amazon Cognito rückt zunehmend in den Fokus. Das Sicherheitsunternehmen Expel beschreibt das Muster, bei dem Angreifer Identity‑Pool‑ID, User‑Pool‑ID, User‑Pool‑Client‑ID und Region aus dem Web‑Frontend einer Anwendung extrahieren – diese Werte sind in Single‑Page‑Applications häufig fest im JavaScript‑Code oder in HTTP‑Antworten enthalten. Über Token‑Tausch gegen temporäre AWS‑Credentials und nachgelagerten Missbrauch der angehängten IAM‑Rechte wird der eigentliche Datenzugriff realisiert.

Cobalt hat parallel eine kritische Cognito‑Fehlkonfiguration beschrieben, bei der ein Angreifer mit einem eigenen gültigen Token das E‑Mail‑Attribut auf die Adresse eines Opfers ändert und dadurch dessen Account vollständig übernimmt – ohne jemals dessen Passwort gekannt zu haben. Diese Klasse von Vorfällen führt nicht zur Verschlüsselung, sehr wohl aber zu massiven, datenschutzrechtlich relevanten Datenabflüssen.

Die Shared‑Responsibility‑Falle: Was AWS leistet – und wo Sie selbst verantwortlich sind

Eine der gefährlichsten Fehlannahmen im Krisenfall lautet: „Das ist Cloud, da kümmert sich AWS um die Sicherheit.“ Das stimmt nur für die untere Schicht. AWS verantwortet die Sicherheit der Cloud – also Hardware, Hypervisor, Netzwerk‑Backbone und Service‑Verfügbarkeit. Für die Sicherheit in der Cloud – Konfiguration der IAM‑Rechte, Schutz der Access Keys, Verschlüsselungs‑Setup, Patching der EC2‑Instanzen, Logging, Backups – ist ausschließlich der Kunde verantwortlich. Genau hier setzen Aufsichtsbehörden mit Art. 32 DSGVO an, wenn sie nach einem Vorfall TOMs prüfen.

Was AWS im Vorfall konkret leistet: Über das AWS Customer Incident Response Team (CIRT) stellt AWS eine global verfügbare 24/7‑Anlaufstelle für aktive Sicherheitsvorfälle auf der Kundenseite des Shared‑Responsibility‑Modells. Das Team unterstützt bei Triage und Wiederherstellung, hilft bei der Root‑Cause‑Analyse über AWS‑Service‑Logs und gibt Empfehlungen für Recovery und Härtung. Seit Ende 2024 ergänzt AWS dieses Angebot durch den kostenpflichtigen Service AWS Security Incident Response, der Findings aus GuardDuty und Security Hub automatisiert triagiert und ebenfalls 24/7‑Zugriff auf das CIRT‑Team eröffnet. Der Zugang zum CIRT erfolgt über einen AWS Support Case.

Was AWS nicht leistet: AWS verhandelt nicht mit Erpressern, stellt keine Decryption‑Keys bereit, übernimmt keine forensische Sicherung beweissicherer Artefakte für deutsche Strafverfahren, kommuniziert nicht mit deutschen Datenschutzaufsichten und ZAC‑Stellen der Polizei, und beurteilt keine straf‑ und außenwirtschaftsrechtlichen Risiken einer etwaigen Lösegeldzahlung. Genau diese Lücke entscheidet im Ernstfall über das rechtliche Überleben der Geschäftsleitung.

Die Lösegeldfrage: Was BSI und BKA empfehlen – und welche Strafbarkeitsrisiken bestehen

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) und das Bundeskriminalamt (BKA) raten konsequent davon ab, auf Lösegeldforderungen einzugehen. Begründet wird dies vor allem damit, dass Zahlungen das Geschäftsmodell der organisierten Cybercrime stärken und keine belastbare Garantie für die Wiederherstellung der Daten oder das Ausbleiben weiterer Angriffe besteht. Beide Behörden empfehlen statt Zahlung die unverzügliche Erstattung einer Strafanzeige bei der Zentralen Ansprechstelle Cybercrime (ZAC) der zuständigen Landespolizei sowie die Information des BSI über die Allianz für Cyber‑Sicherheit.

Aus rechtlicher Sicht wiegt die Frage der Lösegeldzahlung noch deutlich schwerer als die rein faktische. Ein Geschäftsleiter, der eine Zahlung anordnet, bewegt sich in einem strafrechtlichen Spannungsfeld:

Eine Rechtfertigung über Nötigungsnotstand nach § 34 StGB ist nicht ausgeschlossen, setzt aber eine vollständige Dokumentation der Krisenlage, der geprüften Alternativen und der Verhältnismäßigkeit voraus. Diese Dokumentation muss vor der Zahlung anwaltlich aufgesetzt werden – nicht im Nachgang als rechtfertigender Erklärungsversuch.

Hinzu treten zivilrechtliche Risiken für Geschäftsleiter: Eine voreilige oder unsauber dokumentierte Zahlung kann eine Pflichtverletzung im Sinne von § 43 GmbHG oder § 93 AktG begründen und damit zur Innenhaftung führen.

Wie kann man Lösegeld trotzdem sicher bezahlen?

In der Praxis kommt es vor, dass eine Zahlung trotz aller Empfehlungen die einzige verbleibende Option erscheint – etwa wenn unverschlüsselte Backups fehlen, eine kritische Systemausfallzeit den Bestand des Unternehmens bedroht oder Patientenversorgung, kritische Infrastruktur oder Leib und Leben Dritter betroffen sind.

In diesen Fällen darf die Entscheidung nicht ad hoc und nicht unkoordiniert fallen. Sauber strukturiert gehört dazu: ein vollständiger Sanctions‑Screen der Gegenseite über Blockchain‑Forensik (Wallet‑Attribution, OFAC/EU‑Listenabgleich), eine dokumentierte Notstandsabwägung, frühzeitige Einbindung der ZAC und der zuständigen Staatsanwaltschaft, eine forensische Beweissicherung vor jedem Eingriff in die Systeme, und – falls die Zahlung erfolgt – die Abwicklung über regulierte, KYC‑pflichtige ausländische Krypto‑Handelsplätze mit dokumentierter Mittelherkunft.

Improvisierte Zahlungen über anonyme Mixer‑Dienste oder unregulierte Börsen erhöhen das Strafbarkeitsrisiko massiv und erschweren spätere Versicherungs‑ und Steuerthemen. Wir arbeiten daher mit ausgewählten Zahlungsdienstleistern und Kryptobörsen zusammen, die auch größere Kryptotransaktionen an ggf. unsichere Wallets durchführen können.

Datenschutzrechtliche Pflichten: Art. 33 und Art. 34 DSGVO im Ransomware‑Fall

Eine Ransomware‑Attacke ist datenschutzrechtlich praktisch immer eine Verletzung des Schutzes personenbezogener Daten im Sinne von Art. 4 Nr. 12 DSGVO. Sie betrifft typischerweise alle drei Schutzziele gleichzeitig: Vertraulichkeit (durch Datenexfiltration), Integrität (durch Manipulation oder Hintertür‑Accounts) und Verfügbarkeit (durch Verschlüsselung oder Löschung).

Daraus folgen zwei zwingende Pflichten:

Art. 33 DSGVO – Meldung an die Aufsichtsbehörde innerhalb von 72 Stunden. Die Frist beginnt mit Kenntnis des Verantwortlichen vom Vorfall. Die Meldung muss eine Beschreibung der Art der Verletzung mit Angabe der Kategorien und ungefähren Zahl der Betroffenen, die Kontaktdaten des Datenschutzbeauftragten, eine Beschreibung der wahrscheinlichen Folgen und der ergriffenen Abhilfe‑ und Abmilderungsmaßnahmen enthalten. Sind die Informationen innerhalb der 72 Stunden nicht vollständig verfügbar – was bei laufender Forensik die Regel ist – kann und muss zunächst eine Erstmeldung erfolgen, ergänzt durch Folgemeldungen nach Art. 33 Abs. 4 DSGVO.

Art. 34 DSGVO – Benachrichtigung der Betroffenen bei voraussichtlich hohem Risiko. Bei Ransomware‑Vorfällen mit Abfluss von Klarnamen, Kontaktdaten, Geburtsdaten, Anschriften, Finanz‑ oder Gesundheitsdaten ist das hohe Risiko regelmäßig zu bejahen, weil hochpersonalisierte Phishing‑, Smishing‑ und Identitätsmissbrauchsangriffe drohen. Die Benachrichtigung muss in klarer, einfacher Sprache die Art der Verletzung, die wahrscheinlichen Folgen und die ergriffenen Maßnahmen sowie konkrete Verhaltensempfehlungen enthalten.

Versäumnisse bei diesen Meldepflichten werden eigenständig sanktioniert. Der Bußgeldrahmen beträgt nach Art. 83 Abs. 4 DSGVO bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes – kumulierbar mit Sanktionen wegen Verstößen gegen Art. 32 DSGVO.

Bußgeldrisiko wegen mangelhafter Datensicherheit

Die Bußgeldpraxis der europäischen Aufsichtsbehörden zeigt, dass Verstöße gegen Art. 32 DSGVO (Sicherheit der Verarbeitung) im Zusammenhang mit Ransomware‑Vorfällen zu den höchsten Sanktionen führen.

Interserve (UK, ICO, 2022): 4,4 Millionen Pfund. Der britische Information Commissioner verhängte gegen die Interserve Group ein Bußgeld in Höhe von 4,4 Millionen Pfund wegen unzureichender technischer und organisatorischer Maßnahmen, die einen Ransomware‑Angriff auf personenbezogene Daten von rund 113.000 aktuellen und ehemaligen Beschäftigten ermöglicht hatten. Ausgangspunkt war eine Phishing‑E‑Mail; das Unternehmen versäumte es, einer Antiviren‑Warnung nachzugehen, betrieb veraltete Systeme ohne hinreichende Schwachstellen‑Assessments und hatte keine ausreichende Phishing‑Schulung implementiert. Der ICO sah darin Verstöße gegen Art. 5 Abs. 1 lit. f und Art. 32 DSGVO.

Tuckers Solicitors (UK, ICO, 2022): 98.000 Pfund. Eine Anwaltskanzlei wurde vom ICO mit einem Bußgeld belegt, nachdem ein Ransomware‑Angriff über 970.000 Dateien verschlüsselt hatte, davon mehrere zehntausend mit Bezug zu Gerichtsverfahren, von denen 60 anschließend im Darknet veröffentlicht wurden. Auch hier zog der ICO unzureichende TOMs heran.

Knuddels.de (Deutschland, LfDI Baden‑Württemberg, 2018): 20.000 Euro. Die Chat‑Plattform speicherte Passwörter im Klartext; nach einem Hackerangriff wurden Daten von rund 330.000 Nutzern veröffentlicht. Das vergleichsweise niedrige Bußgeld resultierte ausdrücklich aus der vorbildlichen Kooperation mit der Aufsichtsbehörde.

AOK Baden‑Württemberg (Deutschland, 2020): 1,24 Millionen Euro. Verhängt wegen unzureichender TOMs bei der Verarbeitung von Gewinnspielteilnehmer‑Daten, die unter anderem Gesundheitsdaten umfassten.

Niedersächsischer Webshop‑Betreiber: 65.500 Euro. Wegen einer veralteten, seit 2014 nicht mehr mit Sicherheitsupdates versorgten Webshop‑Software, die einen Klartext‑Abgriff von Kundenpasswörtern ermöglichte.

Die Linie der Aufsichtsbehörden ist klar: Geahndet wird nicht der Angriff selbst, sondern das Versagen der Schutzvorkehrungen. Ein vollständig dokumentiertes TOM‑Konzept, Penetrationstests aktuellen Datums, ein gelebtes Incident‑Response‑Verfahren und eine professionelle, schnelle Kommunikation mit der Aufsicht senken das Bußgeld nachweislich – das ist im Knuddels‑Fall ebenso dokumentiert wie im Interserve‑Verfahren, in dem die nachträglichen Investitionen in Sicherheit ausdrücklich strafmildernd berücksichtigt wurden.

Was tun bei Ransomware? Schnelle Hilfe innerhalb von 24 Stunden

Ein Ransomware‑Vorfall in einer AWS‑Umgebung ist kein IT‑Problem, das anschließend juristisch bewertet wird. Es ist von der ersten Stunde an eine Rechtsfrage, in der jede technische Entscheidung – Snapshot ja oder nein, IAM‑Key sofort deaktivieren oder beobachten, Backdoor‑Account löschen oder forensisch konservieren, Lösegeldverhandlung aufnehmen oder ablehnen – unmittelbare straf‑, datenschutz‑ und haftungsrechtliche Konsequenzen hat. Ohne anwaltliche Steuerung werden in den ersten Stunden regelmäßig Beweismittel vernichtet, Meldefristen versäumt und Haftungsrisiken aufgebaut, die später nicht mehr zu reparieren sind.

Maisch.law Rechtsanwälte ist auf genau diese Konstellation spezialisiert. Als IT‑rechtlich ausgerichtete Kanzlei mit Schwerpunkten im Cybercrime‑Recht, im Datenschutzrecht und in der forensischen Aufarbeitung kryptobasierter Geldflüsse begleiten wir Unternehmen 24/7 durch die akute Krisenphase.

Im Notfall stellen wir innerhalb weniger Stunden ein kompaktes Krisenteam: einen anwaltlichen Krisenmanager als zentrale Steuerungsfunktion, IT‑forensische Spezialisten zur beweissicheren Aufarbeitung des Vorfalls, blockchain‑forensische Expertise zur Attribution etwaiger Lösegeldforderungen und – sofern eine Zahlung trotz aller Bedenken erwogen wird – eine rechtssichere Strukturierung über regulierte ausländische Krypto‑Handelsplätze mit vollständiger Sanktionsprüfung und Notstandsdokumentation.

Konkret übernimmt die Kanzlei für Sie:

Die unverzügliche Strafanzeige bei der zuständigen Zentralen Ansprechstelle Cybercrime (ZAC) beim Landeskriminalamt sowie die fortlaufende Kommunikation mit der ermittelnden Cybercrime‑Dienststelle und ggf. den Cybercrime‑Schwerpunktstaatsanwaltschaften. Diese Kommunikation ist nicht nur strafprozessual relevant, sondern hat im Rahmen einer späteren Notstandsargumentation und gegenüber Cyberversicherern erheblichen Wert.

Die Erstmeldung nach Art. 33 DSGVO innerhalb der 72‑Stunden‑Frist sowie die Steuerung sämtlicher Folgemeldungen an die zuständige Datenschutzaufsicht. Wir formulieren Meldung und Folgemeldungen so, dass forensische Restunsicherheiten transparent und ohne unnötige Selbstbelastung dargestellt werden – ein Punkt, an dem laienhaft formulierte Meldungen regelmäßig erhebliche Bußgeldrisiken aufbauen.

Die Benachrichtigung der Betroffenen nach Art. 34 DSGVO in einer rechtssicheren, juristisch geprüften Fassung, die zugleich dem Reputationsschutz Rechnung trägt und Folgehaftung gegenüber Betroffenen vermeidet.

Die Koordination mit dem AWS Customer Incident Response Team und der parallel arbeitenden eigenen oder externen IT‑Forensik, einschließlich der Klärung, welche AWS‑Service‑Logs (CloudTrail, VPC Flow Logs, GuardDuty‑Findings, Cognito‑Auditprotokolle) wie lange aufbewahrt und wie beweissicher exportiert werden müssen.

Die anwaltliche Begleitung der internen Kommunikation an Geschäftsleitung, Aufsichtsrat, Mitarbeiter, Kunden und Investoren – ein Bereich, in dem unkoordinierte Stellungnahmen regelmäßig die spätere Verteidigungsposition schwächen.

Die Schadensregulierung mit der Cyberversicherung, einschließlich der Prüfung von Deckungsausschlüssen wegen vermeintlich grob fahrlässiger Sicherheitsmängel.

Die strafrechtliche Verteidigung der Geschäftsleitung, sollte es im Nachgang zu Ermittlungsverfahren wegen § 129 StGB, § 18 AWG, § 43 GmbHG oder § 203 StGB kommen.

In zahlreichen Mandaten zur Aufarbeitung kryptobasierter Vermögensabflüsse arbeiten wir eng mit dem Forensik‑Spezialisten Timo Züfle (Crypto‑Tracing.com) zusammen, dessen Wallet‑Attributionen regelmäßig in Strafverfahren und Zivilrechtsdurchsetzung Eingang finden.

Fazit: Vorbereitung schlägt Improvisation

Cloud‑Ransomware in AWS folgt heute einem industrialisierten Muster: Credential‑Leak, IAM‑Eskalation, Recon, Exfiltration, Persistenz, Verschlüsselung, Erpressung. Wer die Antwort auf diesen Ablauf erst im Krisenfall improvisiert, verliert in den ersten 24 Stunden Zeit, Beweise und Verhandlungsposition. Wer hingegen einen vorbereiteten Notfallplan, klare Meldewege und einen 24/7 erreichbaren Krisen‑Anwalt im Hintergrund hat, behandelt den Vorfall wie das, was er ist: ein steuerbares Großschadensereignis.

Wenn Sie bereits betroffen sind oder sich auf den Ernstfall vorbereiten möchten, ist unsere Notfallnummer rund um die Uhr erreichbar. Maisch.law Rechtsanwälte – IT‑Recht, Datenschutz, Cybercrime.

Checkliste: Was tun bei Ransomware Angriff auf AWS

Checkliste First Incident Response: Ransomware‑Angriff auf AWS‑Cloud
Für Unternehmer und Geschäftsleitung. Stand: Mai 2026.
Erstellt von Rechtsanwalt Dr. Marc Maisch, Maisch.law Rechtsanwälte, München.



Phase 1 – Sofort (Minute 0 bis 60)

Ruhe bewahren, nicht improvisieren. Keine vorschnellen Löschungen, keine Reboots, keine Snapshots überschreiben. Jede technische Handlung kann Beweismittel vernichten.
Vorfallsbeginn dokumentieren. Datum, Uhrzeit, Entdecker, erste Beobachtungen schriftlich festhalten (Word, Notizbuch, separates Gerät – nicht im potenziell kompromittierten System).
Krisenanwalt kontaktieren. Maisch.law Rechtsanwälte, 24/7‑Notfallnummer. Vor jeder weiteren externen Kommunikation. Anwaltliche Verschwiegenheit schützt die folgende Lagebewertung.
Internen Krisenstab einberufen. Geschäftsleitung, IT‑Leitung, Datenschutzbeauftragter, ggf. CISO. Schriftliche Aufgabenverteilung.
Out‑of‑Band‑Kommunikation einrichten. Keine Kommunikation mehr über potenziell kompromittierte Kanäle (Firmen‑Mail, Teams, Slack). Wechsel auf Mobiltelefon, Signal oder vergleichbare Kanäle.
AWS Support Case eröffnen (Schweregrad: Critical). Aktivierung des AWS Customer Incident Response Team (CIRT).

Phase 2 – Beweissicherung (Stunde 1 bis 6)

Keine kompromittierten Ressourcen löschen. Backdoor‑Accounts, neu angelegte IAM‑User, verdächtige EC2‑Instanzen zunächst isolieren (Security Group restriktiv setzen), nicht entfernen.
CloudTrail‑Logs sichern über den gesamten verdächtigen Zeitraum (mindestens 90 Tage rückwirkend). Export in beweissicheres Format.
VPC Flow Logs, GuardDuty‑Findings, Cognito‑Auditprotokolle, Secrets Manager‑Zugriffshistorie exportieren und außerhalb des kompromittierten AWS‑Accounts sichern.
RDS‑Snapshots und EBS‑Snapshots des aktuellen Zustands anfertigen, bevor Recovery‑Maßnahmen beginnen. Snapshots in separaten AWS‑Account oder Region verschieben.
IAM Credential Report ziehen und sichern.
Erpresserschreiben, Chat‑Verläufe, Lösegeldforderungen vollständig sichern. Hashes, Wallet‑Adressen, Tor‑URLs notieren. Nicht anklicken, nicht antworten.


Phase 3 – Eindämmung (Stunde 1 bis 12)

Kompromittierte Access Keys deaktivieren (nicht löschen – das vernichtet CloudTrail‑Korrelationen).
Aktive Sessions revozieren über aws iam delete-login-profile und Policy‑Anpassung.
Manipulierte VPC‑Routen und Security Groups zurücksetzen.
Angreifer‑IP‑Adressen blockieren (WAF, Security Groups, NACL).
MFA für sämtliche IAM‑User und Root‑Account erzwingen.
Datenbank‑Credentials und Application‑Secrets rotieren (RDS Master Passwords, API‑Keys, Cognito‑Client‑Secrets).
Backups verifizieren. AWS Automated Backups, S3‑Object‑Versioning, AWS Backup‑Recovery‑Points. Integrität prüfen, bevor Recovery startet.
Persistenzartefakte suchen. Neu angelegte IAM‑User, Rollen, Access Keys, Lambda‑Trigger, Cognito‑App‑Clients, KMS‑Keys mit externem Material, ungewöhnliche EventBridge‑Regeln.


Phase 4 – Meldepflichten (Stunde 0 bis 72)

DSGVO‑Erstmeldung nach Art. 33 DSGVO an die zuständige Datenschutzaufsicht – Frist: 72 Stunden ab Kenntnis. Nicht abwarten, bis alles geklärt ist; Erstmeldung mit Folgemeldungen nach Art. 33 Abs. 4 DSGVO ist zulässig und üblich. Maisch.law übernimmt Formulierung und Einreichung.
Strafanzeige bei der Zentralen Ansprechstelle Cybercrime (ZAC) beim zuständigen Landeskriminalamt. Wichtig für spätere Notstandsargumentation und Versicherungsdeckung.
Information des BSI über die Allianz für Cyber‑Sicherheit (sofern KRITIS, NIS2‑pflichtig oder freiwillig).
NIS2‑Meldung (falls anwendbar): Frühwarnung an BSI innerhalb von 24 Stunden, Vorfallsmeldung innerhalb von 72 Stunden.
Bewertung Art. 34 DSGVO – Betroffenenbenachrichtigung. Bei Datenabfluss mit hohem Risiko zwingend. Inhalt, Zeitpunkt und Form anwaltlich abstimmen, bevor Mitteilungen rausgehen.
Cyberversicherung informieren innerhalb der vertraglich vereinbarten Frist (oft 24 bis 72 Stunden). Deckungsausschlüsse prüfen lassen, bevor Mitteilungen erfolgen.
Aufsichtsbehörden im regulierten Umfeld: BaFin (Finanzsektor), Bundesnetzagentur (TK/KRITIS), Landesärztekammer (Gesundheitsdaten) je nach Branche.


Phase 5 – Lösegeldfrage (vor jeder Entscheidung)

Keine eigenständige Kontaktaufnahme zu Erpressern. Verhandlung ausschließlich über spezialisierten Krisenanwalt oder beauftragten Ransomware‑Negotiator.
Strafrechtliche Risikoanalyse durch Maisch.law vor jeder Zahlungsentscheidung: § 129/§ 129b StGB, § 18 AWG, § 261 StGB, § 89c StGB, § 43 GmbHG / § 93 AktG.
Sanctions‑Screening der Wallet‑Adresse über Blockchain‑Forensik (Wallet‑Attribution, OFAC‑/EU‑Cyber‑Sanktionslistenabgleich).
Notstandsdokumentation nach § 34 StGB anwaltlich vorbereiten. Geprüfte Alternativen, Verhältnismäßigkeit, Existenzgefährdung, Schutz von Leib und Leben Dritter dokumentieren – vor Zahlung, nicht nach.
Bei Zahlung: ausschließlich über regulierte, KYC‑pflichtige ausländische Krypto‑Handelsplätze mit dokumentierter Mittelherkunft. Keine Mixer, keine unregulierten Börsen.
Gesellschaftsrechtliche Absicherung: Beschluss der Geschäftsleitung, ggf. Zustimmung des Aufsichtsrats oder Gesellschafterversammlung dokumentieren.


Phase 6 – Recovery (Stunde 12 bis Tag 7)

Recovery aus unangetasteten AWS Automated Backups, AWS Backup oder Elastic Disaster Recovery. Vor Restore: Backups auf Kompromittierung prüfen.
Neuaufsetzen kompromittierter Systeme, nicht bloßes Bereinigen. Bei Verdacht auf tiefe Persistenz: komplette AWS‑Account‑Neueinrichtung.
IAM‑Hardening: Wechsel auf kurzlebige Credentials (IAM Roles, STS), Least‑Privilege‑Policies, SCP‑Restriktionen, AWS Organizations‑Trennung.
Telemetrie nachschärfen: CloudTrail in allen Regionen aktivieren, GuardDuty, Security Hub, AWS Config, VPC Flow Logs, RDS‑Audit‑Logging (log_statement=all für sicherheitskritische DBs).
Penetrationstest der wiederhergestellten Umgebung vor Produktiv‑Schaltung.


Phase 7 – Kommunikation (parallel ab Stunde 6)

Externe Kommunikation ausschließlich anwaltlich abgestimmt. Pressemitteilung, Kunden‑E‑Mails, Investor‑Updates, Social‑Media‑Postings vorab juristisch prüfen.
Mitarbeiter‑Kommunikation: klare interne Sprachregelung, Sensibilisierung für Social Engineering im Nachgang, Vertraulichkeitshinweis.
Reputationsmanagement: keine Schuldzuweisungen, keine voreiligen Schadensangaben, keine Festlegungen zu noch unklaren Fakten.
Vermeidung von Selbstbelastung in öffentlichen Stellungnahmen – jede öffentliche Aussage kann in DSGVO‑Bußgeldverfahren oder Strafverfahren gegen die Geschäftsleitung verwertet werden.


Phase 8 – Nachbereitung (Tag 7 bis Monat 3)

Folgemeldungen an die Datenschutzaufsicht nach Art. 33 Abs. 4 DSGVO bis zur vollständigen Aufklärung.
Lessons‑Learned‑Bericht anwaltlich begleitet erstellen. Vorsicht: dieses Dokument kann beschlagnahmt werden – Formulierung mit Bedacht.
TOM‑Dokumentation aktualisieren (Art. 32 DSGVO). Aufsichtsbehörden fragen zwingend nach.
Incident‑Response‑Plan überarbeiten auf Basis der konkreten Erfahrungen.
Schulungen für Mitarbeiter und IT‑Team (Phishing, Cloud‑Security, IAM‑Hygiene).
Versicherungsabwicklung abschließen, Regressansprüche prüfen (z. B. gegen Auftragsverarbeiter, Software‑Hersteller).
Strafverteidigung der Geschäftsleitung falls Ermittlungsverfahren wegen § 129 StGB, § 18 AWG, § 43 GmbHG eingeleitet werden.

Kritische Fehler, die Sie unbedingt vermeiden müssen:

✗ Backdoor‑Accounts vorschnell löschen, bevor sie forensisch dokumentiert sind. ✗ Snapshots der gelöschten RDS‑Instanzen entsorgen. ✗ Eigenständig mit Erpressern in Kontakt treten. ✗ Lösegeld zahlen ohne anwaltliche Notstandsdokumentation und Sanctions‑Screening. ✗ Öffentliche Schuldeingeständnisse vor abgeschlossener forensischer Analyse. ✗ Meldefristen nach Art. 33 DSGVO verstreichen lassen, weil „die Faktenlage noch unklar“ ist. ✗ Mitarbeiter ohne Vertraulichkeitshinweis informieren. ✗ Cyberversicherung verspätet einbinden – Deckungsausschluss droht.

Notfallkontakt bei Ransomware-Angriff:

Maisch.law Rechtsanwälte – 24/7 im Krisenfall Rechtsanwalt Dr. Marc Maisch, Fachanwalt für IT‑Recht München | maisch.law

Was Maisch.law in den ersten Stunden übernimmt:

Krisenmanager und Lagebewertung • Koordination von IT‑Forensik und Blockchain‑Forensik • Erst‑ und Folgemeldungen nach Art. 33 DSGVO • Betroffenenbenachrichtigung nach Art. 34 DSGVO • Strafanzeige bei ZAC und LKA • Kommunikation mit Cybercrime‑Schwerpunktstaatsanwaltschaft • Strafrechtliche Risikoanalyse Lösegeldzahlung • Strafverteidigung der Geschäftsleitung .

marc.maisch 132 Bewertungen auf ProvenExpert.com