Größte Krypto-Zahlungs-Hacks & die darunter liegende Angriffsfläche

Ihr Zahlungssystem existiert, um Geld zu bewegen — genau deshalb sind Hot Wallets, Signing-Flows und Admin-Berechtigungen direkte Angriffsziele. Wie die folgenden Fälle zeigen, hat sich die Angriffsfläche über Smart-Contract-Bugs hinaus auf die Signing-Infrastruktur, die Schlüssel und die Personen verlagert, die damit arbeiten.

Das ist das Muster hinter drei der größten zahlungsbezogenen Krypto-Vorfälle aus dem Jahr 2025. Wir haben die Angriffsketten eingehend analysiert, und jeder lässt sich einem bestimmten Angriffsweg zuordnen: ein Supply-Chain-Angriff auf die Signing-Infrastruktur, ein durchgesickerter Admin-Schlüssel und durch Social Engineering gebrochene Mitarbeiter. Im Folgenden erläutern wir, was in jedem Fall passiert ist, was es darüber aussagt, wohin Krypto-Zahlungs-Hacks sich entwickeln, und gehen dann eine Ebene tiefer in die Contract-Schicht, auf der diese Zahlungen laufen — wo Smart Contracts in einem Zahlungssystem tatsächlich auftauchen, wie sich die beiden führenden Stablecoins darin unterscheiden, wer Ihre Gelder einfrieren oder prägen kann, und was ein selbst bereitgestellter Zahlungsvertrag vor und nach seiner Inbetriebnahme benötigt.

Bybit, 1,5 Milliarden Dollar: Wenn das Signing-Tool zum Angriffsziel wird

Im Februar 2025 erlitt Bybit den größten einzelnen Sicherheitsvorfall in der Geschichte des Kryptomarkts und verlor etwa 1,5 Milliarden Dollar (401.347 ETH).

Die Angreifer nutzten keine Schwachstelle in Bybits eigenen Contracts aus — sie kompromittierten die Drittanbieter-Oberfläche Safe{Wallet}, der die Unterzeichner vertrauten. Sie injizierten bösartiges JavaScript in den Frontend-Code von Safe{Wallet}, dem Drittanbieter-Multisig-Verwaltungstool, das Bybit verwendete. Als Bybits Unterzeichner in der Safe{Wallet}-Weboberfläche sahen, was wie eine routinemäßige „interne Überweisung" aussah, und diese unterzeichneten, signierten sie tatsächlich eine delegatecall-Operation, die Proxy-Slot 0 des Multisig-Contracts durch einen angreiferkontrollierten Implementierungsvertrag ersetzte. Nach der Unterzeichnung leerten die Angreifer die gesamte Wallet innerhalb von Minuten.

Vier Dinge mussten gleichzeitig versagen, damit das funktionierte:

• Endpunktsicherheit — die Web-Oberfläche der Unterzeichner stammte von einem Drittanbieter, ohne unabhängige Überprüfung.
• Transaktionsverifizierung — blindes Signieren bedeutete, dass Unterzeichner auf dem Bildschirm nicht zwischen einer normalen Überweisung und einem Delegatecall unterscheiden konnten.
• Contract-Design — das Proxy-Upgrade-Privileg hatte keinen Timelock-Schutz.
• Operative Isolierung — die Signing-Umgebung war nicht physisch von der alltäglichen Büroumgebung getrennt.

Dieser letzte Punkt verdient besondere Beachtung: Selbst eine gut ausgestattete Börse kann 1,5 Milliarden Dollar verlieren, wenn mehrere Schutzmaßnahmen gleichzeitig versagen — Endpunktsicherheit, Transaktionsverifizierung, Contract-Design und operative Isolierung. Für einen tieferen Einblick in die Härtung der Signing-Umgebung selbst, siehe Key-Management und Signing-Infrastruktur.

UPCX, 70 Millionen Dollar: Ein durchgesickerter Admin-Schlüssel, totale Kontrolle

Im Jahr 2025 verlor das Zahlungsprotokoll UPCX durch einen durchgesickerten privaten Admin-Schlüssel etwa 70 Millionen Dollar.

