Traffic Generation Toolkit - TGT: Make Network Traffic on One Machine
Say you want to test a network monitor. Zeek, Suricata, Security Onion, one of the OT platforms like Claroty or Nozomi. Before it can catch anything, it has to see traffic. And getting traffic usually means a real network: a switch with a mirror port, a couple of machines talking to each other, cables. That's a lot of gear to set up before you can answer one small question. Is my sensor working?
TGT skips all of that. It's a small Python tool that makes network traffic on a single computer and feeds it straight to your sensor, the same way a mirror port would. No switch. No second machine. No real network at all.
It runs on plain Python 3.9 with nothing else to install. Works on a laptop, in WSL, or in a container.
How it works
TGT creates a pair of virtual network cards that are wired together. Whatever you send out of one shows up on the other.
You generate traffic on tgt0. Your sensor listens on tgt0-mon. That's the whole setup. One side talks, the other side watches. Everything else is just deciding what to put on the wire.
Getting it running
Grab the code and start the UI in quick and simple to run commands:
git clone https://github.com/fqazzazee/Traffic-Generation-Toolkit.git
cd Traffic-Generation-Toolkit
sudo python3 -m tgt
I designed TGT so the UI draws a live diagram of the traffic so you can watch packets move as they go out. This was important to me to make it easier for people to use this educational purposes and make things easier to illustrate.
Open Map and create the virtual pair, open Protocols and pick a few with Space, then press s to start. Point your sensor at tgt0-mon and you're capturing.
If you'd rather use the command line, it's three lines:
sudo python3 -m tgt iface create tgt0 # make the virtual pair
sudo python3 -m tgt run -s ot-baseline -i tgt0 --rate 50 # send traffic
sudo tcpdump -i tgt0-mon # watch it (or point a sensor here)
What you'd actually use it for
Testing in a lab
This is the main one. You've got a monitor and you want to know it reacts the way it should. TGT gives it something to react to.
Pick individual protocols, or grab a ready-made mix so you don't have to think about it:
tgt run -s ot-baseline -i tgt0 # a normal industrial baseline
tgt run -p modbus,s7comm -i tgt0 # just the protocols you name
You can also spin up a fake or a mock-up company network. Named machines with real roles, addresses, vendor MAC addresses, and operating system fingerprints, all having believable conversations. Now your sensor has actual assets to find, and some of them are the kind of old, weak boxes you'd want it to flag:
tgt run --env it-org -i tgt0 --rate 100 # office IT network
tgt run --env ot-plant -i tgt0 --rate 100 # industrial plant
tgt run --env enterprise-mixed -i tgt0 --rate 100 # both together
The office network, for instance, includes an old Windows 2000 file server and a couple of Windows 7 and XP machines still using SMBv1. Exactly the sort of thing a monitor should complain about.
Learning what real attacks look like on the wire
TGT can replay the network fingerprints of famous attacks. This is a great way to see what WannaCry or Stuxnet actually looks like as packets, and to check that your sensor notices:
tgt run --incident wannacry -i tgt0 # SMBv1 EternalBlue and the kill-switch domain
tgt run --incident stuxnet -i tgt0 # S7comm PLC commands and SMB spread
tgt run --incident industroyer -i tgt0 # IEC-104 breaker command flood
WannaCry, Conficker, Mirai, Sunburst, Log4Shell, Stuxnet, Industroyer, and Triton are all there. Each one recreates the tell-tale signs that a detection tool looks for.
Worth being clear: these are the signatures, not the real thing. They carry the patterns a monitor keys on. There's no working exploit, no shellcode, no actual malware. They're for testing detection in your own lab.
For a tougher test, hide an attack inside ordinary traffic and see if it still gets caught:
tgt run --env it-org --sprinkle wannacry -i tgt0 # a small dose of malware
tgt run --env it-org --sprinkle wannacry --sprinkle-ratio 0.1 -i tgt0 # about 10 percent
Anyone can spot an attack when it's the only thing on the wire. The real question is whether your sensor spots it when it's one bad conversation buried in a thousand normal ones.
Making sample PCAPs
Sometimes you don't want a live feed, you just want a capture file. Maybe to share, to study, or to keep as a known-good sample of a protocol. TGT writes PCAPs directly, and this works without root:
python3 -m tgt run -s ot-full --pcap ot.pcap --count 500
python3 -m tgt run -p modbus --pcap modbus-sample.pcap --count 200
Open the file in Wireshark and you've got clean, correct example traffic for whatever protocol you asked for. Handy for teaching, for a folder of samples, or for feeding into other tools.
Playing back a PCAP
Got a capture already? A real sample, a lab recording, something a colleague sent you? Put it on the wire and let your sensor chew on it:
tgt run --replay threat.pcap -i tgt0 # send it out
tgt run --replay threat.pcap -i tgt0 --replay-realtime # keep the original timing
tgt run --replay threat.pcap -i tgt0 --loop # over and over
The realtime option matters when timing is part of what you're testing. Slow scans, beacon intervals, that kind of thing.
Trying out traffic analyzer software
If you're picking a new analyzer, tuning one, or demoing one, you need traffic to show it off. Standing up a real network for that is a pain. With TGT you point the analyzer at tgt0-mon, start a scenario, and you've got a steady, repeatable feed you can shape however you like. Same traffic every time, so when something changes you know it was the tool, not the network.
For a lab that should always have something flowing, TGT installs as a background service with one script:
sudo ./scripts/tgtctl.sh install # dependencies and a quick self-test
sudo ./scripts/tgtctl.sh register # write the config, make the virtual pair
sudo ./scripts/tgtctl.sh start
Point your analyzer at tgt0-mon once and it has traffic from then on.
A note on using it responsibly
TGT is a test tool for labs and for testing you're allowed to do. It builds fake packets between endpoints you set, on virtual cards you make. It doesn't scan anything, break into anything, or reach out to other systems. Keep it to networks you own or have permission to test, and stick with the virtual pair so nothing leaks onto a real network.
If you're writing detections, tuning a ruleset, showing off an OT platform, or just
curious what your monitor does when something ugly goes by, TGT gives you the traffic without the network.
TGT is open source under the MIT license. Code is at github.com/fqazzazee/Traffic-Generation-Toolkit.