Hunting Insider Threats Part 1

LAB 2

Scenario
You are placed on a weekly hunting schedule. Using the hypothesis-based
hunting methods you learned 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

Network Configuration
 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.
Task 1. Connect to the analyst workstation
Starting the lab will connect to the analyst workstation using Remote Desktop
Protocol (RDP). This system contains the tools discussed in the course and the PCAP
files you will analyze.

Task 2. Analyze the pcaps

Utilizing your hypothesis-driven threat-hunting methods learned in the Introduction
to Threat Hunting course find and locate the threats inside the network by
reviewing the PCAPS. For this lab, our hypothesis is that the network is
compromised via a man (or adversary) in the middle attack.

Task 3. Answer the following questions

Since you are specifically hunting for a man-in-the-middle attack, review the Mitre
ATT$CK TTPs [https://attack.mitre.org/techniques/T0830/]. Detecting this type of
attack can be very difficult. The nature of a man-in-the-middle attack is to intercept
and modify network traffic in real time. Per the TTPs you should be on the lookout
for:

 ARP poisoning
 DNS manipulation
 Proxy of traffic away from legitimate sites
 Downgrade to a less secure, deprecated, or weaker protocol version

Per this technique, Once the pcaps are loaded and analyzed, using your threat-
hunting methodology answer the following questions.

1. Analysis of the 1st PCAP:

- How many devices would you consider suspicious within the 172.16.151.0/24 in
the PCAP?
- Upon quick glance, why would you consider these devices suspicious?
- Taking a closer look at the details, what would you flag as strange for each of
these devices?
- Of the suspicious devices, which would you consider a top priority to analyze
further?
- Anything you noticed regarding the web traffic from Charles' machine?
- Using another tool, analyze the PCAP further, what additional information did you
gather regarding these suspicious devices?
2. Analysis of the 2nd PCAP:
- Is there another device to add to the list of suspect devices?
- Upon quick glance, why would you consider this device suspicious?
- Taking a closer look at the details, what would you flag as strange regarding this
device?
- Can you explain what happened with the new suspicious device and the other
device that was previously at the same IP?
- Was MITM used as an attack vector?

Solution

Below, you can find solutions for each task. Remember, though, that you can
follow your own strategy, which may be different from the one explained in
the following lab.

Task 1. Load pcaps into packet analysis tool

1. First, load the Lab1-1.pcap into a tool to begin analyzing the packets
that traversed the network. Opening the PCAP in Wireshark, you would
be looking at a PCAP with over 14,000 packets. To give a quick,
automated, analysis, use an all-in-one PCAP analysis tool like such as
Network Miner.
2. Within the Hosts tab of Network Miner, you will see a list of machines.

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

What can be identified?

Task 2. Analyze the pcaps
Immediately there are some items that raise attention. One device is not
following the corporate naming convention of w####, and it has an unusual
name of "rogue1". There are also two other devices are not showing any
details. You will need to look at the details of these IP Addresses to
investigate these anomalies further.

The first device to be investigated is rogue1.

Expand the detail on Hosts tab by hitting the + icon in Network Miner.

Some details should quickly catch your eye:

- Network Miner gives us the MAC address as well as the vendor.
- What else stands out? The fact that it is not part of the domain, its showing
as under WORKGROUP.
- There is one more thing that you should have caught. That the URI
[http://www.wireshark.org] was queried via DNS.
Moving to the next suspicious device, follow the same procedures outlined in
the previous step.

This device does not show a hostname and Network Miner was unable to
detect what OS is running on this device.

There is a strange MAC address and the vendor for the NIC is unknown.

Looking further at the details there is also abnormal TCP traffic.

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.

Looking at the third device on our suspicious device list, the details are
similar from the previous device.

Information gathered thus far:

4. In Network Miner look at the Sessions tab for more information regarding
these three devices.

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

Nothing is showing for 172.16.151.103, try the other two devices. 6. Apply
filters for the two other devices.

7. No results are coming up, remember that under the Hosts tab there are
149 packets sent/received between 172.15.161.125 & 172.15.161.150.
What's going on here? Go back to the Hosts tab to investigate. 9. Under the
Hosts tab look at the details for these two devices again and look at the
information for Incoming Sessions and Outgoing Sessions.
It shows 0 sessions. You can look at this closer within Wireshark but for now,
continue to gather information from Network Miner. 10. Remember that
172.16.151.103 made a DNS query for the Wireshark website. Look at the
DNS tab within Network Miner and apply a filter so to focus on the device of
interest.

- Packet 14599 confirms the DNS query for the URI and a servfail as the
DNS answer.

- At this point it cannot be confirmed 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 the investigation, look at the Files tab.

1. At frame 14221 there is an index.php.6F2E74C2[27].html file with the

source host as 172.16.151.201 and the destination host as
172.16.151.101. This is Charles' machine. Right-click this file and
choose Open File.

o There is a login page called "Simple Invoices" and it's powered

by Simple Invoices. This appears to be a login page for an
intranet portal.

o If the communication was HTTP, then 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.

o At this point, even though there are 3 devices of interest, 1

device is a priority. That device is rogue1, 172.16.151.103. Now
load the PCAP into Wireshark and take a closer look at the packet
details.

2. Once the PCAP loaded into Wireshark, apply a filter to focus on rogue1
and monitor the captured traffic.
 o Scroll down towards the end to see the standard UDP/53 DNS
Query for www.wireshark.org but nothing else pops out
regarding these packets.

o Let's look at the other two devices of interest.

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

o The packet using SSL stands out, but there is no three-way

handshake needed to establish the encrypted communication
between the two devices.
o Let's look closer at this packet in Wireshark by viewing the
details of the packet.

You should have noticed the following: - Strange MAC addresses observed in
Network Miner (dead beef and beef dead).
- TCP ports 80 & 443 are being used.
- Within Wireshark details where Secure Sockets Layer is, nothing can be
observed.
Remember if this field is empty it is a red flag
16. Before following the TCP stream, look at all the packets in tcp.stream eq
224. Besides the ports, what else can be observed in these packets?

Remember that Wireshark will highlight packets based on certain criteria.

These packets have errors.

| Criteria | Reason
|
|:-----------------:|-----------------------------------------------------
------------------------------------|

| Packet Error | TCP Retransmission

Packets |

| Only SYN Flag set | Incomplete Handshake, only retransmission packets do

not SYN connect when port scanning |

Wireshark analysis notes:

 172.16.151.103: No further regarding the DNS Query to the URI.

 More details about the communication between 172.16.151.125 &
172.16.151.150 are found:
o 1 SSL packet, but no handshake and no details for SSL within the
packet.
o TCP Retransmission packets using ports 80 & 443, SYN flag set.
o Not a port scan, because it was using same ports in each packet.

Thus far, PCAP #1 Summary:

|IP Address | Notes

|

|:---------------|----------------------------------|

|172.16.151.103 |Possibly a Windows box which seems purposely named

rogue1 <br> Not following corporate naming convention & not part of the
internal domain <br> A DNS Query from that machine was made for
www.wireshark.org

|172.16.151.125 & 172.16.151.150|No OS details or hostname for these

devices<br>The NIC vendor is unknown but the MAC addresses seem to be
fake, Dead Beef and Beef Dead<br>149 TCP Retransmission packets from port
80 to port 433 with SYN packet set<br>No SSL details in initial packet to
start off 'transmission'

|172.16.151.101| Accessed a login page using an unencrypted channel, port

80.|

Analysis is working towardsconfirmationof thehypothesisthat there is an

insider threat (MITM) attack occurring. Supporting evidence includes: - That
172.16.151.103 is possibly a rogue device plugged into the network. - That
172.16.151.125 & 172.16.151.150 are possible rogue devices that are not
responding like 172.16.151.103 is. - 172.16.151.101 is a rogue machine that
might be using Wireshark to find admin credentials.Theoretically, at this
point, as a threat hunter, you need to establish what these devices are and
what the adversary is doing at these endpoints. Right now, you only have a
working theory 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 follow the same steps as in
PCAP 1. Load the 2nd PCAP into Network Miner. Below is a snapshot as to
what will be found. Keep in mind to focus on the 172.16.151.0/24 network.
Information found in this PCAP file

|IP Address |Notes|

|:--------------|:------------------------------------|

|172.16.151.101 | Is now called **[kali] (Windows)** <br> 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

172.16.151.103|Rogue1 again, defined as a possible threat from PCAP 1

172.16.151.125 & 172.16.151.150| Defined as a possible threat from PCAP 1

2. Now review the details of this host to see if it's really a Kali box.

Analysis of PCAP 2 shows the following correlation to information found in

PCAP 1: - 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, some
differences can be observed.

PCAP #1

> > PCAP #2

In PCAP #2 you should see A LOT of references to www.kali.org and under the previous IP
Address. It is missing some data for W0100 but there is an internal IP for a smaller network. This
could indicate a home LAN or lab. This leads us to believe that this is a personal edition of Kali
and it is probably running on a computer system plugged directly into the network. One question
to ask is why are the MAC addresses the same? - The user could have used an obfuscation
program, such as macchanger. This would all the user to duplicate the MAC address of another
actual device on the network. - It is possiblw, though unlikely, that the individual plugged the
device into the network and someone obtained the same IP as Charles's device which will cause
IP Address conflicts. Perform further analysis to see if you can obtain clarification with further
analysis. Refer to the host tab in Network Miner. You can see the entry for Kali Linux.

1. Open the Sessions tab to see if there is any information about the
suspect devices. Apply filters to focus on the IP address to be analyzed.
Since this is a Kali box, that should pop up it up as a top candidate in
your investigation, passing rogue1. If you compare a known
unauthorized penetration testing distribution vs a packet analysis tool
the pentesting devices warrant higher investigative priority. This
screenshot demonstrates what could have happened with the original
machine at 172.16.151.101 and this Kali box.

Look at frames 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's box, and as a result, the data recorded seems tainted [kali]
 (Windows). Additional analysis of this network traffis with Wireshark is
needed.

2. Load the PCAP into Wireshark and apply a filter so to see only seeing
packets for 172.16.151.101.

3. Make sure the packets are sorted in ascending order, starting with
packet 40. Note the packets start right into a TCP session on port 80
and that it is an HTTP GET Request for the login page for Simple
Voices.

4. Search for the MAC address and apply filters in order to try to find
when the Kali box jumped into the network.

ip.addr == 172.16.151.101

Charles' Box

eth.src == 00-0C-29-61-E9-14 && ip.addr==172.16.151.101

Kali Box

eth.src == 00:0c:29:f8:96:04 && ip.addr==172.16.151.101

This investigation reveals that the Kali box jumps into the network at packet 294. Investigate this
traffic further: Look for 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. Using your threat-hunting research skills, identify some Linux distros to perform this
type of scan. This helps us conclude that this is a Linux box and not a Windows box. There are
some DNS query packets for kali.org. It is possible that the tool might have performed these
queries when the pentesting distribution was launched. It's possible, the suspect doesn't even
know these calls are made automatically upon launch. Next, search for the ICMP packet.

eth.src == 00:0c:29:f8:96:04 && ip.addr==172.16.151.101

1. Look at that packet further. This packet still pertains to DNS queries
and responses.

Packet 811 is odd. There are 2 RDP packets with the RST flag set.
 To investigate this further, alter the filter and focus on 172.16.151.101.

2. Adjust the filter

ip.addr == 172.16.151.101.

Looking closer at this set of packets to see a struggle for this RDP
session between Charles's machine and the Kali box. After this, it
appears that the Kali box goes quiet.

3. Now focus ONLY on the MAC address of this Kali box, excluding the IP
address.

At packets 824, 2300, and 2466 the theory is confirmed. The suspect
plugged Kali box into the network. Note: A quicker way to spot this
would have been to look at all the ARP packets, by using a filter.

arp
 Can this be a MITM attack instead of a simple DHCP conflict?

4. Adjust your filter, and look at the results:

eth.src==00:0c:29:61:e9:14||eth.src==00.0c:29:f8:96:04) && arp

You should be able to see the back & forth struggle from the ARP
packets. This would indicate a fight for the IP address. Packets 805 &
806 would indicate ARP poisoning. But, if this was the case of an
intentional ARP Poisoning attack, you would not see the back & forth
struggle between the two devices unless the attacker wants you to
believe that.

5. Go back to Network Miner and continue analyzing the packets. The IP

address 172.16.151.101 can point to two devices when in the PCAP.
Look in the Sessions and DNS tabs to investigate activity.

There are no new results regarding the IP Address under investigation.

Review the other tabs for any information regarding this IP Address.

6. Click on the Credentials tab.

 This will reveal that Charles's credentials were passed in cleartext and
provide strong proof that two rogue devices were on the network
today, one of them being a Kali box. At this point it cannot be clearly
determined to 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.

7. Review the Parameters tab. There is a lot of information to go through,

even using the IP address as the filter, but if you use the word pass as
a filter, the credentials can be retrieved.

This will reveal the same IP address that is currently under

investigation. At this point, the findings should be reported using
appropriate processes, so that remediation measures can be taken--
such as resetting passwords. The hunt is not over. The next step is to
attempt to find the rogue devices, the culprit or culprits, and identify if
they're still on the network. Further analysis of this PCAP should be
completed to find any other possible threats and the other IP
addresses of interest on our list. Investigate them with Network Miner.

8. Add a Network Miner 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.

9. Next, do the same within Wireshark for the suspect IP Addresses

172.16.151.103, remember, this suspect is targeting 172.16.151.101.

10. Next let's look at the new IP on our list, 172.16.151.132. You
should only locate two packets and the MAC address for the the Kali
box. This should have been picked up in Network Miner > Hosts.

11. Finally let's look at the last two ips within Wireshark.
The results of these last 4 steps do not reveal and additional information that will further your
investigation.

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? - 3

1. Upon quick glance, why would you consider these devices suspicious?

1 machine had a host name of rogue1.

o
2 machines didn't show a host name.
o
2. Taking a closer look at the details, what would you flag as strange for
each of these devices?

o1 machine was called rogue1 and isn't part of the domain. Plus, it
made a DNS query for the Wireshark website.
o 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.
3. Of the suspicious devices, which would you consider top priority to
analyze further?

Rogue1 due to the DNS Query to Wireshark website.

o
4. Anything you noticed regarding the web traffic from Charles' machine?

oUsing HTTP TCP/80 to access a login page.

5. Upon further analysis, using another tool, what additional information
did you gather regarding these suspicious devices?

o SSL handshake not found within packets.

o Secure Sockets Layer field empty.
o Ports 80 & 443 used but typically these are destination ports, not
source ports.
o TCP Retransmission packets, SYN flag set only in all packets.
PCAP #2: 1. Do we have another device to add to our list of suspect
devices? - 172.16.151.101 - 172.16.151.132

1. Upon quick glance, why would you consider this device suspicious?

o The host name of the machine at 172.16.151.101 is running Kali.

o The other IP doesn't have a host name but has the MAC of the
Kali box.
2. Taking a closer look at the details, what would you flag as strange
regarding this device?

o Machine at 172.16.151.101 is showing signs of a Kali box. We

see that it queries DNS names to kali.org.
3. Can you explain what happened with the new suspicious device and
the other device who was previously at the same IP?

o IP conflict. Unsure if intentional or accidental.

4. Was MITM used as an attack vector?

o 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 a threat researcher
to flag information that can be investigated further in Wireshark or
another analysis tool.
2. Certain applications and operating systems, 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:
o DHCP/IP conflict
o ARP Poisoning [read more about it and understand how it
appear]
Hunting Insider Threats Part 2

LAB 2

Scenario
You are placed on a weekly hunting schedule. Using the hypothesis-based
hunting methods you learned 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

Network Configuration
 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.
TASK
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 PCAPs and answer the

following questions
Once the PCAP is loaded into the selected tool, answer the following
questions based on your analysis of the PCAP.

Analysis of the 1st PCAP:

1. What unusual port stands out within the Hosts tab?

2. What application uses this port by default, unless changed?

3. What other method could we have obtained this information without

resorting to Google?

4. Did Alice access the server? If so, what page did she navigate to?

5. Any details from the previous PCAP was manifested within this PCAP?

6. In Wireshark, inspect the communications between Alice & Bob, are

they encrypted?

Analysis of the 2nd PCAP:

1. What suspicious device do we see within the Hosts tab? Within

Network Miner, can you locate what actions were conducted on this
machine that would make this device priority #1?
2. What similarities did we uncover between Bob's device and this new
device?
3. What did Bob do from his machine before his signed off?
4. What attack is seen once the new device enters the network?
5. The device that accessed the domain controller, what is the user
account logged into this device?
6. What username was used to authenticate into the shared folder on the
domain controller?
Solution
Below, you can find solutions for each task. Remember, though, that you can
follow your own strategy, which may be different from the one explained in
the following lab.

PCAP #1

1. We open the 1st packet in Network Miner to get an overview of the

contents of this packet. Remember we're just focusing on
172.16.151.0/24 network.

We see that some of the tabs across the top has some information for us to
look at. At quick glance, we're not seeing any rogue machines on our subnet
but we already know that we're possibly hunting a malicious insider or
insiders. Let's see if anything stands out within this tab by expanding the
details for each machine.

1. We first look at 172.16.151.100 [W0001].

We see an open TCP port on this machine, 6475 and it's communicating with
another machine within the subnet on port TCP 49201. Now remember in the
module that as hunters we're "native to the land". We're supposed to know
what is 'normal' within our network. Within this particular subnet is it normal
for 172.16.151.100 to communicate to 172.16.151.102 using these ports?
Let's see if we can figure out what application uses this port.

1. Let's Google 'TCP port 6475' and see what comes up.

One entry on this page should quickly stand out 'BeeBEEP (Secure Lan
Messenger)'