Hier musste der Angreifer niemanden dazu bringen, etwas zu signieren. Er beschaffte sich einfach den privaten ProxyAdmin-Schlüssel, nutzte die Contract-Upgrade-Funktion, um den Implementierungsvertrag gegen eine bösartige Version auszutauschen, und rief dann withdrawByAdmin auf, um alle Gelder abzuziehen.

Die Lehre ist eindeutig: Ein durchgesickerter Schlüssel plus Contract-Upgrade-Privileg bedeutet totale Kontrolle. Deshalb muss das ProxyAdmin-Schlüsselmanagement MPC oder Multisig verwenden — niemals einen einzigen Inhaber — und deshalb benötigen Contract-Upgrades einen Timelock (zum Beispiel eine 48-Stunden-Verzögerung), der dem Team ein Zeitfenster gibt, um Anomalien zu erkennen, bevor ein Upgrade in Kraft tritt. Wir gehen anderswo in dieser Serie tiefer darauf ein, wie man ein solches Key-Management-Setup strukturiert.

MoonPay, 250.000 Dollar: Wenn Angreifer den Code vollständig umgehen

Nicht jeder Krypto-Zahlungs-Hack betrifft überhaupt einen Contract oder ein Schlüsselsystem. Laut einer US-amerikanischen Einziehungsklage des Justizministeriums aus dem Jahr 2025 wurden der CEO und CFO des Krypto-Zahlungsunternehmens MoonPay durch eine einzige E-Mail um etwa 250.000 Dollar in USDT gebracht.

Der Angreifer gab sich als bekannte Persönlichkeit aus und verwendete Typosquatting, um die Absenderadresse zu fälschen — er tauschte ein großes „I" gegen ein kleines „l" aus, was in einer serifenlosen Schrift kaum sichtbar ist — um MoonPay-Führungskräfte dazu zu verleiten, USDT an eine vom Angreifer kontrollierte Adresse zu überweisen. Es gab keine technische Schwachstelle, und das Schlüsselsystem wurde nie berührt. Es war reines Social Engineering.

Tether fror später etwa 40.000 Dollar der gestohlenen Gelder ein, während der Rest ins Ausland transferiert wurde und vom Justizministerium verfolgt werden musste.

Einige Punkte fallen dabei auf:

• Social Engineering macht keine Unterschiede — selbst technisch versierte Führungskräfte eines führenden Zahlungsunternehmens können darauf hereinfallen.
• Überprüfen Sie die Empfängeradresse immer unabhängig, bevor Sie senden, niemals nur anhand der in einer E-Mail angezeigten Adresse. Kombinieren Sie Adressverifizierung, Whitelisting und eine Bedenkzeit für größere Beträge.
• Die Einfrierbarkeit von Stablecoins half dabei, einen Teil des Verlusts im Nachhinein zurückzugewinnen, aber nur ein Bruchteil wurde zurückerlangt. Prävention schlägt nachträgliches Einfrieren.

Das Muster: Drei Angriffswege, eine Lektion

Stellt man diese drei Fälle nebeneinander, ergibt sich ein Muster — jeder ist ein anderer Schwachpunkt, aber jeder hat eine klar definierte Verteidigung:

Die Angriffsfläche hat sich verlagert: Es geht nicht mehr nur um Smart-Contract-Bugs, sondern um die Signing-Infrastruktur, die Admin-Schlüssel und das Betriebspersonal drumherum. Wenn Sie für ein Krypto-Zahlungssystem verantwortlich sind, lautet die praktische Schlussfolgerung, alle drei zu verteidigen — Ihre Signing-Tools, Ihre Admin-Schlüssel und Ihr Betriebspersonal — als separate Angriffsflächen, jede mit ihren eigenen Kontrollen.

Dennoch spielten Contract-Berechtigungen in zwei dieser drei Fälle eine Rolle — das nicht zeitgesperrte Proxy-Upgrade war eines der vier Versagen hinter Bybit, und UPCXs ProxyAdmin-Schlüssel war der gesamte Angriff. Es lohnt sich also, eine Ebene tiefer zu gehen: was die Contract-Schicht eines Zahlungssystems tatsächlich umfasst und was sie benötigt.

