Alert, Flow, and PCAP Pivoting

This runbook is a meta-reference on the pivot patterns every family-specific runbook depends on. It does not describe a triage scenario of its own; it describes the motion an analyst performs when they move from one Hunt tab to another in pursuit of evidence. Every other runbook in this chapter refers back to this one for the mechanics of a named pivot, so the individual steps do not have to re-explain how right-click menus, new tabs, and filtered views combine.

This runbook is written for Tier 1, 2, and 3 Security Operations Center (SOC) analysts, threat hunters, Managed Security Service Provider (MSSP) analysts, and incident responders. It assumes a working familiarity with the Hunt Page surface — buckets, tabs, the detail sidebar, and the advanced-search query builder.

First-use acronym expansions in this runbook: SOC (Security Operations Center), MSSP (Managed Security Service Provider), MVP (Minimum Viable Product), IOC (Indicator of Compromise), IP (Internet Protocol), DNS (Domain Name System), HTTP (Hypertext Transfer Protocol), TLS (Transport Layer Security), SNI (Server Name Indication), SSH (Secure Shell), SMB (Server Message Block), RDP (Remote Desktop Protocol), SMTP (Simple Mail Transfer Protocol), FTP (File Transfer Protocol), QUIC (Quick User Datagram Protocol Internet Connection), MDCore (MetaDefender Core), PCAP (packet capture), PII (personally identifiable information), PHI (protected health information), CSV (Comma-Separated Values), JSON (JavaScript Object Notation).

When to Use This Runbook

Analysts reach this runbook in two situations:

From another runbook. Every family-specific runbook — Critical Alert Triage, C2 Beacon Investigation Data Exfiltration Investigation, Malicious File Investigation, ML Anomaly Investigation, Tunneling Investigation — directs the analyst here when a step refers to a pivot by name and the analyst wants the mechanics in full.
As a self-training reference. New analysts read the runbook end-to-end to build a mental map of the pivots available on the Hunt Page before they encounter their first Critical alert.

The runbook is structured around the four named pivot motions — alert → flow, flow → session, session → PCAP, and value → hunt — followed by a short etiquette section on how to manage the tab workspace across a long investigation.

Pivot Taxonomy

Every pivot on the Hunt page shares three properties. Recognizing the shape of a pivot before performing it is the fastest way to read a runbook step.

Trigger. The analyst right-clicks either a cell in the results table or a field in the detail sidebar. Both surfaces expose the same context menu; the sidebar is the more common trigger in practice because the analyst is already reading the row's enrichment blocks when the pivot opportunity appears.
Action. The menu entry names the pivot — Hunt all events from this IP, Show all events with this community id, Show related events, Show related files, Search file hash across all events, or Copy to clipboard. Each action carries a fixed filter template that MetaDefender NDR applies in the new tab.
Result. A new tab opens on the appropriate bucket (All Events, Netflows, or Files), pre-filtered to the pivoted value, with the originating tab's time range preserved. The originating tab is never closed or modified by a pivot — the analyst can always return to the lead.

Pivots are cheap. A pivot is a right-click and a tab-switch, not a query the analyst has to compose. Runbooks assume the analyst performs multiple pivots per alert and recommends pivoting even when the answer looks obvious because corroborating evidence is what separates a defensible disposition from a guess.

Alert → Flow Pivot

The alert → flow pivot answers the question what is the shape of the connection this alert lives on? It is the most frequent pivot in first-response triage and anchors every family-specific runbook's early steps.

Motion

The analyst opens the alert row on an All Alerts tab or on any per-family sub-tab (Suricata Alert, C2 Infrastructure Alert, InSights Alert, MDCore Alert, Beaconing Detection, Data Exfiltration Detection, DNS Tunneling Detection, ML Random Cut Forest Anomaly, and so on).
The analyst right-clicks the community_id column in the row — or the equivalent community_id field in the sidebar header — and selects Show all events with this community id.
A new All Events tab opens, pre-filtered to every event carrying the same community_id: the original alert, the Flow record, every protocol session (DNS, HTTP, TLS, SSH, SMB, RDP, SMTP, FTP, QUIC, FileInfo), any additional alerts raised on the same connection, and every enrichment attached to any of them. The originating tab remains open for re-entry.

