Kali 2026.3 just shipped 6 new tools: what they do and what they leave in your logs

Check the version, then install the six tools added in this release. They come from Kali’s own repository.

# grep VERSION= /etc/os-release
# sudo apt update
# sudo apt install -y rustscan katana dalfox qsreplace snaffler-ng sdrangel

VERSION="2026.3"

The six, in one line each. rustscan — a very fast port scanner. katana — a web crawler that maps a site’s links. dalfox — a cross-site-scripting (XSS) scanner. qsreplace — a tiny text tool that rewrites the values in a URL’s query string. snaffler-ng — hunts Windows file shares for secrets (needs a Windows share, so we only name it here). sdrangel — a software-defined-radio front end (needs radio hardware, named only). We test the four web tools.

So you never point these at anyone else, host a three-page static site on your own loopback address. It has a search form and a product link with a query string, and nothing else.

# mkdir -p /tmp/shop && cd /tmp/shop
# echo '<a href="/products.html">products</a> <form action="/search.html"><input name="q"><input name="page"></form>' > index.html
# echo '<a href="/item.html?id=1&ref=home">item 1</a>' > products.html
# printf 'results' > search.html; printf 'one item' > item.html
# python3 -m http.server 8000 --bind 127.0.0.1 &

The & leaves the web server running in the background so you get your prompt back. Everything from here points at 127.0.0.1:8000, which is this same machine.

rustscan’s job is speed: it finds open ports in a fraction of the time an old full scan took. The -g flag prints one clean “greppable” line.

# rustscan -a 127.0.0.1 -p 22,80,8000,3306 -g

127.0.0.1 -> [8000]

Reading it. Of the four ports asked about, only 8000 answered, so that is the one printed. Left to its own defaults rustscan sweeps all 65,535 ports in seconds and then hands them to nmap for detail. What you will see as a defender: a single source touching hundreds or thousands of your ports within a second or two. That speed is the tell — a human never knocks on ports that fast.

Before attacking anything, a tester maps it. katana follows links and lists every page it finds. -silent prints just the URLs.

# katana -u http://127.0.0.1:8000/ -silent

http://127.0.0.1:8000/
http://127.0.0.1:8000/about.html
http://127.0.0.1:8000/products.html
http://127.0.0.1:8000/item.html?id=1&ref=home

Reading it. katana walked from the home page to the product page and picked up the link that carries a query string (?id=1&ref=home). Add -f qurl and it lists only the URLs that have parameters — the ones worth testing next. What you will see as a defender: one source requesting every page on the site in order, in a few seconds, with a non-browser user agent. That is a crawl, not a visitor.

qsreplace is pure plumbing: feed it URLs and it replaces every query-string value with whatever you give it. Testers use it to drop a test string into every parameter at once.

# echo "http://127.0.0.1:8000/item.html?id=1&ref=home" | qsreplace FUZZ

http://127.0.0.1:8000/item.html?id=FUZZ&ref=FUZZ

Reading it. Both values became FUZZ. On its own it changes nothing and touches no server; it just prepares URLs. Its power is in a pipe: katana ... | qsreplace FUZZ turns a crawl straight into a list of test URLs. There is nothing for a defender to see here, because it runs entirely on the tester’s machine — which is worth knowing, because the quiet step is why the next one arrives already knowing your parameters.

dalfox checks whether a parameter reflects attacker input in a way that could run script (cross-site scripting). Run it against the search page, which is plain static HTML.

# dalfox url "http://127.0.0.1:8000/search.html?q=test&page=1"

[I] Found reflected 0 params
[W] XSS found 0 XSS
[I] scan completed in 2.065 seconds

Reading a clean scan. 0 reflected params means nothing you sent came back in the page, so there is nothing for XSS to hook into, and it reports 0 XSS. That is what a safe page looks like — worth seeing once, so a real finding stands out. This is the honest result: our test page has no bug, so the tool finds none.

Now read the other side. The web server you started has been logging every request. Look at what that two-second dalfox scan wrote.

# grep -c dlfx_sentinel /tmp/shop/*.log 2>/dev/null; wc -l < /tmp/shop/nohup.out 2>/dev/null
# # the scan window in the terminal where python3 is running shows ~100 lines like:

GET /search.html?q=test&page=1&dlfx_sentinel_q_8a3f=... 200
GET /search.html?q=test&page=1&id=...&admin=...&token=...&redirect=...&password=... 200
GET /search.html?q=test&page=1&api_key=...&session=...&csrf=...&next_url=... 200

This is the fingerprint. That one scan sent about a hundred requests in two seconds, each stuffed with hundreds of guessed parameter names (admin, api_key, token, redirect, password…) and a tell-tale dlfx_sentinel marker. The defender’s move: a burst of requests to one URL carrying dozens of parameters it has never used before is a parameter-fuzzing scan. Rate-limit per source, alert on the request spike, and treat the guessed names as a map of what the tool hoped to find.

Stop the web server and remove the practice files. If you used the Docker one-liner, typing exit throws the whole container away.

# pkill -f "http.server 8000"
# rm -rf /tmp/shop
# exit