Differentiating Between Windows Home and Pro

In planning for an Active Directory network,  I need to figure out how many Windows Home versions there are on our network so I can calculate the costs of upgrades.  From what I’ve gathered in using Nmap’s “-O” option, it will only tell give me results such as “Windows XP” or “Windows 7”; it won’t detail specifically if it’s Home or Pro.  I posted a new thread on EthicalHacker.net (highly recommend this site/forum, by the way) and posted on Twitter to see if there was a way to figure this out remotely so that I didn’t have to visit each machine (if you haven’t also gathered, this process will be helping create an updated database of machines on the network as well).

I got 2 replies back rather quickly on EH-net (thanks dynamik and tturner!): one suggesting to use “psexec systeminfo” and the other using WMIC.  @JGamblin on Twitter also suggested “psexec systeminfo”.  Here’s the psexec and the WMIC suggestions:

psexec systeminfo | findstr /B /C:"OS Name" /C:"OS Version"
wmic /node:machinename /user:username os get | find "Windows Home"

**It was also said that “Windows Home” may not be the exact string in the WMIC query there, but that’s easily tweaked.

I’ve played around with the pstools before so I was a little familiar with them, but didn’t know about the systeminfo command of psexec.  As for WMIC, I’ve never used it, let alone heard of it.  Research and testing time!

I gave both a whirl to check the output and if they’d work given our current network setup.  I found that they both worked, except that given the way both of these methods queried the remote systems, they required valid usernames and passwords on the remote systems…and this would be impossible to do with the way the machines are currently setup: no standard admin account on every machine (something else I know I’m going to have to remedy before implementing AD - it’s on the list).

Not too long after, I got another reply on EH-net (thanks hell_razor!) suggesting an nmap NSE script:

nmap -sS -p 445 --script=smb-os-discovery.nse target_ip

I got varied results with this, but I think it depends on the operating system.  It would show “Home” or “Professional” for Windows Vista or Windows 7 systems, but not when it came to Windows XP.  Regardless, since psexec and WMIC require credentials to get the OS info, I decided to go the nmap NSE script route.

If you couldn’t tell already from the script name (smb-os-discovery), it works by connecting to each system via the SMB protocol over port 445 or 139 using the anonymous account if no account is specified (I just used the anonymous account).   This script retrieves not only the OS, but the company name, domain/workgroup, time on the remote system, etc.  Some good information not just for my purpose here, but also for attackers.

Breaking Down the TCP Idle Scan

I’m currently making my way through “Metasploit: The Penetration Tester’s Guide” (along with a couple other books that’ll be in future posts).  Chapter 3 is about information gathering - the process of gathering intelligence on your target so that you can then devise a method of attack.  In the active information gathering section, it brings up TCP idle scanning using Metasploit and Nmap.  Now I read a blog post on the PaulDotCom website awhile back on TCP idle scanning, but not knowing about this type of scan before reading the blog post, I was a little lost.  Here’s the link to the blog post on the PaulDotCom website:

New IDLE scan sees through your firewall to scan hosts inside your network!

So now that I’ve come across it in the Metasploit book, I decided it was time to read up on it more and have a good understanding before going further into the book.  After all, without good information gathering, you’re going to have issues when it comes to planning attack vectors.

The basic idea behind idle scanning is that you’re able to scan a target without ever sending a packet to the target containing your IP address.  This works by sending forged packets to the target that make it look like it’s coming from another host that is idly standing by (I assume this is where it got its name “idle scan”?).  This idle host is often referred to as a “zombie” host.

#Finding your zombie host

Both Nmap and Metasploit are able to automate this process.

But I wanted to know what the process was that’s being automated.  So I started with two things:

  1. Used the “–packet-trace” option when I executed the Nmap command.

  2. Had Wireshark sniffing the traffic while I ran the Nmap command.

The Nmap command I used was:

nmap –packet-trace –script ipidseq –script-args probe-port=80

The packet trace portion of the Nmap scan can be seen below:

From this screenshot you can see that the script starts PCAP to capture the replies from the target.  Nmap then sends SYN packets to the target, then PCAP captures the replies for analysis.

Then you get a print out showing the results of said analysis.  In this case, the IP ID sequence is incremental, which is what we’re looking for in a zombie host.  From these screenshots, we’re unable to see what’s being analyzed though.  Because of this, I re-ran the scan, this time running Wireshark at the same time.

The above screenshot shows the result of one SYN packet being sent by Nmap to the target.  You can see the SYN/ACK sent by the target in return, then the attacker sending a RST packet.  What we want to see is in the IP header of the SYN/ACK packet sent by the target to the attacker.

The above image shows the IP identification number of the packet, which is “23546”.  This was the first of six reply packets sent by the target.  If you look at the IP ID of the 5 following packets, they’ll increment by one each time: 23547, 23548, 23549, 23550, and 23551.  When Nmap analyzes these replies, it sees that it increments by one and determines this host is a good candidate for a zombie to be used during an idle scan.

