Lesson 16 — Indicators
Indicators allow security teams to apply a deliberate response to known files, certificates, IP addresses, URLs and domains across devices protected by Microsoft Defender for Endpoint.
Depending on the indicator type and supported platform capabilities, analysts can allow trusted activity, audit behaviour, warn users or block known threats.
This lesson explains how indicators work, how to choose an appropriate action, how to control scope and expiration, and how to validate that an indicator is producing the intended security outcome.
What you will learn
This lesson explains how to turn validated threat intelligence into controlled endpoint protection.
Learning objectives
After completing this lesson, you should be able to manage indicators as part of a controlled endpoint response process.
- Explain the purpose of Defender for Endpoint indicators.
- Recognise file, certificate, IP, URL and domain indicators.
- Select an appropriate response action.
- Apply scope, expiration and documentation controls.
- Validate and review indicator effectiveness.
The problem this solves
An investigation may confirm that a malicious file, certificate, IP address, URL or domain threatens more than one endpoint.
Indicators convert that intelligence into a reusable control, helping the organisation detect or prevent the same activity across an approved group of protected devices.
What is an indicator?
An indicator is a security rule based on a known observable such as a file hash, signing certificate, network address or web destination.
Microsoft Defender for Endpoint evaluates supported endpoint activity against active indicators and applies the configured response when a match occurs.
An indicator should begin with validated evidence. A suspicious-looking value is not automatically safe to block across an organisation.
File indicators
File indicators commonly use a cryptographic hash to identify a specific file.
- Useful for confirmed malware or unwanted tools.
- Precise for the exact file represented by the hash.
- A modified or repackaged file produces a different hash.
- File prevalence and signer information should be reviewed first.
Certificate indicators
Certificate indicators can apply protection based on the certificate used to sign files.
- Can affect multiple files signed by the same certificate.
- Potentially broader than a single file-hash indicator.
- Useful when a malicious campaign consistently uses one certificate.
- Requires careful validation to avoid blocking legitimate software.
IP address indicators
IP indicators help control communication with known network infrastructure.
- Useful for confirmed command-and-control destinations.
- Shared hosting can make an IP address affect unrelated services.
- Cloud infrastructure may change addresses frequently.
- Threat intelligence should be recent and attributable.
URL and domain indicators
URL and domain indicators can control access to malicious web destinations.
- A URL can target a specific path or destination.
- A domain may affect a much broader set of services.
- Subdomains and redirection behaviour must be considered.
- Business use and false-positive risk should be checked.
Choosing the indicator action
Available actions depend on the indicator type, platform support and security configuration. Always use the options presented by the Microsoft Defender portal for the selected observable.
| Action | Purpose | When it may be appropriate |
|---|---|---|
| Allow | Permits trusted activity that might otherwise be blocked by security controls. | A thoroughly validated business file or destination is being incorrectly prevented. |
| Audit | Records matches without immediately preventing the activity. | The security team wants evidence of prevalence and impact before enforcing a block. |
| Warn | Presents a warning while providing a controlled user experience where supported. | A web destination is risky or discouraged, but the organisation has not selected a complete block. |
| Block | Prevents supported activity associated with the indicator. | The observable is confirmed malicious and enforcement is justified. |
Allow indicators require caution
An allow indicator can override protection for the specified observable and may weaken a defensive control.
Use allow actions narrowly, document the business justification and remove them when the underlying detection or application issue has been resolved.
Audit before enforcement
Audit can help reveal how widely an observable appears before a block is applied.
This is especially useful when the indicator may affect a legitimate internal application, shared infrastructure or a large group of users.
Before creating an indicator
- Confirm the observable was extracted correctly.
- Review the alert, incident, device timeline and related evidence.
- Check file signer, prevalence, reputation and organisational use where relevant.
- Determine whether the observable is unique, shared or likely to change.
- Select the least disruptive action that still meets the response objective.
- Choose the correct device-group scope.
- Set a suitable expiration date.
- Record the incident, owner and reason for the indicator.
Indicator scope
Scope controls which protected devices receive the indicator.
A narrow device-group scope can reduce risk during testing, while organisation-wide scope may be justified for a confirmed high-confidence threat affecting the broader environment.
Expiration and lifecycle
Indicators should not remain active indefinitely without review.
Use expiration dates for temporary controls, revisit long-lived indicators and remove entries that are obsolete, duplicated or no longer supported by current intelligence.
Creating an indicator
Indicators can be created from supported investigation views or manually within the Microsoft Defender portal. The exact fields vary by indicator type.
A useful description should state what was observed, why the action was selected, which incident authorised it and when the indicator should be reviewed.
Propagation is not instantaneous
Creating an indicator does not guarantee every endpoint has applied it at the same moment.
Allow time for the control to propagate, confirm device connectivity and validate the outcome before assuming the threat has been blocked everywhere.
Platform and configuration support
Indicator enforcement depends on supported operating systems, Defender onboarding, cloud-delivered protection and other required security capabilities.
Review Microsoft's current product guidance and the options shown in the portal for the relevant indicator type.
How to validate an indicator
- Confirm the indicator is active and has the expected action.
- Verify the correct observable and value were entered.
- Review the assigned device groups and expiration date.
- Check endpoint security events and Defender alerts for matches.
- Use Advanced Hunting to find earlier and later occurrences.
- Confirm legitimate applications and services remain available.
- Record the test result and any required adjustment.
Hunt for historical exposure
An indicator helps with current and future enforcement, but analysts should also determine whether the observable appeared before the control existed.
Search relevant Defender tables for the hash, certificate, IP address, URL or domain across the required investigation period.
Do not rely on one IOC
Attackers can change file hashes, domains and infrastructure quickly.
Combine indicators with behavioural detections, attack-path analysis, identity investigation and endpoint telemetry to avoid depending on a single observable.
Example investigation workflow
Use the indicator to interrupt a known threat, then hunt for the behaviour that produced it. The attacker may return with a different hash or destination.
Common file-indicator mistake
A file name is not a file hash.
Different files can share the same name, and the same malicious file can be renamed. Validate the cryptographic hash and supporting evidence before creating the control.
Common network-indicator mistake
Blocking a shared IP address or broad domain can affect unrelated customers and legitimate cloud services.
Investigate ownership, hosting and business dependencies, and prefer a more precise observable when one is available.
Common mistakes
| Mistake | Why it creates risk | Better practice |
|---|---|---|
| Blocking without validating the observable | Legitimate software, users or services may be disrupted. | Correlate the IOC with incident evidence, reputation, prevalence and business use. |
| Using organisation-wide scope immediately | A false positive can affect every protected endpoint. | Use a controlled scope when testing is appropriate, then expand deliberately. |
| Creating permanent temporary indicators | Old intelligence accumulates and creates future operational problems. | Set expiration dates and assign review ownership. |
| Assuming the IOC represents the whole attack | The attacker may change infrastructure or payloads while keeping the same behaviour. | Hunt for related processes, identities, devices, techniques and timelines. |
Key takeaways
- Indicators turn validated threat intelligence into reusable endpoint controls.
- Supported types include files, certificates, IP addresses, URLs and domains.
- Actions can include allow, audit, warn and block, depending on type and support.
- Scope, expiration and documentation are essential governance controls.
- Validate propagation, security telemetry and business impact.
- Combine IOC controls with behavioural hunting and wider incident investigation.
Related Agent Foskett resources
Continue learning
Microsoft Defender for Endpoint Indicators
Microsoft Defender for Endpoint indicators help security teams allow, audit, warn or block supported files, certificates, IP addresses, URLs and domains across protected devices.
Module 3 Endpoint Investigations — Indicators Lesson 16
This Agent Foskett Defender for Endpoint Academy lesson explains indicator types, action selection, device-group scope, expiration, validation and the importance of combining indicators with behavioural threat hunting.
