Analyse eines raffinierten Betrugsfalls mit einem gefälschten GIWA-Mainnet, bei dem am 27.09.2026 Benutzer 766 ETH verloren haben und die dezentrale Börse DYORSWAP aufgrund der Integration eines Fake-RPCs kompromittiert wurde.
Meisterhafte Täuschung: Wie man eine Blockchain fälscht
Ich scrolle so durch meinen Security-Monitoring-Feed und... hätte fast meinen Kaffee fallen gelassen. Siebenhundertsechsundsechzig Ether. Einfach im Nirvana verschwunden. Und klar, gegen klassisches Phishing über gefälschte Libraries oder Flash-Loan-Exploits ist man ja mittlerweile abgehärtet. Aber dieser Move war verdammt clever. Die Betrüger haben ein gefälschtes GIWA-Mainnet hochgezogen, es an eine fremde DEX geknüpft und User um ein paar Millionen Dollar erleichtert.
Dröseln wir diesen Vorfall mal im Detail auf, denn aus architektonischer Sicht gibt es hier einiges zu bestaunen. Als InfoSec-Spezialist und aktiver CTO muss ich fast schon den Hut vor dieser Skrupellosigkeit ziehen – auch wenn man den Jungs von DYORSWAP natürlich absolut nachempfinden kann.
Moment mal, wie kann man überhaupt eine Layer-2-Blockchain "fälschen"? Klingt für Außenstehende total absurd, aber in der EVM-Welt ist ein Netzwerk eben keine Magie, sondern schlicht ein Bündel aus Konventionen und RPC-Endpoints.
Die Angreifer haben sich einen Open-Source-Stack geschnappt (höchstwahrscheinlich irgendwas Richtung OP Stack geforkt) und eine Node deployed. Aber ein Server reicht natürlich nicht; man muss Wallets und Apps auch noch verklickern, dass das hier das offizielle Ding der südkoreanischen Börse Upbit ist – deren echtes GIWA-Mainnet übrigens nicht mal offiziell an den Start gegangen war.
Sie haben die offizielle Chain ID – die Nummer 9134, die das GIWA-Team im Vorfeld für seine künftige Blockchain registriert hatte – knallhart in die Node-Konfiguration einhardcodiert. Und genau hier liegt die Achillesferse unseres gesamten Ökosystems: Wallets wie MetaMask verifizieren ein Netzwerk anhand von Konfigurationsstrings und IDs, und eben nicht über kryptographische Vertrauensanker zum wahren Ersteller.
Und genau an dieser Stelle ist DYORSWAP voll in die Falle getappt. Sie haben diesen Fake-RPC in ihre Infrastruktur eingebaut, weil sie unbedingt die Ersten sein wollten, die auf den Hype des neuen Netzwerks aufspringen.
Wisst ihr, damals als ich noch Smart-Contract-Audits am laufenden Band gemacht habe, dachten wir immer: Gut, das Frontend kann man fälschen, den RPC umbiegen, aber der Bridge-Smart-Contract ist unantastbar – der Code läuft schließlich direkt auf der Ethereum-Blockchain! Und genau da lauert die raffinierteste Falle dieses Angriffs.
Warum haben die User keinen Verdacht geschöpft?
Die User haben keinen Verdacht geschöpft, weil die Bridge aussah wie das native Interface, um Funds von Ethereum ins GIWA-L2-Netzwerk zu schaufeln. Die Leute haben in MetaMask Transaktionen unterschrieben und ihr hart verdientes ETH an einen Deposit-Smart-Contract im Mainnet geschickt.
Technisch gesehen war dieser Contract von den Angreifer so geschrieben, dass er die Funktionsweise eines Standard-Deposit-Locators perfekt imitiert. Sobald die Transaktion im Mainnet validiert war, hatten die Scammer die volle Kontrolle über die Kohle. Im Gegenzug bekahn der User wertlose Fake-Token auf seinem gefälschten L2-Saldo angezeigt. Die Zahlen auf dem Bildschirm stiegen, was eine erfolgreiche Bridge suggerierte, während das echte ETH längst auf den Wallets der Hintermänner landete und über Mixer gewaschen wurde. Am Ende hat es 1.335 eindeutige Adressen erwischt und knapp 767,7 ETH verbrannt. Netto konnten sie rund 766.3 ETH bei minimalen Gaskosten abziehen.
Das Team von DYORSWAP hat echten Sportsgeist bewiesen und über 200 ETH aus der eigenen Tasche locker gemacht, um die Verluste zu kompensieren. Respekt für diesen Umgang mit der Reputation, auch wenn diese architektonische Lücke bei der Validierung externer RPCs jetzt schleunigst gestopft werden muss.
Kommen wir nun zum praktischen Teil. Wie verhindert man, dass man das nächste Opfer wird, wenn man neue Blockchains einfach zu gerne als Erster testet? Ich habe euch ein kleines Python-Skript zusammengeschustert, mit dem ihr RPC-Nodes verifizieren könnt, bevor ihr auch nur ansatzweise darüber nachdenkt, sie mit eurer Wallet zu verbinden.
#!/usr/bin/env python3
import requests
def rpc_call(rpc_url, method, params=None):
if params is None:
params = []
payload = {
"jsonrpc": "2.0",
"method": method,
"params": params,
"id": 1
}
response = requests.post(rpc_url, json=payload, timeout=10)
response.raise_for_status()
data = response.json()
if "error" in data:
raise RuntimeError(f"{method}: {data['error']}")
return data.get("result")
def verify_evm_node(rpc_url, expected_chain_id):
try:
chain_id_hex = rpc_call(rpc_url, "eth_chainId")
chain_id = int(chain_id_hex, 16)
net_version = rpc_call(rpc_url, "net_version")
client_version = rpc_call(rpc_url, "web3_clientVersion")
block_number_hex = rpc_call(rpc_url, "eth_blockNumber")
block_number = int(block_number_hex, 16)
latest_block = rpc_call(
rpc_url,
"eth_getBlockByNumber",
["latest", False]
)
print("=" * 60)
print(f"RPC URL : {rpc_url}")
print(f"Chain ID : {chain_id}")
print(f"Expected ChainID : {expected_chain_id}")
print(f"Net Version : {net_version}")
print(f"Client Version : {client_version}")
print(f"Block Number : {block_number}")
if latest_block:
print(f"Latest Block Hash: {latest_block.get('hash')}")
print(f"Latest Block Num : {int(latest_block['number'], 16)}")
print(f"Parent Hash : {latest_block.get('parentHash')}")
print(f"Timestamp : {int(latest_block['timestamp'], 16)}")
print("=" * 60)
checks = []
checks.append(chain_id == expected_chain_id)
try:
checks.append(int(net_version) == expected_chain_id)
except Exception:
checks.append(False)
checks.append(block_number > 0)
checks.append(
latest_block is not None
and latest_block.get("hash")
and latest_block.get("parentHash")
and latest_block.get("number")
)
if all(checks):
print("VERIFICATION PASSED")
return True
print("VERIFICATION FAILED")
return False
except Exception as e:
print(f"ERROR: {e}")
return False
if __name__ == "__main__":
verify_evm_node(
"https://your-rpc-endpoint",
9134
)Merkt euch die goldene Regel: Vertraut niemals irgendwelchen Netzwerk-Listen von shady Twitter-Accounts oder ungeprüften DEXes, es sei denn, das offizielle Projekt haut die exakten Endpoints über seine verifizierten Kanäle raus (und damit meine ich keine Socials, sondern die offizielle Doku oder eine Website mit gültigem SSL-Zertifikat). Upbit hat klipp und klar klargestellt, dass ihr Mainnet noch überhaupt nicht live ist und sämtliche aktuellen RPCs reiner Humbug und purer Scam sind.
