mcafee enterprise security manager windows authentication ... › resources › sites › mcafee ›...

The information contained in this document is confidential and proprietary. Please do not redistribute without permission.

Windows Authentication Content Pack of 28

McAfee Enterprise Security Manager Windows Authentication Content Pack January 22, 2019



Contents

1 Introduction 3

2 Included Components 4 2.1 Alarms 4 2.2 Correlation Rules 4 2.3 Reports 4 2.4 Variables 4 2.5 Views 4 2.6 Watchlists 4

3 Prerequisites 5 3.1 Configure Windows Audit Policy 5 3.2 Add a Windows data source 5

4 Post-Installation Information and Configuration 6 4.1 Correlation Rules 6 4.2 Views 6

5 Use Case(s) 7 5.1 Successful Windows Logon Overview 7 5.2 Failed Windows Logons 10

6 Appendix A – View Details 13

7 Appendix B – Correlation Rule Details 25



1 Introduction It can become very challenging to sift through Microsoft Windows® events and determine welcomed versus unwelcomed logon events. There can be value in monitoring these events. A common misconception is that authentication events are only useful for identifying failed attempts. However, keeping track of successful authentication events can hold value as well.

The Windows Authentication Content Pack was created with the purpose of monitoring both failed and successful authentication events. Microsoft includes event logging in the Windows operating system which, in turn, keeps track of authentication events. These logs can be very beneficial to correlate certain authentication activities; however, due to the nature of a Windows domain, many logon events may be generated for one session. As such there will be more authentication logs than actual, physical, logons. It is important to understand how NTLM and Kerberos protocols function in order to better understand the events being displayed within this content pack’s components.



2 Included Components This section will detail the different components of the content pack.

2.1 Alarms This content pack does not contain any alarms.

2.2 Correlation Rules This content pack includes several correlation rules that are designed to trigger on every instance of a certain type of Windows authentication event. See Appendix B for details about the included rules.

• Windows Authentication – Administrator Account Logon on Vista-2008 or Later

• Windows Authentication – Administrator Account logon on 2000-2003-XP

• Windows Authentication – Admin Logon From Non-Company Geolocation on Vista-2008 or Later

• Windows Authentication – Admin Logon From Non-Company Geolocation on 2000-2003-XP

• Windows Authentication – Admin Logon From Suspicious Geolocation on Vista-2008 or Later

• Windows Authentication – Admin Logon From Suspicious Geolocation on 2000-2003-XP

• Windows Authentication – Restricted Domain Account Failed Logon

• Windows Authentication – Domain User Failed Logon Due To Invalid Password

• Windows Authentication – Domain User Logon After Multiple Failed Attempts

• Windows Authentication – Failed Domain Logon on Restricted Host

• Windows Authentication – Failed Logon Due to Invalid Domain Username

• Windows Authentication – Domain Account Created

2.3 Reports This content pack does not contain any reports.

2.4 Variables This content pack does not contain any variables.

2.5 Views The views give a good look into various authentication events from Windows devices on the network. See Appendix A for examples of views.

• Detailed Successful Windows Logons

• Successful Windows Logon Overview

• Correlated Admin Logons

• Correlated Built-in Account Admin Logons

• Correlated Service Account Admin Logons

• Correlated Successful Admin Logon Overview

• Admin Logons By Normalization

• Built-in Account Admin Logons By Normalization

• Service Account Admin Logons By Normalization

• Successful Admin Logon Overview By Normalization

• Windows Accounts Created

2.6 Watchlists This content pack does not contain any watchlists.



3 Prerequisites The following are required in order to use the components provided in this content pack.

3.1 Configure Windows Audit Policy In order to monitor Windows security events, the Windows audit policy must be properly setup. It is this policy that will regulate the amount, type, and number of events that are logged. Depending on the network, local and domain polices will need to be properly configured. Furthermore, depending on the environment, “Audit account logon events” or “Audit logon events” will need to be configured accordingly. More information on configuring the Audit Policy can be obtained at https://technet.microsoft.com/en-us/library/cc952128.aspx.

