KHIKA App for Windows AD

Introduction

Windows AD servers form an important part of organisations’ networks and hence by monitoring your windows AD servers is imperative.

With KHIKA App for Windows AD servers, you can :

• Monitor hundreds of windows servers at one central place Event logs can be used to identify live attack vectors such as brute force attempts, communication with bad IPs, account lockouts and many others.
• Monitor access to and activities on your critical server assets.
• Use Actionable dashboards showing gaps in secured configuration and hardening of the severs.
• Do File integrity monitoring.
• Check hardening posture of your servers by ensuring secured configuration is always maintained.

We explain below steps to configure and interpret the output of KHIKA App for Windows AD Server. The key parts to get here are:

1. Install the KHIKA App for Windows AD
2. Get data from your Windows AD Server into KHIKA Aggregator

How to Install the KHIKA App for Windows AD?

The section assumes that you have already configured KHIKA Data Aggregator in your environment. If not, please read how to configure KHIKA Data Aggregator and perform the pre-requisite steps.

This section explains how to pick and install the KHIKA application for Windows AD Servers. Installing the application shall put together and activate the adapter (parser) that can handle Windows data format, the dashboards and the alert rules preconfigured.

Go to “Applications” tab in the “Configure” menu.

Check whether the appropriate Workspace is selected. Note: Application is always loaded in a Workspace. Read the section on Workspaces to know more about KHIKA Workspaces. Also select your KHIKA aggregator name in the Node dropdown. This is to ensure that we are collecting data from the desired source and into the correct workspace which is ready with the configured application and components.

Click on the “+” button next to the Windows Server App. A pop up appears.

Users can now select the contents of the application required. For example, on the dropdown for “Reports”, click to expand it. List of all reports can be seen. User can individually select the reports required by checking on the checkbox next to each. Alternatively, check on “Select All” option to get all of them. Similarly you can select contents from Alerts and Dashboards.

What are KHIKA Reports

What are KHIKA Dashboards

What are KHIKA Alerts

Click “Install” to proceed with the installation of the selected Application. If you have created multiple windows workspaces in KHIKA, and installed Windows App previously, you will get below pop up.

Click on OK to proceed. If this is not the case, ignore this step. After successful installation, following status should be displayed.

Click on Close button. This simple procedure to install a KHIKA App, automatically configures the Adapter (required for parsing the data from raw syslogs), calculated KHIKA reports on raw data, Visualizations, Dashboards and Alerts – all in one click.

How to get your Windows AD data into KHIKA ?

KHIKA recommends, popular open source OSSEC integration to monitor the Windows AD servers. There are 2 components in OSSEC Integration with KHIKA.

1. OSSEC Agent – Installed on each Windows AD server which we wish to monitor
2. OSSEC Server – Present on KHIKA Data Aggregator (which you have installed before)

The OSSEC agent and server communicate with each other using a unique key for encryption. The main steps to start getting data from a Windows server are

1. Add the Windows AD server details in KHIKA
2. Extract a unique key for this device from KHIKA
3. Installing Ossec Agent on Windows AD Server
4. Insert this key in the Ossec agent (ie. on your Windows AD server to be monitored)
5. Reload Configuration in KHIKA
6. Verify data collection in KHIKA

Each of these steps is explained in detail in the further sections.

Adding the device in the KHIKA

Go to Adapter tab, from the “Configure” menu. Click on the “Manage Devices” icon.

Pop up appears for device details

Click on “Add / Modify Device” tab. Another pop up appears for device details.

Enter the expected device name. Also, in the field for IP address, enter “any”. Please note : Always enter the IP Address as “any”. This is a safe and sure option to establish a connection with the server where we are suggesting ossec agent to use “any” of its configured IPs to be used to connect with the OSSEC Server. The device may have multiple NIC cards/IP addresses and unless we are sure of what IP will be used for connection, the connect will fail. Hence, use “any”

Select appropriate time zone of this device. In the “Node” field dropdown, select the name of the Aggregator or local data collector for this device. Click on Submit. We get a success message and device is added successfully to this adaptor.

Finally, go to Workspace tab and click on “Apply Configuration” icon.

We get a confirmation message here too, saying, “Changes Applied”

