<![CDATA[GETOVERX FORUM Community Support - Botnets / Bots]]> https://forum.getoverx.com/ Fri, 17 Apr 2026 09:59:30 +0000 MyBB <![CDATA[CryptBot – Infostealer – 2019]]> https://forum.getoverx.com/showthread.php?tid=121 Fri, 05 Dec 2025 17:03:44 +0000 mrwebfeeder]]> https://forum.getoverx.com/showthread.php?tid=121 Nombre:
CryptBot (también visto como Cryptbot Stealer)
Categoría:
Infostealer (ladrón de información, credenciales y wallets)
Fecha de descubrimiento:
Finales de 2019
Comportamiento (lo que hace y archivos que infecta):
  • Suele llegar al equipo a través de instaladores falsos de software “crackeado” (Activators, KMS falsos, versiones piratas de herramientas de edición, etc.) o descargas desde sitios de dudosa reputación.
  • Roba credenciales de navegadores (Chrome, Edge, Firefox, Brave, Opera), cookies, historial y formularios.
  • Extrae información de wallets de criptomonedas y extensiones de navegador relacionadas con cripto.
  • Puede recopilar información del sistema (versión de Windows, procesos, ubicación aproximada) y enviarla al servidor de mando y control (C2).
  • No cifra archivos como un ransomware, pero sí puede permitir posteriormente la instalación de otros malware (ransomware, RATs, mineros, etc.).
Persistencia:
  • Copia el ejecutable malicioso dentro de carpetas de usuario (por ejemplo en
    Code:
    %AppData%
    ,
    Code:
    %LocalAppData%
    o subcarpetas engañosas con nombres de software legítimo).
  • Crea claves de registro en
    Code:
    HKCU\Software\Microsoft\Windows\CurrentVersion\Run
    o equivalentes para ejecutarse al inicio.
  • En algunas variantes utiliza tareas programadas para relanzarse periódicamente o tras un fallo del sistema.
Hash real de referencia (SHA-256):
Ejemplo de muestra pública (CryptBot):

Code:
54f791796231f7899d753f0ba44e7387bf7748dc7a28adbd28f2067c9ab88605
Mitigación con GetOverX Shield v3.0.2.0 o superior:
  • Antivirus:
    • Ejecutar un análisis completo del sistema, priorizando las carpetas de descargas (
      Code:
      Downloads
      ), escritorio y rutas donde el usuario guarde cracks/activadores.
    • Habilitar la detección agresiva de PUA/PUS (Potentially Unwanted Applications) dentro de GetOverX Shield para detectar instaladores “truchos”.
    • Poner en cuarentena cualquier binario sospechoso que se ejecute desde
      Code:
      %Temp%
      ,
      Code:
      %AppData%
      o rutas de crack poco habituales.
  • Firewall:
    • Bloquear conexiones salientes a dominios/IP desconocidos generados por procesos ubicados en rutas de usuario (no en
      Code:
      C:\Program Files
      ni
      Code:
      C:\Windows
      ).
    • Crear una regla para bloquear conexiones HTTP/HTTPS de ejecutables ubicados en carpetas de descarga/cracks, salvo que hayan sido verificados.
    • En caso de incidente confirmado, aislar temporalmente el host (bloquear todo tráfico excepto hacia los servidores de actualización de GetOverX Shield).
  • HIPS/EDR:
    • Configurar reglas para alertar si un proceso no firmado intenta leer en masa bases de datos de navegadores (archivos
      Code:
      Login Data
      ,
      Code:
      Cookies
      ,
      Code:
      Web Data
      , etc.).
    • Habilitar respuesta automática: matar procesos que intenten enumerar wallets o extensiones cripto fuera de navegadores legítimos.
    • Registrar y, si es posible, bloquear la creación de nuevos valores en
      Code:
      Run
      /
      Code:
      RunOnce
      por procesos no firmados.
  • Sandbox:
    • Probar todos los cracks, activadores y “setup modificados” dentro del Sandbox de GetOverX Shield antes de ejecutarlos en el sistema real.
    • Monitorizar en la Sandbox si el instalador intenta leer bases de datos de navegador o carpetas de wallets inmediatamente después de ejecutarse.
  • Medidas posteriores al incidente:
    • Cambiar todas las contraseñas de servicios críticos (correo, banca, redes sociales, panel de hosting, VPN, etc.) desde un equipo limpio.
    • Revocar sesiones activas en servicios en la nube (Google, Microsoft, etc.).
    • Revisar actividad en wallets de criptomonedas y, si es posible, mover fondos a nuevas direcciones con claves regeneradas.
    • Verificar que no se han desplegado otros malware secundarios (RAT, ransomware, mineros).

]]> Nombre:
CryptBot (también visto como Cryptbot Stealer)
Categoría:
Infostealer (ladrón de información, credenciales y wallets)
Fecha de descubrimiento:
Finales de 2019
Comportamiento (lo que hace y archivos que infecta):
  • Suele llegar al equipo a través de instaladores falsos de software “crackeado” (Activators, KMS falsos, versiones piratas de herramientas de edición, etc.) o descargas desde sitios de dudosa reputación.
  • Roba credenciales de navegadores (Chrome, Edge, Firefox, Brave, Opera), cookies, historial y formularios.
  • Extrae información de wallets de criptomonedas y extensiones de navegador relacionadas con cripto.
  • Puede recopilar información del sistema (versión de Windows, procesos, ubicación aproximada) y enviarla al servidor de mando y control (C2).
  • No cifra archivos como un ransomware, pero sí puede permitir posteriormente la instalación de otros malware (ransomware, RATs, mineros, etc.).
Persistencia:
  • Copia el ejecutable malicioso dentro de carpetas de usuario (por ejemplo en
    Code:
    %AppData%
    ,
    Code:
    %LocalAppData%
    o subcarpetas engañosas con nombres de software legítimo).
  • Crea claves de registro en
    Code:
    HKCU\Software\Microsoft\Windows\CurrentVersion\Run
    o equivalentes para ejecutarse al inicio.
  • En algunas variantes utiliza tareas programadas para relanzarse periódicamente o tras un fallo del sistema.
Hash real de referencia (SHA-256):
Ejemplo de muestra pública (CryptBot):

Code:
54f791796231f7899d753f0ba44e7387bf7748dc7a28adbd28f2067c9ab88605
Mitigación con GetOverX Shield v3.0.2.0 o superior:
  • Antivirus:
    • Ejecutar un análisis completo del sistema, priorizando las carpetas de descargas (
      Code:
      Downloads
      ), escritorio y rutas donde el usuario guarde cracks/activadores.
    • Habilitar la detección agresiva de PUA/PUS (Potentially Unwanted Applications) dentro de GetOverX Shield para detectar instaladores “truchos”.
    • Poner en cuarentena cualquier binario sospechoso que se ejecute desde
      Code:
      %Temp%
      ,
      Code:
      %AppData%
      o rutas de crack poco habituales.
  • Firewall:
    • Bloquear conexiones salientes a dominios/IP desconocidos generados por procesos ubicados en rutas de usuario (no en
      Code:
      C:\Program Files
      ni
      Code:
      C:\Windows
      ).
    • Crear una regla para bloquear conexiones HTTP/HTTPS de ejecutables ubicados en carpetas de descarga/cracks, salvo que hayan sido verificados.
    • En caso de incidente confirmado, aislar temporalmente el host (bloquear todo tráfico excepto hacia los servidores de actualización de GetOverX Shield).
  • HIPS/EDR:
    • Configurar reglas para alertar si un proceso no firmado intenta leer en masa bases de datos de navegadores (archivos
      Code:
      Login Data
      ,
      Code:
      Cookies
      ,
      Code:
      Web Data
      , etc.).
    • Habilitar respuesta automática: matar procesos que intenten enumerar wallets o extensiones cripto fuera de navegadores legítimos.
    • Registrar y, si es posible, bloquear la creación de nuevos valores en
      Code:
      Run
      /
      Code:
      RunOnce
      por procesos no firmados.
  • Sandbox:
    • Probar todos los cracks, activadores y “setup modificados” dentro del Sandbox de GetOverX Shield antes de ejecutarlos en el sistema real.
    • Monitorizar en la Sandbox si el instalador intenta leer bases de datos de navegador o carpetas de wallets inmediatamente después de ejecutarse.
  • Medidas posteriores al incidente:
    • Cambiar todas las contraseñas de servicios críticos (correo, banca, redes sociales, panel de hosting, VPN, etc.) desde un equipo limpio.
    • Revocar sesiones activas en servicios en la nube (Google, Microsoft, etc.).
    • Revisar actividad en wallets de criptomonedas y, si es posible, mover fondos a nuevas direcciones con claves regeneradas.
    • Verificar que no se han desplegado otros malware secundarios (RAT, ransomware, mineros).

]]> <![CDATA[DNSChangerGo (2024)]]> https://forum.getoverx.com/showthread.php?tid=72 Sat, 29 Nov 2025 16:19:05 +0000 mrwebfeeder]]> https://forum.getoverx.com/showthread.php?tid=72 Nombre: DNSChangerGo

