# Azure Malware Lab: Cloudron If you've been following along on this journey, you'll know I recently discovered just how costly Azure Bastion can be. While it's a brilliant service, there's one significant drawback - you can't turn it off when you're not using it. That means you're constantly being charged, which isn't exactly ideal for our lab environment. This revelation sent me on a quest to find a more cost-effective solution that would still maintain our security posture. Enter Cloudron - or more specifically, Apache Guacamole running on Cloudron. While Apache Guacamole provides the remote access functionality we need, Cloudron makes the installation process a piece of cake. And as we established earlier... everyone _loves_ cake! ## Prerequisites Before we dive in, you'll need a few things: - A domain name (while free ones exist, I opted for a budget-friendly paid domain) - A [Cloudflare](https://www.cloudflare.com/en-gb/plans/) account - A [Cloudron](https://console.cloudron.io/#/signup) account ## Making the Switch If you've already built your lab following [[Azure Malware Lab Network Build]] using Azure Bastion, no worries! Here's how to make the switch: 1. Remove the Azure Bastion service from your resource group 2. Clean up the associated Bastion Public IP 3. You can now repurpose that subnet for Cloudron (if you haven't already built the Guac_Subnet we discussed in the network build) ## Setting Up Cloudron Now for the fun part! We've already got our network infrastructure ready from our [[Azure Malware Lab Network Build]], so let's get Cloudron up and running. ### Cloudron Machine With our networking sorted, it's time to create our Cloudron server. We'll be using Ubuntu 24.04 LTS for this - you can choose whatever VM size suits your needs, but I've found the Standard DS1 v2 works perfectly well for our purposes. When creating the VM: - Generate an SSH key pair (though password authentication is available if you prefer, but not as secure as key pairs) - Ensure you configure a public IP address - Place it in our previously configured network Once your machine is up and running, we need to lock it down. If you're not using Microsoft Defender with Just-In-Time (JIT) access, you'll need to set up an NSG rule to allow SSH communication between your public IP and the VM's public IP. > [!security] > While limiting SSH access to your public IP is a good security measure, remember that in environments like homes or offices, multiple devices share that IP. Anyone on your network could potentially attempt to connect - something to keep in mind when planning your security layers. Now, let's get Cloudron installed. SSH into your new machine and run these commands: ```bash wget https://cloudron.io/cloudron-setup chmod +x cloudron-setup ./cloudron-setup ``` Fair warning - this installation takes a while. Time to put the kettle on and grab another cuppa... or three. You'll know it's finished when you see a message telling you to navigate to `https://[your-public-IP]`. > [!tip] > If you're wondering whether the installation is still running, you can check the system logs using `journalctl -f` in another terminal window. This will show you the ongoing installation progress. ### Cloudron Configuration Time to get Cloudflare and Cloudron talking to each other. Open your browser and navigate to your Cloudron's webpage. You'll get a certificate warning (don't worry, this is just because it's using a self-signed certificate for now). Click through the advanced options to continue. The webpage will prompt you for two key pieces of information: - Your domain name - Your DNS provider (select Cloudflare) When asked about API access, we'll create a specific API token rather than using the Global API token - it's always better to limit permissions where possible. ### Configuring Cloudflare Let's get Cloudflare managing your domain. You'll need both your DNS registrar and Cloudflare accounts open for this bit. 1. In Cloudflare, add your site and select the free tier 2. Enter your top-level domain name (not a subdomain) 3. Cloudflare will provide you with nameservers 4. Update your DNS registrar's nameserver settings to point to Cloudflare's nameservers 5. Wait for the DNS propagation (this might take a while - perfect time for another cuppa!) Once Cloudflare recognises your domain ownership, let's set up that API token: 1. Click "Get your API token" 2. Select the "Edit Zone DNS" template 3. Configure the following settings: - **Permissions**: Zone → DNS → Edit - **Zone Resources**: Include → Specific Zone → Your Zone Name - **Client IP Address Filtering**: Leave default - **TTL**: Leave default Create the token and copy it into your Cloudron setup. This allows Cloudron to manage DNS records and set up SSL certificates through Let's Encrypt. ### Installing Apache Guacamole The free tier of Cloudron allows two apps, but we only need one - Apache Guacamole. This brilliant piece of tech will be our gateway into the malware analysis environment. If you're curious about how it works, check out the [official documentation](https://guacamole.apache.org/doc/gug/guacamole-architecture.html). Click "My Apps", sign in to your Cloudron account, and find Apache Guacamole. The installation takes about 5 minutes - perfect timing for a quick screen break! ### Configuring Guacamole Thanks to Cloudron, most of the heavy lifting is already done (trust me, setting this up manually is not fun). We just need to configure connections to our MalFlare and MalNux machines. Log in to Guacamole using the default credentials: - Username: `guacadmin` - Password: `guacadmin` Navigate to Settings → Connections → New Connections and let's set up our machines. #### RDP Configuration (For MalFlare) | Setting | Value | Notes | |---------|--------|--------| | Name | Machine Name | Descriptive name for your connection | | Protocol | RDP | Remote Desktop Protocol | | Network Hostname | Server IP | Your VM's IP address | | Port | 3389 | Standard RDP port | | Username | RDP Username | Your Windows login | | Password | User Password | Your Windows password | | Security Mode | NLA | Network Level Authentication | | Ignore Server Certificate | Enabled | Required for our setup | #### SSH Configuration (For MalNux) | Setting | Value | Notes | |---------|--------|--------| | Name | Machine Name | Descriptive name for your connection | | Protocol | SSH | Secure Shell | | Network Hostname | Machine IP | Your VM's IP address | | Port | SSH Port | Usually 22 | | Authentication Username | SSH Username | Your Linux login | | Password | User Password | Your Linux password | > [!tip] > Consider changing the default Guacamole credentials as soon as possible - it's a simple security win! #### VNC Configuration (For MalNux) Remember back in [[Azure Malware Lab REMnux]] when we set up TigerVNC? That's where this connection configuration comes into play. We installed TigerVNC as a system service and configured it to start automatically with our REMnux machine. We also set it up to accept non-localhost connections and created a systemd service file to ensure it starts reliably after each boot. ##### VNC Configuration (For REMnux GUI) | Setting | Value | Notes | | ---------------- | -------------- | -------------------------------------- | | Name | MalNux VNC | Descriptive name for VNC connection | | Protocol | VNC | Virtual Network Computing | | Network Hostname | Machine IP | Your REMnux VM's IP address | | Port | 5901 | The port we configured in TigerVNC | | Password | VNC Password | Set during `vncpasswd` in REMnux setup | | Color Depth | 24 | Recommended for best display | | Resize Method | Display Update | Helps with window scaling | | Read-only | Disabled | Allows full interaction | > [!tip] >If you're having trouble connecting, remember you can check the TigerVNC service status using `systemctl status tigervncserver@:1.service` as we configured in [[Azure Malware Lab REMnux]]. This VNC connection leverages the XFCE desktop environment we installed alongside TigerVNC, giving us a full graphical interface to our REMnux analysis environment. It's particularly useful when you need to use tools with graphical interfaces or prefer a desktop environment for your malware analysis work. > [!note] >The systemd service we created in [[Azure Malware Lab REMnux]] ensures that your VNC server starts automatically after each reboot, so you should always be able to connect - assuming your NSG rules are configured correctly! ### What's Next? We've come a long way in our malware lab journey - from initial network design through to setting up our analysis VMs and now establishing secure remote access through Cloudron and Apache Guacamole. With these pieces in place, we're almost ready to start our malware analysis work. However, there's one crucial piece still missing: how do we simulate internet connections to capture and analyse network indicators when malware attempts to communicate with its Command and Control (C2) servers? Join me in [[Azure Malware Lab Deployment]] where we'll put the finishing touches on our lab environment. We'll configure our MalFlare and MalNux machines to simulate internet connectivity, allowing us to safely observe and analyse malware's network behaviour without risk of it actually reaching out to the real world. > [!tip] >Before moving on to the deployment phase, double-check that all your Guacamole connections are working correctly. It's much easier to troubleshoot access issues now than when you're in the middle of analysing a malware sample! This final piece will complete our secure, isolated malware analysis environment, giving us everything we need to safely study malware behaviour while keeping our own networks protected.