FakeNet honeypot

Why use FakeNet

Sandbox detection used to be the malware's job. Modern samples reach for the internet within seconds of execution: DNS lookup of a hardcoded C2, HTTP GET of a stage-two payload, HTTPS callback with the victim's fingerprint. If the network is "missing" (DNS NXDOMAIN, no route, no DHCP), the malware sleeps or self-destructs and you learn nothing.

FakeNet solves that. From inside the lab guest, the network looks normal:

• DNS resolves — every name returns the router's IP.
• HTTP returns 200 OK with plausible HTML.
• HTTPS presents a cert (self-signed; depending on sample, this matters or doesn't).
• FTP says hello and lets you list a fake directory.
• SMTP accepts mail.
• IRC accepts JOIN and lets the bot register.

The malware proceeds through its kill chain, and every step is logged.

Prerequisites

• Router VM provisioned per Router VM.
• The lab guests should be in Router-VM network mode and getting their DHCP/DNS from the Kali router.
• Host capture (⌘⇧P) is recommended — you'll want a clean recording of the whole session.

Installing FakeNet

The FakeNet flip is a single script: kali-fakenet-setup.sh in scripts/. It runs on top of the router setup — install Kali router first, then layer FakeNet on it.

1. Mount the Scripts USB (VM Library → right-click router → Mount Scripts USB).
2. From inside the router guest:

   sudo mount /dev/sdb1 /mnt
   cd /mnt
   sudo bash kali-fakenet-setup.sh

3. Restart networking: sudo systemctl restart dnsmasq nginx ssl-redirect.socket

The script installs (or configures, if already present):

• dnsmasq — DNS responder, wildcard A record for everything → 10.0.100.1
• nginx — HTTP listener on :80, HTTPS listener on :443 with a snake-oil cert
• sslsplit — transparent TLS MITM for samples that don't pin certs
• inetsim — fake servers for FTP, SMTP, POP3, IRC, daytime, discard, quotd
• iptables NAT rules to redirect outbound :80 / :443 / etc. back to the router itself, so even hard-coded IP destinations land on FakeNet
• A log directory at /var/log/fakenet/ rotated daily

DNS sinkhole

dnsmasq config flips from "forward upstream" to "answer everything with the router IP":

# /etc/dnsmasq.conf (FakeNet variant)
domain-needed
bogus-priv
no-resolv          # do NOT consult /etc/resolv.conf
address=/#/10.0.100.1   # wildcard: anything → 10.0.100.1
no-hosts           # don't read /etc/hosts

Every A query returns 10.0.100.1. Every AAAA returns nothing (sinkhole). Reverse lookups (PTR) get a synthetic secvf.lab.

Logs at /var/log/fakenet/dns.log:

2026-05-10T14:32:01Z client=10.0.100.42 query=evil-c2.example.com type=A  answer=10.0.100.1
2026-05-10T14:32:01Z client=10.0.100.42 query=evil-c2.example.com type=AAAA answer=(sinkhole)
2026-05-10T14:32:03Z client=10.0.100.42 query=update.example.com type=A   answer=10.0.100.1

Use this log first when triaging a sample — every hostname the malware ever tries to reach is recorded.

HTTP/HTTPS responders

nginx config at /etc/nginx/sites-available/fakenet sets up a default server block that answers everything with a small JSON or HTML response:

server {
    listen 80 default_server;
    listen 443 ssl default_server;
    ssl_certificate     /etc/ssl/fakenet/cert.pem;
    ssl_certificate_key /etc/ssl/fakenet/key.pem;
    server_name _;

    access_log /var/log/fakenet/http.log custom;
    error_log  /var/log/fakenet/http.err warn;

    location / {
        default_type application/octet-stream;
        return 200 'OK';
    }
    # canonical "update" payload that many bots GET
    location ~ ^/(update|payload|stage2|gate\.php)$ {
        return 200 'OK';
    }
}

Logs in /var/log/fakenet/http.log include:

10.0.100.42 - [14:32:04 +0000] "GET /gate.php?id=ABC123&v=1.2 HTTP/1.1" 200 32 "-" "Mozilla/4.0 (compatible)"
10.0.100.42 - [14:32:04 +0000] "POST /upload HTTP/1.1" 200 32 "-" "winhttp/1.0"

TLS interception with sslsplit

nginx serves a self-signed cert — fine for unauthenticated TLS but useless if the malware verifies. For samples that don't pin (the majority), nginx is enough. For those that do pin, you get a TLS error in the malware's logs (and that's still useful information).

For middle-ground samples that check a cert but don't pin to a specific issuer, sslsplit runs in transparent-MITM mode and presents a forged cert with the requested CN. Configuration:

# sslsplit running on the router, transparent mode
sslsplit -c /etc/ssl/fakenet/ca.pem \
         -k /etc/ssl/fakenet/ca.key \
         -l /var/log/fakenet/sslsplit.connect.log \
         -L /var/log/fakenet/sslsplit.content.log \
         https 0.0.0.0 8443

# iptables redirect — outbound :443 from the LAN goes to sslsplit
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-ports 8443

The CA at /etc/ssl/fakenet/ca.pem can be installed in your analysis VMs (/usr/local/share/ca-certificates/ on Debian-flavored) — then sslsplit becomes a clean MITM and you see decrypted plaintext.

Other protocol responders

inetsim runs on the router and answers most other classical protocols. Each listens on its standard port, accepts the conversation, logs everything, and replies with the bare minimum that keeps the client talking.

inetsim's logs at /var/log/fakenet/inetsim/ are one file per protocol; the format is human-readable, easy to grep.

Log layout

/var/log/fakenet/
├── dns.log              # every DNS query + the sinkhole answer
├── http.log             # nginx access log (HTTP + HTTPS)
├── http.err             # nginx errors
├── sslsplit.connect.log # one line per intercepted TLS connection
├── sslsplit.content.log # full plaintext when CA is trusted by guest
├── inetsim/
│   ├── ftp.log
│   ├── smtp.log
│   ├── irc.log
│   └── …
├── iptables-redirects.log
└── archive/             # daily-rotated previous logs (logrotate)

For sharing with a teammate or filing with an analysis: tar -czf fakenet-session-<date>.tar.gz /var/log/fakenet gets you everything.

Analysis workflow

A repeatable FakeNet-based sample triage:

1. Snapshot the lab. Duplicate the malware sandbox bundle so you can roll back instantly.
2. Confirm FakeNet is hot. From a lab VM: dig evil-c2.example.com should return 10.0.100.1. curl http://evil-c2.example.com should return the canned OK page.
3. Start the host capture. ⌘⇧P → Start. This catches everything on the virtual switch.
4. Start in-guest capture on the router. secvf-capture start. You want both vantage points.
5. Detonate. Run the sample inside the lab VM.
6. Wait. Most malware does the bulk of its talking in the first 30–60 seconds. Some wait longer to evade sandboxing; if the sample looks dormant, leave it alone for 10–20 minutes.
7. Stop captures. Save the PCAPs. Copy /var/log/fakenet/ off the router.
8. Restore the snapshot. Now you have a known-good lab again for the next sample.

Switching back to live router

FakeNet flips dnsmasq and adds iptables redirects. To revert:

sudo bash /mnt/kali-router-restore.sh    # provided alongside the FakeNet script
# or manually:
sudo cp /etc/dnsmasq.conf.orig /etc/dnsmasq.conf
sudo iptables -t nat -F PREROUTING
sudo iptables-restore < /etc/iptables/rules.v4
sudo systemctl restart dnsmasq

Or — easier and safer — keep two router bundles: Kali-Router (live) and Kali-Router-FakeNet (sinkhole). Switch between them via VM Library → Edit configuration on each lab guest's gateway.