How to Run Fleet-Wide IOC Searches with IntelStream
Configure fleet-wide IOC searches with IntelStream, select endpoint groups and time windows, interpret match sources and launch authorised follow-up actions from Defensium.
01 / What IntelStream is for
IntelStream is Defensium's fleet-wide IOC hunting engine. It centrally orchestrates targeted indicator searches across authorised endpoint groups, returns matches to the Defensium console and connects confirmed results to investigation and response workflows. It helps an analyst answer a practical question after an alert: does this indicator appear elsewhere, and which systems require the next level of attention?
Analysts can pivot on file and network indicators such as hashes, IP addresses, domains and URLs, with additional filename, path and configured indicator searches provided through relevant evidence sources. Each result remains connected to its endpoint, match source and investigation context so the analyst can distinguish a confirmed file identity from supporting or historical evidence.
02 / Before you start
Before launching an IntelStream search:
- prepare the exact IOC value and confirm its type;
- record the intelligence source, confidence and related alert or incident;
- identify the authorised endpoint or endpoint group;
- define the investigation time window and timezone;
- select the evidence source appropriate for the IOC;
- confirm the operator is authorised for the intended follow-up actions.
03 / Why fleet-wide IOC search matters
A detection on one workstation can be the first visible trace of a wider intrusion. Checking every endpoint manually is slow, difficult to reproduce and likely to produce inconsistent scope decisions. IntelStream lets the analyst define the indicator, endpoint group and available time window centrally, then compare returned matches in one operational context.
Fleet-wide IOC search is useful for:
- scoping a known malicious hash across workstations and servers;
- checking whether a delivery domain or IP appears in supported files, logs or telemetry;
- identifying repeated filename or path matches for targeted validation;
- separating confirmed matches from historical or supporting evidence;
- prioritising critical systems before deeper analysis or authorised response.
04 / The IntelStream operating workflow
- Prepare the IOC. Record the exact value, type, source, confidence and investigation reference.
- Select the search logic. Choose the supported indicator pivot and understand what the selected source can actually return.
- Define the endpoint group. Search one endpoint, a controlled group or the authorised fleet segment relevant to the case.
- Set the time window. Use the available time range to focus the question and document its timezone and meaning.
- Run and review. Inspect matches, source, endpoint state, scan observation and related evidence.
- Prioritise and act. Route confirmed or high-impact matches to targeted rescan, collection, quarantine, live response or investigation according to authorisation.
- Record the decision. Preserve the search criteria, result set, unresolved gaps and next-action owner in the incident workflow.
05 / Configure an IntelStream search
The search configuration translates the investigation question into a repeatable fleet operation.
| Field | Purpose |
|---|---|
| Search name | Identifies the hunt in task, scan and investigation history. |
| IOC type | Defines how IntelStream interprets the submitted value. |
| IOC value | Stores the exact hash, IP address, domain, URL, filename, path or configured indicator. |
| Evidence source | Determines which supported file, log, artifact or telemetry source will be searched. |
| Endpoint scope | Selects one endpoint, a controlled group or an authorised fleet segment. |
| Time window | Focuses the relevant scan or observation period. |
| Confidence and severity | Records the operational importance of the submitted indicator. |
| Investigation reference | Connects the hunt to the related alert, case or incident workflow. |
Use a clear search name and preserve the submitted IOC exactly. This makes the result reproducible and allows later validation searches to be compared with the original operation.
06 / IOC types and search pivots
Start with the strongest indicator available. A SHA-256 is usually a more precise pivot than a filename; a domain or IP requires careful interpretation of the source in which it matched.
| IOC type | What it can return | Best use | Important interpretation note |
|---|---|---|---|
| SHA-256 hash | Matching file identity, endpoint and available threat-instance context. | Confirm whether the same content appears on other systems, including renamed copies when the hash is unchanged. | A modified or repacked file has a different hash. |
| Filename | Files sharing a name across supported paths or sources. | Find duplicated or staged files for follow-up. | A renamed file will not match a filename search. Corroborate with hash, path or publisher. |
| File path | Matches for supported path evidence. | Identify repeated staging locations or affected directory patterns. | Availability and meaning depend on the selected evidence source and configuration. |
| Domain | Matches in supported files, logs, artifacts or network telemetry. | Investigate delivery, command-and-control or embedded infrastructure indicators. | A string match does not prove a network connection. |
| IP address | Matches in supported content or telemetry. | Extend scope toward infrastructure and communication hypotheses. | Match source determines whether actual communication can be inferred. |
| URL | Matches in supported files, logs, browser or network-related evidence where available. | Investigate delivery links, callbacks and embedded references. | Historical or embedded URLs may not indicate current activity. |
| Email or other configured indicator | Matches returned through the selected source and configured field. | Follow a case-specific intelligence pivot. | Treat the result as source-dependent evidence and validate it before escalation. |
07 / Search logic and match source
The same IOC can mean different things depending on where it was found. IntelStream results should be read with the match source, endpoint, path or evidence reference and scan observation together.
| Match source | What the result supports | What it does not prove by itself |
|---|---|---|
| File hash | The same file identity was observed on the endpoint. | That the file executed or remains active. |
| File content | The indicator appears in collected content. | That the content was used or that a connection occurred. |
| Log or event record | An application or system recorded the indicator. | The complete attack chain or current activity. |
| Browser or user artifact | User or web-activity context where supported. | That the user intentionally executed or downloaded a file. |
| Network telemetry | Stronger support for connection activity when telemetry is available. | That the remote activity was malicious without additional context. |
| Historical artifact | Prior exposure or historical presence. | That the indicator is currently present or active. |
Use the narrowest search logic that answers the question. If a hash search returns two endpoints, do not immediately broaden to every filename or path variation; first validate those two results and expand only when the evidence supports it.
08 / Time-window control
Time windows make a fleet operation reproducible. Record the selected range, timezone and whether the result reflects a scan observation, an artifact timestamp or a historical record.
Use the window to:
- focus on the incident period;
- avoid mixing old historical evidence with current observations;
- compare an initial search with a later validation scan;
- reduce unnecessary work on endpoints outside the investigation period;
- explain why a result was included or excluded from the operational scope.
Do not label a result “first seen” or “last seen” unless the deployment maintains a historical IOC index. Safer language is earliest available matching observation and latest available matching observation within the selected sources and time window.
09 / Endpoint groups and fleet scope
The endpoint group is part of the investigation logic, not just a filter. Define whether the search covers:
- the initial endpoint only;
- a business unit or server role;
- endpoints with the same alert or exposure path;
- a controlled pilot group for rapid validation;
- the full authorised fleet segment.
Before launching, confirm endpoint identity, operating system, online state, business criticality and collection authorisation. For a spreading threat, begin with confirmed and high-value endpoints, then expand to related systems. Document excluded or unavailable endpoints so the result is not mistaken for complete fleet coverage.
10 / Search result interpretation
Treat the result as a prioritised evidence set rather than a flat count. For each match, review:
- IOC type and exact value;
- match source and rule or evidence reference;
- endpoint name, status and business role;
- path, filename or related metadata where available;
- scan observation and relevant time window;
- related alert severity or behavioural evidence;
- whether the item is present, historical, deleted, quarantined or unverified.
IntelStream result fields
| Result field | Meaning |
|---|---|
| Endpoint | The system that returned the match. |
| IOC type | The indicator type used for the search. |
| IOC value | The exact indicator associated with the result. |
| Match source | The file, log, artifact or telemetry source containing the match. |
| File path / evidence reference | The associated file location or evidence record. |
| Rule / detection reference | The rule, scanner or evidence reference that produced the result. |
| Scan observation | The timestamp associated with the matching scan or record. |
| Endpoint status | The endpoint state used to plan follow-up actions. |
| Threat context | Related severity, threat instance and investigation context. |
| Item state | Present, historical, deleted, quarantined or awaiting validation. |
Example hunt result
| Endpoint | Match source | IOC | Path / evidence | Observation | Assessment |
|---|---|---|---|---|---|
FINANCE-PC-07 | SHA-256 | Demonstration hash | C:\Users\demo\AppData\Local\Temp\invoice_update.exe | Recent matching scan | Confirmed high-priority starting point. |
FINANCE-PC-12 | SHA-256 | Demonstration hash | C:\Users\demo\Downloads\invoice_update.exe | Recent matching scan | Same file identity; expand investigation scope. |
FILE-SRV-02 | Filename only | — | C:\Archive\invoice_update.exe | Historical matching scan | Validate with hash or targeted collection. |
HR-PC-04 | Domain string | update-check.example | Supported log or file content | Older observation | Supporting evidence; not proof of communication. |
The analyst verdict should distinguish confirmed matches, validation candidates and supporting context. A filename-only result is not equivalent to a hash match; a domain embedded in a file is not equivalent to network telemetry.
11 / From result to central action
IntelStream is most valuable when the result leads directly to a controlled next step:
- Search the IOC across the authorised endpoint group.
- Review match source, endpoint state, observation and related evidence.
- Prioritise critical, online and recently observed systems.
- Investigate with a targeted rescan, deeper file analysis, behavioural review or ATLANTIS evidence collection where enabled.
- Act through authorised quarantine, file transfer, live response, isolation or remediation workflows.
- Record the criteria, decisions and action history in the related incident workflow.
The available action set depends on the deployment, endpoint state and operator authorisation. An offline endpoint may require a later retry or alternate evidence path rather than an immediate live action.
12 / No-match and incomplete results
A no-match result means IntelStream did not return the indicator from the selected endpoint scope, evidence sources and time window. It does not mean the indicator never existed in the environment.
Before closing a hunt with no confirmed matches, review:
- endpoints that were offline, unavailable or excluded;
- the selected evidence sources and search logic;
- IOC formatting, normalisation and indicator type;
- the configured time window and timezone;
- partial, failed or pending scan tasks;
- hash, filename, path or infrastructure variations;
- systems that require a retry or targeted verification.
An incomplete result should preserve the successful matches and clearly separate unresolved endpoints. This prevents partial fleet coverage from being interpreted as a complete environment-wide conclusion.
13 / Resource-aware fleet operations
IntelStream supports focused scoping by combining indicator choice, endpoint selection and time-window controls. This allows analysts to begin with a targeted question and reserve deeper work for systems that return relevant evidence. Duration and throughput vary with the indicator, selected source, endpoint state, storage and environment.
The operational goal is low-noise, defensible prioritisation: obtain enough evidence to decide where to look next without turning every alert into an uncontrolled broad collection task.
14 / What Defensium contributes
IntelStream transforms isolated threat intelligence into an operational fleet decision. Analysts can submit an IOC once, apply it consistently across authorised endpoint groups, interpret every result according to its evidence source and route confirmed systems to deeper analysis or response without rebuilding the investigation in separate tools.
- IntelStream IOC search: Centrally orchestrates supported IOC searches across authorised endpoint scopes.
- Source-aware interpretation: Shows that a file, log, artifact or telemetry match has different evidentiary meaning.
- Time and group control: Makes the endpoint population and available observation window explicit.
- Prioritised follow-up: Moves confirmed or high-impact matches toward deeper analysis and collection.
- Central action continuity: Connects search results to enabled rescan, ATLANTIS, file analysis, quarantine, live response and investigation workflows.
- Audit-ready context: Preserves the search criteria, result set, unresolved gaps and analyst decision.
15 / Comparing IOC-hunting capabilities
When evaluating IntelStream against an EDR, DFIR collection platform or standalone scanner, compare the complete operating loop:
| Evaluation area | IntelStream emphasis |
|---|---|
| Indicator breadth | Hash, IP, domain and URL pivots, with filename, path or other support depending on source and configuration. |
| Fleet scope | Centrally orchestrated targeted searches across authorised endpoint groups. |
| Time control | Explicit available window and documented observation meaning. |
| Result context | Endpoint, source, path or evidence reference and related investigation context. |
| Investigation depth | Handoff to deeper file, behavioural and forensic analysis, including ATLANTIS where enabled. |
| Central response | Route selected systems to enabled rescan, collection, quarantine, live response or remediation workflows. |
| Noise management | FP and trusted-hash governance can keep known-good results from dominating the queue. |
Meaningful comparisons should use the same IOC, endpoint scope, evidence source and follow-up requirements across every evaluated platform.
16 / Verification checklist
- IOC value and type are recorded exactly.
- Search source and supported match logic are understood.
- Endpoint group and exclusions are documented.
- Time window and timezone assumptions are recorded.
- Match source is reviewed before escalation.
- Hash, filename, path and network matches are not treated as equivalent.
- Critical and online endpoints are prioritised.
- Unavailable endpoints and unresolved evidence gaps are visible.
- Follow-up action has an owner and authorisation.
- Search criteria, result and decision are documented in the related investigation workflow.
17 / Frequently asked questions
Does a filename match find renamed files?
No. A filename search finds the same name where the selected source supports it. A SHA-256 search is the appropriate pivot for the same file content under a different name or path.
Does a domain or IP match prove a connection?
No. The indicator may appear in a file, log, artifact or network telemetry. The match source must support the claim before actual communication is inferred.
Should every endpoint be searched for every IOC?
Not automatically. Start with the authorised endpoint scope that answers the case question, then expand deliberately when the result or threat model justifies it.
18 / Practical outcome
IntelStream turns one IOC into a measured fleet question: where does the indicator appear, what does each match actually mean and which endpoint should receive the next authorised action? Defensium keeps search, interpretation, investigation and response connected in one operational context.
