11.5 Hunting Bookmarks and Evidence Collection

Hunting Bookmarks and Evidence Collection

Introduction

Required role: Microsoft Sentinel Reader (minimum for hunting queries). Sentinel Contributor for bookmark and hunt management.

A hunting query returns 50 results. Three of them look suspicious. If you close the browser tab, those three results are gone — you have to re-run the query and re-identify them. Bookmarks solve this: they capture specific query results as persistent evidence that survives beyond the hunting session. Bookmarks are the evidence chain of the hunting process.

Creating bookmarks

From the Logs blade: Run a hunting query. Select one or more result rows. Click “Add bookmark.” The bookmark dialog opens with the selected data pre-populated.

From the Hunting blade: Run a hunting query from the Queries tab. In the results pane, select rows → click “Add bookmark.”

Bookmark fields:

Name — a descriptive title: “Suspicious sign-in from Nigeria IP — j.morrison” not “Bookmark 1.”

Notes — explain why this result is significant: “First-time sign-in from Nigerian IP for this user. Same IP appeared in 3 failed MFA challenges 10 minutes earlier. Possible MFA fatigue followed by session token theft.”

Entity mappings — map entities from the result (Account, IP, Host) for investigation graph integration. If your hunting query output includes UserPrincipalName and IPAddress, map them to Account and IP entities.

Tags — categorise the bookmark: “aitm-hunt,” “insider-threat-hunt,” “ioc-search.” Tags enable filtering and grouping across multiple hunting sessions.

Bookmark best practices for different hunt types

IOC hunts: Create one bookmark per matching IOC. Include the IOC value, the table it was found in, and the timestamp range. Tag all bookmarks with the advisory ID (e.g., “CISA-AA26-001”). This creates a traceable record: “We searched for all IOCs in advisory CISA-AA26-001. Found 3 matches (bookmarked). 47 IOCs not found (documented in hunt record).”

Hypothesis hunts: Create bookmarks for both suspicious and benign-but-notable findings. Suspicious findings may be promoted to incidents. Benign findings inform future hunt query refinement. Tag with the hypothesis ID.

UEBA-driven hunts: Create a bookmark for each entity reviewed with the UEBA investigation priority score, the anomaly types found, and your assessment. This documents the UEBA follow-up for audit purposes.

Bulk bookmark operations

During a productive hunt, you may create 10-20 bookmarks. The Bookmarks tab supports bulk operations.

Bulk promote to incident. Select multiple bookmarks → “Create incident from selected bookmarks.” All selected bookmarks are linked to a single new incident. Use when: multiple findings from the same hunt represent different facets of the same attack (e.g., 5 bookmarks from an IOC hunt, each showing a different user who accessed the same malicious IP).

Bulk tag. Select multiple bookmarks → “Add tag.” Apply a consistent tag across all bookmarks from a hunt session. Use for: post-hunt organisation when you forgot to tag individual bookmarks during the hunt.

Bulk delete. Select bookmarks → “Delete.” Use sparingly — typically only for test bookmarks or duplicates. Bookmarks are lightweight; retaining them costs nothing and preserves the evidence trail.

The bookmark review process

After a hunt produces multiple bookmarks, review them as a batch before taking action.

Step 1: Sort by severity. Review the most suspicious bookmarks first. Are any confirmed threats requiring immediate promotion to incident?

Step 2: Correlate across bookmarks. Do multiple bookmarks share entities (same IP, same user, same time window)? If yes, they likely represent the same attack — promote as a group to one incident.

Step 3: Assess the benign bookmarks. For bookmarks marked as benign: document why they are benign. Can the benign pattern be added as a query exclusion for future hunts?

Step 4: Link to hunt record. Reference all bookmarks in the hunt record’s findings section. The hunt record should list each bookmark with a one-sentence summary of the finding.

Managing bookmarks

Navigate to Sentinel → Hunting → Bookmarks tab. All bookmarks are listed with their creation date, creator, tags, and linked incident (if any).

Bookmark lifecycle:

Created — the bookmark captures a hunting finding. It exists as standalone evidence.

Investigated — the hunter or another analyst reviews the bookmark, runs additional queries, and adds notes documenting the investigation outcome.

Promoted — if the bookmark represents a confirmed or suspected threat, promote it to an incident. Sentinel creates a new incident with the bookmark’s entities and notes as the initial evidence.

Archived — if the bookmark was investigated and determined to be benign, archive it with a note explaining why. Archived bookmarks remain available for reference but are filtered out of the active view.

Promoting bookmarks to incidents

When a hunting finding confirms a threat, promote it to a formal incident for structured investigation and response.

Promotion workflow: Select the bookmark → click “Incident actions” → “Create new incident.” The incident is created with: the bookmark’s entities as the incident entities, the bookmark’s notes as the initial evidence, severity based on the hunter’s assessment, and a link back to the original hunting query.

When to promote vs investigate directly: Promote to an incident when: the finding requires containment actions (password reset, device isolation), the finding affects multiple entities requiring coordinated response, or the finding requires documentation for compliance or reporting. Investigate directly (without promotion) when: the finding is a single suspicious event requiring quick verification (check with the user: “Did you sign in from Nigeria?”), or the finding is informational and does not require a formal response.

Bookmark-enriched investigation patterns

Bookmarks are not just evidence storage — they are investigation accelerators. These patterns show how bookmarks enhance the investigation workflow.

Pattern: Progressive bookmark chain. As you hunt, create bookmarks in chronological order of your discovery. Bookmark 1: “Suspicious sign-in from Nigeria IP at 14:32.” Bookmark 2: “Same user created inbox rule at 14:47.” Bookmark 3: “Inbox rule forwards to external address evil@attacker.com.” Bookmark 4: “12 emails forwarded to attacker between 14:50 and 15:30.” When you promote to an incident, the bookmark chain tells the complete attack story in chronological order — the investigating analyst does not need to re-discover the evidence.

Pattern: Multi-entity bookmark map. During a campaign hunt, create bookmarks for each affected entity. Tag all bookmarks with the campaign identifier. The bookmark collection becomes the blast radius assessment: “Campaign HUNT-2026-03-22: 4 users compromised (bookmarks 1-4), 2 IPs used by attacker (bookmarks 5-6), 1 persistence mechanism found (bookmark 7).” Promote all bookmarks to a single incident for coordinated response.

Pattern: Before-and-after bookmarks. When investigating a potential insider threat, bookmark the baseline behaviour (“Normal: user downloads 5-10 files per day for the last 90 days”) and the anomalous behaviour (“Anomalous: user downloaded 847 files in the last 3 days”). The comparison bookmark makes the deviation immediately visible to anyone reviewing the evidence.

Bookmark analytics

Use KQL to analyse bookmark metadata — understanding hunting programme productivity.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

// Bookmark analytics: hunting productivity
HuntingBookmark
| where TimeGenerated > ago(90d)
| extend Tags = parse_json(Tags)
| summarize
    TotalBookmarks = count(),
    PromotedToIncident = countif(IncidentId != ""),
    UniqueHunters = dcount(CreatedByName),
    UniqueHunts = dcount(tostring(Tags))
    by bin(TimeGenerated, 7d)
| order by TimeGenerated desc

Metrics to track: Bookmarks created per hunt (more bookmarks = more thorough hunting). Promotion rate (bookmarks promoted to incidents ÷ total bookmarks — indicates finding severity). Bookmark age distribution (how long bookmarks sit before being promoted or archived — should be < 7 days).

Bookmark cleanup workflow

Over time, bookmarks accumulate. Monthly, review and clean up.

Review unresolved bookmarks. Filter for bookmarks not linked to any incident and older than 14 days. For each: should it be promoted (it was forgotten), archived (it was investigated and is benign), or deleted (it was a test)?

Archive investigated bookmarks. Bookmarks that were investigated and determined benign should be archived with a note — not deleted. The archive serves as reference: “This pattern was investigated on [date] and determined benign because [reason].” Future hunters encountering the same pattern can check the archive before re-investigating.

Bookmarks in the investigation graph

Bookmarks created during hunting appear in the investigation graph alongside alert entities. When a bookmark is linked to an incident (either by promotion or manual linking), the bookmark’s entities enrich the investigation graph.

This means: a hunter who discovers that the attacker’s IP also accessed a second user’s account creates a bookmark with that evidence. When the incident is investigated, the investigation graph shows both the original alert entities AND the hunter’s discovery — providing a more complete picture of the attack scope.

Evidence collection best practices

Bookmark everything suspicious, not just confirmed threats. A suspicious finding that turns out to be benign is still valuable — it documents what was investigated and ruled out. Future hunters reviewing the bookmark log learn from your analysis: “This pattern looked suspicious but was confirmed benign because [reason].”