Wo Smart Contracts in Zahlungssystemen tatsächlich auftauchen

Wenn Sie ein Krypto-Zahlungsprodukt entwickeln, ist es leicht anzunehmen, dass Smart-Contract-Sicherheit DeFi-Komplexität bedeutet: ein Dutzend interagierende Protokolle, ein Geflecht wirtschaftlicher Annahmen und eine riesige Angriffsfläche. Dort befinden sich Zahlungsunternehmen in der Regel nicht. Im Vergleich zu DeFi, wo ein Szenario ein Dutzend unter einem komplexen Wirtschaftsmodell interagierende Contracts umfassen kann, ist die Zahlungs-Contract-Logik in der Regel weitaus direkter. Von niedriger zu hoher Komplexität lassen sich die Anwendungsfälle in vier Bereichen zusammenfassen.

Stablecoin-Contracts, die von fast jedem Unternehmen genutzt werden. USDC und USDT sind selbst Smart Contracts mit Admin-Funktionen wie mint, burn, blacklist und pause. Sie sind Nutzer dieser Contracts, nicht der Deployer — aber Sie müssen dennoch ihr Berechtigungsmodell und ihre Einfrierungsfähigkeit verstehen, worauf wir als Nächstes eingehen.

Contract-Multisig und Account-Abstraktion, die Wallet- und Governance-Schicht. Contract-Multisigs wie Safe verwalten Gelder und Contract-Berechtigungen und stehen im Kern der Wallet-Schicht. Account-Abstraktion (ERC-4337) hat auch begonnen, in Zahlungsszenarien einzufließen und unterstützt gaslose Zahlungen (ein Paymaster übernimmt das Gas, sodass der Nutzer keine nativen Token halten muss), Enterprise-Ausgabenlimits und Session-Keys.

Automatische Aufteilungen, bedingte Freigabe und Cross-Chain-Settlement — die derzeit skalierende Kategorie. Hier verdient „programmierbares Geld" seinen Namen. Das Commerce Payments Protocol von Coinbase und Shopify teilt einen Eingang on-chain in Echtzeit auf: Bei der Erfassung leitet der Contract atomisch die Gebühr an den feeReceiver und den Rest an den Händler weiter, und er kann eine einzelne Autorisierung in mehrere Erfassungen zu unterschiedlichen Sätzen an unterschiedliche Empfänger aufteilen — zum Beispiel die Erfassung von 1.000 USDC in zwei Teilen, Gebühren an verschiedene Empfänger zahlen und den Rest an den Händler auszahlen. Dasselbe Protokoll bringt den bekannten Autorisierungs-/Erfassungsfluss der Kartennetzwerke on-chain: Ein Escrow-Contract hält Gelder nach der Autorisierung durch den Käufer, sodass der Händler später erfassen oder erstatten kann. Auf der Settlement-Seite verwendet Circles CCTP natives Burn-and-Mint für Cross-Chain-USDC-Transfers und kann bei Ankunft nachfolgende Contract-Aktionen auslösen, wodurch Cross-Chain-Bewegung und automatisiertes Settlement miteinander verknüpft werden.

Automatische Rendite und Treasury-Management — noch in der Frühphase. Das bedeutet, Reserven in risikoarme DeFi-Protokolle einzubringen, um Rendite zu erzielen, oder Treasury-Bewegungen mit Contracts zu automatisieren. Die meisten Zahlungsunternehmen haben dies noch nicht im großen Maßstab übernommen, und das aus gutem Grund: Es führt externe Protokollabhängigkeiten ein, was die Angriffsfläche vergrößert.

Die meisten Zahlungsunternehmen befinden sich heute in den ersten beiden Kategorien, die dritte beginnt gerade zu skalieren, und die vierte befindet sich noch in der Frühphase. Je einfacher die Nutzung, desto kleiner die Angriffsfläche — fügen Sie also Contract-Komplexität nur dann hinzu, wenn Ihr Geschäft es erfordert, nicht um der „Programmierbarkeit" willen.

Das Berechtigungsmodell hinter jedem Stablecoin, den Sie nutzen

