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.

4–7 hours core Guided intermediate Evidence required

Start building

Self-hosted · Several hours

TheHive Full Lab

Installation or working instance required

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.

Before you begin

You need: an isolated Ubuntu VM, a recovery point, administrator access, and enough resources for TheHive and its supporting services. For the build route, you should be comfortable using sudo, editing configuration files, checking systemd services, transferring files, and working with IP addresses and ports.

How to use this lab

Complete one session at a time. Stop when a checkpoint fails and fix that boundary before continuing. Interface names can differ between TheHive releases; use the equivalent case, observable, task, and alert views in your supported version.

Recommended first

Case Workflow Lab

Use an existing isolated TheHive instance, or complete Activity 1 once. Then investigate the supplied evidence, document a controlled response, and close the case.

Expected time: 2–3 hours after the platform is working.

Build extension

Build from Scratch

Prepare and validate a supported TheHive stack before completing the case workflow. Installation and troubleshooting may require a separate session.

Expected time: 2–4 hours, excluding unexpected troubleshooting.

1. Session 1Build and snapshot
2. Session 2Investigate and respond
3. Session 3Close and improve

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 TheHive instance and a snapshot or other recovery point. If you are completing the build route, you also need:

• one connected preparation host for the offline package;
• a component combination checked against current vendor requirements.

01

Activity 1: Build the environment

Use this activity only when you need to build the platform. Keep this page open and return after each linked checkpoint.

1. The build is recordedRecord the Ubuntu version, CPU, memory, storage, network, and planned snapshot name.
2. The component combination is supportedReview the recorded lab versions and current vendor compatibility guidance. Do not install the recorded demonstration combination when it falls outside the supported matrix.
3. The services are healthyFollow the installation journey. Confirm Cassandra, Elasticsearch, and TheHive pass their individual checkpoints before continuing.
4. Access is securedReplace default access, create a named analyst account, sign in with it, and record the roles granted.
5. The baseline is recoverableCreate a clean snapshot named thehive-working-baseline and record how to restore it.

Compatibility gate

The versions recorded in the original demonstration are not a recommended new-build combination according to the warning in the installation guide. Continue only with a combination that you have checked against current vendor requirements. If you cannot establish one, use an existing authorised lab or complete the browser exercise instead.

Milestone 1Working baselineThe named analyst can sign in, all required services are healthy, default access is replaced, and the VM can be restored.

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 fictional evidence set throughout the activity. Treat each record as supplied evidence; do not invent additional facts to make the conclusion stronger.

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
Exercise time	09:14–09:18 in your recorded lab time zone

Open the synthetic evidence pack

Time	Source	Record
09:14–09:17	Authentication log	Six failed interactive sign-ins for svc-backup from 198.51.100.24.
09:18	Authentication log	One successful interactive sign-in for the same account and source.
09:20	Asset inventory	FIN-WS01 is a finance workstation; it is business-sensitive but not an enterprise-wide critical service.
09:24	Identity register	svc-backup is privileged. Its owner did not expect an interactive sign-in.
09:32	Endpoint review	No endpoint telemetry is available in this exercise. Credential theft and endpoint execution remain unproven.
09:40	Approval record	Identity Services Lead approves a credential reset and revocation of active sessions.
09:55	Validation log	No further sign-ins are observed for 15 minutes after session revocation.

Save or capture this table with the case record so another learner can trace each conclusion to its source.

Intake and create the case

Choose the route that matches your lab:

• Route A — integrated alert: Open the supplied synthetic alert, select Create case from alert, and later confirm the source alert appears under Linked alerts.
• Route B — direct case: If no authorised integration exists, create a case directly. Record Direct case — no alert integration in this lab in the case description. The analyst interface does not manually create incoming alerts.

Then complete the common steps:

1. Title the case Suspicious privileged-account activity and assign it to your named analyst.
2. Set severity to High, TLP to Amber, and PAP to Amber. Amber limits sharing and automated actions while the evidence is still being assessed. Add the tags identity, privileged-account, and training.
3. Record this rationale: A privileged identity had six failures followed by a success from one source; compromise is not yet proven.

Navigation hint: open Alerts for Route A, or Cases → New case for Route B. In releases with different labels, use the equivalent create-case action.

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 to the named analyst and set a due date within the exercise session. Complete account validation only after adding the supplied task log Owner did not expect an interactive login.
9. In the case description, a task log, or the timeline feature available in your version, create two labelled entries: Recorded facts and Working hypothesis. Use Credentials may have been misused only as the hypothesis.

Navigation hint: open the case, then use Observables to add typed evidence and Tasks to create, assign, log, and complete the investigation work.

Make the analyst decision

Before opening the response steps, record your decision and one-sentence rationale:

• Contain with approval because a privileged account shows an unexpected successful sign-in; or
• Continue monitoring because compromise is not proven.

Compare your choice with the supplied approval record. The recommended path is controlled containment with approval: the account is privileged and the owner did not expect the activity, while the absence of endpoint telemetry limits the conclusion.

Respond, validate, and close

1. Record the supplied 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 supplied validation 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.

Milestone 2Case defensibleAnother analyst can trace the priority, observables, tasks, response decision, and bounded conclusion back to the supplied records.

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

03

Activity 3: Extend and validate

Recommended beginner extension: test a comparison case

Create a second case named Expected service-account failures with three failed sign-ins, no successful sign-in, a standard test asset, and confirmation that the activity came from an approved maintenance test.

1. Set a lower severity than the first case and explain which evidence changed the response.
2. Reuse the relevant investigation tasks, but do not record containment approval or session revocation.
3. Close the comparison case as expected authorised activity.
4. Confirm the original scenario still follows the controlled-containment path.
5. Record how to remove the comparison case and any reusable objects you created.

The original case is the positive test; the approved maintenance case is the non-escalation test.

Optional advanced extensions

After the comparison test works, either create a reusable case template containing the investigation task groups or add a custom field for the approval and recovery condition. Test the change on a disposable case, record its purpose, and document how to undo it.

Milestone 3Decision testedYour positive and non-escalation cases show that the workflow responds to evidence rather than treating every authentication failure as an incident.

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.

• VM specification, network plan, component versions, service health, and recovery snapshot.
• Named analyst account, assigned roles, and confirmation that default access was replaced.
• Selected intake route, owner, severity, tags, TLP/PAP, linked-alert or direct-case status, and initial rationale.
• Typed username, IP, and hostname observables with sharing controls and descriptions.
• Grouped mandatory tasks, assignees, due states, and recorded task logs.
• Containment decision, approver, action owner, recovery path, and validation result.
• Bounded conclusion, exported case summary, detection improvement, and process improvement.
• Original positive case, non-escalation comparison case, different response rationale, and removal instructions.

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

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