Per-Hunt Custom Finding Tags

Overview

When running multiple Hannibal hunts concurrently or sequentially, findings from different engagements can be difficult to distinguish. The per-hunt custom tag feature lets you attach a single free-form tag at launch time. Every finding the hunt produces carries that tag automatically, making it straightforward to filter, track, and report on results from a specific engagement.

Setting a Custom Tag When Launching a Hunt

The custom tag is configured in the Hannibal launch wizard before the hunt starts.

1. Open the Hannibal module and begin a new hunt launch.
2. Progress through the wizard to the Finish criteria & duration step.
3. Locate the optional Custom Tag field and enter your desired tag value (for example, Q4_Application_Hunt).
4. Complete the remaining wizard steps and launch the hunt.

The tag value is saved with the hunt record and requires no further action after launch.

Note: The Custom Tag field is optional. If left blank, findings are tagged with the built-in hunt and agent-reported tags only.

How Tags Are Applied to Findings

Once the hunt is running, the platform propagates the custom tag automatically:

• The tag is stored on the Hunt model alongside the hunt's other metadata.
• Every finding the hunt files receives the custom tag in addition to the standard built-in tags (hunt and agent-reported).
• No manual tagging or post-processing is required.

Filtering and Reporting on Tagged Findings

Tagged findings can be located using the existing tag-based query controls in the Assets and Risks views.

1. Navigate to Assets or Risks.
2. Use the tag filter to enter or select your custom tag value.
3. The view updates to show only findings that carry that tag.

This allows you to scope reports and triage workflows to a single hunt engagement without affecting visibility into other hunts or finding sources.

Considerations

• A custom tag must be set before the hunt launches; it cannot be added or changed after the hunt has started.
• Tag values are case-sensitive. Use a consistent naming convention (for example, Q4_Application_Hunt) to ensure filters work reliably across users and reports.
• The custom tag appears alongside, not instead of, the built-in hunt and agent-reported tags.

---

Viewing Findings in the Hunt Drawer

Opening the hunt drawer for an active or completed Hannibal hunt displays all findings associated with that hunt, regardless of their lifecycle state.

Finding Visibility and Sort Order

The drawer lists findings across all lifecycle states — Demonstrated, Detected, and any other statuses — without requiring manual filter changes. Findings are sorted by criticality, with the most severe items appearing first. Within each severity tier, the most recently discovered finding ranks highest.

This means a hunt that has produced findings but has not yet reached the Demonstrated state will still show its results in the drawer. The previous behavior — which defaulted to showing only Demonstrated findings — caused hunts with no compromises yet to appear empty, which is no longer the case.

Considerations

• No filter changes are needed to see findings at earlier lifecycle stages; all states are visible by default.
• The criticality sort order is applied automatically and cannot be changed within the drawer itself.
• Findings remain accessible in the Risks view for more advanced filtering and reporting.

---

Viewing an Attack Graph from a Finding

When a Hannibal hunt places a finding inside an attack graph, the Exploitation tab on that finding's detail view renders the associated attack graph directly. This lets you see where the finding sits within the broader attack chain without navigating away from the finding.

How It Works

• Open any finding that was produced by a hunt with an associated attack graph.
• Select the Exploitation tab on the finding detail view.
• The attack graph loads automatically. The camera fits the entire kill chain into the drawer pane and centers on the finding's own vulnerability node, so its position in the chain is immediately clear without any manual panning or zooming.

If no attack graph is associated with the finding, the existing Not yet exploited placeholder is shown instead. Empty or incomplete graphs do not suppress this placeholder.

Graph Layout and Camera Behavior

When the Exploitation tab opens, the graph camera behaves as follows:

• Full path in view — all nodes in the attack graph, including those at the far end of multi-hop paths, are included in the initial layout fit. No nodes are clipped off-screen on load.
• Centered on the vulnerability node — the camera opens centered on the vulnerability node for the finding you are viewing, rather than on the attacker origin.
• Consistent zoom level — padding is applied around the fitted graph so that the surrounding attack-path neighborhood remains visible at a legible zoom level.

Switching Between Multiple Attack Graphs

A single finding can appear in more than one attack graph (for example, when multiple hunts reference the same vulnerability). In that case, a switcher control appears above the graph. Each entry in the switcher displays the parsed hunt title; hovering over an entry shows the full name in a tooltip. Select an entry to load the corresponding graph.

Considerations

• The attack graph is only available on the Exploitation tab when the finding has been placed in a graph by a hunt. Manually filed findings without a hunt association will show the Not yet exploited placeholder.
• The highlighted vulnerability node corresponds to the specific finding you are viewing; other nodes in the graph represent related steps in the attack chain and are not directly linked to this finding's detail view.