Hunting Insider Threats

Part 1
Lab 2

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 1

 SCENARIO
You are placed on a weekly hunting schedule. Using hypothesis-based hunting you want to
hunt for insider threat activity. You decide to capture network traffic from various subnets.
You are tasked to review some of the daily PCAP files.

LAB OBJECTIVES
The objective of this lab is to read the PCAP file and identify any abnormal or malicious
traffic. You will need to answer the questions below after analyzing the PCAP files.

LEARNING OBJECTIVES
The learning objective of this lab is to get the student comfortable reading PCAP files and to
identify potentially malicious network traffic using the tools discussed in the module. The
student will be able to accomplish this using the information on how to spot
normal/abnormal traffic patterns based on specific protocols discussed within the module.

RECOMMENDED TOOLS
• Network Miner
• Wireshark

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 2

 NETWORK CONFIGURATION
Lab Network: 172.15.161.0/24

• You:
o IP: 172.16.151.50
o RDP Credentials: elshunter:ahuntingweg0!
• Alice’s Machine:
o Machine Name: w0001
o IP: 172.16.151.100
o MAC: 00-0C-29-5B-2D-60
• Bob’s Machine:
o Machine Name: w0002
o IP: 172.16.151.102
o MAC: 00-0C-29-2E-14-E5
• Charles’ Machine:
o Machine Name: w0100
o IP: 172.16.151.101
o MAC: 00-0C-29-61-E9-14
• Domain Controller:
o Machine Name: dc
o IP: 172.16.151.200
o MAC: 00-0C-29-D2-21-41
• Internal Server:
o Machine Name: xampp
o IP: 172.16.151.201
o MAC: 00-0C-29-3A-A2-FA

*Ignore any other traffic within that PCAP that doesn’t pertain to the internal lab
network and any IPv6 traffic. *

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 3

 TASKS
TASK 1. LOAD PCAPS INTO PACKET ANALYSIS TOOL
Download the attached PCAPs and load them into one of the packet analysis tools discussed
within the course to begin packet analysis.

TASK 2. ANALYZE THE PCAPS

TASK 3. ANSWER THE FOLLOWING QUESTIONS
Once the PCAPs are loaded and analyzed, answer the following questions.

Analysis of the 1st PCAP:

1. How many devices would you consider suspicious within the 172.16.151.0/24 in the
PCAP?
2. Upon quick glance, why would you consider these devices suspicious?
3. Taking a closer look at the details, what would you flag as strange for each of these
devices?
4. Of the suspicious devices, which would you consider a top priority to analyze further?
5. Anything you noticed regarding the web traffic from Charles’ machine?
6. Using another tool, analyze the PCAP further, what additional information did you
gather regarding these suspicious devices?

Analysis of the 2nd PCAP:

1. Is there another device to add to the list of suspect devices?

2. Upon quick glance, why would you consider this device suspicious?
3. Taking a closer look at the details, what would you flag as strange regarding this
device?
4. Can you explain what happened with the new suspicious device and the other device
who was previously at the same IP?
5. Was MITM used as an attack vector?

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 4

SOLUTIONS

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 5

TASK 1. LOAD PCAPS INTO PACKET ANALYSIS TOOL
1. First we need to load the PCAP (Lab1-1.pcap) into a tool to begin analyzing the
packets that traversed the network. If we open up the PCAP immediately in
Wireshark we’ll be looking at a PCAP with over 14,000 packets. It’s recommended
that we should open up the PCAP in an all-in-one tool like, Network Miner, to get a
quick overview of the contents of the PCAP file.

Within the Hosts tab of Network Miner we can see a list of machines.

(The snapshot above is only reflecting the machines of interest, within our internal network.)

What can we identify?

• 172.16.151.1, we can ignore, probably a router.

• 172.16.151.100 is showing as w0001.
• 172.16.151.101 is showing as w0100.
• 172.16.151.102 is showing as w0002.
• 172.16.151.103 is showing as a Windows device called rogue1.
• 172.16.151.125 is not showing any immediate details.
• 172.16.151.150 is not showing any immediate details.
• 172.16.151.200 is showing as dc.elsfoo.labs, which is the domain controller.
• 172.16.151.201 is showing the IP as the name of the device, which is xampp.
• 172.16.151.254, we can ignore.
• 172.16.151.255, we can ignore.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 6

TASK 2. ANALYZE THE PCAPS
Immediately we see some odd things. One device is not following the corporate naming
convention of w####, and it has an unusual name of “rogue1”. Next, two other devices are
not showing any details. We’ll need to look at the details of investigate these machines
further. The first device we should look closer at is rogue1.

1. We can do this within the Hosts tab, by hitting the + icon to expand the details within
Network Miner.

Some things should quickly catch your eye:

• Network Miner gives us the MAC address as well as the vendor.

• What else stood out? The fact that is not part of the domain, its showing as under
WORKGROUP.
• There is one more thing that you should have caught. That the URI
www.wireshark.org was queried via DNS.

2. Let’s look at the details of the next suspicious device, following the same procedures
outlined in the previous step.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 7

 • This device does not show a hostname and Network Miner was unable to detect
what OS is running on this device.
• We also see a strange MAC address and the vendor for the NIC is unknown.
• Looking further at the details we also see abnormal TCP traffic.

We see the source port is port 80 and the destination port is 443. Both are typically TCP
destination ports for HTTP/HTTPS traffic and typically port 80 wouldn’t be a source port. It
can be used by an attacker to hide his traffic in plain sight.

3. Let’s look at the third device on our list that we flagged as suspicious. We see the details
are similar from the previous device.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 8

So, what have we gathered thus far:

• 172.16.151.103:
i. It’s most likely a Windows device.
ii. It’s called rogue1.
iii. It’s not part of the domain.
iv. It queried for www.wireshark.org.
• 172.16.151.125:
i. Strange MAC address, BEEEEFDEEEAD. (fake MAC addresses)
ii. Vendor for NIC unknown.
iii. Host name unknown.
iv. OS unknown.
v. Communicated with the other suspicious device, 172.16.151.150, using
ports 80 & 443.
• 172.16.151.150:
i. Strange MAC address, DEEEADBEEEEF. (fake MAC addresses)
ii. Vendor for NIC unknown.
iii. Host name unknown.
iv. OS unknown.
v. Communicated with the other suspicious device, 172.16.151.125, using
ports 80 & 443.
4. Next within Network Miner we can look at the Sessions tab for more information
regarding these three devices.

5. There are a lot of entries. We can simply apply a filter to narrow down the output. We
can start by looking at the first flagged device, rogue1 (172.16.151.103).

Nothing is showing for 172.16.151.103, but we must try the other two devices.

6. At this point we’ll apply filters for the two other devices.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 9

7. Nothing is coming up, but we recall that under the Hosts tab we saw 149 packets
sent/received between 172.15.161.125 & 172.15.161.150. So, what’s going on here? Let’s
go back to the Hosts tab to investigate.

8. Back under the Hosts tab let’s look at the details for these two devices again and look at
the information for Incoming Sessions and Outgoing Sessions.

We see it shows 0 sessions. We will need to look at this closer within Wireshark but for now
let’s continue to gather information from Network Miner.

9. Remember that 172.16.151.103 made a DNS query for the Wireshark website. Let’s look
at the DNS tab within Network Miner and apply a filter so we can focus on the device of
interest.
• Packet nr 14559 confirms the DNS query for the URI and a servfail as the DNS
answer.
• At this point we can’t confirm that Wireshark was used on this device. Either the
user was investigating the Wireshark tool or the user used the tool and upon
launching the tool, Wireshark, it attempted to access the URI to see if any updates
were available.

Continuing our investigation, let’s look at the Files tab.

10. At frame nr 14221 we see an index.php.6F2E74C2[3].html with the source host as

172.16.151.201 and the destination host as 172.16.151.101. This is Charles’ machine. We
can right-click this file and choose Open File.
• We see a login page called “Simple Invoices” and it’s powered by Simple Invoices.
This appears to be a login page for an intranet portal. If the communication was
HTTP, then we should know that the password can be obtained by sniffing the
network. Maybe that’s the intent of the person of interest sitting behind
172.16.151.103, to sniff out the password.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 10