Categoría: DNS hijacker / Malware para routers

Fecha de descubrimiento: 2024

Comportamiento (lo que hace y qué afecta):
- Malware enfocado en comprometer routers domésticos y de pequeña empresa, con el objetivo de secuestrar el tráfico DNS.
- Changes router DNS settings via exploits:
- Intenta conectarse a la interfaz de administración del router (HTTP/HTTPS/Telnet/otras) usando:
- Credenciales por defecto.
- Listas de contraseñas comunes.
- Explotación de vulnerabilidades conocidas en firmware o paneles web.
- Una vez que consigue acceso, modifica la configuración DNS del router para apuntar a servidores DNS controlados por el atacante.
- Impacto principal:
- Todo dispositivo que obtenga su configuración (DNS) vía DHCP del router:
- Resuelve dominios a través del DNS malicioso.
- Puede ser redirigido a:
- Páginas de phishing (banca, correo, redes sociales).
- Páginas de descarga de malware.
- Publicidad/banners fraudulentos.
- No cifra archivos en los endpoints ni “infecta” el sistema como tal: el vector es el secuestró de la resolución DNS a nivel de red.
- En algunos escenarios, el mismo agente en el endpoint puede:
- Comprobar y reportar cambios anómalos en la configuración DNS local (servidores extraños, cambios repetidos, etc.).
- Intentar moverse lateralmente a otros dispositivos de red mal configurados.

Persistencia (comportamiento típico):
- Mientras el router mantenga:
- Las credenciales sin cambiar.
- El firmware vulnerable sin parchear.
- La configuración DNS maliciosa activa.
- Los equipos seguirán usando los servidores DNS del atacante incluso si están “limpios” a nivel de endpoint.
- En algunos casos, los atacantes configuran:
- DNS primario malicioso + DNS secundario legítimo para mezclar tráfico normal con redirecciones selectivas.
- Reglas de administración remota en el router para poder volver a entrar incluso si el usuario cambia algunos ajustes.

Hash real de referencia (SHA-256):
Muestra pública asociada a DNSChangerGo:
Code:
1b1e96d5fd215768c61a2b7f2e4e6e99794bbeae3b7f5571f18fafdb07bcd837

Mitigación con GetOverX Shield v3.0.2.0 o superior:
  • Firewall block router admin ports:
    - Usar el firewall de GetOverX Shield para proteger el acceso al panel del router:
    - Bloquear o restringir el acceso a los puertos de administración del router (HTTP/HTTPS/Telnet/SSH) desde Internet.
    - Permitir sólo:
    - Acceso desde la red interna.
    - Preferiblemente, desde IPs/hosts de administración específicos.
    - En redes corporativas pequeñas:
    - Crear reglas que impidan que equipos de usuario (segmento “user”) lleguen directamente al puerto de administración del router; sólo un equipo de administración debería tener ese acceso.
    - Registrar y alertar:
    - Intentos de conexión repetidos a la IP de gestión del router desde hosts no autorizados.

  • EDR detect DNS configuration hijacks:
    - Configurar el módulo EDR para vigilar:
    - Cambios en la configuración DNS de los endpoints:
    - Servidores DNS inesperados (IP públicas poco comunes o rangos desconocidos).
    - Cambios frecuentes en los DNS sin intervención del administrador.
    - Modificaciones en:
    - Parámetros de red obtenidos por DHCP.
    - Ficheros de configuración local de DNS (hosts, resolvers, etc. cuando aplique).
    - Comportamiento recomendado:
    - Si se detecta que múltiples equipos reciben el mismo DNS sospechoso:
    - Marcar como posible indica​dor de compromiso del router.
    - Generar una alerta de alto nivel para revisar la configuración del equipo de borde (router/modem).
    - Registrar detalle (host, DNS previo, DNS nuevo, hora) en los logs unificados.

  • Alert on unauthorized DHCP changes:
    - Integrar reglas de monitoreo para:
    - Cambios en la configuración de DHCP (servidores DNS, gateway, dominios de búsqueda) que no coincidan con las políticas definidas.
    - Acciones:
    - Cuando un endpoint reciba parámetros DHCP con DNS fuera de la lista permitida:
    - Generar alerta inmediata.
    - Opcionalmente, forzar:
    - Reemplazo automático por una configuración DNS segura predefinida.
    - Bloqueo de navegación hasta que se confirme o corrija el incidente de red.
    - Recomendado:
    - Mantener un listado de DNS autorizados (propios, de la organización o de proveedores confiables).
    - Alertar cuando aparezcan DNS nuevos que no estén documentados.

  • Medidas adicionales recomendadas:
    - Cambiar credenciales por defecto del router y desactivar la administración remota desde Internet.
    - Mantener el firmware del router actualizado con los últimos parches de seguridad.
    - Revisar periódicamente:
    - Configuración DNS del router.
    - Listas de reenvío (forwarders) en servidores DNS internos si existen.
    - En caso de detectar compromiso:
    - Restaurar el router a valores de fábrica.
    - Reconfigurar manualmente (sin cargar respaldos no confiables).
    - Volver a establecer DNS legítimos y credenciales fuertes.
]]> Nombre: DNSChangerGo

Categoría: DNS hijacker / Malware para routers

Fecha de descubrimiento: 2024

Comportamiento (lo que hace y qué afecta):
- Malware enfocado en comprometer routers domésticos y de pequeña empresa, con el objetivo de secuestrar el tráfico DNS.
- Changes router DNS settings via exploits:
- Intenta conectarse a la interfaz de administración del router (HTTP/HTTPS/Telnet/otras) usando:
- Credenciales por defecto.
- Listas de contraseñas comunes.
- Explotación de vulnerabilidades conocidas en firmware o paneles web.
- Una vez que consigue acceso, modifica la configuración DNS del router para apuntar a servidores DNS controlados por el atacante.
- Impacto principal:
- Todo dispositivo que obtenga su configuración (DNS) vía DHCP del router:
- Resuelve dominios a través del DNS malicioso.
- Puede ser redirigido a:
- Páginas de phishing (banca, correo, redes sociales).
- Páginas de descarga de malware.
- Publicidad/banners fraudulentos.
- No cifra archivos en los endpoints ni “infecta” el sistema como tal: el vector es el secuestró de la resolución DNS a nivel de red.
- En algunos escenarios, el mismo agente en el endpoint puede:
- Comprobar y reportar cambios anómalos en la configuración DNS local (servidores extraños, cambios repetidos, etc.).
- Intentar moverse lateralmente a otros dispositivos de red mal configurados.

Persistencia (comportamiento típico):
- Mientras el router mantenga:
- Las credenciales sin cambiar.
- El firmware vulnerable sin parchear.
- La configuración DNS maliciosa activa.
- Los equipos seguirán usando los servidores DNS del atacante incluso si están “limpios” a nivel de endpoint.
- En algunos casos, los atacantes configuran:
- DNS primario malicioso + DNS secundario legítimo para mezclar tráfico normal con redirecciones selectivas.
- Reglas de administración remota en el router para poder volver a entrar incluso si el usuario cambia algunos ajustes.

Hash real de referencia (SHA-256):
Muestra pública asociada a DNSChangerGo:
Code:
1b1e96d5fd215768c61a2b7f2e4e6e99794bbeae3b7f5571f18fafdb07bcd837

Mitigación con GetOverX Shield v3.0.2.0 o superior:
  • Firewall block router admin ports:
    - Usar el firewall de GetOverX Shield para proteger el acceso al panel del router:
    - Bloquear o restringir el acceso a los puertos de administración del router (HTTP/HTTPS/Telnet/SSH) desde Internet.
    - Permitir sólo:
    - Acceso desde la red interna.
    - Preferiblemente, desde IPs/hosts de administración específicos.
    - En redes corporativas pequeñas:
    - Crear reglas que impidan que equipos de usuario (segmento “user”) lleguen directamente al puerto de administración del router; sólo un equipo de administración debería tener ese acceso.
    - Registrar y alertar:
    - Intentos de conexión repetidos a la IP de gestión del router desde hosts no autorizados.

  • EDR detect DNS configuration hijacks:
    - Configurar el módulo EDR para vigilar:
    - Cambios en la configuración DNS de los endpoints:
    - Servidores DNS inesperados (IP públicas poco comunes o rangos desconocidos).
    - Cambios frecuentes en los DNS sin intervención del administrador.
    - Modificaciones en:
    - Parámetros de red obtenidos por DHCP.
    - Ficheros de configuración local de DNS (hosts, resolvers, etc. cuando aplique).
    - Comportamiento recomendado:
    - Si se detecta que múltiples equipos reciben el mismo DNS sospechoso:
    - Marcar como posible indica​dor de compromiso del router.
    - Generar una alerta de alto nivel para revisar la configuración del equipo de borde (router/modem).
    - Registrar detalle (host, DNS previo, DNS nuevo, hora) en los logs unificados.

  • Alert on unauthorized DHCP changes:
    - Integrar reglas de monitoreo para:
    - Cambios en la configuración de DHCP (servidores DNS, gateway, dominios de búsqueda) que no coincidan con las políticas definidas.
    - Acciones:
    - Cuando un endpoint reciba parámetros DHCP con DNS fuera de la lista permitida:
    - Generar alerta inmediata.
    - Opcionalmente, forzar:
    - Reemplazo automático por una configuración DNS segura predefinida.
    - Bloqueo de navegación hasta que se confirme o corrija el incidente de red.
    - Recomendado:
    - Mantener un listado de DNS autorizados (propios, de la organización o de proveedores confiables).
    - Alertar cuando aparezcan DNS nuevos que no estén documentados.

  • Medidas adicionales recomendadas:
    - Cambiar credenciales por defecto del router y desactivar la administración remota desde Internet.
    - Mantener el firmware del router actualizado con los últimos parches de seguridad.
    - Revisar periódicamente:
    - Configuración DNS del router.
    - Listas de reenvío (forwarders) en servidores DNS internos si existen.
    - En caso de detectar compromiso:
    - Restaurar el router a valores de fábrica.
    - Reconfigurar manualmente (sin cargar respaldos no confiables).
    - Volver a establecer DNS legítimos y credenciales fuertes.
]]> <![CDATA[Botnet – Moobot (2020–2024)]]> https://forum.getoverx.com/showthread.php?tid=71 Sat, 29 Nov 2025 16:18:41 +0000 mrwebfeeder]]> https://forum.getoverx.com/showthread.php?tid=71 Nombre: Moobot

Categoría: Botnet / IoT malware (variante de Mirai)

Periodo de actividad: 2020–2024

Comportamiento (lo que hace y qué infecta):
- Mirai variant infecting IoT via exploits:
- Basado en la familia Mirai, enfocado en:
- Dispositivos IoT (routers SOHO, cámaras IP, DVR/NVR, CPEs, etc.).
- Equipos con credenciales por defecto o vulnerabilidades conocidas.
- Escanea Internet y redes expuestas buscando:
- Puertos típicos de administración (Telnet, HTTP/HTTPS, SSH).
- Firmwares y paneles web con exploits publicados.
- Una vez compromete un dispositivo:
- Descarga binarios cross-compiled para distintas arquitecturas (ARM, MIPS, etc.).
- Se registra en un servidor de mando y control (C2).
- El dispositivo pasa a formar parte de una botnet.
- Uso de la botnet:
- Lanzar ataques de denegación de servicio distribuido (DDoS) contra objetivos definidos por los operadores.
- Posible participación en campañas de escaneo/ataques adicionales contra otros IoT.

Persistencia:
- Permanece activo mientras el dispositivo:
- No se reinicia o resetea a valores de fábrica (en algunas variantes).
- Sigue siendo vulnerable (siguen sin cambiarse credenciales por defecto y sin actualizar firmware).
- En algunos casos:
- Puede modificar scripts de arranque o configuraciones del sistema embebido para relanzar el binario al reiniciar, si el dispositivo lo permite.

Hash real de referencia (SHA-256):
Muestra pública asociada a Moobot:
Code:
bc36bbfb96c3edcdd2951fd98a02b14ec681b8a2760a48565b2e2afadc177a52

Mitigación con GetOverX Shield v3.0.2.0 o superior:
  • Firewall block known IoT exploits:
    - Usar el firewall perimetral y/o el firewall de GetOverX Shield (en el host que hace de gateway/monitor) para:
    - Bloquear tráfico entrante hacia puertos de administración de IoT expuestos (Telnet, HTTP/HTTPS de administración, SSH) desde Internet.
    - Restringir que sólo segmentos de administración autorizados puedan acceder a interfaces de gestión de routers, cámaras, DVR/NVR, etc.
    - Aplicar reglas específicas:
    - Firmas/IDS o listas de bloqueo para patrones conocidos de exploits Mirai/Moobot.
    - Filtrado de peticiones HTTP/Telnet típicas de escaneo de credenciales por defecto.

  • EDR detects anomalous network floods:
    - Desde endpoints o servidores que monitoricen la red con GetOverX Shield:
    - Detectar picos anómalos de tráfico saliente UDP/TCP provenientes de:
    - Rango de IPs dedicado a IoT.
    - Segmentos donde residen routers, cámaras, DVR.
    - Correlacionar:
    - Incrementos súbitos de tráfico hacia un mismo destino o rango (DDoS).
    - Dispositivos que, normalmente, generan poco tráfico pero de repente saturan el ancho de banda.
    - Acciones recomendadas:
    - Marcar los dispositivos implicados como sospechosos de pertenecer a botnet.
    - Aislar o limitar la tasa de tráfico de esos hosts a nivel de firewall hasta que se revisen.

  • Quarantine cross-compiled binaries:
    - En los sistemas donde se descarguen o analicen imágenes/firmwares o herramientas para IoT:
    - Configurar el AV de GetOverX Shield para:
    - Identificar y poner en cuarentena binarios cross-compiled sospechosos (ARM/MIPS/etc.) asociados a Moobot/Mirai-like.
    - En entornos de análisis:
    - Usar Sandbox para ejecutar:
    - Binarios multi-arquitectura sospechosos.
    - Scripts que descargan ejecutables para distintos tipos de CPU IoT.
    - Bloquear la distribución interna si se observa comportamiento de escaneo y DDoS.

  • Medidas adicionales recomendadas:
    - Para todos los dispositivos IoT:
    - Cambiar inmediatamente credenciales por defecto.
    - Desactivar servicios de administración remota desde Internet.
    - Mantener firmware actualizado a la última versión disponible.
    - Segmentar la red:
    - Colocar IoT en VLANs o subredes aisladas del resto de la infraestructura.
    - Limitar severamente las rutas desde IoT hacia Internet y hacia otros segmentos internos.
    - Ante sospecha de compromiso:
    - Reiniciar y restaurar a valores de fábrica los dispositivos afectados.
    - Reconfigurar manualmente con:
    - Credenciales robustas.
    - Límites de acceso y actualizaciones de firmware.
]]> Nombre: Moobot

Categoría: Botnet / IoT malware (variante de Mirai)

Periodo de actividad: 2020–2024

Comportamiento (lo que hace y qué infecta):
- Mirai variant infecting IoT via exploits:
- Basado en la familia Mirai, enfocado en:
- Dispositivos IoT (routers SOHO, cámaras IP, DVR/NVR, CPEs, etc.).
- Equipos con credenciales por defecto o vulnerabilidades conocidas.
- Escanea Internet y redes expuestas buscando:
- Puertos típicos de administración (Telnet, HTTP/HTTPS, SSH).
- Firmwares y paneles web con exploits publicados.
- Una vez compromete un dispositivo:
- Descarga binarios cross-compiled para distintas arquitecturas (ARM, MIPS, etc.).
- Se registra en un servidor de mando y control (C2).
- El dispositivo pasa a formar parte de una botnet.
- Uso de la botnet:
- Lanzar ataques de denegación de servicio distribuido (DDoS) contra objetivos definidos por los operadores.
- Posible participación en campañas de escaneo/ataques adicionales contra otros IoT.

Persistencia:
- Permanece activo mientras el dispositivo:
- No se reinicia o resetea a valores de fábrica (en algunas variantes).
- Sigue siendo vulnerable (siguen sin cambiarse credenciales por defecto y sin actualizar firmware).
- En algunos casos:
- Puede modificar scripts de arranque o configuraciones del sistema embebido para relanzar el binario al reiniciar, si el dispositivo lo permite.

Hash real de referencia (SHA-256):
Muestra pública asociada a Moobot:
Code:
bc36bbfb96c3edcdd2951fd98a02b14ec681b8a2760a48565b2e2afadc177a52