Als Stablecoin-Nutzer müssen Sie das Berechtigungsdesign verstehen, das in den Contract selbst eingebaut ist. Die beiden führenden Stablecoins verfolgen entgegengesetzte Ansätze.

USDC (Circle) verwendet ein Modell der Gewaltenteilung: masterMinter verwaltet Minter-Allowances, pauser kann den Contract pausieren, blacklister verwaltet die Blacklist, und owner verwaltet die Rollenzuweisung. Jede Rolle ist unabhängig, ohne Überschneidungen bei Berechtigungen (siehe den Circle stablecoin-evm-Contract-Quellcode).

USDT (Tether) verwendet ein Einzeleigentümer-Modell: Eine Eigentümeradresse hält alle Berechtigungen gleichzeitig — Mint, Pause und addBlackList. Es ist einfacher im Design, aber stärker konzentriert.

Keines der Modelle ist eindeutig besser — sie bieten unterschiedliche Kompromisse. USDCs getrennte Berechtigungen sind sicherer, aber komplexer zu betreiben, während USDTs konzentriertes Modell effizient ist, aber stärker auf die Sicherheit einer einzigen Eigentümeradresse setzt. Dieser Unterschied ist nicht nur akademisch: Er beeinflusst direkt Ihr Einfrierungsrisiko, falls ein Stablecoin-Emittent jemals auf Ihre Gelder einwirken muss.

Die von Ihnen selbst entwickelten Contracts absichern

Wenn Sie eigene Empfangs-, Settlement-, Aufteilungs- oder Escrow-Contracts bereitstellen, benötigen Sie vor der Bereitstellung ein professionelles Zahlungs-Contract-Audit und eine Reihe integrierter Sicherheitsmechanismen.

Vor der Bereitstellung sollten Sie ein unabhängiges Sicherheitsaudit durch einen Drittanbieter sowie automatisiertes statisches und dynamisches Scanning durchführen lassen. Stellen Sie sicher, dass die Überprüfung speziell Berechtigungsverwaltung, Geldflüsse, Reentrancy und Überlauf bei Aufteilungsverhältnissen abdeckt — die zahlungsspezifischen Risiken, nicht nur generische Contract-Bugs.

Zur Laufzeit gelten vier Mechanismen:

• Timelock — eine Verzögerung (zum Beispiel 48 Stunden) bei Contract-Upgrades und Parameteränderungen, die Ihrem Team und der Community ein Zeitfenster gibt, um Probleme zu erkennen, bevor sie in Kraft treten.
• Circuit Breaker — pausiert automatisch den Contract-Betrieb, sobald eine Anomalie erkannt wird.
• Rollentrennung — Deployer, Upgrader, Pauser und Admin verwenden jeweils unterschiedliche Schlüssel, sodass keine einzelne Zugangsberechtigung alles kontrolliert.
• Upgradefähiges Proxy-Muster — ein transparenter Proxy oder UUPS, mit durch Timelock plus Multisig geschützten Upgrades.

Nach der Bereitstellung ist die sofortige Aufhebung der erhöhten Entwicklerberechtigungen die Kernmaßnahme gegen Insider-Bedrohungen, und sie ist die direkte Lektion des oben genannten UPCX-Vorfalls: Übertragen Sie Admin- und Owner-Berechtigungen auf einen Multisig-Contract, schützen Sie den ProxyAdmin-Schlüssel mit Multisig plus Timelock, überprüfen Sie regelmäßig den Berechtigungsstatus des Contracts, um zu bestätigen, dass keine verbleibenden Entwicklerberechtigungen vorhanden sind, und stellen Sie sicher, dass jede On-Chain-Berechtigungsänderung ein Ereignisprotokoll für Überwachung und Audit ausgibt.

Nichts davon ersetzt das Audit selbst — es ist das, was verhindert, dass ein sauberes Audit nach dem Launch zu einem unüberwachten, überprivilegisierten Contract verfällt.

Vier Angriffsflächen verteidigen und die vierte so klein wie möglich halten