At this point, even though we have 3 devices of interest, 1 device is a priority. That device is
rogue1, 172.16.151.103. Now let’s load the PCAP into Wireshark and take a closer look at the
packet details.

11. Once we have the PCAP loaded into Wireshark, we can apply a filter to focus on rogue1
and monitor the captured traffic.

If we scroll down towards the end we see the standard UDP/53 DNS Query for
www.wireshark.org but nothing else pops out regarding these packets. Let’s look at the other
two devices of interest.

12. Again, we will apply a filter to remove all the noise and just focus on 172.16.151.125 &
172.16.151.150.

You should immediately see that a packet using SSL stands out, but we don’t see the three-
way handshake needed to establish the encrypted communication between the two devices.

13. Let’s look closer at this packet in Wireshark by viewing the details of the packet.

You should have noticed the following:

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 11

 • The strange MAC addresses that we saw within Network Miner (dead beef and beef
dead).
• TCP ports 80 & 443 being used.
• Within Wireshark we can see the details for the Secure Sockets Layer and we are not
seeing anything there.
o Remember from the course material that if this field is empty it is a red
flag.
14. Now let’s look at all the packets in tcp.stream eq 224 before we actually follow the TCP
Stream. Besides the ports, what else can we see regarding these packets?
• Remember that Wireshark will highlight packets based on certain criteria’s. So,
we see these packets are errors.
i. Errors
1. Due to TCP Retransmission packets
ii. Only SYN flag set
1. We don’t see the TCP Handshake within the packets, only
retransmission packets. So, these packets are not SYN connect
packets normally seen when port scanning.

What did we learn after closer analysis with Wireshark?

• 172.16.151.103: We didn’t get anything further regarding the DNS Query to the
URI.
• We got more details about the communication between 172.16.151.125 &
172.16.151.150:
i. 1 SSL packet, but no handshake and no details for SSL within the packet.
ii. TCP Retransmission packets using ports 80 & 443, SYN flag set.
iii. Not a port scan, because it was using same ports in each packet.

Thus far, PCAP #1 Summary:

• 172.16.151.103:
o Possibly a Windows box which seems purposely named rogue1.
o Not following corporate naming convention & not part of the internal domain.
o A DNS Query from that machine was made for www.wireshark.org.
o Hypothesis: This is possibly a rogue device someone plugged into the
network.
• 172.16.151.125 & 172.16.151.150:
o No OS details or hostname for these devices.
o The NIC vendor is unknown but the MAC addresses seem to be fake, Dead Beef
and Beef Dead.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 12

 o 149 TCP Retransmission packets from port 80 to port 433 with SYN packet
set.
o No SSL details in initial packet to start off ‘transmission’.
o Hypothesis: Possibly rogue devices but not responding like
172.16.151.103.
• 172.16.151.101:
o Accessed a login page using an unencrypted channel, port 80.
o Hypothesis: Rogue machine might be after admin credentials using
Wireshark.

Theoretically: At this point, as a hunter, you need to figure out what these devices are and
what the adversary is doing at these endpoints. Right now, you only have an idea as to what
is going on.

Now, you receive another PCAP and load it to see if these three devices are suspect within
the latest PCAP file.

PCAP #2

1. This PCAP has only approx. 3,200 packets but we will follow the same steps as in step 1
and load the 2nd PCAP into Network Miner. Below is a snapshot as to what we seen at
first glance. Remember we’re just focusing on 172.16.151.0/24 network.

What info do we get from this PCAP file.

• 172.16.151.101 is now called [kali] (Windows).

o The hostname Kali definitely throws flags up and we need to quickly assess
the device to see if it’s a pentesting tool or not.
• We see rogue1 again.
o Defined as a possible threat from PCAP 1.
• As well as 172.16.151.125 & 172.16.151.150.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 13

 o Defined as possible threat from PCAP 1.
2. Now let’s see the details of this host to see if it’s really a Kali box.

What information does this provide?

• The MAC address is the same as the machine in PCAP #1.

• The hostname is still kali.
• Both PCAPs show that the device at this IP address accessed 172.16.151.201 on ports
80 & 3389.
• Under Host Details we see some differences:

PCAP #1

PCAP #2

