Cómo detectar cuentas comprometidas en MU Online

Las cuentas comprometidas son uno de los problemas de seguridad más corrosivos en un servidor de MU Online. A diferencia de un ataque DDoS, que es ruidoso e inmediato, la invasión de cuenta es silenciosa: el atacante entra con la credencial robada, vacía el baúl, transfiere ítems valiosos y zen a una cuenta "muleta" y desaparece, muchas veces antes de que el dueño legítimo se dé cuenta. Cuando llega la denuncia, los ítems ya circularon y la reversión se volvió difícil. La defensa eficaz combina prevención (contraseñas fuertes, segundo factor, límites de sesión) con detección rápida: ver el comportamiento anómalo mientras la ventana de reversión todavía está abierta. Esta guía se centra en la detección, mostrando qué señales monitorear, cómo consultarlas en la base de datos y cómo responder sin destruir evidencias.

Los ejemplos usan el schema clásico de MuServer (SQL Server, base de datos MuOnline, tabla MEMB_INFO) y suponen la existencia de tablas de log de login y de movimiento. Los nombres de tabla y columna varían según la season/emulador: muchas distribuciones no tienen log de trade por defecto, y habilitarlo es el primer prerrequisito práctico. Adapta cada query a tu base de datos.

Por qué la detección manual no escala

Esperar la denuncia del jugador es reactivo y lento. Cuando llega el ticket, tres cosas ya ocurrieron: el ítem salió de la cuenta, pasó por una o más intermediarias y posiblemente fue negociado. La ventana en la que consigues revertir con seguridad, antes de que el ítem se mezcle con la economía, suele ser de horas. El enfoque correcto es monitorear señales proactivamente, con queries programadas que señalen patrones sospechosos, y reservar la inspección manual para los casos que la automatización levante.

Prerrequisitos

Para detectar de verdad, necesitas datos. Antes que nada:

• Logs de login activos: registro de cuenta, IP, fecha/hora y resultado (éxito/fallo) de cada intento. Actívalo en el ConnectServer/GameServer de tu distribución.
• Log de movimiento de ítems/zen: warehouse, trade y drop al suelo. No toda season lo trae; habilita o instala un módulo/trigger de log.
• Acceso al SQL Server con permiso de lectura sobre los logs y la base de datos de juego.
• Backup reciente para permitir la reversión de ítems/zen cuando confirmes una invasión.
• Servidor estable en producción. Si todavía estás montando el entorno, empieza por cómo crear un servidor de MU Online y vuelve con los logs configurados.
• Política de respuesta definida: quién congela, quién investiga, quién comunica al dueño.

Las señales de compromiso

Ninguna señal aislada prueba una invasión: el dueño pudo haber viajado, cambiado de operadora o vendido ítems legítimamente. La confianza viene de la correlación. Estos son los indicadores más fuertes:

La regla de oro: una señal es ruido, tres o más juntas son un caso. Un login desde una IP nueva por sí solo no justifica congelar; un login desde una IP nueva, seguido del vaciado del baúl y de trade masivo hacia una cuenta creada ayer, sí lo justifica.

Paso 1 — Detectar logins anómalos

Empieza por los logs de login. La primera query útil encuentra cuentas que iniciaron sesión desde una IP nunca antes asociada a ellas en las últimas 24 horas:

-- Logins desde IP "nueva" (no vista para la cuenta en el histórico anterior) en las últimas 24h
SELECT l.AccountID, l.IP, l.LoginDate
FROM LoginLog l
WHERE l.LoginDate >= DATEADD(HOUR, -24, GETDATE())
  AND l.Result = 'success'
  AND NOT EXISTS (
        SELECT 1 FROM LoginLog h
        WHERE h.AccountID = l.AccountID
          AND h.IP = l.IP
          AND h.LoginDate < DATEADD(HOUR, -24, GETDATE())
      )
ORDER BY l.AccountID, l.LoginDate;
GO

Un segundo patrón clásico es la fuerza bruta: muchos fallos seguidos de un éxito, en la misma cuenta y en corto intervalo.

-- Cuentas con muchos fallos antes de un éxito (posible fuerza bruta)
SELECT AccountID,
       SUM(CASE WHEN Result = 'fail'    THEN 1 ELSE 0 END) AS Fallos,
       SUM(CASE WHEN Result = 'success' THEN 1 ELSE 0 END) AS Exitos,
       MIN(LoginDate) AS Inicio, MAX(LoginDate) AS Fin
FROM LoginLog
WHERE LoginDate >= DATEADD(HOUR, -1, GETDATE())
GROUP BY AccountID
HAVING SUM(CASE WHEN Result = 'fail' THEN 1 ELSE 0 END) >= 10
   AND SUM(CASE WHEN Result = 'success' THEN 1 ELSE 0 END) >= 1
ORDER BY Fallos DESC;
GO

Una tercera señal es el login geográficamente imposible: la misma cuenta iniciando sesión desde IPs muy distantes en pocos minutos. Sin base de geolocalización, puedes aproximarlo comparando bloques de IP (/16) distintos en una ventana corta.

Paso 2 — Detectar movimiento anómalo de ítems y zen

Un login sospechoso solo se convierte en caso cuando hay daño. Crúzalo con el movimiento. Si tienes log de trade, la query más valiosa es la de cuentas destino que concentran ítems de varias orígenes, el comportamiento típico de la cuenta "muleta":

-- Cuentas que RECIBIERON ítems de muchos orígenes distintos en las últimas 6h
SELECT t.ToAccount,
       COUNT(DISTINCT t.FromAccount) AS OrigenesDistintos,
       COUNT(*) AS TotalTrades
