2.

1 Introduction

2.2 ARP Traffic

2.3 ICMP Traffic

2.4 TCP Traffic

2.5 DHCP Traffic

2.6 DNS Traffic

2.7 HTTP & HTTPS Traffic

2.8 Unknown Traffic

2.9 More Hunting Tools

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
Within this module we’ll cover how to recognize normal
network traffic when analyzing packets.

It is important to understand what is normal so you can

identify what is not normal, such as a connection to port 443
but the traffic is in cleartext for example.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

It is not feasible to sit at a workstation and look at hundreds
of thousands of packets a day.

We should have various enterprise products, even open

source, that will aide us in this task and hopefully catch a lot
of malicious traffic should it traverse our hunting grounds.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

The goal of this module is to train your eye should you ever
have to inspect network traffic, whether its live traffic or
saved traffic (PCAP).

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Wireshark

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
ARP

We’ll begin with the ARP protocol.

Again, even though we should be familiar with these

protocols we’ll just briefly explain each protocol before
analyzing traffic for each.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

ARP
ARP (Address Resolution Protocol) is a Layer 2 protocol which is
used by IP to map IP addresses to MAC addresses. ARP messages
are typically a REQUEST message and a RESPONSE message. The
message header is completed with one of the following operation
codes:
• Request (1)
• Reply (2)

You can read more about ARP in RFC 826.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

ARP

Credit: Packet Analysis Reference Guide v3.0

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
ARP
Some facts to help distinguish normal and suspicious ARP traffic.
Normal ARP Traffic Suspicious ARP Traffic
ARP broadcasts are normal from both Tens, hundreds, or even thousands of ARP
clients and servers, including network broadcast messages in a small amount of
devices at a reasonable flow. time.
ARP Request typically follows a response Two identical MAC addresses in the
but depends who is making the request. A network with different IP addresses.
network device might send many ARP
broadcasts into the network for various
reasons.
Legitimate gratuitous ARP packets. Gratuitous ARP packets sent by an attacker.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

ARP

An attacker can manipulate other hosts ARP cache tables by

sending gratuitous ARP replies. Gratuitous ARP replies are
unsolicited ARP Reply messages. In other words the attacker can
send an ARP Reply without waiting for a host to perform an ARP
Request. The ARP cache table can then contain fake information
and the attacker can send gratuitous ARP replies every 30 seconds
or so to prevent the poisoned entry from expiring.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal ARP

Below is a snapshot of 2 packets: 1 ARP Request & 1 ARP Reply.

To see the MAC Address for both the source and destination we can make a quick
change within Wireshark: View > Name Resolution > Resolve Physical Addresses.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal ARP
Here we see an ARP Request
packet.

We know it’s an ARP Request

by the Opcode, request (1), in
the highlighted line. We can
see that the device at
10.54.15.100 needs the MAC
address for 10.54.15.68 to
begin to establish
communication with it. If the
device at 10.54.15.100
already knew that MAC
address for 10.54.15.100 then
it would be contained within
it’s ARP table (ARP –a from
command line).

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal ARP
In this packet we have the
reply to the previous
packet.

This packet is the ARP

Reply packet. We can
quickly tell by the
Opcode, reply (2). Within
this packet we see that
the Sender MAC address
has been populated with
the MAC address of the
device at 10.54.15.68.
This MAC address will be
added to the ARP table of
10.54.15.100.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal ARP

The previous packets were generated within a virtual

machine.

The following packet will reflect an ARP Request within a

network using a broadcast address as the destination.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal ARP

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

ARP

Now we’ll look at an example of suspicious ARP traffic using

Wireshark. Remember the tips regarding normal and
suspicious ARP traffic:
• Normal: ARP broadcasts are normal from both clients and servers,
including network devices at a reasonable flow.

• Suspicious: Tens, hundreds, or even thousands of ARP broadcast

messages in a small amount of time.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Suspicious ARP

Here we see a snapshot of a packet capture. It shows 7 ARP Request packets sent via
broadcast. Via physical address name resolution within Wireshark the source device
seems to be a Cisco device and it’s checking on the status of various devices on the network.

*PCAP from Wireshark Sample Captures page

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious ARP

Now how would we know if this is suspicious traffic or not? How

do we know it’s not just a configuration issue within the Cisco
device or it’s normal behavior? Do you even have Cisco equipment
on the network?

Based on your response to these questions and others you’ll know

whether this needs to be looked into further. In our case we’ll
assume its normal.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Suspicious ARP

How about this traffic? Would it be considered suspicious or normal?

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious ARP

That is definitely suspicious traffic.

Even without knowing off hand what legit device can potentially have
that MAC address on your network but just based on the flow and speed
of the ARP Requests we can tell something is odd.

Starting from packet 15 the IP addresses increment by 1 and time

intervals between packets are relatively small which indicates a scan.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious ARP

Organizations might block/prevent from pinging machines

within the network but the recon phase is not foiled by this.

An attacker can use other means, such as an ARP scan, to get

the information their looking for, which is mapping the
internal network.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious ARP
If your organization doesn’t implement some sort of USB
Lockdown procedures then it’s really easy to pop in a USB
drive and launch a myriad of tools, including penetration
testing operating systems.

Going back to the MAC address remember it’s quite easy to

change the MAC address on a particular host to make it look
like a legit device so we can’t really rely on that either.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

ARP

We need to remember what is the basic behavior of ARP from

a client standpoint and from a network device standpoint in
order to know when to investigate and when to ignore ARP
traffic.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

There are other techniques in which ARP can be used for
nefarious purposes, such as ARP Poisoning (Man-In-The-
Middle Attacks).

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Wireshark Tip

Refer to the Wireshark Display Filter Reference for ARP, here,

on more techniques to filter ARP traffic.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
ICMP

ICMP (Internet Control Message Protocol) provides us

information regarding different nodes on a network. It is
typically used when troubleshooting. Utilities such as ping
and tracert utilize ICMP.

You can read more about ICMP here.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

ICMP

Credit: Packet Analysis Reference Guide v3.0

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

ICMP

Below is a visualization depicting ping. We’ll see this as packets in the upcoming slides.

Echo (Ping) Request

Echo (Ping) Response

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

ICMP

Credit: Packet Analysis Reference Guide v3.0

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal ICMP

The packet capture below reflects Echo (Ping) Requests and Echo (Ping) Replies.

*PCAP from Wireshark Sample Captures page

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal ICMP

Below we see packet details for the Echo (Ping) Request packet, packet 4.

Type 8 & Code 0 both indicate that this packet is an echo request.

Data represents a random text string.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal ICMP
Below we see packet details for the Echo (Ping) Reply packet, packet 5.

Type 0 & Code 0 both indicate that this packet is an echo reply.
Data should be the same random text string from echo request.
If so then ping utility will report success back to the command line.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious ICMP

As you can imagine the data field of an ICMP can be used as a

covert channel or even an exfil channel.

Large ICMP packets should be a red flag.

Also be watchful for unusual types/codes within the ICMP

packets followed by a request, such as a Timestamp request.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Wireshark Tip

For more information on techniques to filter ICMP traffic, you

can refer to the Wireshark Display Filter Reference for ICMP,
here.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
TCP

TCP (Transmission Control Protocol) ensures delivery of data

from the source node to the destination node.

TCP handles sequencing of packets and error recovery.

Prior to communication it would conduct 3 way handshake

between both nodes. You can read more about TCP here.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

TCP

Credit: Packet Analysis Reference Guide v3.0

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
TCP

3 Way Handshake

SYN

SYN + ACK

ACK

Time Time

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

TCP
Some facts to help distinguish normal and suspicious TCP traffic.
Normal TCP Traffic Suspicious TCP Traffic
3 way handshake (SYN, SYN/ACK, ACK) Excessive SYN packets (scanning)
Smart TCP attacks (usage of different flags)
Single host to multiple ports or single host
to multiple nodes (scanning)

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal TCP

Continued on next slide.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
Normal TCP

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal TCP

We will not be digging into every packet detail for TCP but simply be able
to recognize the important parts of TCP behavior and overall packet
structure.

One thing worth mentioning at this point is relative sequence number

and relative ack number.

The 2 following slides will display the official definition from the online
Wireshark Wiki, here.
Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
Normal TCP

“By default Wireshark and TShark will keep track of all TCP sessions
and convert all Sequence Numbers (SEQ numbers) and
Acknowledge Numbers (ACK Numbers) into relative numbers.

This means that instead of displaying the real/absolute SEQ and

ACK numbers in the display, Wireshark will display a SEQ and ACK
number relative to the first seen segment for that conversation.”

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal TCP

“This means that all SEQ and ACK numbers always start at 0
for the first packet seen in each conversation.

This makes the numbers much smaller and easier to read and
compare than the real numbers which normally are initialized
to randomly selected numbers in the range 0 - (2^32)-1
during the SYN phase.”

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal TCP

We can go into Wireshark and make a quick change, Edit > Preferences >
Protocols > TCP > Relative sequence numbers (uncheck box), to see the
sequence and acknowledgment numbers.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Suspicious TCP

Below is a snapshot of a ping sweep performed with Nmap. This particular ping sweep used
Echo (Ping) Requests and TCP SYN connections to ports 80 & 443.

Remember from the ICMP section that it was mentioned to look out for Timestamp Requests
following an Echo (Ping) Request. We are seeing that combination in the packets above.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious TCP

As mentioned in the suspicious TCP traffic checklist, many TCP SYN packets without the
corresponding SYN/ACK packets should raise a flag. Here we see a port scan.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Suspicious TCP

Wireshark gives us a helping hand to let us know something is awry with this traffic.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious TCP

Below we are looking at another packet capture performing another SYN

scan. The traffic was filtered to focus on a specific node within the noise,
10.50.97.5.

We see the following with the last 3 packets:

• SYN to start communication with 10.50.97.5
• SYN,ACK response which tells us the port is open
• RST to end communication.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

TCP

We will not cover every possible scenario.

Some more examples of suspicious TCP traffic will be seen

within the videos/labs in this module.

Please refer to NMAP page on Port Scanning Techniques,

here, to get familiar with them.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

UDP

It is worth mentioning that the NMAP page on Port Scanning

Techniques will also cover UDP (User Datagram Protocol)
scans so we will not dedicate time explaining that, please
refer to the page.

We have seen or will see UDP usage with other protocols,

such as DNS and DHCP.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Wireshark Tip

Refer to the Wireshark Display Filter Reference for TCP, here,

on more techniques to filter TCP traffic.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
DHCP

DHCP (Dynamic Host Configuration Protocol) automatically

assigns an IP address to every node on a network and allows
the devices to communicate with other devices within and
outside the internal network due to IP-based routing.

You can learn more, or freshen up, on DHCP here.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

DHCP

A few things to point out regarding DHCP (Dynamic Host

Configuration Protocol):
• Automatically assigns IP addresses.
• Also provides other information such as DNS server(s), Gateway, etc.
• DORA (DHCP Discover, DHCP Offer, DHCP Request, DHCP
Acknowledgement)
• UDP, Ports 67 & 68

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

DHCP

Below is a visualization depicting DORA. We’ll see this as packets in the upcoming slides.

DHCP Discover

DHCP Offer

DHCP Request

DHCP Acknowledgement

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

DHCP

Credit: Practical Packet Analysis 3rd Edition

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DHCP

Below we see DORA (DHCP Discover, DHCP Offer, DHCP Request, & DHCP ACK)

*PCAP from Wireshark Sample Captures page

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DHCP

We see this is a
DHCP Discover
packet. The protocol
and ports being used
look correct.

In Wireshark DHCP is
still referenced as
BOOTP. When using
display filters BOOTP
will assist you on
filtering DHCP traffic.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DHCP

This is additional packet details from

the same packet shown in the
previous slide. We see that the node
is requesting an IP address, along
with additional info from the DHCP
server. This is sent via broadcast
because the node doesn’t
know which node is the DHCP
server.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DHCP
This is the DHCP Offer
packet.
The DHCP is offering an
IP address
to the node which
requested it.

Other details are also

provided
within this packet, as
we’ll see in the
next slide, such as
netmask, lease
time, DHCP server IP
address, etc.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DHCP

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DHCP

Here is the 3rd step of

DORA.

Again we see the IP

address that is
being offered and the
IP address of the
DHCP server making
the offer.

This transaction,
0x3d13, will end with
the DHCP ACK packet

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DHCP
This is the last packet
within the transaction,
DHCP ACK. This is when
the node which made
the request accepts the
offer from the DHCP
server.

So as you might have

guessed, or known, one
of the indicators to
detect something is awry
is by checking the DHCP
server offering and
fulfilling DHCP requests.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious DHCP

In regards to suspicious DHCP traffic, we must be on the look

out for machines acting as rogue DHCP servers.

An adversary who successfully issues IP address to victims can

launch man-in-the-middle attacks against the victims.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Wireshark Tip

For more information on techniques to filter DHCP traffic,

refer to the Wireshark Display Filter Reference for DHCP, here.

Remember that within Wireshark DHCP is still referenced as

BOOTP.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
DNS

DNS (Domain Name System) is a protocol that resolves

names to IP addresses. We will not dive into how DNS works
exactly but we’ll simply focus on how to recognize normal
DNS traffic and suspicious DNS traffic.

You can learn more, or freshen up, on DNS here and here.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

DNS

A few things to point out regarding DNS (Domain Name

System):
• DNS is a query-response protocol.
• DNS traffic normally uses UDP on port 53.
• DNS traffic should go to DNS servers only.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

DNS

Credit: Packet Analysis Reference Guide v3.0

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

DNS
Some facts to help distinguish normal and suspicious DNS traffic.
Normal DNS Traffic Suspicious DNS Traffic
Port 53, UDP Traffic on port 53 but using TCP instead of
UDP.
Should only go to DNS Servers. DNS traffic not going to DNS Servers.
Should see DNS Responses to DNS Queries. A lot of DNS Queries with no DNS
responses or vice versa.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DNS

Here we see 4 packets: 2 packets for DNS Queries and 2 for DNS Responses.

Also notice that there are 2 different transaction IDs for the packets:
0xde40 & 0xa620.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DNS

DNS Transaction ID:

“A 16-bit field identifying a specific DNS transaction. The

transaction ID is created by the message originator and
is copied by the responder into its response message.
Using the transaction ID, the DNS client can match
responses to its requests.” – Microsoft Technet

In the next slide we’ll look at the packets with transaction ID 0xde40.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DNS

Below we can verify that this is a UDP packet and it’s using an expected port, 53.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal DNS

This is the DNS

Response to
the DNS Query in
packet 16. All looks
normal as far
as the DNS protocol
is concerned. A
question you would
ask yourself is would
this be a recon scan
or normal behavior
within your
network?

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal DNS
Here is another packet capture displaying various DNS queries but you see the pattern of
DNS Query followed by DNS Response.

*PCAP from Wireshark Sample Captures page

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

DNS

Now we’ll look at an example of suspicious DNS traffic using

Wireshark.

Remember the tips regarding normal and suspicious DNS

traffic:
• Normal: Port 53, UDP.
• Suspicious: Traffic on port 53 but using TCP instead of UDP.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious DNS

Here we see 3 packets & all packets share 1 transaction ID. We also see
some AXFR which let’s us know that this DNS Query is pertaining to a DNS
Zone Transfer.

Let’s take a closer look at the packet details for this zone transfer.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Suspicious DNS

Here we see details of packet 60,

which is a zone transfer. We also see
that instead of using UDP/53 this DNS
Query used TCP/53. Also in case you
didn’t know that AXFR referred to a
zone transfer the clue is within the
packet details.

So why was TCP used instead of UDP? The occurs when the response to a DNS query is too
large to fit within a single UDP packet. So the query is resubmitted via TCP to retrieve the
entire contents of the response. DNS Responses for zone transfer occur over TCP/53.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious DNS

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious DNS

DNS over TCP should be considered suspicious.

If your organization is not blocking TCP/53 it then it should at

least be monitored.

This can potentially hide malicious traffic in plain sight.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

DNS

There are other techniques in which DNS can be used for

nefarious purposes, such as DNS tunnels.

We need to remember what is the basic behavior of DNS and

know when to investigate and/or when to ignore DNS traffic.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Wireshark Tip

For more information on techniques to filter DNS traffic, refer

to the Wireshark Display Filter Reference for DNS, here.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
Let’s begin by looking at HTTP and HTTPS traffic.

Even though we should be familiar as to what is normal HTTP

and HTTPS traffic, as we probably use the Internet daily and
browse numerous websites, it should still be covered.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

HTTP

A few things to remember about HTTP:

• HTTP traffic consists of a series of requests and responses known as
messages.
– Client will make a request & server will respond.
– HTTP responses include a 3 digit status code.
• HTTP messages include a message header and body.
• HTTP uses methods to perform various operations.
– 8 HTTP methods defined in RFC 2616.
– Not all methods will be permitted by web server.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 HTTP
Some facts to help distinguish normal and suspicious HTTP traffic.
Normal HTTP Traffic Suspicious HTTP Traffic
Port 80, TCP Malicious binaries (backdoors), scripts, web
Port 8080, TCP (used as alternate) shells, etc. will use this port because
Port 8088, TCP (used as alternate) typically in all corporate environments the
port is open.
Plaintext traffic If the traffic is encrypted then most likely
it’s being used for malicious traffic.
Malicious traffic can be in plaintext as well.
Web server typically in FQDN format. Server will point to an IP address instead of
FQDN format.
Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
HTTP

Now let’s look at 2 basic PCAPs with some HTTP traffic.

We will use some display filters and introduce some other

techniques within Wireshark that you might not be familiar
with to aid us in the hunt.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

Here is a brief summary concerning the image above:

• We are seeing 6 packets (4 relating to TCP and 2 relating to HTTP).
• Packets 3-6 is the TCP Handshake. HTTP relies on TCP for reliability.
• Packet 7 we notice a HTTP method (GET).
• Packet 9 we notice a HTTP response code (200 OK).

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

In the image above we see the packet information as it pertains the different layers of the
OSI model.
• Ethernet II = MAC Addresses (SRC, DST)
• Internet Protocol Version 4 = IP Address (SRC, DST)
• Transmission Control Protocol = TCP (SRC PORT, DST PORT)
• Hypertext Transfer Protocol = HTTP

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

So far we can tell that the traffic is using an expected port, port 80.
Remember that this port doesn’t necessarily have to be port 80. An
organization can decide to use a different port altogether but we know
the standard port is 80 and if it’s port 80 then we’re expecting web
traffic.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

Here we’re looking at the HTTP section of the packet details. The HTTP method is GET
and the host is not in FQDN format. So typically IP addresses would be suspicious but
in this case its pointing to an internal server and that is normal behavior in corporate
environments. The source host has an IP of 10.54.15.100.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

If we double click the link, [Response in frame: 9], in the HTTP section of the packet details of packet 7 we’ll
jump to packet 9 which contains the packet details of the HTTP response to the HTTP request. Within this packet
we can do the same, jump back to packet 7 using the link [Request in frame: 7].

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

Above we notice a section called Line-based text data: text/html within the packet
details. We can clearly see that the packet is returning a login page for the server.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal HTTP
The same information can be obtained
by right-clicking packet 7 or packet 9 and
selecting Follow > Follow TCP Stream.

Here we see the same details but only

information from the packet that pertains
to HTTP.

Now remember that HTTP traffic is

supposed to be in cleartext, which we
have seen so far. Now let’s look at the
packet stream after logging into the internal server to see credentials in cleartext.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

Now before looking at cleartext credentials let’s test our packet analysis skills.
How many TCP streams are there in packet capture below?

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

There are a couple ways to determine this within the

Wireshark GUI:
1. Look at the TCP packets then look at source ports and destination ports.
2. Use display filters and increment the numbers to show a particular TCP
stream until nothing is displayed.
3. Select Statistics > Conversations and then click the TCP tab.
4. In the Follow TCP Stream window, at the bottom right, you can navigate
through the different streams that Wireshark detected.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

1. From the packet capture we can see different source ports so each different source
port will have it’s own TCP Handshake followed by it’s corresponding traffic.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal HTTP

2. Another way this can be done is by using a display filter and increment the number of
the TCP Stream. You will know its not a valid TCP Stream because of no visible packets.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal HTTP

3. Under the TCP tab in Conversations we can see there are 3 TCP Streams. From here we
can select a stream and choose Follow Stream from bottom right corner.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

4. At the bottom right we can see a

dropdown box and we can select the
TCP stream we would like to view.

By inspecting each of the TCP Streams

we can see from the image that the 3rd
TCP Stream (zero indexed) will contain the
cleartext credentials. This is indeed valid
HTTP traffic and typical HTTP behavior.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

2 other useful areas within Wireshark where we can look to

analyze the details of the packet are:
1. Protocol Hierarchy Statistics
– Select Statistics > Protocol Hierarchy

2. Export HTML Objects

– Select File Export Objects > HTML

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP
1. Here we can see the protocols within the packet and their rate of occurrence. Within
this image there is 1 packet we have selected which we will use as a display filter and
open the packet details in a new window to inspect further.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

Using this method we can see

interesting packet details and
again confirm its legit HTTP traffic.
Of course, in an enterprise
environment this traffic should be
encrypted, which we’ll look at
shortly.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

2. Using the Export HTTP Object feature we can quickly see pertinent information
regarding the packet. By saving the objects they can be opened later for further
inspection, especially if any binaries or scripts are exported.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTP

With the previous PCAP example, we took some time to look

at different techniques to use with Wireshark to further
analyze packet details.

With the upcoming examples, we will simply use the

aforementioned techniques without going into details on how
we reached that specific location within Wireshark.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

HTTP

Now we’ll look at an example of suspicious traffic via port 80

using Wireshark and the techniques already demonstrated.

Remember the tips regarding normal HTTP traffic:

• Typically port 80.
• Cleartext web-based traffic.
• Hosts are accessed using FQDNs instead of IP addresses.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

Before we dive deeper into this PCAP let’s take a moment to glance at it to see if we
can spot anything that might look odd.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Suspicious HTTP
This PCAP is much larger than the previous example and we can see all the juicy details in 1
screenshot but there is 1 thing that stands out right away which is highlighted below.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

In the screenshot we can quickly see normal requests to a web

pages such as news.php and newsdetails.php?id=26 then we see
another request to newsdetails.php?id=26%27.

If we URL decode %27 it corresponds to a single quote (‘). This

behavior is typical when looking for SQLi. Now was someone
looking for a SQLi or did someone make a typo in their web page
request? Let’s look at the PCAP further.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

Glancing further at the PCAP, a few packets down we can see more indications of SQLi
attempts. Looking at packets 32 and 44 we can see that the person didn’t make a typo
request at packet 20. This is indeed an attempt to find SQLi on the server.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

Remember to be an effective Threat Hunter you must know and

understand Red Team tactics and recognize malicious actions.
Something this obvious can’t get pass a hunter. He/she must think
like an adversary.

Now knowing that the individual is conducting SQLi queries against

the server, is it manual or is the individual using a tool?

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP
So we begin at the first packet in question, packet 20. By further inspection we see that
the User-Agent is Firefox and the OS is Linux. Now of course we should already know
that this can be spoofed but not always, as we will see shortly.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

We see that the

User-Agent is the
same for packets 31
and 44.

Let’s keep looking to

see if we canfind
anything else of
interest.
Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
Suspicious HTTP

By looking back to the initial packet of interest, packet 20, we can look at the Line-
based text data: text/html portion of the packet details and notice that error messages
are being displayed to the individual conducting the SQLi queries.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

Packet 33 in the screenshot indicates that something went

wrong and the response to the request made in packet 31
was not captured. So we’ll look at the packet containing the
response for the next packet of interest, which will be packet
46.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

Interestingly, this packet shows that it doesn’t

contain any error-based MySQL messages,
even though clearly a SQLi query was executed.

This is common behavior where an attacker

will manually inspect the target before running
automated tools against it.

It seems this individual has enough information

that he/she needs and an automated tool will follow against the target server.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP
Strangely the next packet, packet 56, and the packet after that, packet 73, don’t seem
to contain any SQLi queries. Maybe the individual decided not to continue the attack?

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

Let’s take a closer look at packet 56. Indeed no SQLi is visible within this packet but
something else should have already jumped out at us, the User-Agent. The User-Agent
for this HTTP Get Request is Sqlmap. So the attacker didn’t quit, he/she escalated.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

A few of the subsequent HTTP Get Requests that follows will

also look like legit HTTP traffic but these will also contain the
same User-Agent within the packet details, Sqlmap, until we
reach packet 105.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Suspicious HTTP

So clearly we see the packets are getting more interesting due to Sqlmap and it’s
attempts to find and validate SQLi.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

So here we have the last HTTP Get Request showing a very long query to test for SQLi
on the internal web server and again Sqlmap seems to be the tool that is being used by
the culprit and from here we can inspect the web server logs to investigate further.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTP

Before inspecting the logs pertaining to the web server of interest we already
have a good idea of the source host from which these queries originated from,
10.124.211.200, which is on the same subnet as the web server.

We also know that the individual manually tested for SQLi before running
Sqlmap against the web server.

Now the hunt goes to find out if this is an malicious employee or someone has
infiltrated the network. That quest is for another time ...

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

HTTPS

Now we’ll look at HTTPS traffic within the upcoming slides.

We’ll look into some pointers to remember about HTTPS

traffic and some tips about normal and suspicious HTTPS
traffic.

Finally we’ll look at PCAPs to demonstrate each scenario.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
HTTPS

A few things to remember about HTTPS:

• HTTPS is the secure version of HTTP.
– The “S” refers to Secure Socket Layer/Transport Layer Security (SSL/TLS).

• HTTPS also establishes a handshake similar to TCP but more complicated.

Below is a brief summary:
– Both the client and the server need to agree on the protocol version.
– Both the client and the server need to select cryptographic algorithms.
– Optionally authenticate to each other.
– Use public key encryption techniques to establish secure communications.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 HTTPS
Some facts to help distinguish normal and suspicious HTTPS traffic.
Normal HTTPS Traffic Suspicious HTTPS Traffic
Port 443, TCP Malicious binaries (backdoors), scripts, web
Port 8443, TCP (used as alternate) shells, etc. will use this port because
typically in all corporate environments the
port is open.
Encrypted traffic If the traffic is not encrypted and Secure
Sockets Layer packet details are empty
within packet details then that will fall
under suspicious.
Web server typically in FQDN format. Server will point to an IP address instead of
FQDN format.
Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
HTTPS

We will not dive too deep into the handshake used by HTTPS traffic
but there are certain details within the packets that we should be
familiar with. Those details will be pointed out in the upcoming
slides. If you want to dive deeper into how HTTPS establishes
secure communications please refer to RFC 6101 for SSL 3.0 & RFC
5246 for TLS 1.2.

Note: There is a draft for TLS 1.3, here.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

By looking at the previous screenshot we can’t simply glance

at the packets to get an idea as to what is going on.

Why? Because the packets are encrypted. Which is what we

should be expecting when looking at traffic on port 443.

Let’s take a glance at packets for HTTPS traffic.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal HTTPS

As you may remember, the Secure Sockets

Layer portion of the packet details
should not be empty. Here we see
pertinent info as to what the client has
available in order to attempt to establish
secure communications with the server,
Client Hello packet. We see the following:
• Content Type = Handshake
• Handshake Protocol: Client Hello
• Version: TLS 1.2
• Cipher Suites (11 suites)
• Compression Method (1 method)

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

Here is the server’s response,

Server Hello packet. These
Hello messages again will
contain the availability and
agreement of encryption
algorithms to work with and
exchange of random values
that will be used for
generation of key.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

Here we see the Server Key

Exchange which will be
followed by the Client Key
Exchange packet.

This will be considered step

#3 in the establishment of an
SSL/TLS session between a
server and a client.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

This is the last packet

and the handshake
between the server and
client is now complete.

The rest of the packets

between these 2
devices will now be
encrypted.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal HTTPS

The traffic is unreadable but if this is internal traffic within our corporate environment
then it is feasible to decrypt this traffic using the private key from the internal server.

Most enterprise appliances has this feature built-in but you will need to perform
this task manually if you wish to read the decrypted traffic.
Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
Normal HTTPS

We’ll look at a packet capture file from the Wireshark website

and look at the process to decrypt SSL traffic using the private
key.

You can find the packet capture called snakeoil2_070531.tgz,

and private key, here.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal HTTPS

Note: This packet capture using SSLv3 and the handshake is different from what we seen
in the previous packet capture which used TLSv1.2.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal HTTPS

As expected, the Secure Sockets

Layer field of the packet indeed
has information and we see the
Encrypted Application Data,
that indeed is encrypted.

Now we’ll look at the process to

manually decrypt this traffic using
the server’s private key and
importing it into Wireshark.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

Before doing so, let’s take a look at the Export HTTP object list
to see if anything is shown that we can export from the
packet capture.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal HTTPS

We see from the screenshot below that there is nothing shown that we can export.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

Let’s decrypt this traffic.

In order to import the private key into Wireshark we’ll need

to go to Edit > Preferences > Protocols > SSL.

Now select Edit next to RSA keys list.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal HTTPS
You should see the following
window. Use the + symbol to
import the private key.

You will need to enter the IP

address of the server with the
private key, Port, Protocol, and
the location of the Key File.

Refer to this page for more

guidance on how to import the
key for this specific packet capture.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

Here is the information which was entered. Your configuration should look similar
except for the location of the key file of course.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

We see from the previous screenshot that the traffic was

decrypted. The decrypted traffic is highlighted in the
screenshot in green.

If after you enter the information for the key file and the
packet capture is not showing decrypted traffic, try closing
Wireshark and re-opening it. That might resolve your issue if
everything was configured correctly.
Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
Normal HTTPS

Here is a closer look at a decrypted

packet. Under Secure Sockets Layer
we now see Hypertext Transfer
Protocol information. We also see
a new tab at the bottom titled
Decrypted SSL Data.

As you can see we can still see the

decrypted data without going to the
tab. Next screen shot will show the
details when the tab is selected.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Normal HTTPS

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Normal HTTPS

Now if we check for any

HTTP objects that we can export,
we actually see several images
and HTML pages from the decrypted
traffic.

Again this is possible due to having

access to the private key from the
server, which typically in an internal
corporate environment you should
have access to.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

Now we’ll look at some suspicious HTTPS traffic.

In this example we’ll look at the CrypMIC Ransomware.

Within this malicious traffic we’re only going to focus on how

the malware used port 443 to display the ransomware note
to the victim.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

“CrypMIC and CryptXXX share many similarities; both are spread

by the Neutrino Exploit Kit and use the same format for sub-
versionID/botID (U[6digits] / UXXXXXX]) and export function name
(MS1, MS2).

Both threats also employed a custom protocol via TCP Port 443 to
communicate with their command-and-control (C&C) servers.” –
Trend Labs

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

Let’s start by taking a look at the different protocols within this packet capture,
Statistics > Protocol Hierarchy

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 Suspicious HTTPS

Next we can look at Statistics > Endpoints. We see there is a lot of traffic to several
countries of concern, meaning that malware is known to originate from these destinations.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

Now we’ll look at Statistics > Conversations. We are noticing a lot of traffic on port 443 to
85.14.243.9. This matches to what we seen within the Endpoints window.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS
Here we add a filter to focus on the specific IP address and port 443. Now before
attempting to view the traffic, which should be encrypted, Wireshark is directing
our attention to packets 560 & 561 within this screenshot.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

TCP Spurious Retransmission is when the sending host

‘thinks’ that the receiving host didn’t receive the packet and
sends it again.

That is what we’re seeing in packet 560.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

In packet 561, we see TCP Zero Window.

According to the Wireshark Wiki, this is something to

investigate.

You can read more about this here.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

If we right-click that packet, packet 561, and follow the TCP

Stream, we immediately see something of interest.

We see cleartext traffic on port 443.

More specifically what we see is what appears to be a ransom

note that was displayed to the victim.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

Here is a screenshot of the ransom

note which was displayed to the
victim.

Again this was sent via port 443 but

it’s cleartext traffic, not encrypted.

There is also another thing to point

out about this traffic that should
have been noticeable ..

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

We don’t see any packets showing the SSL/TLS Handshake that is required for encrypted
communication between both nodes.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS
This is from a previously shown PCAP and here we’re being reminded of how to visually
see the SSL/TLS Handshake. Arrow shown below indicates the 1st packet in the process.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

One last thing to point out is that the Secure Sockets Layer field of the
packet shouldn’t be empty like how we see it in the packet details below.

This should also raise a flag.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Suspicious HTTPS

When it comes to HTTP & HTTPS traffic there are a plethora

of attack vectors that we need to look out for because, again,
these ports are not monitored but as time goes on Blue
Teamers are beginning to understand the importance of not
leaving ports 80, 443, etc. unmonitored.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Wireshark Tip

For more information on techniques to filter:

• HTTP traffic: refer to the Wireshark Display Filter
Reference for HTTP here and here

• HTTPS traffic: refer to the Wireshark Display Filter

Reference for HTTPS here

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
Unknown

As we perform network hunting we must know that we won’t

always encounter protocols that we are familiar with. At times you
might be faced with a custom or unknown protocol. This is not far
fetched.

Referring back to the Trend Labs article on the CrypMIC

ransomware it was noted that the threat actors used a custom
protocol via port 443 to communicate with the C2 servers.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

To give an example of unknown traffic we’ll use a PCAP from

Forensics Contest called “Anns Bad Aim”, found here, to
explain this concept.

We won’t go through the entire PCAP or challenge but

instead just focus on the proprietary protocol, AOL Instant
Messenger.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

A filter was used to focus simply on the traffic on port 443.

Remember that traffic on this port should be encrypted.

In the following screenshot we’ll see that the traffic is not

encrypted and the Secure Sockets Layer field in the packet is
empty, there are no details to show to us because is not really
SSL traffic based on the protocol.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

Found within this PCAP there is evidence of a file transfer.

At the beginning of the TCP Stream can be seen OFT2.

OFT2 is AOL instant messaging protocol, OSCAR (Open System

for CommunicAtion in Realtime).

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

Within TCP Stream 5, snippet below, we can see OFT2.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

You can read about the details of OSCAR within a Google

Summer of Code project titled On Sending Files via OSCAR.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

Knowing what specific protocol is associated with this traffic,

we can decode the traffic using Wireshark’s Decode As
feature.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

According to the Wireshark documentation, the “Decode As”

functionality lets you temporarily divert specific protocol
dissections.

Each protocol has its own dissector, so dissecting a complete

packet will typically involve several dissectors.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

Within Analyze > Enable Protocols you should see several

listed related to AIM.

You can read more about the AOL Instant Messenger (AIM)
dissector, here.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

This is a screenshot for the

enabled protocols within
our installation of
Wireshark.

Your settings might be

different from ours.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

Before showing an example of using the Decode As feature

within Wireshark.

Let’s take a look at the packets before decoding them with

the AIM dissector.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown
Before

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

On one of the packets we need to right-click and select

Decode As.

A new window will appear titled “Wireshark Decode As…”.

The first line will be prepopulated with information it

acquired from the packet that was right-clicked on.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown
Before

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

To properly use the AIM dissector with this PCAP, we need to set the
fields as such.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown
After

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown
Here we can see
packet 167 after
using the AIM
dissector.

We now can see

specific information
regarding the
protocol that was
used on port 443,
which was OSCAR
(OFT2).

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

This is packet 167 prior to decoding the traffic with the AIM
dissector.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Unknown

Wireshark has many dissectors which we can use.

We can also add dissectors to Wireshark.

You can read more about that here. You can also find
dissectors on the web.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
We’ll look at a two more tools that will assist us in our packet
hunting engagements.

The first tool will be NetworkMiner.

The following description is from the Netresec website.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

NetworkMiner

“NetworkMiner is a Network Forensic Analysis Tool for

Windows (but also works in Linux / Mac OS X /
FreeBSD). NetworkMiner can be used as a passive
network sniffer/packet capturing tool in order to detect
operating systems, sessions, hostnames, open ports etc.
without putting any traffic on the network.
NetworkMiner can also parse PCAP files for off-line
analysis and to regenerate/reassemble transmitted files
and certificates from PCAP files.”

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

NetworkMiner

This is ascreenshot
of the
NetworkMiner
interface.

We will look at
NetworkMiner
closer within the
Videos section and
you’ll be using it
within the Labs
section.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Network Miner

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

RSA NetWitness Investigator

The last tool we’ll look at is RSA NetWitness Investigator.

The freeware version of the tool can be downloaded here.

The following is an official description of the tool.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

RSA NetWitness Investigator

“Investigator is the award-winning interactive threat

analysis application of the RSA NetWitness product
suite. Investigator provides security operations staff,
auditors, and fraud and forensics investigators the power
to perform free-form contextual analysis of raw network
data. Investigator collects network traffic live or accepts
imported .pcap files providing unprecedented detail,
interactive navigation, and dynamic analysis across all
network layers.”

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

RSA NetWitness Investigator

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

RSA NetWitness
Investigator

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

RSA NetWitness Investigator

We will look at RSA NetWitness Investigator closer within the

Videos section.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Packet Hunting

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

Hunting Insider Threats Hunting Insider Threats
Part 1 Part 2

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

This concludes this module on packet hunting.

We have covered:

✓ Some of the core protocols and how to recognize what is

normal and malicious network traffic.
✓ Unknown protocols, such as OSCAR.

✓ Extra tools to help us in our hunts.

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
ARP (RFC 826) Sample PCAPs

ARP Display Filters ICMP (RFC 792)

ICMP Display Filters TCP (RFC 793)

TCP Relative Sequence NMAP Port Scanning

Numbers Techniques
Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
TCP Display Filters DHCP (RFC 2131)

DHCP Display Filters DNS (RFC 1034)

DNS (RFC 1035) DNS Display Filters

HTTP Methods (RFC HTTPS/SSL 3.0 (RFC

2616) 6101)
Threat Hunting - © Caendra Inc 2017 - All Rights Reserved
HTTPS/TLS 1.2 (RFC 5246) HTTPS/TLS 1.3

Trend Labs (CrypMIC

Wireshark Wiki (SSL)
Ransomware)

Wireshark Wiki (TCP

HTTP Display Filters 1
Zero Window)

HTTP Display Filters 2 HTTPS Display Filters

Threat Hunting - © Caendra Inc 2017 - All Rights Reserved

 On Sending Files via
Ann's Bad Aim PCAP
OSCAR (PDF)

Wireshark "Decode As" Wireshark AIM Dissector

Wireshark Dissector
NetworkMiner
(Add)

RSA NetWitness RSA NetWitness

Investigator Investigator (download)
Threat Hunting - © Caendra Inc 2017 - All Rights Reserved