PyExfil is a catalogue of exfiltration channels used to test what your DLP actually sees

The author calls it a testing tool, and means it

PyExfil is described in the README as a Python 3 toolkit for researching and stress-testing data exfiltration techniques across network, physical and steganographic channels, for red team simulation and DLP detection testing.

The framing in the README itself is unusually careful, and it is worth reading before anything else. The project was born as a proof of concept and a playground, and the author says that in his eyes it is still a messy PoC that needs a lot more work and testing to become stable.

The stated purpose is to set as many exfiltration, and later also communication, techniques that can be used by threat actors and malware to bypass detection and mitigation tools, and the instruction for use is direct: clone it, deploy on a node in your organization, and see which systems can catch which techniques.

That last sentence is the intended workflow, and it defines the audience. This is a tool for the people who own the detection controls, not for the people trying to evade them. The README also states plainly that it is meant to be used as a testing tool rather than an actual red teaming tool.

The techniques themselves are documented per module in the USAGE.md file, and the project has its own documentation site at pyexfil.morirt.com. The licence recorded for the repository is MIT, with a LICENSE.md file at the root.

Four channels, dozens of specific techniques

The technique list is the substance of the project, and it is organised into four groups.

The network group covers DNS query, HTTP Cookie, ICMP type 8, NTP Body, BGP Open, HTTPS Replace Certificate, QUIC with no certificate, Slack exfiltration, POP3 authentication used as a password, FTP MKDIR, source IP based exfiltration, HTTP Response and IMAP Draft. Two of these are credited as ideas from Itzik Kotler, who is also credited for the FTP MKDIR technique.

The communication group is a set of channels rather than transports of payload. NTP Request, DropBox LSP which can be broadcast or unicast, DNS over TLS, ARP Broadcast, JetDirect, GQUIC using the Google Quick UDP Client Hello, MDNS Query which can be used as broadcast, AllJoyn using the IoT discovery name service, PacketSize which uses the size of the packet rather than actual data, UDP-Source-Port which uses the UDP source port as the transmission medium, CertExchange which leverages the certificate exchange function for short bursts, DNSQ which leverages DNS queries, and ICMP_TTL which leverages the TTL byte.

The physical group is Audio with no listener, QR Codes, WiFi frame payload, 3.5mm Jack and UltraSonic.

The steganography group is Binary Offset, Video Transcript to Dictionary, Braille Text Document, PNG Transparency, ZIPCeption, and DataMatrix over LSB.

What makes this list interesting is not any single technique but the coverage. When a DNS query, a BGP open message, a UDP source port and a certificate exchange can all carry data, the question for a defender stops being whether one of those channels is blocked and becomes how many of them are being watched at once.

Installing it from pip or from source

There are two documented install routes, and the pip one is flagged as possibly not the most updated.

pip install --user PyExfil

For source, the README gives three commands.

git clone https://www.github.com/ytisf/PyExfil
cd PyExfil
pip install --user -r requirements.txt

There is also a separate installing step, run from the same folder where PyExfil was cloned.

pip setup.py --user install

The README recommends installing py2exe as well, so that various modules can be cross compiled to a binary for easier transportation.

pip install py2exe

That recommendation tells you something about the intended deployment. A detection test that requires a Python interpreter, a source checkout and a requirements install on every node is not something you will run widely, whereas a cross compiled binary is something you can push to a subnet and leave there.

The dependency list in setup.py is long and gives a good sense of the physical and steganographic channels in practice. It includes requests, impacket, slack-sdk, progressbar2, numpy, Pillow, pycryptodome, base58, names, Faker, luhn, qrcode, scipy, sounddevice, pylibdmtx, opencv-python and librosa.

That list maps almost one to one onto the technique groups. qrcode and pylibdmtx cover the QR and DataMatrix channels, sounddevice and librosa cover the audio channel, Pillow and opencv-python cover the image channels, scipy and numpy cover the binary offset work, and impacket sits under the protocol level techniques. The package requires Python 3.6 or later and declares platforms as any, with classifiers for Windows, POSIX, Unix and MacOS.

Synthetic data generation is what makes it safe to run widely

This is the part of the project that turns a tool into something you can actually deploy on a network.

The README explains that although the tool was initially created as a game and later turned to be a red team oriented tool, a major usage of PyExfil is to test various DLP systems as well as intrusion detection. To make that mission simpler, a module was created to generate fake data with a structure that matches both PII and PCI data sets, and these are intended to trigger alerts while being broadcast outside of the network.

That is a well-designed testing approach. A synthetic record that looks like a credit card number but is not one still exercises the DLP rule, still trips the alert, and still appears in the exfiltration log, but it does not put anyone's actual card number on the wire. The dependency list supports it: Faker for generating plausible identities, luhn for producing numbers that pass a checksum, base58 for encoding, and names for the other fields.

