Intrusion Detection By Analyzing Traffic

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

2.1 Analyzing & Detecting Transport Layer Attacks

2.2 Analyzing Common Application Protocol Traffic & Attacks

2.3 Effectively Using Open Source IDS (Lab-based)

IHRPv1 - Caendra Inc. © 2019 | p.2

Learning Objectives

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

understanding of:

✓ How the attacks at the Transport and Application layers

work
✓ How to detect attacks at the Transport and Application
layers
✓ The detection capabilities of open-source IDS

IHRPv1 - Caendra Inc. © 2019 | p.3

 2.1

Analyzing & Detecting

Transport Layer Attacks

IHRPv1 - Caendra Inc. © 2018 | p.4

2.1 Analyzing & Detecting Transport Layer Attacks

Up to this point, we have seen how to analyze and detect

attacks at the IEEE 802.x Link layer.

Let’s now cover how to analyze and detect attacks at the

Transport layer. We’ll focus on the TCP, UDP and ICMP
protocols.

IHRPv1 - Caendra Inc. © 2018 | p.5

2.1.1 TCP

Let’s start our journey to understanding the Transport layer,

by analyzing the most important aspects of the TCP
protocol.

TCP is a reliable and connection-oriented protocol,

leveraged by many application-layer protocols to deliver
packets.

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

2.1.1 TCP

TCP is quite complex, due to its rich functionality. This is

apparent when studying the TCP header.

IHRPv1 - Caendra Inc. © 2018 | p.7

2.1.1 TCP

The TCP header contains information such as:

• Source Port: The port from where the packet is
transmitted
• Destination Port: The port where the packet will arrive
• Sequence Number: Field value that ensures the
integrity of a data stream. It identifies a TCP segment.
• Acknowledgement Number: Field value containing the
expected sequence number of the next packet to arrive
from the connection peer.
• Flags: Note that, the URG, ACK, PSH, RST, SYN and FIN
flags are used to identify the type of the packet in
transit
• Window Size: Indicates the TCP receiver buffer size
• Checksum: Field value that ensures the integrity of the
TCP header and data upon arrival
• Urgent Pointer: In case the URG flag is set, this field
indicates the position within the packet from where
reading data should start
• Options: Optional fields that may be specified
Source: https://skminhaj.wordpress.com/2016/02/15/tcp-segment-vs-udp-datagram-header-format/

IHRPv1 - Caendra Inc. © 2018 | p.8

2.1.1 TCP

Notes:
1. The TCP header’s size is 20 bytes,
when no options are specified
2. Offset = TCP header length
3. When the SYN flag is set on a TCP
segment, you’ll most probably come
across the TCP maximum segment
size option
4. When the SYN flag is set, there are
no data following the header

Source: https://skminhaj.wordpress.com/2016/02/15/tcp-segment-vs-udp-datagram-header-format/

IHRPv1 - Caendra Inc. © 2018 | p.9

2.1.1 TCP

As already mentioned, TCP is a connection-oriented

protocol. For a connection to be established between two
hosts, a procedure known as 3-way handshake is required.
Then, the actual data transmission can commence.

IHRPv1 - Caendra Inc. © 2018 | p.10

2.1.1 TCP

0 1
The header fields involved 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
in the handshake are: | Source Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Sequence number | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
• Acknowledgement | Acknowledgment Number |
numbers +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data | |U|A|P|R|S|F|
• SYN and ACK flags | Offset| Reserved |R|C|S|S|Y|I|
| | |G|K|H|T|N|N|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |

IHRPv1 - Caendra Inc. © 2018 | p.11

2.1.1 TCP

The steps in the handshake are used to synchronize the sequence and
acknowledgement numbers between the server and the client.

SYN

SYN+ ACK

ACK

Time Time
IHRPv1 - Caendra Inc. © 2018 | p.12
2.1.1 TCP

During the first step, the client sends a TCP packet to the server with the
SYN flag enabled and a random sequence number.

SYN
Seq: 329 Ack: 0

Time Time
IHRPv1 - Caendra Inc. © 2018 | p.13
2.1.1 TCP

In the second step, the server replies by sending a packet with both the
SYN and ACK flag set and another random sequence number.

SYN
Seq: 329 Ack: 0

SYN/ACK
Seq: 498 Ack: 330

Time Time
IHRPv1 - Caendra Inc. © 2018 | p.14
2.1.1 TCP

The ACK number is always a simple increment of the SYN number sent
by the client.

SYN
Seq: 329 Ack: 0

SYN/ACK
Seq: 498 Ack: 330

Time Time
IHRPv1 - Caendra Inc. © 2018 | p.15
2.1.1 TCP

Finally the client completes the synchronization by sending an ACK

packet. Note that the client behaves just like the server when sending
ACK packets.

SYN
Seq: 329 Ack: 0

SYN/ACK
Seq: 498 Ack: 330

ACK
Seq: 330 Ack: 499
Time Time
IHRPv1 - Caendra Inc. © 2018 | p.16
2.1.1 TCP

Consider the 3-way_handshake.pcap file found in this module's resources.

Let’s now see, how the 3-way handshake looks like on the wire (Wireshark).

IHRPv1 - Caendra Inc. © 2018 | p.17

2.1.1 TCP

Consider the 3-way_handshake.pcap file found in this module's resources.

Let’s now see, how the 3-way handshake looks like on the wire (Wireshark).

IHRPv1 - Caendra Inc. © 2018 | p.18

2.1.1 TCP

Note: Wireshark has an option called Relative

sequence numbers on, by default. According
to the official definition from the online
Wireshark Wiki,

“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.”
https://wiki.wireshark.org/TCP_Relative_Sequence_Numbers IHRPv1 - Caendra Inc. © 2018 | p.19
2.1.1 TCP

For example, the initial relative

sequence number shown in
packet #1 (of the 3-
way_handshake.pcap file) is 0.
Relative sequence
If you look at the ASCII decode numbers option enabled
though, you’ll notice that the
actual sequence number is
0xf61c6cbe, or 4129057982
decimal.

IHRPv1 - Caendra Inc. © 2018 | p.20

2.1.1.1 Suspicious TCP Traffic

Let’s now go through some suspicious TCP traffic cases,

but before doing so, find below some tips on what kind of
TCP traffic should alarm you.
Normal TCP Traffic Suspicious TCP Traffic
3 way handshake (SYN, SYN/ACK, Excessive SYN packets (scanning)
ACK)
Usage of different flags
Single host to multiple ports or single host
to multiple nodes (scanning)

IHRPv1 - Caendra Inc. © 2018 | p.21

2.1.1.2 Sequence Number Prediction & SYN Scanning

One of the ways using which the venerable Nmap tool tries
to perform OS fingerprinting, is by examining the Initial
Sequence Numbers (ISNs) generated by the target host
(after connections are being attempted to a listening port).
Each TCP/IP stack (and subsequently each OS) features its
own way of generating Initial Sequence Numbers.

https://nmap.org/book/osdetect-methods.html#osdetect-gcd IHRPv1 - Caendra Inc. © 2018 | p.22

2.1.1.2 Sequence Number Prediction & SYN Scanning

More specifically, Nmap sends a series of SYN packets to