Drei der Angriffsflächen, die die Vorfälle von 2025 offengelegt haben, sind operativer Natur: Ihre Signing-Tools, Ihre Admin-Schlüssel und Ihr Betriebspersonal. Die vierte ist die Contract-Schicht, und dort ist das Ziel ein anderes — nicht die Komplexität von DeFi zu erreichen, sondern der tatsächlichen Nutzung zu entsprechen: das Berechtigungsmodell der von Ihnen genutzten Stablecoins kennen, Ihre eigenen Contracts so einfach halten, wie das Geschäft es erlaubt, und das Audit als Tag eins einer fortlaufenden Berechtigungshygiene-Praxis behandeln, nicht als Ziellinie.

Wo jede dieser Angriffsflächen im Gesamtsystem liegt, erfahren Sie in unserer Aufschlüsselung der Sechsschicht-Zahlungsarchitektur. Für eine vollständige Übersicht, wie diese Kontrollen zusammenpassen, laden Sie das vollständige Playbook (PDF) herunter, und für Echtzeit-Überwachung, die Angriffstransaktionen automatisch auf Mempool-Ebene blockieren kann, werfen Sie einen Blick auf die On-Chain-Sicherheitsüberwachung.

FAQ

Was war der größte Krypto-Zahlungs-Hack im Jahr 2025? Bybit, im Februar 2025, mit einem Verlust von etwa 1,5 Milliarden Dollar (401.347 ETH), nachdem Angreifer den Frontend-Code des Drittanbieter-Multisig-Tools Safe{Wallet} kompromittierten und Unterzeichner dazu verleiteten, einen bösartigen Delegatecall zu genehmigen.

Wie ereignete sich der UPCX-Hack? Ein Angreifer beschaffte sich den privaten ProxyAdmin-Schlüssel von UPCX, nutzte die Contract-Upgrade-Funktion, um einen bösartigen Implementierungsvertrag einzusetzen, und rief withdrawByAdmin auf, um etwa 70 Millionen Dollar an Geldern abzuziehen.

War der MoonPay-Vorfall ein Smart-Contract-Exploit? Nein. Der MoonPay-Vorfall, bei dem CEO und CFO um etwa 250.000 Dollar in USDT gebracht wurden, involvierte keine technische Schwachstelle. Es war reines Social Engineering mit einer gefälschten, durch Typosquatting imitierten Absenderadresse.

Was haben Bybit, UPCX und MoonPay gemeinsam? Jeder Angriff zielte auf eine andere Schicht eines Zahlungssystems ab — das Signing-Tool, den Admin-Schlüssel und das Betriebspersonal — und zeigt, dass die größte Bedrohung sich von Smart-Contract-Bugs hin zu Signing-Infrastruktur, Schlüsseln und Betrieb verlagert hat.

Was ist der Unterschied zwischen den Berechtigungsmodellen von USDC und USDT? USDC (Circle) verwendet ein Modell der Gewaltenteilung mit unabhängigen masterMinter-, pauser-, blacklister- und owner-Rollen. USDT (Tether) verwendet ein Einzeleigentümer-Modell, bei dem eine Adresse alle Berechtigungen gleichzeitig hält — Mint, Pause und addBlackList.

Welche Sicherheitsmechanismen sollte ein selbst bereitgestellter Zahlungsvertrag haben? Vor der Bereitstellung: ein unabhängiges Drittanbieter-Audit plus automatisiertes Scanning, mit gezielter Überprüfung von Berechtigungsverwaltung, Geldflüssen, Reentrancy und Überlauf bei Aufteilungsverhältnissen. Zur Laufzeit: ein Timelock für Upgrades, ein Circuit Breaker, Rollentrennung über Schlüssel und ein upgradefähiges Proxy-Muster, geschützt durch Timelock plus Multisig.

Warum ist die Aufhebung von Entwicklerberechtigungen nach der Bereitstellung so wichtig? Es ist die Kernmaßnahme gegen Insider-Bedrohungen, und es ist die direkte Lektion des UPCX-Falls. Die Übertragung von Admin- und Owner-Berechtigungen auf einen Multisig-Contract und die regelmäßige Überprüfung des Berechtigungsstatus, um zu bestätigen, dass keine verbleibenden Entwicklerberechtigungen vorhanden sind, schließen diese Lücke.