3.2 Add a Windows data source A Windows data source must be setup to receive events from Windows devices within the network environment.

https://technet.microsoft.com/en-us/library/cc952128.aspx



4 Post-Installation Information and Configuration Now that the Windows devices have been configured and the events are being forwarded to the McAfee ESM, the components of the content pack may need to be tuned for the environment they are being used in.

4.1 Correlation Rules In each of the rules, the parameters can be adjusted to match the environment in which they will be deployed.

4.2 Views Just as some of the correlation rules may need to be adjusted, the included views may also need to be calibrated to meet the needs of the environment in which they are deployed.



5 Use Case(s) The following use cases will go through a few examples of how the components provided in this content pack may be beneficial. A use case for both successful and failed authentication events will be shown in the sections that follow.

5.1 Successful Windows Logon Overview For the first use case, an example of how to view abnormal or interesting successful logon activity will be shown. There are several views that can be useful depending on the type of events being investigated. A good place to begin in order to obtain a high-level overview of the network might be the “Successful Windows Logon Overview” view. This view divides successful authentication events into three main categories: human logons, Service account logons, and built-in accounts. Over time, noticeable trends with specific usernames, hosts, and domains should become apparent. This will help identify names that may seem out of place, new, or unusual. This particular view can be a good starting point because it offers the user a broad look at many different domains within the network and allows for further analysis by drilling down for more details.

Image 5.1.1 shows how successful logons are divided between the categories mentioned previously. This can help bring focus to specific sources with corresponding events occurring within a similar time window. One example is being able to view an abnormal amount of human logons from a particular user around the same time that an abnormal amount of Service account logons are occurring.

Image 5.1.1

Image 5.1.1 shows an example overview of some network activity. There are various logon events being split between human logons (at the top), Service Account logons (in the center), and built-in account logons (on the bottom). In this example, human logons will be the focus.



As shown in image 5.1.2, there appears to be an abnormal amount of logon events in the distribution graph as indicated by the largest spike.

Image 5.1.2

This may seem a bit suspicious to have such a high amount of logon activity from this specific user at this time. Starting with the Windows Domains on the far left, different domains can be selected to narrow down which host or hosts that these logon events have occurred on. After selecting the “mcafee-intel.net” domain, hosts within that domain which are showing successful logon events will be displayed. By default, all hosts are selected to begin with, and the source users that have caused events on those hosts are shown immediately to the right. From here, it can be seen that the user “Jared@mcafee-intel” seems to have a lot of logon events compared to the other users. Once the user in question is selected, the distribution graph on the right will only show the activity from that user. There are some apparent spikes in activity over the week and further focus can be given on the specific events that caused the spikes. Image 5.1.3 shows the set of panes together as they are in the view. Image 5.1.4 and 5.1.5 contain the same information as image 5.1.3 but are split up to make viewing the data easier.

Image 5.1.3



Image 5.1.4

Image 5.1.5

Looking at image 5.1.5, it can be observed that there is an apparent spike in activity from the user “Jared@mcafee-intel”, on the “mhs12dc.mcafee-intel.net” host, within the “mcafee-intel.net” domain.

Image 5.1.6

Using the distribution graph, the spike of activity in question can be focused on by using the zoom function. Image 5.1.6 shows that this user had 68 logon events between 4:23 PM and 4:33 PM. This time frame can now be used for further analysis.

The events shown in the distribution pane image 5.1.6 can be drilled down on to find more details about these events. The drilldown function that is built into the McAfee ESM can be used to view the individual events. This function is accessed by selecting the menu button in the upper-left corner of the distribution



window pane (image 5.1.6). After selecting the menu button, you will need to go to “Event Drilldown”, and then the sub-menu category of “Events”. An example of this is shown in image 5.1.7 below.

Image 5.1.7

