> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/cortex-xdr/detect-investigate-and-respond-to-threats/threat-management/extended-threat-intelligence/xti-indicator-rules.md). # XTI indicator rules Create indicator rules that detect known threat indicators and generate issues from matching data. Use XTI indicator rules to monitor your environment for known threat indicators—such as malicious IPs, domains, and file hashes. Configure an indicator rule to scan collected log data and generate an issue for investigation upon a match. XTI indicator rules offer smart, dynamic targeting. In addition to manually selecting static lists of indicators, you can build dynamic, attribute-based filters using rich threat intelligence context. For example, you can create a rule that automatically targets "all indicators linked to a specific threat actor with a malicious verdict". As new intel is ingested that matches your filters, the rule dynamically updates its scope without manual intervention. Historical lookback through recurring retrohunting enables ongoing scanning of past log data. ## Out-of-the box indicator rules Cortex provides out-of-the-box (OOTB) indicator rules to empower security teams with immediate, battle-tested protection that requires minimal setup effort. These rules are designed to bridge the gap between initial onboarding and high-maturity detection engineering by providing broad, industry-standard coverage for common threats. The following out-of-the-box indicator rules are enabled by default and can be disabled if needed:

Rule name	Description
Rule name	Description
Malicious domain associated with a known threat actor or malware family	Identifies activity involving a domain classified as malicious by threat intelligence and associated with at least one known threat actor or malware family, indicating contact with attributed adversary infrastructure.
Malicious file hash associated with a known threat actor or malware family	Identifies a file whose hash is classified as malicious by threat intelligence and is associated with at least one known threat actor or malware family. Hash matches are deterministic and indicate the presence of tooling or malware attributed to tracked adversary activity.
Malicious IP address associated with a known threat actor or malware	Identifies activity involving an IP address classified as malicious by threat intelligence and associated with at least one known threat actor or malware family. Note that IP addresses are more frequently shared across hosting providers, proxies, and CDNs than other indicator types.

## Supported indicator rule types Currently, only detection rules are supported. You can create a detection rule using a static list of manually selected indicators or a dynamic filter that automatically adds new indicators to the rule based on the filter conditions. ## Indicator rule limits * Each tenant is limited to a maximum of 4 million indicators flagged by indicator rules. * The maximum number of indicators allowed per rule depends on the scoping mechanism used (static list or dynamic filter). Rules using static lists support up to 1,000 indicators, while rules using dynamic filters can support up to 1,000,000 indicators. If you require a higher limit, reach out to Palo Alto Networks. * Retrohunting evaluates 200 events per indicator, processing the earliest 200 events ingested. ## Permissions required for using indicator rules Viewing indicator rules requires **View** RBAC permissions for both **Threat Intelligence** and **Rules** in the **Threat Management** component tab. Creating, modifying, enabling/disabling, and deleting indicator rules requires **View** or **View/Edit** RBAC permissions for both **Threat Intelligence** and **Rules** in the **Threat Management** component tab. ## View indicator rules To view and manage indicator rules, go to **Threat Management → Detection Rules → Indicator Rules**. For each rule, you can see: Modification Date, Name, Type, Target, Severity, # of Issues, Created by, Description, Status, Rule ID, and Creation Date. To view issues generated by a specific rule, right-click on the rule and select **View Related Issues**. ## Create an indicator rule for detection To create a detection rule: 1. Go to **Threat Management → Detection Rules → Indicator Rules**. 2. Select **+Add Rule**. 3. In the **Overview**, provide: 1. **Rule Name**: The rule name is used when creating issues triggered by the rule (The title and description of an issue will include the rule name and the indicator value). The rule name can include up to 75 characters; no special characters are allowed. 2. **Severity** (Critical, High, Medium, or Low): The severity of an indicator rule determines the severity of issues created as a result of rule matching. Severity also dictates rule priority. If two rules flag the same indicator, the rule with the highest severity is associated with the indicator and the corresponding issue. If two rules have the same severity, the last modified rule has priority. 3. **Description** (Optional) 4. You can optionally select to **Enable Historical Lookback** to enable one-time lookback scan per dataset triggered on rule creation and rule edit for the last 30 days. Retrohunting evaluates 200 events per indicator, processing the earliest 200 events ingested. Select the data sets for the scans. All datasets are preselected by default.

