Envenenamiento de direcciones: por qué siete de cuarenta caracteres bastaron para desviar 2 millones de dólares

El 21 de agosto de 2026, una transferencia de 2.000.000 USDC salió de una cartera y aterrizó en una dirección que coincidía con la correcta en exactamente siete de cuarenta caracteres. Cuatro caracteres al principio, tres al final. Los treinta y tres restantes eran completamente distintos. Ese recorte es precisamente todo el ataque, porque las carteras y los exploradores de bloques suelen mostrar las direcciones de forma abreviada: unos pocos caracteres delante, unos pocos detrás y tres puntos en medio. Quien solo mira esa forma corta ve en la falsificación lo mismo que en la original.

La técnica se llama address poisoning, o envenenamiento de direcciones. El envenenamiento de direcciones consiste en que un atacante cuela en el historial de transacciones de tu cartera una dirección falsa pero de aspecto parecido, para que más tarde la copies de ahí y envíes tú mismo tu dinero a ella. No se piratea nada, no se roba ninguna clave, no se falsifica ninguna firma. La transferencia es técnicamente impecable y está autorizada por el titular. Simplemente va al destinatario equivocado y, en una cadena de bloques, con eso queda firme.

Este artículo desmonta el caso del 21 de agosto y después va más allá de lo publicado hasta ahora: hemos extraído por completo el historial de transacciones de la cartera afectada y lo hemos contabilizado. El resultado muestra que la dirección señuelo no era un caso aislado, sino parte de un conjunto que supone un tercio de todas las contrapartes de esa cartera.

Envenenamiento de direcciones explicado: cómo entra una dirección falsa en tu historial

El atacante no necesita acceso a tu cartera. Solo necesita una línea en tu historial, porque para la mayoría de los usuarios ese historial es la fuente más cómoda para una dirección de recepción. En lugar de sacar una cadena de cuarenta caracteres de un contrato, de un correo o de un papel, uno retrocede en la aplicación de la cartera o en el explorador, localiza la línea de la última transferencia al mismo destinatario y copia de ahí la dirección. Ese gesto es el objetivo.

Para entrar en el historial hay dos vías habituales. La primera es la transferencia de polvo: el atacante te envía desde su dirección falsa un importe minúsculo, económicamente irrelevante. Basta con una fracción de céntimo. Con eso su dirección figura en tu historial sin que él tenga que saber nada de ti.

La segunda vía es el evento de transferencia falsificado. En Ethereum y en redes comparables, cualquiera puede publicar su propio contrato de token, y ese contrato puede informar de lo que quiera. Un contrato así emite un evento que aparenta que acabas de enviar tú mismo un importe elevado a una dirección determinada. En tu historial aparece entonces una transferencia consumada que nunca existió. La ventaja para el atacante es evidente: una dirección a la que supuestamente ya has enviado dos millones resulta más familiar que otra de la que solo llegó polvo.

Ambas vías le cuestan al atacante casi nada y se pueden repetir a voluntad. No necesita saber cuándo harás tu próxima transferencia. Solo necesita que, en ese momento, su línea esté arriba en tu lista. Que esto funcione tan bien en una red como Ethereum se debe también a que allí cualquier contrato de token puede publicarse sin revisión.

El caso Bofur Capital: 2 millones de USDC treinta minutos después de la retirada en Compound

La firma de seguridad PeckShield notificó el suceso el 22 de agosto de 2026 y atribuye la cartera afectada al participante de mercado Bofur Capital. Esa atribución procede de PeckShield, no puede confirmarse solo con los datos de la cadena y la recogemos aquí como información de terceros. El desarrollo de los hechos, en cambio, figura abiertamente en la cadena y es verificable. Todas las horas que siguen son tiempo universal coordinado.

El 20 de agosto, a las 20:12:23, la cartera transfirió 2.000.000 USDC a una dirección que ya había utilizado un mes antes. Ocho minutos y treinta y seis segundos después, a las 20:20:59, llegó una transferencia de polvo de 0,0002 USDC. El remitente era una dirección de aspecto similar a la recién utilizada. Esa misma dirección había sido dotada segundos antes por un tercero con 0,000801 USDC, es decir, con el saldo justo para ese único señuelo.

