Poco después del último anuncio de "Otra estafa de lanzamiento aéreo, pero con un giro", identificamos una estafa muy similar según los informes de las víctimas.

Según los informes de muchas víctimas, las transferencias de 0 USDT desde direcciones no reconocidas continuaron apareciendo en el historial de transacciones de direcciones de los usuarios de la red TRON, y en cada caso se llamó a la función TransferFrom.

Al hacer clic en una transacción aleatoria para ver sus detalles, como se muestra en la Imagen 1 para la transacción con tx 701e7 en el cuadro rojo.

Esta transacción es una llamada a la función TransferFrom, que permite que la dirección que comienza con TCwd transfiera 0 USDT desde la dirección que comienza con TAk5 a una dirección que comienza con TMfh.

Esto indica que el culpable fue la dirección que comenzaba con TCwd;

Examinemos esta dirección:

Evidentemente, esta dirección llama a TransferFrom varias veces por segundo.

A continuación, examinaremos las transferencias de USDT desde esta dirección.

La mayoría tiene registros de transferencias de cantidades de 0,001. Esto nos recordó una estafa similar que involucraba estafas de lanzamiento aéreo que consistían en direcciones con números finales idénticos.

La dirección que comienza con TCwd podría ser una de las direcciones principales, distribuyendo 0.001 a múltiples direcciones que podrían ser utilizadas por el atacante para el lanzamiento aéreo. Para verificar esto se utilizó la dirección TMQy….6ZRMK.

TADXT……Lhbuo y más abajo están todas las direcciones de recepción de USDT.

La imagen 6 demuestra que la dirección TADXT… Lhbuo tuvo dos transferencias regulares con la dirección TMQ…. Esta persona estaba siendo acosada no solo por lanzamientos aéreos con el mismo último número, sino también por el método 0 transferFrom descrito en este artículo. También es razonable suponer que la misma organización es responsable de estos dos métodos.

Es posible iniciar una transferencia de 0 desde la cuenta de cualquier usuario a una cuenta no autorizada sin fallas, ya que la función TransferFrom del contrato de token no requiere que el monto de la transferencia aprobada sea mayor que 0. El atacante malicioso utiliza esta condición para inicie repetidamente acciones TransferFrom a usuarios activos para activar estos eventos de transferencia.

Aparte de TRON, no podemos evitar preocuparnos si ocurriera el mismo escenario en la red Ethereum.

Entonces realizamos una pequeña prueba en la red Ethereum.

Las llamadas de prueba fueron exitosas, aplicando la misma regla a la red Ethereum.

Inevitablemente, si un usuario descubre un registro de transacción que no es el suyo, puede temer que su billetera haya sido comprometida. Cuando un usuario intenta alterar su billetera o volver a descargarla, corre el peligro de ser estafado y robado; por el contrario, si un atacante “secuestra” el historial de transacciones de un usuario, el usuario puede perder activos al copiar la dirección de transferencia incorrecta.

SlowMist desea recordarle que debido a la inmutabilidad de la tecnología blockchain y la irreversibilidad de las transacciones en cadena, debe verificar la dirección antes de ejecutar cualquier actividad. Además, si ve alguna transacción inesperada desde su dirección, tenga cuidado y analícela detenidamente. No dudes en contactarnos si tienes alguna pregunta, nuestro DM está siempre abierto.

Esta serie es un estudio de caso del servicio de investigación MistTrack.

Descripción general

Los piratas informáticos atacaron un proyecto y transfirieron todos los fondos robados a TornadoCash, lo que llevó a la parte del proyecto a buscar ayuda de MistTrack. Descubrimos la dirección de retiro establecida al realizar un análisis de las transacciones de TornadoCash y separar los fondos de otros usuarios. Después de unos días de espera, algunos de los fondos robados finalmente se transfirieron a un intercambio. Enviamos un mensaje en cadena a la dirección de retiro del pirata informático, solicitando la devolución de los fondos robados o enfrentando acciones legales. Los fondos robados fueron devueltos al equipo en nueve horas.

MistTrack jugó un papel vital en el Caso 01 siguiendo los siguientes pasos:

1. Establecer confianza entre las partes

2. Seguimiento de fondos robados

3. Análisis del perfil de hacker

4. Análisis de retiros de TornadoCash

5. Seguimiento de los retiros de TornadoCash

6. Comunicación en cadena

7. Participación y apoyo de los organismos encargados de hacer cumplir la ley cuando sea necesario

