> 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-3.x/cortex-xdr-3.x-documentation/investigate-and-respond-to-incidents/investigate-alerts/overview-of-the-alerts-page.md). # Overview of the Alerts page The Alerts page consolidates all non-informational alerts from your detection sources, and helps you to analyze and triage the alerts on your system. The **Alerts** page consolidates all non-informational alerts from your detection sources. This helps you efficiently triage the events you see each day. By analyzing an alert, you can better understand the cause of the alert, and take actions where required. The default alert retention period in Cortex XDR is 186 days. To access the **Alerts** page, go to Incident Response → Incidents → **Alerts Table**. By default, the **Alerts** page displays the security alerts received over the last seven days. Every 12 hours, the system enforces a cleanup policy to remove the oldest alerts once the maximum limit is exceeded. To see detailed information about an alert, click an alert to open the alert panel. To investigate further, from the alert panel click **Investigate** or **Investigate Causality Chain**. For more information, see [Triage and investigate alerts](/cortex-xdr-3.x/cortex-xdr-3.x-documentation/investigate-and-respond-to-incidents/investigate-alerts/triage-and-investigate-alerts.md).
Standardized format of user names in alerts Cortex XDR processes and displays the names of users in the following standardized format, also termed “normalized user”. ***``*****`\`*****``*** As a result, any alert triggered based on network, authentication, or login events displays the **User Name** in the standardized format in the **Alerts** and **Incidents** pages. This impacts every alert for Cortex XDR Analytics and Cortex XDR Analytics BIOC, including BIOC, and IOC alerts triggered on one of these event types.
Deduplicated FW alerts To reduce noise in your environment, if firewall alerts with the same name and host are raised within 24 hours, the alerts are deduplicated. A label indicates the number of deduplicated alerts up to 1,000 alert counts, larger quantities display as 1000+. For more information, see [Alert deduplication](/cortex-xdr-3.x/cortex-xdr-3.x-documentation/investigate-and-respond-to-incidents/investigate-alerts/triage-and-investigate-alerts/alert-deduplication.md).
Featured fields You can highlight alerts that are important to you by tagging specific alert attributes, such as host names, user names, IP addresses, and Active Directory, as featured fields. This can help you track alerts in the Alerts table. For more information, see [Create a featured alert field](/cortex-xdr-3.x/cortex-xdr-3.x-documentation/investigate-and-respond-to-incidents/investigate-alerts/triage-and-investigate-alerts/create-a-featured-alert-field.md).
Alert field descriptions The following table describes both the default fields and additional optional fields that you can add to the alerts table using the column manager. | Field | Description | | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |

Status Indicator (

alert-status.png

)

| Identifies whether there is enough endpoint data to analyze an alert. | | ![check-box.png](https://2559304374-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FFOhYBYLdbwpnbJgr6uaX%2Fuploads%2Fgit-blob-c6b6b2f14c7423dbf3125f9808e33a5fb26dab66%2F11468e1befc00db3b0c88f2b1dffb70e40e07f1127a736143f9eb7bdc48aa526.png?alt=media) | Check box to select one or more alerts on which to perform actions. Select multiple alerts to assign all selected alerts to an analyst, or to change the status or severity of all selected alerts. | | ACTION | Action taken by the alert sensor, either `Detected` or `Prevented` with action status displayed in parenthesis. | | ADDED IN CONTENT VERSION | Content version in which the rule that generated the alert was first introduced or significantly changed. | | AGENT OS SUB TYPE | Operating system subtype of the agent from which the alert was triggered. | | ALERT ARRIVAL TIMESTAMP | Time that the alert was stored in Cortex XDR. | | ALERT ID | Unique identifier that Cortex XDR assigns to each alert. | | ALERT NAME | Module that triggered the alert. Alerts that match an alert starring policy also display a purple star. | | ALERT SOURCE | Source of the alert. | | APP-ID | Related App-ID for an alert. App-ID is a traffic classification system that determines what an application is irrespective of port, protocol, encryption (SSH or SSL) or any other evasive tactic used by the application. When known, you can also pivot to the Palo Alto Networks Applipedia entry that describes the detected application. | | APP CATEGORY | APP-ID category name associated with a firewall alert. | | APP SUBCATEGORY | APP-ID subcategory name associated with a firewall alert. | | APP TECHNOLOGY | APP-ID technology name associated with a firewall alert. | | CATEGORY | Alert category based on the alert source. An example of an Cortex XDR agent alert category is Exploit Modules. | | CGO CMD | Command-line arguments of the Causality Group Owner. | | CGO MD5 | MD5 value of the CGO that initiated the alert. | | CGO NAME | Name of the process that started the causality chain is based on Cortex XDR causality logic. | | CGO SHA256 | SHA256 value of the CGO that initiated the alert. | | CGO SIGNATURE | Signing status of the CGO | | CGO SIGNER |

Name of the software publishing vendor that signed the file in the causality chain that led up to the alert.

Note

Cortex XDR can display both the O (Organization) value and the CN (Common Name).

| | CLOUD IDENTITY TYPE | Classification is used to map the identity type that initiated an operation that triggered an alert. For example, `Service, Application`, and `Temporary Credentials`. | | CLOUD IDENTITY SUB-TYPE | Specific classification of the identity initiated the operation. For example, for Identity Type: `Temporary Credentials` the subtype could be `Assumed Role`. | | CLOUD OPERATION TYPE | Represents what has happened because of the identity operation. For example, `Create`, `Delete`, and `Modify`. | | CLOUD PROJECT | Represents the cloud provider folders or projects. For example, AWS Accounts and Azure Subscriptions. | | CLOUD PROVIDER | Name of the cloud provider where the alert occurred. | | CLOUD REFERENCED RESOURCE | Represents the resources that are referenced in the alert log. In most cases, the referred resource will be where the operation was initiated on. | | CLOUD RESOURCE TYPE | Classifications are used to map similar types of resources across different cloud providers. For example, `EC2`, `Google Compute Engine`, and `Microsoft Compute` are all mapped to `Compute`. | | CLOUD RESOURCE SUB-TYPE | Specific classification is used to map the types of resources. For example, `DISK, VPC, and Subnet` are all mapped to `Compute`. | | CONTAINS FEATURED HOST | Whether the alert includes a host name that has been flagged as a Featured Alert Field. | | CONTAINS FEATURED USER | Whether the alert includes a user name that has been flagged as a Featured Alert Field. | | CONTAINS FEATURED IP ADDRESS | Whether the alert includes an IP address name that has been flagged as a Featured Alert Field. | | CID | Unique identifier of the causality instance generated by Cortex XDR . | | DESCRIPTION | Text summary of the event including the alert source, alert name, severity, and file path. | | DESTINATION ZONE NAME | Destination zone of the connection for firewall alerts. | | DNS Query Name | Domain name is queried in the DNS request. | | EMAIL RECIPIENT | Email recipient value of a firewall alerts triggered on the content of a malicious email. | | EMAIL SENDER | Email sender value of a firewall alerts triggered on the content of a malicious email. | | EMAIL SUBJECT | Email subject value of a firewall alerts triggered on the content of a malicious email. | | EVENT TYPE | Type of event on which the alert was triggered. | | EXCLUDED | Whether the alert is excluded by an exclusion configuration. | | EXTERNAL ID | Alert ID as recorded in the detector from which this alert was sent. | | FILE PATH | Path to the file on the endpoint, for alerts that are triggered on a file (the Event Type is File). | | FILE MACRO SHA256 | SHA256 hash value of a Microsoft Office file macro. | | FILE MD5 | MD5 hash value of the file. | | FILE SHA256 | SHA256 hash value of the file. | | FW NAME | Name of firewall on which a firewall alert was raised. | | FW RULE ID | Firewall rule ID that triggered the firewall alert. | | FW RULE NAME | Firewall rule name that matches the network traffic that triggered the firewall alert. | | FW SERIAL NUMBER | Serial number of the firewall that raised the firewall alert. | | HOST | Hostname of the endpoint or server on which this alert was triggered. The hostname is generally available for XDR agent alerts or alerts that are stitched with EDR data. When the hostname is unknown, this field is blank. | | HOST FQDN | Fully qualified domain name (FQDN) of the Windows endpoint or server on which this alert was triggered. | | HOST IP | IP address of the endpoint or server on which this alert was triggered. | | HOST IPv6 | IPv6 address of the endpoint or server on which this alert was triggered. | | HOST MAC ADDRESS | MAC address of the endpoint or server on which this alert was triggered. | | HOST OS | Operating system of the endpoint or server on which this alert was triggered. | | INCIDENT ID | ID of any incident that includes the alert. | | INITIATED BY | Name of the process that initiated an activity such as a network connection or registry change. | | INITIATOR MD5 | MD5 value of the process which initiated the alert. | | INITIATOR SHA256 | SHA256 hash value of the initiator. | | INITIATOR CMD | Command-line used to initiate the process including any arguments. | | INITIATOR SIGNATURE | Signing status of the process that initiated the activity. | | INITIATOR PATH | Path of the initiating process. | | INITIATOR PID | Process ID (PID) of the initiating process. | | INITIATOR SIGNER |

Signer of the process that triggered the alert.

Note

Cortex XDR can display both the O (Organization) value and the CN (Common Name).

| | INITIATOR TID | Thread ID (TID) of the initiating process. | | IS PHISHING | Whether a firewall alert is classified as phishing. | | LOCAL IP | IP address of the host that triggered the alert, for alerts that are triggered on network activity (the Event Type is Network Connection). | | LOCAL PORT | Port on the endpoint that triggered the alert, for alerts that are triggered on network activity (the Event Type is Network Connection). | | MAC ADDRESS | MAC address on which the alert was triggered. | | MISC | Miscellaneous information about the alert. | | MITRE ATT\&CK TACTIC | Type of MITRE ATT\&CK tactic on which the alert was triggered. | | MITRE ATT\&CK TECHNIQUE | Type of MITRE ATT\&CK technique and sub‑technique on which the alert was triggered. | | MODULE | For Cortex XDR agent alerts, this field identifies the protection module that triggered the alert. | | NGFW VSYS NAME | Name of the virtual system for the Palo Alto Networks firewall that triggered an alert. | | OS PARENT CREATED BY | Name of the parent operating system that created the alert. | | OS PARENT CMD | Command line used by the parent operating system to initiate the process including any arguments. | | OS PARENT SIGNATURE | Signing status of the operating system of the activity. | | OS PARENT SIGNER |

Parent operating system signer.

Note

Cortex XDR can display both the O (Organization) value and the CN (Common Name).

| | OS PARENT SH256 | Parent operating system SHA256 hash value. | | OS PARENT ID | Parent operating system ID. | | OS PARENT PID | OS parent process ID. | | OS PARENT TID | OS parent thread ID. | | OS PARENT USER NAME | Name of the user associated with the parent operating system. | | PHONE NUMBER | Shows the phone number that triggered the alert. This is the number that sent a malicious URL/spam or was blocked. | | PROCESS EXECUTION SIGNATURE | Signature status of the process that triggered the alert. | | PROCESS EXECUTION SIGNER |

Signer of the process that triggered the alert.

Note

Cortex XDR can display both the O (Organization) value and the CN (Common Name).

| | REGISTRY DATA | Registry data that triggered the alert, for alerts that are triggered on registry modifications (the Event Type is Registry). | | REGISTRY FULL KEY | Full registry key that triggered the alert, for alerts that are triggered on registry modifications (the Event Type is Registry). | | REMOTE HOST | Remote host name that triggered the alert, for alerts that are triggered on network activity (the Event Type is Network Connection). | | REMOTE IP | Remote IP address of a network operation that triggered the alert. | | REMOTE PORT | Remote port of a network operation that triggered the alert. | | RESOLUTION STATUS |

Status that was assigned to this alert when it was triggered (or modified). Right-click an alert to change the status. If you set the status to Resolved, select a resolution reason.

Any update made to an alert impacts the associated incident. An incident with all its associated alerts marked as resolved is automatically set to Auto-Resolved. Cortex XDR continues to group alerts to an Auto-Resolved Incident for up to six hours. In the case where an alert is triggered during this duration, Cortex XDR re-opens the incident.

| | RULE ID | ID that matches the rule that triggered the alert. | | SEVERITY | Severity that was assigned to this alert when it was triggered (or modified). | | STARRED | Whether the alert is starred by starring configuration. | | SOURCE ZONE NAME | Source zone name of the connection for firewall alerts. | | TAGS |

Displays one or more of the following categories, which is used to filter the results according to the selected tag:

| | TARGET FILE SHA256 | SHA256 hash value of an external DLL file that triggered the alert. | | TARGET PROCESS CMD | Command line of the process whose creation triggered the alert. | | TARGET PROCESS NAME | Name of the process whose creation triggered the alert. | | TARGET PROCESS SHA256 | SHA256 value of the process whose creation triggered the alert. | | TIMESTAMP |

Date and time when the alert occurred in the source origin. For example, when the alert occurred in the XDR agent.

Right-click to show rows 30 days prior or 30 days after the selected timestamp field value.

| | URL | URL destination address of the domain triggering the firewall alert. | | USER NAME |

Name of the user that initiated the behavior that triggered the alert. If the user is a domain user account, this field also identifies the domain.

Any alert triggered based on network, authentication, or login events, displays the User Name in the follow standardized format in the Alerts and Incidents pages.

\\\

| | XFF | X-Forwarded-For value from the HTTP header of the IP address connecting with a proxy. |
--- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://cortex-docs.paloaltonetworks.com/cortex-xdr-3.x/cortex-xdr-3.x-documentation/investigate-and-respond-to-incidents/investigate-alerts/overview-of-the-alerts-page.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.