Has your company been hit by ransomware yet? How about other types of malware? Phishing scams, drive-by downloads or pass-the-hash attacks? If you haven’t already, you probably will be soon.
What do all these attacks have in common? They start on user workstations. There are things you can — and should — do to mitigate this risk, like keeping applications on your endpoints properly patched and educating your users so they’re less likely to click malicious links in phishing emails, open attachments infected with ransomware viruses or insert USB drives of unknown provenance. But attackers are both sophisticated and relentless, so some of them will get inevitably through. You need to be able to catch attacks on your endpoints as early as possible so you can intervene before real damage is done. But how?
By carefully monitoring your workstations. If you’re using native tools, there are three critical logs you need to know how to use to improve endpoint security: the Windows security log, the Sysmon log and the PowerShell logs. Here’s a brief summary of the most important things you can learn from each of these logs.
Window security log
The Windows security log is the only place you can get many critical events, including these:
- Local user and group enumeration — Malicious code often enumerates the local user accounts and local groups on the workstation to find useful credentials, so monitoring these events can help you spot malicious code before it can move laterally to other systems and use those credentials.
- Local account creation and group changes — Attackers also often create or modify local accounts and local groups (especially the local administrators group), so you want to keep an eye on these events.
- Logon attempts with local accounts — Users normally log on to their workstations using a domain account, so attempts to log in using a local account can be a great indicator of attacks.
- Logon with explicit credentials (event 4648) — Scheduled tasks often log on by explicitly specifying another account’s credentials — but scheduled tasks aren’t generally run on workstations. Therefore, this event can indicate an attacker trying to use credentials they've collected.
- When was the user physically present and active —Any activity on a workstation while it’s locked demands further investigation.
- Firewall configuration change — Sometimes applications add exceptions to the Windows firewall as they’re being installed. Exceptions don’t have to be deliberately malicious to create serious security gaps, so you have to keep a close eye on them.
- Plug-and-play device connections — Since malware often enters a workstation through USB drives or other plug-and-play devices, it’s essential to audit connections from all such devices.
Sysmon
Sysmon is a free service from Microsoft that monitors system activity and records it in a Windows event log, which is also called “Sysmon.” Here are a few of the events you should monitor there:
- Process creation — It’s not enough to simply look for obviously malicious processes; attackers can easily create a malicious program with the same name as a legitimate tool or modify an existing program to perform illicit actions. Sysmon provides a hash of the file’s contents so you can spot these sneaky attacks.
- Network connections — Monitoring network connections can also help you spot attackers. Sysmon helps you investigate by linking each connection to a process through the ProcessID and ProcessGUID fields, and providing details about the source and destination hosts.
- Registry changes — To ensure malicious code runs even after the workstation is rebooted, attackers often modify the registry. Sysmon will tell you who made the change, which computer they used, when it happened, the process ID, and the new name of any key or value that was renamed.
- File creation — You need to quickly spot and investigate suspicious file creation events. In particular, you should monitor autostart locations like the Startup folder, as well as temporary and download directories, where malware often appears during initial infection.
PowerShell logs
Hackers love to use PowerShell because it’s so powerful, so it’s critical to keep a close eye on PowerShell activity. Monitoring the two PowerShell logs will help you spot:
- Providers loaded — PowerShell providers are programs that make the data in a given data store available in PowerShell. Any unusual loading of providers could indicate malicious activity.
- Module logging — Module logging provides more detailed auditing that includes every command executed and all of its parameters (but not the output of the command).
- Script block logging— Script block logging shows every block of PowerShell code that was executed, which provides a lot more context than seeing each individual command. Even if a hacker tries to hide or obfuscate the command, this event will show the actual command that was executed.
Next steps
That’s just a high-level introduction to using these logs. If you’re ready to dig into the details, check out my new ebook, “Top 3 Workstation: Logs to Monitor.” It will tell you exactly which event IDs to monitor and how to collect events from each log, and provide other valuable tips, like how to protect Sysmon from tampering.
If that kind of log monitoring sounds like a lot of work, that’s because it is. Moreover, there’s a strong possibility that you’ll miss critical events, because it’s hard to collect logs from all your endpoints in a timely and efficient way (just how many laptops are in use in your organization?), and the logs are incomplete and as well as notoriously cryptic.
If you’re ready for a better option, check out Quest InTrust and Quest IT Security Search. At the end of the ebook, you’ll learn how these solutions can help you dramatically improve endpoint protection while slashing IT workload and storage costs.
