# Azure Malware Lab: Deployment We've done it! Take a moment to bask in your glorious creation... If you've been following along since we first sketched out our [[Azure Malware Lab Design]], through the network deployment, analysis templates, and Cloudron setup, you're now standing at the threshold of having your very own professional-grade malware analysis environment. But before we pop the champagne, we've got a few final pieces to put into place. In this last section, we're going to: 1. Get our hands dirty with INetSim configuration on MalNux and sort out the DNS settings on MalFlare (don't worry - I've got some handy scripts to make this painless) 2. Put the finishing touches on our Azure components, particularly those NSG configurations we started in [[Azure Malware Lab Network Build]]. Remember those placeholder rules for _mal_sub_? Now we've finally got the IP addresses to complete them properly. 3. Tie everything together with a comprehensive script that streamlines the deployment process we outlined in [[Azure Malware Lab Preparation]]. This beauty will handle everything - Snapshot management, Disk creation, VM deployment, and even updating DNS on MalFlare. Since MalFlare is typically the only machine you'll need to redeploy during dynamic analysis, this script will save you heaps of time in the long run. Ready to put the final polish on your malware lab? Let's dive in and finish this masterpiece! ## INetSim Configuration Remember how we talked about network indicators and monitoring malware's attempts to communicate with its command and control (C2) servers? You might be wondering: "In our completely isolated environment, how can we possibly see what happens when malware tries to download a second stage payload?" Well, while we can't actually let the malware connect to the real internet (that would defeat the purpose of our secure lab!), we can do something rather clever - we can simulate the network and file downloads. Enter INetSim, our network simulation superhero that comes pre-installed on REMnux. Here's the cool part: when malware attempts to download a file, INetSim will serve up its own GUI binary instead. This tells us something valuable - we've just confirmed that the malware has a network indicator showing it's trying to fetch a second stage payload. Pretty handy, right? Let's get INetSim configured properly. First, connect to your REMnux machine using either VNC or SSH (if you need a refresher on setting this up, pop back to [[Azure Malware Lab Cloudron]]). Time to edit the INetSim configuration file: ```bash sudo nano /etc/inetsim/inetsim.conf ``` First up, we need to enable DNS. Find and uncomment this line: ```bash start_service dns ``` Next, under the service bind section, we need to configure it to listen on all interfaces: ```bash ######################################### # service_bind_address # # IP address to bind services to # # Syntax: service_bind_address <IP address> # # Default: 127.0.0.1 # service_bind_address 0.0.0.0 ``` Now for the crucial bit - setting up the DNS server to point back to our REMnux machine: ```bash ######################################### # dns_default_ip # # Default IP address to return with DNS replies # # Syntax: dns_default_ip <IP address> # #Default: 10.0.2.4 # dns_default_ip 10.0.2.4 ``` >[!note] >Make sure you use your REMnux server's actual IP address here - it's going to act as the DNS server for your simulated internet. (Don't worry, we'll configure MalFlare to point to MalNux as its DNS server in the next section.) Save your configuration (in nano, that's Ctrl+X, then Y, then Enter), and start up INetSim by simply typing: ```bash inetsim ``` With this configuration, we've essentially created a controlled "fake internet" within our isolated environment. When malware tries to reach out, INetSim will be there to answer - giving us valuable insights into its behaviour without any risk of it actually connecting to the outside world. ## DNS Configuration Now we need to point our MalFlare machine to use MalNux as its DNS server. Connect to MalFlare through your Guacamole connection and fire up PowerShell as administrator. Here's a script that'll handle the DNS configuration for us: ```PowerShell # Define the DNS server address as a variable $dnsServer = "10.0.2.4" # Replace with your MalNux IP address # Get the network adapter(s) to modify $networkAdapters = Get-NetAdapter | Where-Object { $_.Status -eq "Up" } # Check if any network adapters are found if ($networkAdapters) { foreach ($adapter in $networkAdapters) { # Set the DNS server for each adapter Write-Host "Changing DNS for adapter: $($adapter.Name)" -ForegroundColor Green Set-DnsClientServerAddress -InterfaceAlias $adapter.Name -ServerAddresses $dnsServer -ErrorAction Stop Write-Host "DNS server for $($adapter.Name) set to $dnsServer" -ForegroundColor Yellow } } else { Write-Host "No active network adapters found." -ForegroundColor Red } Write-Host "DNS change process completed." -ForegroundColor Cyan ``` >[!note] >When you change these DNS settings, your Guacamole connection will drop - this is normal! You can either reconnect or reboot MalFlare to get back in. ### Testing Your Fake Internet Right, let's make sure everything's working properly. On your MalNux machine, first verify that `inetsim` is running. Now, from MalFlare, try connecting to any website - if everything's configured correctly, you should see something like this: ![[Pasted image 20241231120945.png]] Want to test how your lab handles malware trying to download second-stage payloads? Easy - just try downloading a made-up executable by adding `/something.exe` to the end of any URL: ![[Pasted image 20241231121200.png]] If you run the downloaded file, you'll see the INetSim GUI pop up: ![[Pasted image 20241231121244.png]] And there you have it - we've successfully created our own contained "internet"! Any malware running in our lab can try its best to phone home or download additional payloads, but INetSim will be there to catch and log these attempts, giving us valuable intelligence about the malware's behaviour while keeping everything safely contained. ## Script Talk about saving the best for last! After spending most of New Year's Eve coding and tweaking, I've got something brilliant to share with you – a script that's going to save you heaps of time and effort. Let's chat about why this is so important. When we're doing malware analysis, we've got two main approaches: static and dynamic analysis. Dynamic analysis is where things can get a bit dicey because we're actually deploying malware on our systems. As you can imagine, this can leave our machines in a less-than-ideal state. Thankfully, we've got those incremental snapshots to save our bacon if things go pear-shaped. Now, I've shared various scripts throughout this series to speed things up, but there's still been a fair bit of manual work involved. You've had to faff about changing variables to match your environment, navigate through snapshot directories, disk directories, virtual machine levels... folders everywhere, right? Wouldn't it be brilliant if there was just one script to handle the lot? Something that could update all those variables on the fly? Well, your wishes have been granted! I present to you the Fast Redeployment Script for Flare VM (don't worry, the REMnux version is in the works – Flare is our priority since it's the one we'll be resetting most often). Check it out here: [https://github.com/Syb3rs3c/Azure-Malware-Lab/blob/main/Flare-Redeployment.ps1](https://github.com/Syb3rs3c/Azure-Malware-Lab/blob/main/Flare-Redeployment.ps1) ### A Few Important Notes The script needs to live in the root directory of your folder structure, and you'll want to make sure you're following the same structure as my GitHub repo: [https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main](https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main). Your best bet is to clone the entire repo to your machine and tweak the global variables at the top of *Flare-Redeployment.ps1*. Here are the configuration variables you'll need to set: ```PowerShell # --- Configuration --- $ResourceGroupName = "Changeme" $Location = "Changeme" $SubscriptionId = "12345678-1234-1234-1234-123456789012" $ResourceDisk = "Changeme" # --- Global Resource IDs --- $VirtualNetworkId = "/subscriptions/${SubscriptionId}/resourceGroups/${ResourceGroupName}/providers/Microsoft.Network/virtualNetworks/mal_net" $SourceResourceId = "/subscriptions/${SubscriptionId}/resourceGroups/${ResourceGroupName}/providers/Microsoft.Compute/snapshots/Flare_Base" $SourceDiskId = "/subscriptions/${SubscriptionId}/resourceGroups/${ResourceGroupName}/providers/Microsoft.Compute/disks/${ResourceDisk}" ``` The script assumes you've been following along with our guide and using the same naming conventions. If you've gone rogue with your naming (no judgement!), you'll need to update the code accordingly, particularly for the Flare disk name after taking the snapshot. Once you've sorted your variables, the script will automatically: - Take a snapshot of the base Flare template - Build a disk from the snapshot - Create a new network card - Spin up a new virtual machine using the disk and attach the new network card Here's the clever bit – you won't need to reconfigure Cloudron's Apache Guacamole because the IPs should stay the same. As long as you stick to two machines for your malware analysis lab, MalNux should be at _10.0.2.4_ and MalFlare at _10.0.2.5_. This means one Apache Guacamole configuration will let you connect instantly after reverting your machines. And there you have it! Our modest design has evolved into a fully-functioning malware analysis lab. Get out there and have fun – ***responsibly and ethically***, of course! By the way, keep your eyes peeled – I'll be updating the [[Azure Malware Lab Network Build]] section with some code soon to automate the entire process... the code is now provided. Happy new year. --- Happy hunting! 🌿🌿 Gr00t.