Cloud forensics: Forensic readiness and incident response in Azure Virtual Desktop

Co-authors: Dan Weinstock and Christoph Dreymann

Azure Virtual Desktop (AVD) has rapidly become a core tool for enabling remote work at scale. Consequently, it’s also emerging as a target for threat actors. Recent Microsoft Incident Response engagements show that threat actors are exploiting AVD deployments for lateral movement and persistence. By hijacking legitimate AVD user accounts, they gain what is essentially a trusted “endpoint” inside the network without having to install malware.

Why does this matter to incident responders?

AVD intrusions can be stealthy and fast-moving, and responders must be prepared to detect and investigate suspicious AVD usage quickly. AVD’s architecture is not the same as a typical endpoint or server, so traditional forensic approaches alone may fall short.

This blog post focuses on how to build forensic readiness in AVD and outlines investigation strategies to handle AVD-related incidents. We’ll cover the unique forensic challenges AVD presents, methods to collect critical data and best practices to allow incident responders to approach AVD investigation with confidence.

Real-World Threat Actor Behaviors in AVD

To put theory into context, consider some real threat actor behaviors Microsoft Incident Response – the Detection and Response Team (DART) has observed in AVD environments:

• Threat actors used stolen helpdesk credentials with AVD access to log in from a foreign IP address.
• In another case, threat actors compromised identities, leveraged their AVD sessions to pivot into on-premises resources using the AVD Virtual Machine (VM) as a steppingstone to RDP into other machines for lateral movement.
• Another threat actor accessed the browser in AVD to search internal SharePoint sites for sensitive data and intellectual property.

Once threat actors hijack a legitimate, often poorly monitored AVD session, they gain a privileged execution environment without needing to deploy traditional malware.

This enables threat actors to perform identity discovery, pivot across cloud/on-premises boundaries, exfiltrate data, and stage ransomware operations, emphasizing the necessity for robust logging, monitoring, and least-privilege configurations in virtual desktop environments.

Forensic Challenges Unique to AVD

Incident responders should enable forensic readiness by combining cloud-native and traditional methods to investigate, enable core logs for visibility, and understand how profiles are distributed across VMs and remote storage.

AVD from the lens of a Threat Hunter

An understanding of AVD architecture is essential for detection and response. AVD’s distinctive management of user sessions, profiles, and application delivery presents specific benefits and complexities when monitoring adversary activity. The system has the following fundamental components:

• Session Hosts – AVD’s multi-session architecture allows multiple users (or threat actors) to share a single underlying VM. Because these hosts are often ephemeral – frequently spun up and deallocated – offline evidence such as event logs or memory artifact can be lost quickly without proactive collection. When FSLogix is in use, user profiles are stored as VHDs in remote storage, rather than on the session host; browsing history, downloads, registry hives (i.e., NTUSER.DAT), MRU lists, and startup files live in these offloaded containers.
• Workspaces, Application Groups, & Host pools
  • Workspaces serve as the top-level container, grouping resources and providing users with a single-entry point to their virtual desktops and applications.
  • Application Groups determine which apps or desktops are published and define who can access them, shaping both user experience and permissions.
  • Host Pools, on the other hand, are collections of session hosts – virtual machines that supply the compute power needed for user sessions.
• Azure Storage Accounts & FSLogix VHDs – because FSLogix stores each user’s profile as a VHD or VHDX file on Azure Files or a similar storage solution, investigators must know how to identify and export these VHDs and analyze them using tools like Autopsy or Eric Zimmerman’s utilities to recover user-centric artifact (i.e., browser history, downloads, NTUSER.DAT registry hives). This process is crucial when FSLogix is enabled, as no user data remains on the AVD host after logout.

Figure 1: AVD Components

The following illustration demonstrates the relationship between the key components discussed above:

 

Figure 2: Relationships between key components

Further information on that can be found within Azure Virtual Desktop for the enterprise - Azure Architecture Center.

