wifit3 - WiFi pentest tool

What is wifit3?

wifit3 is a tool you use to test the security of wireless networks. You see the networks in range, pick a target and the tool carries out the well-known WiFi attacks against it, from capturing a handshake to abusing WPS. The tool is the successor to Wifite2 and comes from the same author, derv82.

Mind the spelling. The tool is called wifit3, without the ’e’, even though its predecessor is called Wifite2. A lot of people search for “wifite3”, but that tool does not exist. It is the same software.

What makes wifit3 fundamentally different from its predecessor is that it bypasses the WiFi stack of the operating system completely. Instead of putting a kernel driver into monitor mode and then calling Aircrack-ng, wifit3 ships its own mini drivers: Python ports of Linux kernel drivers that talk to the USB adapter directly with bulk and control transfers. Because frame injection and monitor mode therefore happen entirely in user space, the limitations of Windows NDIS and the driver locking of the Linux kernel do not apply. That is why the same tool works on Linux, Windows and macOS.

What do we use wifit3 for?

During a WiFi pentest we want to know quickly which wireless networks are weakly protected. wifit3 maps out in a single overview which access points are there, which encryption they use, whether WPS is switched on and how many clients are attached to them. That determines where we look further.

After that we use the tool to demonstrate concretely that a network can be cracked. A captured handshake that we then break open with Hashcat is the proof that a password is too weak. A successful PixieDust attack proves that WPS has to be switched off. Where Aircrack-ng gives you separate tools that you tie together yourself, wifit3 does that work automatically and in one interface.

Installing wifit3

The easiest route is a ready-made binary from the releases page. That saves you setting up a Python environment, and on Linux you do not need sudo for it:

# Linux: make it executable and start it
chmod +x wifit3-linux-x64 && ./wifit3-linux-x64

# macOS: remove the quarantine flag first
xattr -d com.apple.quarantine wifit3-macos-universal2
chmod +x wifit3-macos-universal2 && ./wifit3-macos-universal2

If you prefer to work from source, the project uses uv to manage its dependencies:

git clone https://github.com/derv82/wifit3.git
cd wifit3 && uv sync && uv run wifit3

On first start wifit3 sorts out the hardware settings itself, after you click START. On Linux it asks once through pkexec to write udev rules and a modprobe blocklist, on Windows it installs the WinUSB driver through UAC, and on macOS you only grant permission in the dialogue. Note that the card no longer works as an ordinary WiFi adapter afterwards: airmon, iw and your normal WiFi connection are disabled on that device. The Uninstall button on the start screen reverses that.

Which adapters are supported?

You need at least one supported USB adapter. A built-in WiFi card does not work. These are the most common ones:

The full list is in the documentation of the project. If you want to test 5 GHz as well, pick a dual-band chipset. The old TL-WN722N v1 is popular and cheap, but only does 2.4 GHz, and the v2 and v3 have a completely different chipset.

If you have two adapters, use them both. wifit3 can scan with several cards at the same time and let you designate one card to inject with. That saves time, and with an EvilTwin it demonstrably works better than with a single card.

Which attacks can wifit3 carry out?

On top of that, wifit3 does reconnaissance work that Wifite2 did not have. It recognises the manufacturer and model of access points from WPS beacons. And with VAP decloaking it brings hidden networks to light by comparing their BSSID with visible neighbours on the same device: routers almost always give their guest and main network consecutive BSSIDs, so a hidden SSID can simply be inferred. Hiding a network name is therefore not security.

From capture to password

wifit3 writes every successful capture to the captures/ directory, with the SSID and the BSSID in the file name. The .hc22000 format is exactly what Hashcat expects, so you do not have to convert anything:

# Mode 22000 covers both the four-way handshake and PMKID
hashcat -m 22000 captures/TestLab-Guest_02-5f-a3-1c-84-d0.hc22000 /usr/share/wordlists/rockyou.txt

# With rules added for variants such as Zomer2026!
hashcat -m 22000 vangst.hc22000 rockyou.txt -r /usr/share/hashcat/rules/best64.rule

# Aimed at a known pattern: capital letter, five letters, four digits
hashcat -m 22000 vangst.hc22000 -a 3 '?u?l?l?l?l?l?d?d?d?d'

If the cracking does not succeed, that is not a failure but a finding: the key is strong enough. In a report, “the handshake was captured but not cracked within the agreed time” is a perfectly good outcome, because it shows that the password policy works.

Difference from Wifite2

Neither tool cracks WPA3 itself. That is not possible, because SAE was designed precisely to make offline guessing impossible. The difference is that wifit3 can push a network that is in transition mode back to WPA2, and then capture that handshake.

The flip side of the custom drivers is that the hardware requirement is stricter. Where with Wifite2 you could use almost any adapter that handled monitor mode, wifit3 only works with chipsets for which a port has been written.

Bear in mind as well that wifit3 is still in beta. The approach is promising, but you sit closer to the hardware than with Wifite2, and that means an adapter sometimes behaves differently from what you expect. For work at a client we therefore use a card we know is well supported, and we keep Wifite2 on hand as a fallback.

Detection and defence

The attacks from wifit3 leave clear traces in the air. A deauthentication is an 802.11 management frame of subtype 12, which rarely occurs in normal traffic and never in series. An EvilTwin gives itself away because the same SSID is suddenly broadcast from a second BSSID, usually on a different channel and with a different signal strength. And a Channel Switch Announcement that does not come from your own controller has no business being there at all.

A wireless intrusion detection system in an enterprise environment picks this up. Controllers from Ubiquiti, Aruba and Cisco report it as “rogue AP detected”, “deauth flood” or “honeypot AP”. If you do not run anything like that, you can often still see a run of failed WPS attempts or a spike in disconnected clients on the access point itself.

Protecting your own network comes down to four things:

• Switch WPS off. PixieDust and the PushButton attack bypass your password completely and are done in seconds. A long key does nothing against that.
• Use a long, random WPA2 key. A captured handshake is only valuable if the password can be guessed. Four random words or twenty random characters make offline cracking unaffordable.
• Switch WPA3 on with Protected Management Frames (802.11w). PMF signs management frames, so loose deauthentication frames are ignored and forcing a new handshake becomes much harder.
• Turn transition mode off as soon as you can. As long as your access point keeps offering WPA2 alongside WPA3, the downgrade attack is possible and you get little benefit from WPA3.

If you want to know whether your wireless network holds up against this, a WiFi pentest will show you. For how these attacks play out in practice, read our blog on WiFi hacking with wifit3.

Only use wifit3 on networks that are yours or for which you have explicit, written permission. The tool actively sends traffic into the air and disrupts other people’s connections. Without permission that is a criminal offence.