Database

Synopsis

Creates a decoy database server that emulates the MySQL, PostgreSQL, or SQL Server wire protocol far enough to complete an authentication handshake and capture the client's credentials, without exposing a real database. This is distinct from the SQL database collectors documented under Devices > Databases, which poll a real MySQL, PostgreSQL, Oracle, or SQL Server instance for records — this device impersonates one instead.

Schema

- id: <numeric>
  name: <string>
  description: <string>
  type: database
  tags: <string[]>
  pipelines: <pipeline[]>
  status: <boolean>
  properties:
    address: <string>
    port: <numeric>
    mode: <string>
    server_version: <string>
    timeout: <numeric>

Configuration

The following fields are used to define the device:

Device

Field	Required	Default	Description
id	Y		Unique identifier
name	Y		Device name
description	N	-	Optional description
type	Y		Must be database
tags	N	-	Optional tags
pipelines	N	-	Optional pre-processor pipelines
status	N	true	Enable/disable the device

Connection

Field	Required	Default	Description
address	N	"0.0.0.0"	Listen address
port	Y		Listen port
timeout	N	20	Deadline in seconds for each connection, set once when the client connects. Activity does not extend it, so a session is closed this long after it opened

Emulation

Field	Required	Default	Description
mode	N	"mysql"	Wire protocol to emulate
server_version	N	-	MySQL version banner sent in the handshake. mysql mode only

warning

An unrecognized mode value silently falls back to mysql, with no error and no log entry. A typo yields a MySQL honeypot rather than a failure.

mode accepts the following values:

Value	Aliases
mysql	-
postgres	postgresql, pg
mssql	sqlserver, tds

server_version applies to mysql mode only and is ignored by postgres and mssql. An empty server_version yields 8.0.36. The examples below use the default port for each emulated engine — 3306 for MySQL, 5432 for PostgreSQL, 1433 for SQL Server.

Ingest Buffer

Field	Required	Default	Description
max_buffer_size	N	128MB	Ingest buffer admission cap. Also sizes this listener's ingest buffers: 3/8 of this value at start, growing to at most 3x

note

max_buffer_size is the ingest-buffer admission cap, and is distinct from any buffer_size field above, which sizes the network read buffer. Left unset it is 128MB, whose buffers take 48 MiB of heap per listener worker at start and grow to at most 384 MiB as bursts need the room — and with reuse: true a device runs one worker per listener. Size strings are binary, and 32MB and 32MiB are exact synonyms.

See Listener Memory Sizing for the arithmetic, the sizing table, and what happens when the cap is exhausted.

Details

Emulated Protocols

mode	Behavior
mysql	Sends a HandshakeV10 advertising the version banner, mysql_native_password, and a random 20-byte scramble. Reads the client's HandshakeResponse41, captures the username and scramble response, then replies with error 1045, SQLSTATE 28000, "Access denied"
postgres	Answers any SSLRequest or GSSENCRequest with N so the password stays in cleartext, sends AuthenticationCleartextPassword, captures the PasswordMessage and the requested database name, then returns an ErrorResponse of FATAL / 28P01
mssql	Answers PRELOGIN with ENCRYPTION=NOT_SUP, parses the client's LOGIN7 packet, de-obfuscates the password with a nibble swap XOR 0xA5, then closes the connection

In mysql mode, the captured hash is the crackable artifact. In postgres and mssql mode, the password is captured directly in cleartext.

Logged Events

Each connection generates one or both of the following event types:

event_type	Emitted when
connection	A client connects and the protocol handshake begins
auth_attempt	The client submits credentials

Event Fields

Every event carries timestamp, event_type, source_ip, source_port, and local_addr. The remaining fields depend on the event type:

Field	Description
mode	Emulated protocol for the connection
username	Username submitted in the attempt
password	Password submitted in the attempt, in cleartext. postgres and mssql only
database	Database name requested by the client. postgres only
hash	Crackable hash assembled from the handshake. mysql only
auth_method	Authentication method used: mysql_native_password, cleartext, or sql

Captured Hashes

In mysql mode, hash is formatted as $mysqlna$<scramble>*<response>, directly usable with hashcat mode -m 11200. In postgres and mssql mode there is no hash — the password is captured in cleartext directly.

Examples

The following are commonly used configuration types.

MySQL

Creating a MySQL protocol honeypot on the standard port...

devices: - id: 1 name: mysql_honeypot type: database properties: port: 3306 mode: mysql

PostgreSQL

Creating a PostgreSQL protocol honeypot on the standard port...

devices: - id: 2 name: postgres_honeypot type: database properties: port: 5432 mode: postgres

SQL Server

Creating a SQL Server protocol honeypot on the standard port...

devices: - id: 3 name: mssql_honeypot type: database properties: port: 1433 mode: mssql

With Pre-Processing

Routing captured attempts through a pre-processing pipeline before ingestion...	devices: - id: 4 name: mysql_preprocessed type: database pipelines: - decoy-honeypot-enrich properties: port: 3306 mode: mysql
A MySQL login attempt is logged with the crackable hash...	{ "timestamp": "2026-08-03T09:14:22.481937204Z", "event_type": "auth_attempt", "source_ip": "203.0.113.44", "source_port": "51422", "local_addr": "10.0.4.12:3306", "mode": "mysql", "username": "root", "auth_method": "mysql_native_password", "hash": "$mysqlna$3af1c9e0d4b27a68f5e13c0a9d2b7614*8b1e4a7c2f905d3e6a1c48b0f2e9d735c1a04f92" }