Seguimiento de fondos robados

Después de recibir la solicitud de asistencia del equipo, inmediatamente comenzamos una investigación y análisis de este incidente.

Durante nuestro análisis, llegamos a la conclusión de que todos los fondos robados fueron transferidos a TornadoCash.

Análisis del perfil del hacker

El análisis de MistTrack del perfil de los hackers se basa en estos puntos clave.

Fuente de tarifa de gas

Herramientas utilizadas

Cronograma operativo

Perfil de hacker

Análisis previo al ataque

…

La financiación inicial de este ataque provino de TornadoCash, como puede ver a continuación.

Para evitar la detección, los fondos robados frecuentemente se intercambian, puentean o incluso se lavan utilizando técnicas sofisticadas. Esto se puede hacer con una variedad de herramientas, como xxSwap, etc., antes de depositarlo en TornadoCash.

Análisis de retiro de TornadoCash

Según la información proporcionada anteriormente, el Análisis de retiro de TornadoCash es la clave que el Caso 01 pudo resolver.

La herramienta que se muestra a continuación se utiliza en el proceso de análisis de retiros. Ayudó a clasificar las direcciones de retiro de TornadoCash que cumplen con los criterios de filtrado.

Después de obtener la lista de direcciones de retiro, clasificamos las direcciones de retiro según las siguientes características:

Periodo de tiempo activo

Distribución del precio del gas.

Interacción con plataformas similares

Patrones de direcciones de retiro

Distribución del monto del retiro

En una de nuestras clasificaciones encontramos que compartía características similares:

Plataformas similares usadas: xxSwap

Mismo período activo que las direcciones del hacker.

Consistente con la cantidad depositada por los piratas informáticos en TornadoCash

Más importante aún, una de las direcciones de retiro estaba asociada con la dirección del pirata informático original. Dándonos así pruebas de que estas direcciones estaban relacionadas con el hacker.

Monitoreo de retiros de TornadoCash

Notificamos inmediatamente a las partes involucradas sobre todas las direcciones de retiro relevantes de TornadoCash y utilizamos nuestro sistema de monitoreo MistTrack AML para alertarnos de cualquier actividad adicional.

Comunicación en cadena

Después de unos días de seguimiento, recibimos una alerta informándonos que los piratas informáticos habían enviado una parte de los fondos robados a un intercambio después de transferirlos a varias billeteras. Inmediatamente nos comunicamos con la víctima para discutir el mejor curso de acción. Aconsejamos al equipo que se comunique con las autoridades encargadas de hacer cumplir la ley para obtener apoyo y ayudar al proyecto a enviar un mensaje en cadena al hacker. Mensaje: "Reembolsaremos los fondos robados dentro de las 48 horas y retendremos una parte como recompensa por errores, o continuaremos nuestra investigación y tomaremos acciones legales con la ayuda de las autoridades". A lo largo de todo el proceso, proporcionamos pruebas a las autoridades y supervisamos continuamente todas las direcciones involucradas.

Resultado

A las 9 horas de enviarle al hacker un mensaje en cadena, la mayoría de los fondos robados del equipo habían sido devueltos.

Recientemente, varios usuarios denunciaron que les habían robado sus activos. Al principio, no estaban seguros de cómo habían robado sus fondos, pero tras una inspección más cercana, descubrimos que se trataba de un nuevo tipo de estafa de lanzamiento aéreo.

A muchas de las direcciones de las víctimas se les lanzaban constantemente pequeñas cantidades de tokens (0,01 USDT, 0,001 USDT, etc.), y lo más probable es que fueran atacados porque sus direcciones estaban involucradas en transacciones y volúmenes comerciales de alto valor. Los últimos dígitos de la dirección del atacante son casi idénticos a los últimos dígitos de la dirección del usuario. Esto se hace para engañar al usuario para que copie accidentalmente la dirección incorrecta del historial de transacciones y envíe los fondos a la dirección incorrecta.

Información relacionada

Dirección del atacante 1: TX…dWfKz

Dirección de usuario 1: TW…dWfKz

Dirección del atacante 2: TK…Qw5oH

Dirección de usuario 2: TW…Qw5oH

Análisis de seguimiento de niebla

Comencemos con una descripción general de las dos direcciones de los atacantes:

La dirección del atacante (TX…..dWfKz) y la dirección del usuario (TW…..dWfKz) terminan en dWfKz. Incluso después de que el usuario envió por error 115.193 USDT a la dirección incorrecta, el atacante sigue enviando 0,01 USDT y 0,001 USDT a la dirección de la víctima utilizando dos nuevas direcciones que también terminan en dWfKz.

