Malware analysis tools

FakeNet-NG v1.4.9 releases: Next Generation Dynamic Network Analysis Tool

FakeNet-NG is a next-generation dynamic network analysis tool for malware analysts and penetration testers. It is open source and designed for the latest versions of Windows (and Linux, for certain modes of operation). FakeNet-NG is based on the excellent Fakenet tool developed by Andrew Honig and Michael Sikorski.

The tool allows you to intercept and redirect all or specific network traffic while simulating legitimate network services. Using FakeNet-NG, malware analysts can quickly identify malware’s functionality and capture network signatures. Penetration testers and bug hunters will find FakeNet-NG’s configurable interception engine and modular framework highly useful when testing application’s specific functionality and prototyping PoCs.

The FakeNet-NG Diverter implementation for Linux uses Netfilter to examine, log, and redirect packets. Netfilter is available at the kernel level through loadable kernel modules (LKMs) and in userspace through the libnetfilter_queue library. Since FakeNet-NG is Python-based, it uses libnetfilter_queue via the python-netfilterqueue wrapper which is written in Cython.

For purposes of this documentation, some rigorously-defined terms will be repurposed or replaced:

  • TCP defines an endpoint to be a host address and a port number. Although the concept of an endpoint is specific to TCP, we will use the term loosely to mean a host address and port number for any transport protocol we know how to examine (i.e. both TCP and UDP).
  • TCP defines a connection as two endpoints. Because UDP is connectionless, we will use the more general term conversation to represent the concept of a pair of endpoints (again, using that term loosely) that are communicating.

Traffic Flow Condition Evaluation

The simplest case for the Linux implementation of the FakeNet-NG Diverter is MultiHost mode, because IP network address translation (NAT) is not required to support any conditional evaluation such as process blacklists. Hence, we use iptables to implement a REDIRECT rule in the PREROUTING chain. In this use case, FakeNet-NG implements only dynamic port forwarding (DPF) using python-netfilterqueue.

The most complicated case is SingleHost mode (experimental), in which both DPF and NAT must be controlled by FakeNet-NG to permit process blacklisting and other configuration settings. In this case, FakeNet-NG uses python-netfilterqueue to evaluate four conditions:

  1. When a packet is produced, is it destined for a foreign IP address? (if so, fix up its destination address to be a local address)
  2. When a packet is about to be consumed, is it destined for an unbound port? (if so, fix up its destination port to that of the default listener for this protocol)
  3. When a reply packet is produced, is it part of a conversation that has been port-forwarded? (if so, fix up its source port)
  4. When a reply packet is about to be consumed, is it part of a conversation that has been NATted? (if so, fix up its source IP)

Given two processes P1 and P2, here is a diagram of communication and condition evaluation using the INPUT and OUTPUT chains provided by Netfilter:

         (1)                                                      (2)
  .-> [ OUTPUT ] -> [ POSTROUTING ] -> N -> [ PREROUTING ] -> [ INPUT ] ---.
 |                                     E                                    |
 |                                     T                                    V
[P1]                                   W                                  [P2]
 A                                     O                                    |
 |                                     R                                    |
  '---[ INPUT ] <- [ PREROUTING ] <--- K <- [ POSTROUTING ] <- [ OUTPUT ]<-'
         (4)                                                      (3)

And here is more detail on how these conditions are evaluated, per hook:

  • OUTPUT: Evaluate conditions (1) and (3):
    • For (1), check if the packet is destined for a non-local IP address and if so, forward it to 127.0.0.1.
    • For (3), check if the packet’s remote endpoint was port forwarded and if so, fix up the source port to match the transport layer’s expectations.
  • INPUT: Evaluate conditions (2) and (4):
    • For (2), check if the packet is destined for an unbound port and if so, forward it to the default port.
    • For (4), check if the packet’s remote endpoint has been IP forwarded and if so, fix up the source IP address to match the transport layer’s expectations.

Conditions (3) and (4) are necessary to ensure that the transport layer protocol stack perceives the packet as coming from the same endpoint (IP and port) and continues the conversation instead of seeing an extraneous endpoint and sending an RST.

Changelog

Version 1.4.9
————-

  • * Fully customizable HTTP responses without building a full listener

Installation

Usage

flare-fakenet-ng

Copyright 2016 Peter Kacherginsky

Source: https://github.com/fireeye/

Anastasis Vasileiadis

PC Technical || Penetration Tester || Ethical Hacker || Cyber Security Expert || Cyber Security Analyst || Information Security Researcher || Malware analyst || Malware Investigator || Reverse Engineering