To make our task of editing code and inspecting packets easier, we will use the VM to write code and then move the code into the ./volumes folder on the host machine (the VM).

This folder is shared between the VM and the attacker container. When we fire up the attacker container, and docksh into the attacker container, we can move the code from ./volumes into the appropriate directories (like we did in previous labs).

The attacker container has been setup to sniff packets on all the host’s network interfaces (i.e., it lives in the same network namespace as the host VM).

Wireshark is performing the task of parsing those bytes, and displaying the header and payload information of the packet at each layer of the protocol stack.

The Main Window: The Main Window in wireshark, is home to The Packet List Pane which shows the list of captured packets, in our case, packets from the PCAP file.

Packet Details Pane: Next, below that we have the Packet Details Pane, which shows the details of the currently selected packet. You can click on different packets in this PCAP file to inspect each packet.

The Packet Bytes Pane: In the final pane at the bottom, is the Packet Bytes Pane, that shows the hexdump of the packet. I.e., the bytes of the entrie packet represented in hexadecimal.

Below are hints to get started with each of the PCAP files for the Warm-Up and Adventures A-C.

Which IP address received the most packets?

Which IP address sent the fewest packets?

Which IP address sent the most bytes?

In this PCAP file, you will see packets marked with different coloring rules. Take a look at Wireshark’s rules to indicate various properties of a packet. Which colors do you see most often?

For this adventure we want to investigate the PCAP file to find an attacker trying to send data out. Since the data is usually the payload section of the packet, this is the region of the packet we care about.

An additional hint we have here is that the attacker is using a protocol that is not TCP and it is not UDP. You can setup Display Filter Rules, to specify that we don’t want to view specific packets. Here are some examples.

Take a look at the following references for ICMP here and here, a network diagnostic protocol and OSPF, a network routing protocol.

Try investigating which application this maps to, before applying your display filters.

Next, you mgiht want to sort the responses by length, and identify any patterns you observe.

Next, you can filter on the pattern, and sort the messgea by time and find an 8 character password embedded in the payload.

Once you find the data exfiltration payload (everything before code.zip), you can use CyberChef to decode it.

In your VM cd into the lab folder lab5, and start up the docker container as follows:

seed@VM:~/.../lab5$ dcup
Creating network "net-10.9.0.0" with the default driver
Creating seed-attacker  ... done
Creating hostA-10.9.0.5 ... done
Creating hostB-10.9.0.6 ... done
Attaching to seed-attacker, hostB-10.9.0.6, hostA-10.9.0.5
hostB-10.9.0.6 |  * Starting internet superserver inetd                  [ OK ]
hostA-10.9.0.5 |  * Starting internet superserver inetd                  [ OK ]

Let’s now look at the list of networked devices that are running:

lab5$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
6a695e3c95c3        bridge              bridge              local
b3581338a28d        host                host                local
0dd5ef8e67b1        net-10.9.0.0        bridge              local
77acecccbe26        none                null                local

To establish this connection, the application layer message, relies on a transport layer protocol - either TCP (reliable delivery) or UDP (unreliable delivery). In this section of the lab, we will write a simple UDP client-server program.

To start a UDP connection, we associate the client with a socket. You can think of a socket as a construct offered by the O.S. that functions like a mailbox used to send and receive mail.

To traverse the Internet stack we have in the figure above, as the user interacting with the application layer service, we need to specify the following elements of our packet to the O.S. socket.

As an example, let’s build the same UDP packet we built in our hello_world_client.py using Scapy. This time we will construct the packet "from scratch".

We will spoof ICMP echo request packets and send them to another VM on the same network. We will use Wireshark to observe whether our request will be accepted by the receiver. Read up on ICMP packets in the Handy References section.

If it is accepted, an echo reply packet will be sent to the spoofed IP address. Here’s an example of how you might set this up in Scapy:

$ sudo python3
>>> from scapy.all import *
>>> a = IP()
>>> a.dst = '1.2.3.4'
>>> b = ICMP()          # create an ICMP echo request
>>> pkt = a/b
>>> send(pkt)
.
Sent 1 packet

If we now run ls(a) we should see the following:

>>> ls(a)
version    : BitField (4 bits)   = 4                 (4)
ihl        : BitField (4 bits)   = None              (None)
tos        : XByteField          = 0                 (0)
len        : ShortField          = None              (None)
id         : ShortField          = 1                 (1)
flags      : FlagsField (3 bits)  = <Flag 0 ()>      (<Flag 0 ()>)
frag       : BitField (13 bits)   = 0                (0)
ttl        : ByteField            = 64               (64)
proto      : ByteEnumField        = 0                (0)
chksum     : XShortField          = None             (None)
src        : SourceIPField        = ’127.0.0.1’      (None)
dst        : DestIPField             = ’127.0.0.1’     (None)
options    : PacketListField         = []              ([])

You need two machines on the same LAN: the attacker and one of the host docker containers. From the host docker container, you ping IP X. This will generate an ICMP echo request packet. If X is a valid end-host, the ping program will receive an echo reply, and print out the response.

Your sniff_spoof_icmp.py code runs on the attacker container, which monitors the LAN through packet sniffing. Whenever it sees an ICMP echo request, regardless of what the target IP address is, your program should immediately send out an echo reply with a spoofed packet.

Therefore, regardless of whether machine X is valid or not, the ping program will always receive a reply, indicating that X is valid.

To test your program, you should ping the following two IP addresses from the user container.

ping 1.2.3.4     # a non-existing host on the Internet
ping 8.8.8.8     # an existing host on the Internet