Welcome to Mapping a Network.
I'm Josh Mason, your instructor for this section.
In this lesson, we're going to cover the purpose, the process,
and then a few tools for mapping a network.
So the purpose, we're going to talk about scope and discovery.
So scope, when you start a pen test,
you're going to actually begin--
before you touch anything, before you actually
do any of the research, you're going
to negotiate with your client and determine,
what is the most useful use of you for their organization?
You're running a penetration test.
It might be you as an individual.
It might be a team.
Either way, you need to run a penetration test that actually
provides them value, provides them something
that they can then turn around and mitigate risk and harden
their systems, become more secure.
Some clients might just be looking to check a box.
Some clients might need a no-kidding penetration test
on their system.
Let's give them the benefit of the doubt.
Assume that they want a good penetration test.
But you also need to understand that if they're a company that
makes money, if they are an organization that provides
something to somebody, your penetration test,
if it goes the wrong way, if you accidentally
DoS something or knock something over,
you could take out a production system.
And they might be SOL and losing money or losing clients,
or if it's a hospital, worse things.
And we don't want that to happen.
So you need to figure out the scope of what
will provide them value while not interfering
with their business.
Once you have that all sorted, then it becomes, well,
what do you have available to you?
Are you going to be given physical access to maybe plug
into their network?
Are you going to be given a VPN connection to start out?
Or will they say, hey, come at me bro, and you have to figure
it all out for yourself?
Hopefully it's not that last one.
Without some give and take in this,
they're not going to get the value
that you can really provide.
In the end, though, we're going to take
this, a cloud with a bunch of unknowns,
and turn it into this, a network that actually
shows you something useful.
Now, the process that we're going to go through,
we'll look at physical access, sniffing, ARP, and then ICMP.
That's a couple techniques and a couple
of protocols that will help us to kind of flesh
out this overall mapping process.
So the physical access, if you are
doing a penetration test that includes physical security,
maybe testing their guards or cameras,
their access controls, then you can include that
as part of getting network access.
Or in the process of testing those things,
maybe you get access to a console, to a desktop,
whatever, and find some IP addresses that way.
Or through some OSINT--
we'll go through intelligence gathering and information
gathering in another lesson, in another section.
But through DNS records, through websites,
there's ways of finding IP addresses without even having
to touch the network itself.
Or we can get into some social engineering.
Could you get someone to tell you all the things
that you want to know?
Perhaps.
Creativity is your limit there.
And skip.
If we do have access, once we do have access to the network,
either through that VPN, that physical connection or you work
your way to a physical connection,
then the easiest way of finding out what hosts are out there,
what IP addresses, what MAC addresses are on this network
is through some passive reconnaissance,
through sniffing.
We can run tcpdump or Wireshark, or there's several other tools
for packet capture.
You could just watch the normal network traffic,
see what emails, see what websites,
see what they're uploading to file servers.
And in that, you do some information gathering
but also collect IP addresses and MAC addresses
for further enumeration.
We're going to take advantage of ARP.
ARP is Address Resolution Protocol.
It maps IP addresses to MAC addresses.
And the way it does that is sends out these messages.
Who has 10.10.1.5?
Tell 10.10.1.7, tell me.
And it'll send that out in a broadcast.
And if anyone has 10.10.1.5, they'll be like, hey,
10.10.1.5 is 00:0c:29:af:ea:d2.
And then my machine, 10.10.1.7, will add that to its ARP table.
Now if it needs to send something to 10.10.1.7 for some
reason, it knows, I need to tack on the 00:d2 MAC address
for any packets that are going out.
Well, we can do an ARP scan where
we send out all of these requests for everything
on our subnet.
It goes really fast and you get replies if ARP is enabled.
And it usually is, because that's
kind of how networks work.
Now, ARP can be turned off.
And everything can be manually configured
and everything manually added to ARP tables
but might still work.
And it might be kind of quiet, depends on what
you have running on the system.
The next thing we'll talk about is ICMP, Internet Control
Message Protocol.
Now, this protocol is used for diagnosing network connectivity
issues.
So if packets aren't making it somewhere,
if there's dropped packets, ICMP is kind of the answer.
Usually, you get a reply back of some sort of--
why things are going wrong.
There's a couple of tools that we'll use with ICMP.
One is Traceroute.
And that will show you all of the points
in between the destination and source for packets
and where things might be dropping off.
And then Ping, Ping works great.
It says, hey, are you there?
It asks for a reply.
It sends what's called a type 8 echo request.
And I think of it either like a radar ping,
like, ping, waiting for a ping back.
Or I like the analogy of someone in a dark room with a ping pong
ball.
You don't know what's out there.
If you throw the ping pong ball and it comes back at you,
then you know there's something there.
If it doesn't, then there's not something right there.
Now we're going to do that with IP addresses.
We'll throw a ping pong ball or Ping that IP address.
And if it sends a reply back, we can be like, hey,
there is something there.
If it doesn't send a reply back, there's other things.
It might still be there, but maybe reply is turned off.
Network administrators will do that sometimes
for security reasons.
Because they don't want people doing Ping scans.
Well, we're going to utilize some tools to practice
some of these things.
So we'll look at Wireshark.
We'll run Arp-scan, Ping and FPing.
And also, Nmap has a Ping function.
But we'll finish it off with the GUI version of Zenmap.
And that's what we'll cover for the rest of the lesson.
We had started out in Wireshark.
And I'm in a parent VM, but I'll bring up Wireshark.
And needs sudo privileges.
We want to look on our tap0.
We'll start a packet capture.
Now, we might not get anything initially.
So let's run a little arp-scan.
We'll come back and look at that in a minute.
But what we have is we have all these ARP commands
that went out asking, hey, who has this IP address?
Tell us, we're at 240.
Now, the neat thing we can do with Wireshark
is go up to Statistics and then Endpoints
and see all of our Ethernet endpoints.
And this gives us all the MAC addresses.
So that could be useful.
But somewhere in here, there's got to be replies.
There we go.
So 213 is at these MAC addresses.
We've got a 96, a 100, looks like they're multi-hosted.
We've got a 48, 1 and dot 6.
So that's kind of neat.
Now let's look at that arp-scan.
I just run that command.
Because ARP is sending stuff out over that layer too,
it needs sudo privileges.
And we're running it on our interface of tap0 for our VPN.
And then we're going to generate based off of our subnet.
And we could look at that subnet within ip a.
We see our tap0.
We have 10.142.111 dot--
[? we're ?] 240 on a CIDR 24 network.
So again, we could run that scan.
And we see we've got a dot 6, a dot 1,
dot 48, dot 96, dot 99, dot 100, and dot 213.
And we're not showing you, but we are dot 240.
And that's perfectly fine.
ARP's broadcasts from us, so we're not
going to send ourselves a reply.
Now we'll look at Ping.
If we were to run ping on our 10.142.111.6, which
we discovered with arp-scan, we see what we get a return back.
And we stop it.
We sent seven packets transmitted and seven received,
0% packet loss.
We can assume that dot 6 is working and it's up
and we can connect to it.
Now let's run that again with a dot 5 just
to see what the difference would be.
And we get destination host unreachable.
And if we stop it, we see seven packets transmitted,
zero received, some errors, and 100% packet loss.
So dot 5 we are not able to connect to with ICMP.
We'll now take a look at FPing.
Ping on its own is neat.
We could create a script and send
Ping out to multiple hosts.
But on its own, Ping is for one host at a time.
Fortunately, there's a tool fping.
And fping will send out pings to multiple hosts at one time
and give you a little cleaner return back.
So we want to send this out on our tap0.
We want to generate from 10.142.111.0 CIDR 24.
And we want to know all the things that are alive.
And let's go.
It's finding stuff, 1, 6--
whoa.
We're getting host unreachable from all those things.
Well, that started off well and then got a little crazy.
There's a lot of errors in there.
Errors are number 2.
So standard in is 0, standard out is 1, standard error is 2.
So we do 2 redirected to /dev/null.
We'll get the same output without any of the errors.
And there it is.
We have 1, 6, 48, 96, 99, 100, and 240.
Now, that's actually a little different
than what we had before.
I'm going to run this arp-scan real fast just to compare.
So we showed up on this ping scan for 240.
But 213 didn't show up with me.
There's a chance 213 doesn't reply to ping messages.
Let's take a look at that.
So we'll ping 10.142.111.213.
And yeah, seven packets transmitted, zero received.
So ping didn't find it.
And that can be kind of confusing.
So we used ARP, and ARP did find the host but ping did not.
That's why I showed you two different tools.
Because sometimes one works, sometimes the other one works.
I highly suggest you use both or multiples.
Now we'll take a look at doing this with Nmap.
So Nmap is a very powerful tool.
It's open source and available on all operating
systems, including Windows.
And the way you run Nmap is just with the command nmap.
And for our scan, we're just going to use tack sn.
This little guy right there, that's a dash or, in my case,
a tack.
Military background, sorry about that.
If you haven't heard it called the tack before,
that's what I'm going to keep saying.
Can't help it.
And then our subnet 10.142.111.0 CIDR 24.
And Nmap will do its thing.
And here we get 1, 6, 48, 96, 99, 100, 213, and 240.
And what's kind of crazy about all
that is that Nmap did some interesting stuff near the end.
We're still capturing.
So there was ARP that went out.
There was some TCP traffic that went out from us to 99.
Wanted to double check to see if there was any
ICMP that Nmap used.
But it's pretty neat.
Now that we've done these scans though,
if we look at our endpoints in our IPv4,
we also get this list.
And I wouldn't worry too much about these broadcasts.
Though these 169s are interesting.
We won't worry too much about that.
But again, 1, 6, 48, 96, 99, 100, 213, and 240, and a
broadcast.
So we've now identified those same IPs multiple times.
The last tool I want to introduce you to is Zenmap.
And Zenmap is a GUI version of Nmap.
It is available on all operating systems.
It's open source, also free.
All right, here is Nmap.
So we can throw in our subnet.
That's what I get, opened it multiple times.
10.142.111.0 CIDR 24.
Then over here, we'll just choose in our dropdown
the Ping skin.
Then we say Scan.
And we can see what the command is, nmap -sn on our subnet.
And we get back the same reply.
What's neat though is we can go to Topology--
and also, we get it listed over here.
But we can go into Topology and see it visually.
If we do further scans, some discovery
scans, perhaps, we might learn even more.
We'll get into that in the following sections.
And with that, we will close out this section
and move on to port scanning.