Extract key from KHIKA OSSEC Server

Now the expected Windows server is added in the relevant KHIKA Adapter or parser that will parse this data type. To see this device entry, click on “Manage Devices” icon next to the adaptor .

A pop up with device details of the adaptor appears. Select “List of Devices” tab.

Click on the “Get OSSEC Key” icon next to this device.

This is the unique key for this device created by the OSSEC server. Paste this key in the Ossec agent which is installed on this Windows server.

Installing OSSEC Agent for Windows

Download OSSEC agent for Microsoft Windows from KHIKA install directory. The agent is shipped with KHIKA installer and is located on KHIKA Server in /opt/KHIKA/UTILS/OSSEC directory. For Windows you will need to select the Windows installer with filename ossec-win32-agent.zip. This works for both 32-bit and 64-bit windows servers OS versions.

Copy the downloaded installer on your Windows server (using winscp or your favourite scp client) and run installer with local "Admin" on the Server. Please Note : It is extremely important to install the OSSEC agent with admin privileges as this agent reads the security logs and in order to read it successfully, it has to be the local Admin. Select the installer file and Press "Run"

Click Next

Select "I Agree" and proceed

Keep the default selection in the next window and click Next

Enter the location to install the OSSEC agent on the local drive and let the installation complete

After the installation is complete, verify that the OSSEC HIDS Service is successfully installed on your Windows Server. (Go to your Service Control Panel and check for OSSEC HIDS Service)

NOTE :- You will have to repeat these steps on all the Windows Servers that you wish to monitor using KHIKA.

Insert unique OSSEC key in Windows OSSEC Agent

Perform following simple steps on the Windows Agent In the OSSEC Agent installation directory, run win32ui.exe to open-up a window as shown below – Run as Administrator.

In the field “OSSEC Server IP” - Enter the IP Address of the KHIKA data aggregator or collector node and paste the copied key (generated by OSSEC server above) in the box against "Authentication key" and click Save. From "Manage" drop-down, select "Restart" to restart the OSSEC Agent. Click on the Refresh button in the bottom next to Save.

Wait for a few minutes. Repeat above steps for all the agents to be added.

Reload Configuration

Login into the KHIKA portal. Go to Configure, Select workspace, eg. WINDOWS_SERVERS  Go to Node Tab  Click Reload Config

This step restarts OSSEC Server. Wait for a few minutes for server to restart.

Verifying OSSEC data collection

Once the device is added successfully, we can check the data for this device on Discover screen. Go to “Discover” from the main menu. Select the appropriate index for the same. Raw (khika formatted) data of all your Windows servers added is seen here.

To see the data for our newly added device, enter search string in lower case – tl_src_host : name_of_the_device_added_in_lower_case and click on the search icon.

How to check the output of KHIKA Windows App ?

Locked accounts Dashboard

An account getting locked could be due to unwarranted attempts to guess someone else’s password. This dashboards pinpoints the users and machines where accounts locked events occurred. Unusual incidents are easier to identify and analyse in the KHIKA dashboard.

Elements in the Dashboard are explained below :

Elements in Locked accounts Dashboard

Visualization	Description
User wise machine name bar graph	X axis : Usernames Y axis : One or more machine names from where this user got locked out while trying to log into Windows Server and count of such events
Machine name wise locked user pie	Multi level pie chart. Inner level is the contribution of machine names. For any selected machine here, outer level shows all the users who tried to login and got locked out for this.
Time trend	Trend of login events over time. Useful to identify unusual spikes at a glance. X axis : date & time Y axis : count of events
Summary Table	Detailed data with timestamp and count

Some suggestions for useful interaction with this dashboard could be :

1. In the graph "User wise Machine name" click and thus select any one username. This shall isolate the respective user's actions and will be reflected accross the dashboard. ie the other pie charts, time trends and summary table shall show filtered information for this user only.
2. Alternatively, in the pie chart "Machine Name Wise Locked User" click on the inner level of pie chart which shows machine names. This shall isolate the machine which will then show which users were locked out on the same.

Multiple Terminal login Dashboard

Same user connected from multiple workstations doesn’t happen under usual circumstances. Hence this report helps regular monitoring of such incidents. It has details like which user logged in from which workstation how many times. This makes it easier to isolate events at the user or workstation level and see the metrics.

