In this post, I continue my discussion on potential low-cost solutions to mitigate insider threats for smaller organizations or new insider threat programs. I describe a few simple insider threat use cases that may have been detected using Windows Event logging, and I suggest a low-effort solution for collecting and aggregating logs from Windows hosts.

Numerous publications and guides exist, including those from the NSA, Microsoft, and SANS, that explain how and why host-level logging should be used for Windows systems. This cybersecurity concept applies as much to insider threat detection and response as it does to general troubleshooting, intrusion detection, and incident response; it should not be overlooked as a valuable resource. This is particularly true considering that the implementation comes at no additional software licensing cost on top of the base operating system that you are already using. Many security information and event management systems (SIEMs) require additional management overhead, and they may even introduce additional attack vectors. However, Windows Event Forwarding and Collection provides a straightforward mechanism that can be used to centrally aggregate logs across Windows systems without installing additional client collection agents.

Consider the following insider incident:

A system administrator was dating another employee who was fired; the fired employee began sending emails to management demanding her reinstatement using threatening language. Because of the threatening emails, the system administrator was fired as well. Before leaving, the insider created a backdoor administrator account, which he later used to attack the organization. The insider accessed the company's servers several times (post termination), deleted sensitive data, and shut down several machines. The insider was discovered via access logs tied to the backdoor account.

This case highlights the need to audit account creation and privileged group modification, both of which may lead to the creation of unauthorized access paths. The following table lists Windows security event IDs that pertain to account management, which includes activities such as creating and disabling user accounts and groups and modifying group permissions.

These types of security events should occur relatively infrequently on domain controllers and even more infrequently as local account or group modifications on workstations and servers. Depending on the frequency observed, it may be operationally feasible to configure an email alert for these types of activities. You can use the Windows Event Viewer on the Forwarded Events log on your collector (or even on individual servers) to create a task based on specific event IDs. Filter the log to locate an event for the desired ID, then right-click and select Attach Task To This Event. You can use this task method to call specific programs or scripts, such as a PowerShell script that sends a notification email to your security team.

The following incident highlights the need to monitor printing activity, which is fairly straightforward to accomplish for Windows-based workstations and print servers:

An insider expressed disgruntlement to his co-workers about current organizational policies. He logged into a system and printed a sensitive document, which he then physically exfiltrated and mailed to an external party.

In this case study, the PrintService operational log could have been used to collect useful information, such as the title of the document that was printed, the user who printed it, the printer name, the total byte count, and the number of pages printed. You can readily enable this logging on centralized Windows print servers and user workstations by (1) opening the Event Viewer, (2) navigating to Applications and Services Logs > Microsoft > Windows > PrintService, (3) right-clicking Operational, and (4) selecting Enable Log.

After enabling the log, you begin to see an event ID 307 for each print job submitted on the system.

Unless your organization is very small or printing is minimal, it would be impractical to analyze these events individually. However, using just the information contained in this event type, you can do some interesting anomaly detection across all of these events based on page count and size, and you can do trivial keyword searching on the titles of the documents.

If you are forwarding all of this log data to your Event Collector, you can use a few simple PowerShell commands to output it to a flat file as input to an anomaly detection or analysis pipeline. Specifically, you can use the PowerShell Get-WinEvent Cmdlet to locally or remotely connect to the Event Collector and then export the results using the Export-Csv Cmdlet:

If you deploy a more robust SIEM tool, this effort will not be lost since you will have taken the necessary steps to centralize your logging, allowing you to then deploy the SIEM tool's event log collectors on your Event Collector servers instead of across all the systems in your enterprise.

Once you have enabled the desired event logs and implemented some sort of centralized collection mechanism, one of the next steps is to begin analyzing the data to provide meaningful and actionable intelligence and alerting. Stay tuned for more content from the CERT National Insider Threat Center, refer to our current publications (such as Analytic Approaches to Detect Insider Threats), or consider attending our instructor-led Insider Threat Analyst course.

Subscribe to our Insider Threat blog feed to be alerted when any new post is available. For more information about the CERT National Insider Threat Center, or to provide feedback, please contact insider-threat-feedback@cert.org.