DeceptionShield – Honeypot-as-a-Service for SMBs

One-click, AI-powered honeypot network for SMBs — lures attackers, captures every move live, auto-blocks them at your firewall, and answers your questions in plain English.

Comment

Inspiration

Small and medium businesses are hit by nearly half of all cyberattacks, yet they're the least equipped to defend against them. Enterprise deception technology — the kind that lures attackers into fake systems and studies them in real time — routinely costs $25,000+ a year and requires a dedicated security team to run. SMBs are left with firewalls and hope: reactive tools that tell you about a breach after it already happened, not while it's unfolding. We wanted to know if we could bring that same class of active defense down to something a small business could deploy in one command and actually understand, without hiring an analyst to interpret it.

What it does

DeceptionShield is a Honeypot-as-a-Service platform. It deploys realistic decoy services — an SSH server, a WordPress admin panel, an RDP endpoint — that look exactly like real infrastructure to an attacker but are fully isolated from anything real. The moment someone probes, logs into, or runs a command against a decoy, that event is captured, enriched (GeoIP, IP reputation, MITRE ATT&CK technique mapping), and streamed live to a threat dashboard with a force-directed attack graph and a real-time event feed — no polling, no delay.

When an attacker crosses a configurable threshold (e.g. three failed logins in sixty seconds), DeceptionShield automatically blocks them at the real firewall — via AWS Security Groups or a pfSense REST API — after first checking an allowlist so legitimate traffic never gets caught. Every block is logged with a TTL, the triggering rule, and the exact firewall rule ID, and can be reversed with one click.

The centerpiece is the AI Threat Assistant: a natural-language interface, backed by real retrieval-augmented generation, that lets a non-analyst SMB owner just ask what's happening — "what's hit the RDP decoy in the last hour?" — and get a grounded answer with citations linking straight back to the actual captured events, instead of having to read raw logs.

How we built it

  • Honeypot layer: Cowrie for SSH/Telnet capture (including full TTY session logging), plus custom-built decoys for WordPress admin and RDP, each containerized and isolated on a dedicated Docker network with no route to real infrastructure. A Dionaea-based decoy (SMB/FTP/MySQL) is built and staged for the next deployment phase.
  • Ingestion pipeline: Filebeat ships structured JSON logs from each honeypot into Kafka, decoupling ingestion from the honeypots themselves — since a honeypot is, by design, potentially fully compromised at any time, it never holds credentials to write directly into the core database.
  • Backend: FastAPI + async SQLAlchemy over Postgres with the TimescaleDB and pgvector extensions, so the same database that stores time-series event data also powers vector similarity search for the AI assistant.
  • AI Threat Assistant: hybrid retrieval — a structured SQL filter narrows candidates by IP, honeypot, severity, or time window, then a pgvector cosine-similarity search ranks the filtered set by relevance to the question. The Claude API is given only the retrieved events as grounding context and instructed to cite specific event IDs or say it doesn't know, rather than guess.
  • Response engine: threshold-based rule evaluation with allowlist-checked-first blocking, pushed in parallel to AWS Security Groups and a pfSense REST API.
  • Frontend: React, TypeScript, and TanStack Router/Query, with a live Cytoscape.js threat map, an xterm.js session replay for captured attacker terminal sessions, and a WebSocket layer with exponential-backoff reconnect for the live feed.
  • Infrastructure: Terraform modules for an isolated VPC, ECS Fargate honeypot deployment, and RDS — designed so the same "one-click deploy" story that sells the product is also how it actually ships.

Challenges we ran into

Getting the frontend and backend to agree on a single contract was the hardest integration problem — event schemas, WebSocket message envelopes, and pagination shapes all had to be reconciled field-by-field between a Pydantic backend and a TypeScript frontend built somewhat independently, and a couple of real mismatches (a wrapped vs. unwrapped WebSocket envelope, mismatched stats field names) only surfaced once we actually ran both sides together and diffed the real payloads. We also hit a genuinely funny bug: a Python-boilerplate .gitignore rule (lib/, meant to ignore virtualenv folders) silently swallowed our entire frontend src/lib/ directory from version control, which meant the frontend couldn't even build until we tracked that down. On the AI assistant side, the challenge was keeping it honest — grounding every answer in retrieved events with citations, and having it say "I don't know" instead of hallucinating, took real iteration on the system prompt and retrieval scoping.

Accomplishments that we're proud of

  • A working, end-to-end pipeline: real attack → honeypot → Kafka → enrichment → database → live dashboard, in under two seconds.
  • An AI assistant that doesn't just sound smart — it's backed by real hybrid retrieval and cites the actual events behind every answer.
  • A response engine that treats safety as a first-class concern: allowlist-checked before every block, fully audited, fully reversible.
  • 71/71 backend unit and integration tests passing, covering the MITRE ATT&CK mapper, log normalizer, response-engine allowlist logic, and the AI assistant's retrieval pipeline.

What we learned

Building "enterprise-grade" security tooling at hackathon speed forces real trade-offs between scope and honesty about scope — we'd rather ship three honeypot types that genuinely work end-to-end than claim five that don't. We also learned a lot about the specific discipline RAG systems need to be trustworthy for a security use case: retrieval quality and citation grounding matter more than model size when the answer might inform a real firewall action.

What's next

Deploying the Dionaea-based decoy (SMB/FTP/MySQL) alongside the current three, multi-region honeypot fleets with automatic IP rotation to stay ahead of attacker fingerprinting, an anonymized threat-intel sharing network across DeceptionShield deployments, a fully managed SaaS tier for SMBs with no DevOps team at all, and sandboxed detonation of any malware payloads dropped on the decoys, feeding results straight back into the AI assistant.

Built With

Share this project:

Updates

Submission history