When we click the link we get the information we were seeking.

Since we're here let's read the description for this application.
Let's go back to Network Miner and see things from Bob's end,
172.16.151.102 [W0002].

1. Let's expand the details for 172.16.151.102 and see if we see evidence
of BeeBEEP.

So, at this point we can safely conclude that Alice and Bob were using
BeeBEEP to chat within the network securely. This application uses AES
encryption and we should not be able to read the packets in Wireshark to
see what they were saying to each other in their chat sessions. If the
machines are still then we can probably conduct forensics on the machines,
such as memory analysis to see if we can get any chat session data or
maybe the logs are still on the machines. Now if they're using this
application as a secure channel did they leave the default port set on
purpose or by accident? If the port would have been changed, would there
have been another clue to let us know they were using BeeBEEP to
communicate? Let look at the DNS tab to see if we see anything.

1. Click on the DNS tab and add a filter to focus only on the machines of
interest, either 172.16.151.100 or 172.16.151.102.
We see a DNS query to the Sourceforge page we were just at,
beebeep.sourceforge.net. So far 2 applications (Wireshark & BeeBEEP) and 1
operating system (Kali), referring to the previous labs, has given themselves
away via DNS queries. Now within this packet our focus should be Alice
(172.16.151.100) and Bob (172.16.151.102). Let's see if we can find any
other interesting findings about these machines within Network Miner.
 1. Let's open the Sessions tab and see what we find for Alice and Bob's
