What tools are covered by CTHP?

The supplied program lists Kali Purple, ELK Stack, Wazuh, Suricata, Velociraptor, Malcolm, Arkime, OpenCTI and OpenTAXII.

What should a SOC investigation report contain?

Scope, timeline, detection details, evidence, findings, hypotheses, remediation, retest results and limitations.

Technical Knowledge Base · Blue Team · SOC · Threat Hunting

CTHP Cyber Range, SIEM & Threat Hunting Professional: Advanced SOC Labs, Detection Engineering & Threat Hunting Workflows

CTHP Cyber Range SIEM and Threat Hunting Professional hero — Advanced cyber range, SIEM and threat hunting training covering SOC labs, detection engineering and investigation workflows.

Learning-first technical reference: build a controlled cyber range, deploy telemetry, simulate authorized activity, detect it, hunt across endpoint and network evidence, correlate intelligence and produce a professional investigation report.

Training scope: all examples use isolated authorized environments, synthetic data and controlled markers. The focus is defensive learning, detection validation and investigation.

Cyber Range Architecture
Proxy & IDS
Vulnerability Scanning
ELK SIEM
Detection Engineering
Wazuh
Velociraptor
Malcolm & Arkime
Threat Intelligence
Practical Labs
Final SOC Scenario
Reporting
Key Takeaways
Program Information

1. Cyber Range Architecture

A cyber range is most useful when it is isolated, repeatable and measurable. Before installing security tools, define hosts, roles, network boundaries, time synchronization, telemetry sources, synthetic identities and a reset procedure.

Cyber Range Architecture

Kali Purple→Lab Network→Web / Linux / Windows→Telemetry→SIEM→Threat Hunter

Interpretation: Every controlled action should have an observable telemetry path.

Practical Lab — Cyber Range Setup

Objective: Create a repeatable SOC training environment.

Step 1Virtualization/network

Step 2Deploy Kali Purple

Step 3Deploy Linux/Windows

Step 4Validate internal connectivity

Step 5Verify telemetry and time

Step 6Capture architecture evidence

2. Proxy & IDS Setup: NGINX + Suricata

NGINX provides application-facing HTTP evidence while Suricata provides network telemetry. Correlating both views helps an analyst distinguish an application event, a network observation and a detection decision.

AUTHORIZED LAB TEST GET /health?marker=CTHP-LAB-001 EXPECTED HTTP 200 NGINX marker Application marker Correlatable network event

NGINX + Suricata UISTATIC TRAINING SCREENSHOT

NGINX
GET /health
200 · CTHP-LAB-001

SURICATA
Flow observed
Timestamp aligned

14:10:02Z NGINX GET /health 200 14:10:02Z SURICATA flow observed 14:10:03Z SIEM correlation candidate NEXT: validate parsing and clock alignment.

What you see → application and network evidence. What it means → multiple telemetry layers describe one event. Next → enrich and test detection.

3. Vulnerability Scanning: ZAP & GVM

The supplied program includes ZAP and GVM. In the range, scanning should be limited to authorized lab targets. The SOC objective is to understand scanner traffic, result context and telemetry generated during the scan.

Vulnerability Scanner UISTATIC TRAINING SCREENSHOT

ZAP
Target: CTHP-LAB-WEB
Scope: authorized

GVM
Target group: LAB-ASSETS
Results: review

SCAN WINDOW 14:20–14:27Z HTTP requests: 184 IDS observations: 6 SIEM events: 6 QUESTION Which activity is expected scanner behavior?

What you see → scan activity and telemetry. Next → correlate scanner identity, time and scope.

4. ELK Stack SIEM: Ingest → Parse → Normalize → Search

ELK engineering is a data pipeline problem. A known synthetic event should be traceable from the source log through Logstash and Elasticsearch into Kibana with usable fields and a reliable timestamp.

CTHP ELK SIEM detection engineering workflow — ELK ingestion, parsing, normalization, search and detection engineering workflow for controlled CTHP SOC labs.

ELK Ingestion Pipeline

Source Log→Collector→Logstash→Elasticsearch→Kibana→Detection

Interpretation: Validate the same synthetic marker at each stage before using the data for detection.

CTHP-LAB-EVENT-001 source: cthp-web event.dataset: cthp.training event.kind: event message: controlled-training-event @timestamp: synchronized-lab-time

Kibana SIEM UISTATIC TRAINING SCREENSHOT

DATA VIEW
cthp-*
Indexed events

FIELDS
@timestamp
host.name
source.ip
event.dataset

SEARCH message: "CTHP-LAB-EVENT-001" RESULT 1 event host.name: CTHP-WEB status: ingested NEXT: validate parser + timestamp + enrichment.

What you see → searchable normalized event. What it means → ingestion works. Next → build detection logic from stable fields.

5. Detection Engineering

Detection engineering connects a behavior hypothesis to telemetry, a rule, a controlled test and a retest. The detection is not finished when the query is written; it must be exercised and tuned.

Detection Engineering Loop

Hypothesis→Telemetry→Rule→Controlled Test→Alert→Investigation→Tune→Retest

Interpretation: A detection should have explicit test conditions and an investigation path.

Detection Engineering UISTATIC TRAINING SCREENSHOT

RULE
CTHP-AUTH-001
Status: TEST

VALIDATION
Baseline: no alert
Controlled: alert

ALERT CTHP-AUTH-001 Host: CTHP-WIN User: LAB-USER Source: CTHP-TESTER Window: bounded ANALYST ACTION Validate sequence → enrich → correlate.

What you see → rule and validation state. Next → review noise and regression-test.

Dimension	Question	Evidence
Coverage	Does required telemetry exist?	Source inventory
Precision	Does controlled activity alert?	Positive test
Noise	What benign activity alerts?	False-positive review
Context	Can an analyst investigate?	Enrichment fields
Regression	Does the rule survive changes?	Retest

6. Wazuh Monitoring

Wazuh provides endpoint-oriented visibility. Linux and Windows agents, NGINX logs and alert rules can be correlated with SIEM and network evidence.

Wazuh Monitoring Flow

Linux / Windows Agent→Wazuh Manager→Decoder / Rule→Alert→SIEM→Investigation

Interpretation: Host identity and event time are essential correlation keys.

Wazuh Monitoring UISTATIC TRAINING SCREENSHOT

AGENTS
CTHP-LINUX · active
CTHP-WIN · active

ALERT
Rule: LAB-WEB-001
Source: NGINX

14:31:04Z NGINX request 14:31:04Z WAZUH parsed event 14:31:05Z SIEM indexed event 14:31:08Z analyst correlation NEXT: inspect endpoint evidence.

What you see → agent and alert context. Next → pivot into process/file evidence.

7. Incident Response with Velociraptor

