[ad]
Scanrand is extremely quick and effective port scanner. It works by forking two distinct processes:
- One to send the initial queries
- One to receive responses and reconcile them from the above
This makes it extremely fast.
If you haven’t heard of the suite, Scanrand is one of the five tools in Paketto Keiretsu by Dan “Effugas” Kaminsky of Doxpara Research.
Scanrand implements numerous options; reasonable defaults are selected when no specific guidance is received from the user. The only thing mandated is a target destination, which may be specified using either a FQDN(Fully Qualified Domain Name) or a numeric specification.
These numerics may employ any number of dashes, commas, or combination thereof at the same time. For example, scanrand 10.0.1-255.1-10,20:80,137-139 works fine.
More ports will be scanned by default when scanning a single host than when sca
nning a network. Scanrand is able to estimate remote hopcount by examining incoming TTLs.
Note please to install scanrand you need to first install the provided libnet, libtomcrypt and libpcap tarballs.
It’s a good alternative to nmap for certain purposes
You can read a good article on Scanrand here:
Scanrand Dissected: A New Breed of Network Scanner
The article includes nmap vs scanrand.
You can download Scanrand here (as part of Paketto):
Or read more here.
goodpeople says
Nice tool to have next to nmap.
mumble says
Unless you’re trying to make someone’s IDS jack clear out of the rack and land in the sysadmin’s lap, speed is probably not your main concern. The correct hacking tool for this job is GNU screen. Start a screen session with a nice, slow, low-impact scan that won’t set off the IDS – then suspend the session and go make yourself something to eat and a fresh pot of coffee. Later, re-connect to the machine and pick up your results.
net2004eng says
Scanrand is a very fast scanner that has been around for a little while. This tool is integrated into the BiDiBLAH framework as well.
@mumble
I agree, I would think twice about using this scanner depending on what type of environment I am in – if I know there are a IDS/IPS’s’ deployed.
midnitesnake says
looks similar to synscan http://bindshell.net/tools/synscan
Pantagruel says
Like -Mumble- and the article comparing scanrand and nmap mentions, if you want every to light up like a X-mas tree take scanrand. I did a run, it is hardly subtle and will point into the users direction. But as with many tools, it sure is another usefull addition to your toolbox, albeit one for the quick and dirty work.
mumble says
This is a it different from synscan. While they’re both half-open (syn) scanners, synscan doesn’t use the reverse syncookies approach. What would be an interesting hack for scanrand is to run the packet generator on one box, and the receiver on a different box. After all, you don’t actually have to receive the packets at all – just sniff them – so the dest. box doesn’t even have to be involved – it just has to be on the same lan segment as the destination. ARP ARP :-)
dirty says
-T 5 in nmap will also wake the neighbors too…the speed function is more for internal testing where its known you are testing…. @mumble- definitely agree slow and easy is the way for
malicioussneaky probes…Definitely a good addition to the toolbox though….
Sir Henry says
My question is how the sys packets look to the firewall or IDS compared to those sent during a normal handshake? I have read that the syn packets being sent from different scanners are crafted differently than those sent during a legitimate handshake.
net2004eng says
@Sir Henry
Isn’t the goal of sending a syn scan to illicit a response or no response from the end host. I know you can craft packets with hping, nemesis, etc.. but the goal here is typically different.
In respect to the actual syn’s sent by nmap, scanrand, unicornscan, etc… I would inspect the packets with tcpdump/windump while they leave your machine, and take a look at the way they appear when they arrive at the destinaition. I know MS and Linux implement the tcp stack in different ways, and this very well could imapct he way packets leave your machine, but that would be independent of the tool… Also, I know with snort, that it can identify what scanner you are using, but I think this is based off of a collection of multiple captures…if you send a single syn to one host, I don’t think Snort, nor any other IDS/IPS system, would be so sensitive to be able to tell you what tool is performing the scanning…and you wouldn’t want it to either (at least that might be way too sensitive for me)!
This being said, I’m not an IDS/IPS expert by any means…
Sir Henry says
Nor would I proclaim expertise in the ways of IDS/IPS. I do know, however, that if I am sending a SYN packet, I do not want there to be a false negative or drop from the FW because it is crafted in a way that can be detected as a scanner packet. With my SYN scan, I would want to know which hosts are truly alive and not just dropping because they know I am scanning and not embarking on a true SYN request. So, although I do agree with some points, my point is to know that my scan is obtaining all information available and not experiencing false negatives.
goodpeople says
Different target OSses have different responses. You can never be sure that you don’t have false positives or negatives.
Sir Henry says
I agree, goodpeople, but my interest is eliminating a potential for a false negative as much as I can. Just one example of that is to simply make sure that my probes are going out in the same way a legitimate connection probe would. I would hate to be doing consulting work for a firm and realize only after the fact that, had I crafted the packets in a different way than how they are sent from a scanner, I might have gotten different, perhaps more sensitive, responses.
mumble says
It would have to be a pretty tight environment for the admin to get away with using a passive OS-specific firewall rule on a box. I do know the the OpenBSDs PF firewall can do it, but very few people would. Too high a probability of running into one or two machines which are running an odd OS version and flag incorrectly.
When NMAP is running as root, it can be set up to use direct packet injection. It does so by default on windows boxes to get around the WinXP-SP2 raw sockets disabled problem. If NMAPs packet structure is a problem, it really wouldn’t be all that hard to make it look like anything you want it to.
As the cook says, “Use the Sauce…”
mumble says
Thinking about this in slightly more depth — there’s probably a good article in this for Phrack or 2600… Especially if you can identify the scanner’s signature well enough that the false positive rate is down in the noise.
I know that you can immediately forget about the idea of detecting the difference between a “Connect” scan and the real deal, because the scanners all use the OS connect() implementation, as far as I know. Fin and Xmas-tree scans are easy to see on a stateful inspection firewall, and most will just drop the packet. (PF, for example, will happily drop it on the floor…) I’ll have to set up a few boxes and see what happens.
Sir Henry says
@mumble:
Your last comment is exactly that of which I am speaking. Let me know what you find out with your testing. I would be very interested to find out the results.
mumble says
@Sir Henry
Drop me a line. GPG Key ID: D005B227. You can use the email address on the keyserver. I’d post it here, but…spambots.
Sir Henry says
@mumble:
Will do. It would be cool to work on something like this with you.
eM3rC says
I would personally prefer nmap over scanrand but very nice post.
@Sir Henry and mumble
It would be awesome to hear what you guys come up with.