En las casi dos horas siguientes aparecieron además en el historial de la cartera dos supuestas transferencias de 2.000.000 cada una a la misma dirección falsa, a las 20:41:11 y a las 21:16:11. Ambas proceden de un contrato de token ajeno y nunca se produjeron. Para quien mirase la lista al día siguiente, la dirección falsa parecía una a la que esa cartera acababa de enviar varias veces importes millonarios.

El 21 de agosto, a las 16:01:23, la cartera retiró 2.000.000 USDC del contrato Compound USDC. A las 16:31:11, treinta minutos más tarde, salieron 2.000.000,000000 USDC hacia la dirección falsa. No hubo un segundo intento ni corrección alguna. El importe pasó después por una cartera de recogida, se cambió a DAI a las 23:28:35 a través del contrato de liquidación de CoW Protocol y quedó aparcado a las 23:31:11 como 1.999.939,476314 DAI en una tercera dirección. Ahí sigue, a fecha de este análisis, sin cambios.

Cuatro caracteres delante, tres detrás: cuánto se parecía realmente la dirección falsa a la verdadera

El punto decisivo es lo poco que se parecen ambas para que el ataque funcione. La dirección de destino realmente utilizada y la falsa coinciden en cuatro caracteres al principio y en tres al final. Son siete de cuarenta caracteres. Treinta y tres caracteres del medio son distintos, muchos de ellos a simple vista.

Que aun así baste tiene que ver con la representación. La forma abreviada habitual en las aplicaciones de cartera, los exploradores y los listados resumidos muestra aproximadamente los seis primeros y los cuatro últimos caracteres. Ese fragmento exacto es prácticamente idéntico en ambas direcciones. Los treinta y tres caracteres divergentes están en la parte que la interfaz sustituye por tres puntos.

Generar una dirección así no tiene ningún mérito ni exige una proeza de cálculo. El atacante prueba pares de claves hasta dar con uno cuya dirección presente los caracteres iniciales y finales deseados. Cuantos más caracteres deban coincidir, más se tarda, pero cuatro delante y cuatro detrás se consiguen en minutos con hardware corriente. Por eso el número de señuelos tampoco está limitado por el esfuerzo.

Transferencia de polvo y evento falsificado: dos técnicas, un mismo fin

En este caso ambas técnicas actuaron en paralelo, y esa es la parte que falta en lo publicado hasta ahora. Lo que se comunicó fue la transferencia de polvo de 0,0002 USDC. Junto a ella figuran en la cadena varias supuestas transferencias millonarias procedentes de contratos falsos, que son las que completan la imagen en el historial.

La diferencia tiene consecuencias prácticas. Un importe de polvo procedente de una dirección desconocida lo ignoran muchos usuarios, porque lo clasifican como publicidad o correo basura. En cambio, una línea que parece la propia transferencia millonaria recién efectuada funciona como un justificante. Quien busca el último pago al mismo destinatario encuentra precisamente esa línea, y está más arriba en la lista que la original.

Ninguna de las dos líneas puede borrarse técnicamente del propio historial. Una cadena de bloques no olvida nada, y un evento procedente de un contrato ajeno sigue visible aunque sea pura invención. Algunas interfaces ocultan los contratos sospechosos o los señalan. No conviene fiarse de ello, porque la detección es más o menos estricta según el proveedor.

Homóglifos en el nombre del token: por qué un símbolo falso parece USDC en el explorador

Para que las líneas falsas no llamen la atención, el token también tiene que resultar creíble. Los contratos empleados para ello llevan símbolos que en el explorador parecen USDC, DAI o ETH sin serlo. El truco se llama homóglifo. Un homóglifo es un carácter que se parece hasta confundirse con otro, pero que técnicamente es un carácter completamente distinto.

En los datos que extrajimos hay varias construcciones. Un grupo de contratos recurre a letras cirílicas: una dze cirílica en lugar de la S latina y una es cirílica en lugar de la C, más una U con acento. Lo que aparece en pantalla se lee entonces como USDC. Un segundo grupo intercala entre las letras caracteres de control invisibles, por ejemplo un unificador de ancho cero o un separador vocálico mongol. El símbolo tiene así exactamente el aspecto del verdadero sin serlo. Un tercer grupo trabaja con el recurso más simple que existe y escribe una ele minúscula en lugar de una i mayúscula, algo indistinguible en muchas tipografías. Y algunos contratos renuncian a todo disfraz y llevan sin más el símbolo correcto, porque el símbolo de un token no tiene por qué ser único.

