# Azure Malware Lab: Preparation Finally - the exciting part! We've got our templates loaded with tools and samples, and our network infrastructure is all set up. Now it's time to move these templates into our isolated network. But hang on a second... how exactly do we move these machines into the _Mal_Net_ vNet? In VMware or Hyper-V, you'd just flip the network adapter over to the new VLAN or network. In the public cloud though? Not so simple. But don't worry - where there are computer nerds, there's always a way! And actually, the solution is pretty straightforward. We just need to take a snapshot, build a disk from that snapshot, and then create a new machine. Easy as! Not keen on clicking through all the menus? No worries - I've got some code snippets at the bottom of each section to speed things up dramatically. --- ### Snapshots We're using **incremental snapshots** in this malware lab setup. But what does that mean, and why are we doing it this way? Think of a snapshot like a save point in your favourite game. It captures the state of your VM at a specific moment, allowing you to revert to that state later. This is incredibly handy in malware analysis, as you can easily start fresh from a clean snapshot after experimenting with and analysing malware. Now, there are two main types of snapshots: - **Full snapshot**: This is like starting a whole new game save. It copies everything, creating a complete, independent image of your VM. - **Incremental snapshot**: This is like creating a quick save in your game. It only captures the changes made since the last snapshot, making it much quicker to create and saving storage space. In our malware lab, we're all about those incremental snapshots. Why? Because they're: - **Faster**: Creating an incremental snapshot takes way less time than a full snapshot, especially for large VMs. - **Storage-efficient**: Incremental snapshots only store the changes, so they take up far less space than full snapshots. Think of your storage costs - every bit counts! - **Easy to manage**: Managing a chain of incremental snapshots is generally easier than dealing with a bunch of full snapshots. Head over to Snapshots (Azure services → Snapshots), click on create new, and let's fill out the basics: |Name|Configuration|Notes| |---|---|---| |Resource Group|malware_rg|Same resource group from our network build| |Name|Flare_Base|Keep it simple and descriptive| |Region|[Your choice]|Pick the closest one for better performance| |Source Type|Disk|This is where all our good stuff lives| |Source Disk|Flare-Template-OSDisk|The disk from your Flare VM| Click through the settings until you hit networking. Here's where we want to set "_Enable public access from all networks_" to "_Disable public and private access_". Feel free to add some tags if you're into that sort of thing, then head to review and create. Right, now let's do the same for our REMnux box: |Name|Configuration|Notes| |---|---|---| |Resource Group|malware_rg|Keep it in the same resource group| |Name|Remnux_Base|Again, simple and descriptive| |Region|[Your choice]|Stick with your local region| |Source Type|Disk|Where all the magic happens| |Source Disk|Remnux-Template-OSDisk|The disk from your REMnux VM| Same deal with the networking settings - disable that public and private access. Add your tags if you want, then review and create. Brilliant - that's the snapshots sorted! #### Code > [!important] > Make sure you read through the README for each script carefully! While I've tried to keep things consistent, you'll find some small but important differences between them that you'll need to tweak. Take a few minutes to understand what each script needs - it'll save you headaches later! As promised, here's the code to save you from all that clicking! For the Flare VM setup: [https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/2.%20Preparation/Flare/Snapshots](https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/2.%20Preparation/Flare/Snapshots) And for REMnux: [https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/2.%20Preparation/Remnux/Snapshots](https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/2.%20Preparation/Remnux/Snapshots) --- ### Disks Now we've got our snapshots, let's turn them into disks. Find those snapshots we just created (_Flare_Base_ and _Remnux_Base_), click on each one, and select **create disk**. Here's what we're looking at: For Flare: | Name | Configuration | Notes | | ----------------- | ----------------- | --------------------------- | | Resource Group | malware_rg | Keeping everything together | | Disk Name | Mal-Flare-Base-OS | Make it meaningful | | Availability Zone | None | Save a few dollars here | And for REMnux: | Name | Configuration | Notes | | ----------------- | ------------------ | ------------------------------ | | Resource Group | malware_rg | Same resource group as always | | Disk Name | Mal-Remnux-Base-OS | Nice and clear | | Availability Zone | None | No need for extra availability | Same routine with the networking - disable that public and private access. Add your tags if you fancy, then review and create. But hang on a tick... these disks are running on HDD because that's what our template used. For proper analysis work, we might want something a bit zippier. This really comes down to how much you're willing to spend, but for faster analysis and better tool performance, I'd recommend upgrading to an SSD. Want to speed things up? Pop over to Disks, find your new _Remnux-Base-OS_ and _Flare-Base-OS_ disks, and click on **Size + Performance**. Under storage type, you can choose either premium or standard SSD from the locally-redundant storage options. The default performance tier (240 IOPS, 50 MB/s) is a good starting point, but you can always crank it up if you need more oomph! #### Code > [!tip] >These automated steps are absolute gold when you're doing malware analysis! You'll be creating new disks and VMs pretty regularly during dynamic analysis, and trust me - this code will save you heaps of time. Think of it as future-you thanking past-you for the setup work. Ready to automate those disk deployments? Here's where to find the code: For Flare VM: [https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/2.%20Preparation/Flare/Disks](https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/2.%20Preparation/Flare/Disks) And for REMnux: [https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/2.%20Preparation/Remnux/Disks](https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/2.%20Preparation/Remnux/Disks) > [!important] > Just like with the snapshot scripts, make sure you give each README a proper read. While I've tried to keep everything as consistent as possible between the two, there are some small but crucial differences you'll need to adjust. A few minutes reading now will save you troubleshooting later! --- ### Virtual Machines Right, we've made it to the final step (final-ish... more on that later)! We're going to build our virtual machines from those shiny new disks we just created. Ready to bring this lab to life? Let's dive in! Our building blocks are all set - those lovely disks we created earlier. Head over to Azure, find the Disks section, and look for _Mal-Remnux-OS-Base_ and _Mal-Flare-OS-Base_. You'll know you've got the right ones when you see they're unattached. Now, we'll set these up one at a time. > [!tip] >While I'll walk you through the manual process (it's good to understand how everything fits together!), there's some handy code at the end of this section that'll save you heaps of clicking. #### Basic Section | Name | Configuration | Notes | | -------------------- | -------------------------------------------------------- | --------------------------------------------------------------------- | | Resource Group | malware_rg | Where all our analysis tools live | | Virtual Machine Name | MalFlare / MalNux | Our analysis machines - keep the names clear! | | Availability options | None | No need for fancy availability in a lab environment | | Image | Preset | This should be already set based on your disk | | Size | [Your Choice] | Start with basic sizes - you can always beef up Flare later if needed | | Inbound Ports | None | We'll handle this with JIT and NSG | | License Type | Other/Windows Client & Consent for windows 10/11 license | Ubuntu's free as a bird, but Windows needs licensing sorted | Right, basics done! Let's move onto disks. #### Disk Section | Name | Configuration | Notes | | -------------- | ------------- | --------------------------------------------------------------- | | Delete with VM | Enable | Keeps things tidy and costs down when we're done with a machine | #### Networking Section This is where all our hard work from [[Azure Malware Lab Network Build]] comes together! |Name|Configuration|Notes| |---|---|---| |Virtual Network|Mal_Net|Our isolated network| |Subnet|Mal_Sub (10.0.2.0/25)|Where all our security magic happens| |Public IP|None|Definitely don't want internet access here!| |NIC Security Group|None|We'll manage this with JIT| |Delete NIC with VM|Enabled|Clean up after ourselves| #### Management Section Pretty straightforward here - just enable auto-shutdown and set your time zone. Your wallet will thank you later! #### Monitoring Section You can leave boot diagnostics on or turn them off - up to you. They can be handy for troubleshooting if a machine won't start and you need to peek at the console. #### Advanced Section Not much to fiddle with here. There's an option for NVMe disks if that's your thing, but you'll need to check if your image size supports it first. #### Tags You know the drill by now - add them if you use them! #### Review and Create Take a moment to appreciate how far we've come. We've built something pretty special here! When you're ready, hit that create button and watch your malware analysis lab spring to life. ##### Code As promised, I've got some time-saving automation code ready for you. While we've walked through the manual setup process, I know many of you prefer to automate things (and honestly, who doesn't?). I've prepared deployment scripts for both our Flare and REMnux environments. The Flare template will be your primary redeployment tool, but both scripts will prove invaluable in streamlining your lab setup process. You can find them here: - Flare Deployment: [https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/3.%20Deployment/Flare](https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/3.%20Deployment/Flare) - REMnux Deployment: [https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/3.%20Deployment/Remnux](https://github.com/Syb3rs3c/Azure-Malware-Lab/tree/main/3.%20Deployment/Remnux) Before diving in, take a moment to review the README files in each section. This is particularly important if you've customised any resource names during your deployment - you'll need to update the corresponding variables in the scripts to match your environment. ### What's Next Brilliant! We've got our network architecture sorted, our templates built, and our analysis tools ready to rock. But hang on - there's one crucial piece missing from our malware analysis puzzle. How exactly are we going to connect to and manage this secure environment we've crafted? Well, that's where things get really interesting. We need a robust, secure portal that lets us access our analysis environment without compromising any of those carefully planned security controls we've put in place. Enter [[Azure Malware Lab Cloudron]] - our gateway into the malware analysis playground we've built. Think of it as the airlock between our regular network and our contained analysis environment. It's time to set up this final piece and get our lab fully operational. Ready to put the finishing touches on our secure malware analysis environment? Let's dive in!