an open port and tries to perform OS fingerprinting, by
attempting to identify the ISN generation formula in the
returned SYN/ACK and comparing the returned values to a
file that contains expected returned values for a series of
checks.

IHRPv1 - Caendra Inc. © 2018 | p.23

2.1.1.2 Sequence Number Prediction & SYN Scanning

Open the nmap_sequence_number_prediction.pcap file

found in this module's resources, to see what could be a
Nmap OS fingerprinting attempt.

IHRPv1 - Caendra Inc. © 2018 | p.24

 2.1.1.2 Sequence Number Prediction & SYN Scanning

Detection
The first thing you should notice, is the big amount of SYN packets being sent
to the 192.168.1.2 host (in a short amount of time and without the
corresponding SYN/ACK packets).
If you also carefully analyze the series of SYN packets that Nmap sent, you will
notice something weird. Nmap repeatedly used the ISN from the scanning host,
while scanning the different ports of the remote host. Unique ISNs should be
used, while attempting to connect to different ports of a remote host.

IHRPv1 - Caendra Inc. © 2018 | p.25

 2.1.1.2 Sequence Number Prediction & SYN Scanning

Detection
Once you identify a scanning host, you can determine if you are dealing
with Nmap, by noting the scanning host’s ISN and executing the below.
>> tcpdump -S -r nmap_sequence_number_prediction.pcap tcp[4:4] = 3917476875

The scanning
host’s ISN reuse,
indicates that the
scanning/fingerp
rinting attempt
most probably
originates from a
Nmap instance

IHRPv1 - Caendra Inc. © 2018 | p.26

2.1.1.3 Source Port Abnormalities

When it comes to ports, what you should know is that a

distinction exists between Privileged (server) ports and
Unprivileged (client)/ephemeral ports. Specifically,

• Privileged (server) ports [1-1023]  Should remain unchanged

during the entire connection
• Unprivileged (client)/ephemeral ports [> 1023]  Chosen
only for one connection. Can be chosen again after the connection closes.

IHRPv1 - Caendra Inc. © 2018 | p.27

2.1.1.3 Source Port Abnormalities

Consider the nmap_sequence_number_prediction.pcap file

found in this module's resources once again.

Can you spot anything irregular?

IHRPv1 - Caendra Inc. © 2018 | p.28

 2.1.1.3 Source Port Abnormalities

Detection

IHRPv1 - Caendra Inc. © 2018 | p.29

 2.1.1.3 Source Port Abnormalities

Detection

If you carefully look at packets #1, #3-#9 and #12-#13, you will notice that the host 192.168.1.6 uses the same source port (36901)
for multiple connection attempts to different ports of the remote host. This is abnormal. The normal behavior would be
incrementing the source port numbers inside the ephemeral port range.

IHRPv1 - Caendra Inc. © 2018 | p.30

2.1.1.4 Destination Port Abnormalities

Consider the strange_scanning.pcap file found in this

module's resources.

Can you spot anything suspicious?

IHRPv1 - Caendra Inc. © 2018 | p.31

 2.1.1.4 Destination Port Abnormalities

Detection

IHRPv1 - Caendra Inc. © 2018 | p.32

 2.1.1.4 Destination Port Abnormalities

Detection

Obviously, we are dealing with a scanning attempt, but what is that destination port 0 (TCP) all about?
A host is not supposed to be listening on port 0. A scanning tool sending packets to port 0 (TCP) of the remote host, is trying
identify if the remote host is alive. If the remote host is alive, then, a RST response should be sent to all those packets.

IHRPv1 - Caendra Inc. © 2018 | p.33

2.1.1.5 TCP RST Attack

It has been known for years that an existing TCP connection can
be cut apart through a crafted TCP RST (and other) packet sent
either to the client or the server. For a successful RST attack to
be executed, an attacker should have prior knowledge of the
below.

• Source Port
• Destination Port
• Source IP
• Destination IP
• “correct” Sequence Number
IHRPv1 - Caendra Inc. © 2018 | p.34
2.1.1.5 TCP RST Attack

It has been known for years that an existing TCP connection can
be cut apart through a crafted TCP RST (and other) packet sent
either to the client or the server. For a successful RST attack to
be executed, an attacker should have prior knowledge of the
below.
Those can be easily identified by an attacker in
• Source Port the same network, who is sniffing the network
traffic.
• Destination Port
• Source IP TCP RST attacks can also be executed remotely
though, as described in the following paper
• Destination IP https://packetstormsecurity.com/files/downloa
d/33170/SlippingInTheWindow_v1.0.doc
• “correct” Sequence Number
IHRPv1 - Caendra Inc. © 2018 | p.35
2.1.1.5 TCP RST Attack

Consider the TCP_RST_Attack.pcap file found in this

module's resources.

Try to identify any abnormalities.

IHRPv1 - Caendra Inc. © 2018 | p.36

 2.1.1.5 TCP RST Attack

Detection

IHRPv1 - Caendra Inc. © 2018 | p.37

 2.1.1.5 TCP RST Attack

Detection

• If you carefully look at packet #12, you will notice that the 192.168.1.5 host sent a TCP RST packet and subsequently terminated the
connection. So far, everything seems normal. Now, if you carefully look at packet #11, you will notice normal data transmission
originating from the 192.168.1.5 host, but its MAC address is different than the one included in packet #12.
• It looks like an attacker executed a TCP RST attack to terminate the connection, spoofing the 192.168.1.5 host.
• The next sequence number was first identified through sniffing traffic and then used inside the spoofed RST packet.

IHRPv1 - Caendra Inc. © 2018 | p.38

2.1.1.6 TCP Session Hijacking

As you might have figured out by now, TCP is defenseless

against “packet injection” attacks. An attacker could
choose to hijack a whole TCP session, instead of executing
a simple TCP RST attack.

TCP session hijacking requires the same prior knowledge

as the TCP RST attack.

IHRPv1 - Caendra Inc. © 2018 | p.39

2.1.1.6 TCP Session Hijacking

Consider the TCP-hijacking.pcap file found in this module's

resources.

Try to identify any abnormalities.

IHRPv1 - Caendra Inc. © 2018 | p.40

 2.1.1.6 TCP Session Hijacking

Detection

IHRPv1 - Caendra Inc. © 2018 | p.41

 2.1.1.6 TCP Session Hijacking

Detection

• This is obviously a capture file of a Telnet session. Telnet offers no encryption and thus, we can see every command the client issued and every result returned by the
server in clear text.
• Let’s analyze packet #15.
o TCP Retransmission is displayed because the sequence number and the acknowledgement number of this packet are the same as the ones in packet #11.
o The MAC address of the client (192.168.1.4) in this packet is different than the MAC address that is included in all previous packets related to this host.
• It looks like an attacker has taken over (hijacked) the whole Telnet session. This is also apparent in packet #17, that includes the MAC address of the attacker and the
command the attacker issued (uname –a)
• The server has no defense mechanism to detect that the Telnet session is hijacked and sends the output of the uname –a command back to the 192.168.1.4 client.

IHRPv1 - Caendra Inc. © 2018 | p.42

2.1.1.7 TCP Options Abuse

At the end of the TCP header, one may find TCP options
being specified.

Historically, TCP options have been abused for evasion and

information gathering purposes.

IHRPv1 - Caendra Inc. © 2018 | p.43

2.1.1.7.1 TCP Timestamps Option

One example of a TCP option that can be abused, is the TCP

Timestamps option.

According to RFC 1323, the Timestamps option carries two four-byte

timestamp fields. The Timestamp Value field (TSval) contains the
current value of the timestamp clock of the TCP sending the option.
The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is
set in the TCP header; if it is valid, it “echos” a timestamp value that
was sent by the remote TCP in the TSval field of a Timestamps option.

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

2.1.1.7.1 TCP Timestamps Option

Specifically, the TCP Timestamps options can be abused in

order to:
1. Determine the patch level of a system, through uptime
analysis
2. Perform host identification using clock skew
3. Identify how a target DMZ is structured

http://www.caida.org/publications/papers/2005/fingerprinting/KohnoBroidoClaffy05-
devicefingerprinting.pdf
IHRPv1 - Caendra Inc. © 2018 | p.45
2.1.1.7.1 TCP Timestamps Option

Technical details on how attackers are abusing the TCP

Timestamps option can be found in the following link.
https://www.scip.ch/en/?labs.20150305

https://www.scip.ch/en/?labs.20150305 IHRPv1 - Caendra Inc. © 2018 | p.46

2.1.1.7.2 Leveraging TCP Option Support & Ordering

Oftentimes, TCP/IP stacks, support a subset of the

available TCP options and also, perform TCP option storing
in their own unique order. Nmap leverages the above (and
other things), in order to perform OS fingerprinting.

IHRPv1 - Caendra Inc. © 2018 | p.47

2.1.1.7.2 Leveraging TCP Option Support & Ordering

The following article offers technical details (as well as an

example) on how OS fingerprinting can be achieved by
analyzing TCP options (refer to the TCP Options section).
https://nmap.org/nmap-fingerprinting-article.txt

IHRPv1 - Caendra Inc. © 2018 | p.48

2.1.2 UDP

UDP Overview

✓ UDP is a less complicated (than TCP) and lightweight

protocol, due to the lack of fields that ensure reliable delivery
✓ Unlike TCP, UDP can deliver traffic to multiple hosts.
✓ Privileged (server) and ephemeral (client) ports exist, just like
in TCP (For each new connection, a different ephemeral port should be utilized)
✓ IPv6 dictated some changes such as:
▪ UDP length 0 that designates a jumbogram packet
▪ The requirement for UDP checksums
IHRPv1 - Caendra Inc. © 2018 | p.49
2.1.2 UDP

UDP-based attacking techniques, such as DNS Command &

Control, DNS exfiltration etc. will be covered as the course
progresses. Hang on…

IHRPv1 - Caendra Inc. © 2018 | p.50

2.1.3 ICMP

ICMP Overview

✓ The Internet Control Message Protocol (ICMP) is another less

complicated (than TCP) and lightweight protocol
✓ It is commonly used for network troubleshooting and
delivering error messages
✓ It is an unreliable protocol
✓ It can send and respond to broadcast messages
✓ There are no ports and client-server communications involved
IHRPv1 - Caendra Inc. © 2018 | p.51
2.1.3.1 ICMP Abuse

Historically, ICMP has been abused for all kinds of

nefarious purposes, from mapping and reconnaissance all
the way to DDoS and Man-In-The-Middle attacks.

IHRPv1 - Caendra Inc. © 2018 | p.52

2.1.3.1 ICMP Abuse

We all know that we can map live hosts via ICMP echo
requests to a single, broadcast or subnet address. This
mapping technique though has been abused in the past to
such a degree that most sites nowadays disallow inbound
and/or outbound ICMP echo requests.

This fact triggered the creation of a new wave of ICMP-

based mapping techniques by attackers.

IHRPv1 - Caendra Inc. © 2018 | p.53

2.1.3.1.1 ICMP Address Mask Request/Reply

ICMP can be used to identify a target host’s subnet mask.

Such information can be useful in distinguishing subnets
within an IP address range.

This can be achieved, by sending an ICMP address mask

request to a given target.Such a request may elicit
responses from gateway hosts or other network devices
only.

IHRPv1 - Caendra Inc. © 2018 | p.54

 2.1.3.1.1 ICMP Address Mask Request/Reply

Detection

An ICMP Address Mask Request looks as follows on the wire.

IHRPv1 - Caendra Inc. © 2018 | p.55

2.1.3.1.2 ICMP Timestamp Request/Reply

ICMP can also be used to obtain timestamps from remote

systems. We previously covered how valuable a timestamp
can be. That being said, as the years progressed many
Operating Systems have implemented less accurate
timestamps, making this approach unreliable.

An attacker can still use this approach though, as an

alternative to ping when things are filtered.

IHRPv1 - Caendra Inc. © 2018 | p.56

 2.1.3.1.2 ICMP Timestamp Request/Reply

Detection

An ICMP Timestamp Request looks as follows on the wire.

IHRPv1 - Caendra Inc. © 2018 | p.57

 2.1.3.1.2 ICMP Timestamp Request/Reply

Detection

An ICMP Timestamp Reply looks as follows on the wire.

IHRPv1 - Caendra Inc. © 2018 | p.58

 2.1.3.1 ICMP Timestamp Request/Reply

Detection

A great paper showcasing ICMP usage during scanning

activities can be found below.
https://www.cs.dartmouth.edu/~sergey/me/netreads/ICM
P_Scanning_v3.0.pdf

IHRPv1 - Caendra Inc. © 2018 | p.59

2.1.3.1.3 Smurf Attack

ICMP has been used in the past to execute devastating

Distributed Denial of Service (DDoS) attacks. Such an
attack, was the notorious Smurf attack.

IHRPv1 - Caendra Inc. © 2018 | p.60

2.1.3.1.3 Smurf Attack

A Smurf attack is executed as follows:

1. A fake Echo request is generated containing a

spoofed source IP, which is actually the target
server address
2. The request is sent to an intermediate IP
broadcast network (The intermediate
site/router has to allow ICMP echo requests
to broadcast address)
3. The request is transmitted to all of the
network hosts on the network
4. All hosts on the network that respond, will
send an ICMP echo reply to the target server
5. If the number of ICMP responses is big
enough, denial of service or performance
degradation is caused to the target server.
Source: https://www.incapsula.com

IHRPv1 - Caendra Inc. © 2018 | p.61

2.1.3.1.3 Smurf Attack

Suppose, an environment is set up as follows and the attacker

(192.168.0.7) performs a Smurf attack against the victim (192.168.0.5)

Source: http://www.uwindsor.ca/

IHRPv1 - Caendra Inc. © 2018 | p.62

 2.1.3.1.3 Smurf Attack

Detection

The Smurf attack on the wire looks as follows.

Source: http://www.uwindsor.ca/

IHRPv1 - Caendra Inc. © 2018 | p.63

 2.1.3.1.3 Smurf Attack

Detection

The Smurf attack on the wire looks as follows.

The spoofed
packet was
injected and
broadcasted
successfully

The victim
no longer
replies to
Echo
Requests

Source: http://www.uwindsor.ca/

IHRPv1 - Caendra Inc. © 2018 | p.64

 2.1.3.1.3 Smurf Attack

Detection

The IPv6 variant of the Smurf attack on the wire looks as follows.

IHRPv1 - Caendra Inc. © 2018 | p.65

 2.1.3.1.3 Smurf Attack

Detection

The IPv6 variant of the Smurf attack on the wire looks as follows.
The spoofed
packet was
injected and
broadcasted
successfully

IHRPv1 - Caendra Inc. © 2018 | p.66

2.1.3.1.4 ICMP Tunneling

It should be noted, that ICMP can be misused to create a

covert channel of communication. This can be achieved
through ill-intended ICMP tunneling.

Numerous ICMP tunneling solutions exists, but attackers

seem to prefer the ptunnel one.

http://freshmeat.sourceforge.net/projects/ptunnel/ IHRPv1 - Caendra Inc. © 2018 | p.67

2.1.3.1.4 ICMP Tunneling

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

resources. Try to identify any abnormalities.

IHRPv1 - Caendra Inc. © 2018 | p.68

 2.1.3.1.4 ICMP Tunneling

Detection

IHRPv1 - Caendra Inc. © 2018 | p.69

 2.1.3.1.4 ICMP Tunneling

Detection

• The capture file seems imbalanced as far as the amount of Echo requests and Echo replies is concerned. You can see two
or more replies for each request
• An Echo request and the associated Echo reply should have the same length (have identical payloads). This isn’t the case in
this capture file.
• The payload size in some ICMP packets is a lot bigger than normal. For example, see packet #16.

IHRPv1 - Caendra Inc. © 2018 | p.70

 2.1.3.1.4 ICMP Tunneling

Detection

Let’s dig deeper…

First, download ptunnel and then, open

the ptunnel.h file using a text editor.
Around line #191, you will identify that
the ptunnel header begins with a magic
number, a short unique sequence of
bytes that lets the recipient know that
the ICMP payload should be treated as
ptunnel traffic. This magic number is
0xD5200880, by default.

http://freshmeat.sourceforge.net/projects/ptunnel/ IHRPv1 - Caendra Inc. © 2018 | p.71

 2.1.3.1.4 ICMP Tunneling

Detection

It looks like all ICMP packets of

this capture file include the
previously mentioned ptunnel
magic value (0xD5200880),
inside the ICMP payload. The
yellow rectangles designate the
ICMP header session identifier.

IHRPv1 - Caendra Inc. © 2018 | p.72

 2.1.3.1.4 ICMP Tunneling

Detection

In addition, there are

indications that a whole
session, between an attacker
and a compromised machine, is
being concealed through ICMP
traffic (ICMP tunneling).

IHRPv1 - Caendra Inc. © 2018 | p.73

 2.1.3.1.4 ICMP Tunneling

Detection

The fact that a whole session,

between an attacker and a
compromised machine, is being
concealed through ICMP traffic
(ICMP tunneling) can be also
identified by using the strings
Linux command against the
capture file as follows.
>> strings ptunnel.pcap

IHRPv1 - Caendra Inc. © 2018 | p.74

2.1.3.1.5 Abusing ICMP Redirect

When two machines want to communicate with each other

the router has to find the shortest path between them.

If there is an alternate path between the two machines and

if it is shorter than the previous path, then, the router will
send an ICMP redirect packet to the sender machine.

IHRPv1 - Caendra Inc. © 2018 | p.75

2.1.3.1.5 Abusing ICMP Redirect

This ICMP redirect packet will instruct the sender to change

its routing table so that it uses the shortest path.

However, such ICMP redirect packets can be forged by a

attacker and make the sender host redirect its packet to an
attacker-controlled or non-existing destination.

IHRPv1 - Caendra Inc. © 2018 | p.76

2.1.3.1.5 Abusing ICMP Redirect

Suppose, an environment is set up as follows. The network has been

hardened to prevent successful execution of ARP- spoofing-based
attacks. Somehow, the pentester residing in the client network,
managed to sniff client traffic and capture clear-text credentials.

IHRPv1 - Caendra Inc. © 2018 | p.77

2.1.3.1.5 Abusing ICMP Redirect

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

resources. Try to identify how the pentester managed to
sniff client traffic, in spite of the anti-ARP-poisoning
measures.

Note: The majority of TCP traffic has been removed.

IHRPv1 - Caendra Inc. © 2018 | p.78

 2.1.3.1.5 Abusing ICMP Redirect

Detection

IHRPv1 - Caendra Inc. © 2018 | p.79

 2.1.3.1.5 Abusing ICMP Redirect

Detection

• A large number of ICMP Redirect packets exist. In those packets the router instructs the client 10.100.13.126 to make a change in its routing table to use
the gateway 10.100.13.20 for all subsequent packets. At this moment, you should check if the gateway 10.100.13.20 is a legitimate gateway.
• If you filter the whole capture file, based on the MAC address of the router (10.100.13.1) [eth.src==72:9b:2f:a0:90:91], you will notice that this MAC
address is associated with the 10.100.13.20 machine.
• Even though it is not clearly visible in the capture file, every HTTP request can now be sniffed by the 10.100.13.20 host, as a result of the ICMP Redirect
attack.
• So, it looks like the penetration tester crafted malicious ICMP Redirect packets, spoofing the router, and mounted an ICMP Redirect attack.
IHRPv1 - Caendra Inc. © 2018 | p.80
2.1 Analyzing & Detecting Transport Layer Attacks

This is the end of the Analyzing & Detecting Transport Layer

Attacks part.

Moving forward, we will show you how to analyze common

application protocol traffic and attacks.

IHRPv1 - Caendra Inc. © 2018 | p.81

 2.2

Analyzing Common Application

Protocol Traffic & Attacks

IHRPv1 - Caendra Inc. © 2018 | p.82

2.2 Analyzing Common Application Protocol Traffic &
Attacks

We eventually reached the Application layer of the TCP/IP

model. In this part of the module, we will focus our
attention on Microsoft-specific protocols, HTTP(S), SMTP
and DNS .

We will analyze them on the wire and also see attacks that
either leverage them or misuse them.

IHRPv1 - Caendra Inc. © 2018 | p.83

2.2.1 Microsoft-specific Protocols

Undoubtedly, Windows is the most widely used Operating

System. All those Windows hosts out there, use some
universal and Microsoft-specific/Microsoft-implemented
protocols. Let’s go through them and see how they look in
the wire.

IHRPv1 - Caendra Inc. © 2018 | p.84

2.2.1.1 NetBIOS

Network Basic Input/Output System (NetBIOS) is a set of

protocols developed in the early 1980s for LAN
communications, in order to provide services for the
session layer (fifth layer in the OSI model).

A few years later, it was adopted by Microsoft for their

networking over LAN, and then it was migrated for working
over TCP/IP (NetBIOS over TCP/IP—NBT), which is
discussed in RFC 1001 and 1002.
IHRPv1 - Caendra Inc. © 2018 | p.85
2.2.1.1 NetBIOS

In today's networks, NetBIOS provides three services:

• Name service (port 137) for name registration and name

to IP address resolution. Also referred to as NetBIOS-NS.
• Datagram distribution service (port 138) for service
announcements by clients and servers. Also referred to
as NetBIOS-DGM.
• Session service (port 139) for session negotiation
between hosts. This is used for accessing files, opening
directories, and so on. Also referred to as NetBIOS-SSN.
IHRPv1 - Caendra Inc. © 2018 | p.86
2.2.1.1 NetBIOS

NBNS is the service that registers and translates names to

IP addresses. The Microsoft environment was implemented
with WINS, and as most networks did not use it, it was later
replaced by DNS. It works over UDP port 137.

IHRPv1 - Caendra Inc. © 2018 | p.87

2.2.1.1 NetBIOS

NBDS is used for service announcements by clients and

servers. With this service, devices on the network announce
their names, services that they can provide to other devices
on the network, and how to connect to these services. It
works over UDP port 138

IHRPv1 - Caendra Inc. © 2018 | p.88

2.2.1.1 NetBIOS

NBSS is used to establish sessions between hosts, open or

save files, and execute remote files and other sessions over
the network. It works over TCP port 139.

IHRPv1 - Caendra Inc. © 2018 | p.89

2.2.1.1 NetBIOS

There are additional protocols, such as Server Message

Block (SMB), that run over NBSS for transaction operations
and over NBDS for service announcement, spools for
printer requests, and several others.

IHRPv1 - Caendra Inc. © 2018 | p.90

2.2.1.2 SMB

SMB is a protocol that is used for browsing directories,

copying files, accessing services such as printers, and
several other operations over the network.

Common Internet File System (CIFS) is a form, or flavor, of

SMB.

IHRPv1 - Caendra Inc. © 2018 | p.91

2.2.1.2 SMB

SMB runs on top of the session layer protocols such as

NetBIOS as originally designed or can also run directly over
TCP port 445.

IHRPv1 - Caendra Inc. © 2018 | p.92

2.2.1.2 SMB

SMB 2.0 was introduced by Microsoft in 2006 in Windows

Vista, with the intention of reducing the commands and
subcommands required in the SMB 1.0 protocol.

Even though SMB 2.0 came out as a proprietary protocol,

Microsoft published the standard to allow other systems to
interoperate with their operating systems

IHRPv1 - Caendra Inc. © 2018 | p.93

2.2.1.2 SMB

SMB 2.1 was released with Windows 7 and Server 2008 R2

with performance improvements compared to SMB 2.0.

IHRPv1 - Caendra Inc. © 2018 | p.94

2.2.1.2 SMB

SMB 3.0 (earlier referred to as SMB 2.2) was introduced

with Windows 8 and Server 2012. SMM 3.0 has significant
performance improvements (compared to earlier releases)
in order to support virtualization occurring in the data
center computing environment.

IHRPv1 - Caendra Inc. © 2018 | p.95

 2.2.1.2 SMB

Detection
SMB works in a client-server model,
where the client makes specific
requests to the server, and based on
the requests, the server responds
accordingly. Most of the requests are
related to accessing filesystems, while
other forms of requests involve Inter-
Process Communication (IPC).
Code 0 means STATUS_OK, which
implies that everything works fine and
there is no problem. Any other code
should be examined. STATUS_ACCESS_DENIED SMB error example

IHRPv1 - Caendra Inc. © 2018 | p.96

 2.2.1.2 SMB

Detection
SMB works in a client-server model,
where the client makes specific
requests to the server, and based on
the requests, the server responds
accordingly. Most of the requests are
related to accessing filesystems, while
other forms of requests involve Inter-
Process Communication (IPC). SMB errors you should examine

Code 0 means STATUS_OK, which

implies that everything works fine and
there is no problem. Any other code
should be examined.
IHRPv1 - Caendra Inc. © 2018 | p.97
 2.2.1.2 SMB

Detection

Certain versions of Windows allowed for

anonymous and passwordless authentication.
Such a connection is often referred to as a NULL
session. A NULL session may be limited in terms
of privileges, but it could be used to execute
various RPC calls and subsequently perform
information gathering or user enumeration.

On your right, you see traffic generated by

Nmap’s smb-enum-users script. Notice the
successful attempt to identify if a NULL session
is possible. Also notice the RPC calls inside the
subsequent rectangles, that were run to provide
the attacker with a user list.

IHRPv1 - Caendra Inc. © 2018 | p.98

2.2.1.3 MSRPC

The RPC (Remote Procedure Call) mechanism allows an

application to seamlessly invoke remote procedures, as if
these procedures were executed locally.

There are two main implementations of the RPC

mechanism:
• ONC RPC
• DCE RPC
https://www.ietf.org/rfc/rfc1831.txt
http://pubs.opengroup.org/onlinepubs/9629399/
IHRPv1 - Caendra Inc. © 2018 | p.99
2.2.1.3 MSRPC

MSRPC is the Microsoft implementation of the DCE RPC

mechanism. In particular, Microsoft added new transport
protocols for DCE RPC, which use named pipes carried into
the SMB protocol.

File operations utilize SMB/CIFS, whereas administrative

operations, resource management operations etc. utilize
MSRPC.

IHRPv1 - Caendra Inc. © 2018 | p.100

2.2.1.3 MSRPC

There are multiple MSRPC implementations:

• RCP over SMB (this is an example RPC over SMB traffic)

The RPC Endpoint
• DCOM (RPC directly over TCP/UDP) [TCP/UDP port 135] Mapper comes into
play in those
• RPC over HTTP or HTTPS [TCP/UDP port 593] implementations

IHRPv1 - Caendra Inc. © 2018 | p.101

2.2.1.3.1 MSRPC Over TCP Session

There are multiple MSRPC implementations:

• RCP over SMB (this is an example RPC over SMB traffic)

The RPC Endpoint
• DCOM (RPC directly over TCP/UDP) [TCP/UDP port 135] Mapper comes into
play in those
• RPC over HTTP or HTTPS [TCP/UDP port 593] implementations

IHRPv1 - Caendra Inc. © 2018 | p.102

2.2.1.3.1 MSRPC Over TCP Session

TCP/IP RPC services listen on dynamic TCP or UDP ports.

Thus, to reach a given RPC service, identified by its
interface identifier (UUID), a port mapping service is
necessary.

The portmapper service is an RPC service listening on

different endpoints.

IHRPv1 - Caendra Inc. © 2018 | p.103

2.2.1.3.1 MSRPC Over TCP Session

Typically, to discover the port on which a given RPC service

can be reached, a client will establish a TCP connection to
port 135, asking for the port allocated to a given RPC
service.

Then, the client closes the connection to port 135 and

opens a new connection to the port returned by the
portmapper service.

IHRPv1 - Caendra Inc. © 2018 | p.104

2.2.1.3.1 MSRPC Over TCP Session

Consider the schannel_win7-member_to_win2k3-dc.pcap file

found in this module's resources, to see how the MSRPC
over TCP session implementation looks like on the wire.

Note: Study the pcap file from packet #129 onwards.

IHRPv1 - Caendra Inc. © 2018 | p.105

2.2.2 HTTP(S)

Everyday, we browse numerous websites. While doing so,

we are generating HTTP(S) traffic.

It is time we give the HTTP and HTTPS protocols a better

look…

IHRPv1 - Caendra Inc. © 2018 | p.106

2.2.2.1 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.

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

2.2.2.1 HTTP

Some facts to help distinguish normal and suspicious HTTP traffic

Normal HTTP Traffic Suspicious HTTP Traffic

Port 80, TCP Malicious binaries (backdoors), scripts,
Port 8080, TCP (used as alternate) web shells, etc. will use this port
Port 8088, TCP (used as alternate) because 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.

IHRPv1 - Caendra Inc. © 2018 | p.108

2.2.2.1 HTTP

Let’s now see how normal HTTP traffic looks like.

IHRPv1 - Caendra Inc. © 2018 | p.109

2.2.2.1 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).

IHRPv1 - Caendra Inc. © 2018 | p.110

2.2.2.1 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

IHRPv1 - Caendra Inc. © 2018 | p.111

2.2.2.1 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.

IHRPv1 - Caendra Inc. © 2018 | p.112

2.2.2.1 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. The http://IP format should alarm you, 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.

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.

IHRPv1 - Caendra Inc. © 2018 | p.113

2.2.2.1 HTTP

Within this packet we can do the same, jump back to packet 7 using the link
[Request in frame: 7].
IHRPv1 - Caendra Inc. © 2018 | p.114
2.2.2.1 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.

IHRPv1 - Caendra Inc. © 2018 | p.115

2.2.2.1 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. Let’s also look at the
packet stream after logging into the internal server to see credentials in cleartext.

IHRPv1 - Caendra Inc. © 2018 | p.116

2.2.2.1 HTTP

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

IHRPv1 - Caendra Inc. © 2018 | p.117

2.2.2.1 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.
IHRPv1 - Caendra Inc. © 2018 | p.118
2.2.2.1 HTTP

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

IHRPv1 - Caendra Inc. © 2018 | p.119

2.2.2.1 HTTP

2. Another way this can be done is by using a display filter and increment the number of
the TCP Stream. You will identify a non-valid TCP Stream by the non-visible packets.

IHRPv1 - Caendra Inc. © 2018 | p.120

2.2.2.1 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.

IHRPv1 - Caendra Inc. © 2018 | p.121

2.2.2.1 HTTP

4. At the bottom right we can see a

box, there 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.

IHRPv1 - Caendra Inc. © 2018 | p.122

2.2.2.1.1 Malicious HTTP Traffic Example

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.
Shared example with the THP course

IHRPv1 - Caendra Inc. © 2018 | p.123

 2.2.2.1.1 Malicious HTTP Traffic Example

Detection
Before we dive deeper, let’s take a moment to give the traffic capture
below a look and see if we can spot anything that might look odd.

Shared example with the THP course

IHRPv1 - Caendra Inc. © 2018 | p.124

 2.2.2.1.1 Malicious HTTP Traffic Example

Shared example with the THP course

Detection
There is one thing that stands out right away which is highlighted below.

• In the screenshot we can quickly see normal requests to 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 a SQL injection. Now was someone looking for a SQLi or did someone
make a typo in their web page request? Let’s go further down the capture file to find out.

https://www.acunetix.com/websitesecurity/sql-injection/
IHRPv1 - Caendra Inc. © 2018 | p.125
 2.2.2.1.1 Malicious HTTP Traffic Example

Detection
Glancing further at the capture file, a few packets down, we can see more indications of SQL injection
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 SQL injection on the server.

Shared example with the THP course

IHRPv1 - Caendra Inc. © 2018 | p.126

 2.2.2.1.1 Malicious HTTP Traffic Example

Detection

Now knowing that the individual is conducting SQL injection

queries against the server, is he/she doing this manually or
by using a tool?

Shared example with the THP course

IHRPv1 - Caendra Inc. © 2018 | p.127

 2.2.2.1.1 Malicious HTTP Traffic Example

Detection
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. User-Agent’s can be spoofed, but not
always, as we will see shortly.

Shared example with the THP course

IHRPv1 - Caendra Inc. © 2018 | p.128

 2.2.2.1.1 Malicious HTTP Traffic Example

Detection

We see that the User-

Agent is the same for
packets #31 and #44.

Let’s keep looking to see

if we can find anything
else of interest.

Shared example with the THP course

IHRPv1 - Caendra Inc. © 2018 | p.129

 2.2.2.1.1 Malicious HTTP Traffic Example

Detection

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 SQL injection
queries.

Shared example with the THP course

IHRPv1 - Caendra Inc. © 2018 | p.130

 2.2.2.1.1 Malicious HTTP Traffic Example

Detection
Strangely, packet #56, and the packet after that, packet #73, don’t seem to contain
any SQL injection queries. Maybe the individual decided not to continue the attack?

Shared example with the THP course

IHRPv1 - Caendra Inc. © 2018 | p.131

 2.2.2.1.1 Malicious HTTP Traffic Example

Detection
Let’s take a closer look at packet #56. Indeed no SQL injection attempt is visible within
this packet, but something else should have already alarmed us, the User-Agent. The
User-Agent for this HTTP GET Request is Sqlmap. So the attacker didn’t quit, he/she
escalated.

Shared example with the THP course

https://github.com/sqlmapproject/sqlmap IHRPv1 - Caendra Inc. © 2018 | p.132

 2.2.2.1.1 Malicious HTTP Traffic Example

Detection

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.

In addition, they will most probably contain overly long URI

requests.
Shared example with the THP course

IHRPv1 - Caendra Inc. © 2018 | p.133

2.2.2.2 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 study traffic captures of both normal and

suspicious HTTPS traffic.

IHRPv1 - Caendra Inc. © 2018 | p.134

2.2.2.2 HTTPS

A few things to remember about HTTPS:

• HTTPS is the secure version of HTTP.
o 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:
o Both the client and the server need to agree on the protocol version.
o Both the client and the server need to select cryptographic algorithms.
o Optionally authenticate to each other.
o Use public key encryption techniques to establish secure
communications.

IHRPv1 - Caendra Inc. © 2018 | p.135

2.2.2.2 HTTPS

Some facts to help distinguish normal and suspicious HTTPS traffic

Normal HTTPS Traffic Suspicious HTTPS Traffic
Port 443, TCP Malicious binaries (backdoors), scripts,
Port 8443, TCP (used as alternate) web 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.

IHRPv1 - Caendra Inc. © 2018 | p.136

2.2.2.2 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 and RFC 8446 for TLS 1.3.
https://tools.ietf.org/html/rfc6101
https://tools.ietf.org/html/rfc5246
https://datatracker.ietf.org/doc/rfc8446/ IHRPv1 - Caendra Inc. © 2018 | p.137
2.2.2.2 HTTPS

• When analyzing HTTPS traffic, we should see encrypted packets. All traffic on port 443 should look this way.

IHRPv1 - Caendra Inc. © 2018 | p.138

2.2.2.2 HTTPS

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

IHRPv1 - Caendra Inc. © 2018 | p.139

2.2.2.2 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)

IHRPv1 - Caendra Inc. © 2018 | p.140

2.2.2.2 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.

IHRPv1 - Caendra Inc. © 2018 | p.141

2.2.2.2 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.

IHRPv1 - Caendra Inc. © 2018 | p.142

2.2.2.2 HTTPS

This is the last packet and the

handshake between the server
and client is now complete.

The rest of the packets

between these two devices will
now be encrypted.

IHRPv1 - Caendra Inc. © 2018 | p.143

2.2.2.2 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.

IHRPv1 - Caendra Inc. © 2018 | p.144

2.2.2.2.1 Malicious HTTPS Traffic Example

Consider the SSL_renegotiation.pcap file found in this

module's resources. Can you spot any abnormalities?

Hint: Apply the following filter in Wireshark.

ssl.record.content_type == 22

IHRPv1 - Caendra Inc. © 2018 | p.145

 2.2.2.2 HTTPS

Detection

• When it comes to SSL/TLS handshakes, you should remember two things:

o Each SSL/TLS handshake is effectively a new connection (consuming resources)
o SSL/TLS handshakes are quite CPU intensive operations (server-side)
• The number of new Client Hello messages is abnormal.
• Taking into consideration both the above, it looks like we are dealing with a SSL Renegotiation Attack

https://blog.qualys.com/ssllabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks IHRPv1 - Caendra Inc. © 2018 | p.146

2.2.3 SMTP

SMTP (Simple Mail Transfer Protocol) is the internet's

Postman.

It's the protocol responsible for sending emails.

IHRPv1 - Caendra Inc. © 2018 | p.147

2.2.3 SMTP

When connecting to the SMTP server, the client has to

identify itself and authenticate through a password.

Before discussing SMTP, it is important to remember that

the protocol’s implementation may differ from one product
to another.

IHRPv1 - Caendra Inc. © 2018 | p.148

2.2.3 SMTP

SMTP is a text-based protocol, meaning that it relies on

exchanging ASCII based strings as commands between the
server and the client.
HELO Sent by a client to identify itself, usually with a domain
name.

MAIL FROM Identifies the sender of the message; used in the form
MAIL FROM:.

RCPT TO Identifies the message recipients; used in the form

RCPT TO:.

VRFY Verifies that a mailbox is available for message

delivery;.

IHRPv1 - Caendra Inc. © 2018 | p.149

2.2.3 SMTP

Later, in the 1995, ESMTP was

developed. ESMTP was an
extension to the original SMTP
protocol with some modifications.
Some of the modifications included
new commands such as using
EHLO instead of HELO for
identification.

On your right, you can see an

example of SMTP traffic.

IHRPv1 - Caendra Inc. © 2018 | p.150

2.2.3 SMTP

The SMTP server starts the conversation, once the TCP

three-way handshake is completed, by sending its banner,
containing the server’s name and version.

The above will look similar to the below on the wire.

IHRPv1 - Caendra Inc. © 2018 | p.151

2.2.3 SMTP

Back to our example, the client starts the conversation with

the EHLO command, which is the extended version of the
HELO command.

The server replies with the options that an SMTP client can
pick from.

Among these options is the authentication login option,

where the client asks for authentication to login.
IHRPv1 - Caendra Inc. © 2018 | p.152
2.2.3 SMTP

Next, we can see the server

asking the client for the
username. However, the word
username was encoded using
base 64 encoding.

We can verify that by

decoding the string which the
server sent to the client.

IHRPv1 - Caendra Inc. © 2018 | p.153

2.2.3 SMTP

The client responded to that

request by sending their
SMTP username encoded
using base 64 encoding.

IHRPv1 - Caendra Inc. © 2018 | p.154

2.2.3 SMTP

After receiving the username,

the server asks the client for
the password also in base 64
encoding.

IHRPv1 - Caendra Inc. © 2018 | p.155

2.2.3 SMTP

The client responded to that

request by sending the
password encoded in Base
64.

IHRPv1 - Caendra Inc. © 2018 | p.156

2.2.3 SMTP

Once both the username and the password is verified, the

server acknowledges that, by telling the client that they
have been "authenticated."

IHRPv1 - Caendra Inc. © 2018 | p.157

2.2.3 SMTP

Using the MAIL FROM and RCPT TO command, the client

tells the server that it wants to send an email.

After that, the mail body is specified using the DATA

command.

IHRPv1 - Caendra Inc. © 2018 | p.158

2.2.3 SMTP

We can see that the email header specifies the source,

recipient, subject and a message ID.

It also specifies the date and, more importantly, the user-

agent field, which tells what mail client was used to send
that email.

Finally, the type of content being sent is specified.

IHRPv1 - Caendra Inc. © 2018 | p.159

2.2.3 SMTP

It is important to mention that without the proper security

configuration, an attacker may be able to manually connect
to the SMTP server and send a forged email to a client
either on the local SMTP server or to another SMTP server.

In such a case the SMTP server will act as an open relay.

IHRPv1 - Caendra Inc. © 2018 | p.160

 2.2.3.1 Malicious SMTP Traffic Example

Detection
The lack of proper security
configuration may also allow the
attacker to connect to the SMTP
server and manually enumerate the
users on that server using the VRFY,
EXPN or RCPT TO commands.

User enumeration may be used as SMTP enumeration example via RCPT TO

part of a social engineering attack or
as a first step of a brute force attack
against account passwords on that
server.
IHRPv1 - Caendra Inc. © 2018 | p.161
2.2.4 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.

https://www.ietf.org/rfc/rfc1034.txt
https://www.ietf.org/rfc/rfc1035.txt
IHRPv1 - Caendra Inc. © 2018 | p.162
2.2.4 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.

IHRPv1 - Caendra Inc. © 2018 | p.163

2.2.4 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 A lot of DNS Queries with no DNS
Queries. responses or vice versa.

IHRPv1 - Caendra Inc. © 2018 | p.164

2.2.4 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.

https://technet.microsoft.com/en-us/library/dd197470(v=ws.10).aspx IHRPv1 - Caendra Inc. © 2018 | p.165

2.2.4 DNS

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

IHRPv1 - Caendra Inc. © 2018 | p.166

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

IHRPv1 - Caendra Inc. © 2018 | p.167

2.2.4 DNS

Here is another packet capture displaying various DNS

queries but you see the pattern of DNS Query followed by
DNS Response.

IHRPv1 - Caendra Inc. © 2018 | p.168

2.2.4.1 Malicious DNS Traffic Example

A good example of usually suspicious DNS traffic is DNS

Zone Transfers.

DNS zone transfers, are a way to replicate DNS databases

across a group of DNS servers.

Click to go back to slide 152 IHRPv1 - Caendra Inc. © 2018 | p.169

2.2.4.1 Malicious DNS Traffic Example

While DNS records are not sensitive individually, if an

attacker manages to obtain a copy of the entire DNS zone
for a domain (for example by means of an attacker-initiated
AXFR request), they may obtain a complete listing of all
hosts in that zone.

IHRPv1 - Caendra Inc. © 2018 | p.170

 2.2.4.1 Malicious DNS Traffic Example

Detection

Here we see 3 packets & all packets share one 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.
IHRPv1 - Caendra Inc. © 2018 | p.171
 2.2.4.1 Malicious DNS Traffic Example

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

This 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.

IHRPv1 - Caendra Inc. © 2018 | p.172

 2.2.4.1 Malicious DNS Traffic Example

Detection

Here we see details of packet

#61, which is the response to
the zone transfer.

IHRPv1 - Caendra Inc. © 2018 | p.173

2.2.4 DNS

There are other techniques in which DNS can be used for

nefarious purposes, such as DNS tunnels. We will cover
those later in the course.

IHRPv1 - Caendra Inc. © 2018 | p.174

 2.3

Effectively Using
Open Source IDS

IHRPv1 - Caendra Inc. © 2018 | p.175

2.3 Effectively Using Open Source IDS

Now that we have seen our fair share of packets on the

wire, it’s time to automate the detection of malicious traffic,
by using open source Intrusion Detection Systems.

Specifically, we will cover Snort, Bro & Suricata through a

serious of extensive, in-depth and hands-on labs.

IHRPv1 - Caendra Inc. © 2018 | p.176

2.3 Effectively Using Open Source IDS

During those labs, you will not only get familiar with their
detection capabilities, but you will also learn effective rule
writing and how to detect whole classes of attacks.

IHRPv1 - Caendra Inc. © 2018 | p.177

LAB: Suricata Fundamentals

Suricata Fundamentals
In this lab, you will learn about Suricata's
capabilities, features and configuration. In
addition, you will get familiar with
configuring Suricata, according to your
detection needs and, at the same time, you
will learn all about Suricata Inputs and
Outputs. Finally, you will be shown, how to
effectively parse Suricata output and how to
extract critical information out of it.

*To access, go to the course in your members area and click the lab drop-down in the appropriate module line to access a lab, or go to the
virtual labs tab on the left navigation.
IHRPv1 - Caendra Inc. © 2018 | p.178
LAB: Effectively Using
Suricata

Effectively Using Suricata

In this lab, you will learn how to effectively
use Suricata. Specifically, you will first get
familiar with Suricata rules, and then, you will
learn how to develop your own signatures
after analyzing PCAP files containing
malicious traffic. Suricata rules will be
written to detect malicious traffic deriving
from Ransomware, Phishing Attempts,
Trojans and Malicious Documents.

*To access, go to the course in your members area and click the lab drop-down in the appropriate module line to access a lab, or go to the
virtual labs tab on the left navigation.
IHRPv1 - Caendra Inc. © 2018 | p.179
LAB: Effectively Using Bro

Effectively Using Bro

In this lab, you will learn about Bro's
capabilities, features, and architecture.
Additionally, you will get familiar with
effective Bro scripting, so that you can
make Bro suit your detection needs.
Finally, you will be shown effective
manipulation and analysis of Bro logs to
extract critical information out of them.

*To access, go to the course in your members area and click the lab drop-down in the appropriate module line to access a lab, or go to the
virtual labs tab on the left navigation.
IHRPv1 - Caendra Inc. © 2018 | p.180
LAB: Effectively Using
Snort

Effectively Using Snort

In this lab, you will learn about
Snort's capabilities, features,
and architecture. Additionally,
you will get familiar with
effective Snort rule scripting,
so that you can make Snort
suit your detection needs.

*To access, go to the course in your members area and click the lab drop-down in the appropriate module line to access a lab, or go to the
virtual labs tab on the left navigation.
IHRPv1 - Caendra Inc. © 2018 | p.181
References

IHRPv1 - Caendra Inc. © 2018 | p.182

 References
TCP protocol
https://tools.ietf.org/html/rfc793

Online Wireshark Wiki

https://wiki.wireshark.org/TCP_Relative_Sequence_Numbers

OS fingerprinting
https://nmap.org/book/osdetect-methods.html#osdetect-gcd

Slipping in the Window: TCP Reset attacks

https://packetstormsecurity.com/files/download/33170/SlippingInTheWindow_v1.0.doc

IHRPv1 - Caendra Inc. © 2018 | p.183

 References
TCP Timestamps option
https://tools.ietf.org/html/rfc1323

Remote Physical Device Fingerprinting

http://www.caida.org/publications/papers/2005/fingerprinting/KohnoBroidoClaffy05-
devicefingerprinting.pdf

Misusing TCP Timestamps

https://www.scip.ch/en/?labs.20150305

Remote OS detection via TCP/IP Stack FingerPrinting

https://nmap.org/nmap-fingerprinting-article.txt

IHRPv1 - Caendra Inc. © 2018 | p.184

 References
ICMP Usage in Scanning
https://www.cs.dartmouth.edu/~sergey/me/netreads/ICMP_Scanning_v3.0.pdf

Ptunnel
http://freshmeat.sourceforge.net/projects/ptunnel/

ONC RPC
https://www.ietf.org/rfc/rfc1831.txt

DCE RPC
http://pubs.opengroup.org/onlinepubs/9629399/

IHRPv1 - Caendra Inc. © 2018 | p.185

 References
RFC 2616
https://www.ietf.org/rfc/rfc2616.txt

SQL injection
https://www.acunetix.com/websitesecurity/sql-injection/

Sqlmap
https://github.com/sqlmapproject/sqlmap

RFC 6101
https://tools.ietf.org/html/rfc6101

IHRPv1 - Caendra Inc. © 2018 | p.186

 References
RFC 5246
https://tools.ietf.org/html/rfc5246

RFC 8446
https://datatracker.ietf.org/doc/rfc8446/

SSL Renegotiation Attack

https://blog.qualys.com/ssllabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks

Domain names - concepts and facilities

https://www.ietf.org/rfc/rfc1034.txt

IHRPv1 - Caendra Inc. © 2018 | p.187

 References
Domain names - implementation and specification
https://www.ietf.org/rfc/rfc1035.txt

Transaction IDs
https://technet.microsoft.com/en-us/library/dd197470(v=ws.10).aspx

IHRPv1 - Caendra Inc. © 2018 | p.188

 Labs
Suricata Fundamentals
In this lab, you will learn about Suricata's capabilities, features and configuration. In
addition, you will get familiar with configuring Suricata, according to your detection needs
and, at the same time, you will learn all about Suricata Inputs and Outputs. Finally, you will
be shown, how to effectively parse Suricata output and how to extract critical information
out of it.

Effectively Using Suricata

In this lab, you will learn how to effectively use Suricata. Specifically, you will first get
familiar with Suricata rules, and then, you will learn how to develop your own signatures
after analyzing PCAP files containing malicious traffic. Suricata rules will be written to
detect malicious traffic deriving from Ransomware, Phishing Attempts, Trojans and
Malicious Documents.

*To access, go to the course in your members area and click the lab drop-down in the appropriate module line to access a lab, or go to the
virtual labs tab on the left navigation.

IHRPv1 - Caendra Inc. © 2018 | p.189

 Labs
Effectively Using Bro
In this lab, you will learn about Bro's capabilities, features, and architecture.
Additionally, you will get familiar with effective Bro scripting, so that you can make
Bro suit your detection needs. Finally, you will be shown effective manipulation and
analysis of Bro logs to extract critical information out of them.

Effectively Using Snort

In this lab, you will learn about Snort's capabilities, features, and architecture.
Additionally, you will get familiar with effective Snort rule scripting, so that you can
make Snort suit your detection needs.

*To access, go to the course in your members area and click the lab drop-down in the appropriate module line to access a lab, or go to the
virtual labs tab on the left navigation.

IHRPv1 - Caendra Inc. © 2018 | p.190