Velociraptor is included for host connectivity, VFS-style evidence access and hunting. A collection should always have a defined host, artifact, time scope and evidence purpose.

Endpoint Investigation

Alert→Host→Artifact→Evidence→Timeline→Conclusion

Interpretation: Bounded collections make evidence easier to interpret and reproduce.

Velociraptor VFS UISTATIC TRAINING SCREENSHOT

CLIENT
CTHP-WIN
Online

COLLECTION
controlled-file-inventory
LAB-DIRECTORY

COLLECTION Host: CTHP-WIN Time: 14:42:10Z Result: 3 synthetic files NEXT: correlate file timestamps with SIEM.

What you see → scoped endpoint collection. Next → correlate timestamps with the case timeline.

8. Threat Hunting with Malcolm & Arkime

Threat hunting starts with a question. Malcolm and Arkime can expose network sessions and metadata for a defined asset and time window, which can then be correlated with endpoint and SIEM evidence.

CTHP threat hunting and final SOC investigation workflow — Threat hunting, network and endpoint evidence correlation, threat intelligence and final SOC investigation workflow.

Threat Hunting Question → Evidence

Question→Scope→Session Filter→Network Evidence→SIEM Pivot→Hypothesis

Interpretation: Every pivot should answer a specific uncertainty.

Malcolm / Arkime UISTATIC TRAINING SCREENSHOT

QUERY
source.ip = CTHP-LAB-HOST
Incident window

SESSIONS
23 flows
HTTP / TCP / DNS

14:55:01Z WEB → APP 14:55:02Z WEB → DNS 14:55:04Z WEB → TEST-SVC QUESTION Is the third flow expected? NEXT: correlate asset role + application logs.

What you see → sessions and a hunting query. Next → pivot into corroborating telemetry.

9. Threat Intelligence: OpenTAXII, Cabby & OpenCTI

The supplied program includes OpenTAXII, Cabby Client and OpenCTI. Intelligence should add context rather than automatically prove compromise. Review source, confidence, time and environmental relevance.

Threat Intelligence Correlation

Threat Source→TAXII→OpenCTI→Observed Event→Context→Analyst Decision

Interpretation: An indicator match is a correlation point that should be validated against behavior and independent telemetry.

OpenCTI Correlation UISTATIC TRAINING SCREENSHOT

INDICATOR
CTHP-SYNTH-001
Training source

OBSERVATION
Matching synthetic event
Context review

INDICATOR CTHP-SYNTH-001 Environment: CTHP-LAB INTERPRETATION Indicator adds context; it is not independent proof of compromise. NEXT: validate source + behavior.

What you see → intelligence and telemetry relationship. Next → corroborate behavior.

10. Practical Cyber Range & SOC Labs

The practical workflow is repeatable: setup → baseline → controlled simulation → telemetry → detection → hunting → reporting → remediation → retest.

Lab 01 — Cyber Range Setup

Objective: Build the controlled environment

Step 1Virtualization

Step 2Kali Purple

Step 3Linux/Windows

Step 4Telemetry

Step 5Time alignment

Step 6Evidence

Lab 02 — SIEM Deployment

Objective: Make a known event searchable

Step 1Source

Step 2Ingestion

Step 3Marker

Step 4Parsing

Step 5Kibana

Step 6Evidence

Lab 03 — Attack Detection Simulation

Objective: Validate a detection

Step 1Baseline

Step 2Controlled test

Step 3IDS/logs

Step 4Alert

Step 5Investigation

Step 6Tune

Lab 04 — Wazuh Monitoring

Objective: Correlate endpoint and web data

Step 1Agents

Step 2NGINX logs

Step 3Marker

Step 4Alert

Step 5Endpoint pivot

Step 6Retest

Lab 05 — Threat Hunting

Objective: Answer a defined hunting question

Step 1Question

Step 2Scope

Step 3Session query

Step 4SIEM pivot

Step 5Corroborate

Step 6Record

Lab 06 — Final SOC Investigation

Objective: Solve a synthetic multi-source case

Step 1Scope

Step 2Timeline

Step 3Alert

Step 4Network/endpoint

Step 5Intel context

Step 6Report/retest

Final Practical SOC Lab Control RoomSTATIC TRAINING SCREENSHOT

LAB STATE
Range: READY
Telemetry: READY
Agents: 2 online

CASE
CTHP-LAB-CASE-001
Status: INVESTIGATING

14:10 BASELINE 14:12 CONTROLLED TEST 14:13 IDS OBSERVATION 14:16 SIEM ALERT 14:18 NETWORK HUNT 14:21 ENDPOINT PIVOT 14:25 INTELLIGENCE CONTEXT 14:30 REPORT / RETEST OUTPUT scope → timeline → evidence → hypothesis → remediation → retest

What you see → complete SOC workflow. Next → produce the investigation report.

11. Final SOC Investigation Scenario

Training scenario: a synthetic web host generates an unusual sequence of events. The analyst must determine what changed from baseline using authorized telemetry only.

End-to-End Investigation

Baseline→Controlled Test→IDS→SIEM→Endpoint→Network Hunt→Intel→Report

Interpretation: The sequence models evidence correlation and is not a claim about an actual Academy incident.

CASE WORKSHEET SCOPE Authorized CTHP laboratory assets QUESTION What changed from baseline? EVIDENCE NGINX + Suricata + Wazuh + ELK + Malcolm/Arkime + intelligence context HYPOTHESIS Write a testable explanation. CONFIRM Record supporting and contradicting evidence. REMEDIATION Specific control/configuration change. RETEST Repeat the original controlled test.

12. Professional SOC Investigation Reporting

A strong report separates confirmed facts from hypotheses and shows how evidence supports each conclusion.

Final Report UISTATIC TRAINING SCREENSHOT

FINDINGS
ID · severity · asset · status

EVIDENCE
SIEM · IDS · Endpoint · Network

FINDING: CTHP-LAB-001 ROOT CAUSE / EVENT DESCRIPTION Evidence-backed statement CHAIN Alert → timeline → endpoint → network REMEDIATION Specific control/configuration action RETEST Original test repeated Result: PASS LIMITATIONS What was not demonstrated

What you see → findings, evidence, chain, remediation and retest. Next → archive evidence and close the case.

Artifact	Purpose	Minimum Content
Scope	Authorization boundary	Hosts + time window
Timeline	Event sequence	Timestamp + source
Detection	Alert logic	Rule/query + test
Network	Traffic corroboration	Flow/session evidence
Endpoint	Host corroboration	Artifact + host identity
Retest	Remediation validation	Original test after fix

Key Takeaways

Build the cyber range as an isolated, repeatable measurement environment.
Validate telemetry with known markers before relying on dashboards.
Correlate NGINX, Suricata, ELK and Wazuh evidence.
Detection engineering requires controlled tests, tuning and regression testing.
Threat hunting starts with a hypothesis, asset scope and time window.
Network, endpoint and intelligence tools provide complementary evidence.
Every lab should finish with remediation and retesting.
Reports should distinguish facts, hypotheses, intelligence context and limitations.

Program Information: Cyber Threat Hunting Professional (CTHP)

Cyber Range Architecture — Virtualization, Segmentation and Evidence

A production-minded learning range should be designed as a dependency graph. Hypervisor networking determines visibility; visibility determines whether sensors receive traffic; sensors generate telemetry; collectors transport it; parsers normalize it; SIEM components index it; detection logic evaluates it; endpoint and network tools provide pivots. Students should document each dependency before running a test.

What → Why → Architecture → Setup → Tool → Controlled Test → Output → Interpretation → Troubleshooting → Detection → Investigation → Retest

The learning flow for this module is deliberately consistent: first define the observable problem, explain why the component exists, map its position in the architecture, configure the controlled lab, use the relevant tool, generate a benign test marker, inspect output, interpret fields, troubleshoot failures, validate or tune detection, investigate correlated evidence, and finally repeat the test to prove the result.

What → Why → Architecture → Setup → Tool → Controlled Test → Output → Interpretation → Troubleshooting → Detection → Investigation → Retest

NGINX + Suricata — Reverse Proxy Telemetry and IDS Rule Lifecycle

NGINX and Suricata provide complementary views. NGINX describes application-facing requests and responses through access/error logs, while Suricata observes network traffic and emits structured events. The investigation becomes stronger when the two observations share timestamps, endpoints and a known training marker.

What → Why → Architecture → Setup → Tool → Controlled Test → Output → Interpretation → Troubleshooting → Detection → Investigation → Retest

ZAP + GVM — Scanning Methodology and Result Validation

ZAP and GVM should be treated as measurement tools. A scan produces observations that require validation. Scope, baseline, scan configuration, result evidence, asset context, application logs and retest status should all be documented. Severity is not a substitute for verification.

What → Why → Architecture → Setup → Tool → Controlled Test → Output → Interpretation → Troubleshooting → Detection → Investigation → Retest

ELK SIEM — Elasticsearch, Logstash, Kibana and Fleet

A SIEM workflow is valuable when raw events become consistent searchable records. Ingestion, parsing, normalization, enrichment and indexing are prerequisites to useful detection. Kibana then becomes an investigation interface rather than merely a dashboard.

What → Why → Architecture → Setup → Tool → Controlled Test → Output → Interpretation → Troubleshooting → Detection → Investigation → Retest

Detection Engineering — Hypothesis to Retest

Detection engineering is a repeatable loop: Detection Hypothesis → Data Source → Field Mapping → Query/Rule → Test Event → Alert → False Positive → Tuning → Retest. Every detection should be explainable and validated against a known event.

What → Why → Architecture → Setup → Tool → Controlled Test → Output → Interpretation → Troubleshooting → Detection → Investigation → Retest

Wazuh — Agents, Decoders, Rules and Endpoint Investigation

Wazuh contributes host-focused telemetry. Agents collect information, manager-side processing can decode and evaluate it, and alerts provide endpoint context. The analyst should correlate that context with the same time window used by network and SIEM investigation.

What → Why → Architecture → Setup → Tool → Controlled Test → Output → Interpretation → Troubleshooting → Detection → Investigation → Retest

Velociraptor — VFS, Collection and Hunting

Velociraptor investigation starts with a question. Select an artifact, scope collection, inspect results, preserve evidence metadata and correlate the result with other sources. VFS is useful for controlled file-system inspection and hunts can scale a repeatable collection method across authorized endpoints.

What → Why → Architecture → Setup → Tool → Controlled Test → Output → Interpretation → Troubleshooting → Detection → Investigation → Retest

Malcolm + Arkime — Network Hunting and Session Investigation

Network investigation becomes manageable when an analyst pivots from an alert to a bounded time window, candidate endpoints and sessions. Malcolm supports network-analysis workflows while Arkime provides session-oriented investigation and metadata. Packet evidence should be used according to capture scope and retention.

What → Why → Architecture → Setup → Tool → Controlled Test → Output → Interpretation → Troubleshooting → Detection → Investigation → Retest

Threat intelligence should add validated context rather than automatic attribution. TAXII-based sharing can transport structured intelligence, while OpenCTI can organize entities and relationships. Confidence and provenance must remain visible to the analyst.

What → Why → Architecture → Setup → Tool → Controlled Test → Output → Interpretation → Troubleshooting → Detection → Investigation → Retest

Cyber Range Build: Proxmox / VMware Networking Concepts

Layer	Question	Evidence to capture
Hypervisor	Which bridge/vSwitch connects the VM?	NIC + bridge/vSwitch configuration
IP plan	Which subnet belongs to the isolated range?	Address map
Routing	Where is the default gateway?	Route table
DNS	Which resolver is used?	Resolver configuration
Sensor visibility	Which interface sees test traffic?	Interface counters / packet evidence
Isolation	Can the range reach unintended resources?	Segmentation validation

A common lab troubleshooting mistake is starting with Kibana when the upstream packet or log path is broken. Work from the source outward: network path → service → sensor → collector → parser → index → dashboard → detection.

Kali Purple — Analyst Workflow and Controlled Test Markers

Kali Purple is the controlled operator environment in this program. Use it to generate authorized traffic, inspect responses, validate scanning behavior, query telemetry and collect evidence. Test markers make correlation deterministic.

Benign HTTP correlation marker

curl -i -H 'X-CTHP-Lab: CTHP-LAB-EVENT-001' http://<AUTHORIZED-LAB-HOST>/

Synthetic detection event

CTHP-LAB-EVENT-001
host.name=CTHP-WEB
event.dataset=cthp.training
event.kind=event
event.category=web
cthp.test=true

After the marker is generated, the analyst should search for it in application logs, network events and SIEM records. If the marker appears in one source but not another, follow the pipeline boundary instead of assuming the detection logic is wrong.

NGINX + Suricata — Controlled Test, Output and Interpretation

Training-only Suricata marker rule

alert http any any -> any any (msg:"CTHP LAB marker observed"; http.header; content:"X-CTHP-Lab"; sid:9000001; rev:1;)

Suricata event details — synthetic training UI

EVE JSON
timestamp: 2026-09-16T14:13:08Z
event_type: alert
signature: CTHP LAB marker observed
src_ip: 10.10.20.15
dest_ip: 10.10.20.30
proto: TCP
flow_id: LAB-FLOW-001
http.host: cthp-web

What you see	What it means	What to check	What to do next
signature	The configured rule matched	Is the rule intended for this marker?	Review event context
flow_id	Network correlation key	Does another source share it?	Pivot to Arkime/Malcolm
timestamp	Timeline anchor	Are clocks/timezones aligned?	Correlate NGINX/SIEM
source/destination	Endpoints involved	Are they in lab scope?	Record asset context

Rule lifecycle: write the hypothesis, validate syntax, generate the benign marker, confirm EVE output, review expected/benign matches, tune the rule, and retest. Keep the rule inside the authorized range.

ZAP + GVM — Scan Lifecycle and Evidence

Scope definition → Baseline → Scan profile → Controlled scan → Results → Validation → Remediation → Rescan

ZAP lab connectivity check

curl -s 'http://<AUTHORIZED-ZAP-HOST>:8080/JSON/core/view/version/?apikey=<LAB_API_KEY>'

ZAP scan results — synthetic training UI

ZAP
Target: http://cthp-web.lab
Mode: Controlled training scan
Passive alerts: 4
Active findings: 2
Window: 14:12–14:14
Status: Review required
Evidence: request + response + timestamp

GVM result — synthetic training UI

GVM Results
Host: 10.10.20.30
Finding: Example training finding
Severity: High
Observed: 14:12:41Z
Status: Needs validation
Evidence: scanner output + service metadata
Retest: Pending

Interpretation requires context. Compare scanner timing and identity with NGINX and Suricata records. A scheduled authorized scanner can explain a large amount of traffic. Conversely, a finding outside the expected scan window deserves a separate investigation path.

ELK — Log Parsing, Normalization, Enrichment and Kibana

Sources → Logstash / Beats / integrations → Parsing → Normalization → Enrichment → Elasticsearch → Kibana → Detection

Synthetic normalized event

{
  "@timestamp":"2026-09-16T14:14:02Z",
  "host.name":"CTHP-WEB",
  "event.dataset":"cthp.training",
  "event.kind":"event",
  "cthp.marker":"CTHP-LAB-EVENT-001",
  "source.ip":"10.10.20.15",
  "http.request.method":"GET",
  "url.path":"/"
}

Kibana Discover — synthetic training UI

Kibana Discover
Data view: cthp-*
Time range: Last 30 minutes

14:14:02 CTHP-WEB cthp.training CTHP-LAB-EVENT-001
14:13:08 SURICATA alert CTHP LAB marker observed
14:12:41 GVM vulnerability Needs validation

Fields:
@timestamp | host.name | event.dataset | source.ip | cthp.marker

Kibana detection/query — synthetic training UI

Detection / Query
event.dataset:cthp.training AND cthp.marker:CTHP-LAB-EVENT-001
Matches: 3
Rule: CTHP-DET-001
Severity: Medium
Last match: 14:15:02Z
Action: Review correlated sources

Layer	Failure symptom	Likely boundary
Source	No raw event	Service/log generation
Collector	Raw source exists, SIEM empty	Input/transport
Parser	Event exists but fields missing	Mapping/parser
Index	Events received but not searchable	Index/data view/time range
Detection	Events searchable but no alert	Rule/query logic

Detection Engineering Workbench

Detection Hypothesis ↓ Data Source ↓ Field Mapping ↓ Query / Rule ↓ CTHP-LAB-EVENT-001 ↓ Alert ↓ False Positive Review ↓ Tuning ↓ Retest

CTHP detection validation record

Detection ID: CTHP-DET-001
Data Source: SIEM
Test Marker: CTHP-LAB-EVENT-001
Expected Alert: Yes
Actual Alert: Yes
False Positive: No
Retest: Pass

Sigma-style detection concepts are useful because the behavior can be described independently from a particular query language. Document the behavior, required fields, selection logic, scope and known benign examples, then translate it to the deployed SIEM. The important artifact is traceability from hypothesis to evidence.

Wazuh — Agent Architecture, Alert Details and Endpoint Pivot

Linux / Windows Agent → Wazuh Manager → Decoders → Rules → Alerts → Analyst → Host pivot

Benign endpoint marker

echo 'CTHP-LAB-EVENT-001 endpoint validation' >> /tmp/cthp-lab-marker.log

Wazuh alert details — synthetic training UI

Wazuh Alert
Rule ID: CTHP-DET-001
Level: 7
Agent: CTHP-LINUX-01
Marker: CTHP-LAB-EVENT-001
Timestamp: 14:17:09Z

Decoded fields:
host.name
file.path
event.dataset
cthp.test

What you see	Meaning	Check	Next
Agent	Endpoint identity	Is it connected/current?	Inspect host telemetry
Rule	Detection metadata	Why did it fire?	Review decoder/rule context
file.path	Concrete host evidence	Expected lab change?	Correlate timestamp

Velociraptor — VFS and Evidence Collection

Velociraptor VFS — synthetic training UI

VFS
Client: CTHP-LINUX-01
Path: /var/log/nginx/
Selected: access.log
Artifact: Generic.Linux.FileFinder
Status: Complete
Observed: 14:14:02Z

Use the smallest collection that answers the investigation question. Record client, artifact, path/scope, timestamp and evidence identifier. If a collection returns nothing, verify host connectivity, artifact scope, permissions and expected path before concluding that no evidence exists.

Malcolm + Arkime — Session Investigation

Arkime session details — synthetic training UI

Arkime
Session: LAB-FLOW-001
Start: 14:13:07Z
Duration: 1.8s
Source: 10.10.20.15
Destination: 10.10.20.30:80
Protocol: HTTP
Bytes: 1.2 KB
Tags: CTHP-LAB / WEB

Malcolm search view — synthetic training UI

Malcolm Search
Query: CTHP-LAB-EVENT-001
Time: 14:12–14:16
Results: 3

14:13:08 Suricata alert
14:13:09 HTTP session
14:14:02 NGINX request

What you see: bounded sessions and metadata. What it means: the alert can be tied to a specific conversation. What to check: endpoint pair, timing, protocol and capture scope. What to do next: compare with application and SIEM evidence and expand into packet details only when available and justified.

OpenTAXII + OpenCTI — Intelligence Lifecycle and Relationship Graph

Indicator/report → TAXII transport → OpenCTI ingestion → Entity normalization → Relationship graph → Confidence review → Investigation context

OpenCTI relationship graph — synthetic training UI

OpenCTI
Entity: Synthetic-Lab-Indicator-001
Confidence: Training / synthetic

Indicator → observed-on → CTHP-WEB
Indicator → related-to → CTHP Training Campaign
Observation: 14:24:00Z

Analyst action:
validate original observation before using context

An intelligence match should not become a conclusion merely because an indicator appears in a platform. Validate provenance, observation time, confidence and whether the indicator actually relates to the asset or event under investigation.

How the Tools Work Together — CTHP Ecosystem

Kali Purple ↓ Controlled Activity NGINX + Suricata ↓ Telemetry ELK / Wazuh ↓ Detection Velociraptor ↓ Endpoint Evidence Malcolm / Arkime ↓ Network Evidence OpenCTI / OpenTAXII ↓ Intelligence Context Final Investigation → Report → Retest

The ecosystem is easiest to understand as a chain of evidence. Application telemetry answers what the service saw; Suricata answers what the network sensor observed; SIEM provides searchable correlation; Wazuh and Velociraptor add endpoint evidence; Malcolm and Arkime add network/session context; OpenCTI/TAXII adds structured intelligence context.

Synthetic Training Scenarios — Realistic SOC Practice

Scenario	Primary evidence	Investigation logic
Web reconnaissance detection	NGINX + Suricata + SIEM	Check request sequence, source, timing and authorization
Suspicious HTTP sequence	NGINX + Suricata + Arkime	Correlate application and network session
Repeated authentication failures	Auth logs + SIEM + Wazuh	Check account, source, time concentration and expected tests
Unexpected endpoint file creation	Wazuh + Velociraptor	Validate path, timestamp and host context
Suspicious network session	Malcolm + Arkime + SIEM	Pivot from alert to endpoints/session
Scanner vs genuine attack	ZAP/GVM + NGINX	Compare scan identity/window with application evidence
Multi-source alert correlation	SIEM + Wazuh + Suricata	Build one timeline from independent sources
Threat-intelligence match validation	OpenCTI + original observation	Check provenance, confidence and asset relevance

These are synthetic training scenarios based on the supplied learning objectives. They are not claims about actual WhiteDavid23 Academy student incidents.

Investigation Timeline — End-to-End SOC Case

14:10 Baseline ↓ 14:12 Controlled Activity ↓ 14:13 Suricata Observation ↓ 14:14 NGINX Event ↓ 14:15 SIEM Alert ↓ 14:17 Wazuh Pivot ↓ 14:20 Arkime Hunt ↓ 14:24 Intelligence Context ↓ 14:30 Report + Retest

The timestamps are synthetic training data. The workflow teaches the analyst to establish baseline, observe controlled activity, correlate telemetry, pivot to endpoint and network evidence, validate intelligence context, document the finding and prove the final detection through retesting.

SOC Lab Troubleshooting Playbook

Problem	Checks	Next step
Elasticsearch unavailable	Service, port, storage, recent logs	Restore dependency and regenerate marker
Kibana data view empty	Data view, index, time range, ingestion timestamp	Trace one known marker upstream
Logstash not receiving	Pipeline input, config, permissions, logs	Send one controlled event through pipeline
Wazuh agent disconnected	Agent service, registration, network, manager	Reconnect disposable lab agent
Suricata events missing	Interface, capture visibility, rule load, EVE output	Generate benign traffic and check counters
NGINX logs not parsed	Raw format, permissions, field mapping	Compare raw vs normalized record
Timestamp mismatch	Timezone, clock, UTC conversion	Correlate using one known marker
DNS/network issue	Resolver, routes, gateway, firewall	Validate authorized lab paths
Proxmox VM networking issue	Bridge/vSwitch, guest NIC, IP	Prove VM-to-VM connectivity first
Arkime/PCAP visibility issue	Capture interface, ingestion, retention, time range	Generate known session and verify
OpenCTI ingestion issue	Connector/TAXII endpoint, auth, object format	Use synthetic object and verify relationship

Practical Evidence Templates

Detection Validation Sheet

Field	Value
Detection ID	CTHP-DET-001
Data Source	SIEM
Test Marker	CTHP-LAB-EVENT-001
Expected Alert	Yes
Actual Alert	Yes
False Positive	No
Retest	Pass

Incident Timeline Template

Time	Source	Observation	Evidence ID	Action
14:__	NGINX	Controlled request	EV-001	Pivot by source/time
14:__	Suricata	Network event	EV-002	Correlate flow
14:__	SIEM	Detection	EV-003	Open alert
14:__	Wazuh	Endpoint context	EV-004	Host pivot
14:__	Arkime	Session evidence	EV-005	Validate network context

Threat Hunting Worksheet

Field	Entry
Hypothesis
Time range
Hosts/users
Data sources
Query/filter
Evidence
Benign explanation
Conclusion
Follow-up

Evidence Collection Sheet

Evidence ID	Source	Artifact
EV-001	SIEM	Event JSON
EV-002	Suricata	EVE event
EV-003	Wazuh	Alert details
EV-004	Arkime	Session metadata

Detection Tuning Sheet

Version	Change	Reason
v1	Initial rule	Baseline hypothesis
v2	Scope/field refinement	Reduce benign matches
v3	Final tuning	Validated behavior

Final SOC Report Template

Section	Document
Executive summary	Factual finding
Scope	Assets, dates and lab boundaries
Timeline	Ordered observations and evidence IDs
Detection	Rule/query and trigger
Endpoint evidence	Wazuh/Velociraptor
Network evidence	Suricata/Malcolm/Arkime
Intelligence	OpenCTI/TAXII context and confidence
Assessment	Supported facts and uncertainties
Remediation	Defensive corrective actions
Retest	Validation result
Appendix	Queries, screenshots and evidence metadata

End-to-End Capstone — Final SOC Investigation Scenario

Scope → Controlled Marker → NGINX/Suricata → SIEM Alert → Wazuh Pivot → Velociraptor Collection → Malcolm/Arkime Hunt → OpenCTI Context → Timeline → Detection Tuning → Retest → Final Report

The capstone demonstrates the complete CTHP workflow. Every major conclusion should have a source, timestamp and evidence identifier. Where telemetry is unavailable, document the limitation instead of assuming the missing fact.

AEO / GEO Direct Answers

What is CTHP? Cyber Threat Hunting Professional (CTHP) is the WhiteDavid23 Academy program supplied for this article, covering cyber range setup, SIEM deployment, attack detection, endpoint investigation, network hunting and threat intelligence.

What is a Cyber Range? A cyber range is a controlled environment of virtualized systems, networks and security tooling where authorized activity can be simulated and investigated safely.

What is SIEM? A SIEM centralizes security telemetry so analysts can search, correlate, detect and investigate events.

What is Threat Hunting? Threat hunting is hypothesis-driven searching across available telemetry for suspicious or noteworthy behavior that may not already have an alert.

What is the difference between SIEM monitoring and threat hunting? Monitoring evaluates incoming telemetry against dashboards and detection logic; threat hunting actively searches evidence from a stated hypothesis.

What does Wazuh contribute to a SOC? Wazuh provides endpoint-focused collection and detection context through agents, decoders and rules.

