In this module
PT1.11 Secondary SIEM — Elastic Stack
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.
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 elasticsearchConfigure Elasticsearch for lab use:
sudo nano /etc/elasticsearch/elasticsearch.ymlFind 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: falseSave the file (Ctrl+O, Enter, Ctrl+X in nano).
# Start Elasticsearch
sudo systemctl enable elasticsearch
sudo systemctl start elasticsearchWait 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 -20Common 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 kibanaConfigure Kibana:
sudo nano /etc/kibana/kibana.ymlSet:
# 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 kibanaKibana 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, StartTypeStatus Name StartType
------ ---- ---------
Running winlogbeat AutomaticTroubleshooting:
- 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.
- In Kibana, go to Stack Management → Data Views (under Kibana section)
- Click "Create data view"
- Fill in:
Name: winlogbeat-*
Index pattern: winlogbeat-*
Timestamp field: @timestamp- 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.exeThis 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") visibleYou'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
Cancel anytime