The drilldown presents the actual events that contributed to the spike on the distribution chart. In image 5.1.8 the source IP address, source user, port, event subtype, etc. can all be seen. This will be helpful in better understanding where the logons came from, who the logon was generated for, and what kind of Windows logon event that this was. For this particular event, it turns out that it was Windows Security Event 4769, “A Kerberos service ticket was requested”. Windows uses this event ID to indicate that service tickets have been granted. Windows grants service tickets whenever a user or computer accesses a server on the network. Further investigation can now be worked on using these authentication events.

Image 5.1.8

5.2 Failed Windows Logons In this use case the focus will be on failed logon events. The “Failed Windows Logons” view presents a quick overview of logon events within the network that have failed authentication. The rule messages presented at the top left make it simple to see why a particular logon failed. The event can then be filtered down to display the individual events, showing where they came from and how often they have occurred.



Image 5.2.1

Looking at image 5.2.1 a lot of failed logon events are showing up in the first pane. Typically you would want to investigate many, if not all, of these events. For the purpose of this use case the “Bad Username or Password” events that can be seen in image 5.2.1 will be focused on. Once the rule message has been selected in the Windows Failed Event Summary section, information about that event will be displayed within the view. If a “logon type” has been associated with the events, it will be displayed directly to the right. This information can be helpful in better understanding the type of logon that was attempted, with the option to filter by any of the displayed logon types. Two distribution graphs are provided to assist in understanding the events. The first graph will display information for all “Bad Username or Password” events while the second graph will display information about a specific domain, host, or user that has been selected within the view. The domains that the events occurred in, along with the hosts and usernames associated with the events, will be displayed with the option either view information about all domains, or to give specific focus. In this example, multiple failed logons have occurred from one user across two domains, but all events are coming from one host. This host shows several usernames, but for now focus will be given to the user “jared”. Several failed authentication events occurred back in early November, but no failed logon activity occurred again until the next month. This may indicate a user who has a difficult time remembering their password each time it is changed, or it may indicate someone making malicious logon attempts with time between to avoid bringing attention to their attempts.

Lastly, more specific details about these logon attempts can be viewed in order to get a better picture of what is happening. By selecting the events it will show the details that can be seen in image 5.2.2 below.



Image 5.2.2

More information can be seen by selecting the “Custom Types”, as seen in image 5.2.3.

Image 5.2.3

From the information that has been gathered, it looks like there were several logon attempts between 11/11/2014 18:34:26 and 11/13/2014 22:01:37. The custom types tab reveals that the logons were logon_type “interactive”. An interactive logon is a logon at the console of a computer, which tells us that this user was physically attempting a logon with a keyboard at a logon screen. At this point, further investigation can be done if needed.



6 Appendix A – View Details

6.1 Detailed Successful Windows Logons

This view filters on specific signature ID’s with an Event Subtype of “success”.

Looking at the view below, the event rule message is displayed to give a good overview of logon events. To the right, logon types are displayed, along with a stacked graph to easily view spikes and drops in activity. This will aid in watching for abnormalities in events. This view allows filtering from the rule message to the domain, host, source user, and finally the individual events. A secondary graph is provided in order to see specific domain, host, and user event activity as they are filtered.

Image 6.1.1



6.2 Successful Windows Logon Overview This view has three different, yet similar filters. Each filter contains an event subtype of “success” within a specific set of signature IDs. A different filter is applied to each of the left-most panes within the view.

• The first filter removes Windows Service and built-in account logon activity.

• The second filter includes only events that contain a source user with a ‘$’ symbol (indicating a Service account).

• The final filter includes Windows built-in accounts.

The view below provides a general overview of authentication events coming from human logons, Service account logons, and built-in account logon events. Starting on the left, the events are first filtered by domain, then host, and finally the individual users.

Image 6.2.1