machines.

Alice has shown some interest on the XAMPP server. Let's see what pages
she accessed by viewing the Parameters tab.

1. Click on the Parameters tab and use Alice's IP as a filter.

We see that Alice was on the Dashboard page on the XAMPP server. Doesn't
seem like she navigated to the Simple Invoices page though. If we go back to
the Hosts tab and look at the XAMPP server, this would have been noticeable
as well.

1. Click on the Hosts tab and expand the details for 172.16.151.201. Look
for HTTP connects from Alice's machine.
 1. What have we gathered from this PCAP?

a. Alice and Bob are using an application called BeeBEEP for secure
chat.

i. Somehow, they were able to run this application even without local
admin rights.

b. Alice was on the XAMPP server and access the Dashboard page. i.
No security measures are in place on the server to prevent access but
it's curious as to why she would even access the page.

2. Any details from our previous PCAP manifested within this PCAP?

c. No evidence shows that the password to Simple Invoices has been

used.

i. This would have been visible in the Credentials tab.

d. No signs of rogue1 or the kali machine.

i. We would have seen something in the Hosts tab.

c. No strange communications similar to what see saw between

172.16.151.125 or 172.16.151.150.

i. We would have seen something in the Hosts tab.

3. Let's open this PCAP in Wireshark and take a closer look at packets,
especially between Alice and Bob and from their machines, such as to
the XAMPP server.

