KHIKA App for IIS WebServer

Introduction

IIS webserver form an important part of organisations’ networks and hence by monitoring your webserver is imperative.

With KHIKA App for IIS webserver, you can :

• Monitor hundreds of IIS servers at one central place.
• Monitor and shows the http error status for accessed URL on your server.
• Monitor and shows top n URL and also shows average time taken,total time taken by particular URL on your server.
• monitor user wise total request on your servers.

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

1. Install the KHIKA App for IIS Webserver
2. Get data from your IIS Webserver into KHIKA Aggregator

How to Install the KHIKA App for IIS WebServer?

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 IIS WeServers. 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 IIS WebServer data into KHIKA ?

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

1. OSSEC Agent – Installed on each Windows 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 server details in KHIKA
2. Extract a unique key for this device from KHIKA
3. Installing Ossec Agent on Windows Server
4. Insert this key in the Ossec agent (ie. on your Windows 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.

How to check the output of KHIKA Windows App ?

Report_IIS_Webserver_Http_Error_Status Dashboard

This Dashboard shows the information about HTTP status code for accessed URL's.This dashboard also shows top 10 URL's which are accessed most,Server IP and HTTP status code.

Elements in the Dashboard are explained below :

Report_IIS_Webserver_Http_Error_Status Dashboard

Visualization	Description
Server IP wise Status	X axis : ServerIP(s) Y axis : ServerIP wise status code like 200,400,404, etc.
Client IP wise Status	X axis : ClientIP(s) Y axis : ClientIP wise status code like 200,400,404,504, etc.
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 "Server IP wise Status" , click and select any one serverIP. This shall isolate respective status code and URL accessed for that selected serverIP and reflected across the dashboard. i.e the other pie charts, time trends and summary table shall show filtered information for this serverIP only.
2. alternatively,In the graph "Client IP wise Status " click and select any one clientIP. This shall isolate respective status code and URL accessed for that selected clientIP and reflected across the dashboard.

Report_IIS_Webserver_Top_N_URL Dashboard

This dashboard shows top URL's. Also gives the detail about domain and top hits on server.

Elements in the Dashboard are explained below :

Report_IIS_Webserver_Top_N_URL Dashboard

Visualization	Description
Contribution of URL	This pie chart shows different types of URL accessed by server.
Server Name wise Hits	X axis : Names of Server Y axis : Count of such request hits for 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
Contribution of Domain	This pie chart shows different types of domain.
Summary Table	Detailed data with timestamp and count

Some suggestions for useful interaction with this dashboard could be :

1. On the bar graph "Server Name wise Hits" select any one serverIP. This shall isolate the count of requested hits for selected servername and also domain and accessed URL for that servername across the dashboard. i.e the other pie charts, time trends and summary table shall show filtered information for this servername only.
2. Inversely, In the "Contribution of Domain" pie,click on the any one domain to select and rest of the elements on the dashboard then show data for that domain only.

Report_IIS_Webserver_Total_Request_Per_User Dashboard

This dashboard shows user wise total requests.

Elements in the Dashboard are explained below :

Report_IIS_Webserver_Total_Request_Per_User Dashboard

Visualization	Description
Contribution of Server Name	Contribution of servers.
User wise Request	X axis : one or more user Y axis : Count of request hits for that user.
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 Request " , click and select any one user. This shall isolate the requested hits for that selected user and reflected across the dashboard. i.e the other pie charts, time trends and summary table shall show filtered information for this user only.
2. In the pie "Contribution of Server Name " click and select any one servername. This shall isolate the respective user and requested hits for that servername and reflected across the dashboard.

Report_IIS_Webserver_Traffic_Categorization Dashboard

This dashboard shows traffic categorization like DIRECT or REFERRED. Also it shows serverip wise category , top URL's and Servers.

Elements in the Dashboard are explained below :

Report_IIS_Webserver_Traffic_Categorization Dashboard

Visualization	Description
Server IP wise Category	X axis : ServerIP Y axis : count of Category.
Client IP wise Referrer	X axis : ClientIP Y axis : count of Referrer.
Contribution of URL	Contribution of different types of URL
Contribution of Category	Contribution of different types of Category.
Contribution of Referrer	Contribution of different types of Referrer.
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. On the bar graph "Server IP wise Category" select any one serverIP. This shall isolate respective category and its count for selected serverIP and also domain and accessed URL for that serverIP across the dashboard. i.e the other pie charts, time trends and summary table shall show filtered information for this serverIP only.
2. Inversely, In the bar graph "Client IP wise Referrer" ,click on the any one clientIP to select and rest of the elements on the dashboard then show data for that clientIP only.

Report_IIS_Webserver_Top_N_Referers Dashboard

This Dashboard shows top referrers.Also gives the details of domain and top hits on server.

Elements in the Dashboard are explained below :

Report_IIS_Webserver_Top_N_Referers Dashboard

Visualization	Description
Contribution of Domain	Contribution of different types of Domain.
Server Name wise Hits	X axis : ServerName(s) Y axis :servername wise hits.
Contribution of Referrer	Contribution of different types of Category.
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. On the bar graph "Server Name wise Hits" select any one serverIP. This shall isolate count of request hits for selected serverIP and also shows domain and referrer for that serverIP across the dashboard. i.e the other pie charts, time trends and summary table shall show filtered information for this serverIP only.
2. Inversely, In the "Contribution of Domain" pie, click on the any one domain to select and rest of the elements on the dashboard then show data for that domain only.

Report_IIS_Webserver_Referrer_Detail Dashboard

This dashboard shows referrer details. Also it shows top URL's, Referrer, client IP, which are requested for URL and server IP.

Elements in the Dashboard are explained below :

Report_IIS_Webserver_Referrer_Detail

Visualization	Description
Contribution of Referrer	Contribution of different types of Referrer.
Contribution of URL	Contribution of different types of URL .
Server IP wise Hits	X axis : ServerIP Y axis : Count of request hits for that ServerIP.
Client IP wise Hits	X axis : ClientIP Y axis : Count of request hits for that Client IP.
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 bar graph "Server IP wise Hits" click and select any one serverIP.This shall isolate count of request hits for that selected serverIP and also shows referrer and accessed URL for that serverip reflected across the dashboard. i.e the other pie charts, time trends and summary table shall show filtered information for this serverIP only.
2. alternatively,In the graph "Client IP wise Hits" click and select any one clientIP. This shall isolate request hits and also shows referrer and accessed URL for that clientip reflected across the dashboard.

Report_IIS_webserver_loading_delays Dashboard

This dashboard shows the information about total time taken ,average time taken for accessed URI ,server IP.

Elements in the Dashboard are explained below :

Report_IIS_webserver_loading_delays Dashboard

Visualization	Description
URL wise Total Time	X axis : URL's Y axis : Total time required and count of most expensive request for particular URL.
Server IP Hits	X axis : ServerIP Y axis : Count of request hits for that ServerIP.
Contribution of Server IP	contribution of different types of serverIP.
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 bar graph "URL wise Total Time" click and select any one URL.This shall shows total time required for that selected URL and also shows count of most expensive request for that URL and reflected across the dashboard. i.e the other pie charts, time trends and summary table shall show filtered information for this URL only.
2. alternatively,In the bar graph "Server IP Hits" click and select any one serverIP.click on the any one serverIP to select and rest of the elements on the dashboard then show data for that serverIP only.

IIS_WEBSERVER-Report_IIS_Webserver_Avg_Qtime Dashboard

This Dashboard shows the average time taken by accessed URL and it's query.

Elements in the Dashboard are explained below :

Report_IIS_Webserver_Avg_Qtime Dashboard

Visualization	Description
URL wise Hits	X axis :Name of URL's Y axis : Count of request hits for that URL.
Server IP Hits	X axis : ServerIP Y axis : Count of request hits for that ServerIP.
Contribution of Query	contribution of different types of Query.
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 bar graph "Server IP wise Hits" select any one serverIP. This shall isolate the count of request hits for selected serverIP and also query for that servername across the dashboard. i.e the other pie charts, time trends and summary table shall show filtered information for this serverIP only.
2. In the bar graph "URL wise Hits" select any one URL. This shall isolate the count of request hits for selected URL and also query and servername for that URL across the dashboard. i.e the other pie charts, time trends and summary table shall show filtered information for this URL only.

KHIKA Alerts for IIS WebServer

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
IIS communication with possible IOC or bad IP	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.	KHIKA shares community based threat intelligence (TI) every 24 hours. TI has list of IP addresses with bad reputation. Every bad IP is marked with number of communities reporting it, name of each community and confidence indicating how confident are we about the reputation. This alert is generated when communication with a bad IP is let through. If communication with a bad IP is happening, it must be blocked immediately as it could be a possible attack or data exfiltration. You can check how log this communication is happening by simply searching the malicious IP in the logs. You can also check what internal IP addresses are communicating with this IP addresses and track the real users behind those internal IP addresses. Cross-check the reputation of the IP with popular websites such as ipvoid.com, virustotal.com. If you see an internal IP constantly getting involved in malicious communication (with same or multiple external IP addresses), you may install agents on the internal nodes involved and check the real user and process responsible for this communication. It is critical to block this rogue communication.
IIS dangerous content posted to webserver,files with executable extensions	When eventid 1102 occurrs, that the Windows system;s event log has cleared - this alert is triggered.	IIS dangerous content posted to webserver. Victim has posted some potentially dangerous files like executables, scripts, shared objects, etc. on webserver. Kindly check upload activity done by the user and verify the uploaded content for policy violation.
IIS multiple errors for same URL when it is not accessible	Event of user deletion has occured (eventid 4726)	Getting multiple errors for the same url. This kind of alert may occur due to incorrect application url e.g. user trying to access invalid/non-authorized url. Kindly check the legitimacy of the requesting users.
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.

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.