FakeNet-NG: redirecting a malware sample's traffic into services you control

The problem it solves: samples that wait for a network

A malware analyst running a sample in a sandbox hits a wall whenever the sample checks for connectivity before it does anything. It resolves a domain, gets nothing back, and exits. The behaviour that made the sample worth analysing never happens, and no amount of waiting or snapshotting produces it.

FakeNet-NG's answer is to be the network. It intercepts traffic and redirects it to listeners the analyst controls, simulating legitimate network services, so the sample gets answers and keeps going. The README frames it as a tool for quickly identifying malware functionality and capturing network signatures, and adds a second audience: penetration testers and bug hunters who want a configurable interception engine and a modular framework for testing specific application functionality or prototyping proofs of concept.

The lineage is stated up front. The tool is based on the earlier Fakenet work by Andrew Honig and Michael Sikorski, and the setup.py credits the Mandiant FLARE team with Peter Kacherginsky as the original developer. That matters because the design is a decade old in its ideas: the interesting part is not the mechanism but that it is packaged, licensed and maintained by a vendor whose business is incident response, which is why it ships as a runnable executable rather than a script you assemble yourself.

Why antivirus will flag it, and why that is expected

The README handles this head on, which is unusual and useful. FakeNet-NG may be flagged as malicious by antivirus and endpoint detection and response solutions, naming Windows Defender and Chrome's Safe Browsing as examples. The stated reasons are its ability to modify network traffic and simulate network services, together with the use of PyInstaller to build the release executables.

The README calls the official release binaries safe, describes these detections as false positives, and recommends running the tool in a controlled and isolated environment such as a virtual machine where it can safely alter the system's network settings. That is both a security instruction and a practical one: the tool's whole function is to rewrite how the machine resolves names and reaches hosts, so the environment it runs in is disposable by design.

The same reasoning explains why this belongs on an analysis VM and not on a workstation. The tool intercepts all traffic, or the specific traffic you configure. On a machine with real credentials and real sessions, that is a poor trade for a convenience feature.

Three installation paths, and which one to take

The README documents three routes, and the ordering tells you which one the authors consider safest.

The stand alone executable is the preferred method on Windows. You download the compiled version from the releases page and run fakenet.exe, with no additional modules required, which the README calls ideal for a malware analysis machine.

python -m pip install https://github.com/mandiant/flare-fakenet-ng/zipball/master

Installing as a module is the middle path. It requires Python 3.10.11 and current pip, plus Visual C++ build tools on Windows. On Linux there is a dependency list, and the README gives the command to satisfy the main ones:

sudo apt-get install build-essential python3.10-dev libnetfilter-queue-dev

That is also where the Linux specific friction appears, because the DNS listener wants port 53 and systemd-resolved holds it:

sudo systemctl stop systemd-resolved

The final route is the no installation path, which the README frames as useful for development. You install Python, then the dependencies directly:

python -m pip install pydivert dnslib dpkt pyopenssl pyftpdlib netifaces jinja2

On Linux the list becomes netfilterqueue plus the same set. pydivert pulls in the WinDivert library and driver, and the README notes the project bundles those files so they are not necessary for normal use. From a source checkout you then run the package directly in a privileged shell:

python -m fakenet.fakenet

One dependency warning is worth heeding because it is the kind of thing that costs an hour. The Linux instructions include a note that a ModuleNotFoundError for _cffi_backend was observed while testing, with an upgrade of cryptography given as the fix.

What the package actually contains

The setup.py describes the dependency set, and it differs by platform in a way that explains the design. The common requirements are dpkt, dnslib, netifaces, pyftpdlib, cryptography, pyopenssl and jinja2. On Windows the list gains pydivert, and on Linux it gains netfilterqueue.

The platform split is the interesting part, because it names the two interception technologies. WinDivert on Windows is a user mode packet capture and diversion driver, and netfilterqueue on Linux is the netfilter queue mechanism. FakeNet-NG is therefore built on the native packet interception primitive of each operating system rather than on a userspace proxy, which is what allows it to catch traffic from a process that is not going through any proxy you configured.

