1993 bezeichneten Kryptographen dies als „den einfachsten Angriff überhaupt“: Man nimmt eine gültige Nachricht, wartet und sendet sie erneut. Niemand baut einen Tresor in der Erwartung, dass der Schlüssel wiederverwendet wird.
Genau das geschah aber bei der Trennung von Ethereum und Ethereum Classic: Dieselbe signierte Transaktion wurde auf zwei Blockchains übertragen und transferierte zweimal echtes Geld. Kein Hack, kein gestohlenes Passwort, kein Phishing-Link.
Ein sich wiederholender Angriff, der das tut, was er schon immer getan hat: Legitimität als Waffe einsetzen.
Treten Sie UEEx bei
Erleben Sie die weltweit führende digitale Vermögensverwaltungsplattform
Was ist ein Replay-Angriff (Wiederholungsangriff)?
Ein Replay-Angriff ist eine Art von Sicherheitsverletzung im Netzwerk, bei der ein Angreifer gültige Datenübertragungen abfängt und sie in böswilliger Absicht wiederverwendet oder erneut sendet, um ein System zu täuschen.
Im Gegensatz zu Angriffen, bei denen Daten verändert oder gefälscht werden, werden bei einem Replay-Angriff lediglich zuvor erfasste Informationen wie Anmeldeinformationen, Authentifizierungstoken oder Transaktionsanforderungen erneut übertragen, um ein System glauben zu machen, es empfange einen neuen, legitimen Befehl.
Bitte beachten Sie: Ein Replay-Angriff (Wiederholungsangriff) kann auf derselben Kette oder auf einer kettenübergreifenden Kette erfolgen.
Worin besteht der Unterschied zwischen einem Replay-Angriff innerhalb derselben Kette und einem Replay-Angriff über Ketten hinweg?
Bei einem Same-Chain-Replay-Angriff handelt es sich um einen Angriff innerhalb einer Blockchain: Dieselbe signierte Transaktion oder Nachricht wird mehrfach an dasselbe Netzwerk übermittelt.
Der Nonce-Mechanismus verhindert dies bei Standard-Ethereum-Transaktionen; sobald eine Nonce (eine einmal verwendete Zahl) verbraucht ist, wird dieselbe Transaktion abgelehnt.
Cross-Chain-Replay-Angriffe erfolgen zwischen zwei Blockchains, die Adressformate und Signaturlogik gemeinsam nutzen – am häufigsten nach einer Hard Fork.
Die Nonce (eine einmalig verwendete Nummer) ist hier nicht hilfreich, da die beiden Blockchains die Nonces unabhängig voneinander verwalten. Eine Transaktion mit der Nonce 5 auf Ethereum und eine mit der Nonce 5 auf Ethereum Classic sind zwar unterschiedliche Datensätze auf den verschiedenen Systemen, die signierten Transaktionsdaten sind jedoch identisch.
Die Chain-ID von EIP-155 behebt das Problem der kettenübergreifenden Wiedergabe. Der Domänentrenner von EIP-712 unterstützt bei der Verifizierung von Smart-Contract-Signaturen sowohl Varianten innerhalb derselben Kette als auch kettenübergreifende Varianten.
Treten Sie UEEx bei
Erleben Sie die weltweit führende digitale Vermögensverwaltungsplattform
Wann Replay-Angriffe tatsächlich stattfanden: Drei dokumentierte Fälle
Replay-Angriffe in Blockchains sind keine Theorie. Sie haben in mehreren Fällen nachweislich finanzielle Verluste verursacht.
Die Ethereum/Ethereum Classic-Abspaltung – 2016
Als sich das Ethereum-Netzwerk nach dem DAO-Hack in Ethereum (ETH) und Ethereum Classic (ETC) aufspaltete, war jede Transaktion, die vor der Aufspaltung signiert wurde, auf beiden Ketten gültig.
Die beiden Blockchains verwendeten identische Adressräume, Transaktionsformate und Logiken zur Signaturverifizierung.
Eine von einer beliebigen Wallet signierte Transaktion war gleichzeitig eine gültige Transaktion sowohl auf ETH als auch auf ETC.
Börsen, die ETH- und ETC-Kundengelder verwahrten, gerieten sofort ins Visier.
Angreifer fingen gültige ETH-Auszahlungstransaktionen ab und spielten sie auf der ETC-Blockchain nach – wodurch ETC-Guthaben abgezogen wurden, die die Benutzer gar nicht anfassen wollten.
Über 40,000 ETC wurden in der Zeit nach der Abspaltung von den Börsen abgezogen, bevor der Schutz vor Replay-Angriffen flächendeckend eingeführt wurde.
Dieses Ereignis gab unmittelbar Anlass zur Erstellung von EIP-155.
Die Ethereum-Fusion – 2022
Als Ethereum von Proof of Work auf Proof of Stake umstellte (The Merge), entstand eine abgespaltene Blockchain namens Ethereum. PoW (ETHW) wurde erstellt.
Innerhalb weniger Tage nutzte ein Angreifer den Omni Bridge Cross-Chain-Vertrag aus, der keinen ETHW-spezifischen Replay-Schutz bot, und spielte Transaktionen nach, die 200 ETHW vom Bridge-Vertrag übertrugen.
Der Angreifer nutzte im Rahmen des Exploits Preisdaten des ETH-Mainnet-Orakels auf der ETHW-Chain, wo diese veraltet und manipulierbar waren.
Der Diebstahl des Optimism OP-Tokens – 2022
Bei einem Cross-Chain-Replay-Vorfall wurden OP-Token im Wert von 20 Millionen US-Dollar von Optimism während einer umstrittenen Multisignatur-Transaktionssequenz gestohlen.
Der Angriff nutzte die Lücke zwischen den Kettenkontexten L1 (Ethereum) und L2 (Optimism) aus, wobei durch die Wiedergabe einer bestimmten signierten Nachricht auf der falschen Kette Token ohne Autorisierung verschoben wurden.
Dies sind keine Einzelfälle. Sie stellen ein dokumentiertes Muster dar: Jedes Mal, wenn ein neuer Fork oder eine L2-Bereitstellung zwei Umgebungen erzeugt, die Adress- oder Signaturformate ohne kettenspezifische Bindung gemeinsam nutzen, besteht ein Replay-Risiko.
Erinnern Sie sich an das letzte Mal, als eine neue Blockchain mit derselben Ethereum-Adresse gestartet wurde? Haben Sie überprüft, ob Ihre bestehenden signierten Autorisierungen auf dieser neuen Blockchain gültig waren? Haben Sie sichergestellt, dass das Signaturverfahren Ihrer Wallet EIP-155 enthielt? Die meisten Nutzer haben das nicht getan. Den meisten ging es gut. Doch diejenigen, die nicht aufgepasst haben, verloren echtes Geld – und keiner von ihnen hatte damit gerechnet.
EIP-155, eingeführt vom Ethereum-Mitbegründer Vitalik Buterin im Jahr 2016, wurde speziell entwickelt, um zu verhindern, dass Transaktionen über Fork-Chains hinweg wiederholt werden.
Die Lösung war im Prinzip einfach: Man musste lediglich die eindeutige Kennung der Blockchain (chainId) in jede Transaktionssignatur einbetten.
Vor EIP-155 umfasste eine Transaktionssignatur sechs Datenfelder: Nonce, Gaspreis, Gaslimit, Empfängeradresse, Wert und Daten.
Die Signatur war auf jeder EVM-kompatiblen Blockchain gültig, die dieselbe Verifizierungslogik verwendete, da keines dieser Felder angab, für welche spezifische Blockchain die Transaktion bestimmt war.
Nach EIP-155 enthalten Transaktionen drei zusätzliche Felder im Signatur-Hash: chainId und zwei leere Platzhalterwerte.
Eine für eine Transaktion unterzeichnete Transaktion Ethereum Mainnet (chainId = 1) ist keine gültige Signatur auf Optimism (chainId = 10), Polygon (chainId = 137) oder irgendeiner anderen EVM-Chain.
Der Knoten, der die Transaktion empfängt, prüft die Chain-ID anhand seiner eigenen und weist jede Abweichung zurück.
Diese einzelne Änderung hat die Anzahl kettenübergreifender Replay-Angriffe bei Standardtransaktionen deutlich reduziert.
Die wichtige Einschränkung: EIP-155 schützt nur unverarbeitete Ethereum-Transaktionen.
Es schützt keine Signaturen auf Anwendungsebene, also die signierten Nachrichten, die Smart Contracts intern mithilfe der ecrecover-Funktion überprüfen.
Ein Vertrag, der Off-Chain-Signaturen validiert, ohne die Chain-ID zu prüfen, ist selbst bei vollständiger Implementierung von EIP-155 auf Transaktionsebene weiterhin anfällig für Replay-Angriffe. Hier setzt EIP-712 an.
Der Nonce – Wie er Wiederholungen innerhalb derselben Kette verhindert
Die Nonce (eine einmalig verwendete Nummer) ist der Mechanismus, der Replay-Angriffe innerhalb derselben Blockchain verhindert. Jedes Ethereum-Konto verwaltet einen Zähler, der bei 0 beginnt und sich mit jeder gesendeten Transaktion um 1 erhöht.
Wenn Sie eine Transaktion mit Nonce = 5 einreichen, akzeptiert das Netzwerk diese nur, wenn die Nonce Ihres aktuellen Kontos genau 5 beträgt.
Sobald die Transaktion verarbeitet wurde, ändert sich Ihre Konto-Nonce auf 6, und jeder Versuch, die Nonce-5-Transaktion zu wiederholen, schlägt fehl, da das Netzwerk nun die Nonce 6 erwartet.
Deshalb kann man dieselbe Ethereum-Transaktion nicht zweimal auf derselben Blockchain senden: Die Nonce verhindert dies. Der Haken an der Sache, den Gate.io in seiner Analyse vom März 2026 aufzeigte: Eine Nonce allein verhindert zwar Wiederholungen innerhalb derselben Blockchain, nicht aber kettenübergreifende Wiederholungen, da verschiedene Blockchains separate Nonce-Zähler verwalten.
Ihre Konto-Nonce im Ethereum-Mainnet und Ihre Konto-Nonce in Ethereum Classic werden unabhängig voneinander verfolgt.
Eine Transaktion mit Nonce = 5 auf Ethereum kann auch auf Ethereum Classic dieselbe Nonce = 5 haben, wenn auf beiden Blockchains die gleiche Anzahl an Transaktionen durchgeführt wurde. EIP-155 schließt diese Lücke, indem die Chain-ID Teil der Signatur selbst wird.
Treten Sie UEEx bei
Erleben Sie die weltweit führende digitale Vermögensverwaltungsplattform
EIP-155 hat Replay-Angriffe auf Transaktionsebene gelöst. Es hilft jedoch nicht bei der Verifizierung von Smart-Contract-Signaturen.
Wenn ein Smart Contract ecrecover zur Validierung einer Off-Chain-Signatur verwendet, verifiziert er eine Nachricht, nicht eine Transaktion. Der Chain-ID-Schutz von EIP-155 bezieht sich auf die Ethereum-Transaktion, die die Nachricht enthält, nicht auf den Nachrichteninhalt selbst.
Wenn ein Entwickler einen Vertrag erstellt, der Signaturen validiert, ohne die chainId, die Vertragsadresse und die Nonce in die signierten Daten aufzunehmen, können diese Signaturen von jedem, der sie abfängt, wiederholt werden.
EIP-712 (Typed Structured Data Signing) befasst sich mit diesem Thema. Es definiert eine Standardmethode zur Strukturierung signierter Nachrichten, die ein Domänentrennzeichen, einen Hash mit der Chain-ID, die Adresse des verifizierenden Vertrags sowie den Namen und die Version des Vertrags enthält.
Eine gemäß EIP-712 erstellte Signatur ist an einen bestimmten Vertrag an einer bestimmten Adresse in einer bestimmten Blockchain gebunden.
Es kann nicht auf einer anderen Blockchain oder einem anderen Vertrag wiederholt werden, selbst wenn der Bytecode identisch ist.
Für Entwickler: Bevor Sie einen Smart Contract bereitstellen, der Off-Chain-Signaturen verifiziert, stellen Sie sicher, dass Ihr Signaturverfahren alle drei Elemente enthält: Nonce (verhindert die Wiederverwendung derselben Nachricht), Chain-ID (verhindert kettenübergreifende Replay-Angriffe) und Vertragsadresse (verhindert vertragsübergreifende Replay-Angriffe). Die ECDSA-Bibliothek von OpenZeppelin ab Version 4.7.3 implementiert alle drei Elemente korrekt.
Systeme und Protokolle, die anfällig für Replay-Angriffe sind
Zielsystem / Protokoll
Warum es angreifbar ist
Häufige Beispiele und Fehler
Drahtlose Netzwerke
Die Übertragung über offenes Gelände ermöglicht das einfache Abfangen und Weiterleiten von Daten.
Veraltetes Wi-Fi (WEP/schwaches WPA) ohne Paketsequenzierung; Bluetooth-Geräte ohne Nonce-Validierung oder Sitzungskopplung.
Kryptografische Protokolle
Verwendet statische Schlüssel oder verfügt nicht über kontextbezogene Aktualitätsprüfungen.
Kerberos oder OAuth, wenn Sitzungstoken oder Anmeldeinformationen keine strengen Zeitstempel und Ablaufregeln aufweisen.
Internet der Dinge (IoT)
Der Fokus liegt auf niedrigem Stromverbrauch und Benutzerfreundlichkeit, nicht auf robuster Sicherheit.
Intelligente Schlösser und Kameras, die IoT-Protokolle (MQTT, CoAP) nutzen, verfügen aufgrund begrenzter Rechenleistung über keinen integrierten Replay-Schutz.
Zahlungssysteme
Anfällig, wenn Transaktionen keine dynamischen, einmalig verwendbaren Authentifizierungscodes verwenden.
Ältere kontaktlose Karten und POS-Terminals ohne EMV-Kryptogramme oder Transaktionstoken.
1. Zeitstempelvalidierung und Protokollüberwachung
Replay-Angriffe verwenden häufig Daten wieder, ohne deren ursprünglichen Zeitstempel zu verändern.
Durch die Überwachung und Validierung von Zeitstempeln können Systeme erkennen, wenn Nachrichten unerwartet verzögert werden oder außerhalb eines akzeptablen Zeitfensters liegen.
Implementieren Sie strenge zeitbasierte Gültigkeitsprüfungen für Token, Transaktionen und API-Aufrufe.
Markieren Sie Nachrichten, die offenbar verzögert oder außerhalb der normalen Sitzungsdauer verarbeitet werden.
Vergleichen Sie die Systemprotokolle, um Anfragen mit identischen Zeitstempeln zu identifizieren, die mehr als einmal vorkommen.
2. Erkennung doppelter Nachrichten
Ein zentrales Merkmal von Replay-Angriffen ist die Wiederholung identischer Nachrichten oder Pakete.
Systeme sollten auf solche Muster achten, insbesondere in kritischen Bereichen wie Authentifizierung, Finanztransaktionen und Sitzungsverwaltung.
Verwenden Sie Hashing oder Fingerprinting, um doppelte Pakete oder Anfragen zu erkennen.
Vergleichen Sie eingehende Daten mit kürzlich verarbeiteten Einträgen, um nach wiederholten Inhalten zu suchen.
Protokollieren und untersuchen Sie wiederholte Sitzungstoken, API-Aufrufe oder verschlüsselte Nutzdaten.
3. Sequenznummern- und Nonce-Verfolgung
Sichere Systeme verwenden häufig Sequenznummern oder Nonces (einmalig verwendete Nummern), um die Eindeutigkeit von Daten zu verfolgen und zu bestätigen.
Wiederholte Nachrichten verwenden in der Regel dieselbe Nonce oder Sequenznummer, die gekennzeichnet werden kann.
Behalten Sie einen Kurzzeitspeicher (Cache oder Datenbank) der zuletzt verwendeten Nonces oder Sequenznummern.
Löschen oder protokollieren Sie Anforderungen, die wiederverwendete Werte enthalten.
Warnmeldung zu Sitzungstoken oder Anforderungskennungen, die bereits verarbeitet wurden.
4. Erkennung von Verhaltensanomalien
Replay-Angriffe sind nicht immer technische Duplikate; manchmal kann der Verhaltenskontext die Bedrohung aufdecken.
Ein Benutzer, der beispielsweise innerhalb weniger Sekunden zweimal exakt dieselbe Transaktion durchführt, könnte verdächtig wirken.
Überwachen Sie das Benutzerverhalten und erstellen Sie Basisprofile für normale Aktivitäten.
Markieren Sie abnormale Muster wie häufig wiederholte Aktionen, identische Anfragen von verschiedenen IPs oder mehrere Anmeldungen mit demselben Token.
Integrieren Sie Anomalieerkennungssysteme, die typische Verkehrsmuster erlernen und sich daran anpassen können.
5. Analyse des Netzwerkverkehrs
Erweiterte Erkennungstools können den Netzwerkverkehr in Echtzeit analysieren, um nach verdächtigen Mustern zu suchen, insbesondere in drahtlosen oder IoT-Umgebungen, in denen Replay-Angriffe häufig vorkommen.
Verwenden Sie Intrusion Detection Systems (IDS) oder Wireless Intrusion Prevention Systems (WIPS), um verdächtige erneute Paketübertragungen zu erkennen.
Analysieren Sie Paket-Header auf wiederverwendete Kennungen, Nonces oder Verschlüsselungsparameter.
Achten Sie auf sich wiederholende verschlüsselte Nutzdaten, die sich zwischen den Sitzungen nicht ändern.
6. Analyse von Sitzungstoken und Authentifizierungsprotokollen
Bei Replay-Angriffen werden häufig Authentifizierungstoken wiederverwendet. Systeme sollten die Protokolle zur Token-Ausgabe und -Nutzung prüfen und analysieren, um Token zu identifizieren, die wiederverwendet oder missbraucht werden.
Verfolgen Sie die Lebensdauer von Sitzungstoken und die zugehörigen IP-/Geräteinformationen.
Protokollieren Sie Versuche, abgelaufene oder bereits verbrauchte Authentifizierungsdaten wiederzuverwenden.
Untersuchen Sie Anmeldeversuche, bei denen Header, Metadaten oder Sitzungsdetails wiederverwendet werden.
Was ist der Unterschied zwischen einem Replay-Angriff und einem MITM-Angriff?
Bei einem Replay-Angriff werden gültige Daten erfasst und erneut gesendet, um ein System auszutricksen, während bei einem Man-in-the-Middle-Angriff (MitM) die Kommunikation zwischen zwei Parteien in Echtzeit aktiv abgefangen und verändert wird.
Welche Pakettypen werden bei einem Replay-Angriff am häufigsten erfasst?
Zu den häufigsten Pakettypen, die bei einem Replay-Angriff erfasst werden, gehören Authentifizierungsanforderungen, Sitzungstoken, Transaktionsnachrichten und Steuerbefehle, die in der drahtlosen oder Netzwerkkommunikation verwendet werden.
Wie verhindert TLS einen Replay-Angriff?
TLS verhindert Replay-Angriffe durch die Verwendung eindeutiger Sitzungsschlüssel, Sequenznummern und Message Authentication Codes (MACs), um sicherzustellen, dass jede Nachricht aktuell ist und nicht unbemerkt erneut gesendet oder geändert werden kann.
Was ist ein Kerberos-Replay-Angriff?
Ein Kerberos-Replay-Angriff liegt vor, wenn ein Angreifer eine gültige Kerberos-Authentifizierungsnachricht abfängt und erneut sendet, um das System dazu zu bringen, unbefugten Zugriff zu gewähren, ohne sich erneut zu authentifizieren.
Treten Sie UEEx bei
Erleben Sie die weltweit führende digitale Vermögensverwaltungsplattform
Replay-Angriffe mögen simpel erscheinen, doch ihre Auswirkungen können gravierend sein und von unberechtigtem Zugriff über finanzielle Verluste bis hin zu Serviceausfällen reichen.
Es ist unerlässlich, anfällige Systeme zu erkennen, zu verstehen, wie diese Angriffe funktionieren, und mehrschichtige Schutzmechanismen wie Nonces, Zeitstempel und Verschlüsselung anzuwenden.
Da Bedrohungen weiterhin auf Schwachstellen in Verifizierungsprozessen abzielen, sind eine frühzeitige Erkennung und Prävention von entscheidender Bedeutung.
Die Stärkung von Systemen gegen Replay-Angriffe dient nicht nur dem Schutz; es geht darum, Vertrauen, Datenintegrität und einen konsistenten Service in digitalen Umgebungen zu gewährleisten, in denen die Sicherheit nicht beeinträchtigt werden darf.
Akindele T. Francis ist ein vielseitiger Content-Autor mit umfassender Branchenerfahrung. Er ist spezialisiert auf Blogbeiträge, Website-Inhalte, Serviceseiten, überzeugende Verkaufstexte usw. und hat mit zahlreichen Agenturen zusammengearbeitet, um ansprechende und effektive Texte zu erstellen. Mit einem scharfen Auge für Details und einer Leidenschaft für die Gestaltung wirkungsvoller Geschichten übertrifft Akindele stets die Erwartungen seiner Kunden, erzielt Ergebnisse und verbessert die Markenbotschaft auf verschiedenen Plattformen.
Disclaimer: Dieser Artikel dient ausschließlich Informationszwecken und stellt keine Handels- oder Anlageberatung dar. Nichts hierin ist als Finanz-, Rechts- oder Steuerberatung zu verstehen. Der Handel mit oder die Investition in Kryptowährungen birgt ein erhebliches Risiko finanzieller Verluste. Treffen Sie stets eine sorgfältige Prüfung, bevor Sie Handels- oder Anlageentscheidungen treffen.
