How to implement a honeypot against login bots on your MU Online server

Mass account-creation bots and login brute-force scripts are a constant headache for MU Online private server administrators: they inflate fake registration numbers, try to guess passwords for valuable accounts, and, on servers with first-login reward systems, exploit that kind of benefit at scale. A honeypot is a discreet trap — a field, endpoint, or behavior that only an automated script would interact with, never a real human — that lets you identify and block these bots without hurting the experience of legitimate players. This tutorial details how to implement honeypots both on the registration site and on your emulator's ConnectServer, with practical code and configuration examples.

What a honeypot is and why it works

The honeypot's logic is simple: you create "bait" that is technically present on the page or in the protocol, but invisible or irrelevant to a normal human user. Bots that analyze HTML/DOM automatically, or that send network packets generically without replicating a real client's exact behavior, end up interacting with that bait — filling in a field they should ignore, or hitting an endpoint no human would access directly. Unlike a CAPTCHA, a honeypot requires no extra action from the real user, making it practically invisible to the legitimate experience.

Honeypot on the site's registration form

The simplest and most widely used implementation for any site with a form is the invisible field. Add an input field to the registration form, hidden via CSS (never via type="hidden", which some bots already ignore by default), and reject any submission where that field comes in filled.

<style>
  .hp-field { position: absolute; left: -9999px; top: -9999px; }
</style>

<form method="POST" action="/register">
  <input type="text" name="username" placeholder="Username">
  <input type="password" name="password" placeholder="Password">
  <input type="email" name="email" placeholder="Email">

  <!-- Honeypot field: invisible to humans, visible to bots that read the DOM -->
  <input type="text" name="website" class="hp-field" tabindex="-1" autocomplete="off">

  <button type="submit">Create account</button>
</form>

<?php
if (!empty($_POST['website'])) {
    // Honeypot field filled in = bot. Reject silently.
    http_response_code(200); // fake success so the bot isn't tipped off
    exit;
}
// continue the normal registration flow for legitimate submissions

Note the detail of responding with a fake success (200) instead of an explicit error — this keeps the bot operator from adjusting the script upon seeing immediate rejection, keeping the trap effective for longer.

Fill-time honeypot

Complementing the invisible field, measure the time between the form loading and being submitted. Bots frequently submit forms in under 1-2 seconds, which is impossible for a human to read the fields and type username, password, and email.

<?php
session_start();
if (!isset($_SESSION['form_loaded_at'])) {
    $_SESSION['form_loaded_at'] = time();
}

// In the POST handler:
$elapsed_time = time() - $_SESSION['form_loaded_at'];
if ($elapsed_time < 3) {
    // Submission too fast to be human
    http_response_code(200);
    exit;
}

Honeypot on the ConnectServer (protocol level)

For bots that attack the ConnectServer directly (login brute force, account creation via protocol without going through the site), the strategy involves monitoring packet patterns that an official client would never produce: out-of-order packet sequences, absence of the expected version handshake, or a volume of login attempts from the same IP in an interval impossible for human typing. Most emulators (IGCN, MuEMU) already expose login attempt logs in their own table; the query below identifies suspicious patterns.

SELECT IP, COUNT(*) AS attempts, MIN(LoginTime) AS first_attempt, MAX(LoginTime) AS last_attempt
FROM LoginAttemptLog
WHERE LoginTime > DATEADD(minute, -10, GETDATE())
GROUP BY IP
HAVING COUNT(*) > 15
ORDER BY attempts DESC;

IPs with dozens of attempts within a few minutes, especially against sequential or nonexistent usernames, indicate brute force or an automated scanner, and can be added to a temporary blacklist on the firewall or on the ConnectServer itself.

Table of honeypot types and where to apply them

Bait endpoint on the site (fake route)

In addition to the form, create a route that is never linked anywhere visible on the site (for example /wp-login.php or /admin-old), but that automated scanners default to trying when scanning any domain. Any access to this route is, by definition, automated — no human browsing normally would ever land there. Log the accessing IP and add it to an automatic blocklist.

Monitored bait account in the database

A more advanced technique is creating a "bait" account with credentials never publicly disclosed and never used by staff, but present in the database like any real account. If this specific account experiences a login attempt, it's strong evidence that someone is testing credentials obtained from a leak on another service (password reuse) or from a previous dump of the server itself — a valuable alert to review the database's overall security.

Gradual response: soft block before a permanent ban

To minimize the risk of a false positive hurting a real player, apply layered responses of increasing severity instead of banning on the first detection:

Integrating the honeypot into the admin panel

Centralize honeypot alerts (form, bait endpoint, bait account, protocol) into a single panel or notification channel (a webhook to the staff Discord, for example), so the security team sees the full picture instead of scattered logs. A simple webhook can fire a message every time a honeypot is triggered, including IP, timestamp, and trap type activated, enabling a quick manual response in ambiguous cases automation shouldn't resolve alone.

Common errors and fixes

Honeypot implementation checklist

• Invisible field added to the registration and login form.
• Minimum fill-time check implemented.
• Bait endpoint created with no visible link on the site.
• Monitored bait account registered in the database.
• Login attempt pattern query scheduled on the ConnectServer.
• Gradual response (soft block before ban) configured.
• Alerts centralized in a panel or webhook for the security team.
• No technical implementation detail publicly disclosed.

With the honeypot active, you significantly reduce bot noise in registration and login without sacrificing the experience of real players; to close the loop on your infrastructure's security, also review the MU Online server creation tutorial and confirm that the other protection layers (firewall, anti-DDoS) are aligned with this strategy.

Frequently asked questions