Use descriptive names and detailed notes. The bookmark may be reviewed by a different analyst weeks later — during an incident investigation, a post-incident review, or a future hunt. The name and notes must be self-explanatory without running the original query.

Map entities consistently. Use the same entity mapping standard as analytics rules (subsection 10.4): UserPrincipalName → Account, IPAddress → IP, DeviceName → Host. Consistent entity mapping enables cross-reference between hunting bookmarks and analytics rule incidents.

Tag systematically. Use a consistent tagging scheme: the hunt ID (HUNT-2026-0322-001), the hypothesis category (identity, endpoint, network, persistence), and the finding status (suspicious, confirmed, benign). Tags enable filtering the bookmark list to find all findings from a specific hunt or all findings related to a specific attack category.

Building an evidence chain with bookmarks

Bookmarks are not just markers — they are the evidence chain for a hunt. A well-constructed bookmark trail tells the story: what was found, in what order, what led to what, and what the conclusion was.

Bookmark naming convention. Use a consistent format: [Hunt-ID]-[Step]-[Description]. Example: HUNT-2026-04-03-S1-InitialAnomaly, HUNT-2026-04-03-S2-ConfirmedLateralMovement, HUNT-2026-04-03-S3-PersistenceMechanism. The step number shows the investigation progression — a reviewer reading the bookmarks in order sees the analytical narrative.

Context-rich bookmarks. Each bookmark should be self-explanatory without running the original query. Include in the notes: why this result is significant (“This sign-in from IP 203.0.113.47 occurred 2 minutes after the phishing URL click — consistent with AiTM token replay”), what hypothesis it supports or contradicts, and what the recommended next action is (“Investigate non-interactive sign-ins from this IP to determine scope of token usage”).

The baseline bookmark. Before hunting for anomalies, create a bookmark of the baseline: “Baseline: user j.morrison signs in from IPs 192.0.2.10 and 192.0.2.15 exclusively over the past 90 days.” This establishes what normal looks like. When the anomalous bookmark follows (“Anomalous: sign-in from 203.0.113.47 at 08:54”), the deviation is immediately apparent to any reviewer.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

// Create a baseline bookmark query — run this for any user under investigation
// The output establishes "normal" before you hunt for "abnormal"
let InvestigationUser = "j.morrison@northgateeng.com";
SigninLogs
| where TimeGenerated > ago(90d)
| where UserPrincipalName == InvestigationUser
| where ResultType == "0"
| summarize
    TotalSignins = count(),
    UniqueIPs = dcount(IPAddress),
    IPs = make_set(IPAddress, 20),
    UniqueApps = dcount(AppDisplayName),
    Apps = make_set(AppDisplayName, 10),
    UniqueLocations = dcount(tostring(LocationDetails.countryOrRegion)),
    Locations = make_set(tostring(LocationDetails.countryOrRegion), 5),
    FirstSeen = min(TimeGenerated),
    LastSeen = max(TimeGenerated)

Bookmark this result as “HUNT-[ID]-S0-Baseline.” It is the reference point for every subsequent finding.

Cross-hunt bookmark correlation

Over time, bookmarks from different hunts may reveal connections that individual hunts missed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

// Cross-hunt correlation: find IPs that appear in bookmarks from multiple hunts
HuntingBookmark
| where TimeGenerated > ago(180d)
| extend Entities = parse_json(tostring(EntityMapping))
| mv-expand Entities
| where tostring(Entities.entityType) == "IP"
| extend IPAddress = tostring(Entities.fieldMappings[0].value)
| summarize
    HuntCount = dcount(tostring(Tags)),
    Hunts = make_set(tostring(Tags), 10),
    BookmarkCount = count()
    by IPAddress
| where HuntCount > 1
| order by HuntCount desc

If an IP appears in bookmarks from 3 different hunts: it is recurring attacker infrastructure. This cross-hunt visibility — impossible without systematic bookmarking — identifies persistent threats that operate below the threshold of any single detection rule.

Link bookmarks to incidents. If a bookmark is relevant to an existing incident (the hunt was triggered by an incident and discovered additional evidence), link the bookmark to that incident rather than creating a new one. Navigate to the bookmark → “Incident actions” → “Add to existing incident.”

1
2
3
4
5
6
7

// Review all hunting bookmarks from the last 30 days
HuntingBookmark
| where TimeGenerated > ago(30d)
| project TimeGenerated, BookmarkName = DisplayName,
    CreatedBy = CreatedByName, Tags,
    Notes, QueryText
| order by TimeGenerated desc

Knowledge check