Auteur Sujet: [FireEye]New FakeNet-NG Feature: Content-Based Protocol Detection  (Lu 218 fois)

0 Membres et 1 Invité sur ce sujet

Hors ligne igor51

  • Admin
  • Mega Power Members
  • *****
  • Messages: 10302
New FakeNet-NG Feature: Content-Based Protocol Detection

I (Matthew Haigh) recently contributed to FLARE’s   href="">FakeNet-NG
  network simulator by adding content-based protocol detection and
  configuration. This feature is useful for analyzing malware that uses
  a protocol over a non-standard port; for example, HTTP over port 81.
  The new feature also detects and adapts to SSL so that any protocol
  can be used with SSL and handled appropriately by FakeNet-NG. We were
  motivated to add this feature since it was a feature of the original
  FakeNet and it was needed for real world malware.


What is FakeNet-NG


FakeNet-NG     href="/content/fireeye-www/en_US/blog/threat-research/2016/08/fakenet-ng_next_gen.html">simulates
    a network so malware analysts can run samples with network
  functionality without the risks of an Internet connection. Analysts
  can examine network-based indicators via FakeNet-NG’s textual and pcap
  output. It is plug-and-play, configurable, and works on both Windows
  and Linux. FakeNet-NG simulates common protocols to trick malware into
  thinking it is connected to the Internet. FakeNet-NG supports the
  following protocols: DNS, HTTP, FTP, POP, SMTP, IRC, SSL, and TFTP.


Previous Design


Previously FakeNet-NG employed Listener modules, which were bound to
  configurable ports for each protocol. Any traffic on those ports was
  received by the socket and processed by the Listener. 


In the previous architecture, packets were redirected using a
  Diverter module that utilized WinDivert for Windows and netfilter for
  Linux. Each incoming and outgoing packet was examined by the Diverter,
  which kept a running list of connections. Packets destined for
  outbound ports were redirected to a default Listener, which would
  respond to any packet with an echo of the same data. The Diverter also
  redirected packets based on whether FakeNet-NG was run in Single-Host
  or Multi-Host mode, and if any applications were blacklisted or
  whitelisted according to the configuration. It would simply release
  the packet on the appropriate port and the intended Listener would
  receive it on the socket.


New Design


My challenge was to eliminate this port/protocol dependency. In
  order to disassociate the Listeners from the corresponding ports, a
  new architecture was needed. The first challenge was to maintain
  Listener functionality. The original architecture relied on Python
  libraries that interact with the socket. Therefore, we needed to
  maintain “socket autonomy” in the Listener, so we added a “taste()”
  function for each Listener. The routine returns a confidence score
  based on the likelihood that the packet is associated with the
  protocol. Figure 1 demonstrates the taste() routine for HTTP, which
  looks for the request method string at the beginning of the packet
  data. It gives an additional point if the packet is on a common HTTP
  port. There were several choices for how these scores were to be
  tabulated. It could not happen in the Diverter because of the TCP
  handshake. The Diverter could not sample data from data-less handshake
  packets, and if the Diverter completed the handshake, the connection
  could not easily be passed to a different socket at the Listener
  without disrupting the connection.


 Figure 1: HTTP taste() example




We ultimately decided to add a proxy Listener that maintains
  full-duplex connections with the client and the Listener, with both
  sides unaware of the other. This solves the handshake problem and
  maintains socket autonomy at the Listener. The proxy is also easily
  configurable and enables new functionality. We substituted the proxy
  for the echo-server default Listener, which would receive traffic
  destined for unbound ports. The proxy peeks at the data on the socket,
  polls the Listeners, and creates a new connection with the Listener
  that returns the highest score. The echo-server always returns a score
  of one, so it will be chosen if no better option is detected. The
  analyst controls which Listeners are bound to ports and which
  Listeners are polled by the proxy. This means that the listeners do
  not have to be exposed at all; everything can be decided by the proxy.
  The user can set the Hidden option in the configuration file to False
  to ensure the Listener will be bound to the port indicated in the
  configuration file. Setting Hidden to True will force any packets to
  go through the proxy before accessing the Listener. For example, if
  the analyst suspects that malware is using FTP on port 80, she can
  ‘hide’ HTTP from catching the traffic, and let the proxy detect FTP
  and forward the packet to the FTP Listener. Additional configuration
  options exist for choosing which protocols are polled by the proxy.
  See Figure 2 and Figure 3 for configuration examples. Figure 2 is a
  basic configuration for a Listener, and Figure 3 demonstrates how the
  proxy is configurable for TCP and UDP.


 Figure 2: Listener Configuration Options


 Figure3: Proxy Configuration Options


The proxy also handles SSL detection. Before polling the Listeners,
  the proxy examines the packet. If SSL is detected, the proxy “wraps”
  the socket in SSL using Python’s OpenSSL library. With the combination
  of protocol and SSL detection, each independent of the other,
  FakeNet-NG can now handle just about any protocol combination.


The proxied SSL implementation also allows for improved packet
  analysis. The connection between the proxy and the Listener is not
  encrypted, which allows FakeNet to dump un-encrypted packets to the
  pcap output. This makes it easier for the analyst to examine the
  packet data. FakeNet continues to produce pcap output that includes
  packet data before and after modification by FakeNet. While this
  results in repetitive data, it is often useful to see the original
  packet along with the modification.




Figure 4 shows verbose (-v) output from FakeNet on Windows
  responding to an HTTP request on port 81 from a clowncar malware
  variant (SHA-256
  Malware such as clowncar use traditional protocols over non-standard
  ports for many reasons. FakeNet gives the malware analyst the
  flexibility to detect and respond to these cases automatically.


 Figure 4: clowncar malware using HTTP on
    port 81




FLARE’s FakeNet-NG tool is a powerful network-simulation tool
  available for Windows and Linux. The new content-based protocol
  detection and SSL detection features ensure that FakeNet-NG remains
  the most useful tool for malware analysts. Configuration options give
  programmers the flexibility necessary to respond to malware using most
  protocols on any port.

Source: New FakeNet-NG Feature: Content-Based Protocol Detection