# Azure Malware Lab Design Ever been curious about how malware actually works? Like, how it's built and what it does to your operating system? Maybe you've wanted to dig into it but thought "nah, I don't want that anywhere near my computer - what if it breaks out and infects everything?" If you're nodding along, you're not alone! I've always been fascinated by figuring out how things tick, especially when it comes to malware and picking it apart to see what makes it work. --- Here's the thing about building a malware analysis lab - security isn't just a nice-to-have, it's absolutely crucial. You need layers upon layers of protection to stop malware from doing three things: infecting your systems, phoning home to its command servers, or (worst case scenario) breaking free into your network. But at the same time, you still need to watch how it behaves normally to understand it properly. Usually, security professionals go for things like VMware, Hyper-V, or Virtual Box to set up their network. But what if you're worried about malware being sneaky and breaking out of your sandbox? Or maybe you want to access your analysis environment from anywhere, on any device, while keeping everything locked down tight? Well, these days we've got public cloud as an option. Sure, there's a cost involved, but when you think about what could happen if your system gets compromised... suddenly it doesn't seem so expensive. Just keep in mind - this is just one way to do things. It might not be perfect for everyone, but it works great for me, and I'll show you why. We'll start by looking at the usual setup, then see how we can make it work in Azure instead. Along the way, we'll tackle those tricky problems that usually pop up with local setups, before getting into the nitty-gritty of building it all. While we could use fancy tools like Terraform to automate all this (and we'll get to that later!), let's start by doing it manually so we really understand what's going on under the hood. ## The Traditional Setup Before we jump into Azure, let's look at how most people set up their malware labs locally. Here's what a typical setup looks like: ![[Pasted image 20241130190851.png]] Pretty straightforward, right? You've got your host computer running something like VMware or VirtualBox, a couple of virtual machines for analysis, and everything's connected through a virtual switch. It works, but there are some catches: - You're limited to accessing it from that one computer - You're trusting that your hypervisor can fully contain the malware - If something goes wrong, it's your physical machine at risk ## Moving to the Cloud This is where Azure comes in handy. Instead of relying on a local setup, we can build something more robust in the cloud. We'll take the same basic concept - isolated networks and virtual machines - but add some serious security controls that just aren't available in a local setup. The best part? When we're done, you'll be able to access your lab securely from anywhere, and if anything goes wrong, you're only risking cloud resources that you can restore with a click. ## Translating to Azure Before we dive in, we need to figure out three main things: 1. How do we create a network that's completely isolated with no way out? (no egress traffic) 2. How do we actually connect to something that can't access the internet? 3. What happens when we need to start fresh after infecting our machines with malware? Let's tackle these one by one! ### Host-Only Network >[!note] >We'll need two resource groups to keep all our stuff organised - specifically for the network bits. Here's what we're building: First up, we need a dedicated virtual network with an address space that stands out - something like 10.0.2.0/24. You'll want to remember this one. Inside this network, we're setting up two subnets within our **10.0.2.0/24** space: - **Mal_Sub (10.0.2.0/25)** - This is where our two malware analysis machines will live - Completely cut off from the internet (we'll tick that "Enable private subnet" box) - We'll sort out the route table and NSG later - baby steps! - **Guac_Subnet (10.0.2.128/27)** - This is our answer to how we'll actually get into our environment - more on this in a bit! For our internet-friendly network (let's call it _Sky_Net_), we'll use a different address space - something like 10.10.10.0/24. - **Sky_subnet (10.10.10.0/24)** - Right now, Azure lets internet traffic flow if you don't enable private subnetting - Heads up though - this is changing soon, and you'll need a NAT gateway for internet traffic in the future. ### Accessing Our Isolated Lab Remember that second question we had about connecting to something that can't access the internet? Well, we've got two solid options for this: Azure Bastion or Apache Guacamole. Both will let us get into our isolated environment securely, but they each have their own pros and cons. Let's break them down. #### Azure Bastion: The Easy But Pricey Option Setting up Azure Bastion is pretty straightforward - just rename that **Guac_Subnet** to **AzureBastionSubnet** (yep, it has to be exactly that), and you're mostly there. It's a PaaS service that acts like your gateway into the lab. The nice thing about PaaS? Less work for us keeping things secure! ##### What You Get with Bastion - RDP and SSH access through port 443 - Browser-based connections (no special software needed) - Built-in security managed by Azure - No way for malware to escape back to your machine Want to know the nitty-gritty details? Check out: - [Azure Bastion overview](https://learn.microsoft.com/en-us/azure/bastion/bastion-overview) - compares the different versions - [Azure Bastion pricing](https://azure.microsoft.com/en-us/pricing/details/azure-bastion/) - shows you what it'll cost you #### Apache Guacamole: The DIY Money-Saver Now, if you're like me and want to keep costs down, Apache Guacamole might be more your style. It does pretty much the same thing as Bastion - lets you use RDP, SSH, and even throws in VNC support through port 443. The main difference? You're in charge of the whole thing (it's IaaS instead of PaaS). ##### What You Get with Guacamole - All the same connection types as Bastion (RDP, SSH) - Plus VNC support (handy for some Linux setups) - Complete control over the configuration - Significantly lower cost - More setup work required (but we'll get to that) I found the easiest way to set this up is using Cloudron - we'll get into the extra bits you'll need when we hit the building section [[Azure Malware Lab Cloudron]]. ### Snapshot Strategy: Our Safety Net Speaking of that third question - what happens when our analysis machines get infected? This is where Azure snapshots come in clutch. Think of snapshots like system restore points on steroids. Azure lets you take a complete picture of your machine at any point, and you can use that to build new machines later. So when things go wrong (and trust me, they will!), you can just start fresh from your snapshot. Making all the nasty... go away. It's worth taking snapshots at a few key points: - After initial OS installation - After tools are installed but before any malware - Maybe even after specific configurations you want to keep This way, you've always got a clean state to roll back to, no matter what that sneaky malware does to your system. ## Securing Our Design Right, so we've got our resource groups and networks set up - one that can talk to the internet and one that can't. But let's make extra sure nothing can escape from our **Mal_Net** network. Time to add some security! ### User Defined Routes: Our Traffic Control Think of User-Defined Routes (UDRs) as our traffic controllers in Azure. They're our first line of defence, and here's what makes them so handy: 1. They let us override Azure's default traffic rules 2. We can control exactly how traffic flows between our networks 3. We can tell network packets where to go (or in our case, where they can't go) Here's the really cool part - when you create a route of `0.0.0.0/0` and set the next hop type to "None" (basically a dead end), you get: - A catch-all net that matches EVERYTHING trying to get out - A brick wall that nothing can get through - Complete blocking of anything trying to reach the internet - Override of Azure's normal rules that usually let traffic out Let's set this up for our **Mal_Sub** subnet (I'll take you through this step by step in [[Azure Malware Lab Network Build]]): - **Route Name**: Null_Net - **Address Prefix**: 0.0.0.0/0 - **Next Hop Type**: None - **Purpose**: Complete internet traffic isolation ### Network Security Group: Our Virtual Bouncer Now let's talk about Network Security Groups (NSGs). Think of them as your virtual bouncer in Azure - they decide who gets in and out of your network. It's basically a built-in firewall that filters traffic based on rules we set. ### Inbound Rules > [!note] >AllowFromBastion can be used interchangeably with AllowFromGuac, it is just a name. Although, AllowFromBastion will need a CIDR of /28 instead of a /27 for Guac. |Priority|Name|Port|Source|Destination|Action| |---|---|---|---|---|---| |100|AllowFromBastion|22, 3389|10.0.2.128/27|mal_sub|Allow| |101|AllowVNCtoMalNux|5901|Public IP of Cloudron|mal-nux VM|Allow| |65000|AllowVnetInBound|Any|VirtualNetwork|VirtualNetwork|Allow| |65500|DenyAllInbound|Any|Any|Any|Deny| #### Outbound Rules >[!note] >These are Azure's default outbound rules - they're actually pretty good for what we need! | Priority | Name | Port | Destination | Action | | -------- | -------------------- | -------- | -------------- | ------ | | 65000 | AllowVnetOutBound | Any | VirtualNetwork | Allow | | 65500 | DenyAllOutbound | Any | Any | Deny | ### Just-in-Time: : Our Extra Security Layer >[!tip] >Want to use this? You'll need Microsoft Defender for Servers Plan 2 on your subscription - it's about $15 per VM per month. If that's not your thing, you can just use NSG instead. For one final layer of security (because why not?), we'll block all traffic to our Cloudron server except from our own IP address on port 443. You can set this up using a just-in-time policy on your Cloudron's public IP. While it won't stop other devices on your network from getting in, it does help shrink down your attack surface - and in security, every little bit helps! ## Putting It All Together Sweet - now we've got some proper security layers in place! Here's what our beefed-up design looks like: ![[Pasted image 20241207213901.png]] Let's break down what's happening in this design: 1. At the top, we've got our authorised user connecting through HTTPS (port 443) - nice and secure! 2. Inside our **Mal_Net** (10.0.2.0/24), we've got several security controls working together: - A Bastion/Cloudron NSG controlling incoming traffic - User Defined Routes blocking any sneaky internet traffic - A **Mal_Sub** subnet NSG managing access to our analysis VMs 3. In the middle, we've got our gateway (either Azure Bastion or Cloudron) sitting in its own subnet (10.0.2.128/27) 4. At the bottom, our analysis VMs live in the **Mal_Sub** subnet (10.0.2.0/25), completely isolated from the internet but able to talk to each other for analysis The dotted line around our analysis VMs shows the isolation boundary - nothing gets in or out except through our carefully controlled access points. It's like having a secure airlock for a biohazard lab, but for malware! Ready to actually build this thing? Let's move on to [[Azure Malware Lab Network Build]] and get our hands dirty!