Windows Server Security:
How to Look for Suspicious Activities in Windows Servers

+ Bonus: How you can do that and more automatically

By: Sadequl Hussain

Scenario

You are running a large production environment with many Windows servers.

There are multiple forests in the network and some forests have multiple domain controllers.

Your Windows server security is paramount – you want to track and audit suspicious activities and view detailed Windows reports extracted from the Windows servers event logs. 

Looking for suspicious activities in Windows is important for many reasons:

  • There are more virus and malware for Windows than Linux.
  • People often leave their remote desktop sessions running when they disconnect, making those sessions prime targets for unauthorized takeover.
  • Service accounts are often made domain administrators circumvent access issues.
  • Known passwords of service accounts become open backdoors for hackers.
  • Antivirus and local firewalls are sometimes disabled to get acceptable application performance.
  • Patching cycles are missed or sometimes altogether ignored, making Windows systems vulnerable. to potential attacks.

Bottom line: Prevention is better than cure, that’s why all possible security measures should be taken.

Download XpoLog 7 free and discover suspicious events automatically!

Windows Server Security Reports

There should be a robust security monitoring process in place.

This type of monitoring keeps an eye on who or what’s logging into a Windows server and when, and if those log in events look suspicious or out of normal.

Keep an eye on who or what’s logging into a Windows server and when

This not only helps catch potential threats early, but it also provides a trail to follow when a breach happens.

Windows Reports – What to look for?

As a security conscious administrator, you want to keep an eye on a number of events such as:

  1. Successful or failed login attempts to the Windows network, domain controller or member servers.
  2. Successful or failed attempts of remote desktop sessions.
  3. Password lockouts after repeated login attempts.
  4. Successful or failed login attempts outside business hours.
  5. Adding, deleting or modifying local or domain user accounts or groups.
  6. Adding users to privileged local or active directory groups.
  7. Clearing event logs in domain controllers or member servers.
  8. Changing local audit policies and group policies.
  9. Changing or disabling Windows firewall or firewall rules.
  10. Adding new services, stopping or deleting existing services.
  11. Changing registry settings.
  12. Changing critical files or directories.

In this tutorial, we will talk about enabling some important security audits in Windows servers to help catch possible threats.

42 Critical Security Events To Follow

There are some critical security-related events you should include in your audit views and regular searches.

We have compiled a list of these event IDs and their descriptions in this helpful “cheat sheet”.

After reading this tutorial: you will have enough information to boost your Windows servers security level and workstation fleet and protecting them against malicious activities!

Windows Logs

Events in Windows are recorded in the event log.

There are three main types of logs native to Windows:

  • Application.
  • Security.
  • System log.

Investigation of vulnerabilities and breaches typically starts with these logs.

But how does Windows know which security-related events to write to these logs? And how does one know what to look for in these logs?

Read more about XpoLog’s Windows analysis app

Windows Audit Policies

The answer lies in something called audit policy.

With audit policy, you can define what types of events are tracked by Windows.

Whenever an event meets a policy setting, Windows records the event in the machine’s security log.

In a Windows workgroup, these policies are set in each individual server as local security policy, In a Windows domain it’s still possible to configure each machine’s local security policy, but typically the policy is set in Group Policy Objects (GPO) which is then applied to all member servers.

Before Windows Server 2008, audit policies were fairly generic.

Enabled policies would write a large number of events in the security log.

Finding the right information from logs was somewhat an unwieldy process.

These policy settings are still available, but it’s best to use the new advanced audit policies.

With advanced audit policy, it’s possible to pick and choose which events are trapped and sent to Windows security log.

The image below shows the legacy audit settings in an Active Directory domain controller group policy editor.

legacy audit settings in an Active Directory domain controller group policy editor.

And these are the advanced audit policies:

Advanced Audit Policies in Windows Server 2016

Advanced Audit Policies in Windows Server 2016

As you can see, there are ten main categories of policies for advanced auditing.

In each category, there are subcategories of events.

Each of these subcategories can be enabled or left disabled.

When enabled, they can be audited for success, failure or both.

Next, we are going to see which advanced audit policy subcategories should be enabled as best practice for tracking only log in related events.

Before doing that, we recommend making the following change from the Group Policy editor.

  • Under Computer Configuration, go to Policies > Windows Settings > Security Settings > Local Policies > Security Options
  • Enable the option “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings”.

This ensures advanced audit policy subcategories, when enabled, always override legacy audit settings.

This ensures advanced audit policy subcategories, when enabled, always override legacy audit settings.

Windows Reports – What To include and Monitor?

Here is a list of audit policy subcategories you can enable for security monitoring.

Policy Category: Account Logon
Enable SubcategoryConfigure Audit Event Settings
Audit Kerberos Authentication ServiceBoth success and failure
Audit Kerberos Service Ticket OperationsFailure
Since Windows Server 2000, Kerberos is the default authentication method for Windows domain accounts. Enabling these two subcategories will log successful and failed attempts of network login using Active Directory domain accounts.

A successful login attempt will show who logged in, from where and at what time.

A failure audit for Kerberos service ticket operations will show failed attempts to access network resources like file shares after a user has successfully logged in.

Policy Category: Account Management
Enable SubcategoryConfigure Audit Event Settings
Audit Computer Account ManagementBoth success and failure
Audit Other Account Management EventsBoth success and failure
Audit User Account ManagementBoth success and failure
When computer account management is audited, any attempt to add, modify or deleting a computer account from the Active Directory will be logged. This may be useful when a malicious user has used privileged access to install a Windows machine in the network and adds it to the domain to launch attacks from there.

“Audit Other Account Management Events” can track incidents when password hashes of user accounts are accessed, password policy or account lockout policy is changed.

Auditing user account management will capture events when

  • A user account is created, changed, deleted; renamed, disabled, enabled, locked out, or unlocked
  • A user account’s password is set or changed.
  • Permissions on administrative user accounts are changed
Policy Category: Detailed Tracking
Enable SubcategoryConfigure Audit Event Settings
Audit Process CreationSuccess
Audit Process TerminationSuccess
Audit process creation will log events when a program or user starts a process in the server. Similar to process creation, auditing process termination will log events when a user or program ends a process.

This is useful for tracking suspicious services being launched by malicious users or applications.

Policy Category: Logon/Log off
Enable SubcategoryConfigure Audit Event Settings
Audit Account LockoutFailure
Audit Group MembershipBoth success and failure
Audit LogoffSuccess
Audit LogonBoth success and failure
Audit Other Logon/Logoff EventsBoth success and failure
Audit Special LogonBoth success and failure
With these settings in place, Windows will generate an event when a user’s account is locked out after repeated login attempts.

Auditing logon will create events for successful or failed attempts to log in using a local account instead of an AD account. Similarly, the logoff event will show when a local account is logging off.

Both these events will show which group the user belongs to if the group membership audit is enabled.

The “other logon/logoff events” subcategory will capture events like remote desktop sessions, locking and unlocking workstations.

Finally, auditing special logons can show events when someone has been trying to start an application with the “Run as…” option. It can be also used to trap events when users of special groups are logging in.

Policy Category: Object Access
Enable SubcategoryConfigure Audit Event Settings
Audit Detailed File ShareBoth success and failure
Audit File ShareBoth success and failure
Audit File SystemBoth success and failure
Audit Other Object Access EventsBoth success and failure
Audit RegistryBoth success and failure
With these audit policy subcategories, it’s possible to monitor sensitive Windows resources like file shares or sensitive, registry settings or scheduled tasks.

We recommend not to enable “audit detailed file share” or “file share” settings in domain controllers. They should rather be set in Windows servers hosting shared directories.

Auditing file system access may sound like a great way of auditing, but you have to be careful about what you are auditing. For example, auditing database files for access can not only generate a continuously large stream of events, but it may also slow down the database. It’s best suited for sensitive files in file shares. Also, to audit file access, the System Access Control List (SACL) of the file needs to be enabled.

