Suricata

If we break a normal tcp packets flow order and send data before client sends ACK packet and thus complete tcp 3whs then both currently active Suricata versions will not recognize it as HTTP response data. The impact is a complete http response signatures bypass - if an attacker is close to a web client enough he can spoof http response from a legitimate server and send an exploit payload instead of legitimate one and this attack will no be detected by IDS signatures.

Such TCP packets scheme looks as the following:

Client    ->  [SYN] [Seq=0 Ack= 0]           ->  Evil Server     # Client starts a TCP 3-way handshake
Client    <-  [SYN, ACK] [Seq=0 Ack= 1]      <-  Evil Server     # Server responses as it should, but ...
Client    <-  [PSH, ACK] [Seq=1 Ack= 1]      <-  Evil Server     # It sends HTTP response before the 3whs is completed
Client    <-  [FIN, ACK] [Seq=83 Ack= 1]     <-  Evil Server     # Moreover it finishes TCP session 
Client    ->  [ACK] [Seq=1 Ack= 84]          ->  Evil Server     # Client finishes TCP 3whs by sending ACK packet and confirms data from server
Client    ->  [PSH, ACK] [Seq=1 Ack= 84]     ->  Evil Server     # Then it sends a HTTP GET request as nothing wrong happened

In spite of broken TCP flow client accepts "injected" data from server and process it as a normal HTTP Response. Browsers and cli tools like wget/curl were confirmed to process this normally.

If we apply the following signatures agains PCAP file in attachment:

alert tcp any any -> any any (msg: "TCP BEEN RULE"; content: "been"; sid: 5; )
alert http any any -> any any (msg: "HTTP BEEN RULE"; content: "been"; sid: 6; )
alert tcp any any -> any any (msg: "TCP GET RULE"; content: "GET"; sid: 7; )
alert http any any -> any any (msg: "HTTP GET RULE"; content: "GET"; sid: 8; )

We will see only sids 5, 7 and 8 in alerts log file.

Also we see no sid 2260001 alert ("SURICATA Applayer Wrong direction first Data") there.