How to recover a MU Online server after a hack

A successful breach is the worst day in the life of a MU Online server administrator — duplicated items, stolen accounts, a corrupted database, or, worst case, leaked player data. What separates a well-managed incident from a permanent disaster is the speed and order of actions in the first few hours. This tutorial presents an incident response plan adapted to the reality of private servers, covering containment, diagnosis, restoration, and communication.

Recognizing the signs of a breach

Before acting, confirm there really is a breach and not a bug or a legitimate traffic spike. Typical signs include: an abnormal amount of Zen or rare items appearing out of nowhere, admin logins at unusual times and from unusual IPs, player accounts being emptied in sequence, the web panel or GameServer responding erratically, or monitoring tool alerts (CPU/database spiking for no apparent reason).

Step 1 — Contain the attack immediately

The top priority is stopping ongoing damage, not investigating the cause. This usually means:

1. Taking the GameServer and ConnectServer offline immediately.
2. Blocking external access to the web admin panel.
3. If possible, isolating the database from the external network (a temporary firewall rule).
4. Revoking active administrator tokens/sessions on the panel.

Don't skip this step to "investigate first" — every extra minute online with the attacker active means additional damage.

Step 2 — Preserve evidence before any cleanup

Before restoring anything, copy the relevant logs to a secure location outside the compromised server: GameServer logs, MySQL logs (general_log, slow_query_log if enabled), web panel access logs (Apache/Nginx), and operating system logs (auth.log/login events). These files are the only way to identify the attack vector afterward.

mkdir -p /root/incidente_2026-03-14
cp /var/log/mysql/*.log /root/incidente_2026-03-14/
cp /var/log/nginx/access.log /root/incidente_2026-03-14/
cp -r /path/to/gameserver/logs /root/incidente_2026-03-14/

Step 3 — Identify the attack vector

With the logs preserved, cross-reference timestamps. The most common vectors on private MU servers are:

Step 4 — Assess the extent of the damage

Before restoring, understand the scope: how many accounts were affected, which items/Zen were duplicated or stolen, whether any tables were deleted, and whether sensitive data (emails, password hashes) was exfiltrated. A simple query helps map anomalous activity by time:

SELECT memb___id, appl_date, appl_ip
FROM MEMB_INFO
WHERE appl_date BETWEEN '2026-03-14 18:00:00' AND '2026-03-14 23:00:00'
ORDER BY appl_date;

Step 5 — Restore from a clean backup

Identify the most recent backup taken before the confirmed start of the attack — not when you noticed it, which is usually after the actual start. Restore the database to that point and, if safely possible, reapply only the legitimate transactions manually identified between the backup and the incident (confirmed purchases, validated progress). Never restore onto the same compromised server without first reinstalling the operating system, or at least reviewing every binary and configuration for backdoors.

Step 6 — Reset credentials en masse

After restoration, reset: passwords for all administrators and GMs, database access passwords (MySQL root and application users), web panel API keys, and force a password reset for players if there's any indication of hash exfiltration. Announce the forced player password reset in advance with clear instructions on how to reset it.

Step 7 — Fix the root cause before reopening

Reopening the server without fixing the identified vulnerability is the most recurring post-incident mistake — the same attacker comes back within days. Depending on the vector:

• SQL Injection: apply prepared statements in the panel, update or replace the vulnerable CMS.
• Leaked credential: enable 2FA for administrators, review the strong password policy.
• Emulator exploit: apply the community patch or update to the fixed version.
• Weak RDP/SSH: switch to key-based authentication, restrict by IP/VPN, change the default port.

Step 8 — Communicate with the community transparently

Publish a clear announcement on the site and Discord explaining what happened (without exploitable technical details), what was done to contain it, the impact on players (password reset, reverted duplicated items), and the estimated return timeline. Controlled transparency preserves community trust; silence or downplaying breeds distrust and a player exodus.

Ongoing prevention after the incident

Common errors and fixes

Post-breach recovery checklist

• Server taken offline immediately after detection.
• Logs preserved before any cleanup.
• Attack vector identified with evidence.
• Extent of damage mapped (accounts, items, data).
• Clean backup restored in a reviewed environment.
• Admin, database, and panel credentials reset.
• Root cause fixed before reopening to the public.
• Transparent announcement published to the community.

After recovering the server, revisit the fundamentals of secure configuration from the ground up to reduce the chance of a new incident — the MU Online server setup tutorial is a good starting point to reinforce the foundation before reopening to the public.

Frequently asked questions