Enabling “Audit Other Object Access” will monitor events when Windows scheduled tasks are created, modified, deleted, enabled or disabled. This is useful when you have jobs from antivirus, malware protection or firewalls running in the server. Any attempt to stop these jobs will then be recorded.

Auditing registry is fairly similar to the auditing file system. Like files, SACL need to be configured for registry keys.

Policy Category: Policy Change
Enable SubcategoryConfigure Audit Event Settings
Audit Audit Policy ChangeBoth success and failure
Audit Authentication Policy ChangeBoth success and failure
Audit Filtering Platform Policy ChangeBoth success and failure
Audit MPSSVC Rule-Level Policy ChangeBoth success and failure
Changes to the audit policy itself can be tracked with the “audit policy change” subcategory. It also records changes made to the SACL of a file resource or registry key.

Auditing authentication policy changes will record events when:

  • Active Directory forests or domain trusts are created, modified or deleted (this subcategory should be enabled in Domain Controllers only)
  • Changes to Kerberos policy
  • A user or group is granted rights like “Access This Computer From the Network”, “Allow Logon Locally”, “Allow Logon Through Terminal Services”, “Logon as a Batch Job” or “Logon a Service”

To enable auditing of Windows Firewall, enable both the “Audit Filtering Platform Policy Change” and “Audit MPSSVC Rule-Level Policy Change” subcategories. This will ensure the following events are audited:

  • Changes to Windows Firewall policy
  • Changes to Windows Firewall rules
  • Changes to Windows Firewall exception list
  • Changes to Windows Firewall settings
  • Changes to rules ignored or not applied by Windows Firewall Service
  • Changes to Windows Firewall Group Policy settings
Policy Category: Privilege Use
Enable SubcategoryConfigure Audit Event Settings
Audit Sensitive Privilege UseSuccess
Sensitive privilege use auditing can capture events when files and directories are backed up, restored or their ownership is changed. It also generates events when device drivers are loaded or unloaded.

Other events include when computers or user accounts are trusted for delegation, security log management operations happen or a client is impersonated after authentication.

Policy Category: System
Enable SubcategoryConfigure Audit Event Settings
Audit Other System EventsBoth success and failure
Audit Security State ChangeSuccess
The “Other System Events” subcategory helps to audit when Windows Firewall service and driver is started or shut down. It also monitors events when cryptography key files are backed up or restored.

Auditing security state change can help monitor events when the computer’s time is changed or the system is shut down / started.

The policy category “Global Access Auditing” has two subcategories: “File system” and “Registry”.

These are similar to the subcategories “Audit File Settings” or “Audit Registry” under “Object Access”, except these policies are used to audit the entire file system or registry of a computer, not just files shares.

With these settings, a global SACL (System Access Control List) is applied to files, folders and registry keys of a machine and any changes to the SACL is audited.

We recommend not to set these audit subcategories unless there’s a compliance or regulatory requirement for the organization.

They may, however, be useful for tracking changes to a file server, although this may generate a large number of events for the server.

Creating Different Group Policy Audit Policies

Not all audit policies are applicable for every server in a domain.

For example, some settings are more applicable for domain controllers than member servers, and vice-versa.

To create a fine-tuned auditing process, we recommend creating different Group Policy Objects (GPO) for different types of servers (e.g. database servers, domain controllers, print servers, mail servers).

Audit policies for these GPOs can be then be customized for different types of audits and the GPO applied to Active Directory sites, domains or Organizational Units (OU).

To see what policies are applied to a member server, you can run the auditpol utility from the command prompt.

The snippet below shows the command and its partial output:

To see what policies are applied to a member server, you can run the auditpol utility from command prompt

Analyzing GPOs

As the number of GPOs increase, you may have different policies applied to the same machine with conflicting values for the same audit setting.

