BHICS: Dynamic Honeypots That Adapt to Attackers
The 20-Second Summary
Static honeypots tend to become “known locations”: once attackers fingerprint them (timing, banners, response quirks), they route around them. BHICS flips this by converting ordinary IoT nodes into honeypots only when the threat level warrants it, and logging conversions/events in a tamper-evident way.
The Threat Model
Assume an adaptive attacker who can probe devices to identify decoys and who can share fingerprints with others. If the defender commits to a fixed set of honeypot nodes, the attacker’s strategy eventually becomes “avoid known decoys,” which reduces the value of deception over time.
The fundamental problem: static deception has a shelf life. Once attackers learn your honeypot signatures, they simply avoid them.
Why Existing Approaches Fail
| Approach | Problem |
|---|---|
| Static honeypots | Easily fingerprinted; known signatures are shared |
| High-interaction honeypots | Resource-intensive; can’t scale to IoT |
| Random deployment | Suboptimal resource allocation; may miss attack paths |
| Fixed topologies | Attacker learns network layout over time |
The core issue: defenders commit to configurations while attackers adapt. We need to flip this dynamic.
My Approach: BHICS
BHICS (Blockchain-enabled Honeypot Intrusion Conversion System) has three key innovations:
1. Dynamic Honeypot Conversion
Instead of deploying static decoys, BHICS converts real IoT nodes into honeypots on-the-fly based on detected threat levels:
Normal Operation → Anomaly Detected → Node Converts → Captures Attack → Reverts
Practically, attackers can’t reliably fingerprint “honeypot-only” nodes because the same physical node can switch roles over time. It also lets defenders allocate honeypot resources dynamically based on measured threat signals instead of static deployment.
2. ML-Driven Threat Scoring
We use a trained classifier to score each node’s threat level in real time. The features include traffic volume, connection patterns, and payload characteristics; the output is a probability that the node is under attack; and if the score exceeds a threshold $\tau$, BHICS triggers conversion.
3. Game-Theoretic Deployment
We also model the interaction as a Stackelberg game: the defender chooses a conversion strategy (which nodes, when, and for how long), and the attacker responds optimally to observed behavior. The goal is the defender strategy that maximizes detection given the attacker’s best response.
The blockchain records conversion decisions for auditability and traceability.
What We Measured
We evaluated BHICS in IoT network simulations across different network sizes (100 to 1,000 nodes) and compared against a dedicated-honeypot baseline.
Metrics:
We report attack prevention rate, node compromise rate, blockchain logging latency (transaction time), and scalability across network sizes.
Key Results
The reported results are close to dedicated honeypot deployments while reducing compromise risk: attack prevention is 76.5% (±0.9%) versus 79.6% (±1.0%) for the dedicated-honeypot baseline, node compromise rate drops from 49.8% to 22.3%, and blockchain transaction time is ~15.17 ms (±0.03 ms), remaining stable as network size scales from 100 to 1,000 nodes.
Limitations & What I’d Do Next
Current Limitations:
The ML model needs periodic retraining as attack patterns evolve, very resource-constrained nodes may struggle with conversion overhead, and the game-theoretic framing assumes rational attackers (which may not always hold).
Future Work:
Future work includes federated learning for distributing model updates across networks, reinforcement learning for more adaptive conversion policies, and SDN integration for faster switching.