One detection, multiple endpoints: IntelStream fleet-wide IOC hunting

The challenge

A detection on one endpoint is often the first visible trace of a wider intrusion. The same file, hash, domain, IP address or URL may already exist on other systems, but checking each endpoint separately creates delay and inconsistent results. Analysts need a way to test the IOC across the fleet, compare when and where it appeared, and decide which systems require immediate attention.

The investigation question

This use case follows an illustrative alert for a suspicious executable found on a finance workstation. The initial detection is important, but the operational question is broader:

1. Is the IOC present on other endpoints?
2. What are the first and most recent observations?
3. Which endpoints, paths and available user contexts are associated with it?
4. How many endpoints may be affected?
5. Is this an isolated event or a fleet-wide pattern?
6. Which systems should be investigated or contained first?

Demonstration note: The endpoint name, path, hash, domain and timestamps in this scenario are placeholders. Replace them with approved demonstration data or redact them before publication.

Example alert

Initial endpoint: FINANCE-PC-07
File: C:\Users\demo\AppData\Local\Temp\invoice_update.exe
SHA-256: <demonstration hash>
Related domain: update-check.example
Initial result: High-severity detection

The analyst does not assume that the first endpoint is the only affected system. The initial hash becomes the pivot for a wider search, followed by related filename, path and network indicators where appropriate.

Why IntelStream is the right first pivot

IntelStream is Defensium’s threat-intelligence and IOC hunting engine. It is designed for centralised questions before full forensic collection: whether an indicator is present in the selected scan sources, which endpoints return a match and which systems deserve a deeper look. Supported pivots include file hashes, IP addresses, domains and URLs; filename and path-based searches depend on the selected evidence source and deployment configuration.

This separation is operationally important. IntelStream centrally orchestrates targeted IOC scans across the authorised endpoint scope. Analysts can begin with a specific indicator and reserve broader or deeper analysis for endpoints returning relevant matches. That architecture keeps the first answer focused and prevents broad evidence collection from becoming the default response to every alert.

The Defensium workflow

Fleet-wide hunting is designed to answer a focused question without turning every investigation into an uncontrolled broad scan. IntelStream provides the IOC search layer for supported indicators and selected evidence sources. Analysts can begin with a precise search, narrow the endpoint scope, apply an available time window and launch deeper collection only where the evidence justifies it. This helps keep the initial decision focused and avoids unnecessary endpoint load.

1. Start with the strongest available IOC

Begin with the SHA-256 when a reliable hash is available. Hash search provides a precise pivot for known files and helps reduce noise. If the file is unavailable or the hash is not yet trusted, continue with the indicator types supported by the selected scan source and treat filename, path or network-content matches as leads requiring validation.

2. Search across the endpoint fleet

Run the IOC search with the IntelStream engine against the authorised endpoint scope. IntelStream centrally orchestrates the targeted scan and returns the result to the Defensium console, while the analyst retains control over endpoint scope and any available time window. Review matching endpoints, the indicator type, match source, rule or evidence reference and the scan timestamp. Keep the search scope explicit so the result can be reproduced later.

Performance note: A targeted IOC search followed by scoped verification can reduce unnecessary work compared with broad collection. Resource-aware scan controls, time windows and endpoint selection allow deeper scans to be reserved for systems that need them. Exact duration and throughput depend on indicator type, evidence scope, endpoint state and environment, so public material should avoid a universal scan-time promise.

3. Compare first and last observations

A single match and repeated observations mean different things. Compare the earliest available matching scan and the latest available matching scan, then group results by endpoint, path and indicator. Do not describe these as first-seen or last-seen telemetry unless the deployment maintains a historical IOC index.

4. Enrich the match with endpoint context

For each relevant match, review the endpoint status, related threat instances, file metadata and existing scan history. A hash match on an offline endpoint may need a different next step from an active match on a critical server. Use the evidence available in the case rather than severity alone.

5. Scope the incident

If the IOC appears on multiple endpoints or is associated with related indicators, expand the incident scope. Record the affected endpoint set, the reason for inclusion, the earliest available matching scan and any systems that remain unverified. This converts a search result into an auditable scoping decision.

6. Select the next action

Depending on the enabled Defensium capabilities and analyst authorisation, matching endpoints can be routed to targeted rescanning, file collection, quarantine, live response or further investigation. Actions should be proportional to confidence and business impact.

The central action loop

The value of a fleet-wide search is measured by what happens after the result. Defensium keeps the operator in one workflow:

1. Search: Submit the IOC to IntelStream and define the authorised endpoint scope.
2. Review: Inspect matches, scan timestamp, endpoint state, match source and related evidence.
3. Prioritise: Separate active critical systems from stale or low-confidence matches.
4. Investigate: Launch a targeted rescan, deeper file or behavioural analysis, or ATLANTIS collection for selected endpoints.
5. Act: Route authorised endpoints to the enabled quarantine, live-response or further-investigation workflow.
6. Record: Document the search criteria, result set and decision in the related incident workflow.

The result remains connected to the next decision instead of becoming an isolated search export.

What the search can reveal

