search menu icon-carat-right cmu-wordmark

Windows Event Logging for Insider Threat Detection


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.

Event ID Description
608 User Right Assigned
624 User Account Created
626 User Account Enabled
631 Security Enabled Global Group Created
632 Security Enabled Global Group Member Added
635 Security Enabled Local Group Created
636 Security Enabled Local Group Member Added
645 Computer Account Created
646 Computer Account Changed
648 Security Disabled Local Group Created
649 Security Disabled Local Group Changed
650 Security Disabled Local Group Member Added
653 Security Disabled Global Group Created
654 Security Disabled Global Group Changed
655 Security Disabled Global Group Member Added
658 Security Enabled Universal Group Created
659 Security Enabled Universal Group Changed
660 Security Enabled Universal Group Member Added
663 Security Disabled Universal Group Created
664 Security Disabled Universal Group Changed
665 Security Disabled Universal Group Member Added
4720 A user account was created
4727 A security-enabled global group was created
4731 A security-enabled local group was created
4744 A security-disabled local group was created
4749 A security-disabled global group was created
4754 A security-enabled universal group was created
4759 A security-disabled universal group was created
4783 A basic application group was created

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.

Screenshot of windows OS highlighting "Attach Task To This Event..."

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.

Windows OS screenshot highlighting "Enable Log".

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

Windows OS screenshot of Event Properties.

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:

PS C:\Windows> GetWinEvent - logname "ForwardedEvents" 
-ComputerName wef-server -MaxEvents 100 | Export-CSV output.csv

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

Get updates on our latest work.

Each week, our researchers write about the latest in software engineering, cybersecurity and artificial intelligence. Sign up to get the latest post sent to your inbox the day it's published.

Subscribe Get our RSS feed