Para ti eso significa: el símbolo que aparece junto a un importe no demuestra qué token se movió. El único identificador fiable es la dirección del contrato. De USDC y de DAI existe exactamente una correcta, y todos los exploradores la muestran al pulsar sobre el token.

Recuento propio: cuántas direcciones señuelo hay en el historial de una sola cartera

Este análisis lo ha realizado cryptoticker.io el 22 de agosto de 2026. A través de la interfaz pública del explorador de bloques Blockscout recuperamos todos los eventos de transferencia de tokens de la cartera afectada, a lo largo de seis páginas, y después depuramos duplicados y contabilizamos los registros. Se recogieron marca temporal, importe, dirección de contrato del token, remitente y destinatario.

Examinados: 300 eventos de transferencia únicos del periodo comprendido entre el 22 de noviembre de 2025 y el 22 de agosto de 2026, con 84 contrapartes distintas. 165 de esos eventos proceden de los contratos auténticos de USDC o DAI; 135, de otros contratos.

Nueve grupos, treinta y tres direcciones: el recuento en detalle

Agrupamos las 84 contrapartes según coincidieran o no en los cuatro primeros y los cuatro últimos caracteres, es decir, exactamente en el fragmento que muestra una representación abreviada. Resultado: 33 de las 84 direcciones caen en nueve grupos de ese tipo. Cada uno de esos grupos contiene al menos dos direcciones imposibles de distinguir en forma corta. Cerca de un tercio de todas las contrapartes que esa cartera ha tocado alguna vez pertenece, por tanto, a un conjunto de dobles.

El grupo mayor abarca ocho direcciones. El segundo, cinco; el tercero, cuatro. Otros tres grupos tienen tres miembros cada uno y dos tienen dos. En el grupo del que procede el robo del 21 de agosto hay tres direcciones, y en un grupo vecino con el mismo inicio pero distinta terminación, otras tres, entre ellas la dirección de destino realmente utilizada.

La distribución dice algo sobre el método: para cada contraparte recurrente de esa cartera se crearon al parecer varios señuelos y no uno solo. Quien copia una dirección del historial mete la mano en un conjunto en el que la dirección correcta está en minoría.

Límites de este recuento

Lo que no hemos podido comprobar forma parte del informe igual que el resultado. No sabemos si detrás de los nueve grupos está el mismo actor; la agrupación describe un patrón, no una autoría. No sabemos si los 135 eventos procedentes de contratos ajenos son todos intentos de ataque, porque entre ellos hay también tokens publicitarios corrientes sin relación con esta técnica. No sabemos qué software de cartera utilizaba la cartera afectada ni cómo representa las direcciones. No sabemos si inversores alemanes fueron abordados por esos mismos grupos, ni cuántos, porque los datos de la cadena no permiten deducir el lugar de residencia. Y no sabemos si los fondos podrán recuperarse.

El contrato de Compound también tiene dobles: por qué se falsifican incluso las direcciones de protocolo

Un resultado secundario del recuento merece atención propia. La contraparte más frecuente de esa cartera es el contrato Compound USDC, a través del cual deposita y retira con regularidad. También para esa dirección se encontraron otras dos idénticas en los cuatro primeros y los cuatro últimos caracteres.

Eso amplía el peligro más allá del destinatario de un pago. Quien copia una dirección de contrato de su propio historial, para introducirla en una interfaz de cartera o para comprobar que habla con el protocolo correcto, puede ser desviado de la misma manera. Aquí la contramedida es más sencilla que con un destinatario privado: las direcciones de contrato de los protocolos conocidos figuran en su propia documentación, y los exploradores identifican por su nombre los contratos verificados. En el contrato de Compound y en el de liquidación de CoW Protocol esa identificación estaba presente en nuestra extracción; en los dobles, no.

Ocho minutos después del pago real: cuándo se coloca el señuelo

El momento elegido para los señuelos fue el detalle más sorprendente de nuestro análisis. El ataque siguió de inmediato a un pago real, y lo hizo dos veces con el mismo patrón.

El 21 de julio de 2026, a las 14:37:11, la cartera transfirió 2.000.000 USDC a su contraparte habitual. A las 14:45:23, ocho minutos y doce segundos después, llegó una transferencia de polvo de 0,0002 USDC desde una dirección con los mismos cuatro caracteres iniciales. El 20 de agosto se repitió la escena: transferencia real a las 20:12:23, transferencia de polvo a las 20:20:59, una distancia de ocho minutos y treinta y seis segundos.

De ahí se deduce que la cadena está siendo vigilada y que el señuelo solo se coloca cuando se ha hecho visible un pago real y recurrente. Eso importa para la defensa: el punto más peligroso del historial es la línea situada justo encima de la última transferencia real, porque se colocó donde se buscará la próxima vez. Quien envía con regularidad el mismo importe al mismo sitio resulta un objetivo especialmente rentable para esta técnica.

El ladrón, envenenado a su vez: qué ocurrió en su historial 25 minutos después del robo

A las 23:31:11, los 1.999.939,476314 DAI sustraídos reposaban en su nueva dirección. Veinticuatro segundos más tarde, a las 23:31:35, apareció en el historial de la cartera de recogida una transferencia por exactamente el mismo importe a una dirección que coincidía con la recién utilizada en los cuatro primeros y los cuatro últimos caracteres. El importe procedía de un contrato falso cuyo símbolo parecía DAI gracias a un carácter de control invisible.

La cosa no acabó ahí. A las 23:44:23 llegó una transferencia de polvo real de 0,0002 DAI desde otra dirección doble. Durante la noche siguieron tres transferencias falsas más por el mismo importe a tres dobles distintos, además de líneas procedentes de contratos que se hacían pasar por ETH y, en la mañana del 22 de agosto, una transferencia de cero desde el contrato auténtico de DAI. En pocas horas figuraban en el historial del autor al menos cuatro direcciones distintas, todas ellas con los mismos cuatro caracteres iniciales y los mismos cuatro finales que su propio escondite.

El episodio es más que una anécdota. Muestra, en primer lugar, hasta qué punto está automatizada esta técnica: un saldo elevado recién constituido se detecta y se atiende al parecer en cuestión de segundos, sin que nadie tenga que comprobar de quién es. Y muestra, en segundo lugar, que el ataque no necesita saber nada de su víctima. Va contra una costumbre, no contra una persona.

Comprobar la dirección en vez de copiarla: los pasos que dejan el ataque en nada

La buena noticia de esta técnica es que depende por completo de una sola costumbre. Quien no saca la dirección de recepción del historial de transacciones no está expuesto al envenenamiento de direcciones, por muchos señuelos que haya en su lista.

El primer paso es, por tanto, el más importante: coge la dirección de la fuente de la que procede originalmente. Esa fuente es la factura, la página de retirada de tu exchange, la libreta de direcciones de tu cartera o el mensaje del destinatario. Tu propio historial no es una fuente, sino una copia en la que cualquiera puede escribir.

El segundo paso es la comprobación íntegra. Compara la cadena entera, no la forma corta. Lo más fiable es poner una junto a otra las direcciones de ambas fuentes y cotejarlas carácter a carácter, o pegarla en un campo de búsqueda y comprobar que la dirección encontrada tiene realmente el historial esperado. Un vistazo a los primeros y últimos caracteres hace exactamente lo que el atacante tenía previsto.

El tercer paso afecta al centro. Si solo puedes comprobar un fragmento, comprueba deliberadamente caracteres del centro de la dirección y no de los extremos. En nuestro caso, treinta y tres de los cuarenta caracteres eran distintos, y los treinta y tres estaban en la zona que nadie mira.

Por qué la pantalla de la cartera de hardware es el último control

Una cartera de hardware muestra la dirección de recepción en su propia pantalla antes de que confirmes la transacción. Esa pantalla no depende del ordenador y no puede ser reescrita por una interfaz manipulada. Es, por tanto, el último lugar donde puede detectarse un destinatario equivocado, y en la mayoría de los dispositivos la dirección completa puede recorrerse ahí. La comparación merece especialmente la pena con importes elevados y cuesta unos segundos. Qué dispositivos ofrecen esa visualización y de qué forma lo recoge nuestra comparativa de carteras de hardware.

Libreta de direcciones y lista blanca: cómo fijar una dirección de recepción de una vez

Los pagos recurrentes son, como muestra el caso, el objetivo preferido. Justo contra eso ayuda una libreta de direcciones. Casi todos los programas de cartera y todos los exchanges grandes permiten guardar una dirección de recepción una sola vez, ponerle un nombre y en adelante seleccionar únicamente ese nombre. La copia desde el historial desaparece así por completo.