4. Even though it's tempting to just dive into the packets, we need some
direction. Let's look at the Conversations window within Wireshark.

5. In Wireshark go to Statistics Conversations. We can sort by port

number because we already know what we're looking for, BeeBEEP
communication on port 6475.

Below is a snippet from that window. We see 2 separate communications

between Alice and Bob using that port.
 1. Click on Follow TCP Stream. TCP Stream 25 or 26, depending on which
you clicked, should have opened in a new window.

We can clearly see that the contents are encrypted and we won't be able to
see what were the details of the conversation between Alice and Bob using
Wireshark. So now we have to put Alice and Bob on our radar and see if we
can see any other suspicious activity from them in our next PCAP. For now,
let's look to see if we can spot anything odd with Alice's visit to the XAMPP
server.

Going back to the Conversations window within Wireshark, let's sort by Port
again and focus on port 80. All the traffic going to the XAMPP server is
coming from Alice's IP.

1. Inspect the TCP Streams from Alice's machines to the XAMPP server.

2. Nothing out of the ordinary regarding Alice's connections to the server

but still odd.
3. At this point remember what we gathered from this PCAP as we move
to hunt our suspects within the next PCAP.
PCAP #2

1. 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 do we see so far at first glance?

 We see packets for Alice & Bob's machines again.

o Are we going to see more encrypted traffic using BeeBEEP?

 172.16.151.125 & 172.16.151.150 were back on the network.

o Are we going to see the same strange settings and traffic from
Lab 1 PCAP?
 We see a reused IP, 172.16.151.103, but a new host name W0007.

o Possibly a new company device?

 Click on Alice's machine to see what we find.
So, we're seeing evidence of BeeBEEP communication to Bob,
172.16.151.102, but we also see BeeBEEP communication to the new device,
W0007.

1. Now we need to take a look at details for W0007.

What do we see?

 This Windows machine doesn't have the same MAC address as rogue1.

o The host name and MAC address could have easily been changed
though.

o A new machine hasn't been deployed recently named W0007.

  Confirmation that BeeBEEP application used on this device to chat with
Alice.

 2 RDP sessions from this device to the XAMPP server and the domain
controller.

This device now hits our #1 priority since we see RDP sessions to 2 of the
servers on the subnet. Let's look at the other tabs for more information
about this device.

1. Open the Sessions tab and use a filter for 172.16.151.103.

3 connections via RDP to the XAMPP server and 2 were made to the domain
controller.

1. Open the DNS tab and use a filter for 172.16.151.103.

We see the same DNS query for beebeep.sourceforge.net, similar to Alice

and Bob.

1. Lastly open the Parameters tab and use the same filter.
What do we see?

 We see W0007 accessed a share on the domain controller called

'Charles'.

 We also see some important files being accessed, especially ntds.dit.

Now even though we still have Alice and Bob to look at within this PCAP,
along with 172.16.151.125 and 172.16.151.150, right now we need to keep
our focus on W007. We have enough information to begin our search in
Wireshark.

1. Open the PCAP in Wireshark. We should already recognize that the

packets we immediately are presented with is the BeeBEEP application
between Alice and Bob.

2. Scroll down a packet 85 and we see Bob make a query for W0007.

Why would Bob make a query for W0007?

1. Scroll down to packet 290 and we see ARP requests for Bob's machine
but no response.

Seems as if Bob logged off at this point. The preceding packets also affirm
this suspicion.
 1. Scroll down to packet 389.

This is where W0007 enters the network, not part of domain, shortly after
Bob shuts down his machine.

If we add a Wireshark filter for 172.16.151.103 the first packet, we'll see is
packet 404. What do we see after the machine enters the network?

1. Add filter to Wireshark and scroll down to packet 652.

We now see Alice and W0007 chatting via BeeBEEP, again after Bog logged
off his machine. Shortly after we see a connection via RDP. Let's remove the
filter and see all the packets after W0007 enters the network begins chatting
with Alice via BeeBEEP.
 1. Highlight the one of the packets in the window, such as packet 779,
