Forem: Suprim Devkota

Setting Up a Windows VM for Log Collection Using the ELK Stack - A Step-by-Step Guide

Suprim Devkota — Mon, 10 Mar 2025 09:48:36 +0000

Introduction

Log collection is vital for cybersecurity as it provides visibility into system activities, allowing organizations to monitor and track events happening within their infrastructure. They capture detailed information about user actions, network connections, application errors, and system performance, helping to detect suspicious activity such as unauthorized logins, privilege escalation, or malware execution. In the event of a cyberattack, logs become essential for forensic investigation, enabling cybersecurity professionals to trace the attacker's movements, understand the methods used, and identify the vulnerabilities exploited, leading to faster resolution and containment.

The ELK Stack (now often called the Elastic Stack) is a powerful, open-source suite of tools used for log management, data analysis, and visualization, comprising Elasticsearch, Logstash, and Kibana. Let us understand each tool in detail.

Elasticsearch: It is a distributed JSON-based search and analytics engine that stores and indexes data.
Think of it like a giant library where books (data) are stored in an organized way. When you need to find a specific piece of information (search for data), Elasticsearch helps you find it quickly by searching through the library's catalog (indexes).
Logstash: A server-side data processing pipeline that ingests, transforms and sends data to a desired destination. Think of it like a conveyor belt that takes raw materials (data from different sources), processes them (filters and formats the data) and moves them to an appropriate destination (Elasticsearch).
Kibana: A visualization layer that works on top of Elasticsearch, providing search and data visualization capabilities for data indexed in Elasticsearch. Think of it like the control panel in a car, providing you with graphs and information that give you insight to the performance and status of your system. Instead of just showing you the raw data, it helps you visualize and make sense of all the data you have.

In addition to these, Logs are typically collected using Beats. Beats are a collection of lightweight, open-source data shippers that collect and forward data (like logs, metrics and events) from various sources to Elasticsearch or Logstash for processing and analysis.

In this project, I'll be using Winlogbeat which focuses exclusively on Windows Event Logs. Think of Winlogbeat as a specialized messenger who only delivers important notes or messages (event logs) from your Windows system to a destination like Elasticsearch or Logstash.

So to wrap it all up, Winlogbeat collects logs from the system we want to monitor and sends it to Logstash. Logstash filters and formats the raw data and sends it to Elasticsearch which indexes the data for faster searching. Finally Kibana, lets you explore and interact with the indexed data in Elasticsearch in a user-friendly way.

In this guide, I'll walk you through setting up a Windows Virtual Machine (VM) on a host Windows system, installing the Windows OS, and configuring log collection from the VM to the host machine using the ELK Stack (Elasticsearch, Logstash, and Kibana).

By the end of this tutorial, you'll have a working ELK stack capturing Windows event logs from your VM and displaying them in Kibana for analysis.

Setting up the Windows Virtual Machine

Using VMware Workstation or VirtualBox on the host machine, attach the Windows ISO file and install the Operating system. Allocate at least 2 CPUs, 4 GB RAM and 32 GB disk space for the Virtual Machine that will be used to collect logs. To ensure network connectivity configure the network settings to Bridged Adapter or NAT

Setting Up Winlogbeat on the Virtual Machine

Once the Virtual Machine has been setup, the following things must be done to ensure that logs are properly collected and sent to the Logstash server running on the host.

Verify important logs are enabled in Event Viewer

Open Event Viewer (eventvwr.msc).
Expand Windows Logs > Security, System, Application.
Right-click each log category > Properties.
- Ensure Enable Logging is checked.
- Set log size to at least 10 MB.

Enable Audit Policies

Open Local Group Policy Editor (gpedit.msc).
Navigate to: Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration.
Enable relevant audit policies (e.g., Logon Events, Account Management, Object Access).

In this project I enabled auditing the following policies: Audit Security Group Management, Audit Audit Policy Change, Audit Process Creation, Audit Process Termination, Audit Sensitive Privilege Use, Audit File System, Audit Registry, Audit Handle Manipulation, Audit User Account Management, Audit Logon, Audit Logoff, Audit Special Logon and Audit Security State Change.

Install & Configure Winlogbeat

To ensure that firewall rules don't interfere with Winlogbeat we can run the following command to add an outbound rule to Windows Firewall.

  New-NetFirewallRule -DisplayName "Allow Winlogbeat to Logstash" -Direction Outbound -RemotePort 5044 -Protocol TCP -Action Allow

