In this blog post we’ll dip our feet into the world of rootkits and bootkits and how we can defend ourselves against them in Azure. Azure Virtual Machine security has improved a lot since Windows Server 2016. Terms like Trusted Launch and Secure Boot are being thrown around, but do we really understand what these features are? I’ll try to explain the added benefit of using Trusted Launch. Let’s start!
Setting the goal
The goal of this blog post is to get us familiar with a VM security feature called Trusted Launch. By reading this article, you’ll understand on what level does Trusted Launch protect VMs, what components are part of Trusted Launch and what are the requirements to enable it. We’ll also look at the threats that it protects our VMs from and lastly we will gain understanding how Trusted Launch adoption can be monitored using Azure Policies and how it’s integrated into Microsoft Defender for Cloud.
If you’re looking how to enable Trusted Launch for Azure VMs, I have few screenshots from Azure Portal, but for more complete steps Microsoft Learn has you covered!
What protection layer is this?
I consider Trusted Launch as an internal security measure of VMs. We don’t need to purchase additional licenses nor install external products. It comes as Generation 2 VM capability and is enabled at the VM-level. With Trusted Launch we’re dealing with a platform-level solution that springs into action to secure the loading of the operating system; Pre-OS Boot if you will. Essentially Trusted Launch protects VMs from rootkits.
On most days the lowest level of security that we tend to sacrifice any thoughts is the OS-level. There we have topics like antivirus solutions, patching and updating, data protection through backups, data encryption using BitLocker or dm-crypt, VM networking, OS firewall and host level access control. When our VM is running in Azure we have another layer. We have to think about Azure management level access control, authentication security, monitoring, compliance, policies and even business continuity and disaster recovery.
But to understand Trusted Launch we will have to lift the OS-level to see under it. I’m not myself an expert on hardware and firmware topics, so I’ve had to go through many resources to understand the concepts within and enabling Trusted Launch.
What are rootkits and bootkits?
MITRE ATT&CK framework describes Rootkit (T1014) like this:
“Adversaries may use rootkits to hide the presence of programs, files, network connections, services, drivers, and other system components. Rootkits are programs that hide the existence of malware by intercepting/hooking and modifying operating system API calls that supply system information. Rootkits or rootkit enabling functionality may reside at the user or kernel level in the operating system or lower, to include a hypervisor, Master Boot Record, or System Firmware.“
Rootkit technique is categorized under Defense Evasion tactic in MITRE’s ATT&CK. Rootkits are very hard to detect and they hide deep within the system. What rootkits do depends on a rootkit and the level of foothold it has. Kernel-mode rootkit is especially bad as it has access to practically anything. Other types of rootkits are memory-based rootkits and firmware rootkits for example. Threat actors most commonly associated with rootkits are sophisticated state-sponsored groups who are primarily not financially motivated, but rather carrying out espionage and covert operations. Rootkits are not that common of a threat for commercial enterprises, but they are very problematic and can cause a lot of damage.
Bootkits (T1542.003) (a.k.a. Bootloader Rootkit) are also associated with Defense Evasion tactic, but also with Persistence tactic. Description from MITRE ATT&CK says:
“Adversaries may use bootkits to persist on systems. Bootkits reside at a layer below the operating system and may make it difficult to perform full remediation unless an organization suspects one was used and can act accordingly. A bootkit is a malware variant that modifies the boot sectors of a hard drive, including the Master Boot Record (MBR) and Volume Boot Record (VBR).“
MITRE ATT&CK lists Boot Integrity (Secure Boot + vTPM technologies) as a mitigation to bootkit threat. We’ll cover Boot Integrity Monitoring later.
Bootkit, being a variant of a rootkit, has same characteristics that of a rootkit. It is not that common of a threat and it’s known to be used by APT groups and for example North Korean state-sponsored Lazarus Group.
Trusted Launch
As of today, 1st of January, 2025, Trusted Launch is the default state for newly created Azure VMs, unless it is specifically disabled or a VM generation or size is chosen that is not supported by Trusted Launch.
Trusted Launch is a set of security features that can be enabled or disabled independently.
Enable
- Choose Trusted launch virtual machines from Security type
- Configure security features (if there’s no specific reason, then enable all of them)
- We now only get to choose Gen 2 VM images
You can of course achieve this using Bicep, Terraform, PowerShell and so on, but basically enabling Trusted Launch is that easy!
Let’s check what those previously mentioned components are, but first we have to deal with the concept of VM generations that have been mentioned twice already.
Azure VM generations briefly explained
Trusted Launch is only supported by Generation 2 VMs. At the time of writing, Azure has Generation 1 and Generation 2 VMs available. Gen 1 VMs use BIOS-based architecture and Gen 2 VMs use the newer UEFI-based architecture. This is important because UEFI (Unified Extensible Firmware Interface) is the foundation that enables security features that are included in Trusted Launch. Both UEFI and BIOS are low-level software that start when a computer is booted up. BIOS hasn’t evolved much over the course of its existence while other computer technology has taken large leaps. This mismatch has exposed the limitations of BIOS thus resulting in the emergence of UEFI between years 2006-2007.
- UEFI supports faster boot times because it can initialize multiple hardware components in parallel compared to BIOS’s sequential initialization
- UEFI boot is more standardized around launching EFI executables compared to BIOS which runs code from MBR (Master Boot Record)
- UEFI supports GPT (GUID Partition Table) which removes the 2.1 TB hard drive limitation set by the MBR for the boot drive
- UEFI can run in 32-bit or 64-bit mode and has more execution space compared to BIOS’s 16-bit and 1 MB space limits
- UEFI supports Secure Boot
- UEFI supports networking for remote troubleshooting and configuration
Compared to Generation 1 VMs, Generation 2 VMs support the following features and capabilities:
- Intel Software Guard Extensions (Intel SGX)
- Virtualized Persistent Memory (vPMEM)
- SCSI disk controllers
Secure Boot
Secure Boot is simple yet essential protection feature against bootkits and rootkits. It’s a firmware level code. It ensures that only trusted signed OS boot components can boot, thus creating a root of trust. A boot object after another is tasked to check the signature of the following boot object. If any of the signatures is mismatched the VM does not boot. VM fails to boot if it cannot authenticate that the OS image is signed by a trusted publisher. This is actually a valid point to emphasize – Trusted Launch protects your VM’s OS disk, not Data disks. Both Windows and Linux operating systems support Secure Boot.
virtual Trusted Platform Module (vTPM)
Virtual Trusted Platform Module (vTPM) is a secure vault for cryptographic keys and attested measurements like the boot chain measurement. vTPM in Azure VMs enable remote attestation via Defender for Cloud integration. This attestation can cryptographically measure that only trusted signed boot components were run during the boot, hence attesting the boot integrity. vTPM in Azure VMs comply with TPM2.0 specification.
Virtualization-Based Security (VBS)
VBS (Virtualization-Based Security) seems like a loose term to indicate an isolated region of memory that is created by the hypervisor for OS’s needs. Different types of security solutions can then be enabled to run that utilize this isolated memory region, like Windows Defender Credential Guard or Hypervisor Code Integrity (HVCI). Both of these security solutions are out of scope of this post.
Boot Integrity monitoring
Boot Integrity monitoring requires enabling vTPM and Secure Boot and installing Guest Attestation VM extension. For Windows VMs this extension is Microsoft.Azure.Security.WindowsAttestation.GuestAttestation. This VM extension needs to be able to communicate to the Azure Attestation service’s endpoint. If we’re using NSGs (as we definitely should) we need to open an outbound rule with following configuration.
- Service Tag = AzureAttestation
- Service = Custom
- Destination port = 8080
- Protocol = Any
- Action = Allow
We also have to check how our traffic is routed and open outbound rules for any firewalls that sits between the VM and the Azure Attestation endpoint (*.attest.azure.net).
When we create a Trusted Launch VM and choose Boot Integrity, Guest Attestation extension is automatically installed during the VM deployment.
If we choose Trusted Launch, but do not enable Boot Integrity then Guest Attestation extension is not installed.
To enable Boot Integrity monitoring to an existing VM after deployment install the GuestAttestation VM extension via Azure PowerShell or check the box in Azure Portal: VM > Settings > Configuration > Security type. Here are the PowerShell parameters that you need along with RG name and VM name.
- Name: GuestAttestation
- Published: Microsoft.Azure.Security.WindowsAttestation
- ExtensionType: GuestAttestation
- TypeHandlerVersion: 1.0
- EnableAutomaticUpgrade: $true
Audit Trusted Launch using Azure Policy
To help adopt and monitor our environment for Trusted Launch, Microsoft has made couple of audit policies that we can assign to our subscriptions. One policy simply audits if Trusted Launch is enabled or not and the other policy checks if the existing VM has all prerequisites for Trusted Launch met.
- Virtual Machine should have TrustedLaunch enabled
- Disks and OS image should support TrustedLaunch
List VMs that have Trusted Launch disabled using KQL
Another way to get visibility into the VMs that need attention regarding Trusted Launch is to use Kusto Query to list VMs that have it disabled. Run this
resources
| where type =~ "microsoft.compute/virtualmachines"
| extend TrustedLaunchEnabled = tostring(parse_json(tostring(properties)).securityProfile.securityType)
| where TrustedLaunchEnabled != "TrustedLaunch" or isnull(TrustedLaunchEnabled)Microsoft Defender for Cloud
Microsoft Defender for Cloud (MDC) assesses VMs that satisfy Trusted Launch requirements and issues following recommendations based on VM status:
- Guest attestation extension should be installed
- Secure Boot should be enabled
- vTPM should be enabled
- Virtual machines guest attestation status should be healthy (Boot Integrity monitoring)
- Linux virtual machines should use only signed and trusted boot components
- Linux virtual machines should enforce kernel module signature validation
And following alerts (dependent on Boot Integrity monitoring)
- Suspicious kernel module detected [seen multiple times]
- Attestation failed on your virtual machine
Summary
Trusted Launch can mitigate or prevent rootkit threats that could possible do very serious damage. Rootkit detection isn’t easy, but Trusted Launch can help us with that. Together with Azure Attestation service Trusted Launch enables better visibility into our boot integrity. Using Defender for Cloud we can monitor our Trusted Launch adoption and get alerts related to boot integrity anomalies. Best part is that it’s not an additionally licensed feature and you can benefit from it for free. If you have Generation 1 VMs, as part of your VMs lifecycle you should start replacing them with Generation 2 VMs that are Trusted Launch capable. I’d recommend customers* running VMs on Azure to explore their Trusted Launch readiness and plan how to move forward adopting this feature.
* Especially customers that are in specific industries or business sectors that might like public sector, government agencies, military, finance, health care sector, critical infrastructure etc.
Stay secure!
