0x78: El correo era de dev.to y el fraude estaba en el comentario
El correo era de dev.to y el fraude estaba en el comentario
Hoy me llegó un aviso de dev.to.
Alguien llamado Dev Support Team me había mencionado en un comentario.
Lo primero que hice fue abrir el .eml y mirar las cabeceras.
Eran auténticas.
DKIM de dev.to y de SendGrid en pass, SPF pass desde la IP 168.245.48.148 y DMARC pass.
El From es yo@dev.to y el Return-Path rebota en em4960.dev.to.
Ese detalle cambia la lectura del incidente.
El remitente no está suplantado, así que usaron el sistema de menciones de la plataforma para que la notificación saliera desde su infraestructura real y pasara todos los filtros.
La mención era un barrido
Los dos avisos venían de cuentas creadas ese mismo día.
El nombre visible es 𝘿𝙚𝙫 𝙎𝙪𝙥𝙥𝙤𝙧𝙩 𝙏𝙚𝙖𝙢 con caracteres Unicode matemáticos.
Esos caracteres se saltan los filtros de texto y el nombre se lee como el de un administrador. Los usuarios son teclas al azar.
{"type_of":"user","id":4228803,"username":"fgggggggggggggggggg",
"name":"𝘿𝙚𝙫 𝙎𝙪𝙥𝙥𝙤𝙧𝙩 𝙏𝙚𝙖𝙢","twitter_username":null,
"github_username":null,"summary":null,"website_url":null,
"joined_at":"Nov 5, 2026"}Un solo comentario mencionó 10 cuentas por orden alfabético. @anabel_obieze_1a5f44815ba, @anagha_h_a68da6f1218e8e30, @anajsana95, @analista_83 (la mía) y seis más que empiezan por anand. (Fuente: dev.to).
Eso no es un ataque dirigido.
Es un barrido del directorio de usuarios con una lista pegada en un comentario.
Las cuentas ya no existen
Los dos perma links del aviso dan 404 hace un ratejo.
Comprobé un comentario legítimo en la misma plataforma y ese responde 200 así que no es un fallo de la ruta.
Los perfiles tampoco cargan y la API sigue devolviendo los datos porque los cachea.
El comentario y la cuenta ya están barridos.
El destino era un dominio de cinco semanas
El acortador de esa campaña tr.ee/dev-to aterrizaba en offerup-pay.top (Fuente: tr.ee, resuelto el 5 de noviembre).
Está registrado el 1 de octubre a las 21:48 UTC, con PDR Ltd de registrador, nameservers de Cloudflare y certificado Let’s Encrypt emitido ese mismo día (Fuente: rdap.org).
La campaña tiene un paso anterior documentado, anti-bot.icu, registrado el 25 de septiembre con el mismo registrador, hoy está en clientHold y sus nameservers apuntan a suspended-domain.com (Fuente: rdap.org).
El dominio tampoco pasó desapercibido.
El 10 de octubre, diez días después del registro, un análisis público de urlscan.io ya devolvía el mismo título y el certificado del 1 de octubre. Google Safe Browsing no lo tenía clasificado en ese análisis (Fuente: urlscan.io).
El verify you are human protege al estafador
Pasé el control por curiosidad.
No es Cloudflare, es una copia barata con el título “Just a moment” un filtro de matiz encima, el botón derecho desactivado y el copiar y el Ctrl+U bloqueados.
No carga ningún script externo y manda la telemetría del arrastre a /__captcha/verify.
Debajo hay un párrafo que prohíbe a la IA a los LLM y a los rastreadores leer la página.
Un sitio real pone ese control delante de un registro para frenar bots.
Este lo pone delante de la estafa.
Así frena a los escáneres y a quien le pregunta a un asistente si el enlace es seguro.
Detrás aparece la ficha Mandatory Verification Of User #17984 con un plazo de 24 horas y un chat de soporte falso.
El formulario pide número de tarjeta, caducidad, CVV, nombre y el saldo exacto de la tarjeta.
Después llega el código que el banco te manda por SMS.
El dominio se llama offerup-pay porque el guión original era una estafa de marketplace con la excusa de recibir el pago de un comprador.
Le pegaron el logo de DEV encima y lo reutilizaron (Fuente: dev.to/rudratosh).
Qué comprobé en mi equipo
En Brave, los dos enlaces del correo, abiertos a las 19:09 cayeron en 404.
No hay una sola visita a offerup-pay.top ni a tr.ee en el historial de este equipo.
La pasarela la abrí en el móvil.
Tampoco hay rastro de instalación.
Ningún .exe, .msi, .ps1 ni .zip nuevo en Descargas ni en Temp. Las claves de inicio siguen con Syncthing y Discord. Nada más.
Una página web no instala nada sin que aceptes una descarga. El riesgo empieza cuando alguien teclea la tarjeta o el código del banco.
La plataforma lo reconoce
Ben, el fundador de DEV, publicó hoy que están trabajando en mecanismos para rechazar ese tipo de ataques de forma automática (Fuente: dev.to/ben).
Mientras llega ese filtro cualquiera puede dispararte un correo con la marca real de la plataforma y un enlace que funciona.
¿Qué hacer si te llega?
- No pagues, no verifiques y no escribas la tarjeta, el saldo ni el código del banco.
- Reporta el comentario y bloquea la cuenta aunque ya no exista, el reporte alimenta el filtro.
- Reporta el dominio en abuse.cloudflare.com (aunque se lavan las manos) y en el formulario de phishing de Google Safe Browsing.
- Si tecleaste la tarjeta, llama al banco y bloquea la tarjeta y revisa los cargos.
- Si escribiste en el chat, espera llamadas o SMS de un falso soporte en los próximos días.
- Si el enlace lo abriste en el móvil, mira si aceptaste un perfil de configuración o instalaste una app.