Microsoft Defender for Endpoint: Investigating the 'PowerShell Reverse Shell' Mystery

Two hallmark features of Microsoft's (semi) cloud-delivered Defender XDR suite are Microsoft Defender for Cloud and Microsoft Defender for Endpoint. As it turns out, enabling certain capabilities within Defender for Cloud will leverage Defender for Endpoint EDR features, even if Defender for Endpoint (formerly Microsoft Defender Advanced Threat Protection) isn't explicitly enabled. Particularly, enabling the "Protect Cloud Servers" capability for a certain Azure subscription will automatically onboard the servers contained in that subscription to the Defender for Endpoint suite - part of this includes the 'MsSense.exe' executable which is the EDR component of Microsoft Defender.

The MsSense.exe executable will commonly kick off child processes to gather data, perform network discovery, and detect advanced threats. One such child process - of particular interest for this article - is SenseIR.exe. In true Microsoft fashion, there is almost no official detailed information on this executable available online.

SenseIR.exe is a very intriguing process when it pops up. Typically, it is used to spawn PowerShell processes under the local system account when using the live response Defender for Endpoint feature. In this context, it allows the user on the other of the live response session to remotely execute PowerShell scripts by feeding it a .ps1 file (There's even an option to allow execution of unsigned scripts). When this happens, inspecting the command line used by SenseIR.exe reveals that the script is downloaded to C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\Downloads\PSScript_{<GUID>}.ps1, with parameters being passed as base64 encoded JSON. This does looks somewhat suspicious - but it's intended behavior and not what this article is about.

There's something else I've observed SenseIR.exe doing, and it's something that caused hundreds of alerts to get generated, claiming a reverse shell was being established via PowerShell. I'll go ahead and spoil it now - No, a reverse shell was not being created.

The PowerShell

SenseIR.exe was spawning a PowerShell child process with the command: C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy AllSigned -NoProfile -NonInteractive -Command <command>. Passed to the Command parameter is this:

This is Defender for Endpoint ensuring that the script it's about to load into memory - 0e3d6d2d-06cc-486d-9465-9ef3bee75444.ps1 - has a SHA256 hash that matches the expected value.

Concerning the script itself, it's one of many PowerShell scripts in the folder C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection. This folder is only accessible by SYSTEM.

If you noticed the above command used to launch this PowerShell included the -ExecutionPolicy AllSigned parameter. This is because the script being launched (and every other PowerShell script in that directory) is signed with a Microsoft Windows Defender Advanced Threat Protection certificate:

Investigating

Although Microsoft verifies the expected hash and signature of the PowerShell file before loading it into memory, I still wanted to know more about these weirdly named scripts being stored in the *\DataCollection\ folder.

As previously mentioned, the DataCollection folder is only accessible by SYSTEM which makes it hard to gather what's being stored there. Thankfully, that doesn't make it impossible, and I was able to find a GitHub repository that has a few of the scripts. Looking into these scripts more reveals that they're used for a lot of things, from network discovery to data collection - it still isn't clear to me what exactly causes SenseIR.exe to launch a particular script (especially because network discovery should be handled by the SenseNDR.exe binary), but that's an investigation for another day. Most of them heavily rely on .NET frameworks and embedded C#, and that makes sense given that they all eventually spawn a csc.exe process.

Digging Deeper

Luckily, Windows security logging provides me with the relevant process IDs. These logs are sent up to an Azure Log Analytics Workspace via the log analytics agent (Also included in Defender for Cloud) which makes it easy to dig deeper. Querying the log analytics workspace for a process on a particular host with the same ID as the SenseIR.exe parent process confirms that this was initiated by the previously mentioned MsSense.exe:

By the way, that long string of characters included in the end of CommandLine field is more base64 encoded JSON:

Now that I've confirmed that this was started by MsSense.exe, the main EDR binary, I can keep following the process calls:

Finally, something useful. It looks like the PowerShell script I'm investigating (0e3d6d2d-06cc-486d-9465-9ef3bee75444.ps1) eventually spawns OpenHandleCollector.exe. This makes sense when you inspect the source code for this script:

OpenHandleCollector.exe is much like SenseIR.exe in that there's very little official documentation on what exactly it does. As far as I can tell, this is used as a vulnerability management tool by scanning open handles and associated processes on the system.

Findings

In this particular instance, I ended knowing that the PowerShell being invoked by SenseIR.exe (and MsSense.exe before it) eventually launched OpenHandleCollector.exe, which handles vulnerability management as part of Defender for Endpoint. Although Defender for Endpoint isn't explicitly enabled in my environment, the ATP sensors (MsSense.exe, SenseNDR.exe, SenseIR.exe, etc.) are still installed and provide coverage for certain servers thanks to Defender for Cloud. However, there are dozens more of these scripts that likely do different things. This is enough information to make a decision to tune those alerts out though - it's clearly nothing malicious.

As for the supposed 'reverse shell' that brought my attention to this in the first place, I suspect that was likely due to that specific rule definition being slightly misconfigured on the SIEM. It may have been triggered in part due to Microsoft deprecating the legacy Log Analytics Agent for Azure virtual machines, as the deprecation timeline matches with (perhaps coincidentally) when the alerts started coming in. which is onboarded on the offending servers, and does play a role in Defender for Cloud. In any case, I was able to make an exclusion to prevent the alert from being triggered when SenseIR.exe is the parent process.