Covert Man-on-the-Side Attacks


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.

Man-on-the-Side Explained A Man-on-the-Side (MOTS) attack has the following two characteristics:
  • The attacker can read the traffic and insert new messages, but not to modify or delete messages sent by other participants.
  • The attacker relies on a timing advantage to make sure that the response he sends to the request of a victim arrives before the legitimate response.

In practice this means that the attacker relies on packet injection to insert a TCP packet with a payload to be executed by the victim, such as an HTTP redirect to a malicious web site (source The Intercept). The TCP sequence number of this injected packet will typically be the same as that in the real HTTP response coming from the legitimate web server. Thus, the end node will see two overlapping TCP segments with different application layer data.

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 mots-with-fin.pcap (this is not the MOTS attack analyzed in my training). Here's what the PCAP file looks like when analyzed with Tshark:

tshark -r mots-with-fin.pcap -T fields -e ip.src -e ip.dst -e ip.ttl -e tcp.seq -e tcp.flags -e http.response.code -e http.response.phrase 64 189665416  0x0002       54 4114717473 0x0012 64 189665417  0x0010 64 189665417  0x0018       64 4114717474 0x0019 302 Found <--INJECTED 64 189665756  0x0010       54 4114717474 0x0010 64 189665756  0x0011       54 4114717474 0x0018 301 Moved Permanently

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
-> 4114717474
HTTP/1.1 302 Found
Location: //
Content-Length: 0

HTTP/1.1 301 Moved Permanently
Date: Tue, 21 Apr 2015 00:40:01 GMT

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.

Martin's qisniff tool is open sourced under a GPLv2 license and is available on GitHub here:

To run qisniff you need to have Go 1.5 installed as well as gopacket.


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.

UPDATE 2016-02-02

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.

HoneyBadger detecting an injected TCP packet with FIN flag Image: HoneyBadger detecting injected packet in the mots-with-fin.pcap file we released.

UPDATE 2016-10-25

I have now released my own tool called "findject", which is a simple python script that can detect packet injection attacks like QUANTUM INSERT. You can read more about how to detect this type of attacks with findject in my blog post "Detect TCP content injection attacks with findject".

findject logo

More... Share  |  Facebook   Twitter   Reddit   Hacker News Short URL:

Posted by Erik Hjelmvik on Monday, 21 September 2015 08:23:00 (UTC/GMT)


NETRESEC on Twitter

Follow @netresec on twitter:


Recommended Books

» The Practice of Network Security Monitoring, Richard Bejtlich (2013)

» Applied Network Security Monitoring, Chris Sanders and Jason Smith (2013)

» Network Forensics, Sherri Davidoff and Jonathan Ham (2012)

» The Tao of Network Security Monitoring, Richard Bejtlich (2004)

» Practical Packet Analysis, Chris Sanders (2017)

» Windows Forensic Analysis, Harlan Carvey (2009)

» TCP/IP Illustrated, Volume 1, Kevin Fall and Richard Stevens (2011)

» Industrial Network Security, Eric D. Knapp and Joel Langill (2014)