Tag: inetsim linux source based routing

How to build a dual-homed malware testing machine

Practical tips

While doing dynamic analysis for malware, researchers often start by running their suspected samples in isolated environments in order to stop accidental leakage of information (such as alerting the malware author in case the malware is calling back home to the C&C server).

While it’s possible to run these samples in complete isolation, it’s useful to have a server simulating real internet services in order to give malware the illusion (or ability) to continue running. INetSim is the project that would give you this functionality.

However, if the researcher decided that Internet access is required, then she needs to move her network settings to another network that can serve real internet traffic.

The below solution describes how a researcher can implement both of these scenarios using a simple setup and the ability to move between INetSim or real Internet with a click of a button from their malware test (goat) machine.

 

  • Effectively, your test machine needs to be dual-homed. Each of its interfaces need to reside on a separate subnet. (use the above diagram as a guide)
  • The default gateway of this “Research Machine” is a linux machine with enabled ip_forward (no need to use NAT’ing; unless you want to!)
  • We will be utilising source based routing in this “Linux router” by using iproute2 ability to run multiple routing tables in parallel
  • Settings of network interfaces inside “Research Machine”
    • Real Internet interface:
      • IP Address: 192.168.1.2
      • Netmask: 255.255.255.0
      • Gateway: 192.168.1.1
    • Fake Internet interface (going to INetSIm)
      • IP Address: 192.168.2.2
      • Netmask: 255.255.255.0
      • Gateway: 192.168.2.1
    • Linux router interfaces to Research Machine (Real Internet)
      • IP Address: 192.168.1.1
      • Netmask: 255.255.255.0
    • Linux router interfaces to Research Machine (INetSim)
      • IP Address: 192.168.2.1
      • Netmask: 255.255.255.0
    • Linux router interfaces to INetSim
      • IP Address: 172.26.0.1
      • Netmask: 255.255.255.0
    • Linux router interfaces to Real Internet Gateway
      • IP Address: 10.0.0.1
      • Netmask: 255.255.255.0
    • INetSim
      • IP Address: 172.26.0.2
      • Netmask: 255.255.255.0
      • Gateway: 172.26.0.1
    • Internet Gateway
      • As the diagram, or use your existing network setup

Note: If your Linux router isn’t implementing NAT towards Internet Gateway and INetSim, then you need static routes on both of these devices to send traffic back to the 192.168.1.0/24 and 192.168.2.0/24 subnets through the Linux router.

Now, to the reason you’re reading this blog post…

Finally, you need to implement source based routing on the Linux router.

When you run:

  • ip route

which is the equivalent of

  • ip route list table main

in a Linux machine, you get to see the “main” routing table. You can run other routing tables in parallel to this one with different default gateways.

  • First, edit /etc/iproute2/rt_tables
    • Add “100 fakenet” to the end of the file. 100 here is a random number. You may choose something else.
    • Now, you have a new routing table called fakenet. Run the following to inspect its content:

    • ip route list table fakenet

Table is empty right now.

  • Add a default gateway to “fakenet”
  • ip route add default via 172.26.0.2 table fakenet
  • Add a rule to the Routing Policy Database (RPDB) in order to process routing for the Researcher’s fakenet interface/subnet to the new routing table

    • ip rule add from 192.168.2.0/24 table fakenet

    • ip route add 192.168.2.0/24 dev eth1 proto kernel scope link src 192.168.2.1 metric 100 table fakenet

  • Flush the routing cache (rarely needed, but worth using if in doubt)

    • ip route flush cache

       

Finally, all you need to do to send traffic to Real Internet or INetSim from your Research Machine is to keep one of these interfaces up and shutdown the other.