Lo mismo le pasó a nuestra segunda víctima. La dirección del atacante (TK…. .Qw5oH) y la dirección del usuario ( (TW…. .Qw5oH) terminan en Qw5oH. La víctima envió por error 345,940 USDT a la dirección incorrecta y el atacante continúa enviando 0.01 USDT a la dirección de la víctima. usando una nueva dirección que también termina en Qw5oH.

A continuación, examinaremos la dirección 1 del atacante utilizando nuestra plataforma AML MistTrack (tx.. .dWfKz). Como se muestra en la siguiente figura, la dirección 1 del atacante lanza 0,01 USDT y 0,02 USDT a varias direcciones de destino, todas las cuales han interactuado con la dirección que termina en dWfKz.

Mirando hacia atrás, podemos ver que las transferencias iniciales para estos lanzamientos aéreos provinieron de la dirección TF…. J5Jo8 el 10 de octubre, cuando se le transfirieron 0,5 USDT.

Análisis preliminar del FT….J5Jo8:

Esta dirección envió 0,5 USDT a casi 3300 direcciones, lo que indica que cada una de estas direcciones de recepción podría ser una dirección utilizada por el atacante para realizar lanzamientos aéreos. Entonces decidimos seleccionar una dirección al azar para verificar nuestra teoría.

MistTrack se utilizó para analizar la última dirección en el gráfico anterior, TX…..4yBmC. Como se muestra en la figura siguiente, el atacante utiliza la dirección TX….4yBmC para lanzar 0,01 USDT a varias direcciones que terminan en 4yBmC.

Veamos la dirección 2 del atacante (TK…. Qw5oH): 0,01 USDT se lanzaron desde el aire a varias direcciones y la financiación inicial de 0,6 USDT se envió desde TD…. .psxmk.

Como puede ver en el gráfico siguiente, el atacante envió 0,06 USDT a TD…. .kXbFq y también interactuó con la dirección de depósito de un usuario de FTX que termina en Qw5oH.

Así que inviertamos el proceso y veamos si otras direcciones han interactuado con TD… .kXbFq. ¿Hay otras direcciones con los mismos caracteres finales que las que se les enviaron desde el aire?

Una vez más, elegiremos dos direcciones al azar y probaremos nuestra teoría. (por ejemplo, la dirección de depósito de Kraken TU….hhcWoT y la dirección de depósito de Binance TM….QM7me).

Desafortunadamente, el estafador pudo engañar a algún usuario desprevenido para que le enviara sus fondos.

Resumen

Este artículo se centra en cómo un estafador explota a los usuarios que copian la dirección del historial de transacciones sin verificar la dirección completa. Lo logran generando una dirección similar que termina de la misma manera que la dirección del usuario y enviando pequeñas cantidades de fondos a la dirección del usuario de forma regular. Todo esto se hace con la esperanza de que los usuarios copien la dirección falsa y envíen sus fondos al estafador la próxima vez.

SlowMist desea recordarles a todos que debido a la inmutabilidad de la tecnología blockchain y la irreversibilidad de las operaciones en cadena, verifique la dirección antes de continuar. También se anima a los usuarios a utilizar la función de libreta de direcciones en su billetera para no tener que copiar y dirigir cada vez.

Fondo

Los funcionarios de Celer Network declararon el 18 de agosto que entre las 3:45 y las 6:00, hora de Beijing, ciertos usuarios de cBridge fueron dirigidos a contratos inteligentes maliciosos. Inicialmente, se sospechaba que la interfaz frontal de cBridge estaba comprometida por un ataque DNS.

Completamente diferente de los incidentes anteriores de piratería de puentes entre cadenas como Nomad, Wormhole, Ronin, Harmony, etc., este ataque no fue causado por errores en contratos inteligentes y protocolos entre cadenas o la intrusión de servidores relacionados, y la Los activos de la cadena bloqueados en cBridge también se han mantenido seguros. En este ataque, los piratas informáticos apuntaron directamente a la infraestructura subyacente en la arquitectura de Internet fuera del sistema Celer y permitieron a los usuarios de cadenas cruzadas acceder a una interfaz de usuario frontal de "phishing" dentro de un período de tiempo engañando al protocolo de enrutamiento subyacente de Internet ( BGP).La red Celer pudo limitar los daños gracias a su pronta respuesta. Esto se debe a que el equipo de la Red Celer cuenta con un sistema de seguimiento las 24 horas. Su equipo de servicio al cliente pudo identificar el problema y alertar a la comunidad de manera oportuna. El equipo de Celer Network habilitó al equipo de seguridad de SlowMist para responder a esta emergencia y realizar una investigación en profundidad.

Proceso de análisis

El equipo de Celer Network inicialmente sospechó de un ataque DNS y, después de comunicarnos con ellos, pudimos obtener más información sobre el nombre de dominio en cuestión: cbridge-prod2.celer.network. Descubrimos que el navegador no informó ningún error de certificado durante el ataque. Por lo tanto, nuestra investigación comenzó abordando primero la posibilidad de un ataque al DNS. (Un agradecimiento especial a @greysign1 por ayudarnos a comprobar rápidamente la posibilidad de un ataque DNS)

Comenzamos revisando la información relevante del certificado:

El certificado parece haber sido alterado inesperadamente, donde el certificado original emitido por Let's Encrypt fue reemplazado por un certificado falso emitido por GoGetSSL.

GoGetSSL puede emitir un certificado gratuito de 90 días:

Análisis del Certificado 1: https://crt.sh/?id=7356185959

Aparece un error de verificación de CRL en el certificado en el siguiente momento:

Análisis del Certificado 2: https://crt.sh/?id=7356185959

Este certificado también tiene un error de verificación de CRL en los siguientes momentos:

Después de examinar la dirección IP, el certificado y otra información asociada con el Certificado 1, descubrimos que la dirección IP vinculada a este certificado era 44.235.216.69.

La dirección IP del Certificado 2 no pudo consultar la dirección IP correspondiente al Certificado 2, lo que podría deberse a la corta duración del ataque y a que el motor de búsqueda de Internet no recopiló información relevante.

Como resultado, centramos nuestro análisis en los datos de resolución de IP para el dominio cbridge-prod2.celer.network:

La dirección IP, 44.235.216.69, estuvo asociada con cbridge-prod2.celer.network durante un período prolongado de tiempo.

Aquí está la pregunta: el hecho de que esta dirección IP, 44.235.216.69, estuviera asociada con cbridge-prod2.celer.network durante un período prolongado de tiempo, prueba que pertenecía al servidor oficial de Celer Network. Así lo confirmó también con el equipo de Celer Network. Entonces, ¿por qué había un certificado falsificado asociado con esta propiedad intelectual?

Entonces comenzamos a investigar el AS de 44.235.216.69 y descubrimos que el AS correspondiente a esta IP era inusual.

AS16509 anuncia bogones::

Al revisar los bogons, podemos determinar que este es generalmente el caso en el que un atacante falsifica una dirección IP para realizar un ataque: https://networkdirection.net/articles/routingandswitching/bgp-bogonsandmartians/ https://forum .networklessons.com/t/what-are-bogons/6333

Debido a que el AS en 44.235.216.69 presentaba anomalías, primero sospechamos que el problema estaba en BGP, por lo que nos comunicamos con Celer Network para obtener la dirección IP del atacante: 54.84.236.100. Descubrimos que AS14618, donde se encuentra la dirección IP, también tenía una excepción. (AS14618 también anuncia bogones)

Casualmente, el flujo ascendente de AS14618 era AS16509 (AS16509 es también el AS donde 44.235.216.69). Esto nos alertó sobre la posibilidad de un ataque BGP.

Nuestra investigación reveló que la IP: 54.84.236.100 estaba marcada como maliciosa.

Recopilamos información relevante sobre la IP: 54.84.236.100 de nuestra comunidad y encontramos una mención de que esa dirección IP está relacionada con otro incidente de ataque BGP que ocurrió en 2014. Sin embargo, debido a que este incidente ocurrió hace mucho tiempo, es posible que ya no sea importante.

Luego continuamos nuestra investigación siguiendo los registros dejados por este ataque BGP:

El seguimiento del registro BGP para la IP del ataque: 54.84.236.100 reveló que la ruta ya no está disponible.

Continuamos rastreando los rastros del enrutador BGP para la IP de celer: 44.235.216.69 y pudimos encontrar la ruta correcta.

Luego verificamos el registro de cambios de nodo BGP: hora de Beijing: 18/8/2022 2:48 a.m. — 18/8/2022 7:48 a.m. UTC+8

El 18/08/2022, se descubrió que el período de tiempo comprendido entre las 2:48 a. m. y las 7:48 a. m. BST tenía una gran cantidad de adiciones y eliminaciones de nodos de registros de cambios.

Continuamos monitoreando el registro de cambios de AS y descubrimos que AS14618 anteriormente tenía la información de enrutamiento 44.235.216.0/24, pero luego la ruta se modificó a Retirada, lo que demuestra que:

44.235.216.0/24 en AS14618 solía ser la ruta óptima

Ahora 44.235.216.0/24 en AS14618 ya no es la ruta óptima; es Retirado.

(Cuando ocurre un ataque BGP, el atacante publicará una ruta óptima para dirigir el tráfico a su propio servidor)

Para obtener datos más precisos, utilizamos el siguiente bgplay para verificar los cambios en las rutas relacionadas con 44.235.216.69 en el momento del ataque.

El 17/08/2022, podemos ver que durante el período de tiempo entre las 19:19:23 +UTC y las 23:19:23 +UTC, hubo una fluctuación significativa en la información de las rutas de enrutamiento BGP.

Este cambio se refleja en la dirección del tráfico de 44.235.216.0/24 a AS14618, donde el tráfico de 44.235.216.0/24 sale a través de AS16509 después del ataque.

Como resultado, estamos considerando que este incidente es probablemente un evento de ataque BGP, donde AS14618 parece ser un nodo bajo el control del atacante (el enrutador del AS14618 puede tener problemas de seguridad y puede ser explotado por atacantes), con el ataque con una duración aproximada de 4 horas.

El atacante pudo vincular el Certificado 1 (certificado falso) a la IP de Celer Network: 44.235.216.69 porque el atacante tenía un servidor malicioso con la misma IP. Dado que gogetssl admite http para la autenticación, pueden simplemente ingresar el texto proporcionado por gogetssl en el servidor malicioso. Por lo tanto, es posible vincular el Certificado 1 dirigiendo el tráfico al servidor malicioso con la misma IP a través de un ataque BGP. Como resultado, se alertó al navegador sobre el error del certificado.

Determinamos que AS14618 estaba controlado por el atacante por los siguientes motivos.

El atacante primero dirigió el tráfico 44.235.216.69 a AS14618 y, después del ataque, dirigió el tráfico 44.235.216.69 de regreso a AS16509.

IP de ataque: 54.84.236.100 también está dentro de AS14618.

Después del ataque, AS14618 fue retirado al 44.235.216.69.

Para responder a esta pregunta: El hecho de que esta dirección IP, 44.235.216.69, estuviera asociada con cbridge-prod2.celer.network durante un período prolongado de tiempo, prueba que pertenecía al servidor oficial de Celer Network. Así lo confirmó también con el equipo de Celer Network. Entonces, ¿por qué había un certificado falsificado asociado con esta propiedad intelectual?

Si utiliza el protocolo HTTPS para comunicarse, no puede cifrar/descifrar los datos (incluidos los datos de comunicación cliente/servidor) sin obtener la clave privada del certificado. Entonces, para garantizar que el certificado sea correcto y poder llevar a cabo el ataque de intermediario, el atacante debe volver a vincular el certificado aplicado en la autoridad al servidor malicioso con la misma IP 44.235.216.69. Esto permite al atacante descifrar los datos del cliente e insertar el código malicioso en los datos del paquete de respuesta.

Conclusión del análisis

Investigamos este ataque en colaboración con el equipo de Celer Network. A pesar de que se trataba de un sofisticado intento de ataque BGP a la red Celer, en el que el atacante preparaba todo, desde el momento del ataque, la falsificación de certificados, el control de AS y otras operaciones.

En última instancia, reconocemos que muchos proyectos ya son conscientes de los riesgos asociados con los ataques a BGP y han tomado las precauciones adecuadas. Sin embargo, muchos todavía no lo saben, particularmente cuando se trata de modificaciones de rutas de red inducidas por cambios de AS. Sin medidas adecuadas de preparación y respuesta, existe un riesgo considerable de nuevos ataques por parte de los mismos atacantes u otros. Por lo tanto, instamos a que las organizaciones, los ISP y los proveedores de alojamiento de servidores reconozcan dichos riesgos y coordinen estrategias defensivas para evitar que incidentes similares vuelvan a ocurrir. Y, como siempre, si alguna vez necesita ayuda, comuníquese con el equipo de seguridad de SlowMist.

Adjunto

Gráfico DNS de cbridge-prod2.celer.network: