Intrusion Detection By Analyzing

Traffic (Part 1)
S e c t i o n 0 2 | M o d u l e 0 1
© Caendra Inc. 2018
All Rights Reserved
Table of Contents
Module 01 | Intrusion Detection By Analyzing Traffic (Part 1)

1.1 Networking Concepts & Analysis

1.2 Analyzing & Detecting IEEE 802.x Link Layer Attacks

1.3 Analyzing & Detecting IP Layer Attacks

IHRPv1 - Caendra Inc. © 2018 | p.2

Learning Objectives

By the end of this module, you should have a better

understanding of:

✓ Networking and traffic analysis concepts

✓ How the attacks at the IEEE 802.x Link and IP layers work

✓ How to detect attacks in the IEEE 802.x Link and IP layers

IHRPv1 - Caendra Inc. © 2018 | p.3

 1.1

Networking Concepts
& Analysis

IHRPv1 - Caendra Inc. © 2018 | p.4

1.1 Networking Concepts & Analysis

As already mentioned in the previous section, part of your

incident handling activities will be analyzing captured or live
traffic.

Traffic analysis activities can be performed in multiple

phases of the incident handling process.

IHRPv1 - Caendra Inc. © 2018 | p.5

1.1 Networking Concepts & Analysis

For example, there is no doubt you will perform traffic

analysis activities during the Detection & Analysis phase of
the incident handling process.

But, you will also have to perform the same during the
Containment, Eradication & Recovery phase; specifically,
during Long-term Containment and Recovery.

IHRPv1 - Caendra Inc. © 2018 | p.6

1.1 Networking Concepts & Analysis

Let’s first cover some networking concepts before we

proceed to the more practical part of this module, where we
will see how to detect intrusions or spot suspicious
behavior on the wire, by analyzing network traffic.

IHRPv1 - Caendra Inc. © 2018 | p.7

1.1.1 Communication Models

An important IT concept is communication model.

Any network traffic’s format, order and disassembly are

based on communication models. Frames, packets,
headers and data emulate the layers of network
communication models.

IHRPv1 - Caendra Inc. © 2018 | p.8

1.1.1 Communication Models

Back in the day, a communication standard was established

on how hosts would communicate within a network; this
standard is the OSI (Open Systems Interconnection) model.

The OSI model consists of seven (7) layers. Each layer

represents a different function that networked hosts will
perform during communication.

IHRPv1 - Caendra Inc. © 2018 | p.9

1.1.1 Communication Models

Another model, the TCP/IP one, eventually gained more

traction; this model consists of four (4) layers. That being
said, the OSI and the TCP/IP models are quite similar,
despite their representation differences.

The next slide contains a graphic representation of how the

two models resemble each other conceptually.

IHRPv1 - Caendra Inc. © 2018 | p.10

 1.1.1 Communication Models

For the context of

this course, the HTTP,
terms Packet and
Datagram are SMTP,
synonymous. DNS

TCP, UDP

IP

IEEE
802.x

IHRPv1 - Caendra Inc. © 2018 | p.11

1.1.1 Communication Models

Under the hood, during host communication, layers

communicate with upper or lower layers, so that all
communication pieces are gathered.

IHRPv1 - Caendra Inc. © 2018 | p.12

1.1.2 TCP/IP

Let’s focus our attention on how the TCP/IP model works.

As previously mentioned, all communication pieces should

be gathered from all layers before a message is sent.

More specifically, whenever data is being prepared by a

host for transmission, each of the lower layers of the
TCP/IP stack add something; this is known as
encapsulation of layers.

IHRPv1 - Caendra Inc. © 2018 | p.13

 1.1.2 TCP/IP

Encapsulation

Application Payload
At the Application layer, the
respective payload or data is
supplied. The payload or data
will appear after all the
encapsulating headers.

IHRPv1 - Caendra Inc. © 2018 | p.14

 1.1.2 TCP/IP

Encapsulation

TCP Header
The Application layer passes the
payload down to the Transport
layer (in this case TCP). The
Transport layer adds a TCP
header to the application
payload.

This header includes crucial

transmission information such
as source and destination ports
as well as information that
make sure the TCP segment
arrives as expected.

IHRPv1 - Caendra Inc. © 2018 | p.15

 1.1.2 TCP/IP

Encapsulation

IP Packet Header
The TCP header and the application
payload are now being pushed to the
Internet layer. As you can imagine, the
Internet layer adds yet another header
known as the IP header. This header
includes information that makes sure
the packet is delivered to the correct
destination IP.

At this point, the TCP header can be

seen as IP data. This is because, at
this point, the IP or Networking layer is
not interested in knowing information
such as destination ports, etc.

IHRPv1 - Caendra Inc. © 2018 | p.16

 1.1.2 TCP/IP

Encapsulation

Frame header
The IP and TCP headers, as well
as the application payload (aka
the IP packet), are now passed
to the Network Access layer.

At this point, the Network

Access layer adds a header to
the IP packet known as the
Frame header, containing
information such as source and
destination MAC addresses, etc.
The IP packet can be seen as
Frame data.

IHRPv1 - Caendra Inc. © 2018 | p.17

 1.1.2 TCP/IP

Encapsulation

At the destination host, encapsulation will have to be

reversed.

Each received frame will have to be stripped of its headers

so that each resulting message is passed to the
appropriate layer; this process is known as de-
encapsulation.

IHRPv1 - Caendra Inc. © 2018 | p.18

 1.1.2 TCP/IP

De-encapsulation

For example, the Network Access layer will receive the

frame, analyze the data, strip the frame header off and pass
the IP header and accompanying data to the Internet layer.

Each layer deals only with the data that are meant to be
handled by it. Most of the time, a protocol identifier exists
which can be found in the previous layer.
IHRPv1 - Caendra Inc. © 2018 | p.19
 1.1.2 TCP/IP

De-encapsulation

It should be noted, that some layer headers are of fixed

size, while others are of variable length size and are
accompanied by length details (this is useful to
discriminate optional data or know where a layer ends).

Based on this knowledge, each current layer knows where

to start and stop processing data and subsequently what it
should pass to the upper layer.
IHRPv1 - Caendra Inc. © 2018 | p.20
 1.1.2 TCP/IP

De-encapsulation

To conclude the topic of how each layer knows what to

process, option fields also exist, residing in IP and TCP
headers, that are used to identify where current layer
options start and end.

Let’s briefly see a frame de-encapsulation example.

IHRPv1 - Caendra Inc. © 2018 | p.21

 1.1.2 TCP/IP

De-encapsulation

Let’s suppose a network access card supports the Ethernet

(802.3) link layer protocol.

This means that the card understands the format and all
the fields in the frame header.

IHRPv1 - Caendra Inc. © 2018 | p.22

 1.1.2 TCP/IP

De-encapsulation
4. Unfortunately, the Transport layer knows nothing about the protocol that follows
Application or the application’s data/protocol format. It only knows the destination port. We
may be dealing with HTTP, but we are not sure.

3. The IPv4 header, in turn, includes an indicator about the transport protocol that
Transport follows; this is the protocol field. Let’s suppose the protocol is TCP. The data
following the TCP header is passed to the Transport protocol.

Internet 2. The Ethernet layer will pass all data following the Ethernet header to the IPv4-
handling part of the IP layer.

Network 1. For data to be passed properly to the IP layer, an indicator should exist that reveals
what protocol follows the Ethernet header (could be IPv4 or IPv6); this is where the
Access
type field of the Ethernet header jumps in. Let’s suppose the protocol is IPv4.
IHRPv1 - Caendra Inc. © 2018 | p.23
 1.1.2 TCP/IP

De-encapsulation Same example, but a little deeper…

4. The amount of data to be passed to the Application layer can be derived as follows. Total IP
Application datagram length - IP header length - TCP header length = Length of data to be passed

3. The Transport layer header could be of fixed length (UDP or ICMP) or of variable length (TCP).
For example, we can find a header length value about the TCP header, so that the position of the
Transport data that follow the TCP header can be identified and passed to the Application layer.

2. The standard IPv4 header has a length of 20 bytes; however, there are cases when IP option data
Internet exist. Those data can result in the IPv4 header expanding up to 60 bytes (variable length). The IP
header contains a length-related field, so that data following the IP header are passed to the
Transport layer. The IP header also has a field indicating the whole IP datagram length.

Network
Access 1. The Ethernet (802.3) header has a fixed length of 14 bytes; this means that the data that will be
passed to the IP layer begin 14 bytes after the Ethernet header.
IHRPv1 - Caendra Inc. © 2018 | p.24
1.1.2 TCP/IP

Encapsulation

Traffic analysis tools, such as Wireshark, display data

encapsulation. Just be careful in Wireshark’s case, because
the layers are displayed in reverse order (the lower layers
are displayed first).

For example, let’s see how a DNS response looks like in

Wireshark, accompanied by encapsulation details.
https://www.wireshark.org/ IHRPv1 - Caendra Inc. © 2018 | p.25
1.1.2 TCP/IP

Encapsulation
Network Access layer Internet layer Transport layer Application layer

IHRPv1 - Caendra Inc. © 2018 | p.26

1.1.2 TCP/IP

Encapsulation
Network Access layer: In this line, Wireshark displays the source and destination MAC addresses.

IHRPv1 - Caendra Inc. © 2018 | p.27

1.1.2 TCP/IP

Encapsulation
Internet layer: In this line, Wireshark displays the IP layer that comes right after the Frame header.

IHRPv1 - Caendra Inc. © 2018 | p.28

1.1.2 TCP/IP

Encapsulation
Transport layer: In this case, UDP. It follows the IP header (recall the TCP/IP stack). Source
and destination ports are included in this summary line.

IHRPv1 - Caendra Inc. © 2018 | p.29

1.1.2 TCP/IP

Application layer: This summary line, displays a description of the application payload, a DNS response.

IHRPv1 - Caendra Inc. © 2018 | p.30

1.1.2 TCP/IP

Encapsulation
We can have a detailed look at each encapsulated layer
by expanding the respective fields.

IHRPv1 - Caendra Inc. © 2018 | p.31

1.1.2 TCP/IP

Encapsulation

What is important to understand, is that what we see in

Wireshark is Wireshark’s interpretation. As you can imagine,
there is margin for error. Hopefully, Wireshark and other tools
feature packet bytes panes (displaying the whole frame).

By taking the displayed hexadecimal values in those panes and

interpreting them ourselves, we can be 100% certain of the
interpretation result.
IHRPv1 - Caendra Inc. © 2018 | p.32
1.1.2 TCP/IP

As already mentioned, the packet bytes pane displays

Encapsulation the whole frame. We’ll have to click on the layer of
interest to highlight the values associated with it.

In this case, we are analyzing a DNS query

IHRPv1 - Caendra Inc. © 2018 | p.33

1.1.3 Request For Comments (RFC)

Knowing how normal traffic looks like is of great

importance. Then, and only then, you will be able to spot
abnormalities when analyzing traffic.

For this matter, Request For Comments (RFC) is an

invaluable resource. RFC are documents that strictly
describe the expected standards for a particular protocol.

IHRPv1 - Caendra Inc. © 2018 | p.34

1.1.3 Request For Comments (RFC)

For example, RFC 793 – Transmission Control Protocol

describes TCP functionality and implementation details as
well as the interface using which TCP services are
requested.

IHRPv1 - Caendra Inc. © 2018 | p.35

1.1.3 Request For Comments (RFC)

That being said, RFC documents can be ambiguous or even

not extensive at times.

As an analyst, you will have to combine RFC with

environment context in order to conclude if something
poses as a threat or not.

IHRPv1 - Caendra Inc. © 2018 | p.36

1.1.4 Traffic Analysis Tools

Before we continue diving into the Network Access/Link

layer, let’s talk about the traffic analysis tools we will utilize.

Wireshark and the tcpdump are the weapons of choice

when it comes to traffic analysis.

IHRPv1 - Caendra Inc. © 2018 | p.37

 1.1.4 Traffic Analysis Tools

Traffic Analysis Tools

Wireshark is a powerful network protocol analyzer, that can

go to the deepest level of packet inspection. It has excellent
filtering and searching capabilities.

Wireshark’s cons include a sometimes inaccurate

interpretation and a difficulty in effectively handling very
large pcap files.
IHRPv1 - Caendra Inc. © 2018 | p.38
 1.1.4 Traffic Analysis Tools

Traffic Analysis Tools

tcpdump is also a powerful network protocol analyzer that

can go to the deepest level of packet inspection. It can be
found on most package managers and it can easily handle
very large pcap files.

tcpdump’s cons include a minimal protocol decoding list

and a requirement for interpreting things ourselves.
IHRPv1 - Caendra Inc. © 2018 | p.39
 1.2

Analyzing & Detecting IEEE

802.x Link Layer Attacks

IHRPv1 - Caendra Inc. © 2018 | p.40

1.2 Analyzing & Detecting IEEE 802.x Link Layer Attacks

We briefly covered some important networking concepts,

and now, things will get practical. We will start the practical
part of this module by analyzing and detecting IEEE 802.x
Link layer attacks.

But before analyzing and detecting IEEE 802.x Link layer

attacks, let’s first have a look at the IEEE 802.x Link layer
itself.

IHRPv1 - Caendra Inc. © 2018 | p.41

1.2.1 The Network Access/Link Layer

The IEEE 802.x Link layers are a family of standards that

enable intercommunications between equipment from a
variety of manufacturers.

This family of standards actually specifies functions of the

physical layer and the data link layer of major LAN
protocols.

IHRPv1 - Caendra Inc. © 2018 | p.42

 1.2.1 The Network Access/Link Layer

The most known link layers being used nowadays

are:

• 802.3: Ethernet

• 802.11: Wireless

• 802.15.1: Bluetooth

IHRPv1 - Caendra Inc. © 2018 | p.43

1.2.1 The Network Access/Link Layer

Let’s focus on 802.3 and start covering it, by analyzing the

link layer frame.

The link frame actually consists of the Ethernet header plus

all following layers.

IHRPv1 - Caendra Inc. © 2018 | p.44

1.2.1 The Network Access/Link Layer

After the Ethernet header, we find data whose size could

reach up to 1500 bytes. As you already know, that data can
be IP, a transport protocol and data (recall encapsulation),
but it can also be ARP.

The Ethernet header has a length of 14 bytes. The Ethernet

frame, in turn, must have a length of at least 64 bytes,
according to specification.

IHRPv1 - Caendra Inc. © 2018 | p.45

1.2.1 The Network Access/Link Layer

If the frame has a shorter length, a trailer of 0s must be

added to pad the number of bytes to 60. Why 60 and not
64? This is because, the Ethernet frame also features a 4-
byte trailer known as CRC (Cyclic Redundancy Check), used
to identify frame corruption.

If you do the math, the maximum Ethernet frame length is

1518 bytes.

IHRPv1 - Caendra Inc. © 2018 | p.46

1.2.1 The Network Access/Link Layer

Link layer communication is facilitated by Network

Interface Cards (NICs) and the respective device drivers.
Using those, a host can interact with the physical medium
on which it resides.

Any NIC has a unique identification number known as a

MAC address which is issued by the NIC’s manufacturer
during NIC creation. MAC addresses are static 48-bit long
numbers.

IHRPv1 - Caendra Inc. © 2018 | p.47

1.2.1 The Network Access/Link Layer

Here is a MAC address break

down. To decode a MAC
address, we split it in half; this
will give us the OUI and the
network ID.

We can then lookup the OUI on

a website, such as
https://www.macvendorlookup.
com/, to reveal the NICs
manufacturer.

https://www.macvendorlookup.com/ IHRPv1 - Caendra Inc. © 2018 | p.48

1.2.1 The Network Access/Link Layer

According to the TCP/IP stack, the IP layer will have to find

a way to talk to the Link layer; this is done through an IP-to-
MAC address association.

The IP layer communicates using IP addresses, whereas

the Link layer communicates using MAC addresses.

IHRPv1 - Caendra Inc. © 2018 | p.49

1.2.1 The Network Access/Link Layer

What makes this association possible in IPv4 is ARP.

In IPv6, Neighbor Solicitation is used to request for a MAC

address associated with a given IPv6 address, and
Neighbor Advertisement is used for sending the response.

IHRPv1 - Caendra Inc. © 2018 | p.50

1.2.1 The Network Access/Link Layer

In contrast to MAC addresses, IPv4 addresses are software

addresses that can change over time and they have a
length of 32 bits.

The same applies for IPv6 addresses, but they have a

length of 128 bits.

IHRPv1 - Caendra Inc. © 2018 | p.51

1.2.1 The Network Access/Link Layer

At this point, it should be noted that ARP traffic is

generated only when two hosts residing in same local
network want to communicate. If the two hosts reside on
different physical segments, traffic will be routed via the
Internet layer first and then passed to the Network Access
layer.

You can read more about ARP in RFC 826.

https://www.ietf.org/rfc/rfc826.txt IHRPv1 - Caendra Inc. © 2018 | p.52

1.2.2 ARP’s Security Shortcomings

Over the years ARP has been greatly abused by attackers, due to its
inherent security shortcomings.
• There is no way to validate MAC address ownership whenever an
ARP request or response is issued.
• ARP is stateless. Whenever an ARP response is received, hosts will
create or update a cache entry with the observed IP/MAC pair
(regardless of them issuing an ARP request or not).
• An initial ARP request can result in the requester’s IP/MAC pair being
cached by listening (for broadcasts) hosts; this is done to reduce
ARP broadcast requests.

IHRPv1 - Caendra Inc. © 2018 | p.53

1.2.2 ARP’s Security Shortcomings

Those ARP shortcomings can be leveraged by an attacker

to launch man-in-the-middle attacks, where he/she can
pose as just another host on the local network or even as a
router.

IHRPv1 - Caendra Inc. © 2018 | p.54

1.2.2 ARP’s Security Shortcomings

If such attacks are executed successfully, the attacker can

receive traffic destined for another host, inspect it or alter it
and ultimately forward it to the original destination.

Not only that, but the attacker can also receive, inspect or
alter the traffic from the original destination and ultimately
forward it back to the original sender.

IHRPv1 - Caendra Inc. © 2018 | p.55

1.2.2 ARP’s Security Shortcomings

Let’s see how we can detect such attacks on the wire.

First, let’s see some normal ARP traffic…

Note: Refer to the Wireshark Display Filter Reference for

ARP, here, on more techniques to filter ARP traffic.

https://www.wireshark.org/docs/dfref/a/arp.html IHRPv1 - Caendra Inc. © 2018 | p.56

1.2.2.1 ARP Attacks & Detection

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.

IHRPv1 - Caendra Inc. © 2018 | p.57

1.2.2.1 ARP Attacks & Detection

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
establishing 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 or
arp from the command line).

IHRPv1 - Caendra Inc. © 2018 | p.58

1.2.2.1 ARP Attacks & Detection

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.

IHRPv1 - Caendra Inc. © 2018 | p.59

1.2.2.1 ARP Attacks & Detection

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.

IHRPv1 - Caendra Inc. © 2018 | p.60

1.2.2.1 ARP Attacks & Detection

IHRPv1 - Caendra Inc. © 2018 | p.61

1.2.2.1 ARP Attacks & Detection

This is how ARP works if one of the hosts in the network asks for it;
however, this is not the only way though.

The so-called gratuitous ARP requests and responses are also

possible, and they are usually abused by attackers.
• Gratuitous ARP request: Ιt is a request packet where the source
and destination IP are set with the IP of the machine that is
issuing the packet and the destination MAC is the broadcast
address.
• Gratuitous ARP reply: It is an ARP reply that has been sent
without being requested.

IHRPv1 - Caendra Inc. © 2018 | p.62

1.2.2.1 ARP Attacks & Detection

Normal Gratuitous ARP

Make sure the MAC address is legit / belongs to your organization

IHRPv1 - Caendra Inc. © 2018 | p.63

1.2.2.1 ARP Attacks & Detection

Attacker-crafted Gratuitous ARP

Looks like a crafted/illegitimate MAC address

IHRPv1 - Caendra Inc. © 2018 | p.64

1.2.2.1 ARP Attacks & Detection

Gratuitous ARP may be useful to detect IP conflict or simply

inform other hosts/switches of a MAC address in the
network, but attackers can also use these packets to mount
ARP poisoning attacks.

We will see how shortly.

IHRPv1 - Caendra Inc. © 2018 | p.65

1.2.2.1 ARP Attacks & Detection

Now, we’ll look at examples of ARP traffic using Wireshark.

Remember the following 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 within a small time window.

IHRPv1 - Caendra Inc. © 2018 | p.66

1.2.2.1 ARP Attacks & Detection

Here we see a snapshot of a packet capture, which 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.

IHRPv1 - Caendra Inc. © 2018 | p.67

1.2.2.1 ARP Attacks & Detection

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.

IHRPv1 - Caendra Inc. © 2018 | p.68

1.2.2.1 ARP Attacks & Detection

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

IHRPv1 - Caendra Inc. © 2018 | p.69

1.2.2.1 ARP Attacks & Detection

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.

IHRPv1 - Caendra Inc. © 2018 | p.70

1.2.2.1 ARP Attacks & Detection

As already mentioned, there are other techniques in which

ARP can be used for nefarious purposes, such as ARP
Spoofing/Cache Poisoning attacks.

IHRPv1 - Caendra Inc. © 2018 | p.71

1.2.2.1 ARP Attacks & Detection

ARP poisoning can be exploited to add fake information between two

communication peers into a local network. In a scenario in which M
(the attacker) wants to listen to all the traffic between A and B, M
would have to send fake IP/MAC pairs to both A and B, making himself
the Man-in-the-Middle.

Fake IP/MAC Fake IP/MAC

pairs pairs
(M)

IHRPv1 - Caendra Inc. © 2018 | p.72

 1.2.2.1 ARP Attacks & Detection

ARP Poisoning

The following are the steps for a successful attack:

1. M would pretend to be B to A: it will send a gratuitous ARP
reply with the pair: IP_B->MAC_M
2. M would pretend to be A to B: it will send a gratuitous ARP
reply with the pair: IP_A->MAC_M

Because of the TTL in hosts ARP caches, an attacker would need to

send these packets at intervals lower than the timeout (usually every 30
seconds is a good choice).
IHRPv1 - Caendra Inc. © 2018 | p.73
 1.2.2.1 ARP Attacks & Detection

ARP Poisoning
Once the gratuitous ARP packet is sent, B’s ARP cache gets poisoned
with the entry: IP_A->MAC_M. Next time B wants to send a packet to A,
it will be forwarded to M.
ARP Cache Victim (B)
IP_A: MAC_M
IP_G: MAC_G

Gratuitous ARP Packet

MAC: MAC_M
IP: IP_A
(M)

IHRPv1 - Caendra Inc. © 2018 | p.74

 1.2.2.1 ARP Attacks & Detection

ARP Poisoning
The same thing happens against A. The attacker sends the gratuitous
ARP packet, and A’s ARP cache gets poisoned with the entry IP_B-
>MAC_M. Next time A wants to send a packet to B, it will be forwarded to
M.
ARP Cache Victim (B)
IP_B: MAC_M
IP_G: MAC_G

Gratuitous ARP Packet

MAC: MAC_M
IP: IP_B
(M)

IHRPv1 - Caendra Inc. © 2018 | p.75

 1.2.2.1 ARP Attacks & Detection

ARP Poisoning

This attack leaves the MAC address of the attacker in the

ARP cache of the victims.

Another gratuitous ARP with correct values would restore

the correct values after the sniffing is completed.

IHRPv1 - Caendra Inc. © 2018 | p.76

 1.2.2.1 ARP Attacks & Detection

ARP Poisoning
When a host in a LAN wants to send packets to hosts outside the
LAN, it uses the default gateway.

The default gateway MAC address must be used to forward the

packet along with the correct IP address configured by the
administrator or given by DHCP.

The use of ARP poisoning in this scenario leads to a MITM attack

from local to remote.
IHRPv1 - Caendra Inc. © 2018 | p.77
 1.2.2.1 ARP Attacks & Detection

ARP Poisoning
This diagram explains the MitM scenario. Host A sends all the traffic aimed for the internet through the
Attacker.
LAN
IP_G MAC_M
IP_M MAC_M

IP_G MAC_M

IHRPv1 - Caendra Inc. © 2018 | p.78

 1.2.2.1 ARP Attacks & Detection

ARP Poisoning

The following describes the steps that take place in the previous
scenario:
1. Host A wants to send packets to the Internet. It already has the
IP of the gateway (IP_G), and it needs the associated MAC
address.
2. M can use a gratuitous ARP reply to advertise itself as the
default gateway: binds IP_G with his own (MAC_M).
3. All the traffic meant to leave the LAN will pass through M, which
will then redirect it to the real gateway.
IHRPv1 - Caendra Inc. © 2018 | p.79
1.2.2.1 ARP Attacks & Detection

Consider the arp_poisoning.pcapng file found in this module's resources.

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

IHRPv1 - Caendra Inc. © 2018 | p.80

 1.2.2.1 ARP Attacks & Detection

Consider the arp_poisoning.pcapng file found in this module's resources.

How about this traffic? Would it be considered suspicious or normal?
The router’s MAC
address is
ARP Request
00:50:56:eb:f7:91

ARP Reply

A malicious device on
the network is telling
that the router’s MAC
address is Gratuitous
00:0c:29:20:bc:14, by ARP Replies
issuing gratuitous
ARP replies at
frequent intervals .

IHRPv1 - Caendra Inc. © 2018 | p.81

1.2.2.1 ARP Attacks & Detection

We can actually identify the malicious device on the network since we

know the MAC address of the attacker, by doing the following:
Let's filter the traffic looking for frames that hold the attacker’s MAC address. We can see the ARP replies we saw earlier in
addition to an ACK segment coming from 192.168.153.154 which contains the attacker’s MAC address we got earlier.

IHRPv1 - Caendra Inc. © 2018 | p.82

1.2.2.2 ARP Spoofing Prevention

How you can prepare against ARP spoofing attacks, you

may ask.

• Using Static ARP could help, but it is not a feasible

approach into large and always-changing networks.
• Tools like arpwatch can detect but not stop such attacks
• Switches usually feature protections against ARP
spoofing
IHRPv1 - Caendra Inc. © 2018 | p.83
1.2.3 Other Sniffing Attacks & Detection

With hardware switches, traffic sniffing, in general, is more

difficult.

In a normal and not stressed switched network, sniffing for

data is impossible, due to the fact that switches store the
MAC address to physical switch port pairing in their
Content Addressable Memory (CAM) table.

IHRPv1 - Caendra Inc. © 2018 | p.84

1.2.3 Other Sniffing Attacks & Detection

Efficient attack techniques have been introduced though, to

force switches to behave like a hub and then forward
frames on all the ports.

IHRPv1 - Caendra Inc. © 2018 | p.85

1.2.3 Other Sniffing Attacks & Detection

Such a technique is called MAC Flooding. MAC flooding is

meant to stress the switch and fill its CAM table.

A CAM table keeps all the info required to forward frames

to the correct port: <MAC address - port number - TTL>.

IHRPv1 - Caendra Inc. © 2018 | p.86

1.2.3 Other Sniffing Attacks & Detection

When the space in the CAM is filled with fake MAC

addresses, the switch cannot learn new MAC addresses.

The only way to keep the network alive is to forward the

frames meant to be delivered to the unknown MAC address
on all the ports of the switch, thus making it fail open, or act
like a Hub.

IHRPv1 - Caendra Inc. © 2018 | p.87

1.2.3 Other Sniffing Attacks & Detection

That being said, port security measures exist that can

restrict the association of a port with a single source MAC
address.

Additionally, there are switches that can be configured in

such a way so that acting like a hub is prohibited.

IHRPv1 - Caendra Inc. © 2018 | p.88

1.2.3 Other Sniffing Attacks & Detection

Consider the mac_flood.pcapng file found in this module's resources

and assume we are dealing with a switched environment.

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

IHRPv1 - Caendra Inc. © 2018 | p.89

1.2.3 Other Sniffing Attacks & Detection

Consider the mac_flood.pcapng file found in this module's resources

and assume we are dealing with a switched environment.

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

What we can easily
identify, is that:
1. The traffic capture
file is full of
malformed
packets.
2. Packets don’t
belong to the
segment where we
sniffed traffic
(their origin is
quite sparse
actually).

There must be
something going on.

IHRPv1 - Caendra Inc. © 2018 | p.90

1.2.3 Other Sniffing Attacks & Detection

Let’s make sure by utilizing statistical analysis. First, download and

install a trial of Colasoft’s Capsa. Now open Capsa and navigate to the
Replay tab. From there, add mac_flood.pcapng, choose Full Analysis
and press Start. Once analysis is done, navigate to the Summary tab,
where you will find the below information.

https://www.colasoft.com/download/products/download_capsa.php IHRPv1 - Caendra Inc. © 2018 | p.91

1.2.3 Other Sniffing Attacks & Detection

Let’s make sure by utilizing statistical analysis. First, download and

install a trial of Colasoft’s Capsa. Now open Capsa and navigate to the
Replay tab. From there, add mac_flood.pcapng, choose Full Analysis
and press Start. Once analysis is done, navigate to the Summary tab,
where you will find the below information.

The amount of unique MAC addresses is unusually high !

https://www.colasoft.com/download/products/download_capsa.php IHRPv1 - Caendra Inc. © 2018 | p.92

1.2.3 Other Sniffing Attacks & Detection

Let’s visualize things to have a better understand of what is

going on.

To do so, expand MAC Explorer and in turn expand Local

Segment.

Now, navigate to the Matrix tab.

IHRPv1 - Caendra Inc. © 2018 | p.93

 1.2.3 Other Sniffing Attacks & Detection

You will be presented with the following:

Red lines indicate one-way transmitting.

It looks like someone is crafting
(malformed) packets, in order to
perform a MAC flooding attack.

IHRPv1 - Caendra Inc. © 2018 | p.94

1.2.3 Other Sniffing Attacks & Detection

For the complete picture, also browse the MAC Conversation tab. You
will be presented with the following:

Almost all nodes only send one packet out.

Most packets are 60 bytes.

IHRPv1 - Caendra Inc. © 2018 | p.95

1.2.3 Other Sniffing Attacks & Detection

Finally, to be 100% sure of the assumption, browse the Packet tab. You
will be presented with the following:

The time difference between each packet transmission is extremely low,

causing pressure to the switch. We can safely conclude we are dealing
with a MAC flooding attack.

IHRPv1 - Caendra Inc. © 2018 | p.96

1.2.4 802.11 Wireless

To conclude covering the Network Access/Link Layer, let’s

also take a look at 802.11 wireless.

We will focus on a clear-text frame that can be provide us

with some context.

IHRPv1 - Caendra Inc. © 2018 | p.97

1.2.4 802.11 Wireless

Compared to wired packets, wireless ones feature a 802.11 (layer 2) header. This
header contains additional information regarding the packet and medium upon
which it travels. The types of 802.11 packets are:

• Management: Connectivity between hosts at layer 2 is based upon those

packets.
o Authentication packets
o Association packets subtypes
o Beacon packets
• Control: Delivery of packets is enabled by those packets. Congestion is also
“regulated” by them.
o Request-to-send packets
o Clear-to-send packets subtypes
• Data: Those packets are the actual data containers. They are the only packet
kind that can be passed from the wireless to the wired network.

IHRPv1 - Caendra Inc. © 2018 | p.98

1.2.4 802.11 Wireless

The structure of a wireless packet depends on its type and

subtype. As you can imagine, a lot of different structures
exist. Let’s focus on one of the most informative ones, the
beacon packet.

Beacon packets are broadcasted from a wireless access

point to inform other listening wireless clients of its
existence and its connection requirements.

IHRPv1 - Caendra Inc. © 2018 | p.99

1.2.4 802.11 Wireless

Beacon frame capture

The 802.11 management
frame header contains
information such as:
• Timestamp: Packet
transmission time
• Beacon Interval:
Beacon packet
retransmission time
• Capabilities
Information: Hardware
capabilities of the AP
• SSID parameter set:
Network name
broadcasted by the AP
• Supported Rates: Data
transfer rates
supported by the AP
• DS Parameter set:
Channel on which the
AP operates

IHRPv1 - Caendra Inc. © 2018 | p.100

 1.3

Analyzing & Detecting

IP Layer Attacks

IHRPv1 - Caendra Inc. © 2018 | p.101

1.3 Analyzing & Detecting IP Layer Attacks

Now that we have covered analyzing and detecting IEEE

802.x Link layer attacks, it is time to focus our attention on
the IP layer.

But before analyzing and detecting IP layer attacks, let’s

first have a look at the IP layer itself.

IHRPv1 - Caendra Inc. © 2018 | p.102

1.3.1 The IP Layer

The IP layer’s functions are related with how packets are

transferred from one hop to another.

Source and destination IP addresses are used by the IP

layer for inter-host communication. IP addresses reside in
the IP header of the IP packet.

IHRPv1 - Caendra Inc. © 2018 | p.103

1.3.1 The IP Layer

It should be noted that IP packets travel individually as they

are directed to their destination.

For example, IP packets from the same source that are

travelling to the same destination could get there through
different routes.

IHRPv1 - Caendra Inc. © 2018 | p.104

1.3.1 The IP Layer

During packet delivery, a lot of things can go wrong. The IP layer

has no built-in mechanism to identify when a packet gets lost,
expired or dropped.

The Transport protocol or the application itself is responsible for

identifying and resolving any packet loss.

You can read more about IP in RFC 791.

We will cover both IPv4 and IPv6.

https://www.ietf.org/rfc/rfc791.txt IHRPv1 - Caendra Inc. © 2018 | p.105
1.3.1 The IP Layer

Below you can see a representation of the IP header. Note that in order
to facilitate de-encapsulation, the IP header features three distinct
length values.
Length (IP header length): A field
containing the length of the IP
header.

Total Length (IP datagram/packet

length): Specifies the length of the
IP packet that includes the IP
header and the user data.

Fragment(ed) Offset: In case of a

packet being divided, the
fragmentation offset value will be
used to reassemble the packet.

IHRPv1 - Caendra Inc. © 2018 | p.106

1.3.2 Important IPv4 Fields

Let’s elaborate more on some important and, oftentimes,

abused IPv4 fields.

First, an IP Version field exists indicating whether we are

dealing with IPv4 or IPv6 (valid version numbers are 4 and 6
only). If an invalid IP Version value is identified at the host
or router level, the datagram/packet must be silently
discarded according to the respective RFC.

IHRPv1 - Caendra Inc. © 2018 | p.107

1.3.2 Important IPv4 Fields

Oftentimes, attackers check the reactions of firewalls and IDS by crafting

and sending datagrams with an invalid IP version.

Consider the bad_ip_version.pcap file found in this module's resources.

How about this traffic? Would it be considered suspicious or normal?
>> tcpdump -r bad_ip_version.pcap -ntx

IHRPv1 - Caendra Inc. © 2018 | p.108

1.3.2 Important IPv4 Fields

Oftentimes, attackers check the reactions of firewalls and IDS by crafting and
sending datagrams with an invalid IP version.

Consider the bad_ip_version.pcap file found in this module's resources. How

about this traffic? Would it be considered suspicious or normal?
>> tcpdump -r bad_ip_version.pcap -ntx

In yellow, we can
see that the IP
version field has
a value of 0x7.

We can safely
conclude we are
dealing with
malicious traffic.

IHRPv1 - Caendra Inc. © 2018 | p.109

1.3.2 Important IPv4 Fields

Let’s continue analyzing important IPv4 header fields.

This time, let’s look at the IPv4 Protocol Number. Depending on

this field’s value the protocol/transport layer that follows the IP
header is identified.

The venerable Nmap network scanner leverages this to perform

IP protocol scanning against a given target. This type of
scanning is also a stealthier way to identify a live host.

IHRPv1 - Caendra Inc. © 2018 | p.110

1.3.2 Important IPv4 Fields

Consider the proto_scan.pcap file found in this module's resources.

How about this traffic? Would it be considered suspicious or normal?
>> tcpdump -r proto_scan.pcap -ntx -tttt

IHRPv1 - Caendra Inc. © 2018 | p.111

1.3.2 Important IPv4 Fields

Consider the proto_scan.pcap file found in this module's resources.

How about this traffic? Would it be considered suspicious or normal?
>> tcpdump -r proto_scan.pcap -ntx -tttt
1. It is obvious that the 192.168.1.6
host sends a great number of packets
to the 192.168.1.4 one at very at short
intervals.

2. The first IPv4 packet contains the 64

value hexadecimal (GMTP protocol) in
its IP Protocol field. The third IPv4
packet contains the 0b hexadecimal
value (Network Voice protocol) in its IP
Protocol field. The same pattern
continues with all upcoming IPv4
packets containing all kinds of
protocols in their IP Protocol fields and
being sent at short intervals.

3. The multiple ICMP protocol [id]

unreachable messages are a known
indicator, based on which Nmap
concludes if a protocol is supported on
a host or not.

We are most probably dealing with a

malicious IP Protocol Nmap scan

IHRPv1 - Caendra Inc. © 2018 | p.112

1.3.2 Important IPv4 Fields

Another important set of IPv4 header fields are the Source IP Address
and the Destination IP Address fields. There are three golden detection
rules that are related to this set of IPv4 header fields.
• Incoming traffic to your network should obviously have a Source IP
Address that doesn’t belong to your network address space. If it
does, it is most probably crafted.
• Outgoing traffic from your network should obviously have a Source
IP Address that belongs to your network address space. If it doesn’t,
there is most probably a misconfiguration or the address is spoofed.
• Private network addresses or the loopback mode address also
require your attention

https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml IHRPv1 - Caendra Inc. © 2018 | p.113

1.3.2.1 Abusing Fragmentation & Detection

Let’s talk briefly about fragmentation. Fragmentation is the

action of dividing a packet whose size is greater than the
Maximum Transmission Unit (MTU) into equal-sized (except for
the last) packets, whose size is less or equal to the MTU.
Fragmentation can be performed by a router or the sending host
itself.

Each fragment’s IP header contains fields and values that

facilitate reassembling the original packet at the destination.

IHRPv1 - Caendra Inc. © 2018 | p.114

1.3.2.1 Abusing Fragmentation & Detection

What is of interested to us, is that fragmentation is

oftentimes abused for IDS/IPS evasion purposes.

When it comes to fragmented packets, IDS/IPS must act

just if they were the destination host, in terms of packet
reassembling. This is for obvious reasons, IDS/IPS need the
whole packet in order to inspect it.

IHRPv1 - Caendra Inc. © 2018 | p.115

1.3.2.1 Abusing Fragmentation & Detection

That being said, attackers can introduce difficulties in the

reassembling procedure by the IDS/IPS, such as:
• Crafted fragmented packets with identical offsets but
different payloads
• Crafted packets arriving with a great time difference

IHRPv1 - Caendra Inc. © 2018 | p.116

1.3.2.1 Abusing Fragmentation & Detection

For the IDS/IPS to safely perform such packet

reassembling and inspection, it should act just like the
destination host does.

Let’s consider the delayed fragments case. If the IDS/IPS,

due to performance limitations, doesn’t wait as long as the
destination does for a fragment to arrive, a delayed
fragment containing a malicious payload could evade it and
exploit the destination.

IHRPv1 - Caendra Inc. © 2018 | p.117

1.3.2.1 Abusing Fragmentation & Detection

Consider the frag-based_scan.pcap file found in this

module's resources. Do you think this traffic is malicious?
>> tcpdump -r frag-based_scan.pcap -ntx -tttt -v

IHRPv1 - Caendra Inc. © 2018 | p.118

1.3.2.1 Abusing Fragmentation & Detection

Consider the frag-based_scan.pcap file found in this

module's resources. Do you think this traffic is malicious?
>> tcpdump -r frag-based_scan.pcap -ntx -tttt -v

Fragment ID

Fragment
offset

Fragments
follow

IHRPv1 - Caendra Inc. © 2018 | p.119

1.3.2.1 Abusing Fragmentation & Detection

Consider the frag-based_scan.pcap file found in this

module's resources. Do you think this traffic is malicious?
>> tcpdump -r frag-based_scan.pcap -ntx -tttt -v

Fragment ID

Fragment
offset

Fragments
follow

HINT: A stealthy mapping technique exists that leverages fragmentation. Specifically, the attacker sends an incomplete set of fragments (the zero offset fragment must be
included) to the scanned hosts. Of course, the scanned hosts should be listening on the specified port or protocol.

If this is the case, once the first fragment is received, a timer is set. Once this timer expires, the receiving host transmits an ICMP “Fragment reassembly time exceeded” error
back to the attacker.

IHRPv1 - Caendra Inc. © 2018 | p.120

1.3.2.1 Abusing Fragmentation & Detection

Consider the frag-based_scan.pcap file found in this

module's resources. Do you think this traffic is malicious?
>> tcpdump -r frag-based_scan.pcap -ntx -tttt -v
1. Although there is a flag
designating that
fragments will follow, we
see no fragments arriving
for the next 30 seconds

2. Ultimately, we notice an
ICMP “reassembly time
exceeded” error being sent
back to the source that
transmitted the
incomplete fragment.

We are either dealing with

a host misconfiguration or
a stealthy scanning
attempt.

IHRPv1 - Caendra Inc. © 2018 | p.121

1.3.2.1 Abusing Fragmentation & Detection

Let’s see more malicious fragmentation examples.

An old DoS technique was sending an IP packet exceeding

the 65535 bytes limit of data via a ping command. As you
can imagine, this overly big packet would be fragmented
and reassembled at the destination host. When older
Operating Systems tried to reassemble such a packet they
experienced system crashes, reboots or major
degradations in performance.

IHRPv1 - Caendra Inc. © 2018 | p.122

1.3.2.1 Abusing Fragmentation & Detection

In a traffic capture of such an attack, you should see the

following moments before the vulnerable system crashed.

This attack is known as ping-of-death.

Right after that, the value of the reassembled packet will exceed the 65535 bytes limit.

IHRPv1 - Caendra Inc. © 2018 | p.123

1.3.2.1 Abusing Fragmentation & Detection

Another malicious fragmentation example is the old and

UDP-based Teardrop attack.

In this case, crafted overlapping fragments were utilized in

order to introduce ambiguities in the reassembling
procedure and cause vulnerable systems to crash.

IHRPv1 - Caendra Inc. © 2018 | p.124

1.3.2.1 Abusing Fragmentation & Detection

Teardrop attack on the wire

Frame 8 contains an IP fragment with a 36-

byte long payload. If you look at frame 9, it
states that this IP fragment starts at offset
24. Logically, it should be starting at offset
36. This overlap is the essence of the
teardrop attack.

IHRPv1 - Caendra Inc. © 2018 | p.125

1.3.2.1 Abusing Fragmentation & Detection

You may think that there is no real value in studying

older/patched attacks, but older attack mechanics are
constantly being updated and reused to discover new
vulnerabilities.

This was the case with CVE-2018-5391 (aka

FragmentSmack). This attack resembled the way the
original Teardrop attack was executed and affected a
plethora of modern Windows (and Linux) targets.

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180022 IHRPv1 - Caendra Inc. © 2018 | p.126

1.3.3 IPv6

Truth be told, when the IPv4 specification was written, no

one could have predicted the amount of Internet-connected
devices we have today.

We are currently experiencing the exhaustion of the IPv4

address space. For this reason, a new version of the IP
specification was created back in 1998. This new version of
the IP specification was IPv6.

IHRPv1 - Caendra Inc. © 2018 | p.127

1.3.3 IPv6

This is only part of the story.

IPv6 also features security enhancements and higher

packet size limits.

IHRPv1 - Caendra Inc. © 2018 | p.128

1.3.3 IPv6

IPv4 addresses are 32-bits long, whereas IPv6 addresses

are 128-bits long. This fact makes IPv6 addresses a bit
difficult to manage. We usually come across IPv6
addresses being written in eight groups of 2 bytes in
hexadecimal (e.g.1111:aaaa:2222:bbbb:3333:cccc:4444:dddd)

More on IPv6 addresses can be found at the following

resource:
http://www.gestioip.net/docu/ipv6_address_examples.html

IHRPv1 - Caendra Inc. © 2018 | p.129

1.3.3 IPv6

Let’s also see a brief comparison between the IPv4 and IPv6 headers.
IPv4 Header IPv6 Header

IHRPv1 - Caendra Inc. © 2018 | p.130

1.3.3 IPv6

Let’s also see a brief comparison between the IPv4 and IPv6 headers.
IPv6 Header
The version field is 4 bits long and contains the IP version to be expected in
Version the following contents; since we are talking about IPv6, this value is always
going to be 6 (0110).
The traffic class field is 8 bits long and operates the same as the IPv4 Type
Traffic Class of Service field; this includes support for the marking of traffic based on a
differentiated services code point (DSCP).
The flow label field is 20 bits long and is new to IPv6. It enables the ability to
Flow Label
track specific traffic flows at the network layer.
The payload length field is 16 bits long and operates the same as the IPv4
Payload Length length field; this field includes the length of the data portion of the IPv6
packet.
The next header field is 8 bits long and operates similarly to the IPv4
Next Header protocol field. The next header field indicates what to expect after the basic
IPv6 header; this includes options like a TCP or UDP header and packet.
The hop limit field is 8 bits long and operates similarly to the IPv4 Time to
Hop Limit Live field. This field is used to specify the maximum number of routers that
the packet is allowed to travel through before being discarded.
The source address field is 128 bits long and operates the same as the IPv4
Source Address
source address field, with the exception of the length differences.
The destination address field is 128 bits long and operates the same as the
Destination Address
IPv4 destination address field, with the exception of the length differences.

IHRPv1 - Caendra Inc. © 2018 | p.131

1.3.3 IPv6

Let’s also see a brief comparison between the IPv4 and IPv6 headers.
• Any IP options can now be specified in extension headers between the IPV6 header and the transport-related portion of the packet.
• Fragmentation, Flags, Checksum, etc. can be specified in another extension header.
• Validation now lies in the shoulders of the protocol checksums and their pseudo-headers. This means no re-computing of the IPv6
header is required by the routers.
IPv6 Header
The version field is 4 bits long and contains the IP version to be expected in
Version the following contents; since we are talking about IPv6, this value is always
going to be 6 (0110).
The traffic class field is 8 bits long and operates the same as the IPv4 Type
Traffic Class of Service field; this includes support for the marking of traffic based on a
differentiated services code point (DSCP).
The flow label field is 20 bits long and is new to IPv6. It enables the ability to
Flow Label
track specific traffic flows at the network layer.
The payload length field is 16 bits long and operates the same as the IPv4
Payload Length length field; this field includes the length of the data portion of the IPv6
packet.
The next header field is 8 bits long and operates similarly to the IPv4
Next Header protocol field. The next header field indicates what to expect after the basic
IPv6 header; this includes options like a TCP or UDP header and packet.
The hop limit field is 8 bits long and operates similarly to the IPv4 Time to
Hop Limit Live field. This field is used to specify the maximum number of routers that
the packet is allowed to travel through before being discarded.
The source address field is 128 bits long and operates the same as the IPv4
Source Address
source address field, with the exception of the length differences.
The destination address field is 128 bits long and operates the same as the
Destination Address
IPv4 destination address field, with the exception of the length differences.

IHRPv1 - Caendra Inc. © 2018 | p.132

1.3.3.1 Important IPv6 Fields

Let’s now cover some important, and oftentimes, abused

fields of the IPv6 header.

For more details on the IPv6 header, please refer to RFC

2460.

https://tools.ietf.org/html/rfc2460#page-4 IHRPv1 - Caendra Inc. © 2018 | p.133

1.3.3.1 Important IPv6 Fields

An important set of IPv6 header fields are the Source Address and the Destination
Address fields. There are three golden detection rules that are related with this set
of IPv6 header fields.

• Incoming traffic to your network should obviously have a Source Address that
doesn’t belong to your network address space. If it does, it is most probably
crafted. Incoming traffic with Destination Address being a multicast/anycast
address needs investigation.
• Outgoing traffic from your network should obviously have a Source IP Address
that belongs to your network address space. If it doesn’t, there is most probably
a misconfiguration or the address is spoofed. Outgoing traffic with Destination
Address being a multicast/anycast address needs investigation.
• Private network addresses also require your attention.

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml IHRPv1 - Caendra Inc. © 2018 | p.134

1.3.3.1 Important IPv6 Fields

Another important set of IPv6 header fields are the Traffic

Class and the Flow Label fields. Each one of them (or both
at the same time) can be used by an attacker to establish a
covert channel of communication.

The following values should be expected:

• Traffic Class: 0 (unless QoS is used)
• Flow Label: 0

IHRPv1 - Caendra Inc. © 2018 | p.135

1.3.3.1 Important IPv6 Fields

As previously mentioned, the IP Options portion of the IPv4

header has moved into the Extension Header (EH) of the IPv6
header.
No. Functions Remarks
Name
Must be examined by
Carries options for hops,
every hop on the path.
0 Hop-by-Hop Options e.g. Router Alert (for
Must be first EH, only
MLD, RSVP)
one allowed per packet.
Carries options for
Processed by
60 Destination Options destination (e.g. for
destination node only.
Mobile IPv6)
Lists IPv6 nodes that Different types, partly
43 Routing Header must be "hopped" on the deprecated (RFC 5095),
way to destination Mobile IP (RFC 6275).
Fragmentation (at Fragmentation (at
44 Fragmentation Header
source) source)

Other examples: 6:TCP, 17:UDP, 58:ICMPv6, 50/51: ESP/AH (IPSec)

Source: FIRST/SWITCH

IHRPv1 - Caendra Inc. © 2018 | p.136

1.3.3.1 Important IPv6 Fields

Note that Extension Headers are chained. For example:

The Next Header field is used so that the type of the protocol header that follows can be identified. More specifically, the Next
Header field identifies the type of header that resides right after the IPv6 header, or the IPv6 Extension header that carries it.

Source: FIRST/SWITCH

IHRPv1 - Caendra Inc. © 2018 | p.137

1.3.3.1 Important IPv6 Fields

Note that Extension Headers are chained. Example:

Concerns: Threats:
• The number of EHs is not limited 1. High number of EHs could be used for FW/IDS/IPS/RA-
Guard evasion
• The number of options within an (Hop-by-Hop or
Destination) Options Header is not limited 2. High number of EHs could be used to cause DoS to the
destination
• There is no defined order of EHs (only a 3. Manipulation/fuzzing of the EHs could be used to cause
recommendation) (Exception: Hop-by-Hop Options DoS to the destination
Header must be first and non-recurring) 4. An attacker could use EHs for stealthy payload
• EH have different formats exchanges or covert communication
Source: FIRST/SWITCH

https://www.juniper.net/documentation/en_US/junos/topics/concept/port-security-ra-guard.html IHRPv1 - Caendra Inc. © 2018 | p.138

1.3.3.1 Important IPv6 Fields

Here we see an example of IDS evasion using a high number of

EHs.
• In this case, 9 or more IPv6
Destination Options headers
were sent in a single,
unfragmented datagram for
IDS evasion purposes.

• A variation of the attack

could be 8 Dest Opt and 1
Frag Ext Hdr, or, 1 Hop-by-
Hop, 1 Routing Header, 1
Dest Opt Header, 1 Fragment
Header, 5 Dest Opt headers,
etc.

Source: Evasion of High-End IDPS Devices at the IPv6 Era

IHRPv1 - Caendra Inc. © 2018 | p.139

1.3.3.2 IPv6 Fragmentation

IPv6 Fragmentation
• The Unfragmentable Part will consist of the IPv6 main header plus any IPv6
Extension headers that must be processed by intermediate nodes en route to
the destination (suppose that those are the Hop-by-Hop and the Routing IPv6
Extension headers in a later example).

• The Fragmentable Part will consist of the rest of the packet, that is, any IPv6
Extension headers that need be processed only by the final destination
node(s), plus the upper-layer header and data (suppose that those are the
Destination Options IPv6 Extension header, TCP header and its payload in a
later example).

• Each fragment will be composed of:

o The Unfragmentable part of the original packet, with the Payload

Length of the original IPv6 header changed to contain the length of
this fragment packet only (excluding the length of the IPv6 header
itself), and the Next Header field of the last header of the
Unfragmentable part changed to 44

o A Fragment header containing the Next Header value that identifies

the first header of the Fragmentable Part of the original packet.
... <snipped for brevity>...
The fragment itself.
Source: Deering & Hinden, 1998 (RFC 2460)

IHRPv1 - Caendra Inc. © 2018 | p.140

1.3.3.2 IPv6 Fragmentation

Reassembly of IPv6 fragmented diagrams

• “The Unfragmentable part of the reassembled packet consists
of all headers up to, but not including, the Fragment header of
the first fragment packet (that is, the packet whose Fragment
Offset is zero), with the following change(s):
o The Next Header field of the last header of the
Unfragmentable Part is obtained from the Next
Header field of the first fragment's Fragment header.
...”

• In addition, according to RFC 2460:

“The following conditions are not expected to occur, but are not
considered errors if they do:
o ... <snipped for brevity>...
o The Next Header values in the Fragment headers of
different fragments of the same original packet may
differ. Only the value from the Offset zero fragment
packet is used for reassembly. ”

Source: Deering & Hinden, 1998 (RFC 2460)

IHRPv1 - Caendra Inc. © 2018 | p.141

1.3.3.2 IPv6 Fragmentation

Things will get worse with Fragmentation.

Threats:
1. DoS by sending a high number of incomplete
fragment sets (M-flag 1)
2. IDS/IPS evasion by sending overlapping or
nested fragments

Both the “fragmentable” and the “unfragmentable”

parts may contain any IPv6 Extension headers.
Source: FIRST/SWITCH

IHRPv1 - Caendra Inc. © 2018 | p.142

1.3.3.3 Abusing IPv6 Fragmentation & Detection

Let’s analyze some real life examples of IDS/IPS evasion by

combining incorrect usage of the Next Header values and
legitimate fragmentation.

IHRPv1 - Caendra Inc. © 2018 | p.143

1.3.3.3 Abusing IPv6 Fragmentation & Detection

Example 1: Building legitimate but not expected fragmentation

What if an attacker crafted the following
fragments?

• We notice that the Next Header value of the

IPv6 Fragment Extension header is set to 6
(not 60 as in the first fragment and like it
should be actually). Be careful not to mistake
this as normal.
• Remember the “Reassembly of IPv6
fragmented diagrams” slide. Even in the case
of such a crafted packet, the reassembly
should occur by using only the Next Header
value of the IPv6 Fragment Extension header
whose offset is equal to 0

Suppose that the upcoming Layer 4 protocol is TCP

Source: Evasion of High-End IDPS Devices at the IPv6 Era

IHRPv1 - Caendra Inc. © 2018 | p.144

1.3.3.3 Abusing IPv6 Fragmentation & Detection

Example 1: First fragment of the attack

• An IPv6 Destination Options
Extension Header follows the
Fragmentation Header; this is
due to the Next Header value
of the IPv6 Fragment
Extension header being 60.
• The Layer 4 header is TCP.
This is due to the Next Header
value of the IPv6 Destination
Options header being 6.
• Please, observe that the bytes
of the IPv6 Destination
Options header are as
following (highlighted): 06 00
01 00 01 02 00 00.

Source: Evasion of High-End IDPS Devices at the IPv6 Era

IHRPv1 - Caendra Inc. © 2018 | p.145

 1.3.3.3 Abusing IPv6 Fragmentation & Detection

Example 1: The reassembled datagram

• The Next Header value of the IPv6 Fragment
Extension header is 6 (not 60 like we saw on the
first fragment). In purple, is the Layer 4 header
(TCP) and its payload. Wireshark also indicates
a destination port of 256.

• Next, Wireshark warns us of a bogus Header

length. Specifically, the Header length seems to
be 0, while it should be at least 20.

• If we look at the first bytes of the TCP header,

we notice the following sequence : 06 00 01 00
01 02 00 00. If you recall, that’s the IPv6
Destination Options Extension header carried by
the first fragment.

• What happened is that due to the Next Header

value of the IPv6 Fragment Extension Header of
the second fragment being 6, Wireshark
misinterpreted the fragmentable part and
analyzed the IPv6 Destination Options Extension
header (red rectangle) as part of the TCP header
(purple, highlighted text). This is how the
Destination Port 256 came up.

A Tipping Point IDPS version back then, suffered

from the same kind of misinterpretation, resulting in
don’t “seeing” those fragmented packets as HTTP
traffic and allowing them to reach and exploit the
destination.
Source: Evasion of High-End IDPS Devices at the IPv6 Era

IHRPv1 - Caendra Inc. © 2018 | p.146

1.3.4 IPv6 Tunneling

It is a known fact that attackers have been using tunnel-

based IPv6 transition mechanisms for covert
communication and stealthy exfiltration over an IPv4-only
or dual-stack network.

IHRPv1 - Caendra Inc. © 2018 | p.147

1.3.4 IPv6 Tunneling

We will talk about flows in an upcoming module, but the

thing is that you can detect IPv6 tunnels inside network
logs or NetFlow records.

For example:
• IPv4 Protocol type 41 (ISATAP, 6to4 traffic)
• IPv4 to UDP 3544 (Teredo traffic)
• Traffic to 192.88.99.1 (6to4 anycast server)
• DNS server log: resolution of "ISATAP"
https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-629391.pdf IHRPv1 - Caendra Inc. © 2018 | p.148
1.3.4 IPv6 Tunneling

IPv6 tunnel detection with Wireshark (and a nice IPv6

analysis primer in general) can be found on the following
resource:
https://sharkfestus.wireshark.org/sharkfest.11/presentatio
ns/B-3_Leutert-Discovering_IPv6_with_Wireshark.pdf

IHRPv1 - Caendra Inc. © 2018 | p.149

1.3.4 IPv6 Tunneling

Consider the ipv6_tunnel_packets.pcap file found in this

module's resources. Can you identify the security issue?

IHRPv1 - Caendra Inc. © 2018 | p.150

1.3.4 IPv6 Tunneling

Consider the ipv6_tunnel_packets.pcap file found in this

module's resources. Can you identify the security issue?

• Frames 1 to 5 show the connection attempts to 64.233.169.104 (google.com) being closed [Notice the
FIN, ACK on frame 4]

• Frame 6 and 7 are actually IPv6 packets being transmitted by IPv4 UDP. They actually depict a Router
Solicitation and a Router Advertisement. We will analyze both in just a bit. For now, they can be seen as
the IPv6 mechanism to ask for an IPv6 address and offer an IPv6 prefix.

IHRPv1 - Caendra Inc. © 2018 | p.151

1.3.4 IPv6 Tunneling

Consider the ipv6_tunnel_packets.pcap file found in this module's

resources. Can you identify the security issue?
• If we now carefully look at frame 22,
we see an HTTP request being
made to ipv6.google.com.
Specifically, the HTTP GET string is
being carried by a UDP packet.

• If we right-click on this frame, then

Follow and finally UDP Stream, we
will also see the request was
successful.

This is most probably a case of IPv6

tunneling protocols being used to
bypass an IPv4-only firewall.

IHRPv1 - Caendra Inc. © 2018 | p.152

1.3.4 IPv6 Tunneling

Finally, IPv6 packets over IPv4

can be transmitted inside a
Generic Routing Encapsulation
(GRE) tunnel.

For this to happen, tunnel

software-assisted
encapsulation and de-
encapsulation is required.

IHRPv1 - Caendra Inc. © 2018 | p.153

1.3.5 ICMPv6

ICMPv6 is much more complex than ICMP. Below is a short overview

before we dive deeper into it and its usages. It inherits and extends the
functionalities of ICMP version 4.
Error-messages (1-127)
1:Destination Unreachable, 2:Packet too big (PMTUD),
3:Time Exceeded (Hop Limit), 4:Parameter Problem
Info-Messages (Ping)
128:Echo Request, 129:Echo Reply
Multicast Listener Discovery (MLD, MLD2)
130:Multicast Listener Query, 131/143:Multicast Listener Report/2
132:Multicast Listener Done
Neighbor Discovery (NDP), Stateless Autoconfiguration (SLAAC)
133:Router Solicitation, 134:Router Advertisement,
135:Neighbor Solicitation (DAD), 136:Neighbor Advertisement
(DAD), 137:Redirect Message
Other (Router Renumbering, Mobile IPv6, Inverse NS/NA,…)
138-153

IHRPv1 - Caendra Inc. © 2018 | p.154

1.3.5 ICMPv6

ICMPv6 Usages

• IPv6’s ICMPv6 Neighbor Discovery Protocol (NDP) is the equivalent

of ARP and ICMP router discovery and redirect in IPv4.

• IP/MAC association in IPv6 is conducted through Neighbor

Solicitation (NS) (ICMPv6 type 135) and Neighbor Advertisement
(NA) (ICMPv6 type 136) messages.

• The default gateway is identified via Router Solicitation (RS)

(ICMPv6 type 133) and Router Advertisement (RA) (ICMPv6 type
134) messages

IHRPv1 - Caendra Inc. © 2018 | p.155

1.3.5 ICMPv6

In IPv6, the concept of Stateless Autoconfiguration (SLAAC) exists.

• Stateless autoconfiguration allows a node to be configured without

any configuration server.
• Interaction between a node and a local IPv6 router is required for the
node to configure its own globally routable addresses.
• The address combines the adapter MAC address with network
prefixes identified through interaction with the neighboring router.
• Multihomed hosts perform autoconfiguration for each interface.
• Stateless autoconfiguration uses the Neighbor Discovery protocol.

IHRPv1 - Caendra Inc. © 2018 | p.156

1.3.5 ICMPv6

SLAAC

Stateless Autoconfiguration steps

• Link-Local Address Generation: The device generates a link-local address.
• Ensure Link-Local Address is Unique:
o Is there a host with the same address?
o A Neighbor Solicitation message is sent
o Listens for a Neighbor Advertisement
• Link-Local Address Assignment: Address used for local network communication only
• Router Contact:
o Consult with the local router
o A Router Solicitation message is sent
o Listen for a Router Advertisement
• Router Direction:
o Stateful or Stateless?
o Prefix?
• Global Address Configuration: Global unicast address is formed by combining the MAC address (IID) and the
network prefix

IHRPv1 - Caendra Inc. © 2018 | p.157

1.3.5 ICMPv6

Let’s now see how those important ICMPv6 messages look

like on the wire.

IHRPv1 - Caendra Inc. © 2018 | p.158

1.3.5 ICMPv6

Router Advertisement Packet

Source Address: Must be the

link-local addresses assigned
to the interface from which
this message is sent.

Destination Address: Usually

the Source Address from
where a Router Solicitation
originated or the all-nodes
multicast address

IHRPv1 - Caendra Inc. © 2018 | p.159

1.3.5 ICMPv6

Router Solicitation Packet

Source Address: Usually

0:0:0:0:0:0:0:0 or the
configured unicast address of
the interface.

Destination Address: Usually

the all-routers multicast
address (FF02::2).

IHRPv1 - Caendra Inc. © 2018 | p.160

1.3.5 ICMPv6

Neighbor Solicitation Packet

Source Address: An addresses

assigned to the interface from
which this message is sent or
0:0:0:0:0:0:0:0.

Destination Address: The

solicited-node multicast
address corresponding to the
target address or the target
address.

IHRPv1 - Caendra Inc. © 2018 | p.161

1.3.5 ICMPv6

Neighbor Advertisement

A node sends Neighbor

Advertisements in response
to Neighbor Solicitations and
sends unsolicited Neighbor
Advertisements in order to
(unreliably) propagate new
information quickly.

IHRPv1 - Caendra Inc. © 2018 | p.162

1.3.5 ICMPv6

Neighbor Solicitation Packet

To a specific unicast address

Duplicate Address Detection.

IHRPv1 - Caendra Inc. © 2018 | p.163

1.3.6 IPv6 Security Shortcomings

Let’s now analyze some of IPv6’s security shortcomings.

Since we just analyzed IPv6’s Neighbor Discovery Protocol,

let’s focus on some of its weaknesses.

IHRPv1 - Caendra Inc. © 2018 | p.164

1.3.6 IPv6 Security Shortcomings

If you recall, when IPv4 is in place, an attacker can misuse

ARP and ICMPv4 messages to manipulate traffic.

Unfortunately, this is the case with IPv6 as well; this time

NDP messages can be misused to achieve network traffic
manipulation.

IHRPv1 - Caendra Inc. © 2018 | p.165

 1.3.6 IPv6 Security Shortcomings

Network Discovery Attacks

Attackers ultimately want to introduce incorrect IPv6 host address/link
layer pairings; this can be achieved via two (2) distinct ways:

• An attacker on the same local network can tamper with a returned

Neighbor Advertisement (NA) spoofing an address, after a Neighbor
Solicitation (NS) request is sent; this is the equivalent of ARP poisoning
in IPv4.

• An attacker can also craft an NS request containing the fake IPv6 host
address/link layer pairing. Listening neighbors will introduce this ill-
intended pairing in their neighbor cache; this is the equivalent of abused
Gratuitous ARP in IPv4.
IHRPv1 - Caendra Inc. © 2018 | p.166
 1.3.6 IPv6 Security Shortcomings

Network Discovery Attacks

Other Network Discovery attacks include:

• Causing a DoS, by spoofing an NA response, informing the NS request sender

that the target host resides at a non-existing link address. The same can be
achieved by abusing the Neighbor Unreachable Protocol to sent a spoofed NA
response informing that communication with the target is not possible.

• Causing a DoS, by spoofing an NS response, informing that the address is taken.

Recall the Duplicate Address Detection procedure. DAD could be abused multiple
times to prevent a host from being assigned an address.

• Executing a man-in-the-middle attack, by spoofing an RA, informing the host that

sent the RS message that the attacker’s host is the router.
IHRPv1 - Caendra Inc. © 2018 | p.167
 1.3.6 IPv6 Security Shortcomings

Network Discovery Attacks

What you should also be aware of is that Secure Neighbor

Discovery (SEND) exists, ensuring message integrity and
enforcing message source/sender association. It does so
by utilizing a timestamp and a nonce.

More information about SEND can be found in RFC 3971.

https://tools.ietf.org/html/rfc3971 IHRPv1 - Caendra Inc. © 2018 | p.168

1.3.6 IPv6 Security Shortcomings

Those, are only a subset of the attacks that can be executed against an
IPv6 implementation. For more, please refer to the following resources:

1. https://www.ripe.net/support/training/material/ipv6-
security/ipv6security-slides.pdf

2. https://www.blackhat.com/docs/sp-14/materials/arsenal/sp-14-
Schaefer-Workshop-Slides.pdf

3. https://www.tno.nl/media/3274/testing_the_security_of_ipv6_imple
mentations.pdf

IHRPv1 - Caendra Inc. © 2018 | p.169

Lab 1 for Intrusion Detection
by Analyzing Traffic

Traffic Analysis Challenges

During this lab you will:
• Refresh your networking
knowledge
• Learn to identify TCP
spoofing and internal botnet-
like activity
• Practice identifying attacks
by analyzing network traffic,
including IPv6-based ones

*To access, go to the course in your members area and click the resources drop-down in the appropriate module
line to access the files for this offline lab.
IHRPv1 - Caendra Inc. © 2018 | p.170
References

IHRPv1 - Caendra Inc. © 2018 | p.171

 References
Wireshark
https://www.wireshark.org/

MAC Address Lookup

https://www.macvendorlookup.com/

RFC 826
https://www.ietf.org/rfc/rfc826.txt

Wireshark Display Filter Reference for ARP

https://www.wireshark.org/docs/dfref/a/arp.html

IHRPv1 - Caendra Inc. © 2018 | p.172

 References
Colasoft’s Capsa
https://www.colasoft.com/download/products/download_capsa.php

RFC 791
https://www.ietf.org/rfc/rfc791.txt

IANA IPv4 Address Space Registry

https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml

CVE-2018-5391
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV180022

IHRPv1 - Caendra Inc. © 2018 | p.173

 References
GestióIP IPv6 resources
http://www.gestioip.net/docu/ipv6_address_examples.html

RFC 2460
https://tools.ietf.org/html/rfc2460#page-4

Internet Protocol Version 6 Address Space

https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml

RA-Guard
https://www.juniper.net/documentation/en_US/junos/topics/concept/port-security-ra-guard.html

IHRPv1 - Caendra Inc. © 2018 | p.174

 References
NetFlow records
https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-
solution/white_paper_c11-629391.pdf

Discovering IPv6 with Wireshark

https://sharkfestus.wireshark.org/sharkfest.11/presentations/B-3_Leutert-
Discovering_IPv6_with_Wireshark.pdf

RFC 3971
https://tools.ietf.org/html/rfc3971

Ripe NCC – IPv6 Security

https://www.ripe.net/support/training/material/ipv6-security/ipv6security-slides.pdf

IHRPv1 - Caendra Inc. © 2018 | p.175

 References
IPv6 Attack & Defense Strategies
https://www.blackhat.com/docs/sp-14/materials/arsenal/sp-14-Schaefer-Workshop-Slides.pdf

Testing the Security of IPv6 Implementations

https://www.tno.nl/media/3274/testing_the_security_of_ipv6_implementations.pdf

IHRPv1 - Caendra Inc. © 2018 | p.176

 Labs
Traffic Analysis Challenges
During this lab you will:
• Refresh your networking knowledge
• Learn to identify TCP spoofing and internal botnet-like activity
• Practice identifying attacks by analyzing network traffic, including IPv6-based ones

*To access, go to the course in your members area and click the resources drop-down in
the appropriate module line to access the files for this offline lab.
IHRPv1 - Caendra Inc. © 2018 | p.177