**ELK STACK SECURITY**

**MONITORING LAB**

Attack Simulation & Log Analysis Report

Prepared by:

**Pranmoy Patar**

March 2025

|                        |                                                    |
|------------------------|----------------------------------------------------|
| **Platform**           | ELK Stack v8.11.0 + Filebeat                       |
| **Environment**        | Kali Linux + Docker                                |
| **Attack Simulations** | 3 (Credential Stuffing, DNS Tunneling, PowerShell) |

# 1. Objective & Overview {#objective-overview}

This lab demonstrates the deployment and use of an ELK Stack (Elasticsearch, Logstash, Kibana) Security Information and Event Management (SIEM) system to detect, ingest, and visualize simulated cyberattacks. The environment was built entirely on a single Kali Linux virtual machine using Docker containers, making it a practical and portable security monitoring lab.

The primary objectives of this lab were:

- Deploy a fully functional ELK Stack using Docker Compose on a Kali Linux VM

- Configure Filebeat as a log shipper to forward attack simulation logs to Logstash

- Develop Python-based attack simulation scripts to generate realistic log data for three distinct attack types

- Analyze and visualize ingested security events through the Kibana dashboard

- Demonstrate detection capability for common cyber threats: Credential Stuffing, DNS Tunneling, and PowerShell Exploitation

The lab serves as a hands-on demonstration of core blue team / SOC analyst skills including log management, threat detection, and security event visualization --- all using industry-standard tooling.

# 2. Environment Setup {#environment-setup}

## 2.1 Infrastructure Overview {#infrastructure-overview}

|                        |                                                             |
|------------------------|-------------------------------------------------------------|
| **Component**          | **Details**                                                 |
| **Operating System**   | Kali Linux (single VM --- ELK server and client co-located) |
| **Containerization**   | Docker + Docker Compose                                     |
| **ELK Stack Version**  | 8.11.0 (Elasticsearch, Logstash, Kibana)                    |
| **Log Shipper**        | Filebeat (installed directly on the VM host)                |
| **Logstash Port**      | 5044 (Beats input)                                          |
| **Kibana Port**        | 5601 (Web UI)                                               |
| **Elasticsearch Port** | 9200 (REST API)                                             |

## 2.2 Docker Compose Setup {#docker-compose-setup}

The ELK Stack was deployed using a docker-compose.yml file that orchestrated three containers --- Elasticsearch, Logstash, and Kibana --- on the same Kali Linux VM. Using Docker Compose allowed for easy service management, consistent configuration, and simplified networking between ELK components.

Key design decisions in the setup:

- All three ELK services were networked together within Docker using a shared internal network

- Elasticsearch was configured as a single-node cluster suitable for a lab environment

- Logstash was configured to receive Beats input on port 5044 and forward to Elasticsearch on port 9200

- Kibana was exposed on port 5601 for browser-based dashboard access

## 2.3 Filebeat Configuration {#filebeat-configuration}

Filebeat was installed directly on the Kali VM host (not inside a Docker container) so it could access the local log files generated by the Python simulation scripts. It was configured to monitor three separate log paths corresponding to each attack simulation:

> filebeat.inputs:
>
> \# Authentication / Credential Stuffing logs
>
> \- type: log
>
> enabled: true
>
> paths:
>
> \- /var/log/auth.log
>
> \- /var/log/attack-simulation/auth_simulation.log
>
> tags: \[\"authentication\", \"kali-client\"\]
>
> fields:
>
> log_type: authentication
>
> \# DNS Tunneling logs
>
> \- type: log
>
> enabled: true
>
> paths:
>
> \- /var/log/attack-simulation/dns_simulation.log
>
> tags: \[\"dns\", \"kali-client\"\]
>
> fields:
>
> log_type: dns
>
> \# PowerShell Exploitation logs
>
> \- type: log
>
> enabled: true
>
> paths:
>
> \- /var/log/attack-simulation/powershell_simulation.log
>
> tags: \[\"powershell\", \"kali-client\"\]
>
> fields:
>
> log_type: powershell
>
> \# Output: Logstash on localhost (ELK on same machine)
>
> output.logstash:
>
> hosts: \[\"localhost:5044\"\]

Key Filebeat settings:

- The output was directed to localhost:5044 since the ELK stack was running on the same machine

- Host metadata was automatically enriched by the add_host_metadata processor

- The client name was set to kali-client-localhost to clearly identify the log source in Kibana

- Each log type was tagged and enriched with a log_type field for easy filtering in Kibana

# 3. Attack Simulations & Python Scripts {#attack-simulations-python-scripts}

Three Python scripts were developed to simulate realistic cyberattack scenarios. Each script generates log entries in formats that mimic real-world logging (syslog, BIND DNS logs, Sysmon events), along with baseline legitimate traffic to test detection amid normal activity.

## 3.1 Credential Stuffing Attack {#credential-stuffing-attack}

**Attack Description**

Credential stuffing is an automated attack where attackers use large lists of stolen username/password combinations --- typically from prior data breaches --- to gain unauthorized access to user accounts. The attack exploits the tendency of users to reuse passwords across multiple services.

Key indicators of credential stuffing in logs include:

- High volume of failed authentication attempts (SSH, web login, etc.) in a short time window

- Multiple usernames being tried from a single source IP address

- A very high failure rate (typically 95%+) with occasional successes

- Login attempts targeting common usernames like admin, root, or user

**Simulation Design**

The CredentialStuffingSimulator class generates realistic syslog-format SSH authentication messages. The simulation uses three attacker IPs and rotates through 15 target usernames, mimicking a real credential stuffing list. The script also generates legitimate authentication traffic (from internal IPs with a 90% success rate) to provide baseline noise.

|                 |                                                             |
|-----------------|-------------------------------------------------------------|
| **Parameter**   | **Value**                                                   |
| Attack attempts | 50 attempts over 300 seconds                                |
| Failure rate    | 95% (simulating real credential stuffing success rates)     |
| Attacker IPs    | 203.0.113.100, 198.51.100.50, 192.0.2.200 (TEST-NET ranges) |
| Log format      | Syslog-style SSH messages (Accepted/Failed password)        |
| Log file        | /var/log/attack-simulation/auth_simulation.log              |


**Kibana Detection Indicators**

- A spike in Failed password log events from a single source IP

- High ratio of failed-to-successful authentication attempts

- Multiple unique usernames attempted from the same IP within a short timeframe

- Alert conditions: \>10 failed logins from a single IP within 60 seconds

## 3.2 DNS Tunneling Attack {#dns-tunneling-attack}

**Attack Description**

DNS tunneling is a technique used by attackers to encode data within DNS query and response traffic in order to bypass firewalls and exfiltrate data. Since DNS traffic is typically allowed through firewalls, it can be exploited to create covert communication channels between a compromised host and an attacker-controlled Command & Control (C2) server.

Key indicators of DNS tunneling in logs include:

- Unusually long DNS query names (often 50+ characters) due to base64 or hex-encoded payloads embedded as subdomains

- High volume of DNS queries to a single parent domain

- Use of uncommon record types such as TXT in addition to standard A records

- Queries containing randomized, non-human-readable subdomain strings

**Simulation Design**

The DNSTunnelingSimulator class generates BIND-style DNS log entries that closely mimic real DNS tunneling activity. The C2 domain used is malicious-c2.example.com. The simulator encodes random data using either hex or base64 schemes, splits it across multiple subdomain levels, and formats the resulting query in the BIND DNS query log format.

|                   |                                                                  |
|-------------------|------------------------------------------------------------------|
| **Parameter**     | **Value**                                                        |
| Queries generated | 100 malicious queries + 30 legitimate queries                    |
| C2 Domain         | malicious-c2.example.com                                         |
| Encoding types    | Hex and Base64 (randomly selected)                               |
| Subdomain length  | 40--70 characters (encoded payload split across multiple levels) |
| Log format        | BIND-style DNS query log                                         |


**Kibana Detection Indicators**

- Queries with subdomain strings of unusual length (\>30 characters)

- High query frequency to a single parent domain within a short window

- Presence of base64 or hex character patterns (a-f0-9 density) in subdomain labels

- Use of TXT record type queries alongside A record queries to the same domain

- Alert conditions: \>20 queries to the same parent domain within 10 minutes

## 3.3 PowerShell Exploitation Attack {#powershell-exploitation-attack}

**Attack Description**

PowerShell exploitation is a broad category of attack techniques that abuse Windows PowerShell to execute malicious code, bypass security controls, escalate privileges, or establish persistence. PowerShell is a powerful scripting environment built into Windows, making it a frequent choice for attackers (also referred to as Living off the Land --- LotL attacks).

Simulated attack techniques include:

- Encoded Command execution (-encodedCommand flag to obfuscate payloads)

- Execution Policy Bypass (-ExecutionPolicy Bypass to circumvent script restrictions)

- Download and Execute (downloading remote payloads via Net.WebClient)

- Credential dumping via Mimikatz invocation

- AMSI bypass (disabling the Anti-Malware Scan Interface)

- Windows Defender exclusion path addition

- Lateral movement via Invoke-Command

**Simulation Design**

The PowerShellExploitationSimulator class generates Sysmon-style Event ID 1 (Process Create) and Event ID 4104 (Script Block Logging) log entries. The script models 8 distinct malicious command patterns with severity classifications (critical, high, medium) and realistic parent process assignments. A key detection signal is suspicious parent processes --- Office applications (WINWORD.EXE, EXCEL.EXE) or PDF readers spawning PowerShell is a major red flag.

|                     |                                                                  |
|---------------------|------------------------------------------------------------------|
| **Parameter**       | **Value**                                                        |
| Events generated    | 20 malicious + 10 legitimate events over 300 seconds             |
| Suspicious parent % | 60% (WINWORD.EXE, EXCEL.EXE, OUTLOOK.EXE, AcroRd32.exe)          |
| Script block logs   | 20% of events also generate Event ID 4104 (Script Block Logging) |
| Log format          | Sysmon-style Event ID 1 (Process Create) and Event ID 4104       |

**Sample Log Output**


**Kibana Detection Indicators**

- PowerShell processes spawned by Office applications (WINWORD.EXE, EXCEL.EXE) --- classic macro-based attack indicator

- Use of -encodedCommand, -ExecutionPolicy Bypass, or -WindowStyle Hidden flags in command lines

- Presence of keywords: IEX, DownloadString, Invoke-Mimikatz, AMSI, MpPreference in command lines

- Event ID 4104 (Script Block Logging) entries tagged as malicious_script

- Critical severity tags: encoded_command, credential_theft, defense_evasion, amsi_bypass

# 4. Kibana Dashboard & Log Analysis {#kibana-dashboard-log-analysis}

## 4.1 Data Pipeline Overview {#data-pipeline-overview}

The complete data flow from log generation to visualization followed this pipeline:

**Python Scripts → Log Files → Filebeat → Logstash :5044 → Elasticsearch :9200 → Kibana :5601**

- Python scripts wrote logs to /var/log/attack-simulation/ in simulation-appropriate formats

- Filebeat monitored these paths, enriched entries with tags and log_type fields, and shipped to Logstash

- Logstash parsed and indexed the logs into Elasticsearch

- Kibana provided query and visualization capabilities through Discover and Dashboard views

## 4.2 Credential Stuffing --- Kibana Analysis {#credential-stuffing-kibana-analysis}

In Kibana Discover, filtering by log_type: authentication and the tag authentication revealed the authentication log stream. The following observations were made:

- Rapid succession of \"Failed password\" events visible as a spike in the log timeline

- Filtering by source IP (203.0.113.100 etc.) isolated all attacker activity instantly

- Username diversity analysis showed the attacker cycling through all 15 target usernames

- The contrast between attacker traffic (95% failure rate) and legitimate traffic (90% success rate) was immediately visible when comparing by source IP

- A Kibana Lens visualization of failed login events per source IP clearly highlighted the attacker IPs as outliers

Detection summary: Credential stuffing is highly visible in ELK due to the volume and pattern of failed authentication events. A simple threshold alert (e.g., \>10 failures from one IP in 60 seconds) would reliably catch this attack.

## 4.3 DNS Tunneling --- Kibana Analysis {#dns-tunneling-kibana-analysis}

Filtering by log_type: dns in Kibana Discover revealed the DNS query log stream. Observations:

- The encoded subdomain queries were immediately visually distinctive --- long, random-looking strings contrasting with clean legitimate queries to google.com, github.com, etc.

- Aggregating queries by parent domain clearly showed malicious-c2.example.com as a massive outlier in query volume

- A character-length analysis of query names showed the tunneling queries averaging 60--80 total characters vs. \<30 for legitimate queries

- The mix of A and TXT record types from the same source to the same domain was another detectable anomaly

- Timeline visualization showed consistent high-frequency querying characteristic of automated C2 beaconing

Detection summary: DNS tunneling is detectable via query length analysis, domain frequency analysis, and anomalous record type patterns. A Kibana rule checking for query name length \>40 characters or \>20 queries to a single domain in 10 minutes would effectively flag this attack.

## 4.4 PowerShell Exploitation --- Kibana Analysis {#powershell-exploitation-kibana-analysis}

Filtering by log_type: powershell revealed the Sysmon-style event log stream. Observations:

- EventID:1 (Process Create) entries with powershell.exe in the Image field were easily isolated

- Filtering by ParentImage containing WINWORD.EXE or EXCEL.EXE revealed all macro-spawned PowerShell instances

- Keyword search for encodedCommand, DownloadString, and Invoke-Mimikatz immediately surfaced the highest-risk events

- Severity field filtering (Severity:critical) reduced noise and prioritized the most dangerous events

- EventID:4104 (Script Block Logging) entries provided additional evidence with the actual script content captured in ScriptBlockText

- The tags field (encoded_command, credential_theft, amsi_bypass, defense_evasion) enabled rapid categorization of attack techniques

Detection summary: PowerShell attacks generate rich telemetry when Sysmon and Script Block Logging are enabled. Parent process anomalies (Office apps spawning PowerShell) combined with suspicious command-line flags are high-fidelity detection signals with low false positive rates.

## 4.5 Summary Dashboard View {#summary-dashboard-view}

|                         |                      |                                                         |                          |
|-------------------------|----------------------|---------------------------------------------------------|--------------------------|
| **Attack Type**         | **Events Generated** | **Key Detection Signal**                                | **Kibana Tag/Field**     |
| Credential Stuffing     | 50 + 10 baseline     | High failure rate, single IP, multi-username            | log_type: authentication |
| DNS Tunneling           | 100 + 30 baseline    | Encoded subdomains, high query volume to C2 domain      | log_type: dns            |
| PowerShell Exploitation | 20 + 10 baseline     | Malicious parent process, encoded commands, AMSI bypass | log_type: powershell     |

# 5. Conclusion {#conclusion}

This lab successfully demonstrated the end-to-end process of deploying an ELK Stack SIEM, ingesting simulated attack logs, and detecting threats via Kibana. The key takeaways are:

- Docker-based ELK deployment is highly practical for lab and development environments, enabling rapid setup with version consistency

- Filebeat\'s flexible input configuration and tagging capability makes it easy to segment and enrich log streams before they reach Elasticsearch

- Credential stuffing, DNS tunneling, and PowerShell exploitation all produce distinct, detectable log signatures when proper logging is in place

- Kibana\'s Discover and Dashboard views are powerful tools for both ad-hoc investigation and building persistent detection rules

- Generating a mix of malicious and legitimate traffic is essential for realistic detection testing --- it forces the analyst to identify meaningful signal within noise

The skills demonstrated in this lab directly map to core SOC analyst and blue team competencies: log management, SIEM operation, threat detection rule development, and attack pattern recognition. The lab environment can be extended with additional attack simulations, Elastic Security rules, and alerting configurations for further development.

*Pranmoy Patar \| ELK Stack Security Monitoring Lab \| Personal Portfolio*