Mitigación con GetOverX Shield v3.0.2.0 o superior:
  • Firewall block known IoT exploits:
    - Usar el firewall perimetral y/o el firewall de GetOverX Shield (en el host que hace de gateway/monitor) para:
    - Bloquear tráfico entrante hacia puertos de administración de IoT expuestos (Telnet, HTTP/HTTPS de administración, SSH) desde Internet.
    - Restringir que sólo segmentos de administración autorizados puedan acceder a interfaces de gestión de routers, cámaras, DVR/NVR, etc.
    - Aplicar reglas específicas:
    - Firmas/IDS o listas de bloqueo para patrones conocidos de exploits Mirai/Moobot.
    - Filtrado de peticiones HTTP/Telnet típicas de escaneo de credenciales por defecto.

  • EDR detects anomalous network floods:
    - Desde endpoints o servidores que monitoricen la red con GetOverX Shield:
    - Detectar picos anómalos de tráfico saliente UDP/TCP provenientes de:
    - Rango de IPs dedicado a IoT.
    - Segmentos donde residen routers, cámaras, DVR.
    - Correlacionar:
    - Incrementos súbitos de tráfico hacia un mismo destino o rango (DDoS).
    - Dispositivos que, normalmente, generan poco tráfico pero de repente saturan el ancho de banda.
    - Acciones recomendadas:
    - Marcar los dispositivos implicados como sospechosos de pertenecer a botnet.
    - Aislar o limitar la tasa de tráfico de esos hosts a nivel de firewall hasta que se revisen.

  • Quarantine cross-compiled binaries:
    - En los sistemas donde se descarguen o analicen imágenes/firmwares o herramientas para IoT:
    - Configurar el AV de GetOverX Shield para:
    - Identificar y poner en cuarentena binarios cross-compiled sospechosos (ARM/MIPS/etc.) asociados a Moobot/Mirai-like.
    - En entornos de análisis:
    - Usar Sandbox para ejecutar:
    - Binarios multi-arquitectura sospechosos.
    - Scripts que descargan ejecutables para distintos tipos de CPU IoT.
    - Bloquear la distribución interna si se observa comportamiento de escaneo y DDoS.

  • Medidas adicionales recomendadas:
    - Para todos los dispositivos IoT:
    - Cambiar inmediatamente credenciales por defecto.
    - Desactivar servicios de administración remota desde Internet.
    - Mantener firmware actualizado a la última versión disponible.
    - Segmentar la red:
    - Colocar IoT en VLANs o subredes aisladas del resto de la infraestructura.
    - Limitar severamente las rutas desde IoT hacia Internet y hacia otros segmentos internos.
    - Ante sospecha de compromiso:
    - Reiniciar y restaurar a valores de fábrica los dispositivos afectados.
    - Reconfigurar manualmente con:
    - Credenciales robustas.
    - Límites de acceso y actualizaciones de firmware.
]]> <![CDATA[Goldoon (2022)]]> https://forum.getoverx.com/showthread.php?tid=70 Sat, 29 Nov 2025 16:18:17 +0000 mrwebfeeder]]> https://forum.getoverx.com/showthread.php?tid=70 Nombre: Goldoon

Categoría: Botnet / IoT malware (tipo Mirai)

Fecha de descubrimiento: 2022

Comportamiento (lo que hace y qué infecta):
  • SSH brute force:
    - Escanea rangos de IP en busca de servicios SSH expuestos.
    - Intenta acceso con credenciales débiles o por defecto mediante ataques de fuerza bruta.
    - Una vez que logra autenticarse, descarga y ejecuta binarios ELF maliciosos en el dispositivo comprometido.
  • Mirai-like DDoS:
    - Los equipos infectados se unen a una botnet capaz de lanzar ataques de denegación de servicio distribuidos (DDoS).
    - Soporta patrones típicos de Mirai-like:
    - Floods TCP/UDP hacia puertos específicos de la víctima.
    - Ataques volumétricos coordinados desde múltiples nodos IoT/servidores.
  • Plataformas afectadas:
    - Principalmente sistemas Linux y dispositivos IoT/servidores con SSH expuesto y contraseñas débiles.

Hash real de referencia (SHA-256):
Muestra pública asociada a Goldoon:
Code:
c98f8e771ff9e38a158cf47c41bb4be053ea5d4c1fada37a33d0ceb6f10f5233

