Using Your SIEM To Look For Attacks Leveraging PowerShell and Regedit

I recently attended a very good online security conference and one of the items that resonated with me is you don't need new or fancy security tools, leverage what you have. I also have been very busy, so I have not posted to this blog in quite some time. I have a lot of content I need to share that I have learned over the past six months or so that I believe many will find useful.

During my consulting days, I witnessed many clients that had very high-end security tools or utilities, but they either were not configured properly or optimized properly.  

If you listen to the various vendors, they have the latest greatest tool that will do everything for you without lifting a finger. if Cybersecurity was that easy anyone could do it.  Some also believe that putting in a tool is good enought and it does not need any additional tweaks/enhancements and that the tool makes the security program good enough. IT Security is not about the latest coolest tools, much of it is about processes, procedure, strategy and constant improvement. The attackers are not staying static, so you can't either.  Most don't get the basics right, which I will discuss in a future blog post.

Today I want to discuss leveraging your SIEM to detect users running regedit.exe, powershell.exe or psexec.exe. Why would you want to look for those processes running? Most end users should not be running those processes and it is a good early indicator that a machine might be compromised.

To accomplish this, you need to be collecting the proper events from the Microsoft Windows devices on your network. If you are running Windows Defender for endpoint and have it integrated into Microsoft Sentinel, then it becomes very easy to look for these processes.  If you have a SIEM you can also capture those processes. You should be able to work with the SIEM manufacturer on how to better capture those events.

You leverage the Windows Defender for Endpoint DeviceProcessEvents log to build your query to look for processes running on your Windows devices. You will need to have the Windows Defender for Endpoint Microsoft Sentinel connector configured to ingest logs into Santiel.   My advice is to create a report and review it daily, as you will need to filter out the users who need to run those processes are part of their job, it should be mostly IT professionals. Once you have filtered most of the noise out of the logs, you can then turn them into alerts that can be investigated.

If you look at most of the built-in alerts to most EDR/MDR solutions they are looking for a series of events to happen in order, which is generally how most know exploits work.  But what if the threat actor is not using a known tool/exploit or they run the commands over multiple days? This could make your EDR/MDR blind to the initial attack.  I believe many have a false sense of security by just installing and EDR/MDR and thinking it is good enough. It isn't, it along with your SIEM should also be evolving. Once you have the tool installed and the noise eliminated, you should start looking at what might make it past the tool and how can you get early detection of a potential compromise.

I hope you will find this useful and think about implementing checks on basic processes, it is easy, does not cost you much and will alert you to an early potential compromise.

The queries you need are listed below, and I will also put them out in my GitHub site.

DeviceProcessEvents
| where FileName contains "powershell.exe"
| project AccountName, DeviceName, FileName, FolderPath

DeviceProcessEvents
| where FileName contains "regedit.exe"
| project AccountName, DeviceName, FileName, FolderPath


DeviceProcessEvents
| where FileName contains "PSExec"
| project AccountName, DeviceName, FileName, FolderPath

(You will need to filter out users and processes, below are some examples of filters you can leverage)

| where InitiatingProcessAccountDomain <> "nt authority"

| where AccountName <> "xxxxacount"

| where InitiatingProcessCommandLine <> "cmd.exe /c Usr.cmd"

TBJ Consulting

TBJ Consulting