So, in PCAP #2 we’re seeing A LOT of references to www.kali.org and under the Previous IP,
(missing from the PCAP #1 for W0100), we see an internal IP for a smaller network, such as
a home LAN. This leads us to believe that this is a personal edition of Kali and it is probably
running on a laptop plugged directly into the network.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 14

One question you should be asking yourself is why are the MAC addresses the same?

• Maybe the individual used a program, such as macchanger, and changed the MAC to
duplicate an actual device.
• Another possibility, although unlikely, is that the individual plugged the device into
the network and someone obtained the same IP as Charles’ device which will cause
issues.

We will see if we can obtain these answers with further analysis. Before we move to the next
tab within Network Miner, we see an entry for Kali Linux again in the Hosts tab.

3. Next let’s look at the Sessions tab to see if we can get any information about the suspect
devices. Let’s apply filters to focus on the IP we’re analyzing.

Since this Kali box popped up it’s now on top of our list, passing rogue1. Comparing the
impact of a pentesting distro on the network, versus a packet analyzer tool, the pentesting
distro wins hands down, as evident in our behavior.

This screenshot explains what could have happened with our original machine at
172.16.151.101 and this Kali box.

Look at frame nr.’s 221, 725, and 803. They show that at some point this Kali box was put
on the network and took the IP of the original box, Charles’ box, and as a result, the data
recorded seems tainted [kali] (Windows). We need to look at this further in Wireshark.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 15

4. Let’s load the PCAP into Wireshark and apply a filter so we’re only seeing packets for
172.16.151.101.
5. Make sure the packets are sorted in ascending order, starting with packet 40.

We see the packets start right into a TCP session on port 80 and it’s a HTTP GET Request
regarding the login page for Simple Voices.

6. Let’s pull the MAC address and apply some filters using that to try to find when the Kali
box jumped into the network.

Charles’ Box

Kali Box

It seems that the Kali box jumps into the network at packet 294. Let’s look at this traffic
further:

Here we see an unknown protocol, BJNP. You will encounter unknown protocols in your
Network Hunt engagements and you must do your due diligence to research it. The BJNP
protocol is a proprietary protocol from Canon where devices scan the local network for
Canon printers. Upon our TH research, we identified that some Linux distros perform this
scan. This helps us conclude that this is a Linux box and not a Windows box.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 16

We see some DNS Query packets for kali.org, just like we did with wireshark.org. Again, the
tool might have performed these queries upon the launch of the pentesting distro. And
possibly, the suspect doesn’t even know these calls are being automatically done upon
launch.

Next, we see an ICMP packet.

7. Let’s look at that one further. We see this is still pertaining to the DNS Queries and
Responses.

At packet 811 we see something odd. We see 2 RDP packets with the RST flag set.

To investigate this further, let’s alter the filter and focus on 172.16.151.101.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 17

8. Let’s adjust the filter to be: ip.addr == 172.16.151.101.

By looking closer at this set of packets we see a struggle for this RDP session between
Charles’ machine and the Kali box. After this it appears that the Kali box goes quiet.

9. Now let’s focus ONLY on the MAC address of this Kali box, excluding the IP address and
see what we get.

At packets 824, 2300, and 2466 we confirm our theory. The suspect plugged Kali box onto
the network.

Note: A quicker way to spot this would have been to look at all the ARP packets, by using a
filter.

Let’s expand our thinking, can this be a MITM attack instead of a simple DHCP conflict?

10. Let’s adjust our filter and look at this:

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 18

We clearly see a back & forth struggle within the ARP packets. This would indicate a fight for
the IP address, even packets 805 & 806 would indicate ARP poisoning. But, if this was the
case of an intentional ARP Poisoning attack, we wouldn’t see the back & forth struggle
between the two devices unless the attacker wants us to believe that.

11. Let’s go back to Network Miner and continue analyzing the packets. We know thus far
that IP address 172.16.151.101 can point to two devices when we’re analyzing the details
of the PCAP. We already know what’s going on in the Sessions tab and let’s look at the
DNS tab for anything.

Nothing new regarding the IP we’re investigating. Let’s look at the other tabs for any
information regarding this IP.

12. Click on the Credentials tab.

Here we see that Charles’ credentials were passed in cleartext and we already have strong
proof that two rogue devices were on the network today, one of them being a Kali box. At
this point we can’t clearly say if it was sniffed or not. It could have been sniffed either by
rogue1 using Wireshark or Kali using one of several ARP Poisoning tools,

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 19

13. We will see the same if we look at the Parameters tab. There is a lot of information to go
through, even using the IP address as the filter, but if we can use the word “pass” as a
filter we get the credentials easier

We see the same IP address that we’re currently researching. At this point, we should report
the findings to Charles, so he can take the necessary measures, such as resetting the
password for starters. For us, the next step of the hunt is trying to find these rogue devices,
the culprit or culprits, and identify if they’re still on the network.

*Remember we’re looking at PCAPs collected earlier in the day.

*Further analysis must be completed of this PCAP to find any other possible threats and we
still have some IPs of interest on our list. Let’s move on and check if we find anything
regarding the other IPs within Network Miner.

14. Within Network Miner add filter and look for any information in the Sessions and DNS
tabs about 172.16.151.125, 172.16.151.132, & 172.16.151.150.
• In Network Miner, we will don’t see any additional data.
15. Next, do the same within Wireshark for the suspect IPs.
16. First start with 172.16.151.103, remember this is suspect after 172.16.151.101.
• Nothing different really stands out, aside from what we already know.
17. Next let’s look at the new IP on our list, 172.16.151.132.
• For 172.16.151.132 we only see two packets and the MAC address is the same as
the Kali box.
i. (This should have been picked up in Network Miner > Hosts)

18. Finally let’s look at the last two IPs within Wireshark.
• Nothing new for 172.16.151.125 & 172.16.151.150. We see the same traffic as we
did in the previous PCAP.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 20

TASK 3. ANSWER THE FOLLOWING QUESTIONS
PCAP #1:

1. How many devices would you consider suspicious within the 172.16.151.0/24 in the
PCAP?
a. 3
2. Upon quick glance, why would you consider these devices suspicious?
a. 1 machine had a host name of rogue1.
b. 2 machines didn’t show a host name.
3. Taking a closer look at the details, what would you flag as strange for each of these
devices?
a. 1 machine was called rogue1 and isn’t part of the domain. Plus, it made a DNS
query for the Wireshark website.
b. 2 machines seem to talk to each other on ports 80 & 443. They had fake MAC
addresses and no details for host name or OS disclosed.
4. Of the suspicious devices, which would you consider top priority to analyze further?
a. Rogue1 due to the DNS Query to Wireshark website.
5. Anything you noticed regarding the web traffic from Charles’ machine?
a. Using HTTP TCP/80 to access a login page.
6. Upon further analysis, using another tool, what additional information did you gather
regarding these suspicious devices?
a. SSL handshake not found within packets.
b. Secure Sockets Layer field empty.
c. Ports 80 & 443 used but typically these are destination ports, not source ports.
d. TCP Retransmission packets, SYN flag set only in all packets.

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 21

PCAP #2:

1. Do we have another device to add to our list of suspect devices?

a. 172.16.151.101
b. 172.16.151.132
2. Upon quick glance, why would you consider this device suspicious?
a. The host name of the machine at 172.16.151.101 is running Kali.
b. The other IP doesn’t have a host name but has the MAC of the Kali box.
3. Taking a closer look at the details, what would you flag as strange regarding this
device?
a. Machine at 172.16.151.101 is showing signs of a Kali box. We see that it
queries DNS names to kali.org.
4. Can you explain what happened with the new suspicious device and the other device
who was previously at the same IP?
a. IP conflict. Unsure if intentional or accidental.
5. Was MITM used as an attack vector?
a. Pattern of MITM attack appear because of the IP conflict. Doesn’t seem to be
done intentionally by ARP Poisoning tool.

KEY TAKEWAYS
1. Network Miner gives us a good overview and allows us to spot information which we
can research further in Wireshark if we can’t within Network Miner.
2. Certain applications and OSes, such as Kali, make DNS requests to vendor-based
websites.
3. You should be able to spot certain traffic rather quickly if within future packets:
a. DHCP/IP conflict
b. ARP Poisoning

© Caendra Inc. 2017 | Threat Hunting v1 | Hunting Insider Threats Part 1 22