In this module

PT1.11 Secondary SIEM — Elastic Stack

4-8 hours · Module 1 · Free
What you already know

You may or may not have used Elastic before. If you chose Splunk in PT1.10, skip this sub and go to PT1.12. If Elastic is your choice, this sub installs Elasticsearch + Kibana on the Linux VM and Winlogbeat on the Windows endpoint. Every step is shown with commands and expected output.

Operational Objective
This sub installs the Elastic Stack (Elasticsearch + Kibana) on the Linux VM, installs Winlogbeat on the Windows endpoint to forward Sysmon and Security events, creates a data view in Kibana, and verifies events arrive. By the end, you'll have three SIEMs receiving endpoint telemetry from the same source.
Deliverable: A working Elastic Stack instance receiving Sysmon and Security events from the Windows endpoint.
Estimated completion: 45–60 minutes

Step 1: Install Elasticsearch on the Linux VM

On PT-LINUX01:

# Import the Elastic GPG key
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | \
    sudo gpg --dearmor -o /usr/share/keyrings/elastic-keyring.gpg

# Add the Elastic 8.x repository
echo "deb [signed-by=/usr/share/keyrings/elastic-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | \
    sudo tee /etc/apt/sources.list.d/elastic-8.x.list

# Update and install Elasticsearch
sudo apt update && sudo apt install -y elasticsearch

Configure Elasticsearch for lab use:

sudo nano /etc/elasticsearch/elasticsearch.yml

