MDE | Silicon Shecky

Recently, SentinelOne had a blog post about how Lockbit Ransomware was using Windows Defender to side load Cobalt Strike. Considering that this technique I sat down to write up a query(that is available at my Github here) for a custom detection of this procedure based off the information in the SentinelOne Blog post. Here I am going to go through the query and break it down.

The full query looks like this:

DeviceFileEvents
| join DeviceFileCertificateInfo on DeviceName //This is for checking if it is a signed version of the dll joined on Device Name for distinct usage
| where Timestamp > ago(7d) // look back over the past week
| where InitiatingProcessFileName == "MpCmdRun.exe" and IsSigned // checks to make sure that mpclient is being run
| where FileName contains "mpclient"// checks for the misused dlls.
| where FolderPath !contains "\\programdata\\microsoft\\windows defender\\platform" // do not check the normal location for the dll being run
| distinct   DeviceName, Timestamp, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessFolderPath

So when I started writing the query I started simple. Look for the dll name which is mpclient not running from its normal location. this mean I would be starting in the DeviceFileEvents table. It simply came about to look like this:

DeviceFileEvents
| where FileName contains "mpclient"
| where FolderPath !contains "\\programdata\\microsoft\\windows defender\\platform"

This query returned the maximum number of results. First thing I noticed was the duplicate DeviceNames(computer names) in the list, so I added a line using the distinct command to get rid of that.

DeviceFileEvents
| where FileName contains "mpclient"
| where FolderPath !contains "\\programdata\\microsoft\\windows defender\\platform"
| distinct DeviceName, Timestamp, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessFolderPath

While better, this query still was noisy. Updaters and some normal network services tended to call upon that dll in some other locations. So the question became how could I reduce the noise without blinding myself to extra paths? I went back into the original blog post and saw that the intel said the dll was being run using the MpCmdRun.exe command and that the command was legit and signed. Unfortunately the DeviceFileEvents table does not have a way of checking for signatures. While I could have done this:

DeviceFileEvents
| where InitiatingProcessFileName == "MpCmdRun.exe"
| where FileName contains "mpclient"
| where FolderPath !contains "\\programdata\\microsoft\\windows defender\\platform" 
| distinct DeviceName, Timestamp, FileName, FolderPath, InitiatingProcessFileName, InitiatingProcessFolderPath

I felt that making sure the Initiating Process was signed would also help quell the noise a little. Checking for that required joining a table called DeviceFileCertificateInfo. To bring in another table one must use the join command. The join command requires you to join the table with a common point. I originally thought the SHA1 of the process would be perfect, but came to realize that created a problem with my distinct output, so joining them on the DeviceName was the better option. When doing a join it never hurts to double check what field you can join the tables together on, as there are usually a number of options and it does make a difference.

| join DeviceFileCertificateInfo on DeviceName

Once joined I could use the IsSigned field to make sure there was a signature for the file/process. The question is where to put it. In the initial query I put it after checking for mpclient, but came to realize that doing it that way was also checking for a valid signature on the mpclient.dll file that was malicious. Since there would be no guarantee this would be the case I moved the join to immediately after the table call and added the IsSigned as a must have condition only for the InitiatingProcessFileName check.

At this point we have the full query as shown at the start. using a couple of backslashes you can comment out any of the lines in the query for testing different parts of it.

When writing a query like this tables and field are listed on the left hand side of the Advanced Hunting screen. The value of having that right at your fingertips is huge. The hardest part is finding detailed information on fields or commands themselves. Even Microsoft’s own documentation on the web is pretty poor overall, so patience with trial and error is key. Kusto Query Language I have found is a powerful query language, and something people will need to know more going forward.

Identity is the new perimeter. We keep hearing that, especially from Microsoft. Unfortunately, they have not completely bought into this in their Defender suite of security products.

Microsoft Defender security products are nice. They work decently, Gartner likes them, but there is a problem with them. They focus on the device too much as far as some key features go. I specifically am talking about alerting and web filtering. This is made apparent when designing policies for either. Here is an example, you make a custom detection from a hunting query, and it gets applied to a device group. Alert e-mails get sent out to those e-mail addresses that have been specified for that group. This can and does create a bunch of alerts that go to a helpdesk which has no clue on what to do about them, besides the security people who are the ones who should be looking into them. Groups of IT people start ignoring the alerts from Defender, and now you are almost as insecure as you would be without defender. I say almost because there is protection, and maybe even automatic investigations/remediation, but you do not have eyes on it to check for false positives, nor to check the alert overall and see if it is part of a larger attack. This is one way where Microsoft’s Device Group only thinking fails. Make sure you alert only those that need to be alerted. This cuts down on alert fatigue.

Another way I am seeing it fail is with their web filtering feature. This is becoming more prevalent as Defender for Endpoint is now able to be rolled out to mobile devices besides workstations/laptops. This failure is not just a Microsoft problem, I have seen other well known web filtering fail at the whole user identity protection (I’m looking at you Cisco Umbrella, but that is a not keeping up with technological advance (AD vs. Azure AD vs. Hybrid vs. Both)). Microsoft again wants you to apply per device group in your MDE tenant. So if you have person X who has a Laptop, Phone, Workstation and Tablet all of which are suppose to be covered by the web filter policy, you have to manage all 4 devices in their respective groups. Wait, there is more! You now also have to make multiple device groups for similar devices based on a persons function and what they are allowed. All this extra work instead of being able to say people in AD(or AzureAD) group X get web policy Y. You get identity information into MDE, it should not be so hard for Microsoft to allow this for better control.

All of this starts to fall into the identity space, which is definitely the new perimeter. You bring your identity with you everywhere you go. Identity is the most attacked thing right now because it gives that initial foothold. I am not saying get rid of device group policies, but make sure that identity policies are also available. The real answer is both devices and identities do need to be secured, there is no question. The problem is we are tackling the application of these secure controls and alerts to a device instead of to the identities. If you switch devices your new device has to get put into all the right policies instead of being automatically put into the policies that your identity would already be a part of.

This is a starting point, and one that should be discussed and debated respectfully. Security software and alerting has come so far from where it use to be, but I feel we are seeing some major mistakes with how it is being designed. These flaws, just like any flaw, can and will be exploited. The final question is doe the companies like Microsoft actually want to listen to us or are they going to just shove their flawed way of doing it down our throat?

Defender, KQL and Lockbit

Device vs. User