6.3 Correlated Admin Logons This view is filtered by removing Windows Service and built-in accounts that are correlated to an admin logon from rules included in this content pack. It uses the rules titled “Windows Authentication – Administrator Account Logon on Vista-2008 or Later” and “Windows Authentication – Administrator Account Logon on 2000-2003-XP”. Looking at the view below, a distribution graph is provided to allow observation of logons, followed by a pane that displays source users that have correlated as successful human administrator logons. The distribution graph will allow a user to select a specific time range to filter the information. Each source user can then be filtered down to the domain, host, and eventually to the individual events. A secondary graph is provided in order to see specific domain, host, and user event activity as it is filtered.

Image 6.3.1



6.4 Correlated Built-in Account Admin Logons This view is filtered by Windows built in accounts that have been correlated as an admin logon from rules included in this content pack. It uses the rules titled “Windows Authentication – Administrator Account Logon on Vista-2008 or Later” and “Windows Authentication – Administrator Account Logon on 2000-2003-XP”. Looking at the view below, a distribution graph is provided to allow observation of logons, followed by a pane that displays source users that have correlated as successful Windows built-in account logons. The distribution graph will allow a user to select a specific time range to filter the information. Each source user can then be filtered down to the domain, host, and eventually to the individual events. A secondary graph is provided in order to see specific domain, host, and user event activity as it is filtered.

Image 6.4.1



6.5 Correlated Service Account Admin Logons This view filters for any source user that is considered a Windows Service account by adding in any source user with a ‘$’ symbol in addition to looking for events correlated to an admin logon from rules included in this content pack. It uses the rules titled “Windows Authentication – Administrator Account Logon on Vista-2008 or Later” and “Windows Authentication – Administrator Account Logon on 2000-2003-XP”.

Looking at the view below, a distribution graph is provided to allow observation of logons, followed by a pane that displays source users that have correlated as successful Windows Service account logons. The distribution graph will allow a user to select a specific time range to filter the information. Each source user can then be filtered down to the domain, host, and eventually to the individual events. A secondary graph is provided in order to see specific domain, host, and user event activity as it is filtered.

Image 6.5.1



6.6 Correlated Successful Admin Logon Overview This view has three different, yet similar filters. Each filter uses the rules titled “Windows Authentication – Administrator Account Logon on Vista-2008 or Later” and “Windows Authentication – Administrator Account Logon on 2000-2003-XP”. A different filter is applied to each of the left-most panes within the view.

• The first filter removes Windows Service and built-in account correlated logon activity.



The view below provides a general overview of correlated authentication events coming from human logons, Service account logons, and any other logon event. Starting on the left, the events are first filtered by domain, then host, and finally the individual users.

Image 6.6.1



6.7 Admin Logons by Normalization This view filters on any “human logon” event within a specific set of signature IDs. Anything that has been decided not to be considered a human logon has been filtered out. Looking at the view below, a distribution graph is provided to allow observation of logons, followed by a pane that displays source users that have been identified as admin accounts. The distribution graph will allow a user to select a specific time range to filter the information. Each source user can then be filtered down to the domain, host, and eventually to the individual events. A secondary graph is provided in order to see specific domain, host, and user event activity as it is filtered.

Image 6.7.1



6.8 Built-in Account Admin Logons By Normalization This view filters on any logon event within a specific set of signature IDs. This will include specific Windows built-in account names.

Looking at the view below, a distribution graph is provided to allow observation of logons, followed by a pane that displays source users that have been identified as admin accounts. The distribution graph will allow a user to select a specific time range to filter the information. Each source user can then be filtered down to the domain, host, and eventually to the individual events. A secondary graph is provided in order to see specific domain, host, and user event activity as it is filtered.

Image 6.8.1



6.9 Service Account Admin Logons by Normalization This view filters on any event with a source user that contains a ‘$’ with a subtype of “success” within a specific set of signature IDs. Looking at the view below, a distribution graph is provided to allow observation of logons, followed by a pane that displays source users that have correlated as successful Windows Service account admin logons. The distribution graph will allow a user to select a specific time range to filter the information. Each source user can then be filtered down to the domain, host, and eventually to the individual events. A secondary graph is provided in order to see specific domain, host, and user event activity as it is filtered.

Image 6.9.1



