Posted on

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



User Right Assigned


User Account Created


User Account Enabled


Security Enabled Global Group Created


Security Enabled Global Group Member Added


Security Enabled Local Group Created


Security Enabled Local Group Member Added


Computer Account Created


Computer Account Changed


Security Disabled Local Group Created


Security Disabled Local Group Changed


Security Disabled Local Group Member Added


Security Disabled Global Group Created


Security Disabled Global Group Changed


Security Disabled Global Group Member Added


Security Enabled Universal Group Created


Security Enabled Universal Group Changed


Security Enabled Universal Group Member Added


Security Disabled Universal Group Created


Security Disabled Universal Group Changed


Security Disabled Universal Group Member Added


A user account was created


A security-enabled global group was created


A security-enabled local group was created


A security-disabled local group was created


A security-disabled global group was created


A security-enabled universal group was created


A security-disabled universal group was created


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.

Fig 1 Attach Task to This Event.png

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.

Fig 2 Enable Log.pngAfter enabling the log, you begin to see an event ID 307 for each print job submitted on the system.

Fig 3 ID 307.pngUnless 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 [email protected].

Posted on Leave a comment

Navigating the Insider Threat Tool Landscape

Mitigating insider threats is a multifaceted challenge that involves the collection and analysis of data to identify threat posed by many different employee types (such as full-time, part-time, or contractors) with authorized access to assets such as people, information, technology, and facilities. The landscape of software and tools designed to aid in this process is almost as wide and varied as the problem itself, which leaves organizations with the challenge of understanding not only the complexities of insider threats, but also the wide array of tools and techniques that can assist with threat mitigation. This post explores some of the recommended tool features and functionality available through use of a combination of tools, as well as a proposed process to implement and operate controls at an organization.

There are various features and functions to prevent, detect, deter, and respond to insider threats. The following list is not exhaustive, but provides several examples that should be considered as part of a robust and comprehensive insider threat prevention platform.

  • Preserve forensic artifacts in the event of litigation
  • Audit network and host-based activity
  • Monitor data and prevent it from leaving authorized locations
  • Correlate and resolve user and system entity activity across various data sources
  • Perform analysis on data being gathered in the form of rule-based alerting, statistical anomaly detection or both, and prioritize those alerts
  • Generate data visualizations to aid in analysis
  • Manage and track the status and resolutions of cases/incidents
  • Analyze text-based data sources for sentiment and affects
  • Mask or anonymize sensitive information that is presented to analysts

The number of features to consider, however, does not necessarily correspond to the number of different tools required, nor does it mean that one or two tools can or should provide all of the desired functionality. There is a great deal of overlap, which may provide a defense in depth strategy but should not require you to purchase multiple tools, in several critical functional areas that can be accomplished by some combination of Data Loss Prevention (DLP), Enterprise Asset Management (EAM), Security Incident and Event Management (SIEM), User Activity Monitoring (UAM), and User (and Entity) Behavior Analytics (UBA/UEBA) tools. Given this overlap, it is important to understand the capabilities offered by existing hardware and software before assuming that procurement is the only method to introduce new functionality. Despite many claims, there is no single tool that will solve a problem as complex as insider threat. Instead of taking a tool-centric approach, begin by enumerating the desired functions to mitigate the threat and work from there. Depending on the industry or government sector, an organization may be subject to different regulations or mandates for specific types of controls. It is crucial to understand the actual requirements that must be fulfilled to avoid over-buying a particular solution that contains unnecessary functionality. However, in the absence of outside requirements, start by adhering to the best practices outlined in the Common Sense Guide to Mitigating Insider Threats.

Figure 1 illustrates a potential iterative process for implementing and operating insider threat controls.
InsTht Control Implementation Operation.PNG

Figure 1: Proposed Insider Threat Control Implementation and Operation

The first step at the top of the diagram is to identify your critical assets and the threats to those assets in order to help prioritize and focus the control efforts. This is a vital first step, as it helps to temper the expectation that every single system and piece of data must be secured to the highest degree. As the adage goes, if everything is critical, then nothing is critical. Start by involving the right people in the decision-making process, such as an existing risk management group, process owners, and high-level management. Identify areas of work including business process and critical services that are paramount to achieve the organization’s mission and survival and focus the remaining steps of the implementation and operation process starting with those areas.

