Skip to content

TheHive Hands-on Labs

Choose the Interactive Lab for a short browser-based case exercise with no setup, or the Full Lab to deploy TheHive and complete the same workflow in an isolated environment.

Hands-on incident response lab

Deploy it. Investigate it. Improve it.

Start with an isolated Ubuntu VM, validate the supporting services, reproduce an audit-ready response case, and make one controlled improvement another analyst can test.

⏱ 3–5 hours ◆ Intermediate ✓ Evidence required
Start building
Self-hosted · Several hours

TheHive Full Lab

Intermediate · 3–5 hours

Already have a working TheHive lab?

Confirm the instance is isolated, default access has been replaced, and a recovery point exists. You can then skip Activity 1 and begin with Activity 2.

Synthetic evidence only

Use the reserved example addresses and fictional identities below. Do not connect the exercise to production alerts, accounts, endpoints, or response actions.

Objective

Deploy a recoverable TheHive lab, reproduce a case from alert intake through closure, and make one controlled improvement another analyst can validate.

A minimum environment consists of:

  • one isolated Ubuntu VM for TheHive and its supporting services;
  • one connected preparation host for the offline package;
  • a snapshot or other recovery point; and
  • a component combination checked against current vendor requirements.

01

Activity 1: Build the environment

  1. Record the Ubuntu version, CPU, memory, storage, network, and planned snapshot name.
  2. Review the versions used in the lab and current compatibility guidance.
  3. Follow the installation journey, adapting addresses consistently where required.
  4. Confirm Cassandra, Elasticsearch, and TheHive pass their documented checkpoints.
  5. Replace default access, create a named analyst account, and record the roles granted.
  6. Create a clean snapshot named thehive-working-baseline.

Expected result TheHive opens in the isolated lab, its supporting services are healthy, default access is replaced, and a recovery point exists.

02

Activity 2: Reproduce the case workflow

Use this synthetic alert throughout the activity:

Field Training value
Alert title Suspicious privileged-account activity
Source system Training SIEM
User svc-backup
Source address 198.51.100.24
Asset FIN-WS01
Pattern Six failures followed by one success
Time 2026-08-12 09:14–09:18 NZST

Intake and create the case

  1. If your lab already receives synthetic alerts from an authorised integration, open the supplied alert. Otherwise, create the case directly—the analyst interface does not manually create incoming alerts.
  2. Title the case Suspicious privileged-account activity and assign it to your named analyst.
  3. Set severity to High, TLP to Amber, and PAP to Amber. Add the tags identity, privileged-account, and training.
  4. Record this rationale: A privileged identity had six failures followed by a success from one source; compromise is not yet proven.
  5. If you started from an alert, use Create case from alert and confirm it appears in the case’s Linked alerts tab.

Add observables and investigation tasks

  1. In the Observables tab, add svc-backup as type username, 198.51.100.24 as type ip, and FIN-WS01 as type hostname.
  2. Set observable TLP/PAP to Amber, add the training tag, and record why each value matters. Do not mark an observable as a confirmed IOC unless your synthetic evidence supports that conclusion.
  3. In the Tasks tab, create these task groups and mandatory tasks:
  4. Identity: Validate the account owner.
  5. Authentication: Review authentication history.
  6. Endpoint: Preserve endpoint evidence.
  7. Impact: Confirm business impact.
  8. Assign every task and give it a due state. Complete account validation only after adding the fictional task log Owner did not expect an interactive login.
  9. Add a case timeline entry that separates the recorded facts from the hypothesis Credentials may have been misused.

Respond, validate, and close

  1. Record fictional approval from Identity Services Lead to reset svc-backup and revoke its active sessions.
  2. Document the expected effect, action owner, recovery path, and validation check.
  3. Add the synthetic result No further sign-ins observed for 15 minutes after session revocation.
  4. Complete every mandatory task and its required task log before closing the case.
  5. Close with the bounded conclusion Suspicious activity was contained; credential theft was not proven.
  6. Add one detection improvement and one response-process improvement to lessons learned.
  7. Export or capture the case summary for the evidence checklist.

Expected result The installed platform contains an audit-ready synthetic case with linked intake, typed observables, assigned tasks, approval, validation, and a bounded closure another analyst can reproduce.

03

Activity 3: Extend and validate

Choose one controlled improvement:

  • create a reusable case template containing the investigation task groups;
  • add a custom field that records the approval or recovery condition; or
  • process a second synthetic alert with a different severity and explain why its response differs.

Validate the improvement with one positive example and one example that should not be escalated. Record what changed, how you tested it, and how to undo it.

Expected result Another analyst can reuse the improvement, understand its purpose, and verify both the positive and comparison results.

Full Lab evidence checklist

This checklist applies to the VM-based Full Lab. If you completed the Interactive Lab, retain its downloaded evidence summary instead.

0 of 8 recorded Mark each item after saving the evidence.

Clean up

Export the evidence summary and case record you intend to keep. Remove synthetic cases and temporary accounts, stop test activity, and revert the disposable VM if appropriate. Keep only sanitised screenshots, notes, templates, and conclusions as the lab record.

PreviousInstall TheHive NextReturn to overview