The USAGE.md file covers how to use the modules individually, and the repository also has an EXAMPLES.py file and a tests directory.

The boundary condition is worth stating. This tool's value depends entirely on the data being fake and the target being your own network. On a network that is not yours, the same synthetic payload that tests a DLP rule is still a data exfiltration tool.

A repository with two histories

The repository contents and the release history do not quite line up, and that tells you something about the project's status.

The release list shows v1.3.3 Harpax from 2021-06-28, v0.9 from 2016-11-30, and a release literally named latest from 2018-04-25. The last push to the repository was on 2026-06-23.

So the code has been touched recently, but the newest tagged release is several years old, and there is a release tag called latest that is older than v1.3.3. The tags are not a reliable guide to what is on the default branch.

The repository layout also shows the project's structure and history at once. There is a pyexfil package directory, a blackhat directory whose name is a pointer to the original intent, ARCHITECTURE.md, DOCUMENTATION.md, CALL_TO_ACTION.md, USAGE.md, EXAMPLES.py, a static directory, tests, and both requirements2.7.txt and requirements3.txt, which tells you the code was carried through the Python 2 to Python 3 transition.

There is one more inconsistency worth flagging for anyone deploying it. The repository records the licence as MIT, with a LICENSE.md file at the root, while the setup.py declares __license__ as GPLv3 and includes the classifier for the GNU General Public License v3. The author field points at [email protected] and the maintainer name is PyExfil.

Neither the README nor the repository listing explains the mismatch. Read both files before you redistribute any part of this package.

Where PyExfil is the wrong tool

The first limitation is the author's own, and it is the most useful thing in the README. This is a messy proof of concept that needs a lot more work and testing to become stable. The techniques are described as some stable and some experimental, with the transmission mechanism expected to be stable on all techniques. A detection engineer should read that as: some channels will work, some will not, and you cannot tell in advance which.

The second limitation is coverage in the other direction. A DLP control that catches every technique in this list is still missing the technique nobody wrote down. The list is a snapshot of what the author could think of, and it is by construction the set of ideas that a security team would most likely already consider.

The third is that the tool measures detection, not prevention. It tells you what your monitoring saw. It says nothing about whether a channel was actually blocked, and a DLP that alerts on everything and blocks nothing passes a detection test perfectly.

The fourth is the operational weight. The cross compilation advice with py2exe exists because running a Python tool on many nodes is work, and a detection exercise that only runs on one machine with the right packages installed will not tell you much about a segmented network.

The fifth is the legal and authorisation boundary, which the project itself respects by saying it is meant to be a testing tool and that the usage is deploying it on a node in your organization. Running any of these channels, including the synthetic-data ones, against a network you are not authorised to test is a different activity from the one this project is for.

How it compares with a packet capture and a DLP vendor test suite

There are two other ways to answer the question PyExfil is aimed at, which is what your monitoring actually sees.

The first is a vendor test suite. A DLP vendor will send you a set of files and show you which rules fire. That answers the question about their product, and it answers it in their environment. It does not tell you whether your mail gateway, your DNS resolver, your proxy and your EDR agent together cover the channel, which is the question that actually matters.

The second is running the techniques yourself, which is what PyExfil does. The difference from a vendor suite is that the vendor suite is a closed list of files in one protocol, while this is an open list of protocols implemented in front of you. You can extend it, you can point it at your own detection stack, and you can add a channel the vendor has never heard of.

Against a packet capture and a SIEM query, PyExfil sits on the other side of the pipeline. A capture tells you what crossed the wire, which is the right tool for forensics and for baselining what normal traffic looks like. PyExfil tells you which of the unusual shapes your pipeline noticed, which is the right tool for finding the gap between what can be sent and what is watched.

The honest framing is that these are complementary rather than competing. A capture without generated traffic tells you little about the gaps, because you would need the exotic traffic to exist to capture it. PyExfil generates the exotic traffic so that the capture, the SIEM rule and the DLP alert all have something to look at.

The practical value of the toolkit is the coverage it gives you for free, as a catalogue of shapes to point at your own stack. That value drops sharply if you only run the common channels, so the whole list matters more than any one technique.

Editorial conclusion

PyExfil fits a detection engineer or blue team member who wants to know which of their controls actually fire, and who can run it against a node inside their own network with synthetic data rather than real records. It does not fit a production security control, and the author says so directly, describing it as a messy proof of concept needing more work and testing to become stable. Before deploying it, read USAGE.md per module, restrict it to a node inside your own network, and use the fake data generation module so that nothing sensitive leaves your environment while you map which techniques your DLP and intrusion detection miss.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ytisf/PyExfil on GitHub