I wrote a post earlier about the integration between Microsoft Defender ATP (MDATP), Intune and conditional access. In that post I mentioned some of the investigation capabilities within MDATP, but left one key feature unexplored. So I wanted to dedicate one short post solely on that feature – Live Response.
Live Response is a fairly new feature allowing real-time access to clients managed by MDATP. The feature is not enabled by default, so you’ll have to enable it in the advanced features blade (note, that your clients must also be running Windows 10 version 18323 or later). There is a separate setting also for allowing unsigned scripts to be executed via the console (this relates to the PowerShell script execution capability explored later in the post).
Once you’ve enabled the feature, you can see the Initiate Live Response Session option on the machine page:
Selecting the option launches a command line interface on the browser:
Note, that this console is not a normal Windows command prompt, but you’ll only have a limited number of commands available. You can find the full list of available commands here. There are a number of useful commands to inspect running processes, network connections, registry, etc. You can also inspect files and perform static analysis (in this case, the malicious Word document used in the previous blog post came out clean):
One useful command is getfile which allows you to download individual files from the remote client. If you have an analysis machine with proper tools in place, you can continue investigations there. You can also quarantine the file on the remote client by running remediate.
The quarantine event is logged in the Windows event log of the client:
Gimme PowerShell!
While the set of out-of-the-box commands provided by the Live Response console does provide a useful tool set, it clearly has its limitations. Luckily, it also supports running custom PowerShell scripts on the remote client. Now, this is not an interactive PowerShell session, so it may sound a bit cumbersome. But it does work surprisingly well.
For my testing, I’m just running a couple of commands, but I want it to run for some time so that I can have a look at the process itself.
What I need to do first is to upload the file to the library. I also have the option to add parameters to the script.
I can verify that the file has been added to the library by running library on the console. The same command also allows to remove files from the library.
To run the script, I use the run command:
After a minute or so, I can see the PowerShell process in Process Explorer, and it’s running as a child-process of SenseIR.exe (under local system account).
Once the script execution is finished, the output is printed on the console. It will also pipe the output into a file that you can easily download to your local machine using the getfile command (the output file also contains information about the PowerShell version, the process ID used, etc.).
All the commands executed via Live Response are retained in the command log. This keeps a nice audit trail of the activities performed (although, the commands within the PS scripts are not shown, just the name of the script and the output file):
Summary
This was a quick introduction to the MDATP Live Response feature. Overall, this is a necessary addition to the toolkit. While the commands available at the interactive console is fairly limited, it seems to tackle the most critical use cases. And with the ability to download files and run PS scripts, this can be a powerful tool for the incident response teams.
The integration between Intune and Microsoft Defender Advanced Threat Protection (MDATP) has been there for a while now. It’s an interesting feature, as it allows the risk score assigned by MDATP to be utilized in CA policies. Most organizations I’ve worked with only use Intune for MDM and MAM and still use SCCM (or the like) for managing workstations. While Intune’s capabilities in workstation management are still limited, it’s constantly evolving – and with SCCM co-management supported, it’s becoming a very viable option to enroll also your workstations into Intune. In any case, I wanted to do a quick experiment on how the MDATP -> Intune -> CA integration works, and how quickly we can go from detecting an alert in MDATP into actually making access restrictions in Azure AD based on the incident.
In all its simplicity, the environment is depicted in the picture below. The laptop in this case is just a VM running in Azure but it will do the trick. The Windows 10 is directly joined to Azure AD (this would work equally well with hybrid scenarios, but I got lazy setting up the local infrastructure). The device will be enrolled into Intune and into MDATP (using Intune).
Setup: Intune + MDATP + CA
To begin with, you have to integrate Intune with MDATP. You’ll find the setting within the Intune management blade:
As well
as in the advanced settings of the MDATP portal:
Once the
tenant level integration is done, you need to create a device configuration
profile for MDATP:
The next
thing you need is a device compliance policy. This will determine at which
MDATP risk level the device will be marked as non-compliant. In my case, I’ve
set it to ”Low”, which means that any risk level higher than that
will push the device out of compliance. We’ll see how the risk levels are shown
in MDATP later.
On the
compliance policy settings we want to make sure that devices with no compliancy
status will be marked non-compliant:
And finally, you should set up a security baseline for MDATP. Although not strictly required for this experiment, it gives you a good idea which MDATP features you can centrally manage via Intune. If you’re running your Windows 10 remotely, be careful with the firewall configurations. The default settings in the baseline will make you lose RDP connectivity (been there…).
Finally,
we’ll create a couple of conditional access policies. For testing purposes,
I’ll create two policies:
Access to
SharePoint Online will require either a compliant device or MFA
Access to Exchange Online
will require both a compliant device and MFA (picture below)
Enroll!
Now we’re good to go! I start by joining the Windows 10 client to Azure AD, which will also automatically enroll it into Intune (as I have enabled the enrollment policy). After that, I’ll login with an Azure AD account and run the following command. This should generate an informational alert in MDATP, just to show that we’re getting the data.
The
information in the MDATP portal lags a few minutes behind, you have to wait for
a bit for the information to appear. But eventually, you should see this:
As you
can see, the risk level is currently ”No known risks”, as this
activity is not considered suspicious. Note, this view also shows the machines exposure level. MDATP assesses any
vulnerabilities on the host, either due to missing security patches or known
vulnerable configurations. The exposure level does not impact the devices
compliance status, but provides very useful information about the security
posture of the device.
At this
point, we can see our device also in Intune, and it is compliant with all the
defined policies:
When I access SharePoint Online, I’m able to get in with just username and password. And if I login to Exchange Online, I need to authenticate using MFA, but I’m able to get in. So everything is working as expected. Note: if you’re using Chrome, you need to have the Windows 10 Accounts extension enabled. Otherwise the device information will not get conveyed to Azure AD, and it will assume that you’re using a non-compliant device.
Infect me!
Now, let’s break things. In order to do that, I need to simulate an attack on my Windows 10 device so that MDATP will increase the risk level. For that purpose I’m using a Word document that is crafted for this purpose.
The document contains a macro that drops two files on the desktop (diy_rs3_jscript_executes_ps.js and WinATP-Intro-Backdoorexe.jpg). It will then establish persistence by modifying the HKCU\Software\Microsoft\Windows\CurrentVersion\Run registry key. And finally, it starts a trusted process (RuntimeBroker.exe) and injects malicious code into it. This kind of pattern might go unnoticed from traditional anti-malware solutions, and that’s of course the point here.
Once I’ve opened the document, I’ll wait a couple of minutes and voilà! There’s not just one alert, but a bunch of them, and the device risk level jumped to High. We’ll briefly look into the forensics later, now we just want to see what happens with conditional access.
The information has also propagated to Intune via the integration and the device is no longer compliant (this took literally just a couple of minutes from the simulated infection):
At this point, I’m still able to use my open browser session as the access token is still valid (1 hour validity time). But I’m impatient so I just close my browser and reopen it. When I login to Exchange Online now, I get the following notice. In this case, it should say: ”Oops – you really shouldn’t have opened that document”.
I’m still able to access SharePoint Online but it now requires MFA. So the CA policies work just as expected.
Off the grid
One useful feature within MDATP is that you can completely isolate the client from the network. It might be that the device is currently in the corporate network, and therefore just restricting access through Azure AD might not be enough (unless you’ve implemented a full-blown zero-trust model).
Once I do that, it takes a minute or two and I lose my RDP connection. Luckily, that the device will still be able to communicate back to MDATP (well, it would be a pretty crappy feature otherwise). This way, once the remediation activities have been completed and, you can remotely allow the device back into the network. Also, I can still continue my forensic analysis while the device is safely off the grid.
CSI
So what would happen next? Obviously, at this point someone from the SOC team, or whoever is monitoring the alerts, would need to investigate what happend, and help getting the device back into compliance. There are a couple of MDATP features worth exploring at this point (we won’t go through everything). MDATP shows you the process tree during the incident, which gives a nice overview of what happened:
You can also check on individual files, and where they have been seen in the organization, in this case I’m looking at the WinATP-Intro-Backdoorexe.jpg:
You can also take the file hash and use it to drill down to the data using the advanced hunting functionality. This allows you to search the data directly from the MDATP logs using Kusto query language (same that is used with Log Analytics). There’s also a community that has produced useful examples, both for generic use as well as for identifying specific exploits (https://github.com/microsoft/WindowsDefenderATP-Hunting-Queries). In this case, I’m just looking into all the events involving this particular file.
Another useful feature is the ”Collect investigation package”:
This will
pull all sorts of useful information from the machine and allow you to download
it in zip format. This can be very useful when doing the forensic analysis.
Reincarnation
So let’s say we’ve now concluded our investigations and cleaned up the machine. What next? We have to decrease the risk level of the machine for it to become compliant again. To do that, we have to resolve the alerts in the portal. You can also link alerts into incidents, as in this case all the alerts originating from this machine should all be related to a single incident.
Once all the alerts have been resolved, the risk level goes back to ”No known risks”. At this point, if we have isolated the machine, we could release it from the isolation (it took a couple of minutes for me to be able to reconnect my RDP session after the release).
And as
expected, device status in Intune is back to compliant:
