Einleitung
Am 1. April 2026 (UTC) wurde das Drift Protocol auf Solana durch einen koordinierten Angriff kompromittiert, der eine Manipulation der Multisig-Genehmigung mit der Ausnutzung von Durable Nonces kombinierte. Ein Transaktionsmechanismus von Solana, der vortrainierte Genehmigungen auf unbestimmte Zeit gültig bleiben ließ, führte zu einem geschätzten Verlust von etwa 285,3 Mio. US-Dollar [1, 2]. Nach wochenlanger Vorbereitung auf der Blockchain überzeugte der Angreifer zwei von fünf Unterzeichnern des Security Council Multisig, bösartige Governance-Transaktionen vorzusignieren, indem er Phishing oder irreführende Signaturanfragen nutzte. Die signierten Anweisungen wurden bis zum vom Angreifer gewählten Zeitpunkt aufbewahrt und dann in zwei schnellen Transaktionen ausgeführt, um die Übernahme der Admin-Rechte abzuschließen und die administrative Kontrolle zu übertragen. Mit vollen Admin-Privilegien führte der Angreifer ein bösartiges Collateral-Asset (CVT) ein, blähte dessen Oracle-Preis auf, lockerte Auszahlungsschutzmaßnahmen und zog hochwertige Assets über die Kreditvergabe-Pfade des Protokolls ab.
Zum Zeitpunkt der Erstellung hat Drift eine erste Erklärung [1] veröffentlicht, aber noch keinen vollständigen Post-Mortem veröffentlicht. Die folgende Analyse basiert auf öffentlich zugänglichen On-Chain-Daten, der offiziellen Zeitleiste von Drift und unabhängigen Recherchen [2]. Wir untersuchen zunächst, wie Durable Nonces die Sicherheitsannahmen der Multisig-Governance grundlegend verändern, rekonstruieren dann die mehrwöchige Angriffsplanung, die Ausführung der Governance-Übernahme und den Prozess der Geldbeschaffung und schließen mit Lehren für die Minderung dieser Risikoklasse ab.
Hintergrund
Drift Protocol und Squads Multisig
Drift Protocol ist ein DeFi-Protokoll auf Solana, das Margin-Handel, Kreditvergabe, Spot-Märkte und Derivate unterstützt. Seine hochprivilegierten Operationen, einschließlich Admin-Änderungen, Markterstellung, Oracle-Konfiguration, Risikoparameter-Updates und Anpassungen von Auszahlungslimits, werden von einem Multisig und nicht von einem einzelnen privaten Schlüssel gesteuert.
Drift nutzt das Squads Multisig-Framework, ein gängiges On-Chain-Governance-System auf Solana. In Squads werden privilegierte Aktionen als Transaktionen im Rahmen eines Vorschlags zusammengefasst. Sobald genügend Mitglieder den Vorschlag genehmigen, können die gespeicherten Anweisungen atomar über vaultTransactionExecute ausgeführt werden. Zum Zeitpunkt des Angriffs operierte der Security Council von Drift unter einer 2-von-5-Schwellenwertkonfiguration ohne Timelock, was bedeutet, dass jeder von zwei der fünf Unterzeichner administrative Aktionen mit sofortiger Wirkung genehmigen konnte. Die Sicherheit dieses Systems hängt nicht nur von der Verwahrung der Schlüssel der Unterzeichner ab, sondern auch von der Integrität der gesamten Genehmigungspipeline: welche Transaktion erstellt wurde, was die Unterzeichner zu genehmigen glaubten und ob die final ausgeführten Anweisungen dem Überprüfungskontext entsprachen.
Durable Nonce Accounts
Durable Nonce Accounts führen eine kritische zeitliche Dimension in die Transaktionsausführung ein [3]. Unter normalen Bedingungen verlassen sich Solana-Transaktionen auf einen aktuellen Blockhash und verfallen schnell nach der Signierung, wenn sie nicht rechtzeitig gesendet werden. Durable Nonces ersetzen diesen kurzlebigen Blockhash durch einen Nonce, der in einem dedizierten Konto gespeichert ist, wodurch eine signierte Transaktion unbegrenzt gültig bleibt, bis der Nonce fortgeschritten wird. Diese Funktion ist für legitime Fälle wie Offline-Signierung oder verzögerte Einreichung nützlich, schafft aber auch ein wichtiges Angriffsprimitiv: Sie trennt die Zeit der Transaktionssignierung von der Zeit ihrer Ausführung auf der Blockchain. Entscheidend ist, dass ein Unterzeichner seine Signatur nicht widerrufen kann, sobald er eine Durable-Nonce-Transaktion genehmigt hat, es sei denn, der Nonce-Autorität hat den Nonce-Account manuell fortgeschritten.
Diese Trennung hat einen subtilen, aber grundlegenden Einfluss auf die Multisig-Sicherheit. Bei normalen, blockhash-basierten Transaktionen fungiert das kurze Ablaufzeitfenster als implizite Sicherheitsebene: Die Genehmigung eines Unterzeichners wird entweder umgehend ausgeführt oder verfällt unschädlich. Diese zeitliche Beschränkung bedeutet, dass der Angreifer die Transaktion innerhalb eines engen Fensters senden muss, selbst wenn ein Unterzeichner zur Genehmigung einer bösartigen Transaktion verleitet wird, was den Umfang für koordinierte, mehrstufige Ausnutzung einschränkt. Durable Nonces beseitigen diese Beschränkung vollständig. Bei unbegrenzt gültigen Signaturen ändert sich die Kosten eines einzelnen Signaturfehlers grundlegend: Eine getäuschte Genehmigung verfällt nicht mehr nach wenigen Minuten, sondern bleibt ohne automatische Zeitbegrenzung ausnutzbar, was dem Angreifer die volle Kontrolle über den Ausführungszeitpunkt und die Möglichkeit gibt, Folgeaktionen nach Belieben zu koordinieren.
Angriffsanalyse
Der Angriff entfaltete sich in drei verschiedenen Phasen. In der Phase der Vorbereitung vor dem Angriff führte der Angreifer eine mehrwöchige Operation durch, um ein gefälschtes Collateral-Asset zu erstellen und durch irreführende Signaturanfragen Zugriff auf die Governance zu erhalten. In der Phase der Governance-Übernahme wurden zwei vorab signierte Durable-Nonce-Transaktionen in schneller Abfolge eingereicht, um die administrative Kontrolle zu übernehmen. In der Phase der Geldbeschaffung manipulierte der Angreifer die Protokollparameter und zog reale Assets über die Kreditvergabe-Pfade des Protokolls ab. Das folgende Diagramm veranschaulicht den Ablauf der Angriffsausführung über drei Phasen, die den folgenden Unterabschnitten entsprechen. Die parallele Spur zur Herstellung von CVT, die in der Vorbereitung vor dem Angriff detailliert beschrieben wird, ist im Diagramm nicht dargestellt.
Vorbereitung vor dem Angriff
Der Angriff war kein einzelner opportunistischer Schlag, sondern eine mehrwöchige Operation mit zwei parallelen Vorbereitungsschienen. Die erste Schiene konzentrierte sich auf die Herstellung eines glaubwürdigen Collateral-Assets. Am 11. März zog der Angreifer 10 ETH aus Tornado Cash ab und verwendete die Gelder zur Bereitstellung von CarbonVote Token (CVT), wobei 750 Millionen Einheiten geprägt wurden. In den folgenden Wochen legte der Angreifer eine kleine Menge Liquidität auf Raydium an und nutzte Wash Trading, um eine künstliche Preisentwicklung nahe 1 US-Dollar aufzubauen, wodurch CVT den Anschein von Marktlegitimität erhielt [4].
Die zweite Schiene zielte auf den Governance-Zugriff ab. Laut der offiziellen Zeitleiste von Drift [1] wurden am 23. März vier Durable-Nonce-Accounts erstellt: zwei, die mit Mitgliedern des Drift Security Council Multisig verbunden waren, und zwei, die vom Angreifer kontrolliert wurden. Dies deutete darauf hin, dass mindestens zwei von fünf Unterzeichnern bereits Transaktionen mit Durable-Nonce-Accounts signiert hatten, was dem Angreifer die erforderliche 2-von-5-Genehmigungsschwelle gab.
Am 27. März führte Drift eine geplante Migration des Security Council aufgrund eines Wechsels eines Ratsmitglieds durch. Diese Migration machte die zuvor gesammelten Signaturen unter der alten Konfiguration ungültig. Bis zum 30. März erschien jedoch ein neuer Durable-Nonce-Account, der mit einem Mitglied des aktualisierten Multisig verbunden war, was darauf hindeutet, dass der Angreifer die erforderliche Zwei-von-Fünf-Genehmigungsschwelle unter der neuen Konfiguration wiedererlangt hatte.
Diese Abfolge zeigt, dass der Angreifer die On-Chain-Governance-Änderungen aktiv überwachte und sich in Echtzeit anpasste. Anstatt einer einzelnen Phishing-Kampagne war die Signatursammlung eine fortlaufende Operation, die eine Multisig-Neukonfiguration während der Vorbereitung überlebte. Die Migration selbst könnte dem Angreifer unwissentlich geholfen haben: Während Governance-Übergängen neigen Unterzeichner eher dazu, administrative Signaturanfragen zu sehen und zu genehmigen, was ein natürliches Social-Engineering-Fenster schafft.
Am 1. April wählte der Angreifer ein präzises Ausführungsfenster. Drift führte zuerst eine legitime Testauszahlung aus dem Versicherungsfonds durch. Ungefähr eine Minute später reichte der Angreifer die vorab signierten Angriffstransaktionen ein. Dieses Timing deutet darauf hin, dass der Angreifer die On-Chain-Aktivitäten in Echtzeit überwachte und auf eine erfolgreiche legitime Operation wartete, um den normalen Betriebszustand des Systems zu bestätigen, bevor er zuschlug.
Governance-Übernahme
Um ca. 16:05 UTC am 1. April reichte der Angreifer die beiden vorab signierten Durable-Nonce-Transaktionen mit einem Abstand von vier Slots ein. Die erste Transaktion (2HvMSg...2C4H) erstellte und genehmigte den bösartigen Admin-Übertragungsvorschlag. Die zweite Transaktion (4BKBmA...RsN1) genehmigte und führte diesen aus, beginnend mit AdvanceNonceAccount, um den gespeicherten Nonce zu aktivieren, und fuhr dann mit proposalApprove und vaultTransactionExecute fort, wobei schließlich UpdateAdmin aufgerufen wurde, um die administrative Kontrolle an eine vom Angreifer kontrollierte Adresse zu übertragen.
Dieser Ausführungsfluss unterstreicht eine Schlüsseleigenschaft des Angriffs: Die entscheidende Autorisierung fand nicht zum Zeitpunkt der Ausführung statt, sondern im früheren Signierungsstadium. Die On-Chain-Transaktionen machten lediglich bereits erteilte Berechtigungen geltend.
Geldbeschaffung
Nachdem er die administrative Kontrolle erlangt hatte, unternahm der Angreifer drei vorbereitende Schritte, bevor er Gelder abzog: Erstellung eines bösartigen Collateral-Marktes für CVT, Umstellung auf ein vom Angreifer kontrolliertes Oracle zur Preisaufblähung und Lockerung der Auszahlungsschutzmaßnahmen zur Ermöglichung der groß angelegten Entnahme.
Der erste Schritt war die Erstellung eines bösartigen Collateral-Marktes für CVT. Das Problem mit diesem Markt war nicht nur, dass er neu war, sondern dass ihm echte Liquidität fehlte und ihm übermäßig nachgiebige Risikoparameter zugewiesen wurden. Ein Asset ohne einlösbaren Wert, das einmal als hochgewichtetes Collateral innerhalb des Protokolls akzeptiert wird, kann verwendet werden, um nicht existierende Kreditbefugnisse zu schaffen.
Der zweite Schritt war die Umstellung auf ein vom Angreifer kontrolliertes Oracle und die Aufblähung des Preises. Mit Admin-Berechtigungen war für diesen Schritt keine weiteren Einschränkungen zu umgehen. Sobald das Oracle unter der Kontrolle des Angreifers stand, konnte der Buchpreis von CVT beliebig aufgebläht werden, wodurch ein Asset mit fast keinem realen Marktwert als hochwertiges Collateral innerhalb des Protokolls erschien.
Der dritte Schritt war die Lockerung von Auszahlungsschutzmaßnahmen und Circuit Breakers. Selbst mit aufgeblähter Collateral-Bewertung hätten Auszahlungslimits auf wichtigen Asset-Märkten groß angelegte Entnahmen eingeschränkt. Diese Schutzmechanismen mussten angehoben oder entfernt werden, bevor der konstruierte Collateral-Wert in entziehbare reale Assets umgewandelt werden konnte.
Nach Abschluss dieser Schritte zahlte der Angreifer eine große Menge überbewertetes CVT in das Protokoll ein und führte dann 31 schnelle Abhebungen über etwa 12 Minuten durch, wobei er reale Assets abzweigte, darunter USDC, JLP, SOL, cbBTC, USDT, wETH, dSOL, WBTC, JTO und FARTCOIN. Dies schloss den Gewinn-Extraktionskreislauf: Governance-Kontrolle erlangen, Parameter ändern, ein wertloses Asset als hochwertiges Collateral verpacken und Gelder über die vorab bestehenden Kredit- und Auszahlungswege des Protokolls abziehen.
Zum Zeitpunkt der Erstellung beträgt der Gesamtverlust 285.279.417,69 US-Dollar, berechnet basierend auf dem Abzugskonto des Angreifers (HkGz4K...pZES).
Gelerntes
-
Die Sicherheit von Multisig geht über die Schlüsselverwahrung hinaus. Der Schutz privater Schlüssel und die Durchsetzung von Signaturschwellenwerten reichen nicht aus. Die gesamte Autorisierungspipeline, einschließlich der Transaktionskonstruktion, -anzeige und -interpretation durch die Unterzeichner, muss vertrauenswürdig sein. Bei diesem Vorfall wurden die Schlüssel der Unterzeichner nicht kompromittiert, aber der Genehmigungsprozess wurde manipuliert, um unbeabsichtigte Aktionen zu autorisieren.
-
Timelocks sind für hochprivilegierte Operationen unerlässlich. Administrative Aktionen wie Eigentumsübertragungen sollten nicht sofort ausführbar sein. Die Null-Timelock-Konfiguration von Drift bedeutete, dass die administrative Kontrolle innerhalb von Minuten nach der Auslösung der vorab signierten Transaktionen übertragen und ausgenutzt wurde, was keine Möglichkeit zur Erkennung oder Intervention ließ. Ein Timelock hätte ein Reaktionsfenster geschaffen, um die bösartige Übertragung zu identifizieren und zu blockieren.
-
Mechanismen zur verzögerten Ausführung erfordern zusätzliche Schutzmaßnahmen in Governance-Kontexten. Durable Nonces entkoppeln die Signierung von der Ausführung und entfernen die impliziten zeitlichen Garantien, auf die sich die Unterzeichner verlassen. In Governance-Systemen sollte diese Art von Mechanismus mit höheren Signaturschwellenwerten, zeitlich befristeten oder widerruflichen Genehmigungen und Beschränkungen kombiniert werden, die verhindern, dass signierte Transaktionen auf unbestimmte Zeit gültig bleiben.
Schlussfolgerung
Dieser Vorfall wurde nicht durch eine Smart-Contract-Schwachstelle oder eine Schlüsselkompromittierung verursacht, sondern durch einen Zusammenbruch des Multisig-Autorisierungsprozesses in Kombination mit einer Durable-Nonce-basierten verzögerten Ausführung. Der Angreifer sammelte im Voraus gültige Multisig-Genehmigungen von zwei von fünf Security Council Unterzeichnern durch irreführende Signierungen, bewahrte diese mithilfe von Durable-Nonce-Transaktionen auf und führte sie später aus, um die administrative Kontrolle zu erlangen. Die anschließende Geldbeschaffung war eine direkte Folge der kompromittierten Governance und wurde durch ansonsten gültige Protokolloperationen durchgeführt. Die Minderung dieser Risikoklasse erfordert die Sicherung der gesamten Autorisierungspipeline, die Durchsetzung von Timelocks bei hochprivilegierten Operationen und die Implementierung zusätzlicher Schutzmaßnahmen für verzögerte Ausführungsmechanismen. In Verbindung mit On-Chain-Überwachungssystemen, die in der Lage sind, anomale Governance-Aktivitäten in Echtzeit zu erkennen, bilden diese Maßnahmen ein umfassendes Sicherheitssystem gegen diese Art von Governance-Layer-Angriffen.
Referenzen
[1] DriftProtocol, "Official statement": https://x.com/DriftProtocol/status/2039564437795836039
[2] Phalcon (BlockSec), "Drift Protocol Exploit Analysis": https://x.com/Phalcon_xyz/status/2039602380074016909
[3] Solana, "Introduction to Durable Nonces": https://solana.com/developers/guides/advanced/introduction-to-durable-nonces
[4] CoinDesk, "How Drift attackers drained more than $270 million using a Solana feature designed for convenience": https://www.coindesk.com/tech/2026/04/02/how-a-solana-feature-designed-for-convenience-let-an-attacker-drain-usd270-million-from-drift
