5 min read · mysql · dns · deployment
How to test a MySQL dump honeytoken
The tripwire is DNS on SOURCE_HOST, not a MySQL listener on 3306. openssl/nc can alert via resolve. Import or dig match the real path.
A MySQL dump honeytoken is a .sql file that looks like a backup. Buried in it is CHANGE REPLICATION SOURCE TO with SOURCE_HOST set to a unique callback hostname from your dashboard. When anything resolves that hostname, you get an alert. HorasEye is not offering a real replica listener on port 3306.
The download buttons on the token page are the dump files. Obfuscated wraps the replication SQL in BASE64 so a casual grep misses the host. Full dump adds fake tables around the same block. Snippet is the plain SQL to paste into a backup you already have. Do not copy /api/tokens/.../download paths into a browser or into mysql. Those are internal download links, not something you SOURCE.
The snippet builds the CHANGE REPLICATION SOURCE TO statement with CONCAT and two server variables: @@lc_time_names (locale, often en_US) and @@hostname (the box that imported the dump). That is intentional. On import, those values get glued onto SOURCE_USER. It is not an incomplete script.
SOURCE_USER is a generated replica account, often the same unique id as the left label of SOURCE_HOST. That is fine. Real dumps rarely use root for replication (repl is more typical). Do not change SOURCE_HOST. That unique hostname is the tripwire. Changing it to something pretty will break detection.
Quick test: on the token page, click Send test probe, or run the dig command shown there. Then open Trigger History. A healthy callback answers 127.0.0.1. That loopback address is expected. It is not a MySQL endpoint you log into.
Realistic attacker path: someone steals the dump, imports it or configures replication against SOURCE_HOST. MySQL (or their tooling) resolves that hostname. That lookup is the alert. Then the replica TCP/handshake fails because nothing is serving MySQL protocol for this token. That failure after the DNS hit is expected. On a throwaway MySQL 8+ instance: create a disposable DB, then mysql -u root -p throwaway_db < backup.sql. Here -u root is only your login to import the file; SOURCE_USER inside the dump is a generated replica account (not root) used for the outbound replica attempt. Do not import into production.
About openssl, nc, telnet, or nmap against host:3306: those tools usually resolve the hostname first, then open TCP. The resolve step is enough to fire HorasEye. So if openssl s_client -connect your-callback:3306 produced an alert, that is real, but it proved DNS, not “MySQL on 3306 answered.” HorasEye does not listen on 3306 for this token. A successful-looking TCP connect often means you hit whatever 127.0.0.1:3306 is on your own laptop (local MySQL), which is unrelated to the honeytoken.
Prefer dig (or Send test probe) when you only want to confirm the callback. Prefer the throwaway import when you want the same sequence an attacker following the dump would take. Treat port-3306 probes as an optional DNS side effect, not as the intended product test.
MariaDB still uses CHANGE MASTER TO / START SLAVE in some versions. HorasEye dumps use MySQL 8 syntax (CHANGE REPLICATION SOURCE TO / START REPLICA). Import on MySQL 8+ if you want the realistic path.
Do not paste live SOURCE_HOST values or dump files into a public thread. Say “MySQL dump, dig worked” or “import stayed silent.” If import is silent, the statements never ran (wrong server version, or you only opened the file in an editor).