How to detect multi-accounting and multi-account abuse on your MU Online server

Well-managed multi-accounting is just a player with two casual accounts; abused multi-accounting is an army of bots or ghost accounts monopolizing rare drops, event slots, and rankings — and that erodes community trust faster than almost any other gameplay problem. Detecting this abuse requires cross-referencing technical data (IP, HWID, connection timing) with in-game behavior patterns (trading, movement, event participation). This tutorial shows how to build that investigation from scratch, with practical queries against the account database and objective criteria for telling coincidence apart from fraud.

Why multi-accounting becomes a problem

The damage from abusive multi-accounting shows up on three fronts. In the economy, a single player controlling 5 accounts can monopolize rare-drop bosses, resell to themselves (self-trade) to launder Zen, or artificially inflate prices by hoarding stock. In events, extra accounts occupy limited slots (Devil Square, Chaos Castle, Battle Soccer), taking chances away from real players and skewing the reward rankings. In the community, once the abuse becomes publicly known, legitimate players feel the effort isn't worth it and migrate to another server — the metric that hurts an administrator the most.

Technical signals for correlating accounts

Three data sources form the foundation of any investigation:

No single signal is definitive proof. The correct approach is to accumulate points: an account sharing IP and HWID and showing a login pattern synchronized with another has strong correlation; one that only shares IP has weak correlation.

Collecting IP and HWID at login

Most MU emulators (MuEMU, IGCN, X-Team) already log the connection IP in the account table or an access log — typically AccountCharacter, MEMB_STAT, or a dedicated audit table. HWID usually requires an agent on the client or launcher that sends a hardware hash during the handshake; if your emulator doesn't collect this natively, it's worth integrating a third-party launcher with this feature before investing time in manual detection.

-- Example of a typical access table (names vary by emulator)
SELECT AccountID, LastIP, HWID, LastLoginDate
FROM MEMB_STAT
WHERE LastIP = '203.0.113.45';

IP correlation query

To pull all accounts sharing an IP over the last 30 days:

SELECT LastIP, COUNT(DISTINCT AccountID) AS Accounts, GROUP_CONCAT(AccountID) AS List
FROM MEMB_STAT
WHERE LastLoginDate >= DATEADD(day, -30, GETDATE())
GROUP BY LastIP
HAVING COUNT(DISTINCT AccountID) >= 3
ORDER BY Accounts DESC;

This result is a starting point, not a conclusion. IPs with 3+ accounts in large cities or on mobile networks are common and usually legitimate; the signal gets strong when the same group of accounts also shows up in the HWID query below.

HWID correlation query

SELECT HWID, COUNT(DISTINCT AccountID) AS Accounts, GROUP_CONCAT(AccountID) AS List
FROM MEMB_STAT
WHERE HWID IS NOT NULL AND HWID <> ''
GROUP BY HWID
HAVING COUNT(DISTINCT AccountID) >= 2
ORDER BY Accounts DESC;

Cross-referencing this result with the previous one (same IP and same HWID) already eliminates most shared-network false positives and points to accounts almost certainly controlled by the same person.

Behavioral patterns that confirm abuse

After the technical correlation, validate with in-game behavior:

• Synchronized login: multiple accounts entering and leaving within a window of a few seconds, repeatedly, indicates a single operator switching between clients or using automated multi-clienting.
• Self-trade: item or Zen transfers between correlated accounts with no market counterpart (price far below or above fair value).
• Impossible simultaneous participation: two accounts from the same group in events with a character-per-account/IP limit happening at the same time, when the event should block this.
• Mirrored movement: characters from different accounts following the same farming route, at the same time, day after day — typical of multi-client botting.

Useful tools and logs on the server side

Beyond the account tables, it's worth auditing:

Datacenter/VPN/proxy IPs deserve extra scrutiny: a legitimate player rarely plays MU behind a commercial VPS, so this signal alone already raises suspicion even without multiple accounts.

Telling apart a LAN house, a family, and real abuse

Before punishing, ask: do the accounts play at times incompatible with a single person (two characters simultaneously active in manual farming, requiring attention)? Is there payment/IP history across different cities over time? Is there a clear economic benefit (rare items concentrated, laundered Zen)? Families and LAN houses tend to have non-overlapping usage hours and no self-trade pattern; the multi-account abuser almost always has both.

Setting account limits per event

Prevention is cheaper than investigation. Configure technical limits directly on the event:

• One character per IP in individual-reward events (Blood Castle, Devil Square).
• Entry cooldown tied to HWID, not just the account, for events with rare prizes.
• Purchase limit in the event shop per HWID/IP, preventing one person from emptying stock with 5 accounts.

These limits drastically reduce the volume of manual investigation needed afterward.

Escalated punishment policy

A clear policy prevents accusations of arbitrariness and protects the moderation team:

Document every case with screenshots of the queries and logs — this protects the team if the player publicly contests the punishment.

Communicating the punishment without generating distrust

Avoid disclosing the exact technical details of how detection works (that teaches the next abuser how to escape). When announcing a mass punishment, use generic language ("improper use of multiple accounts identified through connection and behavior analysis") and, when possible, show aggregated numbers (how many accounts, which event) to reinforce transparency without exposing the method.

Common errors and fixes

Multi-account investigation checklist

• IP correlation query run over the last 30 days.
• HWID correlation query cross-referenced with the IP one.
• Trade/auction logs reviewed for self-trade between suspicious accounts.
• Event participation logs checked for impossible simultaneity.
• LAN house/family context ruled out before concluding abuse.
• Escalated punishment policy documented and applied consistently.
• Technical IP/HWID limits configured on higher-risk events.

Once multi-account detection is stabilized, the natural next step is reviewing your server's overall anti-cheat and event configuration to reduce the abuse surface at the root — see the MU Online server creation tutorial to review your environment's baseline configuration.

Frequently asked questions