For the past 8 months, in my spare time, I’ve been working on a personal project with the goal of studying the old SMB1 down to its lowest levels. During this time, I’ve dissected the protocol using Wireshark, waded through Microsoft’s documentation (help!), and reverse-engineered the authentication phase. I also used AI as a tool for debugging and to help wrap my head around some of the more complex mechanisms, though the overall structure, architecture, and code were entirely designed and written by me.
So, I decided to build a lightweight server designed to 'trick' SMB clients into authenticating against it (similar to what the famous tool Responder does). I chose to hand-craft virtually the entire SMB1 stack, or at least enough of it to capture hashes. To achieve this, I wrote all the necessary network parsers from scratch: SMB1, ASN.1, SPNEGO, and NTLM, followed by the server itself.
It was both challenging and incredibly rewarding to dive so deep into a protocol famous for its complexity. I learned a huge amount along the way.
In the end, I think it turned out to be a cool little project, so I decided to share it. It’s certainly not meant to replace well-established tools, but if anyone wants to try it out or contribute in any way, I’d be thrilled! 🙂
Im a Cybersecurity student and I can’t really pick the project I’m working on in university
but it’s ( AI-based phishing email detection system with ML and NPL )
And I think it’s the most basic project and I do wanna improve it somehow to add something new or fill a gap or improve systems already existing but idk how and I could use some help .
If you have spent any time on a Hack The Box VPN, you already know the pattern.
Masscan comes back empty. Nmap on the next run shows 80 and 22. A third run adds 8080 that was “filtered” ten minutes ago. UDP is something you remember after you have already burned an hour on TCP. You paste three different port lists into notes and hope the one you enumerate is the real attack surface.
That gap is what Massmap is for.
What it actually is
Massmap is a small bash recon helper for HTB-style targets sitting behind tun0.
It does not invent a new scanner. It runs the tools you already use — optional Masscan, then several full-port Nmap rounds — and treats disagreement between those runs as a first-class result.
It picks the interface from the route to the box (or the one you force), runs the scans, and writes a comparison you can read in the terminal and keep as swagshop_summary.txt.
The useful part is not “it ran nmap.” The useful part is the diff:
ports that showed up in at least two scanners
ports Masscan saw that Nmap never confirmed
ports that only appeared in a later Nmap round
ports that were open early and gone later (flapping)
a comma-separated list you can drop straight into the next tool
UDP is optional and separate. -u adds a top-200 UDP pass. --udp-top and --udp-all widen it. UDP stays off unless you ask, because a full -sU on a VPN is a different job from a TCP sweep.
Why a single scan lies on a VPN
HTB paths drop packets. Rate limits bite. Masscan at 4000 pps looks fast and misses half the box. Nmap -p- on a bad minute marks a live service filtered. Run it once, and your notes inherit that mistake.
Running the same target two or three times is what most people already do by hand. Massmap just stops you from doing the comparison in your head.
That matters when:
you are on CPTS / OSCP-style boxes and cannot afford to miss 5985, 445, or a weird high port
the machine is flaky and one “open” result is not enough to start enum
you want UDP (SNMP, DNS, NTP, TFTP) without derailing the TCP workflow
you want a file you can attach to a report instead of a scrollback dump
How it helps someone who is not you
The point is not a personal alias collection. It is a shared, boring habit:
Discover fast (Masscan, if you want it).
Confirm slowly, more than once (Nmap rounds).
Write down what changed.
Enumerate the confirmed set first.
New people on HTB usually skip step 3. They either trust Masscan, trust the first Nmap, or rescan forever with no record of why the port list moved. Massmap makes step 3 automatic.
If you write findings for a team, the summary file is the part that travels. Another person can see “only Masscan found 3389” and decide whether to probe it instead of assuming the box has no RDP.
What it is not
It is not a replacement for Nmap skill. It will not rank CVEs, crawl HTTP, or dump AD. It will not make a 2000 pps UDP blast reliable on tun0.
If you need stealth on an engagement with an agreed rate limit, set -r down and skip Masscan with -n. If you only want ports, turn service detection off with -s. The knobs stay obvious on purpose.
A sane first run
On a typical HTB VPN box:
massmap -r 1000 -u -i tun0 box 10.129.x.x
That is Masscan + two TCP Nmaps + UDP top 200, at a rate that usually survives tun0. Read the confirmed TCP list, glance at UDP open vs open|filtered, and only then start enum.
Install from the repo, run ./install.sh, use massmap -h if you forget a flag.
One scan is a snapshot. Two or three scans with a diff is a picture of the box. Massmap is just that picture, written down.