To ensure this does not happen, you can use the Policy Analyzer tool from Microsoft.

The Policy Analyzer utility can compare and analyze multiple Group Policy Objects (GPOs) for duplicate or redundant settings, inconsistent or conflicting values and highlight the differences.

The output can be exported to an Excel spreadsheet for further analysis. Policy Analyzer comes as part of Microsoft Security Compliance Toolkit.

Tools for Malware Detection

Besides auditing for suspicious activities, administrators can regularly scan Windows systems for malware.

This is not a substitute for running antivirus or regular patches, but an extra layer of protection.

There are many third-party malware detection tools, but it’s best to start with what Microsoft offers.

Running Windows Malicious Software Removal Tool (MSRT) can help find malware and reverts changes made by these apps.

The tool is generally released monthly as part of Windows Update. It can be also downloaded as a standalone software from Microsoft site.

Another tool to consider is Microsoft Safety Scanner.

It’s recommended administrators download the latest version of the tool every time they want to scan for malware.

Aggregating Logs and Creating Audit Views

Once your audit policies are set and you are happy with the events collected in different Windows servers, it’s time to combine those logs into one place.

There are two reasons for it:

  • First, anyone serious about causing harm to a system would delete any traces of intrusion. They will either delete all entries in the event log before leaving, or disable the audit policies when they log in. Having a centralized location ensures logs are continuously saved for later access.
  • Secondly, once logs are aggregated, they can be streamed to a SIEM tool like XpoLog. From there, you can run analysis, create visualization or drill down on specific events, These features are not natively available in Windows.

Follow this tutorial to see how Windows server logs can be aggregated into a central server.

You can also create custom audit views on aggregated logs.

Customized views in the Event Viewer can filter out logs to display only certain types of events. This can help quickly find any potential threat.

You can refer to this tutorial to see how custom views can be created in Windows Event Viewer.

Critical Security Event Numbers – Cheat Sheet

42 critical security-related events you should include in your audit views and regular searches.

Bonus Tip : How to Boost Your Windows Servers Security with Automation?

Discover Suspicious Activites, Errors, Audit Users Activity and more, in minutes.

Much of the work involved in log aggregation, complex searching and customizing views can be easily done with a good log management and SIEM solution like XpoLog.

XpoLog is a powerful log management tool widely used by IT organizations worldwide.

It offers easy setup and log aggregation, advanced search capabilities as well as powerful analytics, visualization and alerting features.

System administrators and IT operation teams can take advantage of XpoLog “apps” which are pre-packaged dashboards for different data sources.

For Windows, there are two out of the box apps with details Windows reports and analysis:

View Windows security event with ready to use dashboards and reports

Some readily available security insights from the Windows app include:

  • Windows Events Security Detection: this dashboard displays Windows login related analytics such as: unique number of users from all failed login attempts, top users with failed logins and more.

this dashboard displays Windows login related analytics such as unique number of users from all failed login attempts, top users with failed logins and more.

  • Firewall Rules: this dashboard shows Windows Firewall related events such as: number of firewall rules added or deleted over a period of time and firewall settings change report.

this dashboard shows Windows Firewall related events such as number of firewall rules added or deleted over a period of time and firewall settings change report.

  • Audit: widgets in this dashboard show suspicious logins by: server, number of audit success or failures events from the security log and so on.

widgets in this dashboard show suspicious logins by server, number of audit success or failures events from the security log and so on:

  • Application Installs and Updates: these two dashboards show successful and failed application installs and updates.

these two dashboards show successful and failed application installs and updates.

  • Services Activity: the Top Stopped Services widget in this dashboard can highlight if critical services like anti-virus, malware detection or firewall is stopped.

the Top Stopped Services widget in this dashboard can highlight if critical services like anti-virus, malware detection or firewall is stopped.

  • Registry: Registry Changes Per Server or Registry Changes Per User and the Top Changed Property widget can show which user account is making registry changes.

See how you can use XpoLog to monitor your Windows and Active Directory servers