Presiona ESC para cerrar

Red GIWA Falsa: 766 ETH Robados Mediante un Bridge L2 Fraudulento

Análisis a fondo de una estafa sofisticada con una mainnet falsa de GIWA que, el 27/09/2026, hizo que los usuarios perdieran 766 ETH y dejó a la exchange descentralizada (DEX) DYORSWAP completamente expuesta por culpa de una integración de RPC trucho.

Estafa de otro nivel: ¿Cómo se clona una blockchain?

Estaba revisando el feed de monitoreo de seguridad y... por poco se me cae el café. Setecientos sesenta y seis Ethers. Literalmente evaporados. Si hubiera sido el clásico phishing de librería o un exploit de contrato con flash loans, diría "bueno, lo de siempre, ya me la sé". Pero este caso está armado con una elegancia y una malicia tremenda. Los estafadores levantaron una mainnet falsa de GIWA, la enchufaron a un DEX de terceros y le robaron unos cuantos millones de dólares a la comunidad.

Vamos a desglosar este incidente con lupa, porque a nivel de arquitectura e ingeniería da gusto analizarlo. Como especialista en InfoSec y CTO en funciones, casi que aplaudo la audacia de la movida, aunque a los pibes de DYORSWAP la verdad es que no hay que envidiarles nada.

Pará, ¿cómo se supone que se puede "falsificar" una blockchain de Capa 2 (L2)? Suena re loco para alguien que recién arranca, pero en el mundo EVM una red no tiene nada de mágica; es simplemente un conjunto de convenciones y endpoints RPC.

Los tipos agarraron un stack open-source (seguramente un fork de algo tipo OP Stack) y desplegaron su propio nodo. Pero no basta con prender el server; tenían que convencer a las wallets y a las dApps de que ese era el producto oficial de la exchange surcoreana Upbit, cuyo mainnet de GIWA ni siquiera había arrancado oficialmente todavía.

Le metieron un hardcodeo picante a la configuración del nodo con el Chain ID oficial — el número 9134 que el equipo de GIWA había registrado con tiempo para su futura blockchain. Y acá es donde se pudre todo y salta la gran vulnerabilidad del ecosistema: wallets como MetaMask validan las redes mirando strings de configuración e IDs, y no por raíces de confianza criptográficas que apunten a los creadores reales.

Y fue exactamente ahí donde el DEX DYORSWAP pisó el palito. Mandaron este RPC trucho a su infraestructura con las ganas de ser los primeros en subirse al tren del Hype de la nueva red.

¿Saben qué? En la época en que yo mismo hacía auditorías de smart contracts a pulmón, siempre pensábamos: bueno, el frontend te lo pueden clonar, el RPC te lo pueden fraguar, pero el contrato inteligente del bridge es sagrado, ¡si el código corre directo en la blockchain de Ethereum! Y ahí es donde te arman la trampa más fina de todo este ataque.

¿Por qué los usuarios no sospecharon nada?

Los usuarios no sospecharon porque el bridge pintaba exactamente igual a la interfaz nativa para mandar fondos de Ethereum a la red L2 de GIWA. La gente firmaba transacciones en MetaMask, mandando sus queridos ETH derecho al contrato inteligente de depósito en el mainnet.

Técnicamente, este contrato estaba programado por los estafadores para caretear el funcionamiento de un localizador de depósitos estándar. Apenas la transacción pasaba la validación en la red principal, los vivos se adueñaban de los fondos. A cambio, al usuario le figuraban tokens truchos sin ningún tipo de respaldo en el saldo de su L2 trucha. Los numeritos en pantalla subían, armando la ilusión de un puente exitoso, mientras el éter de verdad ya volaba a las wallets de los organizadores y se esfumaba por mixers. Al final, cayeron 1.335 direcciones únicas y quedaron atrapados unos 767.7 ETH. Lo peor es que se llevaron limpios cerca de 766.3 ETH gastando re poco en gas.

El equipo de DYORSWAP se portó de diez poniendo más de 200 ETH de su propio bolsillo para los reembolsos. Banco fuerte esa banca a la reputación, aunque esa brecha arquitectónica en la validación de RPCs externos la van a tener que coser a fuego.

Ahora pasemos a los bifes. ¿Cómo hacemos para no terminar financiándole las vacaciones a estos chantas si te gusta probar redes nuevas de una? Armé este script en Python para chequear y verificar nodos RPC antes de pensar en conectar tu wallet ni de chiste.

#!/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
    )

Anótate la regla de oro: nunca le confíes tus cosas a listas de redes que tiran cuentas de Twitter falopa o DEXs que no conoce nadie, a menos que el proyecto oficial tire los endpoints posta por canales verificados (nada de redes sociales, mirá la documentación oficial o la web con certificado SSL válido). Upbit ya salió a aclarar con todas las letras que su mainnet no está arriba ni por casualidad, y que cualquier RPC dando vueltas por ahí es alto scam.

Resumir esta publicación de blog con:

FAQ

Los atacantes desplegaron un nodo Layer 2 compatible con EVM utilizando el Chain ID oficial 9134 de GIWA aún no lanzado, conectaron un contrato de depósito de bridge fraudulento y engañaron a 1,335 billeteras para transferir ETH real a cambio de saldos L2 ficticios.

El intercambio descentralizado verificó la legitimidad de la red automáticamente basándose únicamente en la coincidencia del parámetro Chain ID 9134, omitiendo la validación criptográfica de raíz y la confirmación con los anuncios oficiales del equipo de Upbit.

Los desarrolladores y usuarios deben realizar validaciones cruzadas de respuestas RPC mediante métodos nativos como net_version, inspeccionar la continuidad de los encabezados de bloque vía eth_getBlockByNumber y confiar exclusivamente en documentación oficial verificada criptográficamente.
Oleg Filatov

As the Chief Technology Officer at EXMON Exchange, I focus on building secure, scalable crypto infrastructure and developing systems that protect user assets and privacy.

With over 15 years in cybersecurity, blockchain, and DevOps, I specialize in smart contract analysis, threat modeling, and secure system architecture.

At EXMON Academy, I share practical insights from real-world...

...

Escribe una opinión

Tu correo electrónico no será publicado. Los campos obligatorios están marcados *