How to rehearse machine isolation and remediation before a real incident forces you to learn it.

Most security teams never run machine isolation in anger until the day they have to, and that is the worst possible moment to learn it. The buttons are unfamiliar, the device drops off the network, and everyone is watching. This series removes that risk by rehearsing the whole flow in a safe lab, end to end, so the real thing is muscle memory.

Across four parts we onboard a test device, generate a clean incident, isolate the machine, remediate it through Live Response, and then recover a device that has locked everyone out:

• Part 1 – Building the lab (this post)
• Part 2 – Generating a clean incident
• Part 3 – Isolation and remediation through Live Response
• Part 4 – Recovering a device locked out of RDP

Everything runs in a dedicated lab tenant. The KQL queries and PowerShell scripts are in a companion repository, linked at the end.

The lab

The lab is a single Azure-hosted Windows 11 virtual machine, Entra joined, managed by Intune, and onboarded to Microsoft Defender for Endpoint. One VM is enough to show every response action in the series.

Hosting it in Azure matters later. When a device is isolated it keeps only its connection to the Defender service, so Remote Desktop and Bastion both drop. Azure still gives us an out-of-band way to see the machine, which an on-premises laptop would not have. We enable that view below, before we need it.

Licensing

Live Response, device isolation and the full set of response actions require Microsoft Defender for Endpoint Plan 2, which is included in Microsoft 365 E5. Plan 1 covers isolation and an antivirus scan, but not Live Response.

Confirm the exact licence SKU in your own tenant before publishing.

Turning on the response features

The response features live under Settings > Endpoints > Advanced features. Four settings matter for this series.

• Live Response – the remote shell from the Defender portal to the device. Required for everything in Parts 3 and 4.
• Live Response for Servers – only needed for server operating systems. A Windows 11 client does not need it.
• Live Response unsigned script execution – allows unsigned scripts to run from the library. Convenient in a lab, but signing your scripts and leaving this off is the better habit, and it is the approach the companion repo is built for.

Tamper protection should be on. It stops malicious apps turning off core Defender features. It is worth knowing its limits now, because they shape Part 4: tamper protection guards virus and threat protection, real-time protection and behaviour monitoring. It does not guard the Windows Firewall or the Remote Desktop registry settings that we deliberately break later.

One newer setting is worth noting: Isolation Exclusion Rules, off by default, lets you name IP addresses, processes or services that stay reachable while a device is isolated. We leave it off for a true isolation.

Role-based access

Live Response is gated by role. Basic permissions allow the read-only commands, such as listing processes, services and registry values. Advanced permissions allow run, putfile and remediate, which are the commands that actually change the device. Assign the advanced role to whoever will perform the remediation.

Preparing an out-of-band view

Because isolation cuts Remote Desktop, set up an out-of-band view of the VM before you need it. Two Azure features cover this.

Boot diagnostics

Boot diagnostics gives you a console screenshot of the VM even when the network is cut:

• Azure portal > the VM > Help > Boot diagnostics > Settings
• Choose Enable with managed storage account (recommended), then Save
• The Screenshot tab then shows a live console image on demand

Serial console (optional)

The serial console gives an interactive text session and needs boot diagnostics plus SAC/EMS. On Windows client editions, enable EMS first:

bcdedit /ems {current} on
bcdedit /emssettings EMSPORT:1 EMSBAUDRATE:115200
# then reboot

After the reboot, the VM > Help > Serial console gives a text console you can reach even with RDP blocked. For most of this series the boot diagnostics screenshot is enough, so treat the serial console as an advanced option.

Verify the serial console steps in your own tenant, and blur the subscription name and ID on any Azure screenshots.

Confirming the sensor is reporting

Before relying on the device, confirm it is actually talking to Defender. On the VM, the Sense and DiagTrack services should both be Running, and the onboarding state should be 1:

Get-Service Sense, DiagTrack | Format-Table Name, Status, StartType
(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status').OnboardingState

The definitive test is a Live Response session. From the device page, choose the actions menu and Initiate Live Response session.

A session that connects, with an empty library, confirms the cloud channel works end to end. The device can show as Inactive in the portal for a while after a reboot, so a working Live Response session is a more reliable signal than the health state.

The companion repository

The KQL queries and PowerShell scripts for the series are in a public repository:

github.com/cloud-secure-ai/mde-isolation-live-response-lab

Next

With the lab onboarded and the response features on, Part 2 generates a clean, reproducible incident on the device, without running any real malware.

Raising a genuine Defender alert and incident on the lab device, without real malware.

With the lab onboarded, we need something for Defender to react to: an alert and an incident we can isolate on in Part 3. The trick is to generate a real detection that is also safe and repeatable.

Why not just run Mimikatz

The obvious move is to run a real tool such as Mimikatz. In practice that is awkward and beside the point. Defender does its job and quarantines the tool before it runs, so the session turns into a fight with your own defences instead of a demonstration of the response. Anyone who has tried to run an attack simulation on a protected machine knows the feeling.

For a repeatable walkthrough, and for anyone following along at home, benign and purpose-built triggers are the professional choice. We use two. The EICAR test file is the industry-standard string that every antivirus engine recognises as a test. Microsoft also publishes an endpoint detection test, a benign download-and-execute pattern that raises an EDR alert. Both produce a genuine alert and incident, and neither involves real malware.

The detection script

Invoke-DetectionTest.ps1, in the companion repo, does two things: it writes the EICAR string (assembled at runtime, so the script file itself is not quarantined) and it runs Microsoft documented detection test. Run it from an elevated PowerShell session on the lab VM.

# writes the EICAR test file, then runs the Microsoft detection test
.\Invoke-DetectionTest.ps1

When nothing fires

On the first run the EICAR file wrote to disk and nothing happened, which is worth dwelling on because it is exactly the situation a responder meets in the field. Real-time protection was on, confirmed on all four counts:

Get-MpComputerStatus | Format-List RealTimeProtectionEnabled, `
  BehaviorMonitorEnabled, IoavProtectionEnabled, OnAccessProtectionEnabled
# all True

Two things explained it. The PowerShell session was not elevated, so the exclusions could not even be read (“Must be an administrator to view exclusions”), a reminder to triage from an elevated session. And an on-demand scan caught the file immediately:

Start-MpScan -ScanType CustomScan -ScanPath 'C:\sim'
# Threats found - EICAR_Test_File quarantined

The wider lesson is the one every responder learns the hard way: a forgotten exclusion, or a quiet gap in coverage, is exactly why a real threat sometimes never raises an alert. Checking Get-MpPreference exclusions belongs in your triage, not just your lab notes.

Re-running the test for this post hit the same trap. C:\sim had been added as an exclusion during the credential theft work and was never removed, so the EICAR file sat on disk untouched. Removing it with Remove-MpPreference -ExclusionPath ‘C:\sim’ brought back the toast and the quarantine straight away. Lab exclusions drift just like production ones – review them before you trust a quiet result.

The incident in the portal

Before the test, the device queue was clean, which makes the new detection easy to spot.

Within a minute the device carried a new alert and a new incident.

Defender correlated both triggers into a single incident, “EICAR_Test_File detected on one endpoint”, with two alerts (the EICAR detection and a suspicious PowerShell command line) and a full attack graph tying the device, the user, the test file and the processes together. That correlation is the point: one benign script, one coherent incident to respond to.

Hunting the activity

The same story is available in Advanced hunting. The companion repo includes three queries for this stage: the alerts and their evidence, the antivirus detections, and the credential-theft-style command lines. Set the DeviceNameFilter at the top of each query and run them.

Next

We now have a genuine incident on a healthy, onboarded device. Part 3 isolates that device and remediates it through Live Response, and drops our Remote Desktop session in the process.

Containing a compromised device and remediating it over the one channel the attacker cannot touch.

Part 2 left us with a genuine incident on the lab device. Now we contain it. Device isolation is the response most teams have never actually run, and it is worth understanding what it does before you reach for it in anger.

Isolation is the attacker’s own tactic, turned around

Attackers routinely cut off normal access to a device – disabling Remote Desktop, changing firewall rules, locking out administrators – while they keep their own foothold through a channel nobody is watching. Device isolation is the defender doing exactly that to the attacker. It severs the device from the network so the attacker loses their path in, while the SOC keeps one privileged, out-of-band channel: Live Response. Part 4 shows the attacker’s version of this; here we do it deliberately.

Isolating the device

From the device page, choose Isolate device. Keep it a full isolation – do not tick “Allow Outlook, Teams and Skype”, which would leave those paths open. Add a comment for the audit trail and confirm.

The action moves from pending to completed, and the device carries an Isolated badge. From this point the device can only reach the Defender service.

Access goes dark

Being in Azure does not keep the device reachable. Within seconds of the isolation taking effect, the Remote Desktop session drops and will not reconnect. Bastion and every other inbound path go the same way.

This is where the out-of-band view set up in Part 1 earns its place. The Azure boot diagnostics screenshot shows the device is alive and running, just unreachable – which an on-premises laptop could never show you.

Insert your Azure boot diagnostics console screenshot here.

Investigating over the isolated channel

Isolation keeps the device connected to the Defender service, so a Live Response session still works. From the device page, start Live Response – it connects even though nothing else can reach the box.

The scripts staged to the library in Part 1 are ready to run. Get-DefenderDetectionSummary.ps1 pulls the device’s protection state and recent detections, including the one from Part 2, from a device with no other network path.

Get-RdpLockoutState.ps1 is worth running here too, because of what it does not find: no local blockers. The RDP failure is purely the network isolation, with nothing wrong on the device itself. Hold that thought – Part 4 is the mirror image.

Remediate, then release

Once the investigation is done and the device is clean, release it from the device actions menu with a comment. The network path returns and Remote Desktop reconnects. The whole arc – isolate, investigate over Live Response, release – takes minutes and never requires physical or network access to the machine.

Next

Part 4 turns this around: the attacker locks the device out of Remote Desktop locally, with the device still on the network, and we recover it over the same Live Response channel.

When the device is on the network but locked out locally, Live Response is the way back in.

Part 3 was the defender cutting a device off deliberately. Part 4 is the attacker’s version: blocking Remote Desktop on the device itself – firewall rules and a registry change – to lock administrators out while keeping their own foothold. The device stays on the network the whole time, which is exactly what makes Live Response the recovery route.

The lockout technique

Two changes lock a Windows device out of Remote Desktop:

• An inbound firewall rule blocking the RDP port.
• The fDenyTSConnections registry value set to 1, which disables Remote Desktop and tears down the listener.

Neither is covered by tamper protection. Tamper protection guards Defender’s own settings – virus and threat protection, real-time protection, behaviour monitoring – and not the Windows Firewall or the Remote Desktop registry. So a local administrator, or an attacker who has become one, can apply both with tamper protection fully on. The lab script Invoke-RdpLockoutSimulation.ps1 makes exactly these changes, and refuses to run without an explicit confirmation switch.

Insert your -WhatIf preview and the real lockout run from the VM here.

Running it from an elevated session enables the firewall, adds the block rule and sets fDenyTSConnections to 1. The Remote Desktop session drops on that last step.

The crucial difference from isolation

The device is not isolated. It is still on the network, still reporting to Defender – it is just locked out locally. The Defender sensor talks outbound to the service, which the inbound RDP block does not affect, so a Live Response session connects normally. That is the whole recovery route.

Finding the blockers

Get-RdpLockoutState.ps1 over Live Response now finds what it could not in Part 3. It reports the LAB-Block-RDP-Inbound firewall rule, that nothing is listening on the RDP port, and a clear count of local blockers pointing at the remediation script.

Recovering the device

Restore-RdpAccess.ps1, run over the same channel, clears them: it sets fDenyTSConnections back to 0, confirms the Remote Desktop services and allow rules, and disables the block rule. It supports -WhatIf for a dry run, and reports a summary of what it changed.

Remote Desktop reconnects. A device that locked everyone out was recovered without network or physical access, through a channel the lockout never touched.

Insert your successful RDP reconnection here to close the sequence.

Next

The lockouts in Parts 3 and 4 both start with an attacker getting a foothold, and credential theft is how that usually happens. The next post looks at defending the credentials themselves.

The technique attackers use for the foothold, and the layered defences that stop it – with the nuance Microsoft documents but few people read.

The lockouts in this series both assume an attacker who has already gained a foothold. Credential theft is how they usually get it, and the Local Security Authority Subsystem Service (LSASS) is the target. Tools in the Mimikatz family read credentials straight out of LSASS memory. This post is about the defence, not the tool – so no attack tooling is provided here – and about a nuance in how those defences interact that is easy to get wrong.

The layers that defend LSASS

Defender for Endpoint stops LSASS credential theft at several layers:

• Antivirus quarantines known credential-theft binaries on write or execution, usually before they run at all.
• The attack surface reduction (ASR) rule “Block credential stealing from the Windows LSASS subsystem” blocks processes from reading LSASS memory.
• LSA protection (RunAsPPL) runs LSASS as a protected process, so non-protected processes cannot read it.
• Credential Guard uses virtualisation-based security to isolate the secrets entirely, out of reach even of a process that opens LSASS.

The lab’s posture

The lab VM is already hardened to the recommended baseline. RunAsPPL is enabled, and both Credential Guard and memory integrity are running under virtualisation-based security.

A detail worth a line: Credential Guard shows as running but not explicitly configured by policy, because it is enabled by default on Windows 11 Enterprise when the hardware supports it. On this device, a Mimikatz run gets nowhere – the binary is quarantined by antivirus, and even past that, RunAsPPL and Credential Guard protect the secrets.

The nuance: use one, not both

Here is the part that trips people up. When LSA protection is enabled, Microsoft’s own documentation states the ASR rule is not required, gives no additional protection (the two work the same way), and is reported as “not applicable” in the Defender portal. The ASR rule is positioned as the fallback for environments that cannot enable LSA protection or Credential Guard – not as a second layer to stack on top.

The portal bears this out. On the hardened lab device, the ASR configuration shows rules off, none in block or audit, and two rules not applicable – the credential-stealing rule among them, deactivated because LSA protection already covers it.

This behaviour is consistent with guidance Microsoft provides directly through support. Write it from experience; there is no need to reference any case.

So the practical rule is: lead with LSA protection (RunAsPPL) and Credential Guard. Reach for the ASR rule only where you cannot deploy them, and do not expect it to add anything when they are already on – it will simply read “not applicable”.

The ASR rule is noisy by design

There is a second reason the ASR rule is the fallback rather than the first choice: it is noisy, and Microsoft documents this plainly. Many processes make unnecessary calls to LSASS that do not need blocking, so the rule produces a large volume of audit events, almost all of which are safe to ignore in block mode. It blocks things like svchost.exe reading LSASS, which can usually be ignored, and a single event does not by itself indicate a threat.

Defender manages the noise by suppressing alerts and notification pop-ups for friendly processes and duplicate block actions – the deduplication that keeps the rule usable. Notably, for this specific rule Microsoft says you can skip audit mode and go straight to block, because the audit volume is so high and so benign that evaluating it first adds little. That runs against the usual “always audit first” advice, and it is worth calling out.

Hunting the technique

Where you do want visibility – on devices running the ASR rule rather than LSA protection – the companion repo’s 03-Credential-Theft-Commands.kql hunts the technique directly: Mimikatz-style command lines (sekurlsa::, lsadump::), LSASS OpenProcessApiCall events, and the AsrLsassCredentialTheft block and audit events. Set the DeviceNameFilter and run it in Advanced hunting.

In short

Protect LSASS with RunAsPPL and Credential Guard as the primary, quiet, strong defence. Treat the ASR rule as the noisy fallback for where you cannot, and understand that it switches itself off to “not applicable” when the stronger protections are present. One layer, chosen deliberately, beats two layers fighting for the same job.

Next

Defences are best understood under attack. The next post walks the full kill chain – credential theft, privilege escalation and ransomware – on a deliberately unhardened device, and watches each of these defences fire in turn.