The package data list describes the rest of the surface. It ships pem files and the listeners/ssl_utils directory including its own certificates, html_report_template.html, a configs directory with ini files, a defaultFiles directory, and lib directories for 64-bit and 32-bit. Those lib directories holding prebuilt libraries for both architectures is a packaging choice aimed at the analysis VM, where a missing wheel for an unusual interpreter version is a bad morning.

The console_scripts entry point maps fakenet to fakenet.fakenet:main, which is why the installed command is simply fakenet. The classifiers describe it as a Beta at development status 4, and Python 3 as the target.

Running it, and the modular listener design

Execution is the simplest part. Run the executable as an Administrator on Windows, or fakenet from any directory in a privileged shell on Linux. The README shows the help output starting from a command prompt at a tools path with fakenet.exe --help, and the ASCII art banner is the tool's own logo, so recognising it in a log is straightforward.

The design principle underneath is that listeners are plugins. The README calls the interception engine configurable and the framework modular, and the package data confirms it by shipping a listeners directory with a nested ssl_utils directory inside it. Adding a service means adding a listener rather than changing a switch statement in a core loop, which is what makes the tool usable in front of protocols nobody anticipated when it was written.

That modularity is also the honest limit. Because the services are emulations, a sample that speaks a protocol the listeners implement poorly will produce behaviour that does not match a real deployment, and a sample that validates certificates or checks latency may behave differently than it would in the wild. Dynamic analysis answers what a sample does when it believes it has a network, not what it does when the network is real.

Logging goes to stderr from both the client and server components, and the README suggests journalctl when running under systemd. That is a small but practical detail: the tool's output is designed to be captured by the same pipeline as everything else on an analysis host.

Where FakeNet-NG sits and what to check first

The comparison that matters is not against other interception tools but against sandboxing. A commercial or open sandbox gives you a real network path, a real file system image and a report, at the cost of isolation from your own tooling and often a per sample charge. FakeNet-NG gives you the network behaviour locally, inside a VM you already control, and gives you the source. For an analyst with an existing malware lab, the local tool is the cheaper answer; for anyone without a lab, the sandbox is the practical one.

The other alternative is a hand rolled redirect through iptables or a hosts file plus a few listeners. That works for one protocol and becomes a maintenance burden across a sample set, which is the argument for using a maintained tool rather than a script.

Before adopting it, check three things. Your analysis VMs have a snapshot or reset path, since the tool modifies system network settings by design. Your endpoint tooling will not quarantine the analysis host when it sees WinDivert load, which the README flags as expected. And on Linux, that resolving service is stopped and restarted when you are done, since the tool takes port 53 for its DNS listener.

The project is Apache 2.0 licensed with a LICENSE.txt file in the tree, so redistribution and modification are straightforward. The repository also carries a fakenet.spec file, a test directory, a resources directory and a CHANGELOG.txt, which together describe a project with packaging and test infrastructure rather than a single file script. The newest release is FakeNet-NG 3.5 from 2025-04-09, after 3.3 from 2024-11-22 and 3.2-alpha from 2024-04-11, so version numbering has been moving at a measured pace.

Editorial conclusion

FakeNet-NG is worth having on a Windows analysis machine for the cases where a sample refuses to do anything interesting without a network, because the alternative is a sandbox with real services behind it. The costs are specific: it needs administrator rights, it takes over port 53 on Linux, and it will be flagged by antivirus and endpoint tooling because that is what it does. On Linux, stop systemd-resolved first, since the DNS listener needs the port. The last push was on 2026-05-28 and the newest release is FakeNet-NG 3.5 from 2025-04-09, so read the changelog before pinning a version in a repeatable analysis setup.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. mandiant/flare-fakenet-ng on GitHub
4. README
5. Releases