En los exchanges esa misma función suele llamarse lista blanca de retiradas. Tiene una ventaja adicional: las direcciones nuevas a menudo no pueden utilizarse hasta pasado un plazo de espera de 24 o 48 horas. Aunque alguien se hiciera con tu acceso, no podría enviar el saldo de inmediato a una dirección recién creada. Comprueba si tu proveedor ofrece ese plazo de bloqueo y si está activado, porque con frecuencia no lo está de fábrica.

El momento del registro sigue siendo decisivo. Una dirección que traslades a la libreta desde un historial envenenado quedará ahí permanentemente equivocada, y el siguiente error se producirá entonces de forma automática. Regístrala por eso desde la fuente original y compruébala íntegramente una vez al introducirla.

Transferencia de prueba: cuándo ayuda un pequeño anticipo y cuándo solo cuesta comisiones

Un pequeño pago previo a una dirección nueva es una protección sensata si el destinatario puede confirmarte la recepción. Entonces compruebas el resultado en lugar de la dirección, y esa es la prueba más sólida. En un exchange ves el abono en tu propia cuenta; con un socio comercial necesitas una respuesta.

Sin esa confirmación, la transferencia de prueba aporta poco. Que una transacción se haya confirmado solo indica que la dirección existe. En un ataque de envenenamiento de direcciones la dirección falsa existe, por supuesto, y acepta el importe de prueba igual que el grande. Quien transfiere después sin respuesta no habrá hecho más que pagar dos veces al mismo atacante.

Calcula además los costes. En redes con comisiones elevadas, una transferencia de prueba puede salir cara, mientras que una comparación íntegra de la dirección no cuesta nada. El orden que funciona: comprobar primero la dirección por completo y, con destinatarios nuevos e importes elevados, probar además.

Documentar la pérdida: qué datos aseguras tras un envío erróneo

Una vez que el dinero se ha ido, la cadena de bloques no lo cambiará. Una transacción confirmada no puede revocarse y nadie puede deshacerla. Lo que cuenta ahora es la documentación, y de inmediato, porque las interfaces cambian y los listados se reordenan.

Asegura el identificador de la transacción, la dirección completa del destinatario, el momento exacto, el importe y la dirección de contrato del token movido. Asegura además la línea desde la que copiaste la dirección, con su marca temporal, porque acredita cómo ocurrió. Una captura de pantalla lo complementa, pero no sustituye a los identificadores. Qué sigue siendo posible después en la práctica y qué está definitivamente perdido lo hemos recogido en nuestro artículo sobre cripto enviada a la dirección equivocada.

Para el tratamiento fiscal de una pérdida así no existe en Alemania una línea clara y generalmente aceptada, y aquí no fijamos ninguna a propósito. Lo que sí puedes hacer es sentar la base: un registro completo y sin contradicciones de todas las operaciones afectadas, con el que pueda trabajar un asesor fiscal. Las herramientas de cartera y fiscalidad ayudan en ello, porque conservan direcciones y operaciones de forma duradera.

Detectar el envenenamiento de direcciones: qué te llevas de aquí

1. No saques nunca la dirección de recepción del historial de transacciones. Cógela de la factura, de la página de retirada o de la libreta de direcciones. El historial es el único sitio en el que un atacante puede escribir, y precisamente por eso ataca ahí. Qué carteras traen una libreta de direcciones aprovechable lo muestra nuestra comparativa de carteras de software.
2. Comprueba la dirección completa, con el foco en el centro. Siete de cuarenta caracteres bastaron en nuestro caso para que la forma corta pareciera idéntica. Con importes mayores, lee además la dirección en la pantalla de tu cartera de hardware, porque esa pantalla no se puede manipular; los dispositivos, en conjunto, están en la comparativa de carteras de hardware.
3. Configura la libreta de direcciones y la lista blanca de retiradas antes de necesitarlas. Registra una sola vez a los destinatarios recurrentes desde la fuente original y activa, donde esté disponible, el plazo de bloqueo para direcciones nuevas. Lleva un registro limpio de tus direcciones y operaciones, por ejemplo con alguna de las herramientas de nuestra selección de herramientas fiscales y de seguimiento de cartera.

Las pruebas de este artículo son verificables públicamente: la comunicación del incidente en The Crypto Times y el historial completo de transacciones de la cartera afectada en el explorador de bloques Blockscout, en el que se basa nuestro recuento.

(22 de agosto de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)