6.10 Successful Admin Logon Overview by Normalization This view has three different, yet similar filters. Each filter contains an event subtype of “success” within a specific set of signature IDs. A different filter is applied to each of the left-most panes within the view.

• The first filter removes Windows Service and built-in account logon activity.



The view below provides a general overview of authentication events coming from source users with administrator privileges. Logons will be displayed for human logons, Service account logons, and built-in account logon events. Starting on the left, the events are first filtered by domain, then host, and finally the individual users.

Image 6.10.1



6.11 Failed Windows Logons This view filters on specific signature IDs with an Event Subtype of “failed”.

Looking at the view below, the event rule message is displayed to give a good overview of failed logon events. To the right, logon types are displayed, along with a stacked graph to easily view spikes and drops in activity. This will aid in watching for abnormalities in events. This view allows filtering from the rule message to the domain, host, source user, and finally the individual events. A secondary graph is provided in order to see specific domain, host, and user event activity as they are filtered.

Image 6.11.1



6.12 Windows Accounts Created This view filters on Windows Events 4720 (Windows Vista+) and 624 (Windows 2000-2003/XP). These events will trigger when a user account has been created on either the domain or local level.

Looking at the view below, domains within the network are displayed, followed by a pane displaying new accounts created. As account names are selected, the “Account Created By” pane will filter to display the Source User that created the new account, along with associated event details below. Two dials have been added to help show both distinct new accounts created, as well as Service Accounts. A Service Account is filtered as any account name that ends with a dollar ($) symbol. Watching the activity of every Service Account can prove difficult due to how many exist, and how much activity they are involved with. This view can help analysts keep watch for any new accounts having been created once a baseline has been established.

Image 6.12.1



7 Appendix B – Correlation Rule Details

7.1 Windows Authentication – Administrator Account Logon on Vista/2008 or Later This rule detects the occurrence of a successful logon with elevated rights on a Windows host.

A successful logon with elevated rights is not an immediate indicator of nefarious activity, and in fact, may be perfectly normal. However, it is important to keep track of users logging in with elevated privileges. There may be many instances of service account activity that will not be an indicator of human activity. It is important to watch for unusual activity involving privileged user accounts.

Parameter Defaults:

• Time_Window: 1 second

• Number_of_Events: 1 event

7.2 Windows Authentication – Administrator Account Logon on 2000/2003/XP

This rule detects the occurrence of a successful logon with elevated rights on a Windows host. A successful logon with elevated rights is not an immediate indicator of nefarious activity, and in fact, may be perfectly normal. However, it is important to keep track of users logging in with elevated privileges. There may be many instances of service account activity that will not be an indicator of human activity. It is important to watch for unusual activity involving privileged user accounts. Parameter Defaults:



7.3 Windows Authentication – Admin Logon from Non-Company Geolocation on vista/2008 or Later This rule detects the occurrence of a successful logon with elevated rights on a Windows Vista/2008 or later host outside company geolocations. A successful logon with elevated rights outside company geolocations should be considered suspicious. It is possible that an employee may be using a proxy service and forgot to disconnect before logging in, or may actually be in a location that is not part of the Company Geolocation list. It is important to watch for unusual activity involving privileged user accounts. This is especially true for those that come from geolocations that are not defined as Company Geolocations. Parameter Defaults:



7.4 Windows Authentication – Admin Logon from Non-Company Geolocation on 2000/2003/XP This rule detects the occurrence of a successful logon with elevated rights on a Windows 2000/2003/XP host outside company geolocations.



A successful logon with elevated rights outside company geolocations should be considered suspicious. It is possible that an employee may be using a proxy service and forgot to disconnect before logging in, or may actually be in a location that is not part of the Company Geolocation list. It is important to watch for unusual activity involving privileged user accounts. This is especially true for those that come from geolocations that are not defined as Company Geolocations. Parameter Defaults:



7.5 Windows Authentication – Admin Logon from Suspicious Geolocation on Vista/2008 or Later This rule detects the occurrence of a successful logon with elevated rights on a Windows Vista/2008 or later host from a suspicious geolocation. A successful logon with elevated rights with an IP address from a suspicious geolocation should be looked into further. It is possible that an employee may be using a proxy service and forgot to disconnect before logging in, or may actually be in a suspicious geolocation. It is important to watch for unusual activity involving privileged user accounts. This is especially true for those that come from a suspicious geolocation.

Parameter Defaults:



7.6 Windows Authentication – Admin Logon from Suspicious Geolocation on 2000/2003-XP This rule detects the occurrence of a successful logon with elevated rights on a Windows 2000/2003/XP host from a suspicious geolocation. A successful logon with elevated rights with an IP address from a suspicious geolocation should be looked into further. It is possible that an employee may be using a proxy service and forgot to disconnect before logging in, or may actually be in a suspicious geolocation. It is important to watch for unusual activity involving privileged user accounts. This is especially true for those that come from a suspicious geolocation.

Parameter Defaults:



7.7 Windows Authentication – Restricted Domain Account Failed Logon This rule detects multiple failed logon attempts for an expired, disabled, or time restricted Windows domain account.



Not every failed logon from an expired, disabled, or time restricted account is an immediate indicator of nefarious activity. However, having multiple events occur on the same source in a short time period is suspicious and should be looked into further. It is possible that a user has added their credentials to be used by a host automatically, and the host is attempting to authenticate with credentials that are invalid. It may be that the user is not aware of time restrictions that are set in place. These events could also be an indicator of someone attempting to use credentials that are no longer valid for one reason or another; or that someone is attempting to gain access to a system outside of business hours. These attempts may originate from an internal or external source. View the events that triggered this alert for specific details. Parameter Defaults:

• Time_Window: 10 minutes


7.8 Windows Authentication – Domain User Failed Logon Due to Invalid Password This rule detects a failed logon with a Domain Username on a Windows Domain due to an incorrect password. Recurring failed login attempts generally means one of two things: a user cannot remember their password, or an attacker is attempting to guess the required credentials. If the former is true, this is not a serious incident. In this case, a failed logon attempt has occurred on a Windows Domain account in your network. If this event was triggered by the actions of an attacker, they will likely continue to try until they gain access. Parameter Defaults:



7.9 Windows Authentication – Domain User Logon after Multiple Failed Attempts This rule detects multiple failed logon attempts with a Windows Domain username due to an incorrect password, followed by a successful logon within the specified time window. Recurring failed login attempts followed by a successful login generally mean one of two things: a user had difficulty remembering their password, or an attacker is attempting to guess the required credentials. If these events were triggered by a forgotten, and then remembered, password then this is not a serious incident. However, if these events were triggered by the actions of an attacker then actions should be taken immediately to stop the attack. At this point the attacker could potentially monitor, impersonate or hijack confidential data using the compromised account/host.

Parameter Defaults:



• Failed_Events: 3 events

• Failed_Event_Time_Window: 10 minutes

7.10 Windows Authentication – Failed Domain Logon on Restricted Host This rule detects the occurrence of failed logon attempts on a restricted Windows host using a domain account.



A user has been detected attempting to logon to a Windows host of which access has been restricted. More than likely, the user has made the attempt without knowledge of the restriction set in place. While a single event is not typically cause for alarm, multiple attempts with may be an indicator of suspicious activity and should be looked into further. Parameter Defaults:



7.11 Windows Authentication – Failed Logon Due to Invalid Domain Username This rule detects the occurrence of failed logons due to an invalid username on a Windows domain client. A user has been detected attempting to logon to a Windows client with an invalid domain account. More than likely, the user has mistyped their username or may be using the wrong username by mistake. However, invalid usernames are not as common as invalid passwords, and while a single event is not typically cause for alarm, multiple attempts with may be an indicator of suspicious activity and should be looked into further.

Parameter Defaults:



mcafee enterprise security manager windows authentication ... › resources › sites › mcafee ›...

Documents