Como detectar contas comprometidas no MU Online

Contas comprometidas são um dos problemas de segurança mais corrosivos em um servidor de MU Online. Diferente de um ataque DDoS, que é barulhento e imediato, a invasão de conta é silenciosa: o atacante loga com a credencial roubada, esvazia o baú, transfere itens valiosos e zen para uma conta "laranja" e some — muitas vezes antes de o dono legítimo perceber. Quando a denúncia chega, os itens já circularam e a reversão ficou difícil. A defesa eficaz combina prevenção (senhas fortes, segundo fator, limites de sessão) com detecção rápida: enxergar o comportamento anômalo enquanto a janela de reversão ainda está aberta. Este guia foca na detecção, mostrando quais sinais monitorar, como consultá-los no banco e como responder sem destruir evidências.

Os exemplos usam o schema clássico do MuServer (SQL Server, banco MuOnline, tabela MEMB_INFO) e supõem a existência de tabelas de log de login e de movimentação. Nomes de tabela e coluna variam por season/emulador — muitas distribuições não têm log de trade por padrão, e habilitá-lo é o primeiro pré-requisito prático. Adapte cada query ao seu banco.

Por que detecção manual não escala

Esperar a denúncia do jogador é reativo e lento. Quando o ticket chega, três coisas já aconteceram: o item saiu da conta, passou por uma ou mais intermediárias e possivelmente foi negociado. A janela em que você consegue reverter com segurança — antes de o item se misturar à economia — costuma ser de horas. A abordagem correta é monitorar sinais proativamente, com queries agendadas que sinalizam padrões suspeitos, e reservar a inspeção manual para os casos que a automação levantar.

Pré-requisitos

Para detectar de verdade, você precisa de dados. Antes de tudo:

• Logs de login ativos: registro de conta, IP, data/hora e resultado (sucesso/falha) de cada tentativa. Ative no ConnectServer/GameServer da sua distribuição.
• Log de movimentação de itens/zen: warehouse, trade e drop no chão. Nem toda season traz isso — habilite ou instale um módulo/trigger de log.
• Acesso ao SQL Server com permissão de leitura sobre os logs e o banco de jogo.
• Backup recente para permitir reversão de itens/zen quando confirmar uma invasão.
• Servidor estável em produção. Se ainda está montando o ambiente, comece por como criar servidor de MU Online e volte com os logs configurados.
• Política de resposta definida: quem congela, quem investiga, quem comunica o dono.

Os sinais de comprometimento

Nenhum sinal isolado prova invasão — o dono pode ter viajado, trocado de operadora ou vendido itens legitimamente. A confiança vem da correlação. Estes são os indicadores mais fortes:

A regra de ouro: um sinal é ruído, três ou mais juntos são um caso. Um login de IP novo por si só não justifica congelar; um login de IP novo, seguido de esvaziamento de baú e trade em massa para uma conta criada ontem, justifica.

Passo 1 — Detectar logins anômalos

Comece pelos logs de login. A primeira query útil encontra contas que logaram de um IP nunca antes associado a elas nas últimas 24 horas:

-- Logins de IP "novo" (não visto para a conta no histórico anterior) nas ú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

Um segundo padrão clássico é a força bruta: muitas falhas seguidas de um sucesso, na mesma conta e curto intervalo.

-- Contas com muitas falhas antes de um sucesso (possível força bruta)
SELECT AccountID,
       SUM(CASE WHEN Result = 'fail'    THEN 1 ELSE 0 END) AS Falhas,
       SUM(CASE WHEN Result = 'success' THEN 1 ELSE 0 END) AS Sucessos,
       MIN(LoginDate) AS Inicio, MAX(LoginDate) AS Fim
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 Falhas DESC;
GO

Um terceiro sinal é o login geograficamente impossível: a mesma conta logando de IPs muito distantes em poucos minutos. Sem base de geolocalização, você pode aproximar comparando blocos de IP (/16) distintos em janela curta.

Passo 2 — Detectar movimentação anômala de itens e zen

Login suspeito só vira caso quando há dano. Cruze com a movimentação. Se você tem log de trade, a query mais valiosa é a de contas destino que concentram itens de várias origens — o comportamento típico da conta "laranja":

-- Contas que RECEBERAM itens de muitas origens diferentes nas últimas 6h
SELECT t.ToAccount,
       COUNT(DISTINCT t.FromAccount) AS OrigensDistintas,
       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 OrigensDistintas DESC;
GO

E a de contas que esvaziaram o baú logo após o login:

-- Muitos itens saindo do warehouse pouco depois do 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

Se a sua distribuição não tem log de trade/warehouse, a alternativa é comparar instantâneos do zen e da contagem de itens da conta entre dois momentos (por exemplo, snapshots diários), sinalizando quedas bruscas. É menos preciso, mas melhor que nada.

Passo 3 — Correlacionar os sinais

A força do método está em juntar login anômalo com movimentação anômala. Uma query que combina "IP novo nas últimas 24h" com "esvaziamento de baú na mesma janela" produz uma lista curta e de alta confiança para inspeção manual:

-- Suspeitas fortes: IP novo + esvaziamento de baú na mesma sessão
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

Agende essa consulta (SQL Server Agent, a cada 15–30 minutos) para receber alertas quase em tempo real. É a diferença entre reverter um roubo e apenas lamentá-lo.

Passo 4 — Responder sem destruir evidências

Ao confirmar uma suspeita forte, a ordem das ações importa:

1. Congele a conta invadida (bloqueie o login sem banir). No MuServer isso costuma ser feito alterando o status de bloqueio da conta:

``sql -- Bloquear login sem apagar nada (nome de coluna varia por distribuição) UPDATE MEMB_INFO SET bloc_code = 1 WHERE memb___id = 'contaVitima'; GO ``

1. Congele também a conta destino ("laranja") para impedir que os itens sigam adiante.
2. Preserve os logs: exporte as linhas relevantes de LoginLog, TradeLog e WarehouseLog para uma tabela ou arquivo de caso. Não confie que ficarão no banco — logs rotacionam.
3. Reconstrua a linha do tempo: primeiro login suspeito, itens que saíram, para onde foram.
4. Reverta com base no backup e nos logs, devolvendo os itens à vítima e removendo-os da conta laranja. Faça em transação e documente.
5. Contate o dono legítimo por um canal verificado, oriente a trocar a senha e (se houver) ativar segundo fator/PIN de baú.
6. Só então decida sobre banimento da conta destino, se ficar comprovado que foi criada para o roubo.

> Nunca comece pelo banimento. Banir apaga rastros, pode punir o dono legítimo cuja conta foi usada, e fecha a porta para a reversão limpa. Congelar preserva tudo e é reversível.

Passo 5 — Fechar a prevenção

Detecção é a última linha; reduzir o volume de casos vem da prevenção:

• Senhas fortes e hash adequado: nunca armazene senha em texto puro. Force comprimento mínimo e complexidade no registro.
• Segundo fator ou PIN de baú/trade: uma trava extra sobre o warehouse impede o esvaziamento mesmo com a senha vazada.
• Limite de sessões simultâneas por conta e, se possível, alerta ao logar de IP novo.
• Anti-força-bruta: bloqueio temporário após N falhas de login por conta/IP.
• Educação da comunidade: a maioria dos vazamentos vem de phishing e sites falsos de "recarga". Avise os jogadores.

Erros comuns e soluções

Checklist de lançamento

• Logs de login (conta, IP, data, resultado) ativados e retidos
• Log de movimentação de itens/zen (warehouse, trade) ativado ou instalado
• Backup recente disponível para reversão de itens/zen
• Query de login de IP novo testada contra dados reais
• Query de força bruta (falhas antes do sucesso) validada
• Query de contas "laranja" (muitas origens) validada
• Query correlacionada (login novo + esvaziamento) agendada a cada 15–30 min
• Fluxo de resposta documentado (congelar → preservar → reverter → decidir)
• Comando de congelamento (bloc_code ou equivalente) testado e reversível
• Prevenção reforçada (senha forte, PIN de baú, limite de sessão, anti-brute-force)
• Canal verificado para contatar donos legítimos definido

Perguntas frequentes