Download Winlogbeat from Winlogbeat downloads page.
Extract to C:\Program Files\Winlogbeat. (You might need to rename the downloaded directory to just Winlogbeat in order to avoid PATH TOO LONG errors.).
Configure winlogbeat.yml by uncommenting the following lines and adding your Host machine's IP as:

  output.logstash:
  hosts: ["<HOST_MACHINE_IP>:5044"]

winlogbeat.event.logs field specifies what feed to send to the Logstash server. The default configuration covers a large variety of relevant logs so I left that unchanged.

Install and Start Winlogbeat by running PowerShell as Administrator and entering the following commands:

  cd "C:\Program Files\Winlogbeat"
  Set-Execution-Policy Unrestricted -Scope CurrentUser
  .\install-service-winlogbeat.ps1
  Start-Service winlogbeat
  Set-Execution-Policy Restricted -Scope CurrentUser

Ensure that the winlogbeat service is running by executing the following command in Powershell: Get-Service winlogbeat.

Setting Up ELK Stack on the Host Machine

Now that logs are sent from the virtual machine to the host machine, we have to make sure that ElasticSearch, Logstash and Kibana are installed and configured to receive, index and display the logs in the host machine.

Install Java JDK

Download Java JDK and install it in the host computer.
Set the JAVA_HOME environment variable to point to the jdk directory.

Download & Install Elasticsearch

Download Elasticsearch from Elasticsearch downloads page.
Extract to C:\Program Files\Elasticsearch (You might need to rename the downloaded directory to just Elasticsearch in order to avoid PATH TOO LONG errors.)
Configure elasticsearch.yml as:

  network.host: 0.0.0.0
  http.port: 9200
  discovery.type: single-node

Make sure to set security features to false in order to use http instead of https which requires an SSL certificate.
Start Elasticsearch as:

  cd C:\ELK\elasticsearch\bin
  .\elasticsearch.bat

Verify that Elasticsearch has started by browsing to: http://localhost:9200.

If asked to signin, run the following command in Powershell to generate a new password from the /bin directory: elasticsearch-reset-password -u elastic

Download & Install Logstash (Only Required when logs are to be parsed before being sent to Elasticsearch)

To ensure that firewall rules don't interfere with Logstash we can run the following command to add an inbound rule to Windows Firewall.

  New-NetFirewallRule -DisplayName "Allow Logstash" -Direction Inbound -LocalPort 5044 -Protocol TCP -Action Allow

Download Logstash from Logstash downloads page.
Extract to C:\Program Files\Logstash (You might need to rename the downloaded directory to just Logstash in order to avoid PATH TOO LONG errors.)
Configure C:\Program Files\Logstash\config\logstash.conf as:

  input {
    beats {
      port => 5044
      ssl => false
    }
  }
  output {
    elasticsearch {
      hosts => ["http://localhost:9200"]
      index => "%{[@metadata][beat]}-%{[@metadata][version]}-%{+YYYY.MM.dd}" 
      user => "..."
      password => "..."
    }
  }

Start Logstash as: C:\ELK\logstash\bin\logstash.bat -f C:\ELK\logstash\config\logstash.conf

Download & Install Kibana

Download Kibana from Kibana downloads page.
Extract to C:\Program Files\Kibana (You might need to rename the downloaded directory to just Kibana in order to avoid PATH TOO LONG errors.)
Configure kibana.yml as:

  server.port: 5601
  elasticsearch.hosts: ["http://localhost:9200"]

Start Kibana as: C:\ELK\kibana\bin\kibana.bat
Verify that Kibana has started by browsing to: http://localhost:5601.

Create Index Pattern and validate logs in Kibana

Open Kibana at: http://localhost:5601.
Navigate to Management > Stack Management > Kibana > Data views.
Create an data view: Enter a name ,winlogbeat-* as the index pattern and select @timestamp as the time filter.
Go to Discover and select the name of the data view to view logs from the index pattern.

Conclusion

In this guide, we have covered the essential steps to set up a Windows VM for log collection using the ELK Stack:

Successfully created and configured a Windows Virtual Machine.
Enabled Windows Event Logging and configured auditing policies.
Installed and configured Winlogbeat to forward logs to Logstash.
Installed and set up the ELK Stack (Elasticsearch, Logstash, and Kibana) on the host machine.
Verified and analyzed logs in Kibana.

Next Steps and Enhancements:

Implement alerting: Use Kibana’s Watcher feature to create real-time alerts based on specific log patterns or anomalies.
Strengthen security: Secure your ELK stack using TLS encryption and authentication to protect sensitive log data.
Create custom dashboards: Develop tailored visualizations and dashboards in Kibana to monitor key performance indicators and security events.
Expand log collection: Integrate additional log sources such as Sysmon, PowerShell, and network traffic for comprehensive visibility.

Cyber-Sentry: Building a Secure Honeypot Fortress with Azure Sentinel and Log Analytics Workspace

Suprim Devkota — Tue, 02 Jan 2024 14:32:39 +0000

Introduction

Honeypots, in the context of cybersecurity, are decoys or sacrificial computers intended to lure in attackers. It mimics a potential target system and in doing so gains useful insights from the intrusion attempts of the hackers. It may also be used to gain information about the mode of operation of the hackers or to distract them from real systems and make them focus their efforts on the decoy.

In this guide, we'll walk through the process of creating a honeypot using Microsoft Azure. This involves setting up a virtual machine, configuring security measures, and leveraging Azure Sentinel for visualizing geodata related to potential attacks. We'll also be exposed to the Log Analytics Workspace in Azure and Kusto Query Language (KQL) which will be used to query logs in the project.

Azure Account Setup

To begin, create an Azure account using your college email (one ending in .edu), which provides $100 in free credits valid for a year.

Creating an Azure Virtual Machine

Create an Azure Virtual Machine. For this project I used the Windows 10 x64 Pro image, equipped with 2 vCPUs, 8 GB memory. I also created an admin account. (Be sure to remember the password as it will be used later to log in to the VM remotely.)

Resource Group and Network Security Group

In Azure, resources such as VMs and Log Analytics Workspaces can be group into a logical group which usually shares the same lifespan. This grouping of resources is called a Resource Group. Azure also allows us to establish and configure a Network Security Group (NSG), which serves as a virtual firewall. We will be allowing all traffic to the VM by setting source and destination as *.

Caution: Setting NSG configuration to allow all traffic is typically avoided for any resource you have on the cloud that is to be protected, but for the intent of our Honey Pot, this is ideal.

Log Analytics Workspace (LAW) and Microsoft Sentinel

Log Analytics Workspace (LAW) provides a centralized for collecting and analyzing data in Azure. We will set it up to ingest logs, including Windows event logs and custom logs for geographic location. Microsoft Sentinel will then connect to LAW to display geodata on a map. Set the Microsoft Defender for Cloud to collect all events and connect LAW to the VM for data collection.

Visualizing Geodata with Microsoft Sentinel

Remote Desktop Connection

Obtain the public IP address of the VM and connect via Remote Desktop Connection app in your system using the admin account credentials you created while setting up the VM. Inside the VM, turn off the firewall and verify by pinging its public IP from your machine.

Analyzing Event Logs

You can then explore the Event Viewer to identify failed login attempts (Event ID: 4625). This event id will be helpful when filtering records using KQL later.

Geolocating IP Addresses

If you look closer at the event log, you'll see that it only contains the source IP address for the failed login attempt. Since we eventaully need to plot the IP address, we'll need some way to convert this IP address into geological data. For this we'll use ipgeolocation.io's API to obtain geographical information for the IP addresses. This API is useful as it gives us Lattitude, Longitude, Country and similar information.

We'll use a powershell script for extracting the data from the Windows Event Logs and using the API key we'll convert the IP address to geological data.

Creating Custom Log in LAW

Fortunately for us, we can simply copy the custom log powershell script from https://github.com/joshmadakor1/Sentinel-Lab/blob/main/Custom_Security_Log_Exporter.ps1. This script basically continuously monitors and export failed login attempts to failed_rdp.log. Take care to replace the API key with a new key from ipgeolocation.io.

In Azure, create a custom log in LAW by uploading the failed_rdp.log file. This will take some time to fully upload however it will train the LAW to parse our custom log.

Extracting Fields using KQL

To visualize the data collected in LAW, we'll use a new workbook in Microsoft Sentinel. Further, we'll employ Kusto Query Language (KQL) to extract relevant fields from the raw custom log data which will be used by Azure Sentinel to plot the intrusion attempts. For this use the query below:

FAILED_RDP_WITH_GEO_CL
 |extend username = extract(@"username:([^,]+)", 1, RawData),
         timestamp = extract(@"timestamp:([^,]+)", 1, RawData),
         latitude = extract(@"latitude:([^,]+)", 1, RawData),
         longitude = extract(@"longitude:([^,]+)", 1, RawData),
         sourcehost = extract(@"sourcehost:([^,]+)", 1, RawData),
         state = extract(@"state:([^,]+)", 1, RawData),
         label = extract(@"label:([^,]+)", 1, RawData),
         destination = extract(@"destinationhost:([^,]+)", 1, RawData),
         country = extract(@"country:([^,]+)", 1, RawData)
 |where destination != "samplehost"
 |where sourcehost != ""
 |summarize event_count=count() by timestamp, label, country, state, sourcehost, username, destination, longitude, latitude

This query basically extracts username, timestamp, latitude, longitude, sourcehost, state, label, destination and country from the raw log data and filters it to exclude the initial training data. It also summarizes event count by the extracted fields.

Conclusion

By following these steps, we've successfully set up a honeypot in Microsoft Azure, configured logging, and visualized geodata using Azure Sentinel. This comprehensive approach allows you to monitor and analyze potential security threats effectively. The intrusion map I obtained after letting the VM run for a couple of days is shown below:

Web Vulnerabilities: SQL Injections

Suprim Devkota — Mon, 11 Dec 2023 10:56:58 +0000

SQL injection (SQLi) is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database.

Impacts
- Unauthorized access to sensitive data such as passwords, credit card details and personal user information.
- Reputational damage and regulatory fines.
- Possibility of attacker gaining a persistent backdoor into an organization’s systems.
What parts of a SQL query can be injected?
- Common in WHERE clause of SELECT statement.
- In UPDATE statements, within the updated values or the WHERE clause.
- In INSERT statements, within the inserted values.
- In SELECT statements, within the table or column name.
- In SELECT statements, within the ORDER BY clause
Detection mechanisms
- Submit a single quote character ' and look for errors and other anomalies.
- Boolean conditions such as OR 1=1 or OR 1=2
- Payloads designed to trigger time delays such as ' OR '1'='1' AND SLEEP(5) --
- Comments with -- at the end of an injection.
Examples
1. Retrieving hidden data
  
  Imagine a shopping application that displays products in different categories. When the user clicks on the Gifts category, their browser requests the URL: https://insecure-website.com/products?category=Gifts and causes the application to make a SQL query to retrieve details of relevant products from the data base as:
```
SELECT * FROM products WHERE category = 'Gifts' AND released = 1
```
  This is vulnerable to SQL injection as follows:
```
-- Payload = Gifts'-- shows gifts released or not
SELECT * FROM products WHERE category = 'Gifts'--' AND released = 1

--Payload = Gifts' OR 1=1-- shows all items released or not
SELECT * FROM products WHERE category = 'Gifts' OR 1=1--' AND released = 1
```
  CAUTION: When injecting the condition OR 1=1 it’s common for applications to use data from a single request in multiple different queries. So if the condition reaches an UPDATE or DELETE statement, it can result in accidental data loss.
2. Subverting application logic
  
  Imagine an application that lets users login with a username and password. The application checks the credentials by performing an SQL query as follows and if the query returns details of the user, login is successful else it is rejected.
```
SELECT * FROM users WHERE username = 'wiener' AND password = 'bluecheese'
```
  This is vulnerable to injection as follows:
```
/*payload = administrator'-- allows the attacker to log in as any user
without need for password*/
SELECT * FROM users WHERE username = 'administrator'--' AND password = ''
```
  This query returns user whose username is administrator without the need for a password.
3. UNION attacks
  
  Imagine an application executes the following query containing the user input Gifts:
```
SELECT name, description FROM products WHERE category = 'Gifts'
```
  This is vulnerable to injection as follows:
```
UNION SELECT username, password FROM users--

--The malicious SQL query would then be:
SELECT name, description FROM products
WHERE category = '' 
UNION 
SELECT username, password FROM users--
```
  This causes the application to return all usernames and passwords along with the names and descriptions of the products.
4. Blind SQL injection
  
  Most SQLi are blind in nature but can still be exploited to gain unauthorized data. Some techniques are:
  
  a. Divide by zero:
```
    SELECT * FROM users 
    WHERE username = '' OR 1=1 AND 1/0 --'
    AND password = '';
```
  b. Triggering time delays with SLEEP()

Prevention against SQL Injection using Prepared Statements or Parameterized Queries