Step two is to implement a baseline set of security controls. It is recommended to start with the tools and capabilities that already exist within the organization. Again, identify any governing standards or regulations or begin by referencing accepted standards, such as the Insider Threat specific controls included in NIST SP 800-53 Revision 4 and above. For example, one might leverage an existing log collection mechanism from host operating systems with a particular focus on auditing user activity.

Once the capabilities of the current toolset have been fully implemented, identify and fill any gaps with new (or modified) security controls. For instance, if there are no controls to prevent or log data movement across network or storage boundaries, then that gap might be filled by a DLP component.

The next step is to measure the effectiveness of the implemented controls. This measurement is not purely the number of actors that have been caught (which may not be greater than zero due to the low base rate of occurrence for insider incidents). However, one goal of this phase, in the absence of a high frequency of true positives, is to reduce false positives and false negatives. This step also includes measuring the control implementation and the effectiveness of the surrounding procedures, such as how long it takes to complete case investigations or how long it takes to engage or receive information from other parts of the organization. The final aspect of this step is to measure the coverage of controls and maximize the percent of machines, users, or data repositories that are actively monitored.

Given these data and measurements, the final step to closing an iteration of the loop is to refine the controls and alerts in order to maximize effectiveness and maintain capabilities. The iterative and continuous nature of this approach is especially important when you are faced with things like changing organizational priorities, missions, personnel, technologies, and risks.

For more information, including a few potential software solutions for smaller organizations or new Insider Threat programs, see the Navigating the Insider Threat Tool Landscape: Low Cost Technical Solutions to Jump Start an Insider Threat Programi presentation at the 2018 Workshop on Research for Insider Threats as part of the 39th IEEE Symposium on Security and Privacy.

Please send questions, comments, or feedback to [email protected].

i Spooner, D., Costa, D., Silowash, G. & Albrethsen, M. Navigating the Insider Threat Tool Landscape: Low Cast Technical Solutions to Jump Start an Insider Threat Program. Software Engineering Institute, Carnegie Mellon University. To be published.

Posted on Leave a comment

Introducing Atlas: A Prototype for Visualizing the Internet

After 30 years, cyber command centers, educators, and Internet threat intelligence organizations have yet to embrace a standardized, encompassing, and intuitive way to represent the entities and activities of the Internet. Such a representation would make the Internet more understandable and allow shared situational awareness of Internet events and activities–the much-sought-after “Cyber Common Operational Picture.” This post describes Atlas: a working demonstration application for visualizing the Internet.

What Does the Internet “Look Like?”

Randall Munroe, creator of the webcomic xkcd, proposed a map of the IPv4 address space in 2006:


Source: under license CC BY-NC 2.5

He was definitely onto something: a better way to represent the Internet as a graphic. By better, I mean more intuitive than a “squashed bug” depiction, which provides no context:

squashed bug depiction of the InternetSource:

More relevant than a geographic overlay, which isn’t readable at scale, wastes visual real estate showing unpopulated areas (oceans, Antarctica, deserts, etc.), and overvalues the importance of geography relative to the Internet:

geographic overlay.pngSource: Research Pipeline

More predictable than a connectivity graph, which redraws continuously as nodes and connections change:

connectivity graph.png


So what attributes of an Internet visualization do I think are ideal?

Intuitive. With limited training and a basic understanding of the Internet, a user should be able to visually identify attributes of individual Internet entities (such as hierarchical relationships, scale, size, distribution, country of ownership, domain, reputation, etc.) using display techniques commonly found in apps and geographic map displays.

Contextual. The display should emphasize concepts most directly related to the Internet, such as IP addressing, network connectivity, and domain membership.

Visually efficient. The display, when viewed at a scale that still allows identification of individual sub-elements, should fit into a reasonable viewing area without including unused space. It should support both a useful global view as well as increasing granularity when exploring individual elements.

Predictable. Entities should consistently be in the same place relative to each other. This greatly improves the ability of a user to visually orient themselves and read the map.