and remove the filter so we can manually inspect the packets that
follow.

We see the query for beebeep.sourceforge.net from W0007, which we

already knew about from Network Miner. Let's continue scrolling. What else
do we see?

In case we didn't gather this information already, W0007 has a MAC address
of 00:50:56:3A:AF:03. In packets 790 and 791 we see Charles' machine and
the XAMPP server both showing as having the MAC address of W0007.
Furthermore, Wireshark kindly warns us of some duplicate entries. Unlikely in
our previous PCAP from Lab 1, this seems intentional and indicates ARP
Poisoning.

1. Keep manually scrolling to see what else we can gather from the
packets.

We are seeing A LOT of TCP errors between Charles' machine and the server.
If we keep scrolling we're going to continue seeing A LOT of errors between
these machines. Let's apply a filter and find another spot to apply our focus.

1. Apply filter for W0007 and let's find another spot to focus on.
At packet 8242 we see communication between W0007 and XAMPP. Let's
select that packet and clear the filter to inspect those packets.

1. Highlight packet 8242 and remove the filter so we can manually

inspect the packets that follow.

Here we see is the point where W0007 logged into the XAMPP server via RDP
shortly after performing ARP Poisoning attack. We also see that
172.16.151.125 & 172.16.151.150 begin their communication.

* In a real scenario, you should check the logs, such as DHCP logs, to see if
these machines exist. *

Now did Charles log into XAMPP after the ARP Poisoning attack? High
probability. In Lab 1 we know credentials were obtained for the web portal
and maybe the credentials were obtained for the web server. At this point we
can place our focus via a filter on W0007 and XAMPP.

1. Apply filter in Wireshark to focus on traffic between these 2 devices.

1. Inspect the traffic to see if anything pops out at you.

We know that W0007 also accessed the domain controller thanks to Network
Miner. Let's adjust our current filter and focus on the traffic between W0007
and the DC.

1. Apply filter in Wireshark to focus on traffic between W0007 and the DC.

1. Let's manually look at the packets between these 2 devices. At packet

19122 we should see something interesting.

Now we found a connection between W0007 and rogue1. The user account
logged into W0007 is called rogue. So, we can assume that the MAC address
and host names were deliberately changed but the user account wasn't
changed. Now the threat back in Lab 1 is most likely the same as in Lab 2.
These are all packets of interest so we need to keep scrolling.

1. Keep scrolling until you reach packet 19246.

What do we see?

 At this point we see a network share being authenticated as

webadmin.

 We also see a network share called charles.

 Keep scrolling until you reach packet 19307.

These packets confirm what we saw in Network Miner, W0007, is copying

files pertaining to Active Directory and the registry.
 1. Keep scrolling until you reach packet 19526.

Now we see the ntds.dit file being copied, which will give them every NT
hash in the domain, including Charles'. These hashes can then be cracked or
used in PTH attacks.

1. Keep scrolling until you reach packet 21516.

We finally see the System portion of the registry being copied. So, it's clear
what was obtained. Let's focus on W0007 by changing the filter and see what
he did after obtaining these files.

1. Apply filter and focus on traffic after RDP session to DC closed, packet
25088 or 25090.

We see continued chatting between W0007 and Alice after the files were
obtained & RDP session closed. Let's continuing scrolling to see what
happened next.

So, we see W0007 leaving the network and Alice is unable to communicate
with the device because of that. Also note that Bob's machine wasn't among
the packet traffic and he didn't log into his machine after W0007 signed out.

What do we know at the end of this lab?

  Alice and Bob have been using an application called BeeBEEP to hide
their chats via encryption.

 Alice accessed the XAMPP server and viewed the dashboard.

o No malicious attacks seen.

 A new device entered the network which is not recognized, W0007.

o Had a host name and MAC we didn't recognize.

o User account was named rogue which links it to rogue1 from

Lab1 PCAP.

 Bob queried DNS for W0007 before shutting down his machine.

 Alice chatted via BeeBEEP with W0007 after Bob shutdown his
machine, W0002.

 Evidence of ARP Poisoning found in PCAP using W0007 as for MITM.

 W0007 logged into XAMPP and DC via RDP.

 W0007 transferred ntds.dit, and associated files), via mounted network

share.

o Authentication used was credentials to webadmin (possibly

obtained via MITM).
 W0002, Bob's machine, stayed offline during this packet capture.

 Strange traffic from 172.16.151.125 & 172.16.151.150 appeared again

on the network.

o No evidence of DHCP leases for these devices. (extra info)

PCAP #1:

1. What unusual port stands out within the Hosts tab?

a. 6475

2. What application uses this port by default, unless changed?

a. BeeBEEP Secure LAN Messenger.

3. What other method could we have obtained this information without

resorting to Google?
 a. Within DNS tab in Network Miner. The application made a DNS
request to Sourceforge.

4. Did Alice access the server? If so, what page did she navigate to?

a. Yes, the dashboard.

5. Any details from the previous PCAP was manifested within this PCAP?

a. No.

6. In Wireshark, inspect the communications between Alice & Bob, are

they encrypted?

a. Yes

PCAP #2:

1. What suspicious device do we see within the Hosts tab? Within

Network Miner, can you locate what actions were conducted on this
machine that would make this device priority #1?

a. W0007. RDP sessions to XAMPP and DC. Network share accessed.

NTDS.DIT file (among others) downloaded.

2. What similarities did we uncover between Bob's device and this new
device?

a. BeeBEEP was used on this machine to chat securely with Alice as

well.

3. What did Bob do from his machine before his signed off?

a. Performed a lookup for W0007 within the network.

4. What attack is seen once the new device enters the network?

a. ARP Poisoning.

5. The device that accessed the domain controller, what is the user
account logged into this device?

a. Rogue.

6. What username was used to authenticate into the shared folder on the
domain controller?

a. Webadmin.
KEY TAKEWAYS
1. You should have realized that we took a more manual approach within
Wireshark this time around.

2. You were introduced to some new techniques within Wireshark to

quickly look for the information we're after.

a. Protocol Hierarchy

b. Endpoints

c. Conversations

3. Even though the device was logged into the domain controller via RDP,
we were able to see the folder which was shared within the RDP
session, as well as important information regarding the share:

a. The username that was used to authenticate

b. The name of the folder

c. The contents that were copied from the shared folder