Search pivot	Useful output	Investigation value	Caution
SHA-256 hash	Matching files, endpoints and threat instances.	Can identify the same file content across different paths and endpoints, including renamed copies when the hash is unchanged.	A new build or modified copy may have a different hash.
Filename	Files sharing a name across paths and endpoints.	Finds files with the same name that are duplicated or staged in different locations.	A renamed file will not match a filename search; corroborate with hash, path or publisher.
File path	Repeated locations such as user-writable, temporary or shared directories.	Shows common staging locations and helps identify affected endpoint groups.	Paths can be legitimate and may vary by user or operating system.
Domain, IP or URL	Matches within supported files, logs, artefacts or network telemetry, depending on the selected source.	Extends the investigation toward potential command-and-control, delivery or embedded infrastructure indicators; the match source determines whether actual communication can be inferred.	A file or log match alone does not prove a network connection.

The match source determines what a result means:

Match source	Correct interpretation
File hash	Strong evidence that the same file identity was observed.
File content containing a domain or IP	The indicator appears in the file or collected content; this does not prove a network connection.
Log or event record	The indicator was recorded by an application or system event and needs contextual review.
Browser or user artefact	Provides user or web-activity context where the selected evidence source supports it.
Network telemetry	Provides stronger support for actual connection activity when such telemetry is available.
Historical artefact	Indicates prior exposure; the IOC may no longer be active.

Synthetic hunt result

The following example shows how an analyst can distinguish confirmed matches from supporting evidence:

Endpoint	Match source	IOC	Path / evidence	Scan observation	Assessment
FINANCE-PC-07	SHA-256	Demonstration hash	C:\Users\demo\AppData\Local\Temp\invoice_update.exe	Recent matching scan	Initial high-priority detection.
FINANCE-PC-12	Filename + hash	Demonstration hash	C:\Users\demo\Downloads\invoice_update.exe	Recent matching scan	Same file identity; expand scope.
FILE-SRV-02	Filename only	—	C:\Archive\invoice_update.exe	Historical matching scan	Hash validation required.
HR-PC-04	Domain string	update-check.example	Log or file content	Older matching scan	Supporting evidence; not proof of network communication.

Analyst verdict: The SHA-256 is confirmed on two workstations. The filename-only result on the file server is queued for targeted verification, while the domain match remains supporting evidence until a connection source is confirmed. The incident scope is expanded to the two confirmed endpoints and the file server is queued for validation.

How to compare IOC-hunting capabilities

When evaluating Defensium against an EDR, a DFIR collection platform or a standalone scanner, compare the complete operating loop rather than one search box:

Evaluation area	Defensium / IntelStream focus
Indicator breadth	Hash, IP, domain and URL pivots, with filename, path or email support depending on the selected source and configuration.
Fleet scope	Centrally orchestrated targeted scans across authorised endpoints, with explicit group and available time-window control.
Investigation depth	Handoff to deeper file, behavioural and forensic analysis, including ATLANTIS collection where enabled.
Response continuity	Route matching endpoints to enabled rescan, file analysis, quarantine, live response or further-investigation workflows.
Analyst noise	Trusted-hash and FP governance can keep repeat known-good results from dominating the queue.
Resource control	Targeted first-pass search and scoped follow-up reduce unnecessary endpoint workload.

This comparison framework is capability-based. Product-specific feature claims should be validated against each vendor’s current public documentation before publication.

From one result to a prioritised endpoint list

IntelStream’s result is the starting point for prioritisation, not the end of the investigation. The output should not be treated as a flat list. Prioritise matches using a consistent set of questions:

• Is the endpoint online and responding?
• Is it a high-value server, identity system or sensitive workstation?
• Is the match recent or repeated?
• Does the endpoint have a related high-severity alert or behavioural rule?
• Is the file present, deleted, quarantined or only referenced by historical evidence?
• Is there a second indicator that supports the same activity?

This produces a practical queue: immediate containment candidates, endpoints requiring evidence collection, and lower-confidence matches that need validation.

What Defensium contributes

Defensium turns an IOC from a single alert field into a fleet-level investigation and response workflow, powered by IntelStream:

• IntelStream IOC search: Pivot on supported hash, IP, domain and URL indicators, with additional pivots depending on the selected source and configuration.
• Resource-aware scoping: Start with a low-noise targeted search, use available time windows and reserve deeper scans for confirmed matches.
• Scope comparison: Review matching endpoints and observations together to determine whether the event is isolated or distributed.
• Evidence continuity: Document the search criteria, returned matches and analyst decision in the related incident workflow.
• Centralised action: Route selected endpoints from the IntelStream result into enabled rescanning, file analysis, ATLANTIS evidence collection, quarantine, live response or further investigation.

Practical outcome

Fleet-wide IOC hunting answers the question that a single-endpoint detection cannot: where else should we look? Defensium helps the analyst move from one suspicious object to a measured endpoint scope, a prioritised action list and documented incident context.

The operational advantage is focused scoping with central control: IntelStream helps establish whether an IOC appears isolated or distributed across the selected endpoint scope, while Defensium keeps the resulting investigation and authorised next actions within the same operational context. Resource-aware follow-up prevents the investigation from becoming unnecessarily disruptive to business systems.

Verification checklist

Before closing the hunt, confirm:

• the IOC value and type are recorded exactly;
• the endpoint search scope and time window are documented;
• matching and non-matching endpoint groups are distinguishable;
• first and latest observations are compared where available;
• filename and path matches are corroborated before escalation;
• affected critical systems are prioritised;
• follow-up scans, evidence collection or response actions have an owner;
• the final scope and unresolved gaps are documented in the related incident workflow.