Anatomía del exploit al locker de DxSale: captura de propiedad, un drenaje self-call y un rastro de lavado en dos cadenas

El 27 de mayo de 2026, una dirección atacante drenó un liquidity locker de DxSale en BNB Smart Chain poco más de una hora después de ser fondeada, y luego distribuyó los fondos por dos cadenas: una pata directa y expuesta a KYC, la otra enrutada por un bridge, swaps en DEX y un mixer. Esta es la reconstrucción on-chain completa, con cada afirmación respaldada por evidencia sellada y reproducible.

Cómo leer este reporte. Cada hallazgo lleva un nivel de confianza explícito bajo nuestro estándar forense (OCS-FIS-V1):

• Confianza: Alta (evidencia) — directamente observable on-chain y sellado bajo cadena de custodia desde al menos dos fuentes independientes.
• Confianza: Media (hipótesis) — una interpretación razonada que la evidencia sellada sostiene pero no prueba. Se enuncia como hipótesis, nunca como hecho.

Cada hash de transacción, dirección y bloque es reproducible por cualquier tercero contra las cadenas públicas. Nombramos las etiquetas de entidad que muestran los exploradores de bloques (p. ej. “DxSale Exploiter 1”, “Binance 51”) como observaciones atribuidas, no como identidades del mundo real probadas. No se nombra ni se atribuye a ninguna persona natural en este reporte.

Resumen ejecutivo

Un caveat gobierna toda la mitad de lavado de este reporte y lo ponemos por delante: la dirección atacante es un operador serial, y los fondos que movió son proceeds mezclados (commingled) de su actividad más amplia. Nuestra evidencia sellada no establece que los BNB y SOL específicos lavados aquí provengan del drenaje del locker de DxSale. Lo que ata el lavado al exploit de DxSale es la dirección atacante compartida, no una traza de valor sellada desde la liquidez drenada. No afirmamos ninguna cifra en dólares específica de DxSale para los fondos lavados.

1. Captura de propiedad Alta · evidencia

El 2026-05-26, dentro de una ventana de ~6 minutos que abarca los bloques 100449023–100449822 (01:08:21Z a 01:14:21Z), la dirección deployer 0x47BAcf935066b802EAA0067eC14AB035B24eB78b envió tres transacciones BSC exitosas, cada una invocando transferOwnership (selector 0xf2fde38b, valor 0 BNB) contra un contrato locker distinto:

• 0x2D045410f002A95EFcEE67759A92518fA3FcE677 — sin etiqueta en el explorador
• 0xEb3a9C56d963b971d320f889bE2fb8B59853e449 — etiquetado DxSale Network: Legacy Liquidity Locker
• 0x81E0eF68e103Ee65002d3Cf766240eD1c070334d — etiquetado KIPS: Locked Wallet

En las tres, el argumento newOwner fue 0xC4574DDEF299e7E563971e200433e592EeaaFA69 — la dirección que los exploradores etiquetan DxSale Exploiter 1. El control de los tres lockers pasó a esa sola dirección en un solo lote.

Lo que no afirmamos: los datos on-chain por sí solos no distinguen un insider malicioso de una llave deployer comprometida, y una migración interna benigna es lógicamente posible — pero queda debilitada por el drenaje posterior del Legacy Locker y por la ausencia de cualquier anuncio oficial de migración de DxSale.

2. Fondeo previo al ataque Alta · evidencia

En la transacción 0xffc7b601d90f6bc5584a9880693eb41f41ad62619e863e97b5d72477f5e4b72a (bloque 100798786, 2026-05-27T20:57:54Z, éxito), la dirección 0x318d2aAe4C99c2e74F7B5949fa1C34DF837789B8 envió exactamente 104.1473 BNB a la dirección atacante como transferencia simple (call data 0x, sin método). Ambas fuentes selladas muestran al emisor etiquetado Bybit 17 y al receptor DxSale Exploiter 1.

Este fondeo entrante precede al drenaje por 1h 39m 51s (respecto al timestamp del drenaje, sellado por separado en F-03).

Límites honestos:

• Llamar a Bybit 17 una “hot wallet” de Bybit es nuestra inferencia a partir de una etiqueta de operaciones de exchange — no texto que la etiqueta misma afirme. La corroboración de segunda fuente independiente de la atribución al exchange (p. ej. Arkham) está pendiente, aún no sellada. Los hechos de la transferencia (monto, direcciones, bloque, éxito) son de confianza Alta con dos fuentes selladas; la capa de identidad del exchange no.
• Una transferencia simple desde una wallet etiquetada de exchange es consistente con un retiro ordinario de cliente. No establece, por sí sola, que el exchange haya dirigido fondos hacia el drenaje, ni prueba intención.
• El emisor y el receptor son direcciones distintas y no deben confundirse.