Elements in the Dashboard are explained below :

Elements in Multiple Terminal login Dashboard

Visualization	Description
Contribution of users pie	This pie chart shows all the usernames occupying space according to the number of times they were logged in concurrently from multiple devices.
User wise login count	X axis : Names of users Y axis : Count of such events for each user
Summary Table	Detailed data with timestamp and count

Some suggestions for useful interaction with this dashboard could be :

1. On the bar graph "User wise login count" if there is any one bar with a particularly large count of events, click on that bar for that user. You can now check out details for this user and his multiple logins in the summary table below.
2. Inversely, in the "Contribution of Users" pie, if a particular username is occupying larger chunk of the pie, click on the user to select and rest of the elements on the dashboard then show data for that user only.

Host wise Logon Dashboard

This dashboard monitors machines for access. ie. login activities of users on different servers. Who logged in and from which host.

Elements in the Dashboard are explained below :

Elements in Host wise Logon Dashboard

Visualization	Description
Contribution of servers pie	Contribution of servers, according to logon events occurred.
Contribution of users pie	Contribution of usernames according to logon events occurred.
Server wise passed failed login count	X axis : Server names Y axis : Count of login failures and successes on each server
Time trend	Trend of login events over time. Useful to identify unusual spikes at a glance. X axis : date & time Y axis : count of events
Summary Table	Detailed data with timestamp and count

Some suggestions for useful interaction with this dashboard could be :

1. Click on and select a particular server from the pie chart "Contribution of Servers". The next pie for users and the graph below for successful and failed logins shall give you a quick picture of which users have access to this server and how many times / count of login attempts and hence usage.
2. On the graph "Server wise passed failed login count" if any bar has a high count on the y axis - you can click on it. The server and its user and login information shall be seen in the rest of the pie charts and summary table too.

Windows AD logon failures

This dashboard shows a summary of logon failures, the host from which logon attempts were made to the windows server which we are monitoring, IP addresses, logon type, process details, domain details, reasons for failure etc. This information gives helpful insights into user activity.

Elements in the Dashboard are explained below :

Elements in Windows Ad logon Failure Dashboard

Visualization	Description
Contribution of Servers pie	Contribution of machine names according to the number of logon failure events.
Contribution of Users pie	Contribution of user names according to the number of logon failure events
Contribution of Domains pie	Contribution of domain names
Contribution of Logon type pie	Contribution of Logon type
Workstation wise remarks bar graph	X axis : workstation names Y axis : the count of logon failure events and remarks for each.
Time trend	Trend of login events over time. Useful to identify unusual spikes at a glance. X axis : date & time Y axis : count of events
Summary Table	Detailed data with timestamp and count

Windows Server Hardening Dashboard

Server Hardening is the process of enhancing server security through a variety of means which results in a more secure server operating environment. This is due to the advanced security measures that are put in place during the server hardening process. KHIKA checks each server against out-of-box server hardening policies to ensure your servers are securely configured. It helps you to pinpoint and tune the exact details on hosts for better security posture. The server hardening policies against which the servers are checked can be seen here.

Elements in the Dashboard are explained below :

Windows Server Hardening Dashboard Details

Visualization	Description
Contribution of status pie chart	Failed or Passed compliance status
Server wise Hardening Status	X axis : Windows servers added into KHIKA Y Axis : stacked within each bar (server) the count of failed / passed events for various rules / policies
Policy wise status	X axis : Policy names Y axis : stacked with each bar (policy) count of failed or passed servers for that policy
Time trend	Trend of login events over time. Useful to identify unusual spikes at a glance. X axis : date & time Y axis : count of events
Summary Table	Detailed data with timestamp and count

Some suggestions for useful interaction with this dashboard could be :

1. Click on “Failed” in the “Contribution of Status” pie chart. The rest of the dashboard gets filtered and shows only Failed events. Enables having an easier look at the servers / policies which failed more often
2. Click on a particular server in the bar “Server Wise Hardening Status”. Also click on the “Failed” in the above pie. This isolates the actionable inputs that you need to tune the server in question.