Mitigación con GetOverX Shield v3.0.2.0 o superior:
  • Network firewall blocks brute force attempts:
    - Configurar el firewall perimetral / de red para:
    - Limitar el acceso SSH únicamente desde IPs de administración autorizadas.
    - Aplicar listas de control de acceso (ACL) que bloqueen intentos masivos de conexión SSH desde Internet.
    - Habilitar reglas de detección de:
    - Múltiples intentos de login fallidos desde la misma IP (patrón de fuerza bruta).
    - Escaneos sistemáticos de puertos hacia 22/TCP.
    - Opcional: usar protección de rate-limiting para conexiones SSH y sistemas de bloqueo temporal (fail2ban u otros) alrededor del servicio.

  • AV quarantine ELF variants:
    - Usar el motor AV de GetOverX Shield en servidores Linux supervisados para:
    - Detectar y poner en cuarentena binarios ELF asociados a Goldoon y otras variantes Mirai-like.
    - Escanear directorios habituales:
    -
    Code:
    /tmp
    ,
    Code:
    /var/tmp
    ,
    Code:
    /home/*
    , y directorios de servicios.
    - Integrar reglas YARA (si están disponibles) para identificar patrones de botnets IoT y binarios multi-arquitectura.

  • EDR detects SSH attack patterns:
    - Configurar el EDR para:
    - Correlacionar eventos de autenticación SSH fallida en corto intervalo de tiempo.
    - Marcar como sospechosos hosts que:
    - Generan tráfico de salida masivo tipo DDoS hacia un mismo destino.
    - Ejecutan repentinamente procesos desconocidos relacionados con redes/binaries en
    Code:
    /tmp
    .
    - Acciones recomendadas:
    - Aislar temporalmente los hosts que muestren patrones de DDoS o indicadores fuertes de compromiso por Goldoon.
    - Registrar detalle (IP origen, usuario intentado, binario ejecutado, destinos atacados) en los logs unificados para análisis.

  • Buenas prácticas adicionales:
    - Forzar cambio de contraseñas débiles en todos los sistemas con SSH expuesto.
    - Habilitar autenticación por clave pública en lugar de sólo usuario/contraseña cuando sea posible.
    - Mantener firmware/OS de dispositivos IoT y servidores actualizado con parches de seguridad.
]]> Nombre: Goldoon

Categoría: Botnet / IoT malware (tipo Mirai)

Fecha de descubrimiento: 2022

Comportamiento (lo que hace y qué infecta):
  • SSH brute force:
    - Escanea rangos de IP en busca de servicios SSH expuestos.
    - Intenta acceso con credenciales débiles o por defecto mediante ataques de fuerza bruta.
    - Una vez que logra autenticarse, descarga y ejecuta binarios ELF maliciosos en el dispositivo comprometido.
  • Mirai-like DDoS:
    - Los equipos infectados se unen a una botnet capaz de lanzar ataques de denegación de servicio distribuidos (DDoS).
    - Soporta patrones típicos de Mirai-like:
    - Floods TCP/UDP hacia puertos específicos de la víctima.
    - Ataques volumétricos coordinados desde múltiples nodos IoT/servidores.
  • Plataformas afectadas:
    - Principalmente sistemas Linux y dispositivos IoT/servidores con SSH expuesto y contraseñas débiles.

Hash real de referencia (SHA-256):
Muestra pública asociada a Goldoon:
Code:
c98f8e771ff9e38a158cf47c41bb4be053ea5d4c1fada37a33d0ceb6f10f5233

Mitigación con GetOverX Shield v3.0.2.0 o superior:
  • Network firewall blocks brute force attempts:
    - Configurar el firewall perimetral / de red para:
    - Limitar el acceso SSH únicamente desde IPs de administración autorizadas.
    - Aplicar listas de control de acceso (ACL) que bloqueen intentos masivos de conexión SSH desde Internet.
    - Habilitar reglas de detección de:
    - Múltiples intentos de login fallidos desde la misma IP (patrón de fuerza bruta).
    - Escaneos sistemáticos de puertos hacia 22/TCP.
    - Opcional: usar protección de rate-limiting para conexiones SSH y sistemas de bloqueo temporal (fail2ban u otros) alrededor del servicio.

  • AV quarantine ELF variants:
    - Usar el motor AV de GetOverX Shield en servidores Linux supervisados para:
    - Detectar y poner en cuarentena binarios ELF asociados a Goldoon y otras variantes Mirai-like.
    - Escanear directorios habituales:
    -
    Code:
    /tmp
    ,
    Code:
    /var/tmp
    ,
    Code:
    /home/*
    , y directorios de servicios.
    - Integrar reglas YARA (si están disponibles) para identificar patrones de botnets IoT y binarios multi-arquitectura.

  • EDR detects SSH attack patterns:
    - Configurar el EDR para:
    - Correlacionar eventos de autenticación SSH fallida en corto intervalo de tiempo.
    - Marcar como sospechosos hosts que:
    - Generan tráfico de salida masivo tipo DDoS hacia un mismo destino.
    - Ejecutan repentinamente procesos desconocidos relacionados con redes/binaries en
    Code:
    /tmp
    .
    - Acciones recomendadas:
    - Aislar temporalmente los hosts que muestren patrones de DDoS o indicadores fuertes de compromiso por Goldoon.
    - Registrar detalle (IP origen, usuario intentado, binario ejecutado, destinos atacados) en los logs unificados para análisis.

  • Buenas prácticas adicionales:
    - Forzar cambio de contraseñas débiles en todos los sistemas con SSH expuesto.
    - Habilitar autenticación por clave pública en lugar de sólo usuario/contraseña cuando sea posible.
    - Mantener firmware/OS de dispositivos IoT y servidores actualizado con parches de seguridad.
]]> <![CDATA[P2PInfect (2023)]]> https://forum.getoverx.com/showthread.php?tid=69 Sat, 29 Nov 2025 16:17:44 +0000 mrwebfeeder]]> https://forum.getoverx.com/showthread.php?tid=69 Nombre: P2PInfect

Categoría: Botnet / Gusano P2P para servidores Redis

Fecha de descubrimiento: 2023

Comportamiento (lo que hace y qué infecta):
- Peer-to-peer botnet infecting Redis servers:
- Apunta principalmente a servidores Redis expuestos a Internet (sin autenticación o mal configurados).
- Explota funciones de Redis (por ejemplo escritura en disco) para dejar caer binarios maliciosos en el servidor.
- El malware convierte al servidor en un nodo más de una botnet P2P, es decir:
- No depende de un único servidor C2 central.
- Cada nodo puede comunicarse con otros nodos para recibir actualizaciones e instrucciones.
- Funciones típicas tras comprometer el servidor:
- Descarga y ejecuta binarios adicionales (ELF) para la propia botnet.
- Puede usar el servidor comprometido para:
- Escanear otros Redis expuestos.
- Propagar la infección a nuevos objetivos.
- Participar en tareas distribuidas (escaneo, ataques, etc.).
- Plataformas afectadas:
- Principalmente Linux donde se ejecutan instancias de Redis en puertos accesibles desde Internet (generalmente 6379/TCP) sin las medidas de seguridad adecuadas.

Persistencia (comportamiento típico):
- Puede escribir ficheros maliciosos en disco usando comandos de Redis (por ejemplo, modificando rutas de dump o módulos).
- En algunos despliegues se han observado:
- Scripts o binarios añadidos a mecanismos de arranque (cron, systemd, rc.local, etc.) para relanzar el malware tras reinicios.
- Archivos ubicados en rutas temporales o de sistema con nombres genéricos para pasar desapercibidos.

Hash real de referencia (SHA-256):
Muestra pública asociada a P2PInfect:
Code:
0f6e0da2dcfabba283b34149c1f1a38c05f7ce269adb8e318ac7e4d52d513c62

Mitigación con GetOverX Shield v3.0.2.0 o superior:
  • Firewall: block Redis exposure:
    - Asegurar, desde el firewall de red y/o el firewall del host, que:
    - El puerto de Redis (por defecto 6379/TCP) no esté expuesto a Internet.
    - Redis sólo sea accesible:
    - Desde la propia máquina (127.0.0.1) o
    - Desde segmentos internos específicos (por ejemplo, capa de aplicación).
    - Crear reglas que:
    - Bloqueen conexiones entrantes al puerto de Redis desde direcciones externas no autorizadas.
    - Alerten sobre escaneos masivos contra 6379/TCP.

  • EDR: detect process spawning from Redis:
    - Configurar el EDR para:
    - Detectar cuando el proceso de Redis (por ejemplo
    Code:
    redis-server
    ) lanza:
    - Shells (
    Code:
    /bin/sh
    ,
    Code:
    /bin/bash
    ).
    - Otros binarios no habituales (especialmente en
    Code:
    /tmp
    ,
    Code:
    /var/tmp
    o rutas no estándar).
    - Marcar como sospechoso cualquier patrón:
    - Redis → shell → descarga y ejecución de ejecutables remotos.
    - Respuesta recomendada:
    - Detener el proceso hijo sospechoso.
    - Registrar y revisar la configuración actual de Redis (incluyendo rutas de dump y módulos cargados).
    - Si se confirma compromiso, aislar temporalmente el servidor de la red para análisis.

  • Sandbox suspicious server binaries:
    - Cualquier binario recién creado cerca de Redis (por ejemplo en
    Code:
    /tmp
    ,
    Code:
    /var/tmp
    o directorios asociados al servicio) debe:
    - Analizarse en la Sandbox de GetOverX Shield antes de ejecutarse manualmente.
    - Verificarse si:
    - Establece conexiones P2P.
    - Escanea puertos de otros hosts.
    - Se comporta como botnet (tráfico periódico, comandos remotos, etc.).
    - Poner en cuarentena:
    - Binarios ELF que muestren comportamiento de botnet o coincidan con firmas de P2PInfect.

Buenas prácticas adicionales:
- Configurar Redis con:
- Autenticación (contraseñas robustas).
- bind a interfaces internas únicamente.
- Mantener Redis y el sistema operativo actualizados con parches recientes.
- Revisar periódicamente:
- Tareas programadas, servicios y scripts de arranque en servidores con Redis.
- La integridad de binarios y configuraciones en sistemas expuestos.]]> Nombre: P2PInfect

Categoría: Botnet / Gusano P2P para servidores Redis

Fecha de descubrimiento: 2023

Comportamiento (lo que hace y qué infecta):
- Peer-to-peer botnet infecting Redis servers:
- Apunta principalmente a servidores Redis expuestos a Internet (sin autenticación o mal configurados).
- Explota funciones de Redis (por ejemplo escritura en disco) para dejar caer binarios maliciosos en el servidor.
- El malware convierte al servidor en un nodo más de una botnet P2P, es decir:
- No depende de un único servidor C2 central.
- Cada nodo puede comunicarse con otros nodos para recibir actualizaciones e instrucciones.
- Funciones típicas tras comprometer el servidor:
- Descarga y ejecuta binarios adicionales (ELF) para la propia botnet.
- Puede usar el servidor comprometido para:
- Escanear otros Redis expuestos.
- Propagar la infección a nuevos objetivos.
- Participar en tareas distribuidas (escaneo, ataques, etc.).
- Plataformas afectadas:
- Principalmente Linux donde se ejecutan instancias de Redis en puertos accesibles desde Internet (generalmente 6379/TCP) sin las medidas de seguridad adecuadas.

Persistencia (comportamiento típico):
- Puede escribir ficheros maliciosos en disco usando comandos de Redis (por ejemplo, modificando rutas de dump o módulos).
- En algunos despliegues se han observado:
- Scripts o binarios añadidos a mecanismos de arranque (cron, systemd, rc.local, etc.) para relanzar el malware tras reinicios.
- Archivos ubicados en rutas temporales o de sistema con nombres genéricos para pasar desapercibidos.

Hash real de referencia (SHA-256):
Muestra pública asociada a P2PInfect:
Code:
0f6e0da2dcfabba283b34149c1f1a38c05f7ce269adb8e318ac7e4d52d513c62

Mitigación con GetOverX Shield v3.0.2.0 o superior:
  • Firewall: block Redis exposure:
    - Asegurar, desde el firewall de red y/o el firewall del host, que:
    - El puerto de Redis (por defecto 6379/TCP) no esté expuesto a Internet.
    - Redis sólo sea accesible:
    - Desde la propia máquina (127.0.0.1) o
    - Desde segmentos internos específicos (por ejemplo, capa de aplicación).
    - Crear reglas que:
    - Bloqueen conexiones entrantes al puerto de Redis desde direcciones externas no autorizadas.
    - Alerten sobre escaneos masivos contra 6379/TCP.

  • EDR: detect process spawning from Redis:
    - Configurar el EDR para:
    - Detectar cuando el proceso de Redis (por ejemplo
    Code:
    redis-server
    ) lanza:
    - Shells (
    Code:
    /bin/sh
    ,
    Code:
    /bin/bash
    ).
    - Otros binarios no habituales (especialmente en
    Code:
    /tmp
    ,
    Code:
    /var/tmp
    o rutas no estándar).
    - Marcar como sospechoso cualquier patrón:
    - Redis → shell → descarga y ejecución de ejecutables remotos.
    - Respuesta recomendada:
    - Detener el proceso hijo sospechoso.
    - Registrar y revisar la configuración actual de Redis (incluyendo rutas de dump y módulos cargados).
    - Si se confirma compromiso, aislar temporalmente el servidor de la red para análisis.

  • Sandbox suspicious server binaries:
    - Cualquier binario recién creado cerca de Redis (por ejemplo en
    Code:
    /tmp
    ,
    Code:
    /var/tmp
    o directorios asociados al servicio) debe:
    - Analizarse en la Sandbox de GetOverX Shield antes de ejecutarse manualmente.
    - Verificarse si:
    - Establece conexiones P2P.
    - Escanea puertos de otros hosts.
    - Se comporta como botnet (tráfico periódico, comandos remotos, etc.).
    - Poner en cuarentena:
    - Binarios ELF que muestren comportamiento de botnet o coincidan con firmas de P2PInfect.

Buenas prácticas adicionales:
- Configurar Redis con:
- Autenticación (contraseñas robustas).
- bind a interfaces internas únicamente.
- Mantener Redis y el sistema operativo actualizados con parches recientes.
- Revisar periódicamente:
- Tareas programadas, servicios y scripts de arranque en servidores con Redis.
- La integridad de binarios y configuraciones en sistemas expuestos.]]> <![CDATA[BOTNET – Cutwail]]> https://forum.getoverx.com/showthread.php?tid=49 Sat, 29 Nov 2025 15:56:26 +0000 mrwebfeeder]]> https://forum.getoverx.com/showthread.php?tid=49 Nombre: Cutwail / Pushdo
(indica el nombre del malware, incluir alias si los tiene)

Categoría: Botnet
(ej.: Ransomware, Infostealer, Troyano bancario, RAT, Loader/Downloader, etc.)

Fecha de descubrimiento: Alrededor de 2007

Comportamiento (lo que hace y archivos que infecta):
- Botnet orientada principalmente al envío masivo de spam y a la realización de ataques distribuidos.
- Los equipos infectados se convierten en “zombies” que:
- Envían grandes volúmenes de correo no deseado (phishing, malware adjunto, enlaces maliciosos).
- Pueden participar en ataques de denegación de servicio distribuida (DDoS) contra objetivos específicos.
- Descargan otros malware de forma silenciosa, como troyanos bancarios, ransomware o stealers.
- Afecta principalmente a estaciones Windows:
- Instala binarios en rutas de usuario o sistema con nombres que imitan procesos legítimos.
- Genera un fuerte aumento de tráfico de red saliente, especialmente SMTP y conexiones hacia servidores de C2.
- No cifra archivos ni los modifica de forma destructiva; el impacto se centra en:
- Abuso de recursos (CPU/red) para spam/DDoS.
- Riesgo reputacional por inclusión de la IP en listas negras de spam.

Persistencia:
- Describe cómo se mantiene en el sistema:
- Claves de Registro (Run/RunOnce):
- Añade entradas de inicio automático en rutas como:
-
Code:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
-
Code:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
- Tareas programadas:
- Crea tareas que relanzan el binario del bot tras cada reinicio o a intervalos regulares.
- Servicios:
- En algunas variantes se registra como servicio de Windows con nombres que suenan legítimos.
- Copias en carpetas de usuario o sistema:
- Guarda el ejecutable en directorios como AppData, ProgramData o subcarpetas del sistema con nombres genéricos.
- Uso de herramientas administrativas, RDP, etc.:
- Puede aprovechar credenciales comprometidas para propagarse lateralmente y desplegar el bot en otros equipos de la red.

Hash real de referencia (SHA-256):
- Añade un hash SHA-256 real de una muestra pública conocida del malware.
- Ejemplo de formato:
Code:
67a43b3556105c8c65050ab47b183b6ddc7c8c3c17e297dc1c2ea945b124e532

Mitigación con GetOverX Shield v3.0.2.0:
Describe los pasos recomendados usando los módulos de GetOverX Shield:
  • Antivirus:
    Explica cómo usar el motor AV para detectar y eliminar el ejecutable principal y sus droppers.
    - Ejecutar un escaneo completo de todas las unidades para localizar el binario de Cutwail/Pushdo y cualquier dropper asociado.
    - Poner en cuarentena:
    - Ejecutables ubicados en AppData/ProgramData con nombres sospechosos.
    - Ficheros que coincidan con firmas o reglas YARA específicas para Cutwail/Pushdo.
    - Programar escaneos periódicos en servidores de correo y estaciones con clientes de correo instalados.

  • Firewall:
    Indica qué tipo de tráfico debe bloquearse (C2, dominios sospechosos, puertos, etc.) y si es recomendable aislar el host.
    - Restringir el tráfico SMTP saliente:
    - Permitir sólo los servidores de correo corporativos o gateways autorizados.
    - Bloquear conexiones directas a puertos 25/465/587 desde estaciones que no deban enviar correo.
    - Monitorear y bloquear:
    - Conexiones hacia IPs/Dominios identificados como C2 de Cutwail/Pushdo.
    - Tráfico saliente anómalo de alto volumen que pueda indicar envío masivo de spam o participación en DDoS.
    - Aislar temporalmente los hosts que muestren actividad de botnet hasta completar la limpieza.

  • HIPS/EDR:
    Detalla qué comportamiento debe vigilarse:
    - Creación masiva de archivos (ransomware)
    - Acceso masivo a almacenes de credenciales (stealers)
    - Uso anómalo de PowerShell / scripts
    - Movimiento lateral, enumeración de red, etc.
    Incluye si se debe configurar respuesta automática (matar proceso, bloquear hash, etc.).
    - Configurar reglas para detectar:
    - Procesos que generan un volumen inusual de conexiones SMTP y conexiones recurrentes a C2.
    - Creación/modificación de claves Run/RunOnce y tareas programadas que apunten a ejecutables desconocidos.
    - Respuesta automática recomendada:
    - Matar procesos responsables del envío de spam y comunicación con C2.
    - Bloquear el hash de los binarios identificados.
    - Generar alerta crítica y marcar el host para análisis forense y posible aislamiento de red.

  • Sandbox:
    Explica cuándo es recomendable usar el módulo de Sandbox:
    - Antes de ejecutar adjuntos de correo
    - Antes de instalar software de procedencia dudosa
    - Para analizar muestras sospechosas en un entorno aislado
    - Analizar en la Sandbox:
    - Adjuntos sospechosos usados en campañas de spam (documentos, ejecutables, archivos comprimidos).
    - Herramientas o instaladores descargados desde enlaces incluidos en correos no solicitados.
    - Observar si:
    - El binario intenta enviar spam o abrir múltiples conexiones SMTP.
    - Se conecta a dominios asociados a C2 de Cutwail/Pushdo o descarga otros malware.
    - Bloquear la distribución interna de cualquier archivo que muestre comportamiento de botnet.

  • Medidas posteriores al incidente:
    Indica acciones adicionales:
    - Restaurar desde copias de seguridad offline
    - Cambiar contraseñas
    - Revisar accesos a cuentas sensibles (banca, VPN, paneles de hosting)
    - Revisión de herramientas de administración remota abusadas
    - Revisar colas y logs del servidor de corr
]]> Nombre: Cutwail / Pushdo
(indica el nombre del malware, incluir alias si los tiene)

Categoría: Botnet
(ej.: Ransomware, Infostealer, Troyano bancario, RAT, Loader/Downloader, etc.)

Fecha de descubrimiento: Alrededor de 2007

Comportamiento (lo que hace y archivos que infecta):
- Botnet orientada principalmente al envío masivo de spam y a la realización de ataques distribuidos.
- Los equipos infectados se convierten en “zombies” que:
- Envían grandes volúmenes de correo no deseado (phishing, malware adjunto, enlaces maliciosos).
- Pueden participar en ataques de denegación de servicio distribuida (DDoS) contra objetivos específicos.
- Descargan otros malware de forma silenciosa, como troyanos bancarios, ransomware o stealers.
- Afecta principalmente a estaciones Windows:
- Instala binarios en rutas de usuario o sistema con nombres que imitan procesos legítimos.
- Genera un fuerte aumento de tráfico de red saliente, especialmente SMTP y conexiones hacia servidores de C2.
- No cifra archivos ni los modifica de forma destructiva; el impacto se centra en:
- Abuso de recursos (CPU/red) para spam/DDoS.
- Riesgo reputacional por inclusión de la IP en listas negras de spam.

Persistencia:
- Describe cómo se mantiene en el sistema:
- Claves de Registro (Run/RunOnce):
- Añade entradas de inicio automático en rutas como:
-
Code:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
-
Code:
HKLM\Software\Microsoft\Windows\CurrentVersion\Run
- Tareas programadas:
- Crea tareas que relanzan el binario del bot tras cada reinicio o a intervalos regulares.
- Servicios:
- En algunas variantes se registra como servicio de Windows con nombres que suenan legítimos.
- Copias en carpetas de usuario o sistema:
- Guarda el ejecutable en directorios como AppData, ProgramData o subcarpetas del sistema con nombres genéricos.
- Uso de herramientas administrativas, RDP, etc.:
- Puede aprovechar credenciales comprometidas para propagarse lateralmente y desplegar el bot en otros equipos de la red.

Hash real de referencia (SHA-256):
- Añade un hash SHA-256 real de una muestra pública conocida del malware.
- Ejemplo de formato:
Code:
67a43b3556105c8c65050ab47b183b6ddc7c8c3c17e297dc1c2ea945b124e532

Mitigación con GetOverX Shield v3.0.2.0:
Describe los pasos recomendados usando los módulos de GetOverX Shield:
  • Antivirus:
    Explica cómo usar el motor AV para detectar y eliminar el ejecutable principal y sus droppers.
    - Ejecutar un escaneo completo de todas las unidades para localizar el binario de Cutwail/Pushdo y cualquier dropper asociado.
    - Poner en cuarentena:
    - Ejecutables ubicados en AppData/ProgramData con nombres sospechosos.
    - Ficheros que coincidan con firmas o reglas YARA específicas para Cutwail/Pushdo.
    - Programar escaneos periódicos en servidores de correo y estaciones con clientes de correo instalados.

  • Firewall:
    Indica qué tipo de tráfico debe bloquearse (C2, dominios sospechosos, puertos, etc.) y si es recomendable aislar el host.
    - Restringir el tráfico SMTP saliente:
    - Permitir sólo los servidores de correo corporativos o gateways autorizados.
    - Bloquear conexiones directas a puertos 25/465/587 desde estaciones que no deban enviar correo.
    - Monitorear y bloquear:
    - Conexiones hacia IPs/Dominios identificados como C2 de Cutwail/Pushdo.
    - Tráfico saliente anómalo de alto volumen que pueda indicar envío masivo de spam o participación en DDoS.
    - Aislar temporalmente los hosts que muestren actividad de botnet hasta completar la limpieza.

  • HIPS/EDR:
    Detalla qué comportamiento debe vigilarse:
    - Creación masiva de archivos (ransomware)
    - Acceso masivo a almacenes de credenciales (stealers)
    - Uso anómalo de PowerShell / scripts
    - Movimiento lateral, enumeración de red, etc.
    Incluye si se debe configurar respuesta automática (matar proceso, bloquear hash, etc.).
    - Configurar reglas para detectar:
    - Procesos que generan un volumen inusual de conexiones SMTP y conexiones recurrentes a C2.
    - Creación/modificación de claves Run/RunOnce y tareas programadas que apunten a ejecutables desconocidos.
    - Respuesta automática recomendada:
    - Matar procesos responsables del envío de spam y comunicación con C2.
    - Bloquear el hash de los binarios identificados.
    - Generar alerta crítica y marcar el host para análisis forense y posible aislamiento de red.

  • Sandbox:
    Explica cuándo es recomendable usar el módulo de Sandbox:
    - Antes de ejecutar adjuntos de correo
    - Antes de instalar software de procedencia dudosa
    - Para analizar muestras sospechosas en un entorno aislado
    - Analizar en la Sandbox:
    - Adjuntos sospechosos usados en campañas de spam (documentos, ejecutables, archivos comprimidos).
    - Herramientas o instaladores descargados desde enlaces incluidos en correos no solicitados.
    - Observar si:
    - El binario intenta enviar spam o abrir múltiples conexiones SMTP.
    - Se conecta a dominios asociados a C2 de Cutwail/Pushdo o descarga otros malware.
    - Bloquear la distribución interna de cualquier archivo que muestre comportamiento de botnet.

  • Medidas posteriores al incidente:
    Indica acciones adicionales:
    - Restaurar desde copias de seguridad offline
    - Cambiar contraseñas
    - Revisar accesos a cuentas sensibles (banca, VPN, paneles de hosting)
    - Revisión de herramientas de administración remota abusadas
    - Revisar colas y logs del servidor de corr
]]> <![CDATA[BOTNET – Mirai]]> https://forum.getoverx.com/showthread.php?tid=33 Sat, 29 Nov 2025 15:41:14 +0000 mrwebfeeder]]> https://forum.getoverx.com/showthread.php?tid=33 Nombre: Mirai
(indica el nombre del malware, incluir alias si los tiene)

Categoría: IoT Botnet
(ej.: Ransomware, Infostealer, Troyano bancario, RAT, Loader/Downloader, etc.)

Fecha de descubrimiento: 2016

Comportamiento (lo que hace y archivos que infecta):
- Botnet orientada a dispositivos IoT (cámaras IP, DVR/NVR, routers SOHO, CPEs, etc.).
- Infecta dispositivos principalmente mediante:
- Escaneo masivo de Internet en busca de servicios expuestos (Telnet, SSH, HTTP de administración).
- Uso de credenciales por defecto o muy débiles para iniciar sesión y desplegar el binario.
- Una vez que compromete el dispositivo:
- Descarga y ejecuta un binario adaptado a la arquitectura (ARM, MIPS, etc.).
- Registra el dispositivo como un nodo más de la botnet Mirai.
- Ataques DDoS masivos:
- Utiliza los dispositivos infectados para lanzar ataques de denegación de servicio distribuida (DDoS) contra objetivos definidos por los operadores.
- Soporta múltiples vectores (UDP floods, TCP SYN floods, HTTP floods, etc.).
- Escaneo en Telnet/SSH:
- Los bots escanean direcciones IP aleatorias o listas específicas en busca de nuevos dispositivos vulnerables.
- Intentan autenticarse con listas de usuarios/contraseñas por defecto para propagarse.
- “Archivos que infecta”:
- En muchos dispositivos IoT, el binario se ejecuta en memoria o se descarga a directorios temporales (por ejemplo
Code:
/tmp
).
- No cifra ni modifica archivos del usuario; su foco es el control del dispositivo y la participación en DDoS.

Persistencia:
- Describe cómo se mantiene en el sistema:
- En muchas variantes clásicas:
- El malware reside principalmente en memoria; al reiniciar el dispositivo, la infección se pierde.
- Sin embargo, el mismo dispositivo puede ser reinfectado rápidamente mientras siga:
- Expuesto a Internet.
- Usando credenciales por defecto.
- Variantes más recientes pueden:
- Escribir scripts o entradas en el sistema embebido para relanzar el binario tras un reinicio (según capacidades del firmware).
- Modificar parámetros de arranque o archivos de inicio para mantener la ejecución del bot.
- El mecanismo de “persistencia real” de Mirai a nivel de red es:
- La reinfectación constante desde otros nodos de la botnet si no se corrige la causa raíz (exposición, claves débiles, firmware sin parches).

Hash real de referencia (SHA-256):
- Añade un hash SHA-256 real de una muestra pública conocida del malware.
- Ejemplo de formato:
Code:
SHA256: 1c234e7eaf7c5751ec8f6a8abca096935ccebff98c582a289bc8123b7d57ed85

Mitigación con GetOverX Shield v3.0.2.0:
Describe los pasos recomendados usando los módulos de GetOverX Shield:
  • Antivirus:
    Explica cómo usar el motor AV para detectar y eliminar el ejecutable principal y sus droppers.
    - En servidores Linux o equipos que gestionen firmware/imagenes de dispositivos:
    - Ejecutar escaneos sobre binarios ELF descargados (especialmente en
    Code:
    /tmp
    ,
    Code:
    /var/tmp
    y repositorios de firmware).
    - Mantener firmas y reglas YARA enfocadas a variantes Mirai/Mirai-like.
    - En gateways o appliances monitorizados por GetOverX Shield:
    - Escanear regularmente ficheros sospechosos asociados a herramientas de administración remota y scripts de despliegue.

  • Firewall:
    Indica qué tipo de tráfico debe bloquearse (C2, dominios sospechosos, puertos, etc.) y si es recomendable aislar el host.
    - Bloquear desde el perímetro:
    - Acceso Telnet (23/TCP) y SSH (22/TCP) desde Internet a dispositivos IoT siempre que no sea estrictamente necesario.
    - Exposición de paneles HTTP/HTTPS de administración de cámaras/DVR/routers a Internet.
    - Crear reglas específicas para:
    - Limitar conexiones salientes desde segmentos IoT hacia Internet a los servicios estrictamente necesarios.
    - Detectar y bloquear tráfico característico de DDoS (floods volumétricos provenientes de rangos IoT internos).
    - Aislar de la red (o limitar fuertemente el ancho de banda) a los dispositivos que muestren comportamiento típico de bot (tráfico de DDoS, escaneo agresivo).

  • HIPS/EDR:
    Detalla qué comportamiento debe vigilarse:
    - Creación masiva de archivos (ransomware)
    - Acceso masivo a almacenes de credenciales (stealers)
    - Uso anómalo de PowerShell / scripts
    - Movimiento lateral, enumeración de red, etc.
    Incluye si se debe configurar respuesta automática (matar proceso, bloquear hash, etc.).
    - En servidores y equipos de administración monitorizados:
    - Detectar procesos que:
    - Compilan, despliegan o ejecutan binarios ELF multi-arquitectura sin justificación clara.
    - Generan tráfico de escaneo de puertos a gran escala desde la red interna.
    - Respuesta recomendada:
    - Marcar como sospechosos los hosts que generen tráfico de escaneo o DDoS.
    - Registrar IPs internas implicadas para facilitar la localización física de los dispositivos IoT comprometidos.
    - Si el malware se ejecuta en un sistema administrado por GetOverX Shield, matar el proceso y bloquear el hash.

  • Sandbox:
    Explica cuándo es recomendable usar el módulo de Sandbox:
    - Antes de ejecutar adjuntos de correo
    - Antes de instalar software de procedencia dudosa
    - Para analizar muestras sospechosas en un entorno aislado
    - Analizar en la Sandbox:
    - Binarios ELF sospechosos destinados a IoT o servidores Linux.
    - Scripts que descargan ejecutables multiplaforma (ARM/MIPS/etc.).
    - Observar si:
    - El binario inicia rutinas de escaneo de puertos (Telnet/SSH) y de fuerza bruta de credenciales.
    - Establece conexiones con infraestructura de C2 típica de Mirai o lanza tráfico de prueba tipo DDoS.
    - Si se confirma comportamiento Mirai-like:
    - Bloquear la distribución de ese binario dentro de la red.
    - Marcarlo para uso como IOC en futuras detecciones.

  • Medidas posteriores al incidente:
    Indica acciones adicionales:
    - Restaurar desde copias de seguridad offline
    - Cambiar contraseñas
    - Revisar accesos a cuentas sensibles (banca, VPN, paneles de hosting)
    - Revisión de herramientas de administración remota abusadas
    - Para dispositivos IoT comprometidos:
    - Cambiar inmediatamente todas las credenciales por defecto por contraseñas robustas.
    - Actualizar el firmware a la última versión disponible.
    - Cuando sea posible, realizar un reset de fábrica y reconfigurar desde cero sin reutilizar configuraciones antiguas no confiables.
    - En la red:
    - Segmentar los dispositivos IoT en VLANs separadas con acceso muy limitado.
    - Revisar logs de firewall y de tráfico para confirmar que ya no se observan patrones de DDoS ni escaneos salientes.
    - Documentar:
    - Modelos de dispositivos afectados.
    - Versiones de firmware vulnerables.
    - Medidas tomadas, para prevenir futuras reinfecciones.

Notas opcionales:
- Mirai fue responsable de algunos de los ataques DDoS más grandes registrados públicamente en 2016, demostrando el impacto que puede tener una botnet basada en dispositivos IoT mal configurados.]]> Nombre: Mirai
(indica el nombre del malware, incluir alias si los tiene)

Categoría: IoT Botnet
(ej.: Ransomware, Infostealer, Troyano bancario, RAT, Loader/Downloader, etc.)

Fecha de descubrimiento: 2016

Comportamiento (lo que hace y archivos que infecta):
- Botnet orientada a dispositivos IoT (cámaras IP, DVR/NVR, routers SOHO, CPEs, etc.).
- Infecta dispositivos principalmente mediante:
- Escaneo masivo de Internet en busca de servicios expuestos (Telnet, SSH, HTTP de administración).
- Uso de credenciales por defecto o muy débiles para iniciar sesión y desplegar el binario.
- Una vez que compromete el dispositivo:
- Descarga y ejecuta un binario adaptado a la arquitectura (ARM, MIPS, etc.).
- Registra el dispositivo como un nodo más de la botnet Mirai.
- Ataques DDoS masivos:
- Utiliza los dispositivos infectados para lanzar ataques de denegación de servicio distribuida (DDoS) contra objetivos definidos por los operadores.
- Soporta múltiples vectores (UDP floods, TCP SYN floods, HTTP floods, etc.).
- Escaneo en Telnet/SSH:
- Los bots escanean direcciones IP aleatorias o listas específicas en busca de nuevos dispositivos vulnerables.
- Intentan autenticarse con listas de usuarios/contraseñas por defecto para propagarse.
- “Archivos que infecta”:
- En muchos dispositivos IoT, el binario se ejecuta en memoria o se descarga a directorios temporales (por ejemplo
Code:
/tmp
).
- No cifra ni modifica archivos del usuario; su foco es el control del dispositivo y la participación en DDoS.

Persistencia:
- Describe cómo se mantiene en el sistema:
- En muchas variantes clásicas:
- El malware reside principalmente en memoria; al reiniciar el dispositivo, la infección se pierde.
- Sin embargo, el mismo dispositivo puede ser reinfectado rápidamente mientras siga:
- Expuesto a Internet.
- Usando credenciales por defecto.
- Variantes más recientes pueden:
- Escribir scripts o entradas en el sistema embebido para relanzar el binario tras un reinicio (según capacidades del firmware).
- Modificar parámetros de arranque o archivos de inicio para mantener la ejecución del bot.
- El mecanismo de “persistencia real” de Mirai a nivel de red es:
- La reinfectación constante desde otros nodos de la botnet si no se corrige la causa raíz (exposición, claves débiles, firmware sin parches).

Hash real de referencia (SHA-256):
- Añade un hash SHA-256 real de una muestra pública conocida del malware.
- Ejemplo de formato:
Code:
SHA256: 1c234e7eaf7c5751ec8f6a8abca096935ccebff98c582a289bc8123b7d57ed85

Mitigación con GetOverX Shield v3.0.2.0:
Describe los pasos recomendados usando los módulos de GetOverX Shield:
  • Antivirus:
    Explica cómo usar el motor AV para detectar y eliminar el ejecutable principal y sus droppers.
    - En servidores Linux o equipos que gestionen firmware/imagenes de dispositivos:
    - Ejecutar escaneos sobre binarios ELF descargados (especialmente en
    Code:
    /tmp
    ,
    Code:
    /var/tmp
    y repositorios de firmware).
    - Mantener firmas y reglas YARA enfocadas a variantes Mirai/Mirai-like.
    - En gateways o appliances monitorizados por GetOverX Shield:
    - Escanear regularmente ficheros sospechosos asociados a herramientas de administración remota y scripts de despliegue.

  • Firewall:
    Indica qué tipo de tráfico debe bloquearse (C2, dominios sospechosos, puertos, etc.) y si es recomendable aislar el host.
    - Bloquear desde el perímetro:
    - Acceso Telnet (23/TCP) y SSH (22/TCP) desde Internet a dispositivos IoT siempre que no sea estrictamente necesario.
    - Exposición de paneles HTTP/HTTPS de administración de cámaras/DVR/routers a Internet.
    - Crear reglas específicas para:
    - Limitar conexiones salientes desde segmentos IoT hacia Internet a los servicios estrictamente necesarios.
    - Detectar y bloquear tráfico característico de DDoS (floods volumétricos provenientes de rangos IoT internos).
    - Aislar de la red (o limitar fuertemente el ancho de banda) a los dispositivos que muestren comportamiento típico de bot (tráfico de DDoS, escaneo agresivo).

  • HIPS/EDR:
    Detalla qué comportamiento debe vigilarse:
    - Creación masiva de archivos (ransomware)
    - Acceso masivo a almacenes de credenciales (stealers)
    - Uso anómalo de PowerShell / scripts
    - Movimiento lateral, enumeración de red, etc.
    Incluye si se debe configurar respuesta automática (matar proceso, bloquear hash, etc.).
    - En servidores y equipos de administración monitorizados:
    - Detectar procesos que:
    - Compilan, despliegan o ejecutan binarios ELF multi-arquitectura sin justificación clara.
    - Generan tráfico de escaneo de puertos a gran escala desde la red interna.
    - Respuesta recomendada:
    - Marcar como sospechosos los hosts que generen tráfico de escaneo o DDoS.
    - Registrar IPs internas implicadas para facilitar la localización física de los dispositivos IoT comprometidos.
    - Si el malware se ejecuta en un sistema administrado por GetOverX Shield, matar el proceso y bloquear el hash.

  • Sandbox:
    Explica cuándo es recomendable usar el módulo de Sandbox:
    - Antes de ejecutar adjuntos de correo
    - Antes de instalar software de procedencia dudosa
    - Para analizar muestras sospechosas en un entorno aislado
    - Analizar en la Sandbox:
    - Binarios ELF sospechosos destinados a IoT o servidores Linux.
    - Scripts que descargan ejecutables multiplaforma (ARM/MIPS/etc.).
    - Observar si:
    - El binario inicia rutinas de escaneo de puertos (Telnet/SSH) y de fuerza bruta de credenciales.
    - Establece conexiones con infraestructura de C2 típica de Mirai o lanza tráfico de prueba tipo DDoS.
    - Si se confirma comportamiento Mirai-like:
    - Bloquear la distribución de ese binario dentro de la red.
    - Marcarlo para uso como IOC en futuras detecciones.

  • Medidas posteriores al incidente:
    Indica acciones adicionales:
    - Restaurar desde copias de seguridad offline
    - Cambiar contraseñas
    - Revisar accesos a cuentas sensibles (banca, VPN, paneles de hosting)
    - Revisión de herramientas de administración remota abusadas
    - Para dispositivos IoT comprometidos:
    - Cambiar inmediatamente todas las credenciales por defecto por contraseñas robustas.
    - Actualizar el firmware a la última versión disponible.
    - Cuando sea posible, realizar un reset de fábrica y reconfigurar desde cero sin reutilizar configuraciones antiguas no confiables.
    - En la red:
    - Segmentar los dispositivos IoT en VLANs separadas con acceso muy limitado.
    - Revisar logs de firewall y de tráfico para confirmar que ya no se observan patrones de DDoS ni escaneos salientes.
    - Documentar:
    - Modelos de dispositivos afectados.
    - Versiones de firmware vulnerables.
    - Medidas tomadas, para prevenir futuras reinfecciones.

Notas opcionales:
- Mirai fue responsable de algunos de los ataques DDoS más grandes registrados públicamente en 2016, demostrando el impacto que puede tener una botnet basada en dispositivos IoT mal configurados.]]>