Thus far my articles have focused on detecting external attacks, but let’s be honest. Sooner or later one of your users won’t be able to resist that incredibly strong urge to click “enable macros” on a strange document they’ve been emailed, or enter their network credentials on a third party website that swears it needs them to unlock a secret encrypted email from someone, and then the attackers will be inside your network.
And if your network is like most, it’ll be a Windows system that first gets compromised. That’s not an attack on Windows, it’s just a fact that Windows still holds the biggest market share right now as far as operating systems go so it’s more likely than not that the user who compromises your network will be on a Windows system. Often these logs can get very large, too large to open in Excel, and if you don't have a SIEM configured to properly collect these logs you're out of luck - until now. Gigasheet makes it easy to open, filter and analyze huge Windows Event log CSV files.
So, with that in mind, I’m going to go over a few things you can detect within Windows security logs to help detect a malicious attacker inside your network.
Windows uses Event IDs to track different events. The ones we’ll be looking at are 4688 and 4720. Each deals with creation; 4688 is process creation and 4720 is a new user creation.
I started this exercise by extracting Windows logs from Event Viewer as CSV and then uploaded the file to Gigasheet, which parsed it out nicely right away.
If you operate in a very controlled environment then you can treat 4720 as a huge red flag right away. If we filter down into our events to just Event ID 4720, we can see the account that created the new accounts. In this case I created the accounts as a test, but if you see someone who shouldn’t be creating new user accounts doing so... well that’s what we call a clue.
Attackers will sometimes create new user accounts to gain persistence on a network. This is also why it’s a bad idea to allow your regular users to have local administrative permissions. Not only can they install malware (either deliberately or accidentally) but if their account is compromised then an attacker can use their account to establish persistence through creating a new local user.
Unfortunately, many organizations don’t really restrict who can do what on their systems. If yours is one of those organization, then some other things you can look for are deviations from your normal naming convention, such as an account that is just one word when you normally use a format like “first.last” or first name followed by last initial such as “antonioa”. The timing of such an event might also be a clue, such as two in the morning when your IT staff only work 9-5.
Picking out new user creations is pretty easy. We just have to filter by the event ID. How about event 4688? This process creation is just as easy to find but it can be a little more interesting to look at. Not only do these logs show the process created, but they show the parent process that created it.
Just filtering down to Event ID 4688 we can see powershell being run. You can also see the process that called it. You don’t have to be a master threat hunter to see the value there. If you’re looking at the workstation for a non-technical user and you see powershell being launched that’s a clue, especially if you don’t use scripting in your environment. With the right logging settings you can even see the command line that was run. If you see the term “wget” appear in the command line you might want to order some coffee because you could be in for a long night.
Moving on from the idea of threat hunting, let’s talk about compliance. If your organization is required to abide by NIST or CMMC standards you may have a need to track when users are running something elevated (as an administrator). That can mean user account control within Windows. How can you find this in your logs though?
A two filter search can turn up the evidence of a UAC prompt. For this exercise, I filtered down to just Event ID 4688. Then, on the last column (which contains all the details from the Windows log) I filtered by the presence of the term “consent.exe” which is the executable for UAC.
These are just a few of the basic things you can find within individual system logs. When you start diving into domain logs you may find yourself hunting for authentication type 0x17 which means the usage of RC4 encryption for Kerberos tickets (a common symptom of different network based attacks like Kerberoasting) or mounting shares. That’s beyond the scope of this tutorial though.
All of this requires that logging be turned on properly though. By default Windows will collect some basic logging but to get the details you need and the number of logs you need to detect these events you may need to modify group policy to increase logging to the proper level. You don’t have to be on a domain to do this, just run the command “gpedit” and you can then modify your security policy to collect these logs.
Logging won’t prevent an attack, there’s no denying that, but if you accept the fact that no matter how much you harden your environment someone will always get through, logging is still essential to your security. Without proper logging, as well as the proper knowledge and means to parse through those logs, you may well be helpless to root out those attackers who do get through.
Want to quickly analyze Windows Event Viewer CSV exports? Try Gigasheet. Sign Up for Free today!
The ease of a spreadsheet with the power of a data warehouse.
