A published application on Azure Virtual Desktop feels like a single program on a screen. It is a session on a domain-joined Windows machine sitting inside your network, and the question worth answering is what a user can reach once they stop using the application as intended. Breakout testing answers it, usually in less time than the deployment took.
How a breakout usually starts
The route out is almost always a dialog box. Any feature that opens a file, saves a report, prints to PDF or shows a help page can lead to a file browser, and a file browser reaches the whole disk. From there a tester looks for a way to launch something: right-clicking a script, typing a path into the address bar, or using an application’s own macro or scripting engine. Older line-of-business software is generous here. Once a command prompt or PowerShell session opens, the assessment stops being about the published application and starts being about the machine.
What the session host can see
The session host is a normal domain member, so everything an internal attacker would do becomes possible from inside a published app. That includes enumerating Active Directory, mapping file shares, and looking at what the host’s managed identity can reach in the tenant. Session hosts often hold more than they need: cached credentials from administrators who logged on to fix something, FSLogix profile shares with permissions set to allow more than the owning user, and local administrator rights granted to a support group that includes half the helpdesk. The NCSC’s cloud security principle on separation between users exists for this reason, and a shared session host is exactly where separation gets tested.
“Clients treat virtual desktop projects as an infrastructure exercise and forget they have created a room full of unattended domain-joined machines that anyone with a password can sit at. We book these as internal tests starting from a standard user session, and the results read like an internal network report, because that is what it is.”
William Fieldhouse, Director, Aardwolf Security Ltd
Controls that hold up under testing
Application control is the control that works, and it needs to be in enforcement rather than audit. Windows Defender Application Control or AppLocker, configured to allow only signed and approved binaries, stops most breakout chains at the point where the tester tries to run something. Add constrained language mode for PowerShell, remove local administrator rights from ordinary support staff, and disable clipboard and drive redirection unless the business genuinely needs them. Check host configuration rather than the policy document, since a policy applied to the wrong organisational unit is common and invisible until somebody tests it.
Where cloud and network testing meet
Scope this work as both a cloud and an internal engagement, because the findings land in both places. An Azure penetration test covers the tenant side: who can add session hosts, what the host identity can read, whether Conditional Access requires compliant devices for the client connecting in. Internal network penetration testing services cover what happens after the breakout, which is the part that leads to domain credentials. Booking them separately usually means each tester stops at a boundary the attacker will walk straight through.
Frequently asked questions about virtual desktop security
These questions come up when a virtual desktop rollout reaches its security review.
Does multi-session Windows change the risk?
It raises it. Several users share one host, so a weakness in isolation between sessions affects everyone on that machine, and cached artefacts from one user can be visible to the next.
Is a published app safer than a full desktop?
Only if breakout is prevented properly. Publishing a single application narrows the intended surface and does nothing about file dialogs, so treat it as a convenience feature rather than a security boundary.