They make SQL injections virtually impossible.
Prepared statements separate code from data by ensuring that user-supplied input does not alter your program’s logic.
Prepared statements are compiled by the SQL server before adding user input.
Anything that is not part of the prepared statements is treated as string data and not as an executable SQL query.

// Create MySQL server and store username and password in variables.
$mysqli = new mysqli("mysql_host", "mysql_username", "mysql_password", "database_name");
$username = $_POST["username"];
$password = $_POST["password"];

// Vulnerable SQL statement
$vuln = "SELECT Id FROM Users WHERE Username='$username' AND Password='$password'";
$result = $mysqli->query($vuln);

// Safe prepared statement
$stmt = $mysqli->prepare("SELECT Id FROM Users WHERE Username =? AND Password =?");
$stmt->bind_param("ss", $username, $password);
$stmt->execute();

// Unsafe prepared statement
$stmt = $mysqli->prepare("SELECT Id FROM Users WHERE Username='$username' AND Password=password'");
$stmt->execute();

Exploit Development: Buffer Overflows

Suprim Devkota — Fri, 24 Nov 2023 06:13:32 +0000

Introduction

Let’s say you have a candy jar with a capacity for 10 candies. Each candy represents a piece of data. Now, let’s say you have a friend who loves to share candies with you.

In a world without proper checks, your friend might get excited and decide to share 15 candies with you, not realizing the jar can only hold 10. As a result, candies spill out of the jar, making a mess. In the realm of computer security, this overflow of candies is similar to a buffer overflow, where data spills beyond the allocated space, potentially causing chaos and security vulnerabilities.

To understand buffer overflows we have to first look at the anatomy of memory in the computer and the organization of stack in said memory.

A buffer overflow attack is exploited when the data sent to the buffer overflows the Buffer Space into the Extended Instruction Pointer (EIP) which contains the address of the next instruction to be executed. Changing the value in this EIP register to point to malicious code is the crux of the whole exploit.

Steps involved in a buffer overflow attack

Finding the vulnerable service by spiking: Spiking involves sending various input values to the target service to identify potential vulnerabilities. This helps in understanding how the service behaves under different conditions and if it reacts unexpectedly to certain inputs. Identifying a service that exhibits abnormal behavior or crashes in response to specific inputs might indicate a potential buffer overflow vulnerability.
Fuzz the service: Fuzzing is the process of sending a large number of random or specially crafted inputs to the target service to observe its response. This helps in discovering points of failure or unexpected behavior. Fuzzing aims to trigger any unexpected responses or crashes that may indicate the presence of a buffer overflow vulnerability.
Obtain the offset address of the EIP: Once a buffer overflow is identified, the next step is to determine the offset at which the Extended Instruction Pointer (EIP) is overwritten. This involves sending input with a pattern and analyzing the crash to find the distance from the start of the buffer to the overwritten EIP.Purpose: Knowing the offset is crucial for crafting the payload to precisely overwrite the EIP.
Overwrite the EIP: Craft a payload to overwrite the EIP with a controlled value, typically pointing to the location of the attacker’s shellcode. By controlling the EIP, the attacker can redirect the program’s execution to the injected malicious code instead of following the normal flow.
Find bad characters: Identify characters that may interfere with the proper execution of the payload, such as null bytes (/x00) or other characters that might be altered during transmission. This ensures that the payload doesn’t contain characters that could disrupt the execution of the exploit.
Find the right module: Identify the module or library in the target process that can be used to execute the payload. This often involves locating a module with a memory address that remains consistent across different executions of the program. Determining a reliable module helps in crafting the exploit to ensure stability and effectiveness.
Generate Shellcode: Create a payload, often in the form of shellcode, which is a small piece of code that performs a specific action, such as spawning a shell or providing remote access. The shellcode is the actual payload that the attacker wants to execute on the target system.
Gain Root!: Execute the crafted exploit to take control of the target system, typically by escalating privileges to gain root access or the highest level of control. This is the ultimate objective, allowing the attacker to manipulate the system as desired.

Buffer Overflow Safeguards and Prevention

Runtime bounds checking makes it theoretically impossible for a buffer overflow to happen by checking whether the space in a buffer is enough to accomodate the incoming data. This is the reason why languages such as Python and Java implement it.

However there are also performance costs associated with this method as extra computation has to be done every time an element is to be inserted. This is the reason why languages such as C and C++ do not implement it and hence why programs written in these languages are vulnerable to overflows.