Back to Articles

FaPro: Building Entire Fake Networks with a Single Binary

[ View on GitHub ]

FaPro: Building Entire Fake Networks with a Single Binary

Hook

Most honeypots just display a fake SSH banner and log connection attempts. FaPro can simulate an entire /24 subnet with dozens of hosts running authentic-looking services that respond to commands, execute fake SQL queries, and even render RDP desktop screens—all from a single binary without spawning actual server processes.

Context

Traditional honeypots fall into two camps: high-interaction systems that run real services in sandboxed environments (resource-intensive, complex to manage, genuine attack surface) or low-interaction decoys that simply open ports and log connections (trivially fingerprinted by sophisticated attackers). Security teams deploying deception infrastructure face a painful tradeoff: deploy heavyweight VMs running actual vulnerable software to catch advanced threats, or scatter lightweight port listeners that only fool the most basic scanners.

FaPro emerged from the FOFA team (creators of a popular internet asset search engine) to solve this middle-ground problem. They needed something that could simulate realistic protocol interactions without the operational overhead of managing actual service instances, while being sophisticated enough to fool automated reconnaissance tools and even semi-skilled attackers. The result is a honeypot that handles authentication flows, processes protocol-specific commands, and generates contextually appropriate responses across dozens of protocols—SSH terminals that accept commands, MySQL servers that parse queries, SMTP relays that process email headers—all without running the actual services.

Technical Insight

FaPro's architecture centers on two operational modes that fundamentally change how it interacts with the network. In local machine mode, it binds protocol handlers to specific ports on localhost, operating like a traditional multi-service honeypot. The more interesting capability is virtual network mode, where FaPro uses raw packet manipulation to simulate an entire subnet of hosts. Rather than binding to ports, it captures traffic at the packet level and crafts responses as if multiple machines exist on the network.

The protocol handler system is where FaPro differentiates itself from simple port simulators. Each handler implements state-aware interaction logic rather than just banner responses. Here's what a basic FaPro configuration looks like for simulating multiple services:

{
  "version": "0.45",
  "network": "127.0.0.1/32",
  "network_build": "localhost",
  "storage": null,
  "geo_db": "/tmp/geoip_city.mmdb",
  "hostname": "fapro-deployed",
  "use_logq": true,
  "cert_name": "fapro.com",
  "syn_dev": "any",
  "udp_dev": "any",
  "icmp_dev": "any",
  "exclusions": ["192.168.66.1"],
  "hosts": [
    {
      "ip": "127.0.0.1",
      "handlers": [
        {
          "handler": "ssh",
          "port": 22,
          "params": {
            "prompt": "$ ",
            "server_version": "SSH-2.0-OpenSSH_7.4"
          }
        },
        {
          "handler": "mysql",
          "port": 3306,
          "params": {
            "server_version": "5.7.40-log",
            "auth_plugin": "mysql_native_password"
          }
        }
      ]
    }
  ]
}

What makes this configuration powerful is what happens behind the scenes. When an attacker connects to the fake SSH server, FaPro doesn't just send a version banner—it handles the full SSH handshake, processes authentication attempts (always failing with realistic timing delays), and if configured, presents a fake shell that accepts commands. Type ls and you'll see a fake directory listing. Execute uname -a and you'll get a pre-configured system response.

The MySQL handler goes even further. It parses actual SQL queries and returns fake result sets. Connect with a MySQL client, send SHOW DATABASES, and you'll receive a list of fake databases. Query a table and FaPro generates randomized but structurally correct result sets. This level of interaction defeats reconnaissance tools that probe beyond the initial connection to determine if a service is genuine.

For virtual network deployments, FaPro operates at the packet level using libraries like gopacket. When configured with "network_build": "raw", it captures SYN packets destined for any IP in the configured subnet and crafts SYN-ACK responses as if multiple hosts exist. An attacker scanning 192.168.1.0/24 might discover hosts at .10, .15, .23, each responding to different service probes. FaPro manages connection state in memory, tracking TCP sequences and responding appropriately to the three-way handshake for dozens of simultaneous "hosts".

The logging pipeline deserves attention for production deployments. FaPro implements a message queue system (use_logq: true) that buffers events before writing to storage backends. Without this, high-volume scanning can overwhelm SQLite or even network-attached databases, causing log loss. The queue decouples event capture from storage writes, essential when your honeypot gets hammered by internet-wide scanners. Storage options include local SQLite for small deployments, MySQL for centralized logging, or Elasticsearch for teams wanting to aggregate honeypot data across multiple instances and build Kibana dashboards.

One sophisticated feature is JA3 fingerprint support for SSL/TLS connections. Attackers can fingerprint honeypots by analyzing SSL handshake characteristics—cipher suites, extensions, elliptic curves. FaPro allows you to specify JA3 fingerprints to mimic specific software implementations, making the TLS handshake look like it's coming from a real Apache server, nginx instance, or Windows IIS rather than a generic Go TLS library.

Gotcha

Virtual network mode sounds powerful until you hit the deployment constraints. On Windows, you need WinPcap or Npcap installed for raw packet capture, and these drivers have a history of conflicting with VPN software, corporate network tools, and other packet-capture utilities. In cloud environments, you'll struggle entirely—AWS, GCP, and Azure don't typically allow the promiscuous mode and raw packet injection required for virtual subnet simulation. FaPro works best on bare metal or dedicated virtual servers where you control the network stack. If you're deploying on containerized infrastructure or serverless platforms, you're limited to local machine mode, losing the compelling "simulate an entire subnet" capability.

The protocol coverage, while broad, varies wildly in depth. SSH and MySQL handlers support genuine interaction with command processing and query parsing. But protocols like Oracle TNS, BACnet, and COAP explicitly only support basic nmap fingerprint spoofing. An attacker who knows Oracle databases well will quickly realize your TNS listener doesn't behave like a real instance once they move past initial probes. The documentation doesn't always clarify which protocols support deep interaction versus basic banner simulation, so you'll need to test your specific use case. Additionally, the website cloning feature—useful for creating fake HTTP admin interfaces—requires a full Chrome/ChromeDriver installation. This adds hundreds of megabytes to your deployment and introduces maintenance overhead when Chrome updates break ChromeDriver compatibility.

Verdict

Use if: You're building threat intelligence infrastructure and need to simulate diverse network environments without deploying actual vulnerable services. FaPro excels for security teams running distributed honeypots who want realistic protocol interactions that defeat basic fingerprinting, or for researchers studying attacker behavior across multiple service types. The single-binary deployment and support for log aggregation make it viable for production-scale deception networks. It's particularly valuable if you have bare-metal or dedicated VM infrastructure where virtual network mode can shine. Skip if: You need deep emulation of a single protocol (dedicated honeypots like Cowrie for SSH will outperform), you're deploying exclusively in cloud/container environments where packet-level manipulation is restricted, or you lack infrastructure for centralized logging and analysis. The tool generates substantial event data that becomes useless without proper aggregation and querying capabilities. Also skip if your threat model doesn't justify the setup complexity—simple port monitoring or cloud-native honeypot services may suffice for basic attack detection.

// ADD TO YOUR README
[![Featured on Starlog](https://starlog.is/api/badge/ai-agents/fofapro-fapro.svg)](https://starlog.is/api/badge-click/ai-agents/fofapro-fapro)