No. Glutton sits in the low-interaction range: handlers emulate enough protocol behavior to capture useful probes and payloads, but they're controlled Go implementations, not real services or shells.
TCP: SMTP, RDP, SMB, FTP, SIP, RFB/VNC, SPICE, Telnet, MQTT, iSCSI, BitTorrent, Memcache, Jabber, ADB, MongoDB, HTTP, MCP, Modbus, generic TCP, plus proxy_tcp forwarding. UDP: SIP, OpenVPN, mDNS, L2TP, RakNet, Kerberos, CoAP, BitTorrent DHT, proxy_udp forwarding, and a generic UDP catch-all.
The HTTP handler also dispatches a handful of nested, payload-driven mini-handlers once a request is parsed:
- Ethereum JSON-RPC
- Hadoop YARN exploit
- Docker Engine API
- Citrix ADC / NetScaler (CVE-2019-19781)
- VMware "hyper/send" attack (request is captured only; the honeypot never dials the address in the body)
- Wallet probes
These nested branches live inside the HTTP handler rather than being registered as separate handler keys, so they're not selectable via a rule target.
No. Current grammar files are http.spicy and tcp.spicy. Spicy is used for selected HTTP parsing and TCP-payload protocol detection only.
Glutton is built on Linux-only kernel facilities and tooling like TPROXY, iptables and AF_PACKET sockets. On macOS or Windows you can edit the Go code, but the binary will not redirect traffic, manage iptables, or load the Spicy runtime. Use a Linux VM, container, or remote host for anything beyond static analysis.