A compromised virtual desktop platform hands an attacker the front door, the golden image every user boots from, and the service accounts that tie the whole estate to your directory and hypervisors. This playbook covers what to do when the broker, gateway, session hosts, image pipeline or management plane of a virtual desktop infrastructure (VDI) or desktop-as-a-service (DaaS) platform is suspected or confirmed compromised. It is vendor-neutral and built on common architecture, NIST guidance and the Five Eyes joint advisory on incident handling. It is written for incident responders, infrastructure engineers and identity teams who have to contain the platform without stranding thousands of remote workers. Hardening the platform before an incident is covered separately in Securing the VDI and DaaS itself.
Key takeaways
- Scope before you reset. The attacker almost certainly holds more than one credential, so a hasty password change on one account tips them off without removing them.
- Treat the golden image as evidence and as a suspect. If the image or its build pipeline was touched, every non-persistent desktop rebuilt from it re-infects itself at the next logon.
- The service accounts matter most. Broker to hypervisor, broker to directory and image-build accounts usually hold more privilege than any single user session.
- Contain at the gateway first. Cutting or narrowing external access, and ending active sessions, buys time without destroying the session hosts you need to examine.
- Rebuild the control plane, not just the desktops. Recovery means a new broker and gateway from known-good media, new secrets and certificates, and a re-validated image before users return.
Why a VDI compromise is different
NIST SP 800-46 Rev. 2 groups VDI with portals and terminal servers: application software runs on servers you own, and with non-persistent VDI the virtual image is discarded after each session so the next user gets a clean desktop. That design is the reason VDI is used for contractors and unmanaged devices, and it is also why a platform compromise spreads quickly. The same guidance warns that a compromised remote access server can eavesdrop on and manipulate traffic, and can act as a jumping-off point for attacks on other internal hosts.
A VDI or DaaS platform is several systems with different trust levels. Each one needs its own containment decision.
| Component | What it holds or can do | Why compromise matters |
|---|---|---|
| External gateway | Terminates user connections from the internet, often with single sign-on and MFA in front | Session tokens and credentials pass through it; a gateway flaw can expose live sessions (ATT&CK T1133, T1539) |
| Connection broker | Maps users to pools, holds service credentials for the directory and hypervisor | Control of the broker means control of who lands where, and the ability to publish desktops to new users |
| Session hosts and desktops | Run user sessions, shared memory space on multi-session hosts | Multi-session hosts expose one user's session to another; RDP session hijacking (T1563.002) is possible with local admin |
| Golden image and build pipeline | The template for every non-persistent desktop | Persistence placed in the image (comparable to T1525 Implant Internal Image) returns after every rebuild |
| Profile and user data store | Roaming profiles, containers, browser data, cached tokens | Browser cookies and saved credentials for SaaS apps sit here and survive desktop resets |
| Hypervisor and management plane | Creates, snapshots and deletes virtual machines | Management access lets an attacker clone desktops, read memory snapshots or destroy the estate |
| Machine and service identities | Computer accounts for pooled desktops, broker and provisioning service accounts, API keys for DaaS management | Long-lived, rarely reviewed, often over-privileged; see the Service Account Security Guide |
How the compromise shows up
VDI incidents are often first reported as something else. These signals should open this playbook rather than a routine ticket.
| Signal | Where to look | What it may mean |
|---|---|---|
| Vendor or government advisory for your gateway or broker, with active exploitation | CISA Known Exploited Vulnerabilities catalogue, vendor security bulletins | Assume compromise if you were exposed and unpatched during the exploitation window |
| Sessions from new countries, hosting providers or impossible travel, with valid MFA | Gateway and IdP sign-in logs | Stolen session tokens replayed (T1550.004) or MFA bypass |
| New or changed pool assignments, published applications or entitlements | Broker administrative audit log | Attacker granting themselves or a helper account access |
| Image version changed outside the change window, or unknown snapshot | Image pipeline history, hypervisor tasks and events | Image tampering for persistence |
| Interactive logon by a broker or provisioning service account | Directory domain controller logs, hypervisor management logs | Service credential stolen and reused (T1078) |
| Session host processes attaching to other users' sessions | EDR on session hosts | RDP session hijacking on multi-session hosts |
| Unexpected files in the gateway web root or new modules on the broker | File integrity monitoring, EDR, appliance integrity checks | Web shell or implant (T1505.003) that will survive a password reset |
Triage questions for the first hour
- Which tier is involved? Gateway only, broker, session hosts, image pipeline, hypervisor management, or several. The answer decides whether containment is a firewall change or a platform rebuild.
- Is the platform self-hosted or a DaaS service? With DaaS, the provider controls the control plane: open a case at once, ask for their logs and their view of tenant activity, and confirm which credentials (tenant admin, API keys, directory connector accounts) you own and must rotate.
- Which identities could the attacker have used? List user sessions on affected hosts, administrators of the broker and hypervisor, and every service account the platform holds.
- Was the golden image or its pipeline reachable? If yes, every desktop built since the earliest suspicious time is untrusted.
- What else trusts the platform? Firewall rules that allow VDI subnets to reach finance systems, OT jump hosts or admin consoles define your blast radius.
- Who must keep working? Identify critical user groups (clinical, contact centre, contractors) so containment can give them a clean alternative path.
Containment by priority
The Five Eyes joint advisory on uncovering and remediating malicious activity warns against mitigating affected systems before responders have protected data, against preemptive credential resets, and against communicating over the compromised network. Containment should therefore be staged and coordinated out of band.
- Open an out-of-band channel. Do not coordinate through chat or email reachable from the VDI estate, especially if administrators use VDI desktops to manage it.
- Preserve volatile evidence first. Snapshot memory and disk of the gateway, broker and a sample of affected session hosts before rebooting or reimaging. On hypervisors, take snapshots that include memory where the platform supports it, and export them off the management plane.
- Restrict the front door. Narrow the gateway to known corporate ranges, or move to an alternative access path, and place the gateway behind an extra authentication layer if that can be done without reboot. Patch or apply the vendor mitigation if a known flaw is involved, noting that patching does not remove sessions or implants already in place.
- Invalidate sessions in a single coordinated action. End all active gateway sessions, revoke refresh tokens at the IdP for affected users, and clear the gateway session cache. Do it in the same window as credential rotation so the attacker cannot simply log on again.
- Freeze the image pipeline. Stop scheduled image updates and pool recomposition; disable publishing of new desktops except from a known-good image.
- Isolate the management plane. Restrict hypervisor and broker management interfaces to a privileged access workstation path and disable remote management from VDI subnets.
- Tighten egress from VDI subnets. Limit east-west reach to the minimum users need while the investigation runs. See the Zero Trust Network Segmentation Playbook for Flat Networks.
Credential rotation order
Rotate in an order that removes the attacker's most privileged foothold first, and only once you have scoped which credentials exist. Rotating a user password while a broker service account remains stolen achieves little.
| Order | Credential | Action | Watch for |
|---|---|---|---|
| 1 | Hypervisor and management plane administrators, DaaS tenant administrators | Reset, re-enrol phishing-resistant MFA, remove unknown admins, review role assignments | Admin accounts created during the incident (T1098) |
| 2 | Broker to directory and broker to hypervisor service accounts, DaaS API keys and directory connector accounts | Create new accounts or keys, update the platform, then disable the old ones | Outages if old secrets are disabled before the platform picks up new ones |
| 3 | Gateway and broker TLS certificates and private keys, SAML signing and federation trust | Reissue from your CA, revoke old certificates, update relying party trust | Keys exported from a compromised appliance remain valid until revoked |
| 4 | Image build and deployment accounts, local administrator in the image | Rotate, and use per-machine local admin passwords rather than one shared value | Shared local admin baked into the image across all desktops |
| 5 | Users with sessions on affected hosts | Reset passwords, revoke tokens, re-register MFA where tampering is possible | Saved browser passwords and SaaS cookies in the profile store |
| 6 | Computer accounts of pooled desktops | Delete and recreate during rebuild rather than reset in place | Stale computer objects left enabled in the directory |
If a directory administrator logged on to a compromised session host, treat the directory itself as in scope and move to the Active Directory Domain Compromise Response Playbook. If federation trust or the IdP tenant was changed, use the Identity Provider Tenant Compromise Playbook.
Eradication and rebuild
- Gateway and broker: Do not clean an appliance in place. Deploy new instances from verified vendor media at the patched version, restore only reviewed configuration (exported as text and diffed against a pre-incident copy), and bind new certificates and secrets.
- Golden image: Rebuild the image from source media and your documented build steps, not from the last image. Compare the rebuilt image against the suspect one to learn what the attacker changed. See the Server Build and Golden Image Hardening Guide.
- Session hosts: Destroy and recreate all hosts in affected pools from the new image. For persistent desktops, decide per desktop: rebuild and migrate user data after scanning, or reimage outright.
- Profile store: Scan profiles for planted executables, startup items and scheduled tasks. Consider resetting browser data for affected users, because cookies and saved credentials survive a desktop rebuild.
- Hypervisor hosts: If the management plane was accessed, check for unknown virtual machines, snapshots and exported disks, and rebuild hosts from vendor media where integrity is in doubt. NIST SP 800-125A Rev. 1 describes the hypervisor functions (resource mediation, VM isolation, virtual networking) whose integrity you are restoring.
- DaaS: Work through the provider. Ask for confirmation of control plane integrity, a list of tenant-level changes, and whether provider-side keys were exposed.
Recovery and validation
- Pilot ring: Restore access for a small group of IT staff on the rebuilt platform, with enhanced logging, for at least one working day.
- Validate: Confirm image hash and version, check that old certificates and service secrets fail, run EDR scans on new hosts, and confirm no unknown admins or published resources exist.
- Staged return: Reopen access by user group, critical workers first, with MFA re-registration enforced where tampering was possible.
- Rollback plan: Keep the alternative access path available until the rebuilt platform has run cleanly for an agreed period. Never roll back to the suspect image or appliances; rollback means falling back to the alternative path.
- Heightened monitoring: Keep tighter alert thresholds on gateway logons, broker admin changes and service account use for at least 30 days.
Evidence to preserve
- Gateway: Access and authentication logs, session cache or token logs, web root file listings with hashes, configuration exports, memory capture.
- Broker: Administrative audit log, pool and entitlement history, service account usage, configuration database backup.
- Session hosts: Windows Security log (logon events such as 4624 with logon type 10 for remote interactive), RDP session connect and reconnect records, EDR telemetry, and the artefacts listed in the joint advisory: running processes, run keys, scheduled tasks, listening ports.
- Image pipeline: Every image version since the earliest suspicious time, build logs and who triggered them.
- Hypervisor: Task and event history, snapshots, exported disks.
The joint advisory recommends keeping logs for at least one year; check your retention before you need it. Record chain of custody for every image and snapshot, as described in the Evidence Handling and Chain of Custody Guide.
Notification triggers
A VDI compromise often means unauthorised access to whatever data users opened in their sessions. Under UK and EU GDPR Article 33, a personal data breach must be reported to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless it is unlikely to result in a risk to individuals. Essential and important entities under NIS2 have an early warning duty within 24 hours of becoming aware of a significant incident. Sector rules (financial services, health) and contracts with customers may set shorter deadlines. Involve legal counsel early and record when you became aware.
Detection and measurement
- Time to end all sessions: minutes from decision to every gateway session terminated and tokens revoked.
- Service credential coverage: percentage of platform service accounts and API keys rotated, against an inventory taken before the incident.
- Image integrity: percentage of running desktops on the validated image version, target 100% before full reopening.
- Admin change alerting: share of broker and hypervisor admin changes that raise an alert within 15 minutes.
- Exercise frequency: at least one tabletop or technical exercise of this playbook per year, including rebuild of a pool from source.
Framework mapping
| Activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | MITRE ATT&CK |
|---|---|---|---|
| Triage and scoping | RS.MA-02, RS.AN-03 | IR-4, IR-5 | T1133, T1078 |
| Containment and session invalidation | RS.MI-01 | IR-4, AC-17 | T1539, T1550.004, T1563.002 |
| Credential and certificate rotation | PR.AA-01 | IA-5, SC-12, AC-2 | T1098 |
| Image rebuild and eradication | RS.MI-02 | CM-2, CM-3 | T1525, T1505.003 |
| Recovery from verified assets | RC.RP-01, RC.RP-03 | CP-10, CP-9 | n/a |
| Monitoring and reporting | DE.CM-01 | SI-4, AU-6, IR-6 | n/a |
Common failure patterns
- Patching and declaring victory. Gateway flaws that leak session tokens leave attackers with valid sessions after the patch; the 2023 session token theft campaign against remote access gateways showed that sessions had to be killed as well as the flaw fixed.
- A remote access login without MFA. The Change Healthcare breach began with a remote access portal that accepted a password alone; rebuilds that restore old exceptions repeat the mistake.
- Recomposing pools from the suspect image. Teams reset every desktop to the same tampered template and assume they are clean.
- Forgetting the service accounts. User passwords are reset, while the broker's directory account and the DaaS API key stay valid.
- Ignoring the profile store. Cookies and saved credentials for SaaS apps survive the rebuild and keep cloud access open.
- Managing the incident from VDI desktops. Responders use the compromised platform to coordinate and administer, and the attacker watches.
Practitioner checklist
- Keep an inventory of every VDI service account, API key, certificate and admin role, with owners.
- Pre-agree an alternative access path for critical users that does not depend on the VDI platform.
- Store golden image build steps and source media so the image can be rebuilt without the last image.
- Export broker and gateway configuration regularly as text, and keep it off the platform.
- Confirm you can end all sessions and revoke tokens at the gateway and IdP in one action.
- Forward gateway, broker, hypervisor and session host logs to a SIEM outside the platform, retained for at least one year.
- Agree with your DaaS provider, in the contract, what logs and incident support you get.
- Run this playbook as an exercise at least once a year, including a pool rebuild.
Standards and references
- NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
- NIST: SP 800-46 Rev. 2, Guide to Enterprise Telework, Remote Access, and BYOD Security
- NIST: SP 800-125A Rev. 1, Security Recommendations for Server-based Hypervisor Platforms
- Canadian Centre for Cyber Security with CISA, NCSC and partners: Technical Approaches to Uncovering and Remediating Malicious Activity
- NIST: SP 800-53 Rev. 5
- NIST: Cybersecurity Framework 2.0
- MITRE ATT&CK: RDP Hijacking
- CISA: Known Exploited Vulnerabilities Catalog
Related NHI Mgmt Group resources: Virtual Desktop (VDI) and DaaS Security Guide · Securing the VDI and DaaS itself · Session Hijacking and Cookie Theft Guide · Network Rebuild After Compromise Playbook