Honeypots Emerge as Critical Defense Layer After Successfully Deceiving Pro-Russian Hacktivists
The cybersecurity community scored an unconventional victory last month when Forescout researchers successfully lured the TwoNet pro-Russian hacktivist group into attacking a fake water treatment facility. This incident, publicly disclosed October 9, 2025, marks a pivotal moment in operational technology defense strategy - highlighting how deception technology may be evolving from a nice-to-have to a necessity in critical infrastructure protection.
The Anatomy of a Successful Deception
The TwoNet operation revealed both the sophistication and limitations of current hacktivist capabilities. The group gained initial access at 08:22 AM using the credentials admin/admin - a sobering reminder that even politically motivated threat actors still reach for low-hanging fruit first. Over the subsequent 26 hours, they executed what appeared to be a textbook ICS attack: exploiting CVE-2021-26829 for cross-site scripting, enumerating databases, defacing HMI login screens, disabling real-time updates, removing PLCs from data sources, and manipulating setpoints.
From TwoNet's perspective, they had successfully compromised critical water infrastructure. In reality, they had revealed their entire playbook to security researchers while causing zero actual damage.
Building Your Own Deception: The ConPot Framework
The success of operations like Forescout's raises an obvious question: how can organizations implement similar deception capabilities? Enter ConPot, an open-source ICS/SCADA honeypot framework that's democratizing access to OT deception technology.
ConPot, maintained by the Honeynet Project, simulates multiple industrial protocols including:
- Modbus TCP (the exact protocol targeted by TwoNet)
- S7comm (Siemens S7 communication)
- BACnet (building automation)
- SNMP (network management)
- Guardian AST (tank monitoring)
- IEC 60870-5-104 (electric power systems)
Setting up a basic ConPot instance requires minimal resources:
Within minutes, you have a functioning honeypot presenting realistic industrial control interfaces. However, the default templates are well-known to sophisticated attackers. The real work lies in customization.
Making Deception Believable
The Forescout honeypot succeeded because TwoNet believed they were attacking real infrastructure. This authenticity doesn't happen by accident. Based on the 26-hour attack timeline, we can infer several critical customizations:
Realistic Response Times: OT systems don't respond instantly. Adding 50-200ms delays to Modbus responses mimics real PLC behavior under load.
Correlated Data Points: Water treatment facilities have interconnected processes. If tank levels rise, pressure should change accordingly. ConPot allows scripting these relationships through its template system.
Imperfect Operations: Real systems have noise. Temperature readings that are perfectly stable or that change in exact increments immediately signal a honeypot. Adding gaussian noise to sensor values increases authenticity.
Authentic Naming Conventions: Instead of default ConPot identifiers, use realistic tag names like "TANK001LEVEL" or "CHLORINEPUMPSTATUS" that match actual industrial naming patterns.
Why Honeypots Are Becoming Essential
The success of this operation exposes an uncomfortable truth about OT security: our traditional defenses are failing to stop even moderately sophisticated attacks. When hacktivists using default credentials can operate undetected for over 24 hours, it suggests that many real facilities would fare no better.
This creates a compelling case for honeypots as a compensating control. Consider what Forescout's honeypot achieved:
- Intelligence Collection: The researchers captured detailed TTPs, timeline data, and tool usage that would be impossible to obtain from a real breach where the priority is containment and recovery.
- Resource Diversion: Every hour TwoNet spent attacking the fake facility was an hour not spent targeting real infrastructure. With limited human resources, even sophisticated groups must choose their targets.
- Attribution Indicators: The controlled environment allowed for better collection of infrastructure data, behavioral patterns, and technical artifacts that aid in attribution.
- Early Warning: The honeypot served as a canary, alerting the community to evolving hacktivist capabilities before they could be deployed against real targets.
Community Defense Through Shared Deception
The Iranian multi-protocol campaign detected by the same honeypot network illustrates another advantage: distributed deception creates community-wide visibility. Organizations running ConPot instances can contribute to collective defense by sharing attack data.
The Modern Honey Network (MHN) project enables this collaboration, allowing multiple ConPot instances to report to a central collector. Imagine if every water utility ran a single honeypot alongside their real systems - we'd have real-time visibility into targeting patterns across the entire sector.
Several organizations are already pioneering this approach:
- GridPot extends ConPot specifically for electric grid simulation
- GasPot simulates oil and gas systems
- The Honeynet Project maintains a threat feed from distributed deployments
Deployment Considerations
Running a honeypot isn't without risk. Poor isolation could turn your deception tool into an attacker's pivot point. Critical requirements include:
- Network Segregation: Complete isolation from production networks. VLANs aren't enough - physical separation or properly configured firewalls with deny-all default rules are essential.
- Resource Limits: Honeypots can be targeted for cryptomining or as DDoS amplifiers. CPU and bandwidth limits prevent resource exhaustion.
- Legal Considerations: Depending on jurisdiction, collecting attacker data may have legal implications. Consult with legal counsel before deployment.
- Maintenance Overhead: Honeypots require tuning. Too many successful attacks might indicate it's too easy (and therefore suspicious). Too few might mean it's not discoverable.
The Uncomfortable Truth
Perhaps the most telling aspect of this incident is what it reveals about our current security posture. When our biggest defensive success is tricking attackers into hitting fake targets, it suggests our real systems remain dangerously vulnerable. Honeypots are essentially an admission that we can't prevent intrusions - we can only hope to misdirect them.
This isn't necessarily defeatist; it's realistic. Given the massive installed base of legacy OT systems, many running protocols designed without security considerations, perfect protection is impossible. In this context, honeypots represent a pragmatic approach: accept that some attacks will succeed, but ensure they succeed against systems designed to absorb and analyze them.
Looking Forward
The TwoNet incident likely marks an inflection point. As honeypot success stories proliferate and tools like ConPot mature, we should expect:
- Adversarial Evolution: Sophisticated actors will develop honeypot detection capabilities. ConPot's GitHub repository is public - attackers can study its patterns.
- Improved Deception Technology: The community will develop more sophisticated simulation capabilities, possibly incorporating machine learning to generate realistic operational patterns.
- Standardization: We'll likely see industry-specific honeypot templates emerge, similar to how ConPot already includes templates for different industrial sectors.
The cybersecurity community's celebration of the TwoNet honeypot success is justified, but it should be tempered with recognition of what it implies: we've reached a point where misdirection is more achievable than prevention.
For organizations looking to contribute to collective defense, deploying a ConPot instance is a concrete step forward. Every honeypot adds another sensor to our community-wide detection grid. In a landscape where we can't stop every attack, we can at least ensure some of them reveal their methods while attacking shadows.
🌊