Un botnet de relleno de credenciales en vivo que apunta a cuentas de Twitter/X ha sido encontrado completamente expuesto a internet, sin necesidad de contraseña para acceder a su panel de control, credenciales del servidor de trabajadores o datos de ataques en tiempo real. El sistema expuesto, que opera bajo el nombre “Twitter Checker Master Panel – FULL FIX v2.3”, dejó al descubierto las contraseñas root SSH de los 18 trabajadores 

Una botnet de credential stuffing en vivo que atacaba cuentas de Twitter/X ha sido encontrada completamente expuesta en internet, sin necesidad de contraseña para acceder a su panel de control, credenciales de servidores trabajadores o datos de ataques en tiempo real.

El sistema expuesto, que funcionaba bajo el nombre “Twitter Checker Master Panel – FULL FIX v2.3,”, dejó las contraseñas root SSH de los 18 servidores trabajadores legibles para cualquiera que se conectara a la dirección IP correcta y supiera a qué puerto acceder.

El panel de comando y control de la botnet operaba en 144[.]76[.]57[.]92 en el puerto 5000, alojado en un servidor Windows Server 2019 a través de Hetzner Online GmbH en Falkenstein, Alemania.

El panel estaba construido con Python Flask y Socket.IO para transmitir registros en vivo, pero no tenía ninguna capa de autenticación: ni página de inicio de sesión, ni claves API, ni verificaciones de sesión.

Cualquiera que accediera al servidor podía verlo todo: estadísticas de ataques en tiempo real, detalles de los servidores trabajadores, listas activas de credenciales y un registro en ejecución de cuentas comprometidas. Servicios adicionales como RDP, SMB y WinRM también estaban expuestos en la misma máquina.

Analistas de Breakglass Intelligence descubrieron el panel expuesto durante un escaneo rutinario de infraestructura el 10 de abril de 2026. En una ventana de observación de 12 minutos, los analistas vieron cómo la botnet probaba 722,763 credenciales en tiempo real y confirmaba 18 nuevos compromisos.

Las estadísticas de por vida capturadas durante la sesión mostraban que la operación ya había probado más de 4.8 millones de cuentas, resultando en 138 compromisos confirmados, todos pertenecientes a usuarios que no tenían autenticación de dos factores activada en sus cuentas.

En el momento de la publicación, ni el servidor C2 ni ninguna de las IPs de los servidores trabajadores tenían detecciones en VirusTotal (0/94), ThreatFox, URLhaus o AbuseIPDB.

Los 18 servidores trabajadores estaban dentro de un único bloque de IPs (31[.]58[.]245[.]0/24) propiedad de Komuta Savunma Yuksek Teknoloji Limited Sirketi, un proveedor de hosting en Ankara, Turquía.

Múltiples indicadores —nombres de servidores usando la palabra turca “Sunucu”, un panel construido completamente en turco y contraseñas root que terminaban en “kmt” (abreviatura de Komuta)— apuntan claramente a un operador de habla turca.

El despliegue inicial comenzó el 25 de diciembre de 2025, cuando cinco servidores se pusieron en línea, un momento consistente con actores de amenazas que levantan infraestructura cuando los equipos de seguridad están menos activos y los tiempos de respuesta son más lentos.

Uno de los detalles más reveladores enterrados en los propios datos de la operación es lo que dicen los números sobre la autenticación de dos factores. De 4,862,580 cuentas probadas, el 85.6% devolvió un desafío de 2FA, deteniendo a la botnet por completo.

La operación no tenía forma de eludir el 2FA: simplemente marcaba esas cuentas y seguía adelante, buscando exclusivamente dentro del 14.1% que dependía solo de contraseñas. Esta cifra confirma directamente que activar el 2FA elimina a la mayoría de los usuarios de este tipo de ataques.

La API expuesta: una botnet que cualquiera podía controlar

El elemento más grave de este caso no fue solo que la botnet existiera, sino que cualquiera que la encontrara podía controlarla por completo. El panel Flask exponía un conjunto completo de endpoints REST API sin autenticación en ninguno de ellos.

Una simple solicitud GET a /api/servers devolvía la dirección IP de cada trabajador, la contraseña root SSH, el estado de instalación y métricas de salud en texto plano.

El operador construyó el panel sin ningún control de acceso, confiando por completo en la suposición de que nadie descubriría el puerto 5000 en esa dirección IP.

Los endpoints accesibles iban mucho más allá de leer credenciales. Cualquiera con acceso a la red podía iniciar o detener toda la botnet, subir sus propias listas de credenciales, descargar los resultados, enviar nuevas configuraciones a las 18 máquinas e incluso reinstalar el software de verificación.

El endpoint /api/bulk/download significaba que un tercero podía extraer silenciosamente todas las cuentas comprometidas de Twitter/X de la operación sin que el operador original lo supiera.

Los analistas de Breakglass Intelligence recomiendan que Twitter/X bloquee de inmediato las 19 direcciones IP identificadas y obligue a restablecer las 138 cuentas comprometidas.

Tanto Hetzner como Komuta Savunma deberían procesar urgentemente los informes de abuso para su respectiva infraestructura.

Para los usuarios individuales, los hallazgos son claros: activar la autenticación de dos factores protegió al 85.6% de todas las cuentas probadas en esta operación, y evitar la reutilización de contraseñas en diferentes servicios elimina el riesgo restante.