Dataset	Description	Indicators in scope
Dataset	Description	Indicators in scope
XDR Data	The xdr_data dataset is the primary normalized dataset for endpoint and network telemetry.	File hash, IP, Domain
Email Data	The email_data dataset contains normalized information related to email traffic and security events ingested from supported email providers.	File hash, IP
Cloud Audit Logs	The cloud_audit_logs dataset stores normalized audit telemetry from public cloud environments.	IP
SaaS Audit Logs	The saas_audit_logs dataset contains normalized logs from third-party SaaS applications.	IP

4. Select **Next**. 5. In the **Select Target Indicators**, select one of the following. 1. **Static List**: Manually select indicators one by one. Click on **Add Indicators** to filter and add them. You can select up to 1000 indicators. 2. **Dynamic Filters**: Specify a filter. The filter automatically adds new indicators to the rule based on the filter conditions, up to 1 million indicators per rule. 6. Select **Next**. 7. Confirm the details and select **Create New Rule** to save the rule. During forward-looking matching, Cortex generates a single issue for each indicator. Retrohunting generates a separate issue for each indicator per dataset. When investigating an issue, you can view matching indicators and matching raw events from the issue side pane. ## Modify an indicator rule You can modify a previously created indicator rule to update future detections. All parameters can be modified. Note: Changes take effect going forward and do not apply retroactively. Existing issues are not closed or updated after a rule modification. To modify a previously created rule: 1. Go to Threat Management → Detection Rules → Indicator Rules. 2. Right-click a rule and then select Edit Rule. ## Enable or disable an indicator rule You can enable or disable indicator rules. {% hint style="info" %} Disabling a rule stops new rule matching but does not close previously generated issues. {% endhint %} To enable or disable a rule: 1. Go to **Threat Management → Detection Rules → Indicator Rules**. 2. Right-click a rule and then select **Disable Rule** or **Enable Rule**. 3. Confirm by selecting **Yes**. ## Delete an indicator rule You can delete a previously created indicator rule to prevent future detections. Deleting an indicator rule cannot be reverted. Note: Existing issues generated by the rule are not closed after you delete the rule. To delete a rule: 1. Go to **Threat Management → Detection Rules → Indicator Rules**. 2. Right-click a rule and then select **Delete Rule**. 3. Confirm by selecting **Delete**. ### Datasets used for indicator rule matching XTI indicator rules match against the following datasets:

Dataset	Description	Indicators in scope
Dataset	Description	Indicators in scope
XDR Data	The xdr_data dataset is the primary normalized dataset for endpoint and network telemetry.	File hash, IP, Domain
Email Data	The email_data dataset contains normalized information related to email traffic and security events ingested from supported email providers.	File hash, IP
Cloud Audit Logs	The cloud_audit_logs dataset stores normalized audit telemetry from public cloud environments.	IP
SaaS Audit Logs	The saas_audit_logs dataset contains normalized logs from third-party SaaS applications.	IP

### Event field mapping The following event fields are utilized for indicator rule matching against a dataset:

Event field	Normalized XDM	XTI type
Event field	Normalized XDM	XTI type
action_process_image_sha256	xdm.target.process.executable.sha256	File Hash
action_process_image_md5	xdm.target.process.executable.md5	File Hash
action_file_sha256	xdm.target.file.sha256	File Hash
action_file_md5	xdm.target.file.md5	File Hash
action_remote_ip	Can be one of the following: Xdm.target.host.ipv4_addresses Xdm.target.ipv4 Xdm.target.ipv6 Xdm.intermediate.ipv4 xdm.intermediate.ipv6	IP
action_external_hostname	Can be one of the following: Xdm.intermediate.host.fqdn Xdm.source.host.fqdn Xdm.target.host.fqdn Xdm.target.ipv4 xdm.target.ipv6	Domain
action_remote_ip	Can be one of the following: Xdm.intermediate.ipv4 Xdm.intermediate.ipv6 Xdm.target.host.ipv4_addresses Xdm.target.ipv4 xdm.target.ipv6	IP
action_local_ip	Can be one of the following: Xdm.source.ipv4 xdm.source.ipv6	IP
action_external_hostname dst_action_external_hostname	Can be one of the following: Xdm.target.host.fqdn Xdm.target.ipv4 Xdm.target.ipv6	Domain, IP
dns_query_name	xdm.network.dns.dns_question.name	Domain

\ \
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xdr/detect-investigate-and-respond-to-threats/threat-management/extended-threat-intelligence/xti-indicator-rules.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.