Find and set these values (some may need uncommenting — remove the # at the start of the line):

# Bind to all interfaces so the Windows endpoint can reach it
network.host: 0.0.0.0

# Single-node mode — no cluster discovery needed for a lab
discovery.type: single-node

# Disable security for simplicity in the lab
# (In production you'd never do this — in a lab it removes TLS complexity)
xpack.security.enabled: false
xpack.security.enrollment.enabled: false
xpack.security.http.ssl.enabled: false
xpack.security.transport.ssl.enabled: false

Save the file (Ctrl+O, Enter, Ctrl+X in nano).

# Start Elasticsearch
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearch

Wait 30–60 seconds for Elasticsearch to start (it's Java-based and slow to initialize on 2 GB RAM).

Verification:

curl -s http://localhost:9200 | python3 -m json.tool | head -10
{
    "name": "pt-linux01",
    "cluster_name": "elasticsearch",
    "cluster_uuid": "abc123...",
    "version": {
        "number": "8.15.0",
        "build_flavor": "default",
        ...
    },

If curl returns "connection refused", Elasticsearch hasn't started yet. Check the logs:

sudo journalctl -u elasticsearch --no-pager | tail -20

Common issues: not enough memory (needs at least 1 GB free — if other services are running, stop Caldera while using Elastic), or the config file has a YAML syntax error.

Step 2: Install Kibana

sudo apt install -y kibana

Configure Kibana:

sudo nano /etc/kibana/kibana.yml

Set:

# Bind to all interfaces so you can access from your host browser
server.host: "0.0.0.0"

# Point to Elasticsearch
elasticsearch.hosts: ["http://localhost:9200"]
sudo systemctl enable kibana
sudo systemctl start kibana

Kibana takes 1–2 minutes to start.

Verification: open a browser on your host and navigate to http://10.0.0.20:5601. The Kibana interface should load. If it shows "Kibana server is not ready yet", wait another minute and refresh.

Troubleshooting:

  • Port 5601 not reachable — check firewall: sudo ufw allow 5601/tcp
  • "Unable to connect to Elasticsearch" — confirm Elasticsearch is running: curl http://localhost:9200
  • Kibana stuck on loading — on a 2 GB RAM VM, Kibana and Elasticsearch together consume most of the memory. If the VM has less than 512 MB free, stop Caldera: kill $(pgrep -f "caldera")

Step 3: Install Winlogbeat on the Windows endpoint

Winlogbeat is the Elastic Beat agent that forwards Windows event logs to Elasticsearch.

On PT-WIN-ENDPOINT:

# Download Winlogbeat
Invoke-WebRequest -Uri "https://artifacts.elastic.co/downloads/beats/winlogbeat/winlogbeat-8.15.0-windows-x86_64.zip" `
    -OutFile "C:\Tools\winlogbeat.zip"

# Extract
Expand-Archive "C:\Tools\winlogbeat.zip" -DestinationPath "C:\Program Files\" -Force

# Rename to a clean directory name
Rename-Item "C:\Program Files\winlogbeat-8.15.0-windows-x86_64" "C:\Program Files\Winlogbeat"

Configure Winlogbeat to send Sysmon and Security events:

notepad "C:\Program Files\Winlogbeat\winlogbeat.yml"

Replace the winlogbeat.event_logs section and output.elasticsearch section with:

winlogbeat.event_logs:
  - name: Microsoft-Windows-Sysmon/Operational
    processors:
      - add_tags:
          tags: [sysmon]
  - name: Security
    processors:
      - add_tags:
          tags: [security]

output.elasticsearch:
  hosts: ["10.0.0.20:9200"]

Remove or comment out any output.logstash section if it exists (only one output can be active).

Install and start the Winlogbeat service:

cd "C:\Program Files\Winlogbeat"

# Install the service (run in an Administrator PowerShell)
.\install-service-winlogbeat.ps1

# If execution policy blocks the script:
Set-ExecutionPolicy -ExecutionPolicy Bypass -Scope Process -Force
.\install-service-winlogbeat.ps1

# Start the service
Start-Service winlogbeat

# Verify
Get-Service winlogbeat | Select-Object Status, Name, StartType
Status  Name        StartType
------  ----        ---------
Running winlogbeat  Automatic

Troubleshooting:

  • Service won't start — check the Winlogbeat logs: Get-Content "C:\Program Files\Winlogbeat\logs\winlogbeat" -Tail 20. Common issues: can't reach Elasticsearch (check network), YAML syntax error in config.
  • "Connection refused" in logs — the endpoint can't reach Elasticsearch on port 9200. Test: Test-NetConnection 10.0.0.20 -Port 9200
  • "output.elasticsearch" and "output.logstash" both configured — only one output is allowed. Comment out the Logstash section.

Step 4: Create a data view in Kibana

Events are flowing but Kibana needs a data view to query them.

  1. In Kibana, go to Stack Management → Data Views (under Kibana section)
  2. Click "Create data view"
  3. Fill in:
Name:           winlogbeat-*
Index pattern:  winlogbeat-*
Timestamp field: @timestamp
  1. Click "Save data view to Kibana"

Now navigate to Discover (Analytics section). Select the winlogbeat-* data view from the dropdown. You should see events flowing in from the Windows endpoint.

Step 5: Verify with a detection query

In Kibana Discover, enter this KQL query in the search bar:

event.code: "10" and winlog.event_data.TargetImage: *lsass.exe

This is the Elastic KQL equivalent of the LSASS access detection. When no LSASS access has occurred, the query returns empty — that's expected. During Module 7 when you fire credential dumping techniques, this query will return results.

To verify data is flowing at all, use a broader query:

event.code: "1"

This shows all Sysmon Event 1 (process creation) events. You should see dozens of events from normal Windows activity.

Verification checklist

☐ Elasticsearch installed on PT-LINUX01 and responding on port 9200
☐ Kibana installed and accessible at http://10.0.0.20:5601
☐ Security features disabled for lab simplicity
☐ Winlogbeat installed on PT-WIN-ENDPOINT
☐ Winlogbeat configured for Sysmon + Security logs
☐ Winlogbeat service running
☐ Endpoint can reach Elasticsearch on port 9200
☐ Data view "winlogbeat-*" created in Kibana
☐ Events visible in Kibana Discover
☐ Process creation events (event.code: "1") visible
Next
PT1.12 — Smoke Test. Fire T1059.001 (PowerShell execution) and confirm telemetry lands in all three SIEMs. This is the final validation that the lab works.

You've built the lab and understand the validation gap.

Module 0 showed you why detection rules fail silently — vendor schema changes, attacker tool evolution, environment divergence, tuning drift. Module 1 gave you a working four-environment, three-SIEM purple-team lab. From here, you walk the kill chain technique by technique.

  • 61 ATT&CK techniques across 12 tactic modules — Initial Access through Impact, each walked end-to-end with attack commands, annotated telemetry, and multi-SIEM detection rules
  • Every detection in four formats — Sigma rule (canonical), Sentinel KQL, Defender XDR Advanced Hunting KQL, and Splunk SPL or Elastic. Tabbed side-by-side in every technique sub
  • Module 14 Capstone — CHAIN-HARVEST — full purple-team exercise on an AiTM credential-phishing chain. Multi-stage attack, detection results across all three SIEMs, coverage gaps, tuning recommendations
  • Programme template — coverage matrix, MTTD per technique, FP rates, detection quality scores, remediation backlog. Populated as you work, presentable to leadership by Module 14
  • Public Sigma rule repo — every detection rule in a GitHub repository. Alumni contribute via PR. The artefacts outlive the course
Unlock with Specialist — £25/mo See Full Syllabus

Cancel anytime