Learn how to set up a truly isolated lab network for malware analysis and the safety considerations of different lab setups.

@September 12, 2022

This is a free and open section for Practical Malware Analysis & Triage. The full 9+ hour course is available on TCM Security Academy for $29.99. The first 5 hours of the course are available for free on YouTube:

Practical Malware Analysis & Triage

Arm yourself with knowledge and bring the fight to the bad guys! Practical Malware Analysis & Triage (PMAT) brings the state of the art of malware analysis to you in engaging instructional videos and custom made, practical labs. Welcome to Practical Malware Analysis & Triage.

t.co

Malware Analysis In 5+ Hours - Full Course - Learn Practical Malware Analysis!

My gift to you all. Thank you 💜 Husky 🔬 Practical Malware Analysis & Triage: 5+ Hours, YouTube Release This is the first 5+ house of PMAT, which is my course that is available on TCM Security Academy. The full course is 9 hours of high quality videos, practical labs, and challenges to learn the art and science of malware analysis.

youtu.be

This section covers an additional lab network setup that uses an Internal Network instead of a Host-Only adapter. This section follows the lab setup section and offers more insights on proper malware lab safety.

It assumes that the reader has completed PMAT sections through “InetSim Setup”. For anyone reading this outside the context of PMAT, the steps to do Internal Network configuration will work with other malware analysis lab hosts but you may need to connect the dots a bit.

Introduction

In PMAT, safety is taught from the beginning of the course and underpins every single activity that the student conducts. One of the most critical pieces of the malware analysis puzzle is the lab set up. Isolating a malware analysis lab is incredibly important to reduce the risk to your physical host and surrounding network.

The PMAT course teaches how to create a malware analysis lab network that uses a Host-Only network adapter to facilitate communication between lab hosts. Over time, students have approached me with a reasonable concern regarding the lab network setup:

“If Host-Only mode allows a VM to route to the physical host in some circumstances, can it really be considered safe for malware analysis?”

I applaud my students for approaching me about this because it means they are thinking critically about safety during malware analysis. While we can never truly eliminate the risk incurred during malware analysis, we must make every effort to mitigate the risk as much as possible wherever it exists.

In this section, I’d like to cover some of the safety considerations for the Host-Only network setup to assuage these concerns. I’d also like to walk you through an additional, optional lab network setup for those looking for an extra degree of security.

Host-Only Safety

First thing’s first. I’d like to get this out of the way immediately:

The PMAT course’s Host-Only lab network setup, when followed to the letter, is safe, has been safe, and will always be safe for malware analysis during this course! There is no need to setup an Internal Network to complete the course safely. The malware in the course has been designed and/or chosen to be as safe as possible in tandem with this lab set up.

In most circumstances, a Host-Only setup effectively mitigates the risk of a malware sample being able to route out to the greater internet to download second stages or call back to a C2. This comes standard with the design of a Host-Only network.

Consider the following table of VirtualBox network configurations:

In Host-Only mode, a guest VM does not know and cannot see the outer LAN. That’s good ✅

But it’s the VM→ Host and Host → VM communication capability represented in the first two columns of the table that tends to concern students. Let’s examine how this functions and some of the mitigating factors at play.

Safety Test

Assume that for the following section, I am using the FLAREVM host with a Host-Only network adapter with a configuration that mirrors the course’s lab network setup configuration. FLAREVM is the host that is used to detonate malware in the course, so we need to make sure it’s safe for our analysis efforts.

Our first experiment is to start a listening socket in our FLAREVM machine and attempt to reach it with our physical host. For simplicity sake, I’ll use port 80.

On FLAREVM:

C:\Users\husky>ncat -nvlp 80
Ncat: Version 5.59BETA1 ( http://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:80

From my physical host:

PS C:\Users\Matt> ncat -nv 10.0.0.4 80
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Connected to 10.0.0.4:80.
hello!

C:\Users\husky>ncat -nvlp 80
Ncat: Version 5.59BETA1 ( http://nmap.org/ncat )
Ncat: Listening on 0.0.0.0:80
Ncat: Connection from 10.0.0.1:1343.
hello!

Just like the table depicts, we can route from our physical host to our guest VM.

But now, let’s attempt to do this in reverse. Note that I use a Windows OS for my physical host with a default set of host firewall configuration rules.

On my physical host:

PS C:\Users\Matt> ncat.exe -nvlp 80
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Listening on :::80
Ncat: Listening on 0.0.0.0:80

From FLAREVM, I can try to access my physical host through its Host-Only adapter IP address, which is 10.0.0.1:

C:\Users\husky>ncat -nv 10.0.0.1 80
Ncat: Version 5.59BETA1 ( http://nmap.org/ncat )
Ncat: .

PS C:\Users\Matt> ncat.exe -nvlp 80
Ncat: Version 7.92 ( https://nmap.org/ncat )
Ncat: Listening on :::80
Ncat: Listening on 0.0.0.0:80

No connection is established. We can repeat this with our physical host’s LAN IP and the same thing happens. The Windows host firewall has prevented this from occurring. As long as the default firewall settings are configured, no connection will traverse from the guest VM to the host.

So when we think about the risk displayed in the previous test, what do we see? Our physical host can route into our guest VM, but our guest VM cannot route to our physical host because it is blocked by the host firewall.

Is there much risk in our physical host being able to originate a connection and reach our guest VM? I would say no. Our physical VM’s hypervisor is how we interact with the guest VM, so this represents another way that the hypervisor host can access the guest. If the opposite was true, it would be riskier.

If we imagine any malware sample that detonates in FLAREVM and tries to traverse out to our physical host, this traffic will now either:

• be handled and routed to INetSim,
• or, be dropped by the physical host’s firewall.

*nix and MacOS

Now, that works well for Windows hosts, but what about a physical host running *nix or MacOS? While it’s true that these OS do not come standard with a host firewall, the malware in the PMAT course is not designed to be compatible with *nix operating systems. The one exception here is the Android malware sample, but this sample is only examined with static analysis methodology, meaning it is never executed. There are no malware propagation mechanisms in the malware in this course that can infect a *nix/MacOS host.

Additionally, *nix and MacOS can use the venerable iptables utility to drop traffic that is inbound from the guest VMs. iptables is built into the *nix OS and serves as a host firewall:

# iptables -A INPUT -s [IP ADDRESS] -j DROP

If you are using *nix/MacOS for your physical host’s OS, it may be a good idea (though is not necessary for this course) to implement iptables rules for future analysis, especially if you want to analyze malware that is built for *nix. Please see the man page for iptables and the following site for more information:

Block an IP address on a Linux server -

Last updated on: 2021-05-05 Authored by: Morgan Marion A large number of requests from one IP address can deplete the server of available resources. This article provides the commands to block an IP address on three common Linux® software firewalls. Basic understanding of commands in a Linux operating system.

docs.rackspace.com

Internal Networks

For the final part of this section, I’d like to offer the steps for how to make an Internal Network for our malware analysis lab. This is completely optional and you cannot have an Internal Network and a Host-Only network configured at the same time, so please pick one to configure.

Again, Host-Only is sufficient for this course. The Internal Network provides an additional level of safety that removes the reliance on a host firewall to protect our physical host, so if you are more comfortable implementing it, please feel free to do so.

I want to teach this because it is likely that, during your lucrative career as the world’s preeminent malware analyst, you’ll be faced with a situation where the risk calculus is such that an Internal Network is the only safe option. In truth, all of my malware analysis work is done with VMworkstation Pro and an Internal Network. While VMworkstation Pro is not available for free, the VirtualBox Internal Network is now sufficiently stable and usable that we can use it in the course.

Setting Up REMnux

We need to create an Internal Network and associate both VMs to it. We’ll start with REMnux. Perform the following steps to do so.

• Right-click on the REMnux VM and select Settings
• Click on Network
• In the Attached To dropdown menu, select Internal Network
• In VirtualBox, Internal Networks are associated by name. Add a name to the new Internal Network, like “pmat-internalnet”
• Click the drop down arrow next to Advanced to expand the advanced settings
• In the Promiscuous Mode drop down menu, select “Allow VMs”

Your settings should now look like this:

Click OK. Then, power on the REMnux guest host by clicking the Start button.

REMnux Static IP Assignment

There is no DHCP server in the Internal Network, so we need to manually define a static IP address for the REMnux host. We will use the netplan utility to do so. The netplan utility uses a YAML config file to control the host’s adapter settings. This YAML config file lives in /etc/netplan/

Open the netplan conf file in nano with sudo:

remnux@remnux:~$ sudo nano /etc/netplan/01-netcfg.yaml

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: yes

We want to remove this from DHCP and assign all network information statically. YAML syntax requires specific code indentation to be processed correctly. Please pay attention to the amount of spaces for each YAML object.

Change dhcpv4 to no, add the addresses and gateway4 objects, and configure them with the following values:

# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
ethernets:
    enp0s3:
     dhcp4: no
     addresses: [10.0.0.3/24]
     gateway4: 10.0.0.1

remnux@remnux:~$ sudo netplan apply
remnux@remnux:~$

If no output returns after the netplan apply command, the YAML file is formatted correctly and has been processed.

If you get the following error:

remnux@remnux:~$ sudo netplan apply
/etc/netplan/01-netcfg.yaml:10:10: Invalid YAML: inconsistent indentation

… or:

Invalid YAML at //etc/netplan/01-netcfg.yaml line 7 column 6: did not find expected key

… that means your YAML syntax is off somewhere. It will show you the line that you need to fix.

We can now inspect the adapter settings on REMnux:

remnux@remnux:~$ ip -br -c a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
enp0s3           UP             10.0.0.3/24 fe80::a00:27ff:feef:67e4/64

Setting Up FLAREVM

FLAREVM is, believe it or not, a bit more straightforward than REMnux for this setup.

• Right-click on the FLAREVM host and select Settings
• Click on Network
• In the Attached To dropdown menu, select Internal Network
• Associate FLAREVM to the same Internal Network that we made earlier in the setup for REMnux by selecting it from the Name dropdown: “pmat-internalnet”
• Click the drop down arrow next to Advanced to expand the advanced settings
• In the Promiscuous Mode drop down menu, select “Allow VMs”

Your settings should now look like this:

Click OK. Then, power on the FLAREVM guest host by clicking the Start button.

Once you have logged in and are at the FLAREVM desktop, go to the Windows button and enter View Network Connections in the search to get to the Network Connection Adapter settings.

Two adapters are present: an Ethernet Adapter and the Npcap Loopback Adapter. Right click on the Ethernet adapter and select Properties → IPv4 Properties.

We will now statically define our IPv4 settings to mirror the Host-Only setup. This means that at the end of the day, we want:

• The IPv4 address of FLARE to be set to something. It doesn’t matter what it’s set to as long as it’s a valid address in the 10.0.0.0/24 network and we keep track of it.
• The Subnet Mask to configure a /24 network.
• Our Default Gateway to be the REMnux host so we can make use of INetSim.
• Our DNS server to be the REMnux host so we can make use of INetSim.

The correct settings look something like this:

Once this looks good, select OK and then select OK in the adapter settings window.

Now, examine the IP settings in a cmd prompt:

C:\Users\husky>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : DESKTOP-M87PSAK
   Primary Dns Suffix  . . . . . . . :
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter
   Physical Address. . . . . . . . . : 08-00-27-55-06-07
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::f4fb:f210:ea5a:478f%4(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.0.0.4(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 10.0.0.3
   DHCPv6 IAID . . . . . . . . . . . : 101187623
   DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-28-B4-6C-F2-08-00-27-55-06-07
   DNS Servers . . . . . . . . . . . : 10.0.0.3
   NetBIOS over Tcpip. . . . . . . . : Enabled

Note the entries for the IP address, subnet mask, default gateway, and DNS server.

Testing & Troubleshooting

Now, let’s test our network. Ideally, our network now facilitates communication between FLAREVM and REMnux while also denying traffic to our physical host and beyond. And unlike a Host-Only network, we don’t need to rely on a host firewall to drop traffic heading for our physical host.

Test Connectivity Between VMs

The old ping test. Ping the other VM.

On FLAREVM:

C:\Users\husky>ping -n 2 10.0.0.3

Pinging 10.0.0.3 with 32 bytes of data:
Reply from 10.0.0.3: bytes=32 time<1ms TTL=64
Reply from 10.0.0.3: bytes=32 time<1ms TTL=64

Ping statistics for 10.0.0.3:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

On REMnux:

remnux@remnux:~$ ping -c 2 10.0.0.4
PING 10.0.0.4 (10.0.0.4) 56(84) bytes of data.
64 bytes from 10.0.0.4: icmp_seq=1 ttl=128 time=0.308 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=128 time=0.321 ms

--- 10.0.0.4 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1020ms
rtt min/avg/max/mdev = 0.308/0.314/0.321/0.006 ms

Test Outbound Connections

Ensure that our Internal Network is truly isolated with a few tests. Each of these tests should fail which indicates that our network is not routable to our physical host and beyond.

On REMnux:

remnux@remnux:~$ ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 10.0.0.3 icmp_seq=1 Destination Host Unreachable
From 10.0.0.3 icmp_seq=2 Destination Host Unreachable

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms
pipe 2

remnux@remnux:~$ nslookup google.com
Server:		127.0.0.53
Address:	127.0.0.53#53

** server can't find google.com: SERVFAIL

remnux@remnux:~$ ping -c 2 [your physical host's IP address/Wifi address]
PING x.x.x.x (x.x.x.x) 56(84) bytes of data.
From 10.0.0.3 icmp_seq=1 Destination Host Unreachable
From 10.0.0.3 icmp_seq=2 Destination Host Unreachable

--- x.x.x.x ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1001ms
pipe 2

On FLAREVM, repeat the previous steps.

C:\Users\husky>ping -n 2 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
Request timed out.
Request timed out.

Ping statistics for 8.8.8.8:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),

C:\Users\husky>ping -n 2 google.com
Ping request could not find host google.com. Please check the name and try again.

C:\Users\husky>ping -n 2 [your physical host's IP address/Wifi address]

Pinging x.x.x.x with 32 bytes of data:
Request timed out.
Request timed out.

Ping statistics for x.x.x.x:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss),

Under certain circumstances, you may see a ping response when pinging a DNS record. Depending on if you have been using the lab and INetSim, this response may be coming from the INetSim DNS resolver. Stopping INetSim, flushing the DNS cache on FLAREVM, and attempting to ping again should fix this:

C:\Users\husky>ping -n 2 google.com

Pinging google.com [10.0.0.3] with 32 bytes of data:
Reply from 10.0.0.3: bytes=32 time<1ms TTL=64
Reply from 10.0.0.3: bytes=32 time<1ms TTL=64

Ping statistics for 10.0.0.3:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms

...
[On REMnux, stop INetSim wih Ctl+C]
...

C:\Users\husky>ipconfig /flushdns

Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

C:\Users\husky>ping -n 2 google.com
Ping request could not find host google.com. Please check the name and try again

Test INetSim

Use the configuration details from the INetSim setup from PMAT and test to make sure FLAREVM can still access arbitrary DNS records.

Start INetSim on REMnux:

remnux@remnux:~$ inetsim
INetSim 1.3.2 (2020-05-19) by Matthias Eckert & Thomas Hungenberg
Using log directory:      /var/log/inetsim/
Using data directory:     /var/lib/inetsim/
Using report directory:   /var/log/inetsim/report/
Using configuration file: /etc/inetsim/inetsim.conf
Parsing configuration file.
Configuration file parsed successfully.
=== INetSim main process started (PID 1902) ===
Session ID:     1902
Listening on:   10.0.0.3
Real Date/Time: 2022-09-12 06:48:40
Fake Date/Time: 2022-09-12 06:48:40 (Delta: 0 seconds)
 Forking services...
  * dns_53_tcp_udp - started (PID 1906)
  * smtp_25_tcp - started (PID 1909)
  * pop3_110_tcp - started (PID 1911)
  * pop3s_995_tcp - started (PID 1912)
  * smtps_465_tcp - started (PID 1910)
  * ftp_21_tcp - started (PID 1913)
  * https_443_tcp - started (PID 1908)
  * http_80_tcp - started (PID 1907)
  * ftps_990_tcp - started (PID 1914)
 done.
Simulation running.

Use nslookup from FLAREVM for an arbitrary DNS record:

C:\Users\husky>nslookup asdasdasd.com
Server:  www.inetsim.org
Address:  10.0.0.3

Name:    asdasdasd.com
Address:  10.0.0.3

Use a browser to browse to an arbitrary site name:

Conclusion

That concludes this section on Host-Only network safety and creating an Internal Network for our malware analysis lab. You have learned more about the safety considerations of the Host-Only network setup and how to make an Internal Network to apply a greater degree of safety to the lab setup.

Remember, both of these lab network setups are sufficiently safe for this course. Please consider each type of network and what your needs are as a malware analyst for analysis beyond the PMAT course.

(and hey, when you make it to the top of the world as the world’s greatest malware analyst, don’t forget me! 😉 )

-Husky

— — — — — — > Back to 🖊️Blog

🌐 Where You Can Find Me

🐦 Twitter | 📡 Main Blog | 👽 GitHub | 📺 YouTube

📒Recent Notes

8/30/22 🥋Content Creators, I Will Teach You Cyber Jiu-Jitsu

8/12/22 🛡️The Responsible Red Teamer’s Manifesto

7/30/22 🌉On Patching Binaries

7/16/22 🦟MS-Interloper: On the Subject of Malicious MSIs

4/22/22 👁️‍🗨️Failing All The Way To Token Manipulation, Part 1

4/16/22 ☁️COM Hijacking Creative Cloud

⚡My Work

TryHackMe | Weasel

I think the data science team has been a bit fast and loose with their project resources.

tryhackme.com

The Taggart Institute: Master Your Craft

Great hackers are good people. Many courses on red teaming will teach you the technical process of how to exploit targets. But seldom do courses cover what it means to carry out the role of a red teamer responsibly.

taggartinstitute.org

TryHackMe | Takedown

We have reason to believe a corporate webserver has been compromised by RISOTTO GROUP. Cyber interdiction is authorized for this operation. Find their teamserver and take it down.

tryhackme.com

Practical Malware Analysis & Triage

Arm yourself with knowledge and bring the fight to the bad guys! Practical Malware Analysis & Triage (PMAT) brings the state of the art of malware analysis to you in engaging instructional videos and custom made, practical labs. Welcome to Practical Malware Analysis & Triage.

academy.tcm-sec.com

GitHub - HuskyHacks/PMAT-labs: Labs for Practical Malware Analysis & Triage

Welcome to the labs for Practical Malware Analysis & Triage. Read this carefully before proceeding. This repository contains live malware samples for use in the Practical Malware Analysis & Triage course (PMAT). These samples are either written to emulate common malware characteristics or are live, real world, "caught in the wild" samples.

github.com

📝Recent Blog Posts

ChatGPT & Malware Analysis

I, for one, welcome our new AI overlords.

notes.huskyhacks.dev

TryHackMe: Takedown Walkthrough

This is the official walkthrough for this room. I did not cover every single detail available but do cover enough to get from start to finish. Obviously, major spoilers are ahead from here on out.

notes.huskyhacks.dev

Malware Analysis Labs: Internal Network vs Host-Only

"If Host-Only mode allows a VM to route to the physical host in some circumstances, can it really be considered safe for malware analysis?" I applaud my students for approaching me about this because it means they are thinking critically about safety during malware analysis.

notes.huskyhacks.dev

How To HACK Your EX'S SOCIAL MEDIA ACCOUNTS (REAL GUIDE)

What better way to get revenge than to your ? That's where I, 0xTastyyboi, come in. I'm going to show you all that you need to know to EX'S SOCIAL MEDIA ACCOUNTS your . EX'S SOCIAL MEDIA ACCOUNTS ... Kali doesn't have notepad.exe ? What the hell is...

notes.huskyhacks.dev

Red Team Infrastructure Done Right

You may be familiar with Tim MalcomVetter's blog post on Safe Red Team Infrastructure , where he lays out the high level overview of how to make a safe red team operational network. That post changed my life, but it did lack the technical details on how to do this process in a practical sense.

notes.huskyhacks.dev

We Put A C2 In Your Notetaking App: OffensiveNotion

Notion is a popular notetaking application. It has lots of great features that make notetaking a snap. Some of the features we love the most include the capability to share notebooks across teams, push notes to cloud storage, build custom templates, and, in general, deck out your pages so they feel like they have lots of personality!

medium.com

DLL Hijacking & DLL Proxying An SNES Emulator

Time: 30 mins Difficulty: Beginner Skills: Custom Exploit Development, DLL Hijacking 30 minute exploit dev post. Let's get it. I fell down another security research rabbit hole and when I snapped out of it, I found myself.... ...playing Chrono Trigger? Wait, what? That program in the picture is an SNES Emulator and, if you're like...

huskyhacks.dev