We should be able to follow this output as it is not protected by TLS, and recover the TLS session keys.įrom the ( ), we know the `sslkeylogfile` follows a format of ` `. This basically tells Wireshark to treat all traffic on TCP port 1080 as TLS, and not as Socks.Įarlier, when we did `strings` on the `log.pcap` file, we noticed that the attacker ran `xargs -n1 -a sslkeylogfile` on the victim's system, which would effectively print the contents of `sslkeylogfile` to the output stream. To combat this and allow Wireshark to read the traffic properly as TLS, we can add an entry to the "Decode As" list under the "Analyze" tab, pointing port 1080 to TLS: This is likely because the attacker used a Socks proxy when attacking our victim. Opening `log_chopped.pcap` file in Wireshark, we see the ICMP packets have now changed into either TCP or Socks packets, the source/destination address and ports have also changed. `$ editcap -C 15:33 log_ordered.pcap log_chopped.pcap` Using the `editcap` tool and following the documentation ( ), we cut away 33 bytes (20 bytes from TCP header of ICMP + 13 bytes from Hans) starting from offset byte 15 (after 14 bytes from Ethernet header of ICMP) for each packet, then export the packets into a `log_chopped.pcap` file: In fact, we can simplify it to only one cut operation by removing the TCP header and the Hans header altogether. This can be achieved by transplanting the Ethernet header from the ICMP packet to the ICMP data segment, and removing the magic/type header inserted by Hans. If we can somehow restore the original TLS packets, then there is a possibility where we can extract the session keys and use them to decrypt the rest of the packets. We know the TCP data inside of the ICMP data has to contain the TLS traffic which the attacker used to exfiltrate data, or the handshakes associated with them. We can also see the `0x07` byte at the end, which is defined as `TYPE_DATA` in the source code under `src/worker.h`: This header is inserted by the Hans application. Searching for the bytes in the malformed Ethernet header `00 00 4a e3 f9 24 34 44 68 61 6e 73 07`, we were able to determine the specific application used to establish the ICMP tunnel, called "Hans" (( )). But, if we look carefully, we can see there is a malformed Ethernet header, followed by an IP header, and then a TCP header: Looking at one of the fragmented IPv4 packets, we see that there is a data segment with 1480 bytes of data:Īt first, the data may look like random bytes. With the ordering fixed, we can then start analysing the individual packets. If the reordering was successful, there should be 167 fragmented IPv4 packets with size of 1514 bytes in the newly created `log_ordered.pcap` file. We can fix the packet ordering issue using the `reordercap` tool, which should come installed with Wireshark: Also, the frame numbers are all over the place and are not ordered correctly. This should not be possible, packets cannot travel back in time before the capture started. Looking at Wireshark, we notice some of the packets have negative time values. From the second hint, we also know that the capture logs were imprecise and the packet timestamps were unusual. From the first hint, we know that the attacker used an IP over ICMP tunnel network to access an HTTP/2 web server with SSL.Ģ. Opening the packet capture file `log.pcap` in Wireshark, we see a conversation between `192.168.1.30` and `192.168.1.205` through ICMP (ping), along with some fragmented IPv4 packets.ġ. We see mentions of files `flag.zip`, `pass.txt`, ` download.py`, and `sslkeylogfile`, as well as commands such as `id`, `python3` and `xargs` being run. P7zip Version 16.02 (locale=C.UTF-8,Utf16=on,HugeFiles=on,32 bits,1 CPU LE) `$ strings log.pcap | sort | uniq | grep. ` to display only lines with length greater or equal to 6: Running `strings` against the `.pcap` file, we pipe the output to `sort` and `uniq` to only display unique entries, then `grep. We are provided with a `` archive from the challenge description, which we can decompress using `xz` and `tar` as so: Each packet has an unusual timestamp and it's kinda messy." Hint #2: "Even so, our captured logs aren't precise enough. Hint #1: "When the incident happened, the attacker got into our `IP over ICMP` tunnel network to access an `HTTP/2` web-server with `SSL` enabled." There's an indication that the robber tried to steal some items which are considered as confidential assets. A robber broke into our vault in the middle of night.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |