In this video,
I'm going to demonstrate how to use Zenmap
to conduct scanning and enumeration.
For this example, I am connected directly
to the local area network of my victim machines.
So now Zenmap pops up and we can start doing our scans.
The first scan we want to do is the least intrusive,
so we can figure out what machines are on this network.
To do that, we're going to do a ping scan.
Our target for this network is going
to be the entire network,
so I'm going to use
192.168.56
.0/24
That will tell me that I want that entire subnet.
Now, another way you could write this,
is we can actually say 0-254,
which would be all of those addresses as well.
But in our case, I would like
to use the CIDR notation of /24.
Now you'll notice here in Zenmap
that we actually get the command-line syntax for Nmap,
right here shown for us.
So Zenmap is going to use Nmap to do the work for us,
but then it's going to take that detail
and bring it back to us in a graphical format.
Now, right now our profile's selected as the intense scan,
and that's going to be way too intensive
for what we're trying to do.
So we're going to go down and select a ping scan instead.
Notice that the ping scan is just -sn
and the IP address range that you want.
And now I'm going to click Scan.
Now here in this main tab,
what you'll notice is you're going to see the results
that Nmap would provide you.
In our case, all we did was a ping scan.
So it searched 256 IP addresses
and it found four of them that were up.
Those four is the server, the DHCP server we set up.
One of our virtual machines,
our second virtual machine,
and then our Kali Linux box ourself.
Now we don't necessarily know
what these two machines are at this point, we just know
that they're up and taking requests.
But since we do know that 102 is our own machine,
we don't need to scan that one anymore,
because we don't need to attack it.
We want to attack these other two machines.
So what we're going to do is
we're going to take it a step further.
And we're going to start doing different scans
as we can gather different information.
Now, if you notice, if I click on the Ports/Hosts tab,
there's no ports yet
because we haven't scanned any ports.
We've only done, "Is this machine up or down?"
But here we can see in the topology, our network,
and you'll see that there are four hosts connected.
And we can also do a fisheye
that makes it a little bit easier to see.
You can see that we do have four hosts on the network.
We have the three machines plus the one DHCP server.
Now if we look at host details,
all we know is the status that it's up.
The only reason we know that is because it did a ping,
we haven't scanned any ports yet.
This is important to realize.
So let's go ahead and go back to our Nmap output,
and let's try a more intensive scan,
but only targeting it to the two machines
that we want to look at, which were: 101,
excuse me, 100 and 101.
And from here we're going to do what's called a quick scan.
Now if you notice here, the quick scan is going to do some
of the most common ports for us
and find what information we can about this.
So let's go ahead and do a quick scan.
So here's what Nmap would've given you if you were doing
this in the command prompt, the scan report for 101.
And if we look at 101, you'll see all
of these ports are open.
That is a lot of open holes that may be vulnerable for us
to do exploitation later.
Now if you notice that 192.168.56.100,
all the ports were filtered.
And that's interesting to note, because we're going to have
to take a look at that machine later as we go forward.
But with the quick scan, we have identified
that this 101 is a very vulnerable box.
Now if we look through it,
we're going to see some port numbers,
and those ports are going to be
important to help us identify
what this machine is.
So as I look through it, I see that we have FTP
and SSH and Telnet.
Those are common to Windows and Linux,
but the ones that aren't are things like rpcbind 111,
this 139 and 445,
those are common of Microsoft and Windows machines.
Notice though, that there's not a 135,
which is another NetBIOS port
that's commonly seen on Microsoft.
So what this is telling me is that this, now this machine,
which I think is Linux, is running some Microsoft services,
and they're probably running Samba
to do file sharing with Microsoft.
If it had 135, 139, and 445,
I would assume it's a Windows machine,
but we're going to be able to determine it later
when we do our enumeration.
As we keep going on, we'll see the login and the shell,
again, very common Linux things.
We also have MySQL.
We have a VNC player and X11,
X11 is an extremely common Linux thing.
So that again, is one of those things
that tells us it's probably Linux.
Now, if we click on the Port/Hosts tab,
there's an actually an easier way
to see all this information.
So if I click on the host I want to look at,
and I click on the Port/Hosts,
101, you'll see that I have open and close states.
In this case, all these were open ports
that we're looking at, the port number, and the FTP.
So it makes it a very easy to see graphical representation.
Now if I click on Host Details, it doesn't know what type
of host this is yet, but it did find
that there was 82 closed ports and 18 open ports,
and we did look at a hundred ports,
which was pretty noisy of us.
You could see under Scans, this is the history
of the scans we've done before, we did our ping scan,
and now we've done our quick scan.
Now if we want to get a little more intrusive,
we can do what's called an Intense scan.
And what we're going to do is do an Intense scan,
and then we're going to hit Scan.
Now, the Intense scan is going to look at the open ports
and the closed ports, and it's also going to try
to do some basic enumeration for us to try to figure out
what this machine is or isn't.
So in our case, we're looking at it,
we're doing a stealth scan right now.
You can see that.
And this scan will take us a little bit longer,
because it's going through a lot of information.
One of the things it does try to do is it tries
to do an OS detection.
It was unable to do an OS detection
of the .100 system.
Again, with the text-based information,
it's going to give you a lot of information,
and we can go through each of this individually if we want,
but all of this is going to be shown
in a much more graphical format
for us to use as we move forward.
So let's go ahead and go over here to the ports,
and then click on the host.
If you notice over here our OS changed
on a .101 machine, that Metasploitable machine.
If you'll notice, we have a little Linux icon here.
We now see all of the open ports again,
but notice the difference here from before,
not only is it FTP,
but we know that it's vsftpd version 2.3.4.
This is that enumeration piece.
You'll see that our Apache is version 2.2.8.
You'll see that they were running Samba,
which again, Samba Debian is a Linux version
of file sharing to allow us
to share with Windows Workgroup users.
So our guess of this being a Linux machine
did pan out to be right.
In this case, we have MySQL version 5.0.51.
And again, these are all important to know,
because we can take this information
and search the CVE database
and be able to find out what known exploits there are
for these particular services.
So this is all part of that information gathering stage
for us to plan our attack.
And then we're going to move further down.
You'll see here we have a Metasploitable root shell.
We have IRC channel, Unreal IRC deamon,
and again HTTP with a Tomcat Coyote JSP engine on Apache.
So we also have another FTP up here on port 2121.
So lots of different things that we can go
after as we start attacking this machine later on.
Now let's take a look at that Windows machine we had
and you can see here no ports were identified.
If we click on Host Details, it was unable
to identify the fact that this was Windows.
And if we go to Linux, you'll see
that this not only was able to figure out that it was Linux,
but that it's most likely Linux 2.6,
somewhere between version 9 and version 33.
That's going to go and it gives us an accuracy used
based on the ports that it saw.
So based on what ports it had,
and the responses it received from those,
it's able to tell us with a hundred percent accuracy
that this is Linux 2.6.
So based on the ports used
and the way that it responds, it understood
that this was Linux with a hundred percent accuracy.
So it did a lot of that enumeration for us.
Now, Windows has not been responding.
Let's go take a look at our Windows machine
and see why that is.
Let's go into our Control Panel.
We'll go to our Security Center.
So you'll notice the Windows Firewall was on.
We're going to go take a look at the Windows Firewall,
and see if that's the reason why it's not responding to us.
So in this case, we have the firewall on,
and the only exceptions are the ones in the Exceptions tab.
If we look here, there wasn't a whole lot of exceptions.
If you notice, File and Print sharing was not an exception,
let's go ahead and let that be an exception right now,
because most home networks only use file and print sharing
to be able to share files
and printers across their network.
And then let's hit, OK.
Now, let's go back and try our scan again.
So now that we've set the exception on the firewall,
we're going to scan the Windows machine again using
that Quick scan, that's going to do the
100 most common ports.
So we'll scan that machine.
And you can see now,
because we've opened the Windows File Sharing
and allowed that exception,
that we can now identify port 139
and port 445 as part of that machine.
Now, if we go to the Host Details,
let's see if we can figure that out.
We still can't figure that out yet, so we're going to have
to do a more intensive scan.
We'll go back here, and do an intense scan on 100,
just the one machine, and we'll scan again.
Now it's discovering the open ports on 139 and 445.
It's going to do a SYN stealth scan to try
to be a little bit sneaky for us as it goes
through 1000 commonly looked at ports.
Now, if they happen to be looking at this network traffic,
they're probably going to see this
because going port one, port two, port three, port four,
and going all the way down,
you're going to end up seeing something.
The other thing, because this is an intense scan,
it's actually using 138 specific scripts as it goes through
and does this, this is how it's able
to do things like the enumeration for us,
figuring out what ports were open is fairly easy
with a scan, but now it's actually
going to use those different scripts.
It's going to see those open ports,
and based on the way it responded from each of those ports,
we're going to be able to determine what version
of the operating system it's using.
So as we scroll up here in our text,
we can see some information that was found from the scripts.
Again, port 135 and 445, we believe it's Windows XP
based on the way it responded.
We also get the MAC address,
and based on that MAC address, we know it's a virtual box.
In this case, we also can see the operating system scan
was unreliable because they couldn't find
at least one open and one closed port.
They only found those open ports.
The firewall blocked the rest of the ports from us,
but they believe that it's Microsoft 2000 or XP.
Now, why would it be 2000 or XP?
Well, Microsoft XP
and Microsoft 2000 share a common code base,
just like Windows Vista and 2003 share a common code base,
Windows 7 and 2008, both share a common code base,
2012 and Windows 8 also share a common code base.
So as they move forward in these,
you can start seeing this overlap,
and you'll a lot of times get one where it thinks it's one
or the other or both.
Now in this case, it did a fairly good job.
It realizes it's either Windows XP Service Pack 2
or Service Pack 3, or Windows 2000 Service Pack 4.
In this case, it wasn't able to do the prediction
through TCP sequence,
but it can do it based on the information
received from the port scans.
Now, as we scroll down,
we had some enumerations run as well.
In this case, it did a NetBIOS check.
It found the name of the computer,
the name of the computer is John's PC.
It also gave us the fact
that he's in a workgroup, not in a domain.
We also know the fact
that we're still again using Windows XP
based on SMB that we found,
SMB being the file sharing,
and then it did a trace route.
In our case, the trace route goes immediately there,
because we're on the same network.
After it did all the scanning,
it runs through a couple of other different reports
and scripts, tries to find as much information as it can,
and it did all of that scanning
in about 50 seconds for one host.
This is important to know,
because if you're doing an intensive scan,
it does take some time.
This was on a network that was on the same network,
on the same machine, meaning it was very quick.
If I had to go all the way across the Internet
to another host, and I was scanning numerous hosts,
that time goes up.
The more time you're spending,
the more packets you're sending,
the more likely you are to get caught.
In our case, we sent out 2035 packets,
but we only received 15 back.
So the chances of us getting seen was 2035 times
that we sent information to them.
There are ways we can be a little bit
more sneaky with these tools,
it just depends on the profiles we use
and the way we configure them.
Now, as we go into Ports/Hosts,
and we click on our Windows tab here,
the .100 machine, you'll see the fact,
again, based on that text output we had,
in a nice graphical format that we can see.
We then go into Topology,
and we now see that there is some sort of a lock on this,
meaning that there was a firewall or some sort.
And then we're going to go here to the Host,
and here we can see that we scanned 1000 ports,
and of those only two were open and 998 were filtered.
Filtered means that there was some sort of firewall
there blocking us.
Again, the accuracy, the fact that we are Windows 2000
or Windows, very accurate in this case,
and they do that based on the port that they saw.
The one they made their decision on was 139,
which was a NetBIOS file sharing.
And the class is Windows 2000.
And as I said before, Windows 2000,
Windows XP share a common code base,
they answer up the same way,
so they look very similar in traffic.
So as you can see, we can be very invasive
or very quiet in our scanning techniques.
It really depends on the level
of information that we're trying to gather.
The question now becomes:
"How quiet do you want to be in your hack?"
Well, that's going to depend on why you were hired
by the organization in the first place.
Are they looking for a realistic hack
to challenge their defenders and find their weaknesses?
If so, then you would want to be very, very quiet
to give them a realistic threat.
But if you were tasked to provide the defenders
a simple emulation of an adversary,
of a script kiddie, you'd want to be really noisy,
and that way,
they can find you quickly and take you down.
It really depends on the intent of the assessment.
Again, these tools can be used very sneakily
due to the customization, or very loudly.
It all depends on how well you understand your toolset,
your intent, and your method during the hack.