This short video demonstrates how you can search through PCAP files with regular expressions (regex) using
CapLoader and how this can be leveraged in order to
improve IDS signatures.
The EmergingThreats snort/suricata rule mentioned in the video is
“ET TROJAN Fareit/Pony Downloader Checkin 2”.
The header accept-encoding header with quality factor 0 used by the Pony malware is: Accept-Encoding: identity, *;q=0
And here is the regular expression used to search for that exact header:
\r\nAccept-Encoding: identity, \*;q=0\r\n
After recording the video I noticed that the leaked source code for Pony 2.0 actually contains this accept-encoding header as a
hard-coded string. Have a look in the
redirect.php file, where they set
curl’s CURLOPT_HTTPHEADER to this specific string.
Wanna learn more about the intended use of quality factors in HTTP accept headers?
Then have a look at section 14.1 of RFC 2616section 5.3.4 of RFC 7231, which defines how to use qvalues (i.e. quality factors) in the Accept-Encoding header.
After Edward Snowden exposed NSA's Man-on-the-Side attack capabilities we've started to see IDS signatures that can
detect such attacks being released and re-discovered.
However, despite these efforts Man-on-the-Side attacks, such as QUANTUM INSERT,
can still be carried out without triggering these IDS signatures.
I recently taught a network forensics class in Stockholm.
One of the topics covered in this training was how to detect Man-on-the-Side attacks in full content PCAP files.
In one of the labs, in the network forensics training, students were tasked with finding a Man-on-the-Side attack in a 2.3 GB PCAP dataset.
However, the way this MOTS attack was carried out made it invisible to normal signatures designed to detect TCP stream overlaps with different data, such as the Suricata signature 2210050.
alert tcp any any -> any any (msg:"SURICATA STREAM reassembly overlap with different data"; stream-event:reassembly_overlap_different_data; classtype:protocol-command-decode; sid:2210050; rev:2;)
The reason why Suricata and other methods fail to detect this attack is because the injected packet contained both application layer data
(an HTTP redirect) and a TCP FIN flag.
Upon receiving this spoofed packet the client (victim) followed the redirect as well as closed down its current TCP socket
to the web server, by responding with a FIN+ACK packet.
Subsequent packets sent by the real web server were then ignored by the client since the TCP socket was already closed when they arrived.
Stream reassembly engines in intrusion detection systems also ignore packets
sent after the TCP tear-down, since the TCP session is assumed to be closed at this point.
Overlapping TCP segments with different data are therefore not detected by intrusion detection systems
when an injected TCP packet carries the FIN flag.
I've created an example PCAP file, which illustrate this behavior, called
(this is not the MOTS attack analyzed in my training).
Here's what the PCAP file looks like when analyzed with Tshark:
Frame number 5 is the injected “302 Found” packet spoofed by the attacker.
The TCP flag value 0x19 translates to FIN+PUSH+ACK, which is the attackers attempt to tear-down the TCP connection.
The client responds with a FIN+ACK (0x11) in frame 8. The final frame is the real HTTP response coming from the legitimate web server.
Detecting MOTS Attacks
Martin Bruse was one of the guys taking the network forensics class last week.
After realizing that there currently doesn't seem to exist any effective method for
automatically detecting TCP segment overlaps with different data, regardless of the TCP state,
Martin developed a tool called qisniff.
This is what it looks like when mots-with-fin.pcap is analyzed with qisniff:
go run qisniff.go -file mots_with_fin.pcap
HTTP/1.1 302 Found
In the output above we can see the injected content <A> and the legitimate content from the real web server <B>.
What qisniff does is basically reassembling streams and comparing the application layer data in new TCP segments
with that in previously received segments.
This is a very generic way of detecting any form of packet injection in a TCP stream, regardless if it is done as part of a
Quantum Insert attack, an Airpwn injection or
some brand new packet injection attack.
To run qisniff you need to have
Go 1.5 installed as well as
We would like to thank Fox-IT for publishing their great blog post
Deep dive into QUANTUM INSERT,
in which they shed some light on many technical details of Man-on-the-Sida attacks as well as
published IDS signatures designed to detect such attacks.
David Stainton has updated his HoneyBadger tool,
which is specifically designed detect TCP injection attacks, so that it now also detects injected TCP packets with the FIN flag set.
The update was released on January 31, in update 1457755.