What Do We Have to Work With?

  • Countries. Countries are an appropriate level of geographical granularity for Internet situational awareness because country-level legal restrictions and requirements often require commercial and government organizations to try to determine a user’s country of origin.
    • Autonomous Systems (AS). An Autonomous System is a collection of netblocks managed by a single entity or organization. AS are the highest level building blocks of the Internet.
      • Netblocks. Netblocks are the building blocks of AS. Each netblock represents a portion of the Internet usually belonging to a single entity or organization.
        • IP addresses. IP addresses belong to netblocks and represent end-point devices, servers, and Internet infrastructure.

Given these building blocks, could we build a map of the Internet that predictably and intuitively fixes the location for netblocks, while accounting for AS and countries?

“Really, displaying hundreds of thousands of individual netblocks?” you might ask. “With that number growing significantly each year?”

Well, yes, that is what I’m proposing. There’s even an analog: planet Earth.

The National Geospatial Intelligence Agency provides the Digital Terrain and Elevation Data (DTED) datasets. DTED Level 1 provides landform, slope, elevation and/or gross terrain roughness for Earth’s land surfaces in 100-square-meter chunks. Imagine a similar dataset for netblocks that includes identifying (ownership) information, the number of assigned IP addresses, services offered, and reputation/history data. If only we could figure out a way to draw the netblock “DTED-like” dataset using a projection that addresses the shortfalls of the other display options we discussed above.

Geographic cartography can help us out. All geographic maps throughout history have made arbitrary decisions about where to begin, what scale to use, what to include and exclude, and how to manage complications. Wikipedia lists dozens of unique map projections that attempt to represent the round Earth on a flat display, each making its own set of trade-offs and arbitrary reference decisions. What if we make a set of similar limiting assumptions about our Internet map?

Introducing Atlas

Atlas is an application originally developed by the SEI to display the results of research into Internet reputation, specifically to answer the question, “Can we display where ‘bad neighborhoods’ are on the Internet?” It was built using a commercial game development engine to explore the advantages and disadvantages of increased display interactivity.

Atlas has implemented two different projections, both based on three key elements: country, AS, and netblock. This blog post will discuss the first Atlas projection, Parallel Planes. I’ll discuss the second projection, Pangaea, in a future post.

The Parallel Planes projection creates two layered representations, both organized physically by country. The top layer displays ASNs as hexagons, while the bottom layer displays netblocks as squares.

Atlas_parallel planes.png

The upper layer represents AS, grouped by their country of registration. Beginning in the center of each hexagon with the lowest numbered AS (theoretically, the oldest), AS spiral out in AS numerical sequence. New AS will be added to the outer rim of the hexagon, allowing the innermost AS to remain relatively consistent and predictable. Each AS is represented by a hexagonal column, whose color and height are determined by the number of netblocks assigned to that AS.

Atlas_AS hexagons.png

The lower layer represents netblocks as individual square columns. Netblocks are grouped by country of physical location. Locating a netblock “in a country” is a key challenge for this projection, again highlighting an area for further analytical research. Within a country, netblock columns are arrayed in rows ordered by CIDR (Classless Inter-Domain Routing) prefix from lowest to highest. The color and height of each netblock column can be flexibly determined based on specific parameters of interest, such as number of IP addresses or aggregate reputation. For this implementation, netblocks are represented by graduated “reputation spikes” based on the total number of incidents reported by commercial threat intelligence companies for IP addresses within that netblock.

Atlas_netblock squares.png

Both layers of this projection are loosely geographic, in the sense that the hexagons and squares are arrayed as closely as possible to Earth’s geography (ignoring oceans, but respecting continental membership) while acknowledging that the land area of most countries is not a good representation of their Internet footprint. The resulting country layout is a geography much more relevant to the Internet while wasting considerably less display space. This is most apparent in a top-down view of both layers:

Atlas_top-down view.png

One of the most interesting abilities of this projection is to visually explore the relationships between AS and their component netblocks. Selecting an AS on the top layer will activate lines connecting that AS to all of its component netblocks, immediately showing AS that support netblocks in multiple countries.

Atlas_layer connections.png

Internet map projections could provide a canvas onto which information about Internet entities can be layered and displayed to make the enormous complexity of the Internet more accessible and understandable. A context-rich, cyber-specific, consistent, intuitive, and standardized visualization of the Internet could do for the Internet what Google Earth did for improving people’s understanding of, and access to, the physical world. Atlas is a prototype that I hope will elicit feedback and engender discussion about approaches to solving the Internet visualization gap. Send your thoughts to [email protected].