One day network administrator discovers unknown device in his office network.
He was able to capture network traffic between unknown device and public IP.
He discovered that unknown device is using secure and insecure communication protocols.
Can you help your network administrator investigate network traffic on a suspicious device,
and discover the flag from insecure communication??
unknown-device.pcap
In the network capture file unknown-device.pcap there are two Virtual Private Network sessions.
One session is IPSec, judging by ISAKMP and ESP packets, and the other session is Point-to-Point Tunneling Protocol (PPTP), judging by PPTP and GRE PPP packets.
IPSec traffic can't be decrypted without encryption key, as written in many resources - WireShark: ESP Payload Decryption, Fortinet: Decrypt ESP packets, Sophos UTM: How to capture and decrypt ESP traffic - and key is nowhere to be found.
So ignore the IPSec traffic.
PPTP, on the other hand, have many security vulnerabilities and the traffic most probably can be decrypted. That is where the attention should be.
As PPTP uses GRE tunnel, to work only with this traffic, it can be filtered as "pptp or gre" in WireShark or tshark.
There are two PPTP sessions, but the first one doesn't contain any traffic (only authentication), therefore only second session needs to be analyzed.
$ tshark -r unknown-device.pcap -Y 'pptp or gre and frame.number>100'
113 27.544442 192.168.11.1 → 100.100.100.1 PPTP 222 Start-Control-Connection-Request
115 27.545398 100.100.100.1 → 192.168.11.1 PPTP 222 Start-Control-Connection-Reply
117 27.545990 192.168.11.1 → 100.100.100.1 PPTP 234 Outgoing-Call-Request
118 27.546530 100.100.100.1 → 192.168.11.1 PPTP 98 Outgoing-Call-Reply
119 27.547224 192.168.11.1 → 100.100.100.1 PPP LCP 64 Configuration Request
120 27.547707 100.100.100.1 → 192.168.11.1 PPP LCP 73 Configuration Request
121 27.547959 100.100.100.1 → 192.168.11.1 PPP LCP 68 Configuration Ack
122 27.548218 192.168.11.1 → 100.100.100.1 PPP LCP 73 Configuration Ack
123 27.548649 100.100.100.1 → 192.168.11.1 PPP CHAP 89 Challenge (NAME='Unknown device', VALUE=0x41918206e33288b988722fb957328acc)
124 27.549286 192.168.11.1 → 100.100.100.1 PPP CHAP 116 Response (NAME='catch-me', VALUE=0x96000cdbb6c254c4ea99a991b148b34e0000000000000000eeec9d8a2c9678bf641727ff…)
125 27.551628 100.100.100.1 → 192.168.11.1 PPP CHAP 100 Success (MESSAGE='S=AF810E6E0F81F6622DBD3F5E972B086C56A5B210')
126 27.551924 100.100.100.1 → 192.168.11.1 PPP IPCP 64 Configuration Request
127 27.552258 100.100.100.1 → 192.168.11.1 PPP MPLSCP 60 Configuration Request
128 27.552316 192.168.11.1 → 100.100.100.1 PPP IPCP 64 Configuration Request
129 27.552350 192.168.11.1 → 100.100.100.1 PPP MPLSCP 58 Configuration Request
130 27.552604 192.168.11.1 → 100.100.100.1 PPP CCP 64 Configuration Request
131 27.552663 192.168.11.1 → 100.100.100.1 PPP IPCP 64 Configuration Ack
132 27.552720 100.100.100.1 → 192.168.11.1 PPP CCP 64 Configuration Request
133 27.552982 192.168.11.1 → 100.100.100.1 PPP MPLSCP 58 Configuration Ack
134 27.553174 192.168.11.1 → 100.100.100.1 PPP CCP 64 Configuration Ack
135 27.553459 100.100.100.1 → 192.168.11.1 PPP IPCP 64 Configuration Nak
136 27.553812 192.168.11.1 → 100.100.100.1 PPP IPCP 64 Configuration Request
137 27.553863 100.100.100.1 → 192.168.11.1 PPP MPLSCP 60 Configuration Ack
138 27.554035 100.100.100.1 → 192.168.11.1 PPP CCP 64 Configuration Ack
139 27.555576 100.100.100.1 → 192.168.11.1 PPP IPCP 64 Configuration Ack
153 35.148867 192.168.11.1 → 100.100.100.1 PPP Comp 112 Compressed data
154 35.148923 192.168.11.1 → 100.100.100.1 PPP Comp 112 Compressed data
155 35.155863 100.100.100.1 → 192.168.11.1 PPP Comp 112 Compressed data
156 35.244078 100.100.100.1 → 192.168.11.1 PPP Comp 128 Compressed data
157 35.245409 192.168.11.1 → 100.100.100.1 PPP Comp 142 Compressed data
158 35.287797 100.100.100.1 → 192.168.11.1 PPP Comp 142 Compressed data
159 35.288739 192.168.11.1 → 100.100.100.1 PPP Comp 131 Compressed data
160 35.292911 100.100.100.1 → 192.168.11.1 PPP Comp 171 Compressed data
161 35.390451 192.168.11.1 → 100.100.100.1 GRE 46 Encapsulated PPP
162 36.247132 192.168.11.1 → 100.100.100.1 PPP Comp 142 Compressed data
163 36.289341 100.100.100.1 → 192.168.11.1 PPP Comp 142 Compressed data
164 36.380672 192.168.11.1 → 100.100.100.1 GRE 46 Encapsulated PPP
167 37.248665 192.168.11.1 → 100.100.100.1 PPP Comp 142 Compressed data
168 37.291073 100.100.100.1 → 192.168.11.1 PPP Comp 142 Compressed data
169 37.390589 192.168.11.1 → 100.100.100.1 GRE 46 Encapsulated PPP
170 38.250552 192.168.11.1 → 100.100.100.1 PPP Comp 142 Compressed data
171 38.292770 100.100.100.1 → 192.168.11.1 PPP Comp 142 Compressed data
172 38.390487 192.168.11.1 → 100.100.100.1 GRE 46 Encapsulated PPP
183 39.251686 192.168.11.1 → 100.100.100.1 PPP Comp 142 Compressed data
184 39.293801 100.100.100.1 → 192.168.11.1 PPP Comp 142 Compressed data
185 39.390011 192.168.11.1 → 100.100.100.1 GRE 46 Encapsulated PPP
189 40.253043 192.168.11.1 → 100.100.100.1 PPP Comp 142 Compressed data
190 40.295339 100.100.100.1 → 192.168.11.1 PPP Comp 142 Compressed data
191 40.390480 192.168.11.1 → 100.100.100.1 GRE 46 Encapsulated PPP
229 49.283922 192.168.11.1 → 100.100.100.1 PPP Comp 118 Compressed data
230 49.285581 100.100.100.1 → 192.168.11.1 PPP Comp 118 Compressed data
231 49.286659 192.168.11.1 → 100.100.100.1 PPP Comp 110 Compressed data
232 49.286756 192.168.11.1 → 100.100.100.1 PPP Comp 196 Compressed data
233 49.287679 100.100.100.1 → 192.168.11.1 PPP Comp 110 Compressed data
234 49.288855 100.100.100.1 → 192.168.11.1 PPP Comp 295 Compressed data
235 49.289020 100.100.100.1 → 192.168.11.1 PPP Comp 152 Compressed data
236 49.289636 192.168.11.1 → 100.100.100.1 PPP Comp 110 Compressed data
237 49.289804 192.168.11.1 → 100.100.100.1 PPP Comp 110 Compressed data
238 49.290496 100.100.100.1 → 192.168.11.1 PPP Comp 110 Compressed data
239 49.390106 192.168.11.1 → 100.100.100.1 GRE 46 Encapsulated PPP
260 57.242663 192.168.11.1 → 100.100.100.1 PPP LCP 79 Termination Request
261 57.243086 100.100.100.1 → 192.168.11.1 PPP LCP 60 Termination AckLet's deep-dive into protocol.
Encapsulated Point-to-Point Protocol (PPP) is described in rfc1661.
Essentially, a PPP frame contains Protocol, data for that specific protocol and padding. List of unique PPP protocols used.
$ tshark -r unknown-device.pcap -Y 'pptp or gre and frame.number>100 and ppp' -T fields -e ppp.protocol | sort -u | paste -s -d',' -
253,32801,33021,33409,49185,49699Up-to-date Point-to-Point (PPP) Protocol Field Assignments lists each protocol, and its documentation.
| 253 | 0x00fd | PPP Comp | Compressed datagram | rfc1962 |
| 32801 | 0x8021 | PPP IPCP | Internet Protocol Control Protocol | rfc1332 |
| 33021 | 0x80fd | PPP CCP | Compression Control Protocol | rfc1962 |
| 33409 | 0x8281 | PPP MPLSCP | Multi-Protocol Label Switching Control Protocol | rfc3032 |
| 49185 | 0xc021 | PPP LCP | Link Control Protocol | rfc1661 |
| 49699 | 0xc223 | PPP CHAP | Challenge-Handshake Authentication Protocol | rfc1994 |
Point-to-Point authentication phase (rfc1661#3.5) "MUST request the use of that authentication protocol during Link Establishment phase (rfc1661#3.4)", which uses LCP configuration options (rfc1661#6) to configure authentication with Authentication-Protocol option (rfc1661#6.2).
It describes two authentication protocols - Password Authentication Protocol (PAP) with value 0xc023 (49187) and Challenge-Handshake Authentication Protocol (CHAP) with value 0xc223 (49699).
Though, tshark has nicely decoded that this session is using CHAP, check it manually. Verified, 49699 or 0xc223 is CHAP.
$ tshark -r unknown-device.pcap -Y 'pptp or gre and frame.number>100 and lcp.opt.auth_protocol' -T fields -e lcp.opt.auth_protocol | uniq
49699
There are only few packets for CHAP, which contain challenge, response and success.
$ tshark -r unknown-device.pcap -Y 'pptp or gre and frame.number>100 and chap'
123 27.548649 100.100.100.1 → 192.168.11.1 PPP CHAP 89 Challenge (NAME='Unknown device', VALUE=0x41918206e33288b988722fb957328acc)
124 27.549286 192.168.11.1 → 100.100.100.1 PPP CHAP 116 Response (NAME='catch-me', VALUE=0x96000cdbb6c254c4ea99a991b148b34e0000000000000000eeec9d8a2c9678bf641727ff…)
125 27.551628 100.100.100.1 → 192.168.11.1 PPP CHAP 100 Success (MESSAGE='S=AF810E6E0F81F6622DBD3F5E972B086C56A5B210')
CHAP describes that LCP Authentication-Protocol configuration option (rfc1994#3) should also define what algorithm to use, though it only describes md5 algorithm with value 5.
Checking with tshark what algorithm is defined, the value is 129.
$ tshark -r unknown-device.pcap -Y 'pptp or gre and frame.number>100 and lcp.opt.algorithm' -T fields -e lcp.opt.algorithm | uniq
129
Updated list of PPP Authentication Algorithms describes value 129 as MS-CHAP-2.
It is Microsoft PPP CHAP version 2 (MS-CHAPv2), described in rfc2759.
It describes the challenge packet (rfc2759#3) and response packet (rfc2759#4).
Before going further, retrieve the challenge and response packet value with tshark.
$ tshark -r unknown-device.pcap -Y 'pptp or gre and frame.number>100 and chap.name' -T fields -e chap.name -e chap.value
Unknown device 41918206e33288b988722fb957328acc
catch-me 96000cdbb6c254c4ea99a991b148b34e0000000000000000eeec9d8a2c9678bf641727ff5ff776331575f42916215cd100
Challenge packet's value (Authenticator-Challenge) is just 16 random bytes, in this case 41918206e33288b988722fb957328acc.
Response packet's (rfc2759#4) value has format: Peer-Challenge (16 random bytes), reserved (8 zero bytes), NT-Response (24 bytes) and reserved flags (1 zero byte).
Therefore, the Peer-Challenge is 96000cdbb6c254c4ea99a991b148b34e and NT-Response is eeec9d8a2c9678bf641727ff5ff776331575f42916215cd1.
John The Ripper john can crack MS-CHAPv2. Format is described in MSCHAPv2_bsd_fmt_plug.c:
* USERNAME:::AUTHENTICATOR CHALLENGE:MSCHAPv2 RESPONSE:PEER CHALLENGE
* USERNAME::DOMAIN:AUTHENTICATOR CHALLENGE:MSCHAPv2 RESPONSE:PEER CHALLENGE
* DOMAIN\USERNAME:::AUTHENTICATOR CHALLENGE:MSCHAPv2 RESPONSE:PEER CHALLENGE
* :::MSCHAPv2 CHALLENGE:MSCHAPv2 RESPONSE:
Crack the hash with john. Password is !2moondreamer2!.
$ echo 'catch-me:::41918206e33288b988722fb957328acc:eeec9d8a2c9678bf641727ff5ff776331575f42916215cd1:96000cdbb6c254c4ea99a991b148b34e' > vpn.hash
$ john --format=mschapv2 --wordlist=/usr/share/seclists/Passwords/Leaked-Databases/rockyou.txt vpn.hash
Loaded 1 password hash (MSCHAPv2, C/R [MD4 DES (ESS MD5) 32/64])
!2moondreamer2! (catch-me)
Data is transmitted in Compressed datagram (Comp) (rfc1962#2.1).
Data compression is configured by Compression Control Protocol (CCP) (rfc1962#2) configuration options (rfc1962#4).
$ tshark -r unknown-device.pcap -Y 'pptp or gre and frame.number>100 and ccp' -T fields -e ccp.opt.type | uniq
18
Value 18 corresponds to Microsoft Point-to-Point Compression (MPPC), described in rfc2118, and Microsoft Point-to-Point Encryption (MPPC), described in rfc3078 and rfc3079.
Compression Control Protocol (CCP) configuration option (rfc3078#2) describes Supported Bits, which defines use of stateless mode, encryption strength (40/56/128-bit) and desire for compression.
$ tshark -r unknown-device.pcap -Y 'pptp or gre and frame.number>100 and ccp' -T fields -e ccp.opt.supported_bits | uniq
0x01000040
Value 0x01000040 corresponds to stateless mode, 128-bit encryption and no compression.
Extract compressed datagram, and source/destination IPs.
$ tshark -r unknown-device.pcap -Y 'pptp or gre and frame.number>100 and comp_data' -T json -x | jq -r '.[]._source.layers | [ .ip."ip.src", .ip."ip.dst", .comp_data_raw[0] ] | @tsv ' | tee comp.dat
192.168.11.1 100.100.100.1 9000e9dd640f04e8720a47521c753a18d157bfd3642b8ad19731860031931bd806d3d4286ef8012144561d5545ee87fae5d9e2c2f943261bdc90
192.168.11.1 100.100.100.1 9001d3136dc3c9b1665301fadb4d2e498d29504af91b4a8fcf137b6f761e620bec53914dd363a2515b9d9e5b4af40e530a12658d739ca3a5e295
100.100.100.1 192.168.11.1 9000a0465d5db0a9676a9d22e809e0f2f0ee6164d23be2a67652a89c3602280d285d2cde681de0ef989768f1f09a55d9c188ba2ebbd331f8a146
(..)First two bytes contain encryption flags and counter (rfc3078#3.1). The rest of the data is encrypted.
To generate 128-bit session keys (rfc3078#3.3), multiple keys have to be generated.
There are some predefined constants (rfc3078#3.4): Magic1 ("This is the MPPE Master Key"), Magic2 is "On the client side, this is the send key; on the server side, it is the receive key.",
Magic3 is "On the client side, this is the receive key; on the server side, it is the send key.", SHAPad1 (40 bytes of 0x00) and SHSPad2 (40 bytes of 0xf2).
Master-Key is 128 bits of sha1 of PasswordHashHash (md4 of user's NTLM) + NT-Response + Magic1.
User's NTLM (of password !2moondreamer2!) is 1cc7d2e3eabfb61a45b540bcd02a24ae. Master-Key is 2718d849fa9ba805f408ef04f82ed6cc8c2b45f5.
Client/Server Master-Key is 128 bits of sha1 of Master-Key + SHSPad1 + (Magic2 for client, Magic3 for server) + SHSPad2.
Client-Master-Key is ec80aaf4ba5b8d46c4025ea6682758ad, Server-Master-Key is aaa1c740e48c54dc8fd4a8fe35c437bc.
Client/Server Session-Key is 128 bits of sha1 of Client/Server-Master-Key + SHSPad1 + (previous Session-Key or, if none, then Master-Key) + SHSPad2.
Initial Client-Session-Key is db6c1babb42d033fbd51455bd08e8229, Initial Server-Session-Key is 11c9ecd640e130f2f539ae66b893d9cb.
Finally, set RC4-Key for Client and Server, using their respective session keys.
RC4 keys must be rotated. In stateless mode it basically means for every packet (when counter changes), in stateful mode it's rarer, every 255 packets. The key change algorithm (rfc3078#3.3) is as follows: recreate Session-Key, using Master-Key and previous Session-Key. Set RC4-Key to Session-Key. Encrypt Session-Key with RC4-Key. Set RC4-Key to Session-Key.
Data is decrypted with respective RC4-Key. If first two bytes of decrypted data is 0x0021, then it is an IP packet.
That is all what's required for decryption. Create a script ppp-decrypt.py, which implements decryption and outputs IP packets in hex.
#!/usr/bin/env python3
import sys, io, binascii, hashlib
from rc4 import RC4
MAGIC1 = b'This is the MPPE Master Key'
MAGIC2 = b'On the client side, this is the send key; on the server side, it is the receive key.'
MAGIC3 = b'On the client side, this is the receive key; on the server side, it is the send key.'
SHSPAD1 = b'\x00'*40
SHSPAD2 = b'\xf2'*40
PASSWORD = '!2moondreamer2!'
NT_RESPONSE = binascii.unhexlify('eeec9d8a2c9678bf641727ff5ff776331575f42916215cd1')
def get_key(mk, ck, klen):
return hashlib.new('sha1', mk[:klen] + SHSPAD1 + ck + SHSPAD2).digest()[:klen]
ntlm = hashlib.new('md4', PASSWORD.encode('utf-16le')).digest()
mkey = hashlib.new('sha1', hashlib.new('md4', ntlm).digest() + NT_RESPONSE + MAGIC1).digest()[:16]
ppp = {'cli': {'c': -1, 'ip': None}, 'srv': {'c': -1, 'ip': None}}
ppp['cli']['mkey'] = get_key(mkey, MAGIC2, 16)
ppp['srv']['mkey'] = get_key(mkey, MAGIC3, 16)
ppp['cli']['skey'] = get_key(ppp['cli']['mkey'], ppp['cli']['mkey'][:16], 16)
ppp['srv']['skey'] = get_key(ppp['srv']['mkey'], ppp['srv']['mkey'][:16], 16)
ts = 0
with io.open('comp.dat', 'rb') as fp:
for rline in fp:
rline = rline.strip().split(b'\t')
ip_src, ip_dst = rline[0], rline[1]
data = binascii.unhexlify(rline[2].decode('utf-8'))
# rfc3078#3.1
abcd = data[0] >> 4
ccount =((data[0] & 0xf) << 8) + data[1]
bit_a, bit_d = abcd & 1 != 0, abcd & 8 != 0
data = data[2:]
if ppp['cli']['ip'] is None:
ppp['cli']['ip'] = ip_src
ppp['srv']['ip'] = ip_dst
tx = ppp['cli'] if ppp['cli']['ip'] == ip_src else ppp['srv']
# rfc3078#7.3
for i in range(0, ccount - tx['c']):
tx['skey'] = get_key(tx['mkey'], tx['skey'], 16)
tx['skey'] = RC4(tx['skey']).crypt(tx['skey'])
tx['c'] = ccount
dec = RC4(tx['skey']).crypt(data)
# rfc3078#3.1
if dec[:2] != b'\x00\x21':
# not IP packet
continue
ts += 1
print("0:00:00.{0} {1}".format(ts, dec[2:].hex()))
Download rc4 dependency. Execute the ppp-decrypt.py script, outputting to decrypt.hex1 file.
The script reads data from previously created comp.data file, decrypts the traffic and outputs in hex format.
$ curl -sO https://raw.githubusercontent.com/DavidBuchanan314/rc4/master/rc4/rc4.py
$ python3 ppp-decrypt.py | tee decrypt.hex1
0:00:00.1 45000036ab3b40003f1174a1ac10016464640a02e2e3003500224bd00e9601000001000000000000046b616c69036f72670000010001
0:00:00.2 45000036ab3c40003f1174a0ac10016464640a02e2e300350022cedf8b6b01000001000000000000046b616c69036f726700001c0001
0:00:00.3 4500003622f5000040113be864640a02ac1001640035e2e300224e5f8b6b81800001000000000000046b616c69036f726700001c0001
(..)
Convert the decrypt.hex1 file to one, which text2pcap understands.
Convert to decrypt.pcap.
$ while read line; do echo $line | cut -d" " -f 2 | xxd -r -p | od -Ax -tx1 -v; echo; done < decrypt.hex1 > decrypt.hex2
% text2pcap -l 101 decrypt.hex2 decrypt.pcap
Input from: decrypt.hex2
Output to: decrypt.pcap
Output format: pcap
Wrote packet of 54 bytes.
Wrote packet of 54 bytes.
Wrote packet of 54 bytes.
Wrote packet of 70 bytes.
Wrote packet of 84 bytes.
Wrote packet of 84 bytes.
Wrote packet of 73 bytes.
Wrote packet of 113 bytes.
Wrote packet of 84 bytes.
Wrote packet of 84 bytes.
Wrote packet of 84 bytes.
Wrote packet of 84 bytes.
Wrote packet of 84 bytes.
Wrote packet of 84 bytes.
Wrote packet of 84 bytes.
Wrote packet of 84 bytes.
Wrote packet of 84 bytes.
Wrote packet of 84 bytes.
Wrote packet of 60 bytes.
Wrote packet of 60 bytes.
Wrote packet of 52 bytes.
Wrote packet of 138 bytes.
Wrote packet of 52 bytes.
Wrote packet of 237 bytes.
Wrote packet of 94 bytes.
Wrote packet of 52 bytes.
Wrote packet of 52 bytes.
Wrote packet of 52 bytes.
Read 28 potential packets, wrote 28 packets (2747 bytes).
Looking at the traffic with tshark reveals single HTTP connection. Extracting it, gives the flag.
$ tshark -r decrypt.pcap
1 0.000000 172.16.1.100 → 100.100.10.2 DNS 54 Standard query 0x0e96 A kali.org
2 0.000001 172.16.1.100 → 100.100.10.2 DNS 54 Standard query 0x8b6b AAAA kali.org
3 0.000002 100.100.10.2 → 172.16.1.100 DNS 54 Standard query response 0x8b6b AAAA kali.org
4 0.000003 100.100.10.2 → 172.16.1.100 DNS 70 Standard query response 0x0e96 A kali.org A 192.124.249.10
5 0.000004 172.16.1.100 → 192.124.249.10 ICMP 84 Echo (ping) request id=0x0cfd, seq=1/256, ttl=63
6 0.000005 192.124.249.10 → 172.16.1.100 ICMP 84 Echo (ping) reply id=0x0cfd, seq=1/256, ttl=127 (request in 5)
7 0.000006 172.16.1.100 → 100.100.10.2 DNS 73 Standard query 0x6fd3 PTR 10.249.124.192.in-addr.arpa
8 0.000007 100.100.10.2 → 172.16.1.100 DNS 113 Standard query response 0x6fd3 PTR 10.249.124.192.in-addr.arpa PTR cloudproxy10010.sucuri.net
9 0.000008 172.16.1.100 → 192.124.249.10 ICMP 84 Echo (ping) request id=0x0cfd, seq=2/512, ttl=63
10 0.000009 192.124.249.10 → 172.16.1.100 ICMP 84 Echo (ping) reply id=0x0cfd, seq=2/512, ttl=127 (request in 9)
11 0.000010 172.16.1.100 → 192.124.249.10 ICMP 84 Echo (ping) request id=0x0cfd, seq=3/768, ttl=63
12 0.000011 192.124.249.10 → 172.16.1.100 ICMP 84 Echo (ping) reply id=0x0cfd, seq=3/768, ttl=127 (request in 11)
13 0.000012 172.16.1.100 → 192.124.249.10 ICMP 84 Echo (ping) request id=0x0cfd, seq=4/1024, ttl=63
14 0.000013 192.124.249.10 → 172.16.1.100 ICMP 84 Echo (ping) reply id=0x0cfd, seq=4/1024, ttl=127 (request in 13)
15 0.000014 172.16.1.100 → 192.124.249.10 ICMP 84 Echo (ping) request id=0x0cfd, seq=5/1280, ttl=63
16 0.000015 192.124.249.10 → 172.16.1.100 ICMP 84 Echo (ping) reply id=0x0cfd, seq=5/1280, ttl=127 (request in 15)
17 0.000016 172.16.1.100 → 192.124.249.10 ICMP 84 Echo (ping) request id=0x0cfd, seq=6/1536, ttl=63
18 0.000017 192.124.249.10 → 172.16.1.100 ICMP 84 Echo (ping) reply id=0x0cfd, seq=6/1536, ttl=127 (request in 17)
19 0.000018 172.16.1.100 → 100.100.10.5 TCP 60 46780 → 80 [SYN] Seq=0 Win=64240 Len=0 MSS=1410 SACK_PERM=1 TSval=2680190498 TSecr=0 WS=128
20 0.000019 100.100.10.5 → 172.16.1.100 TCP 60 80 → 46780 [SYN, ACK] Seq=0 Ack=1 Win=65160 Len=0 MSS=1410 SACK_PERM=1 TSval=3670322404 TSecr=2680190498 WS=128
21 0.000020 172.16.1.100 → 100.100.10.5 TCP 52 46780 → 80 [ACK] Seq=1 Ack=1 Win=64256 Len=0 TSval=2680190501 TSecr=3670322404
22 0.000021 172.16.1.100 → 100.100.10.5 HTTP 138 GET /secret.txt HTTP/1.1
23 0.000022 100.100.10.5 → 172.16.1.100 TCP 52 80 → 46780 [ACK] Seq=1 Ack=87 Win=65152 Len=0 TSval=3670322406 TSecr=2680190501
24 0.000023 100.100.10.5 → 172.16.1.100 TCP 237 HTTP/1.0 200 OK [TCP segment of a reassembled PDU]
25 0.000024 100.100.10.5 → 172.16.1.100 HTTP 94 HTTP/1.0 200 OK (text/plain)
26 0.000025 172.16.1.100 → 100.100.10.5 TCP 52 46780 → 80 [ACK] Seq=87 Ack=186 Win=64128 Len=0 TSval=2680190504 TSecr=3670322408
27 0.000026 172.16.1.100 → 100.100.10.5 TCP 52 46780 → 80 [FIN, ACK] Seq=87 Ack=229 Win=64128 Len=0 TSval=2680190504 TSecr=3670322408
28 0.000027 100.100.10.5 → 172.16.1.100 TCP 52 80 → 46780 [ACK] Seq=229 Ack=88 Win=65152 Len=0 TSval=3670322409 TSecr=2680190504
$ tshark -r decrypt.pcap -Y 'http' -z follow,http,hex,0
22 0.000021 172.16.1.100 → 100.100.10.5 HTTP 138 GET /secret.txt HTTP/1.1
25 0.000024 100.100.10.5 → 172.16.1.100 HTTP 94 HTTP/1.0 200 OK (text/plain)
===================================================================
Follow: http,hex
Filter: tcp.stream eq 0
Node 0: 172.16.1.100:46780
Node 1: 100.100.10.5:80
00000000 47 45 54 20 2f 73 65 63 72 65 74 2e 74 78 74 20 GET /sec ret.txt
00000010 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a 20 HTTP/1.1 ..Host:
00000020 31 30 30 2e 31 30 30 2e 31 30 2e 35 0d 0a 55 73 100.100. 10.5..Us
00000030 65 72 2d 41 67 65 6e 74 3a 20 63 75 72 6c 2f 37 er-Agent : curl/7
00000040 2e 36 38 2e 30 0d 0a 41 63 63 65 70 74 3a 20 2a .68.0..A ccept: *
00000050 2f 2a 0d 0a 0d 0a /*....
00000000 48 54 54 50 2f 31 2e 30 20 32 30 30 20 4f 4b 0d HTTP/1.0 200 OK.
00000010 0a 53 65 72 76 65 72 3a 20 53 69 6d 70 6c 65 48 .Server: SimpleH
00000020 54 54 50 2f 30 2e 36 20 50 79 74 68 6f 6e 2f 33 TTP/0.6 Python/3
00000030 2e 38 2e 33 0d 0a 44 61 74 65 3a 20 54 68 75 2c .8.3..Da te: Thu,
00000040 20 30 35 20 4e 6f 76 20 32 30 32 30 20 31 32 3a 05 Nov 2020 12:
00000050 34 31 3a 33 38 20 47 4d 54 0d 0a 43 6f 6e 74 65 41:38 GM T..Conte
00000060 6e 74 2d 74 79 70 65 3a 20 74 65 78 74 2f 70 6c nt-type: text/pl
00000070 61 69 6e 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e ain..Con tent-Len
00000080 67 74 68 3a 20 34 32 0d 0a 4c 61 73 74 2d 4d 6f gth: 42. .Last-Mo
00000090 64 69 66 69 65 64 3a 20 54 68 75 2c 20 30 35 20 dified: Thu, 05
000000A0 4e 6f 76 20 32 30 32 30 20 31 30 3a 33 36 3a 33 Nov 2020 10:36:3
000000B0 31 20 47 4d 54 0d 0a 0d 0a 1 GMT... .
000000B9 66 6c 61 67 20 2d 20 38 37 64 30 35 61 33 65 66 flag - 8 7d05a3ef
000000C9 36 62 30 30 63 32 36 30 30 33 36 66 30 35 32 63 6b00c260 036f052c
000000D9 37 33 30 33 63 62 39 20 20 0a 7303cb9 .
===================================================================$ tshark -r decrypt.pcap -Y 'http.file_data' -T fields -e http.file_data
flag - 87d05a3ef6b00c260036f052c7303cb9 \n