This clarifies that AVD is not simply "another VM"; rather, it is an Infrastructure-as-a-Service (IaaS) offering with a corresponding shared responsibility model, in which customers are accountable for identity management and the deployment of individual Azure resources.

Logging Considerations

Many actions such as user session brokering and application publishing are logged not on the VM but in Azure – if logging is enabled. By default, Azure Monitor diagnostics logs for AVD are not turned on. If an organization hasn’t enabled these, responders may lack crucial logs like when sessions started/ended, which applications were opened, or from what client IP address. Entra ID handles AVD authentication and therefore, Entra ID sign-in logs will provide further details and should be retained appropriately as well.

Forensics implication: Misconfigured or missing diagnostic settings can hide evidence.

Log sources

The following table outlines various sources that provide comprehensive insights in the event of an incident:

* Onboard non-persistent virtual desktop infrastructure (VDI) devices - Microsoft Defender for Endpoint | Microsoft Learn

 

Enabling diagnostic logs

Enabling diagnostic logs in AVD Azure resources offers valuable insights into session activities and remote application usage for detecting anomalies, tracing threat actor activity, and supporting forensic investigations. For threat hunting, the most relevant log tables include:

• WVDFeeds – shows which published applications were available, including ClientIP and ClientType details.
• WVDConnections – lists information such as Client IP address, clientType, ConnectionType, ResourceAlias, and host connection data.
• WVDCheckpoints – indicates which published application was accessed and supplies its execution path.

You can enable these logs via the diagnostics settings for Host Pool, Application Group, and Workspace Azure resources. If an incident occurs, these logs help determine exactly what a threat actor interacted with, which is vital for assessing whether additional logs should be collected.

 

Figure 3: Diagnostic log examples

Forensic Data Collection Strategies

When an incident is suspected in an AVD environment, investigators need a plan for acquiring and preserving evidence:

• Live vs. Offline Collection – disk and memory artifact can be captured either from a running system or from an offline snapshot. Live collection can recover volatile data like memory (RAM) but might miss user profile content when FSLogix is in use. In such cases, focus on offline acquisition by generating a snapshot of the relevant disk or file share and downloading the associated VHD. For live or offline captures, you can leverage widely used forensic tools such as Velociraptor (for remote collection across endpoints) or disk forensics tools like Autopsy to extract and analyze forensic data.
• Disk Snapshots – to acquire disks for offline collection and analysis, create a snapshot of the AVD Host VM disk and export it to your designated collection and analysis environment. The high-level steps are captured here.
• Storage account VHD Extraction – if FSLogix is enabled, user profiles are stored as VHD containers in Azure Storage. To review user data such as browser history, downloads, NTUSER.DAT, MRU lists, startup folders, and other profile artifacts you have to download the VHD that matches the username within the Azure Storage account. More about Storage account forensics can be found within Cloud forensics: Why enabling Microsoft Azure Storage Account logs matters.

Figure 4: File share

Artifact Analysis: What to Look for on a Host

Once the user’s profile VHD and VM Host disk snapshot are acquired, analysts should focus on:

• Browser Data – cached web history, downloads, and session cookies can reveal malicious downloads or credential collection attempts. Threat actors frequently exploit post-breach browser access to scrape credentials, hijack sessions, or implant malicious extensions.
• User Registry Hives – files like NTUSER.DAT contain valuable user-specific configuration settings and MRU (Most Recently Used) lists that can reveal executed commands or opened documents.
• Startup Items and Temporary Directories – malicious payloads or scripts often persist by storing components in startup folders or system temp directories. These may be visible only within the user VHD if FSLogix is in use.
• Jump Lists and Shell Bags – these systems cache file access and folder navigation actions, offering timelines and insights into threat actoractivities.

Threat Hunting in AVD Environments

Threat hunting in AVD environments requires three critical dimensions: Identity, Azure platform, and host/endpoint artifact. Each layer provides unique signals and telemetry that, when correlated, help uncover malicious activity and reduce dwell time.

• Identity – investigate authentication patterns, privilege escalations, and anomalous sign-ins across Entra ID and related identity providers.
• Azure – examine control-plane operations, resource configurations, and subscription-level activities for indicators of compromise or persistence mechanisms.
• Host/Endpoint Artifacts – analyze session hosts for forensic traces such as browser history, file events, and registry changes that may reveal lateral movement or payload deployment.

By combining insights from these components, defenders can build a threat-hunting strategy tailored for AVD’s distributed architecture.

 

Figure 5: Threat hunting in AVD

Core Hunting Objectives

When hunting in AVD environments, start with three fundamental questions:

• Where did the threat actor log in from? – identify unusual or foreign IP addresses and devices accessing your host pools.
• What did they do once inside? – track actions within the session host, such as which applications were launched, commands executed, or files accessed.
• Where did they go next? – look for lateral movement to other resources (cloud or on-premises) and evidence of persistence (i.e., credential artifacts, backdoor accounts).

These questions form the basis for iterative, hypothesis-driven hunts, allowing you to “follow the thread” and adapt as you uncover new evidence – be it new accounts, unexpected machines, or suspicious process trees.

The following diagram illustrates a standard hunting process from the initial event through hunting within the entire environment and cross-domain correlation:

 

Figure 6: Investigation Analysis Pathway

Today’s security tools can make this process easier. Microsoft Sentinel combines Entra ID logs, AVD diagnostics, and MDE events into one place, so you can use KQL queries and workbooks to link related data, like joining Sign-in Logs and WVDConnections using the same user and timestamp.

With MDE’s Advanced Hunting feature, you can query across endpoints; for example, you might review all AVD host devices for certain indicators or activity patterns, such as listing processes that ran during a suspected breach. The aim is to build a complete picture of the incident.

Sample Hunting Queries

Below are example Sentinel queries tailored to address the core hunting objectives. These should be adapted to your environment and replace dummy values with real user names, host identifiers, or IP ranges.

Where did the threat actor log in from?

Hunt for the suspicious user in the Entra Sign-in logs:

SigninLogs
| where TimeGenerated >= ago(7d) //update to reflect specific time period of interest
| where UserPrincipalName has "<<Suspicious User>>"
| where AppDisplayName has "Azure Virtual Desktop
| project-reorder TimeGenerated, UserPrincipalName, AppDisplayName, ResultType, ClientAppUsed, DeviceDetail, IPAddress, UserAgent
| summarize FirstDate=min(TimeGenerated), LastDate=max(TimeGenerated), count() by  UserPrincipalName, AppDisplayName, ClientAppUsed, IPAddress, UserAgent

Sign-in events to AVD always use the below Entra Applications. Both the application name and ID can be hunted on:

 

Figure 7: AVD Entra Application IDs

What did they do once inside?

To investigate a potential security incident within AVD, it is important to review the user activity within the diagnostic logs. Therefore, we are looking next into the diagnostic logs tables WVDFeeds, WVDConnections, and WVDCheckpoints to get a better understanding of what has happened:

WVDFeeds

Displays the published applications that are accessible, as well as the ClientIP and ClientType information.

WVDFeeds
| where TimeGenerated >= ago(7d) //update to reflect specific time period of interest
| where UserName has <<UserName>>
//splitting the IP as the ClientIP is shown with port i.e. 1.1.1.1:54282
| extend ClientIP = tostring(split(ClientSideIPAddress, ":")[0])
| summarize FirstDate = min(TimeGenerated), LastDate = max(TimeGenerated), count() by UserName, ClientOS, ClientType, ClientIP

 

WVDConnections

Displays the Client IP address, client type, connection type (Desktop or App), resource alias, and the host (from the host pool) to which the client has connected.

WVDConnections
| where TimeGenerated >= ago(7d) //update to reflect specific time period of interest
| where UserName has <<UserName>>
| project-reorder TimeGenerated, UserName,ClientSideIPAddress, ClientOS, ConnectionType, SessionHostName, SessionHostPoolType, State
| sort by TimeGenerated asc

 

WVDCheckpoints

Determine which published application was utilized. It shows also the Operation conducted when a session was started.

WVDCheckpoints
| where TimeGenerated >= ago(7d) //update to reflect specific time period of interest
| extend ConnectionStage = tostring(Parameters.connectionStage)
| extend AppFileName = tostring(Parameters.filename) //It is only populated when it published App and not Desktop Session
| extend Operation= Name
| project-reorder TimeGenerated, UserName, ActivityType, Source, Operation, AppFileName, ConnectionStage

 

Advanced Hunting in Microsoft Defender for Endpoint

Now that the AVD host has been identified, you can then deep dive further by focusing on EDR and host forensic logs. If MDE Advanced Hunting is enabled, the following tables helps often to understand what happened on a system:

• DeviceNetworkEvents
• DeviceProcessEvents
• DeviceRegistryEvents

Further tables within MDE and the Device Timeline help to get a full picture of what happened.

Lateral Movement

After gaining access to an AVD session host, threat actors often attempt lateral movement to expand their foothold or establish persistence. This can involve pivoting to other session hosts, Azure resources, or even on-premises systems.

Focus on the following tables/log sources:

• Firewall logs (On premise / Cloud)
• DeviceNetworkEvents (Cloud: Defender)
• DeviceProcessEvents (Cloud: Defender)
• DeviceRegistryEvents (Cloud: Defender)
• NSG logs (Diagnostic Logs)
• Windows EventsLogs (Collected host logs)

Best Practices for AVD Forensic Readiness

The following measures enhance forensic processes for Azure Virtual Desktop:

• Implement an endpoint detection and response product – deploy an endpoint detection and response (EDR) solution to provide advanced detection and response capabilities on AVD VMs.
• Enable and export comprehensive logging – activate diagnostic logging for all host pools, workspaces, and application groups. Ensure these logs are exported to a Log Analytics workspace or a security information and event management (SIEM) platform such as Microsoft Sentinel.
• Develop forensic workflows for AVD – establish and document clear forensic workflows for AVD incident response. This should cover the entire process, from detecting suspicious activity, through live or offline evidence acquisition, to verifying FSLogix profile stores, exporting VHDs, and analyzing collected artifacts.

Security Recommendations for Azure Virtual Desktop

When implementing AVD, it is vital to follow recommended security practices. These strategies complement the best practices for forensic readiness and ensure that both proactive and reactive security measures are in place.

• Review Microsoft AVD Security Guidance – utilize the official Microsoft documentation for Azure Virtual Desktop security to guide your deployment and operational security policies. The resource provides up-to-date recommendations on securing your AVD environment.

• Enable MFA on all users – implement multi-factor authentication (MFA) for every user accessing Azure Virtual Desktop to ensure an additional layer of security beyond just passwords.
  • Where possible, implement phish-resistant MFA for maximum protection. If full adoption isn’t practical, prioritize high-risk accounts and critical roles first.

• Enable Conditional Access – utilize Conditional Access policies to proactively manage and mitigate risks before granting access to your AVD environment. This helps ensure only legitimate users and trusted devices can connect to your resources.
  • Regularly review Conditional Access policies for exceptions and minimize them wherever possible. Implement detection and alerting for any changes to CAP configurations to maintain a strong security posture.

More information can be found in the following article from Microsoft - Security recommendations for Azure Virtual Desktop - Azure Virtual Desktop | Microsoft Learn

Conclusion

As the threat landscape evolves, cloud-hosted virtual desktops become both enablers of productivity and channels for threat actor persistence. By applying robust logging configurations, understanding the unique forensic challenges of FSLogix and AVD, and enhancing your threat hunting capabilities, you can achieve higher levels of forensic readiness. This preparedness not only accelerates investigations when incidents occur but also strengthens the overall security posture of your organization. Proactive planning today is essential to respond to tomorrow’s threats with confidence and clarity.