Most attacks today begin on user workstations. Why? Well, in part it's because workstations, unlike servers, are typically the province of non-technical users, who are easier prey for attackers. For example, Verizon's 2017 Data Breach Investigations Report (DBIR) found that 1 in 14 users were tricked into following a malicious link or opening an infected attachment — and a quarter of those were duped more than once. Workstation users also fall victim to drive-by downloads from websites they think they can trust, unwittingly insert USB drives containing ransomware or other malware, and make other critical mistakes that allow attackers to gain a foothold in the corporate network.
It's easy to lay all the blame on users, but attacks are getting more sophisticated all the time. In particular, hackers mine social media for information they can use to make their phishing emails increasingly convincing, and hide malware in downloadable files that seem to be the genuine assets that users are looking for. Even IT pros themselves sometimes fall for these more sophisticated gambits.
The other side of the coin is that users' workstations are also particularly vulnerable, for several reasons. First, many modern exploits rely on interactive local user actions, which are the most common scenario on workstations. Second, most attacks exploit malicious file and web content — and workstations come into contact with far more files from the Internet than servers do. Finally, many vulnerabilities involve third-party GUI-driven applications used on workstations, such as internet browser extensions, and keeping these applications properly patched remains a weak point in many organizations.
Most attacks begin on user workstations. Learn how to fight back.
This combination of non-technical users and vulnerable workstations is irresistible to hackers, so you have to make endpoint security a priority. The key to catching attacks as early as possible and stopping them before real damage is done is to properly monitor your workstations. But what's the best way to do that? This ebook reveals the three most important logs for tighter Windows workstation security — the security, Sysmon and PowerShell logs — and details exactly which events to collect for each and why.
Of course, with the high number of workstations and large amount of log data at most organizations, there are some real challenges involved in collecting and archiving workstation logs, let alone monitoring, searching and analyzing them. So we'll also briefly show how Quest® InTrust® and Quest® IT Security Search can help you further strengthen endpoint security without running your IT teams ragged or blowing your storage budget.
Effective workstation log monitoring begins with the Windows security log. It's the main record of security-related activity on workstations, and many important security events are logged only there.
Many important security events are recorded only in the Windows security log. The Windows security log is the only place to get the following events:
There are other important events that you can get from the security log — but I recommend getting them from Sysmon instead because the quality of the data is better. These events include:
We'll explore these events in the "Sysmon" section below.
Expert tip: Create honey objects — folders or SharePoint document libraries with tempting names — and watch for attempts to access them.
A workstation's audit policy determines which type of information about the system you'll find in the security log. Windows uses nine audit policy categories and 50 audit policy subcategories to give you granular control over which information is logged. You can choose whether to log successful events, failed events or both.
Lean toward more auditing, since it rarely slows the system down. Just be sure to increase the size of your logs.
I recommend turning on auditing for the following audit subcategories. Choose both "success" and "failure" for Logon events, and "success" only for the others.
This list represents the minimum auditing I recommend; you might well want to turn on additional subcategories. Remember, you don't have to collect and archive every event that's logged. I always lean towards more auditing because it doesn't slow the system down (except in a very few cases, such as auditing all access to all files). Just be sure to increase the size of your logs; I recommend something between 200MB and 1GB.
Sysmon is a free service from Microsoft that monitors system activity and records it in a Windows event log, which is also called "Sysmon."
There is some overlap between the Sysmon log and the security log, but for certain events, Sysmon provides better quality data.
As noted earlier, there is some overlap between the Sysmon log and the security log. I recommend using Sysmon for the following events because the quality of the data is better:
I also recommend using Sysmon to monitor the following events that are not included in the security log:
To install Sysmon, simply download the executable from Microsoft and then run the following command:
To control which event IDs are logged, specify the appropriate settings in an XML configuration file and then run this command.
Sysmon –c config.xml
Many of the events I listed above will generate some false positives, so, for example, you could specify a list of EXE files that Sysmon should exclude from monitoring. For a configuration file template that is a great starting point for system change monitoring, visit https://github.com/ SwiftOnSecurity/sysmon-config.
Your Sysmon config file controls which events are logged.
It's much easier to tamper with Sysmon than the Windows security log. Fortunately, there are a few techniques that can mitigate this risk. First, you can obscure Sysmon by changing the driver name (use the DriverName tag in the config file) and changing the service name (rename the executable before installing it).
However, there are still methods hackers can use to find Sysmon, so you also need to monitor for attacks on it. Fortunately, Sysmon tracks changes to itself using the following events:
You can also set up a scheduled task via Group Policy that periodically wakes up and runs the following command to enforce the proper configuration (replace "server\share" with the correct path in your environment):
\\server\share\sysmon -i -accepteula -c \\server\ share\sysmon.xml
if errorlevel 1 \\server\share\sysmon -c \\server\ share\sysmon.xml
There are also third-party tools that can automatically reset your Sysmon configuration after improper changes.
Hackers love to use PowerShell because it's so powerful. Therefore, it is critical to keep a close eye on PowerShell activity. There are two PowerShell logs: The Microsoft-WindowsPowerShell/Operational log gets most of the attention, but there is also the Windows PowerShell log. I recommend monitoring certain events from both of them:
Windows PowerShell log
Microsoft-Windows-PowerShell/Operational (renamed to "MicrosoftWindows-PowerShellCore/Operational" in PowerShell 6)
The Windows PowerShell log captures events by default, so you don't need to enable logging to see which providers have been loaded (event ID 600).
You can turn module logging and script block logging on or off using the corresponding Group Policy settings under Administrative Templates | Windows Components | Windows PowerShell.
Hackers love to use PowerShell because it's so powerful.
Together, the Windows security log, Sysmon and the PowerShell logs can give you some visibility into your user workstations that can help you spot and thwart attacks. But there are multiple reasons not to rely on just these logs and the native tools to ensure workstation security.
First there's the challenge of simply getting the logs from all your workstations in a timely and efficient way, especially if many of them are mobile laptops. Then you have to have workflows for analyzing them quickly and efficiently, so you can spot and investigate suspicious activity in time to prevent serious damage.
That's tough, in part because native logs are notoriously cryptic. For instance, earlier in this ebook I recommended enabling the Authorization Policy Change subcategory in the Windows security log. Doing so will enable you to see when permissions on files and folders are changed – but unless you're a complete Window log guru, you won't know much else, because the log data is not provided in anything close to a human-readable format. Instead, each time a permissions change occurs, you'll have to manually run a PowerShell command like this:
(get-acl <folder name>).access | ft IdentityReference,FileSystemRights,AccessControlType,IsInherited, InheritanceFlags -auto
In the time it takes you to spot the change to permissions and run this command, an attacker can easily slip into your network.
Then there are the expenses. It takes time to perform all these log data management and analysis tasks, which drives up staffing costs. If you're using a security information and event management (SIEM) solution or log management tool that charges for processing based on events per second or megabytes per day, the high volume of events that native logging generates can run into serious money. And you might be spending a bundle on storage as well, especially if you're storing the data without compression.
With native tools, it's a challenge to even collect logs from all your workstations and laptops, let alone analyze them effectively.
Finally, there are the gaping holes. To start with, manual tasks by their very nature are ripe for human errors and oversights, which mean that you might well miss critical events that happen on your workstations. Moreover, the log data itself is incomplete and fragmented. For example, I explained how you can use Sysmon to monitor file creation events, but of course, file creation is just a tiny part of the larger task of file system auditing. Unfortunately, there is really no way to perform quality file system auditing — or many other critical tasks — using native tools.
The right third-party tools can be a win-win — enabling you to dramatically improve workstation security while driving down personnel and storage costs. Together, Quest® InTrust® and IT Security Search give you the visibility you need into workstation activity, in an integrated, easy-to-use solution.
Quest InTrust is an event log management solution that enables you to collect, store, search and analyze massive amounts of IT data from numerous data sources, systems and devices — securely and efficiently. The data repository is indexed for fast searches and offers perhaps the best compression on the market: 20–1 with indexing and 40–1 without.
Even better, you don't have to be a Windows log expert to get actionable information from InTrust, because it normalizes critical Who, When, What, Where, Where and from Whom data into human-readable form, as illustrated in the built-in report shown in Figure 1.
Figure 1. InTrust simplifies event log management to enable better workstation security while reducing costs.
On top of all that, InTrust offers both easy deployment and massive scalability: You can deploy InTrust agents to 5,000 workstations in just 20 minutes. InTrust can ingest roughly 60,000 events per second, and one InTrust server can monitor well over 10,000 endpoints. If you have more endpoints, all you have to do is add another InTrust server and split the load.
IT Security Search enables fast security incident response and forensic analysis across disparate systems from a single pane of glass.
Quest IT Security Search is a free solution included with InTrust, as well as with other Quest auditing solutions, including Enterprise Reporter, Change Auditor, Recovery Manager for AD and Active Roles. It pulls data from disparate IT systems and devices into a single pane of glass and provides a Google-like, web-based interactive search engine for fast security incident response and forensic analysis — with no training or log expertise required.
In particular, you can easily review the critical Windows workstation logs we just discussed.
You can filter the data to eliminate noise, and dynamically pivot your investigation as other details emerge, as illustrated in Figure 2.
Figure 2. Reviewing Windows workstation log data in IT Security Search
Attackers are constantly upping their game, and workstations are often their target of choice. Judicious use of the security, Sysmon and PowerShell logs can help you spot and block attacks, including ransomware and other malware, in time to prevent serious damage. And Quest InTrust and IT Security Search will simplify the process of collecting and analyzing that log data, along with lots of other data from across your environment, to slash response time, IT workload and storage costs.
To learn more, check out these resources:
Brian Hymer is a solutions architect at Quest and an expert on the Windows security log and Active Directory forest recovery. His 30 years of experience in the IT industry spans multiple sectors, including power, retail, healthcare, insurance and finance. During his 18 years at Quest, he has focused on helping customers around the globe implement and use Quest products in a wide variety of environments. He has also presented numerous worldwide webinars.
Quest InTrust and IT Security Search help you slash response time, IT workload and storage costs.
At Quest, our purpose is to solve complex problems with simple solutions. We accomplish this with a philosophy focused on great products, great service and an overall goal of being simple to do business with. Our vision is to deliver technology that eliminates the need to choose between efficiency and effectiveness, which means you and your organization can spend less time on IT administration and more time on business innovation.