KHIKA Alerts for Windows AD

Alerts are generated when certain ciritical behaviour is observed in the system – real time and notified on the Alerts Dashboard in KHIKA as well as can be received in email to relevant stakeholders. The details of KHIKA Alerts are mentioned here Click on “Alert Dashboard” on left menu. Certain alerts for Windows are pre-canned and shipped with KHIKA, keeping in mind the requirements of the users. They are mentioned in the table below :

Alerts Description

Alert Details Table

Alert Name	Description	Suggested Resolution
Malicious account creation followed by failed authorization	A new account is created and then there is login failure thrice on the same within 30 minutes. When these events occur in this order, it triggers this alert.	Soon after the user creation someone might start guessing the password. This could be an attempt to compromise the account. This happens in organisations where account creation is automated and insiders know (or can guess) the usernames. There are typical default passwords that someone can guess and in the attempt to guess the password, there are multiple login failures. This should raise suspicion. Check with the affected user and disable the account if suspicion is raised. Further investigation may involve tracing the system from where these authentication attempts were made and trigger investigation on that system.
Event log cleared	When eventid 1102 occurrs, that the Windows system;s event log has cleared - this alert is triggered.	Attempt to destroy the evidence by deleting the event logs. Attacker typically do this to delete the traces of their activities. It could be a false positive as many systems are scheduled to delete the logs at a periodic interval or upon reaching a size. In such cases whitelisting can be done and this event can be ignored. Otherwise, it warrants investigation.
User account deleted	Event of user deletion has occured (eventid 4726)	Sometimes an attacker deletes the compromised account after performing the intended tasks. This could be an intentional attempt to wipe-out the evidence or cause harm to legitimate user/s by deleting their accounts. The application accounts when deleted can cause outages. Please check what account was deleted and who deleted the account. If appropriate approvals were not in place to delete the account, this should raise suspicion and issue needs further investigation. The person deleting the account should be questioned.
Suspicious authentication attempts	A disabled or unknown user is trying to login and a login failure event occurs.	A disabled user trying to login may mean an account compromise attempt. Many a times employees leave the organisation or application accounts are disabled after their job is done and after sometime someone tries to use the disabled accounts to launch an attack. Ideally, a disabled user should not try to login. Check with the affected user. Trace end-node/terminal from where the login attempts were made.
Concurrent logins or password sharing	Same user has logged in from multiple servers within 5 minutes. This pattern triggers this alert.	There are very few legitimate reasons for the same user to be connected to a server from several different workstations. Same user suddenly logging into to multiple servers is suspicious and could mean a compromised account. Check with the affected user and disable the account if suspicion is raised. Further investigation may involve tracing the system from where these logins were made and trigger investigation on that system. Process tracking and investigating logs prior to successful logins may be useful.
User account unlocked	Alert triggered when event of account unlocked has occurred (eventid 4767)	A brute force attack tries to guess-n-crack the passwords. This results into multiple login failures and if appropriate account lock-out policy is configured, the victim account gets locked. This is a safety mechanism to thwart the further attempts of the attackers and prevents the possible password crack. The locked accounts get automatically unlocked after some time, if such policy is configured. In some cases, AD admin can manually force account unlocks and brute force attacks resume immediately after that. Such unlocked accounts should be tracked and investigated if they are being targeted by brute-force-attackers. If intentional brute-force attempts are confirmed, the auto-unlock feature must be disabled till you fix the brute-force attempts as the auto unlock feature actually helps the attacker
Suspicious activity on server	Alert triggered when one or more suspicious events have occurred within 5 minutes. The events are mentioned in the next columns.	Triggered for any of the following : Event ID 1102: The audit log was cleared. Here an attacker may be trying to destroy the audit trail of evidence being recorded in the event logs. EventID 1104: The security log is now full. Attacker floods the system with security events (such as logon failure) so much so that security logs reach its pre-defined size limit and then no event can be logged into the system. This enables the attacker to perform the further actions without leaving any traces of evidence behind in the system's security logs. EventID 1100: The event log service was shutdown. After event log service is shutdown, no event can be logged into the system. This would enable the attacker to perform the actions without leaving any traces of evidence behind in the system's security logs. EventID 1108 : The event logging service encountered an error. After event log service encounters an error, no event can be logged into the system. This would enable the attacker to perform the actions without leaving any traces of evidence behind in the system's security logs. EventID 4608 : Windows is starting up. Abrupt shutdown and restart, perhaps without following change request. EventID 4609 : Windows is shutting down. Abrupt shutdown, perhaps without following change request. EventID 4616 : The system time was changed. All the events listed here are suspicious events. Though many a times these events can be legitimate and part of the normal procedure (such as daily jobs scheduled to clear the event logs or normal reboot of the system after applying a patch), it cannot be left unnoticed. Appropriate justification has to be in place before closing these alerts. In case of suspicion, it is worth carefully looking at the events before and after the alert (especially, logon activity and process creation events)
Possible compromise to scheduled task	A user has logged in and scheduled task activities have occurred from the same account and host within 60 minutes.	An attacker may login and immediately create a windows task. If logon and task creation events happen in abnormally close proximity to the login event, then it could be an attack. Check the user who logged in. Check the terminal/workstation from where the user logged in. Check the created task. In case of suspicion, (a) disable the user (b) delete the task (c) check the user login and source. Investigate the user in question and take clues from workstation used for login.
New user immediately added to sensitive group	A new user created followed by the new user account being enabled followed by the newly created user being added to security group all events within one minute - in this order triggers this alert	A newly created user getting added immediately to a security group could raise suspicion. It may be an attack where the attacker creates a rogue user and adds it to a security sensitive group. It can even be an insider who may add a new (and perhaps an existing) user to a security sensitive group which may compromise the security posture. The affected user and the affecting user, both must be consulted. Check if the change requests, approvals and all the processes were followed.
Successful brute force attack doing changes	Alert triggered as - 5 failed login attempts followed by a successful login attempt followed by a change in the same account (eventid 4738) - occurred in this order	This is a typical successful brute force attack. Several failed login attempts may indicate that the user was trying to guess the password and may not be the legitimate user. A successful login followed by multiple unsuccessful attempts means that password guess was finally correct. Followed by this, was the change in user account (which could be the password, name etc.). This is highly suspicious series of events and must be inspected. Check with affected user immediately. If the user has not done the logins, immediately disable the user and trigger further investigation by collecting the logs of the system from where the login attempts were made, last interactive login on that system so that we can try and track the real user who launched this attack.
Account locked out	Alert triggered when an account is locked out (eventid 4740)	Multiple and consecutive login failures within a short time span can cause the account to get locked out as per the policy defined by the organisation. This could be an indication of a possible brute-force attack. When happens multiple times on the same account, can be treated as an early clue of a brute-force attack if it happens to the same user multiple times.
System time changed	This alert is triggered when system time is observed to be changed on any windows machine (eventid 4616)	Attackers sometime compromise the system and change the system time which results into many application failures. It could spoil the audit trail and logs after the timestamp of the events change. Check with system admin if this was done intentionally. If not, one must investigate further by 1) checking the interactive logins that happened near this event. 2) checking any other alerts generated during the same time on this system This can be a false positive if NTP service is doing it to synchronise the time with the NTP server. In such cases, the user is seen as SYSTEM in the event.
Unauthorised user creating a user	Event in which a new user is created (eventid 4720) by another user who is not an admin	After compromising a system, an attacker would typically create a user (with admin privileges). This user will then be used for other attacks, lateral movement etc. Sometimes, the internal admins may abuse their rights and create users for convenience which may change or compromise the security posture of the whole system. Check if the created user was create by authorized person. Check if all change controls and approvals were sought as per the standard operating procedure. Check if the newly created user was created with appropriate nomenclature, minimum rights etc. If any of the above is violated, then disable the user until appropriate justification is gathered.
Successful Brute Force Attack	Events of five failed logins followed by successful login within 30 minutes have occurred in this order	This sequence of events indicates a successful brute force attack where multiple login failure events (4624) were a result of password guess attempts and the successful login followed by that (4625) indicating a success guess of the password. Check with the affected user and disable the account if suspicion is raised. Further investigation may involve tracing the system from where these logins were made and trigger investigation on that system. Process tracking and investigating logs prior to successful logins may be useful.