When I read the Metasploit page about its “ipidseq” module, it said that the only difference Nmap’s check and its own implementation was that instead of using SYN/ACK packets for its check, it uses SYN packets.  This confused me as I had just seen that Nmap’s NSE script was using SYN packets.  This led me to jump over to Nmap’s page on it’s idle scan option (-sI).  On this page I read that when you kick off an idle scan, Nmap will test the zombie host before actually doing the scan.  So I ran Nmap again with the packet-trace option, this time just running an idle scan instead of using the NSE ipidseq script.

Mind you, I was on a different network when I took the below screenshot, so the IP’s differ from what you saw in the above screenshots.

As you can see, Nmap does in fact use SYN/ACK packets to probe the zombie host.  This must’ve been what the Metasploit ipidseq module page was referring to, not the NSE ipidseq script.  This is a  good tidbit of information to remember when you’re looking to run an idle scan, just in case your zombie is, or sits behind, a stateful firewall (learned about port scanning - SYN vs SYN/ACK - as it pertains to stateful vs stateless firewalls from watching Fyodor’s DEFCON 16 video).

Now that I know how the process works for finding a zombie host, it’s time to look under the hood to see how the idle scan works.

#Executing the idle scan

Now to break down the idle scan as performed by Nmap.  Again, we’ll use Nmap’s handy packet-trace option to see what’s going on.

##Open port

  • Attacker:

  • Zombie:

  • Target: scanme.nmap.org (

  • Command: nmap -Pn -p 80 –packet-trace -sI scanme.nmap.org

As you saw in the last screenshot of the previous section, Nmap likes to verify the zombie host to ensure it’s viable.  Nmap sends 6 packets, each time checking the IP ID.  As you can see, the IP ID increments 1 each time from 8650 to 8655.

Then Nmap runs another check, this time checking to make sure the target accepts spoofed packets and that the zombie hosts IP ID’s aren’t changed from host to host.  What you see here is Nmap spoofing packets to the zombie making it look like they’re coming from the target.  If this is a viable zombie, this should increment the zombie’s IP ID another four.  So it should now be 8659.  The attacker then sends another probe to the zombie host, this time not spoofing its source address, to see what it’s IP ID is now causing the zombie host’s IP ID to increment one more.  And looking at the last line in the screenshot, we see that the zombie’s IP ID is now 8660 which is exactly what we wanted to see.  Now Nmap begins the idle scan.

Here you see the attacker spoofs the packet sent to the target to make it look like it’s coming from the zombie.  Then it sends a probe to the zombie host to check it’s IP ID, which in turn will cause the zombie to send a reply and increase its IP ID by one.  In the above screenshot, we see the zombies IP ID is 8662, which is two more than when we checked before.  This tells us the port is open on the target.  How do we know this?  We know that there was communication between the target and zombie before we probed the zombie for its IP ID again.  Since the port was open, the target sent an ACK to the zombie.  And being that this communication from the target was unsolicited, the zombie sent a RST packet; this increased the zombie’s IP ID by one.  So when the attacker probed the zombie again, causing its IP ID to increment one again, we saw the increase as a total of two.  This is the role the zombie host plays in an idle scan.

##Closed Port

If the port were closed on the target, our spoofed packet would’ve caused the target to send a RST packet instead of an ACK packet to the zombie.  And instead of the zombie seeing the ACK and sending a RST back to the target, it would’ve seen the RST packet and just ignored it.  Therefore it’s IP ID wouldn’t have increased during this portion.  And when the attacker probed the zombie, it would’ve seen the its IP ID only increased by one, which was caused by the probe itself.

##Filtered Port

A filtered port would have the same result from the zombie’s perspective.  But instead of the target sending a RST packet to the zombie, it’d simply ignore it.  Still though, the zombie would never receive a packet from the target, therefore wouldn’t send have it’s IP ID incremented.


And that’s the TCP idle scan!  Seeing Nmap’s packet-trace and Wireshark’s trace file during the idle scan helped me understand what exactly was going on.  I hope this write-up is able to help somebody else as well.  Now to continue on with my Metasploit book!

Standard(?) First Post

Hello World!  Sooo here’s my blog.  Here I will be blogging things pertaining to IT (I’m currently a system/network admin) and infosec (I’m working on getting into an infosec position).  Normally it’ll be things I come across during my studying that I find interesting and worth sharing, a lot will have to do with topics I needed to do more research into.  There will also be posts about solutions I’ve found that were either a pain in the ass to gather all the info for so I’m putting it all in one place, or clever fixes (IMO) I’ve come up with for certain issues I see in my job or study lab at home.  Along with sharing, typing it out in a way that I’m trying to explain/teach the reader, it’ll help embed the info into my brain better and ensure that I understand it thoroughly as well.

So here we go!