Let’s say you and I went out to the local bar down the road and threw back a few beers. We would get to know each other. You would ask me what I do for a living, how’s the blog and if I had any brothers or sisters. And I would ask you about your hobbies, whether you have a family and your role at your current company.
And let’s say during our little interaction I discover that you’re the Senior Network Engineer at a large financial firm in New York City. You begin telling me how much you love your job, the benefits and salary. And then I ask you the million dollar question…
Have you taken a baseline of your network?
That’s the question isn’t it?
And what should I expect to hear?
Um, no. We don’t have time for that.
Why a baseline is so important
How can you expect to identify anomalous network activity unless you’ve studied normal activity?
For example, let’s say you have two hosts plugged into two switchports in the same VLAN. (broadcast domain) And the two hosts are exchanging files. If you setup a packet capture on a trunk link you woudln’t expect to see any traffic from those hosts. Why? Because they are on the same broadcast domain; therefore, there’s no reason why a layer 2 ethernet frame should pass over the trunk link. The hosts will simply use unicast layer 2 physical addresses to exchange data.
What you would expect to see depends on where you capture the data and how you capture it. If you setup a packet capture on the host you may get a different result then if you set it up on the default gateway.
Detecting malicious traffic without a baseline
But you don’t have a baseline.
Heck, the only time you use that word is when you’re playing a pickup basketball game on the weekends.
Even without a standard of normal network behavior we can still use our networking skills to identify suspicious activity. We’re g
That creepy smiley guy in the cubicle
You know that creepy smiley guy in the cubicle next to you? Yeah, he’s up to no good.
If he wanted to scan the network for vulnerabilities he could send a sweeping ping request to all hosts in the local subnet and then analyze the ICMP echo reply messages. But not all devices respond to Ping. So what’s the next option?
NMAP is the next option.
With NMAP you can send a send a TCP SYN request to port 80, you’ll send back a SYN/ACK if you’re running port 80. IT’s a slightly more covert way of probing the network for open ports.
So today I want to show you how to detect this sort of thing in Wireshark.
In this demonstration I’ve got a Windows XP SP3 machine at 10.0.0.2 and I’m using NMAP on Kali Linux (10.0.0.3) to do some reconnaissance. We’ll analyze the packet captures and I’ll show you exactly what you should never see on your network!
Let’s go!
Getting nasty with NMAP
Let’s start with the basics.
nmap 10.0.0.2
I setup a packet capture on the link between our victim’s computer and the switchport.
Then on my capture machine, which is a Mac running Yosemite, I right-clicked the packet list area and choose Conversation Filter and picked UDP.
This is a quick way to zero in on a specific PDU type.
Lookie here:
Ohh, what’s this? It looks like the host with MAC address 08:00:27:a7:79:8b is trying to scan 10.0.0.2 using a weird protocol called Canon BJNP.
Hmmm…
So this is a quick way to something fishy is going on.