Agradecimientos: un agradecimiento especial a Rich Mozeleski por sus aportes a esta investigación y a este artículo.
Huntress ha observado un aumento notable en los ataques de phishing mediante código de dispositivo en 2026. A principios de este año, informamos sobre una oleada masiva de ataques de phishing mediante código de dispositivo que se originaron en Railway, una plataforma como servicio creada para vibe coding. A partir de abril, también vimos ataques desde direcciones IP vinculadas a un revendedor de servidores privados virtuales (VPS) llamado BL Networks.
Huntress comenzó a detectar actividad de autenticación sospechosa de Microsoft 365 vinculada a BL Networks el 13 de abril de 2026, y esta actividad continúa hasta el momento de esta publicación. A principios de abril, vimos que todos los incidentes se vinculaban a una sola dirección IP infractora (216.203.20[.]95).
En mayo, la infraestructura utilizada se expandió de una IP específica a varias dentro de distintas subredes: vimos ataques de phishing mediante código de dispositivo originados en BL Networks que abarcaban varias IP, incluidas 193.149.176[.]151, 193.149.176[.]238 y 45.61.136[.]129.
Hasta julio, la actividad ha comenzado a disminuir, pero BL Networks sigue en uso: entre el 3 y el 27 de julio, vimos 26 incidentes de severidad crítica vinculados a BL Networks que abarcaron 23 identidades.
Esto se asemeja a la oleada de ataques de phishing mediante código de dispositivo que observamos a principios de este año, vinculada a Railway, que atribuimos a la plataforma de modelo de phishing como servicio (PhaaS) EvilTokens. Si bien esa actividad ya se ha reducido, este segundo aumento de actividad vinculado a BL Networks más adelante en el año demuestra que la historia no terminó con la primera cobertura sobre la infraestructura de phishing mediante código de dispositivo, y tampoco terminará aquí.
¿Qué es BL Networks?
BL Networks (también conocida como BitLaunch o BLNWX) está activa desde al menos 2017, operando bajo el ASN AS399629, según Bushido Token Threat Intel. Los revendedores de VPS ofrecen servidores privados virtuales con Linux o Windows para su compra. Un VPS puede usarse para casos de hospedaje legítimos (como pequeñas empresas de hospedaje que atienden negocios locales), pero los clientes también pueden usarlo para alojar actividad ilegal, como campañas de spam, botnets, sitios de phishing o distribución de malware.
Detectamos por primera vez actividad de autenticación maliciosa desde BL Networks en abril. Entre el 13 y el 30 de abril, Huntress identificó 533 eventos vinculados a BL Networks específicamente desde 216.203.20[.]95, con 113 inicios de sesión exitosos originados en BL Networks en una ventana de 48 horas entre el 20 y el 21 de abril.
El aumento de phishing mediante código de dispositivo vinculado a EvilTokens que vimos a principios de este año se originó a través de la infraestructura completamente legítima de Railway. BL Networks es un poco diferente porque también ofrece hospedaje estándar. Sin embargo, los investigadores de ciberseguridad han señalado con frecuencia sus direcciones IP porque los actores maliciosos también han usado sus servidores para campañas maliciosas.
Por qué esto nos resulta familiar
BL Networks plantea el mismo problema central para los defensores que vimos en el kit anterior de EvilTokens: los atacantes abusan de infraestructura que parece legítima para reproducir u operar tokens robados de Microsoft 365 sin activar los controles que muchos equipos esperan que los protejan.
El phishing mediante código de dispositivo ya es difícil de detectar porque no se parece al robo de credenciales tradicional. Se envía al usuario a un flujo de inicio de sesión legítimo de Microsoft. La MFA puede seguir ocurriendo. No es necesario robar directamente ninguna contraseña. Desde la perspectiva del defensor, lo que suele destacar no es la página de phishing en sí, sino el contexto que la rodea: de dónde proviene el inicio de sesión, qué aplicación o flujo se usó, si la combinación de identidad e infraestructura tiene sentido y si la actividad coincide con el comportamiento normal del usuario.
Por eso infraestructuras como BL Networks merecen un escrutinio especial. Si la autenticación tiene éxito y la infraestructura no parece automáticamente hostil para los controles posteriores, los atacantes pueden seguir obteniendo valor del flujo incluso después de que la atención pública se desplace hacia otro tema.
La campaña de BL Networks nos revela tres cosas
Primero, los actores de amenazas no han dejado de perfeccionar el phishing mediante código de dispositivo. La existencia de informes y detecciones anteriores no ha hecho que esta clase de actividad desaparezca. De hecho, la aparición de direcciones IP de BL Networks sugiere que el ecosistema se está adaptando y reutilizando lo que funciona.
Segundo, la reputación de la infraestructura tiene demasiado peso en muchos esquemas de defensa. Cuando un inicio de sesión proviene de un proveedor o sistema autónomo que generalmente goza de confianza entre los controles comerciales, los atacantes obtienen una ventana para operar. Esa ventana puede ser corta, pero en operaciones de abuso de tokens, a menudo corta es suficiente.
Tercero, los defensores deben dejar de pensar en estas campañas como nombres de marca aislados. Ya sea que una campaña se discuta internamente como Railway, EvilTokens o potencialmente vinculada a Kali365, la lección más duradera es que ahora se trata de un patrón de ataque: servicios en la nube legítimos, páginas de autenticación legítimas de Microsoft, infraestructura señuelo desechable y técnicas de post-compromiso centradas en tokens.
Los defensores deben prestar atención al comportamiento, no solo al nombre de la infraestructura
Si hay un aspecto positivo en todo esto, es que este tipo de actividad genera patrones. Los equipos de Huntress pudieron identificar a BL Networks como lo suficientemente sospechosa para considerar su clasificación como infraestructura adversaria, y el equipo afirmó explícitamente que la cantidad desproporcionada de inicios de sesión mediante código de dispositivo fue suficiente para tomar esa decisión. Ese es el tipo de umbral que los defensores también deberían considerar internamente.
La pregunta no debería ser "¿Hemos visto exactamente este proveedor en un informe de amenazas antes?". En su lugar, pregúntate lo siguiente:
¿Estamos viendo inicios de sesión exitosos repetidos desde infraestructura que no tiene ningún sentido comercial para el usuario?
¿Esos inicios de sesión se agrupan en torno a flujos de código de dispositivo?
¿Aparecen en varias organizaciones, usuarios o identidades de una manera que parece operativa y no accidental?
¿Estamos viendo los mismos comportamientos circundantes que aparecieron en campañas anteriores de reproducción de tokens?
Si la respuesta es sí, esperar una atribución impecable puede convertirse en un lujo. Cuando la evidencia es suficientemente sólida, los defensores deben inclinarse hacia la contención y la generación de señales.
Qué puedes hacer ahora
Las organizaciones preocupadas por esta tendencia deben enfocarse en defensas prácticas a nivel de identidad:
Revisa el uso de la autenticación mediante código de dispositivo en tu entorno y restríngela donde no sea necesaria.
Monitorea los inicios de sesión exitosos vinculados a infraestructura inusual o recién sospechosa, en especial cuando se combinan con actividad de código de dispositivo.
Investiga los grupos de eventos
UserLoggedInexitosos provenientes del mismo sistema autónomo o proveedor de hosting, incluso cuando esos inicios de sesión no parezcan "de alto riesgo" a primera vista.Revoca sesiones y tokens de autenticación rápidamente cuando se identifique un abuso sospechoso de código de dispositivo.
Da por hecho que MFA por sí solo no basta cuando el atacante abusa de un flujo legítimo de Microsoft en lugar de robar una contraseña.
La lección más importante aquí no es que un proveedor sea malo para siempre. Los adversarios han aprendido a convertir plataformas confiables en multiplicadores de fuerza. Pueden rotar señuelos, hosting, cadenas de redirección y flujos posteriores al compromiso más rápido de lo que muchos equipos de seguridad pueden actualizar sus supuestos.
Reflexiones finales
Más allá de bloquear enlaces obviamente maliciosos o detectar páginas de inicio de sesión falsas, los defensores pueden frustrar ataques de phishing al reconocer cuando servicios reales, flujos de autenticación reales e infraestructura en la nube real se combinan en una cadena de ataque que lleva al compromiso.
Y eso, más que el nombre de cualquier campaña en particular, es la razón por la que vale la pena vigilar a BL Networks.
¿Quieres ver el panorama completo? Descarga el informe completo para un desglose más detallado de los manuales de Railway y BL Networks, cómo se desarrollan estos ataques de phishing mediante código de dispositivo y qué deben hacer los defensores a continuación.
