=================[ Detection of cyber-attacks ]=================

Detection of real "cyber" attacks (i.e., of network traffic that
leads to system compromises or results from such compromises) still
largely relies on matching signatures of known attacks, either 
byte-for-byte, or via regular expressions that match bytes strings
(if you are not sure how regular expressions or RegExwork, read
  http://perl.plover.com/Regex/article.html for a short intro.)
against files and network streams.

You can get a sense of what these rules look like from the DHS
reports on the so-called GRIZZLY STEPPE attacks. The signatures
start on page 8 of 

https://www.us-cert.gov/sites/default/files/publications/AR-17-20045_Enhanced_Analysis_of_GRIZZLY_STEPPE_Activity.pdf 

and describe byte strings and byte string patterns found in files
(pages 8--10), and in network packets (bottom of page 10, page
19). Both of the network rules match outgoing web traffic from
internal machines : 
  "alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS" 
and are thus "indicators of compromise" or IoC, i.e., evidence 
that some of your internal computers have been infected and
are now making unauthorized connections to an outside attacker's
command-and-control servers (which may also be someone else's
compromised machines).

So how can such binary pattern matching be evaded?

=================[ Evasion of intrusion prevention ]================= 

The basic idea is that network monitors rarely match the target
machines _exactly_. A monitor must take short-cuts when reassembling
TCP streams, and may choose to skip verifying a checksum or a
header. It may also have different time-outs during which it would
hold on to packets, or expect that all packets in a TCP connection are
in order. In case of duplicate or overlapping TCP segments, it may
favor newer or older ones, whereas the target does just the opposite.

In short, the idea is to tweak the TCP stream so that the stream
pattern-matched by a defensive monitor is different from what actually
reaches the target, and does not trip the detection patterns.

These ideas were first published in one famous paper in 1998,
  http://insecure.org/stf/secnet_ids/secnet_ids.html

and have been refined since then (e.g., 
  http://web.archive.org/web/20160127203733/https://www.symantec.com/connect/articles/evading-nids-revisited)

You can find sample code for these attacks in the Dsniff suite,
e.g., https://www.monkey.org/~dugsong/fragroute/ , 
      http://tools.kali.org/information-gathering/fragrouter , etc.

They still work, for the most part :)