3. El drenaje, tal como se observa on-chain Alta · evidencia

En el bloque 100812090 (2026-05-27T22:37:45Z), la transacción 0xb107f19af1a8ff90d19cbb40d935f8be5d79f5fb9b497824e4ed28b9e7555fe9 se ejecutó con estado éxito como un self-call — from y to son ambos la dirección atacante 0xC4574DDEF299e7E563971e200433e592EeaaFA69. Llevó 0 BNB e invocó el selector personalizado y no verificado 0x11b432b4.

Re-derivamos el efecto de primera mano desde el getTransactionReceipt sellado (RPC público), no solo desde el decode del explorador. El receipt lleva 10 event logs crudos:

• 5 son eventos Transfer ERC-20/BEP-20 del token LP de PancakeSwap (Cake-LP) 0x88DA6Bc38D5BFEF6e332F87E06a310a9e5f768E2, cada uno moviendo 12.872812929106341247 unidades (suma 64.364064645531706235) desde el Legacy Liquidity Locker 0xEb3a9C56d963b971d320f889bE2fb8B59853e449 hacia la dirección atacante.
• Los otros 5 son eventos no-Transfer emitidos por el contrato locker, que deliberadamente no caracterizamos más.

La transacción se muestra con una Dirección Delegada EIP-7702 0x74Ad1Ef17Fbb3e494c31c72F7ec730A27FEf0310.

Nota de alcance: el “5” es el conteo de eventos Transfer, no el conteo total de logs (10). Este hallazgo registra solo hechos observables. Si algún control fue evadido, y por qué mecanismo, queda fuera de alcance aquí — ver F-04.

4. Mecanismo del drenaje Media · hipótesis

Esto es una hipótesis, no verificada on-chain por nosotros. La lectura propuesta: el drenaje abusó funciones privilegiadas del locker que quedaron alcanzables después de la captura de propiedad de F-01 (una atribución OSINT consistente con write-ups públicos). Los hechos sellados de F-03 sostienen esta lectura pero no la prueban.

La ruta exacta de evasión permanece abierta porque:

• El selector 0x11b432b4 es personalizado y no verificado — no hemos decompilado ni resuelto por ABI el código llamado, así que no podemos confirmar que sea un retiro del locker solo-para-owner en vez de un patrón genérico de multicall/router/agregación.
• El contrato auxiliar en el delegado EIP-7702 0x74Ad1Ef17Fbb3e494c31c72F7ec730A27FEf0310 tiene bytecode sin leer — la delegación podría implementar la lógica de transferencia ella misma, con lo que la función propia del locker podría no ser el vector.
• La captura de propiedad como precondición habilitante es inferida y correlacionada por tiempo, no probada causalmente dentro de esta transacción.

Resolver el mecanismo exige deconstruir el locker y los contratos auxiliares — diferido.

5. Distribución a través de BSC Alta · evidencia

Entre los bloques BSC 100869981 y 100977493 (cada transacción sellada individualmente como JSON getTransactionByHash):

• Fondeo de los distribuidores: la dirección atacante envió 1,542.285 BNB al distribuidor DIST-01 0xb71c1C2A0cD7A88f1317f9A996e4d121E7db5E92 (4 tx) y 1,438.285 BNB al distribuidor DIST-02 0x4c5ee9703653C8e7725C65593bff372655e0453C (4 tx).
• Distribución (piso): 22 salidas selladas de DIST-01 hacia 22 wallets distintas suman 1,527.28 BNB; 8 salidas selladas de DIST-02 hacia 8 wallets distintas suman 1,438 BNB — en agregado al menos 2,965.28 BNB hacia al menos 30 wallets receptoras distintas.
• Cierre: DIST-01 devolvió 15.001 BNB a la dirección atacante en 3 tx.

Estas son cantidades-piso. El RPC público EVM no puede enumerar transacciones por dirección, así que los conteos (22 / 8 / 30) provienen de una única enumeración por explorador del lado del navegador y son pisos, no totales exhaustivos. No afirmamos que estas sean las únicas salidas de los distribuidores, ni un conteo exacto de wallets, ni (aquí) la atribución a exchange de las 30 wallets.

6. Consolidación hacia una sola wallet de exchange Alta · evidencia

Muestreamos 5 de las 30 wallets receptoras y sellamos sus hops posteriores. Las cinco reenviaron los BNB que recibieron a la misma dirección 0x8894E0a0c962CB723c1976a4421c95949bE2D4E3, que las páginas selladas del explorador etiquetan Binance 51:

Cada hop está sellado con dos fuentes independientes — el JSON getTransactionByHash del RPC público y la captura de la página de la transacción del explorador. La cadencia de barrido es rápida y uniforme: entre el depósito de cada wallet y su hop de salida, de 210 a 1,506 bloques (aproximadamente 95 segundos a ~11 minutos). Ejemplo trabajado, todo desde la propia página sellada de 0xAc69F86C…: depósito en el bloque 100928690 (13:13:41 UTC), hop en el bloque 100929535 (13:20:02 UTC) — 845 bloques en 381 segundos (~0.45 s/bloque), consistente con barrido automatizado. Al menos una wallet muestreada muestra FUNDED BY: Binance: Deposit Funder y ciclos repetidos de depósito-y-barrido antes y después de la ventana del exploit.

Lo que no afirmamos: afirmamos consolidación solo para las 5 wallets muestreadas. La afirmación “las 30 wallets consolidan en Binance” deliberadamente no se hace — las salidas de las 25 wallets restantes no fueron selladas. Binance 51 es una etiqueta del explorador, no una identidad probada on-chain.

7. Cruce hacia Solana vía Relay.link Alta · evidencia

24 transacciones BSC exitosas movieron valor desde tres wallets relay hacia el bridge Relay.link. Cada cruce está atestado de extremo a extremo por tres artefactos sellados: (a) la transacción de origen BSC, (b) el propio registro de estado público del operador del bridge que mapea ese hash de origen exacto a una firma de fill en Solana + destino + valuación en USD, y (c) la transacción de fill de Solana misma, sellada de forma independiente.

Las tres cuentas de destino son distintas entre sí — los fondos con bridge no convergieron en una sola cuenta Solana (esto corrige una nota de “convergencia triple” del rastro pre-Lab). Del lado BSC, las entradas de RELAY-02 sumaron 8,809.826078 BUSD + 9,885.496711 USDT + 90.840809 WBNB (receipts sellados).

Límites honestos: los registros de estado del operador son una segunda fuente independiente pero no consenso de cadena; esto se mitiga con (c), cada fill recuperado independientemente desde un RPC público de Solana. Las cifras en USD son las valuaciones del operador al momento del request — citadas como atribuidas, no como precios propios nuestros. Por nuestro estándar de confianza, el vínculo cross-chain lleva un techo ex-ante porque ningún hash se comparte a través del bridge; aquí las dos fuentes independientes coinciden en identificadores exactos de transacción, lo que lo eleva a Alta.

8. Swaps y la frontera del mixer Alta · evidencia

Aguas abajo en Solana (todas las cantidades son deltas de balance de JSONs getTransaction sellados; el RPC de Solana sí enumera las firmas de una cuenta, así que los deltas por transacción son de confianza Alta, pero la completitud del conjunto descansa en esa enumeración — los conteos son pisos):

• Traspasos: 2dQg9J… reenvió 1,020.653 SOL a AgnEKmN1XHBduneu9bFu1bfp69GRVUuCyNpQjAHSJ6do (2 tx); 8E6SHPRJ… reenvió 4,631.92 SOL a 3vy9hoGMq382E48EEyGuEYTeP8Raya8WRVRgbrvCGxKY (2 tx). (Las formas abreviadas de estas dos cuentas se usan más abajo tras esta primera mención completa.)
• Swaps en DEX a USDT (2026-06-02): A6uMgTcF… convirtió 5,300.156953 SOL → 400,000 USDT (su salida de swap iguala su posterior única salida de 400,000 USDT — el balance cierra); 3vy9hoGM… convirtió 2,324.482379 SOL → 173,500.88 USDT; AgnEKmN1… convirtió 513.30551 SOL → 38,305 USDT.
• Movimientos terminales: AgnEKmN1… envió 38,276 USDT a B3KoJ9TETMmEiAUPMXzeCJsTvHh2rn1mawj3NZMi1zrf (2026-06-08), una cuenta cuya página sellada de Solscan muestra las etiquetas literales #Binance Exchange y #Deposit Address. Por separado, el pool 4AV2Qzp3N4c9RfzyEbNZs2wqWfW4EwKnnxFAZCndvfGh — nombre público en Solscan Privacy Cash Pool, owner Privacy Cash — fue acreditado con 1,107.4496944 SOL en 6 depósitos sellados (183.5 SOL desde AgnEKmN1…; 923.9496944 SOL desde 3vy9hoGM…).

La parada honesta: salidas materiales (400,000 USDT + 5,424.15 SOL desde el destino de RELAY-01, y salidas adicionales desde 3vy9hoGM…) fueron a cuentas que no enumeramos. El mixer es una frontera dura de visibilidad — los depósitos son observables, los retiros son no-vinculables on-chain. Por eso no afirmamos ninguna atribución terminal de la pata Solana ni ninguna afirmación sobre dónde aterrizó la mayoría de su valor.

9. Un aparato EIP-7702 Alta · evidencia

La dirección atacante operó bajo delegación EIP-7702 (transacción tipo 0x4) en BSC. Sellado on-chain: la transacción 0x6f83d59da4de3ac68c9cb941530daa2d75d33c6e43497ee0dc6a8efbc171e211 (bloque 101536427) delega la autoridad de la cuenta del atacante a 0x44BCb3eAeE1C15f5D669A2B5e628d42c1ec19A18 en chainId 0x38. Las páginas selladas del explorador muestran: más de 10,000,000 de autorizaciones EIP-7702, valores de nonce de autoridad de hasta 123,429 al 2026-05-31, y — en la página del contrato delegado — CONTRACT CREATOR: DxSale Exploiter 1, la propia etiqueta del atacante.

Contraste, sellado on-chain: las wallets relay RELAY-01 y RELAY-02 también ejecutaron transacciones tipo 0x4, pero delegan a 0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B — un delegado de wallet estándar ampliamente desplegado — no al delegado personalizado del atacante.

Alcance: las cifras de escala (>10M autorizaciones, nonce 123,429) son agregados computados por el explorador sobre capturas selladas, no re-derivados por nosotros; el bytecode del delegado no fue deconstruido. Esto es una semilla para una investigación dedicada.

10. Dos posturas de opsec — sobre fondos mezclados Media · hipótesis

Esto es un marco interpretativo sobre los hallazgos de evidencia anteriores; no afirma hechos nuevos, ni identidad, ni intención. Y hereda el caveat de commingling por completo: la dirección atacante es un operador serial (123,448 transacciones; el aparato EIP-7702 de F-09), y los fondos de abajo son sus proceeds mezclados. La evidencia sellada no establece que provengan del drenaje del locker de DxSale específicamente. El vínculo con DxSale es la dirección compartida, no una traza de valor.

Dicho eso, las dos cadenas lucen muy distintas:

• BSC — ofuscación mínima. Atacante → 2 distribuidores → al menos 30 wallets (piso ≥2,965.28 BNB), con las 5 wallets muestreadas barriendo a una sola hot wallet Binance 51: una salida directa y expuesta a KYC que concentra cualquier apalancamiento de subpoena en un exchange.
• Solana — bastante más sofisticación. El tramo con bridge (valuado por el operador en ~$1,350,897.92 a través de 24 cruces) se dividió en tres destinos, se swapeó a USDT, envió 1,107.45 SOL a un mixer Privacy Cash y se abrió hacia cuentas no-enumeradas — con solo 38,276 USDT llegando a una cuenta de depósito etiquetada de Binance.

Lecturas posibles, ninguna afirmada: (a) operadores o playbooks distintos por cadena; (b) un operador aplicando mayor opsec al tramo cross-chain; (c) la salida BSC se apoyó en cuentas mula o comprometidas donde la exposición KYC era aceptable. La asimetría también podría ser un artefacto de qué tan profundo enumeramos cada lado. Lo enmarcamos para el lector; no lo resolvemos.

Lo que esta investigación no afirma

• Ninguna cifra en dólares específica de DxSale para los fondos lavados. Los fondos son proceeds mezclados de un operador serial; el vínculo con DxSale es la dirección compartida, no una traza de valor sellada.
• Ninguna identidad del mundo real. Toda referencia a “Binance”, “Bybit”, “DxSale Exploiter” y “Privacy Cash” es una etiqueta de entidad del explorador de bloques — una observación atribuida, no una identidad probada, y nunca una persona natural.
• Ningún conteo exhaustivo en BSC. Los conteos de wallets y transacciones del lado EVM son pisos.
• Ningún aterrizaje terminal en Solana. El mixer y el fan-out no-enumerado son fronteras duras.
• Ningún mecanismo de drenaje probado. F-04 es una hipótesis pendiente de deconstrucción de contratos.

Metodología y custodia

Cada transacción, dirección y bloque citado es reproducible por cualquier tercero contra las cadenas públicas BNB Smart Chain y Solana. Toda la evidencia está sellada bajo una cadena de custodia de escritura-única (WORM): cada artefacto es hasheado por contenido (SHA-256) al capturarse y los hashes quedan fijados (pin); el conjunto de hallazgos se valida con un gate mecánico de exportación antes de publicar. Los niveles de confianza siguen nuestro estándar forense OCS-FIS-V1: el lenguaje afirmativo se usa solo para evidencia sellada y observable, y las interpretaciones se etiquetan como hipótesis. El rastro público preexistente de este caso se trató solo como pista — cada hecho aquí fue re-recolectado y re-sellado de forma independiente.

Las direcciones y hashes de transacción de referencia aparecen en línea arriba y resuelven directamente en los exploradores públicos.