The community_id is the 5-tuple correlator that stitches every event belonging to the same connection into a single view. It is more reliable than pivoting on the source-and-destination pair directly because the correlator accounts for the protocol, ports, and direction — two distinct flows between the same hosts do not merge.

What to Examine

On the new All Events tab the analyst scans:

The Flow record. Packets to-server and to-client, bytes to-server and to-client, flow start and end, age, state, termination reason, alerted flag, transaction count, and exception policy. These fields describe the connection's shape: a short-duration flow with balanced bytes is a single request-response; a long-duration flow with one-sided upload volume is a streaming transfer; an abnormally terminated flow with a low packet count is a reset or a half-open connection.
Related alerts on the same connection. A single-family alert is a weaker hypothesis than a multi-family cluster. The analyst counts corroborating alerts: a Beaconing Detection co-occurring with a C2 Enrichment and a Suricata signature is three independent signals on one connection.
Session records. One row per protocol transaction the parser emitted during the flow. Their presence tells the analyst which protocols rode the connection and which are worth pivoting into next.

When It Is Enough

The alert → flow pivot is enough when the Flow record and the co-occurring alerts answer the open question by themselves — for example, when a Beaconing Detection's connection count is corroborated by the Flow record's packet cadence and no session-level detail is required.

The pivot is not enough when the question is about what was on the wire rather than how the connection looked. Questions about DNS query names, TLS SNI, HTTP URLs, file contents, or SMTP recipients require the next pivot.

Flow → Session Pivot

The flow → session pivot answers the question what protocol-level evidence lives on this connection? It is the natural follow-on when the Flow record and the alert row raise a question the session records can answer.

Motion

From a Flow row — or from the All Events tab opened by the previous pivot — the analyst right-clicks the community_id and selects Show related events. The same action is available on the row or in the sidebar header.
MetaDefender NDR opens a new All Events tab scoped to the same community_id. The analyst then narrows to the relevant protocol by selecting the per-protocol sub-tab on the Network Sessions bucket: DNS, HTTP, TLS, SSH, SMB, RDP, SMTP, FTP, QUIC, or FileInfo. Each sub-tab applies the column projection documented in the Hunt Page chapter.
The analyst selects each session row in turn and reads the sidebar's protocol-specific section (Suricata DNS, Suricata HTTP, Suricata TLS, SSH detail, SMB detail, RDP detail, SMTP detail, FTP detail, Suricata QUIC, Suricata FileInfo).

What Each Protocol Reveals

Different protocols answer different questions on the same connection.

Protocol	What the session reveals
DNS	Query name, record type, response code, answer data, Time-To-Live (TTL). Answers what name was resolved, whether the resolution succeeded, what Internet Protocol (IP) addresses were returned, and in DNS-tunneling scrutiny what the labels look like.
HTTP	Hostname, Uniform Resource Locator (URL), method, status, user agent, referer, content type, response length. Answers what URL was requested, what the client identified itself as, what content came back, and whether the exchange looks consistent with the declared purpose.
TLS	Version, SNI, certificate subject and issuer, validity window, JA3 / JA3S / JA4 fingerprints, cipher, session-resumption flag. Answers what name the client requested (often the only visible identity inside an encrypted session), who issued the certificate, and whether the client's TLS fingerprint matches known tooling.
SSH	Protocol version, client and server software, HASSH client and server fingerprints, key-exchange and cipher algorithms. Answers what client connected, what the server identified as, and whether the fingerprint pair matches known tooling.
SMB	Command, share, filename, access flags, status. Answers what file was read or written, on which share, and whether the action succeeded.
RDP	Client name, client build, cookie, version, certificate subject and issuer. Answers which client connected and which target was presented.
SMTP	Mail-from, recipients, HELO, attachment filenames, reply codes. Answers who the mail was from and to, what attachments rode it, and whether the server accepted delivery.
FTP	Command, command data, reply code. Answers what commands the client issued and what file names crossed the control channel.
QUIC	Version, SNI, JA3 / JA4 fingerprints, Application-Layer Protocol Negotiation (ALPN). Answers the encrypted-session questions the TLS sub-tab answers for Transmission Control Protocol traffic.
FileInfo	Filename, magic string, Secure Hash Algorithm 256-bit (SHA-256), Message Digest 5 (MD5), size, state (`CLOSED` when eligible for MDCore enrichment), stored flag. Answers what files the sensor extracted from the connection and which of them were scanned by MD Core.

The analyst rarely reads every sub-tab. The runbook step directs which protocol matters: a DNS-family alert directs to the DNS sub-tab, a file-scan alert directs to FileInfo, a data-exfiltration question about upload content directs to HTTP or TLS.

Session → File Sub-Pivot

When a session row carries file metadata and the question is about the file itself, the analyst extends the pivot with a right-click on the row and selects Show related files. A new Files tab opens filtered to files extracted from the same flow. Each file row carries the MDCore scan verdict when enrichment has run. The analyst reads the row's sidebar (Suricata FileInfo plus the MDCore Enrichment section) before deciding whether to pull the file from archival storage for deeper analysis.

When It Is Enough

The flow → session pivot is enough when the protocol-level evidence answers the open question — the DNS query name matches or does not match a known indicator, the TLS SNI identifies the destination by name, the SMTP recipient list names the target user. The pivot is not enough when the question is about bytes the session parser did not surface as structured fields — encrypted payload bodies, binary command-channel fragments, or protocol-parser edge cases that emitted no session row. Those cases require the PCAP pivot.

Session → PCAP Pivot

The session → PCAP pivot is the last resort. It answers the question what were the actual bytes on the wire? when the alert, the flow record, and the session metadata together do not resolve the question. PCAP inspection is slower, more expensive, and more constrained than any other pivot, so the runbook calls it out explicitly rather than implying it.

PCAP Availability Is Selective

MetaDefender NDR does not retain a packet capture for every flow. PCAP retention is configuration-dependent: the sensor captures selectively based on policy (alert-triggered capture, rolling windows, or tagged hosts), and retention is bounded by on-sensor storage capacity. An analyst requesting the PCAP for a flow may discover that no capture exists, and the runbook accepts that as a valid outcome of the pivot.

The rule is: flows and protocol logs first, PCAP only when they cannot answer the question. Treating PCAP as the default pivot fills sensor storage fast, slows the investigation, and buries the question in packet-level detail the analyst does not need for most dispositions.

Motion

The analyst confirms the open question is not answerable from the session sub-tab alone. Typical cases: the session row is absent (a protocol parser did not emit one), the session row is present but the relevant field is the payload body (an encrypted TLS application record, an HTTP request body parser-truncated by size), or a suspected protocol anomaly occurs between sessions (an unexpected reset, a malformed handshake).
The analyst records the exact flow identity: the community_id, the source and destination 5-tuple, the flow start and end timestamps from the Flow record, and any alert identifier the PCAP request should cite.
The analyst follows the SOC's PCAP-request workflow to retrieve a capture slice for the recorded time window, restricting the window to the minimum necessary — a two-hour slice for a ten-minute flow wastes sensor storage and slows the retrieval. On-demand PCAP capability and the exact retrieval interface are covered in the Sensor Management administration chapter; runbook scope stops at request the PCAP because the retrieval surface is an administrative concern.
The analyst opens the retrieved PCAP in the SOC's standard packet analysis tool and inspects the payload for the specific question the session metadata could not answer.

PCAP Handling Discipline

PCAPs carry more than the question under investigation. They carry everything the sensor saw on the wire during the capture window — including any PII, PHI, authentication material, or unrelated traffic. The analyst follows the SOC's data-handling and redaction procedures for the captured file, keeps the PCAP out of shared systems that are not authorized for full-traffic data, and disposes of the file on completion. Runbook dispositions refer to specific findings from the PCAP (for example, "HTTP POST body at offset 0x1234 contains Base64-encoded credential dump"), not to the PCAP file itself.

When the Pivot Fails

If the PCAP is unavailable for the requested window (sensor capacity exhausted, capture disabled on the affected segment, retention expired), the pivot returns no result. The correct response is not to escalate harder — it is to widen the session-metadata search (longer time window, adjacent connections from the same source, related flows with the same destination) and to document the PCAP gap on the ticket so future tuning of the capture policy has the evidence to justify the change.

Value → Hunt Pivot

The value → hunt pivot is the simplest of the four and the one analysts use most casually. It answers the question where else has this value appeared?

Motion

The analyst right-clicks any value — an IP, a domain, a SHA-256 or MD5 hash, a community_id, a signature message, a user agent, a TLS fingerprint — either in a table cell or in the sidebar's protocol-specific or enrichment section.
The context menu exposes the pivot actions appropriate to the value's type. The catalog is the same on every tab, because the context menu is driven by the value rather than by the tab's bucket.

Menu Action	Scope	Result
Copy to clipboard	Any value	The value is placed on the system clipboard. Used constantly to paste into advanced search, to carry across to external lookup tools, or to paste into the ticket evidence record.
Hunt all events from this IP	Any IP-valued cell (source or destination)	A new All Events tab opens filtered to rows where the IP appears in either 5-tuple position. The originating tab's time range carries over.
Show related events	Any row	A new All Events tab opens filtered to the row's `community_id`. Equivalent to the flow → session pivot when used on a Flow or session row.
Show all events with this community id	Any row with a `community_id`	A new All Events tab opens on that `community_id`. This is the alert → flow pivot when used from an alert row.
Show related files	Any row with a flow or session context	A new Files tab opens filtered to files extracted from the same flow.
Search file hash across all events	Any SHA-256 or MD5 cell	A new All Events tab opens on every event referencing the hash — the upstream HTTP download, the SMB write or SMTP delivery that carried it, the downstream MDCore scan result, and any alert the hash fired.

Time Range Is Load-Bearing

Every value → hunt pivot inherits the originating tab's time range. When the analyst widens the time range on the originating tab before pivoting, the pivoted tab inherits the wider window — useful for checking whether an indicator has a multi-day or multi-week history. When the analyst pivots from a narrow window (for example, Last 15 minutes on a real-time tab), the pivoted tab is also narrow and may miss prior occurrences. Runbook steps that direct the analyst to check a seven-day window for a repetition pattern specify the window explicitly because of this inheritance.

Advanced-Search Alternative

When the pivot target is a value the context menu does not name explicitly (for example, a Suricata Signature Identifier, a Behavioral Detection's destination Autonomous System Number, or an ML Random Cut Forest anomaly score threshold), the analyst composes the query manually in the advanced-search builder. The mechanics are documented in Hunt page — Search and filtering. The result is the same shape as a context-menu pivot — a new tab opens scoped to the value — but the filter is assembled by hand.

Pivoting Etiquette

Pivot-driven investigations produce many tabs quickly. Tab hygiene keeps the workspace useful rather than overwhelming.

Open tabs purposefully. A pivot that does not answer a specific open question is clutter. The analyst asks what question does this pivot answer? before performing it, and closes the resulting tab if the question turns out to be already answered elsewhere.
Keep the lead tab open. The originating alert tab is the return address for the investigation. Analysts do not close it until the disposition is recorded.
Close stale pivot tabs. A pivot tab that has served its purpose — the repetition check returned no prior occurrences, the community-id view confirmed a single-signal alert — is closed immediately. The workspace carries one to five active investigation tabs on a typical triage, not twenty.
Name tabs implicitly through ordering. Tabs can be reordered by drag. Analysts group related pivots together (for example, All Alerts → alert's community_id → alert's source IP) so the chain reads left to right.
Export, do not screenshot, when the evidence must leave the Hunt page. The CSV and JSON export on the tab action menu produces a machine-readable artifact the ticket can cite. Screenshots are a last resort for evidence that cannot be expressed as a row set.
Rely on persistence for long investigations. Every tab — its bucket and detection type, time range, search expression, column customization, sort, and pagination — persists across sign-out and sign-in. An investigation that spans a shift change resumes in the incoming analyst's workspace exactly where the outgoing analyst left off. The lead tab and the pivot chain survive a browser restart, a session expiry, and a sign-in from a different machine.
Row selection does not persist. The detail sidebar's open state and the selected-row highlight reset at sign-in. Analysts who need to return to a specific row bookmark it by leaving the tab filtered to that row — for example, by pasting the row's community_id into the tab's quick-search — rather than by relying on the selection itself.

Investigations that outrun the workspace's useful tab count indicate a structural problem, not a discipline problem. When an analyst finds they are managing more than ten active tabs, the right response is to reshape the investigation into a smaller number of broader queries rather than to continue pivoting; the family-specific runbook at that point typically directs escalation to Tier 2 or Tier 3.