Why use Suricata with ELK/Wazuh? Suricata provides network event telemetry that can be centralized and correlated with endpoint and application data.

What is Arkime used for? Arkime supports session-oriented network investigation, allowing analysts to pivot from alerts to network conversations and metadata.

Technical FAQ — 15 Practical Questions

CTHP kis level ke learners ke liye hai? The supplied program level is Intermediate to Advanced.

Cyber Range mein kya practice hoti hai? The supplied program includes range setup, SIEM deployment, simulated attack detection, monitoring, threat hunting and a final SOC investigation scenario.

ELK aur Wazuh ka relationship kya hai? The program teaches both. ELK provides general log/search analytics, while Wazuh contributes endpoint-focused collection and detection; exact integration depends on deployment.

Suricata SIEM se kaise integrate hota hai? Suricata can emit structured network events that a collection pipeline can ingest, normalize and index.

Threat hunting aur incident response mein difference? Threat hunting is hypothesis-driven searching; incident response is the broader process of validating, containing, remediating and documenting an identified incident.

Malcolm aur Arkime ka role kya hai? They support network/session investigation and help analysts pivot from alerts into network evidence.

OpenCTI kya karta hai? OpenCTI organizes intelligence entities and relationships for structured investigation context.

OpenTAXII ka role kya hai? OpenTAXII supports TAXII-based threat-intelligence sharing workflows.

Practical exam mein kya demonstrate karna hota hai? The supplied structure specifies SIEM setup, log ingestion, simulated-attack detection, threat hunting and an investigation report during the practical examination.

Minimum hardware requirements kya hain? The supplied requirements specify minimum 16GB RAM, 32GB recommended, virtualization support, Linux knowledge recommended and strong internet.

Linux knowledge kitni useful hai? Linux knowledge is explicitly recommended and is useful for lab setup, services, logs and command-line troubleshooting.

Detection validate kaise karein? Use a known synthetic marker, confirm telemetry, validate the alert, review false positives, tune and perform a documented retest.

Scanner finding ko confirmed attack maan sakte hain? No. Scanner observations should be validated against asset context, configuration, logs and the authorized testing window.

Timestamps important kyun hain? Timestamps provide the common axis for correlating application, network, SIEM, endpoint and intelligence observations.

Synthetic scenario label kyun zaroori hai? It clearly separates educational exercises from claims about real Academy incidents or student experiences.

Item	Supplied Detail
Certification	Cyber Threat Hunting Professional (CTHP)
Offered By	WhiteDavid23 Academy
Duration	4 Months (Blue Team + SOC Advanced Program)
Mode	Live + Cyber Range Lab + Recorded Access
Level	Intermediate to Advanced
Exam	3 Hour MCQ + 3 Hour Theory + 6 Hour Practical Lab Exam
Fee	36999

Course Modules

1. Building a Cyber Range — Kali Purple, Proxmox, Kali Linux, lab architecture and secure testing environment.

2. Proxy & IDS Setup — NGINX, Suricata, Linux/Windows web servers, application deployment and attack-traffic testing.

3. Vulnerability Scanning — ZAP, GVM, scans and result analysis.

4. SIEM Setup — ELK, Kibana HTTPS, log integration, Fleet Server and host enrollment.

5. Detection & Monitoring — reconnaissance, exploitation attempts, alerts and log enrichment.

6. Wazuh Monitoring — Wazuh, Linux/Windows agents, NGINX logs, webshell detection and vulnerability integration.

7. Incident Response — Velociraptor, Linux/Windows hosts, VFS and threat hunting.

8. Threat Hunting — Malcolm, Cyberville Lab exploration, hunting workflows and Arkime.

9. Threat Intelligence — OpenTAXII, Cabby Client, OpenCTI and threat-data correlation.

Practical Labs Included

Cyber Range Setup Lab · SIEM Deployment Lab · Attack Detection Simulation · Wazuh Monitoring Lab · Threat Hunting Exercises · Final SOC Investigation Scenario.

Tools Covered

Kali Purple · ELK Stack · Wazuh · Suricata IDS · Velociraptor · Malcolm · Arkime · OpenCTI · OpenTAXII.

System Requirements

Minimum 16GB RAM (32GB Recommended) · Proxmox / VMware virtualization support · Linux Knowledge Recommended · Strong Internet Connection.

Career Roles

SOC Analyst · Threat Hunter · SIEM Engineer · Blue Team Specialist · Detection Engineer.

AEO Quick Answer

What Is CTHP Cyber Threat Hunting Professional?

CTHP is a Blue Team and SOC-oriented training program supplied by WhiteDavid23 Academy combining cyber-range construction, SIEM deployment, attack-detection simulation, endpoint monitoring, threat hunting and threat-intelligence correlation. The learning workflow is controlled and evidence-first: generate a known event, observe it across telemetry sources, detect it, investigate it, document evidence and retest.

Technical Foundations: SOC, SIEM and Threat Hunting

A SOC workflow becomes measurable when every stage has an observable input and output. The cyber range supplies controlled assets, telemetry records activity, the SIEM centralizes events, detection engineering turns hypotheses into repeatable tests, and hunting tools provide deeper pivots.

Core distinction: SIEM monitoring focuses on collecting, searching and alerting on telemetry; threat hunting begins with a question or hypothesis and proactively searches evidence for supporting or contradicting signals.

Concept	Purpose	CTHP Evidence
Cyber Range	Controlled environment	Hosts, network, baseline
SIEM	Centralized telemetry	Normalized events, alerts
IDS	Network observation	Suricata events
Endpoint Monitoring	Host evidence	Wazuh / Velociraptor
Threat Hunting	Hypothesis-driven search	Queries, sessions, pivots
Threat Intelligence	Context and relationships	OpenCTI / TAXII

Cyber Range Build: Step-by-Step Lab Structure

Start with an inventory. Give every virtual machine a stable role and hostname, isolate the laboratory network, document the expected telemetry path and create a reset point.

Build Sequence

01 — PlanDefine authorized assets, network segments, storage and reset points.

02 — VirtualizeUse the supported Proxmox/VMware environment and verify virtualization support.

03 — DeployPrepare Kali Purple plus Linux/Windows lab hosts.

04 — BaselineRecord host names, IPs, services and normal traffic.

05 — TelemetryConnect logs, IDS and endpoint monitoring.

06 — ValidateUse a synthetic marker and confirm every pipeline stage.

Safe lab marker

CTHP-LAB-BASELINE-001 environment=authorized-training asset=CTHP-WEB purpose=telemetry-validation

Next: do not tune detections until the marker is searchable in the SIEM and its timestamp is consistent across sources.

NGINX + Suricata: Network and Application Evidence Together

NGINX records the application-facing request while Suricata supplies network telemetry. Compare time, source, destination and event context instead of relying on one dashboard.

Application-to-Network Evidence Path

Lab Client→NGINX→Application→Suricata→SIEM

Interpretation: one controlled request can create multiple evidence records.

Safe HTTP payload / marker

GET /training?marker=CTHP-LAB-HTTP-001 HTTP/1.1 Host: cthp-web.lab User-Agent: CTHP-Lab/1.0 Connection: close

How to use: 1) send only to the authorized lab web server; 2) verify NGINX log; 3) search the marker in ELK/Wazuh; 4) inspect Suricata/session evidence; 5) compare timestamps; 6) save evidence; 7) validate detection.

Training interpretation: this is a deterministic telemetry marker, not an exploit.

Vulnerability Scanning: ZAP and GVM as SOC Telemetry Sources

Scanning is useful for defenders because scanner traffic creates recognizable patterns and findings that can be compared with observed telemetry. Keep all scans inside authorized lab scope.

ZAP / GVM SCAN WORKBENCHAUTHORIZED LAB

TargetCTHP-WEB

ScopeLAB

Requests184

StatusComplete

ZAP
Passive observations
Active test window
Finding review

GVM
Target group: LAB-ASSETS
Result validation

What you see → scanner scope/results. Next → correlate with network and web logs.

Safe scanner validation checklist

SCOPE = CTHP-LAB-WEB WINDOW = bounded training window MARKER = CTHP-LAB-SCAN-001 1. Confirm target authorization 2. Start lab scan 3. Verify NGINX events 4. Verify Suricata observations 5. Verify SIEM ingestion 6. Document result

ELK Stack Deep Dive: Ingestion, Parsing and Search

Follow the data path. If a document is missing, test the earliest stage first. If a document exists but fields are wrong, compare raw input with parsed output before changing detection logic.

ELK Data Pipeline

Source Logs→Collector→Logstash→Elasticsearch→Kibana

Synthetic structured event

{ "event.dataset": "cthp.training", "event.kind": "event", "event.id": "CTHP-LAB-EVENT-001", "host.name": "CTHP-WEB", "event.action": "controlled-test", "training.marker": "CTHP-LAB-EVENT-001" }

KIBANA DISCOVER — TRAINING VIEWSTATIC MOCKUP

Indexcthp-*

HostCTHP-WEB

StateIndexed

query: "CTHP-LAB-EVENT-001" @timestamp: synchronized-lab-time event.dataset: cthp.training host.name: CTHP-WEB result: searchable

Check: time range, data view, index, parser fields and host identity. Next: build a narrow detection.

Detection Engineering: From Hypothesis to Retest

Detection engineering is a lifecycle. Define behavior, identify telemetry, choose stable fields, write the detection, test with a controlled marker, review false positives, tune and repeat.

Detection Lifecycle

Hypothesis→Telemetry→Rule→Controlled Test→Alert→Tune→Retest

Detection validation record

DETECTION-ID: CTHP-DET-001 DATA-SOURCE: ELK + Wazuh TEST-MARKER: CTHP-LAB-EVENT-001 BASELINE: no alert CONTROLLED TEST: expected alert ACTUAL RESULT: record observed state FALSE POSITIVE REVIEW: record examples RETEST: repeat original test LIMITATION: record telemetry gaps

DETECTION ENGINEERING WORKBENCHTEST MODE

RULE
CTHP-DET-001
State: TEST
Data: ELK/Wazuh

VALIDATION
Baseline: PASS
Positive test: PASS
Noise review: OPEN

ALERT CTHP-DET-001 host: CTHP-WEB marker: CTHP-LAB-EVENT-001 action: controlled-test ANALYST: validate → enrich → correlate → document

Next: tune after confirming the raw event and required fields.

Wazuh: Endpoint Monitoring and Investigation Pivots

Use Wazuh to establish endpoint visibility, then pivot from an alert to host identity and related evidence. NGINX log collection can connect application activity with the host.

Safe endpoint training marker

CTHP-LAB-ENDPOINT-001 host=CTHP-LINUX artifact=training-marker purpose=endpoint-telemetry-validation

Procedure: verify agent → generate/record marker in designated lab source → confirm Wazuh receives it → inspect decoded/rule context → pivot to ELK/network evidence → record timeline.

WAZUH MONITORINGSTATIC MOCKUP

Agents2

Online2

Alerts1

Case001

CTHP-LINUX
Agent: active
Source: NGINX
Marker: observed

ALERT CONTEXT
Rule: LAB-WEB-001
Timestamp aligned
Pivot: SIEM

What you see → endpoint status/context. Next → pivot to host and network evidence.

Velociraptor: Scoped Endpoint Evidence Collection

Use Velociraptor when a SIEM alert needs endpoint corroboration. Define client, artifact and time window before collection. Training remote actions should remain benign evidence-collection tasks.

Endpoint Investigation Chain

SIEM Alert→Host→Artifact→Evidence→Timeline→Finding

VELOCIRAPTOR VFS / COLLECTIONSTATIC MOCKUP

CLIENT
CTHP-WIN
Status: Online
Scope: LAB

COLLECTION
Artifact: controlled inventory
Window: bounded
Result: synthetic

COLLECTION-ID: CTHP-COL-001 HOST: CTHP-WIN PURPOSE: corroborate SIEM timeline RESULT: evidence collected NEXT: compare timestamps with network events

Evidence rule: collect only what is necessary for the hypothesis and document source/time/artifact.

Malcolm & Arkime: Network Threat Hunting Workflow

Begin with a hunting question. Constrain asset and time, inspect session metadata, then pivot into independent endpoint or SIEM evidence.

MALCOLM / ARKIME HUNT VIEWSTATIC MOCKUP

AssetCTHP-WEB

Window15 min

Flows23

PivotSIEM

QUERY: source.asset = CTHP-WEB time = incident-window SESSIONS: HTTP → expected DNS → expected TEST-SVC → investigate NEXT: asset role → application log → endpoint evidence

Interpretation: an unusual session is a lead, not a conclusion. Corroborate it.

Threat Intelligence Correlation: OpenTAXII + OpenCTI

Review source, confidence, timestamp and relationships. A training indicator match is contextual evidence, not automatic proof of compromise.

Intelligence Correlation

Source→TAXII→OpenCTI→Observed Event→Context→Decision

Synthetic intelligence marker

indicator=CTHP-SYNTH-001 source=training confidence=lab-context environment=CTHP-LAB purpose=correlation-test

OPENCTI CORRELATION VIEWSTATIC MOCKUP

INDICATOR
CTHP-SYNTH-001
Source: training
Confidence: lab-context

OBSERVED EVENT
Same marker
Asset: CTHP-LAB
Independent evidence required

RELATIONSHIP indicator → observed-event INTERPRETATION Contextual match only. NEXT validate behavior + source + timestamp

Next: enrich the case, then document confidence and limitations.

Safe Payload & Code Usage: Complete Step-by-Step Structure

In this article, payload means a benign synthetic input that creates observable telemetry. It is intentionally designed for isolated authorized training and does not provide credential theft, destructive actions, persistence, evasion or unauthorized access.

Payload 01 — HTTP marker

GET /training?event=CTHP-LAB-HTTP-001 HTTP/1.1 Host: cthp-web.lab User-Agent: CTHP-Lab/1.0

How to Use Payload 01

Step 1Confirm CTHP-WEB is an authorized lab target.

Step 2Send the marker only to the lab web service.

Step 3Verify the NGINX access event.

Step 4Search the exact marker in ELK/Wazuh.

Step 5Compare Suricata or session timestamps.

Step 6Capture evidence and validate the detection.

Payload 02 — Synthetic application log

CTHP-LAB-APP-002 level=INFO action=training_test host=CTHP-APP user=LAB-USER marker=CTHP-LAB-APP-002

Use: place the line only in the designated lab test-log source → wait for ingestion → search the marker → confirm field parsing → compare timestamps → record the result. Never inject training markers into production logs.

Safety boundary: replace no placeholder with real credentials, public targets, third-party IPs or operational attack instructions.

Output → Interpretation → Debugging → Fix → Retest

Observed Output	Interpretation	Next Action
Source log exists, SIEM empty	Ingestion/indexing gap	Check collector → pipeline → index
SIEM event exists, fields missing	Parser/normalization gap	Compare raw vs parsed event
Alert fires without context	Enrichment gap	Add host/user/network context
Network event exists, endpoint absent	Endpoint visibility gap	Check agent/collection scope
Intel matches, behavior absent	Context-only match	Validate independent evidence
Retest no alert	Potential remediation success	Verify telemetry still exists

SOC Lab Troubleshooting Playbook

Kibana shows no events

Check source log, collector, Logstash pipeline, Elasticsearch index/data view and time range. Check timezone alignment before assuming ingestion failure.

Wazuh agent is offline

Check lab host connectivity, agent service state, enrollment identity and manager visibility. Confirm the VM is actually running.

Suricata has no expected event

Verify the intended lab interface sees the traffic and that event output is being written where the collector expects it.

NGINX fields are wrong

Compare the raw access-log line with parser/decoder output. Correct field mapping before tuning detection.

Arkime/Malcolm shows sessions but SIEM has none

Compare capture scope, timestamps and ingestion windows. Network capture and SIEM ingestion are separate pipelines.

OpenCTI correlation is confusing

Review source, confidence, timestamp and relationships. Do not treat an isolated indicator match as independent confirmation.

Realistic Training Scenarios

Scenario 1 — Web scan vs application event: a bounded scanner runs against a lab host. The analyst distinguishes expected scanner behavior from another application event using NGINX, Suricata and SIEM timestamps.

Scenario 2 — Endpoint correlation: a synthetic web marker appears and a corresponding endpoint artifact is observed within the same controlled window. Wazuh and Velociraptor evidence are correlated without assuming malicious intent.

Scenario 3 — Network hunt: a synthetic case contains several sessions. The analyst investigates one unusual flow, pivots to the SIEM, checks the asset role and records evidence supporting or contradicting the hypothesis.

Scenario 4 — Intelligence context: a training indicator is present in OpenCTI and appears in a synthetic event. The analyst validates source and behavior before documenting significance.

These scenarios are constructed for training; they are not claims about actual WhiteDavid23 incidents or student cases.

Final SOC Investigation: Multi-Source Capstone

The capstone requires the learner to combine multiple telemetry sources instead of solving a case from one dashboard.

End-to-End Investigation

Baseline→Controlled Test→IDS→SIEM→Endpoint→Network Hunt→Intel→Report

14:10 Baseline recorded

14:12 Synthetic activity generated

14:13 NGINX + Suricata evidence observed

14:15 SIEM detection validated

14:18 Wazuh endpoint pivot

14:21 Malcolm/Arkime hunt

14:24 OpenCTI context reviewed

14:30 Report + remediation + retest

SOC Investigation Report Template

Reusable analyst report skeleton

CASE-ID: CTHP-LAB-CASE-001 1. SCOPE Authorized assets + time window 2. QUESTION What changed from baseline? 3. TIMELINE Timestamp + source + event 4. DETECTION Rule/query + expected/actual result 5. EVIDENCE SIEM + IDS + endpoint + network 6. HYPOTHESIS Supporting evidence Contradicting evidence 7. CONCLUSION Evidence-backed statement 8. REMEDIATION Specific control/configuration change 9. RETEST Original controlled test repeated 10. LIMITATIONS Telemetry gaps / unresolved uncertainty

Evidence Quality: What an Analyst Should and Should Not Conclude

Evidence	Supports	Does Not Prove	Next Pivot
NGINX request	Application activity	Malicious intent	Source/time correlation
Suricata event	Network observation	Host compromise	Session/context
Wazuh alert	Endpoint rule match	Root cause alone	Artifact review
Velociraptor artifact	Host evidence	Complete incident story	Timeline correlation
Arkime session	Observed communication	Malicious purpose	Application/endpoint pivot
OpenCTI match	Threat context	Independent confirmation	Source + behavior validation

SEO, AEO & GEO Optimization Blueprint

Primary entity: Cyber Threat Hunting Professional (CTHP). Semantic cluster: cyber range, SOC, SIEM, ELK, Wazuh, Suricata, detection engineering, Velociraptor, Malcolm, Arkime, OpenCTI, OpenTAXII and threat hunting.

SEO/AEO Element	Implementation
CTR Title	CTHP Cyber Range, SIEM & Threat Hunting Professional: Advanced SOC Labs, Detection Engineering & Threat Hunting
Search Intent	Technical learning + SOC workflow + course reference
Answer Intent	Direct definitions + procedural explanations
Entity Coverage	CTHP + major tools in the supplied curriculum
Internal Links	Relevant WhiteDavid23 technical articles at page end
Structured Data	Article + FAQPage + BreadcrumbList

Important: good SEO/AEO/GEO structure can improve clarity and crawlability, but cannot guarantee indexing speed, rankings or a specific search position.

FAQ

What does CTHP focus on?

The supplied program focuses on cyber range setup, SIEM deployment, detection, Wazuh, incident response, threat hunting and threat intelligence.

What is the practical workflow?

Setup → baseline → controlled activity → telemetry → detection → investigation → remediation → retest.

Why correlate multiple security tools?

Each tool exposes a different evidence layer, helping build a defensible timeline.

What should the final report contain?

Scope, timeline, detection logic, evidence, conclusion, remediation, retest and limitations.