FROM TradeLog t
WHERE t.TradeDate >= DATEADD(HOUR, -6, GETDATE())
GROUP BY t.ToAccount
HAVING COUNT(DISTINCT t.FromAccount) >= 4
ORDER BY OrigenesDistintos DESC;
GO

Y la de cuentas que vaciaron el baúl justo después del login:

-- Muchos ítems saliendo del warehouse poco después del login
SELECT w.AccountID, COUNT(*) AS ItensRetirados, MIN(w.MoveDate) AS Inicio
FROM WarehouseLog w
JOIN LoginLog l
  ON l.AccountID = w.AccountID
 AND w.MoveDate BETWEEN l.LoginDate AND DATEADD(MINUTE, 15, l.LoginDate)
WHERE w.Direction = 'out'
  AND l.LoginDate >= DATEADD(HOUR, -24, GETDATE())
GROUP BY w.AccountID
HAVING COUNT(*) >= 10
ORDER BY ItensRetirados DESC;
GO

Si tu distribución no tiene log de trade/warehouse, la alternativa es comparar instantáneas del zen y del recuento de ítems de la cuenta entre dos momentos (por ejemplo, snapshots diarios), señalando caídas bruscas. Es menos preciso, pero mejor que nada.

Paso 3 — Correlacionar las señales

La fuerza del método está en juntar el login anómalo con el movimiento anómalo. Una query que combina "IP nueva en las últimas 24h" con "vaciado del baúl en la misma ventana" produce una lista corta y de alta confianza para inspección manual:

-- Sospechas fuertes: IP nueva + vaciado del baúl en la misma sesión
WITH LoginsNovos AS (
    SELECT l.AccountID, l.IP, l.LoginDate
    FROM LoginLog l
    WHERE l.LoginDate >= DATEADD(HOUR, -24, GETDATE())
      AND l.Result = 'success'
      AND NOT EXISTS (
            SELECT 1 FROM LoginLog h
            WHERE h.AccountID = l.AccountID AND h.IP = l.IP
              AND h.LoginDate < DATEADD(HOUR, -24, GETDATE()))
)
SELECT n.AccountID, n.IP, n.LoginDate, COUNT(w.AccountID) AS ItensRetirados
FROM LoginsNovos n
JOIN WarehouseLog w
  ON w.AccountID = n.AccountID
 AND w.Direction = 'out'
 AND w.MoveDate BETWEEN n.LoginDate AND DATEADD(MINUTE, 15, n.LoginDate)
GROUP BY n.AccountID, n.IP, n.LoginDate
HAVING COUNT(w.AccountID) >= 5
ORDER BY ItensRetirados DESC;
GO

Programa esa consulta (SQL Server Agent, cada 15–30 minutos) para recibir alertas casi en tiempo real. Es la diferencia entre revertir un robo y solo lamentarlo.

Paso 4 — Responder sin destruir evidencias

Al confirmar una sospecha fuerte, el orden de las acciones importa:

1. Congela la cuenta invadida (bloquea el login sin banear). En MuServer esto suele hacerse alterando el estado de bloqueo de la cuenta:

``sql -- Bloquear el login sin borrar nada (el nombre de columna varía según la distribución) UPDATE MEMB_INFO SET bloc_code = 1 WHERE memb___id = 'contaVitima'; GO ``

1. Congela también la cuenta destino ("muleta") para impedir que los ítems sigan adelante.
2. Preserva los logs: exporta las filas relevantes de LoginLog, TradeLog y WarehouseLog a una tabla o archivo de caso. No confíes en que se queden en la base de datos: los logs rotan.
3. Reconstruye la línea de tiempo: primer login sospechoso, ítems que salieron, hacia dónde fueron.
4. Revierte con base en el backup y en los logs, devolviendo los ítems a la víctima y quitándolos de la cuenta muleta. Hazlo en una transacción y documenta.
5. Contacta al dueño legítimo por un canal verificado, orientándolo a cambiar la contraseña y (si existe) activar el segundo factor/PIN de baúl.
6. Solo entonces decide sobre el baneo de la cuenta destino, si queda comprobado que fue creada para el robo.

> Nunca empieces por el baneo. Banear borra rastros, puede castigar al dueño legítimo cuya cuenta fue usada, y cierra la puerta a la reversión limpia. Congelar preserva todo y es reversible.

Paso 5 — Cerrar con prevención

La detección es la última línea; reducir el volumen de casos viene de la prevención:

• Contraseñas fuertes y hash adecuado: nunca almacenes la contraseña en texto plano. Fuerza longitud mínima y complejidad en el registro.
• Segundo factor o PIN de baúl/trade: una traba extra sobre el warehouse impide el vaciado incluso con la contraseña filtrada.
• Límite de sesiones simultáneas por cuenta y, si es posible, alerta al iniciar sesión desde una IP nueva.
• Anti-fuerza-bruta: bloqueo temporal tras N fallos de login por cuenta/IP.
• Educación de la comunidad: la mayoría de las filtraciones vienen de phishing y sitios falsos de "recarga". Avisa a los jugadores.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Logs de login (cuenta, IP, fecha, resultado) activados y retenidos
• Log de movimiento de ítems/zen (warehouse, trade) activado o instalado
• Backup reciente disponible para la reversión de ítems/zen
• Query de login desde IP nueva probada contra datos reales
• Query de fuerza bruta (fallos antes del éxito) validada
• Query de cuentas "muleta" (muchos orígenes) validada
• Query correlacionada (login nuevo + vaciado) programada cada 15–30 min
• Flujo de respuesta documentado (congelar → preservar → revertir → decidir)
• Comando de congelamiento (bloc_code o equivalente) probado y reversible
• Prevención reforzada (contraseña fuerte, PIN de baúl, límite de sesión, anti-fuerza-bruta)
• Canal verificado para contactar a los dueños legítimos definido

Preguntas frecuentes