> 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-xsiam/detect-investigate-and-respond-to-threats/attack-surface-management/attack-surface-management-detections/attack-surface-testing.md). # Attack Surface Testing {% hint style="info" %} ### Note Requires the ASM add-on. {% endhint %} Attack Surface Testing confirms vulnerabilities and misconfigurations on your external attack surface, enabling you to quickly and confidently prioritize risks. With your approval, Cortex XSIAM runs daily, controlled exploits against externally facing assets to confirm the presence or absence of vulnerabilities, eliminating the need to manually verify every inferred CVE. Issues are created for positive attack surface test results, so you can address these vulnerabilities as part of your existing remediation workflows. ## **Attack surface tests** Cortex XSIAM has an extensive set of attack surface tests for CVEs and other risks that affect externally-facing services and can be confirmed with controlled testing. Our attack surface testing is layered on top of our existing attack surface management (ASM) global scanning infrastructure, which distributes requests across a broad time range to minimize the impact to scanned and tested services. We perform external scans only, which means we only test directly-discovered services accessible from the public internet and that you selected for testing. To further decrease test load and the possibility of impacting a service, we map attack surface tests to service classifications, enabling us to run tests only on the relevant services in your approved set of targets. For example, we only run Apache attack surface tests against your Apache services. {% hint style="info" %} ### Note Attack surface testing scans are typically not CFAA compliant, meaning that they may attempt more extensive fuzzing to confirm or deny the presence of a CVE. Additionally, some attack surface tests are more intrusive than others. Tests are labeled with the level of intrusiveness, so you can decide whether to run more intrusive tests. {% endhint %} New attack surface tests are added at the discretion of the Cortex XSIAM Security Research Team when new vulnerabilities are announced. ## **Attack surface tests for default credentials** Attack Surface Testing does not perform authenticated tests; however, we do have attack surface tests focused on the detection of applications that are using manufacturer default credentials. These attack surface tests attempt to log in to specific business operations systems, IT, and networking devices with default credentials, but don't perform any operations if login is successful and will never change the state or configuration of a tested service. You can identify attack surface tests for default credentials by looking at the test Name field, which typically includes **Default Credentials** , and the Vulnerability ID field, which uses the prefix **DEFAULT-CRED-**. **Attack Surface Testing intrusivity** Attack surface tests are classified by their level of intrusivity. While most tests are benign, some vulnerabilities require more intrusive methods for confirmation. You can choose whether to enable these more intrusive tests, with the various levels of intrusiveness described in the table below. | Intrusivity level | Description | Examples | | ------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Level 0: Non-intrusive | No interaction with the target system beyond passive information gathering. The system remains completely unaffected by any tests. | | | Level 1: Minimal interaction | Basic interactions that involve standard requests without altering the system state or data. Any changes are confined to volatile memory and do not persist. | | | Level 2: Temporary modification | Makes temporary and fully reversible changes to the system. Modifications do not impact normal operations and can be undone without lasting effects. Cleanup is not necessary, but can be done. | | | Level 3: Reversible changes | Introduces changes that persist but can be reversed with your actions. These changes may slightly impact normal operations, but are recoverable. | | | Level 4: Significant impact | Makes significant changes that are not easily reversible. These actions may disrupt services or alter system data. | | | Level 5: Full compromise | Actions that fully compromise the system, leading to irreversible damage, persistent backdoors, or extensive disruption. | | ## **Set up Attack Surface Testing** To set up Attack Surface Testing for the first time, complete the following tasks: * [Task 1: Verify that you have edit permission for Vulnerability Testing](#UUID-afc5809d-f703-b7b0-82dc-85e85bb14fa6_section-id235175053282886) * [Task 2: Accept the End-User Licensing Agreement (EULA)](#UUID-afc5809d-f703-b7b0-82dc-85e85bb14fa6_section-id235175051846476) * [Task 3: Select targets for attack surface testing](#UUID-afc5809d-f703-b7b0-82dc-85e85bb14fa6_section-id235175050244242) * [Task 4: Configure the default enablement of new attack surface tests](#UUID-afc5809d-f703-b7b0-82dc-85e85bb14fa6_section-id235174946165067) **Task 1: Verify that you have edit permission for Vulnerability Testing** To set up Attack Surface Testing, you must have a role that includes edit permission for Vulnerability Testing. To check your role-based permissions go to **Settings** → **Configurations** → **Access Management** → **Roles**, and select the role. Select the Components tab, and find **Vulnerability Testing** under **Attack Surface**. **Task 2: Accept the End-User Licensing Agreement (EULA)** The EULA gives Cortex XSIAM permission to conduct attack surface testing scans. You only need to accept the EULA once. After accepting the EULA the Vulnerability Testing Configuration page opens automatically so you can select the targets for testing. You only need to accept the EULA once, before you enable attack surface testing for the first time. 1. Navigate to **Modules** → **Attack Surface** → **Policies** → **Attack Surface Tests**. 2. On the Welcome to Vulnerability Testing page, click **Next**. 3. Read the End-User Licensing Agreement and click **Accept Terms**. After accepting the terms of the EULA, the **Vulnerability Testing Configuration** page opens and you can select the set of services to be tested. **Task 3: Select targets for attack surface testing** Attack surface testing targets are directly-discovered services, which are definitively associated with an asset that belongs to your organization. You can choose to run attack surface tests on all your relevant directly-discovered services or you can specify a subset of services. Specify the directly-discovered services upon which Cortex XSIAM will run attack surface tests. After the initial set-up, you can update this set of targets anytime. 1. Navigate to **Settings** → **Configurations** → **Attack Surface** → **Attack Surface Testing**. 2. To select specific targets, in the **Target Testing** section, make sure the toggle is set to **Selected Targets**, and click **Edit Targets** (or **Add Targets** if this is the first time you are selecting targets.) To select all the targets, set the toggle to **All Targets**. This overrides your target selection. 3. Use the filter to define a set of targets from your list of services. 4. Click **Save Targets**. **Task 4: Configure the default enablement of new attack surface tests** When you first enable Attack Surface Testing, all existing attack surface tests with intrusiveness level 0 or level 1 are enabled by default. Moving forward, all new tests that are introduced, for all intrusiveness levels, are disabled by default. To configure Cortex XSIAM to automatically enable new attack surface tests and to specify the intrusiveness level of those default tests, perform the steps below. After the initial set-up, you can update this set of defaults anytime. 1. Navigate to **Settings** → **Configurations** → **Attack Surface** → **Attack Surface Testing**. 2. In the **Default Attack Surface Test Enablement** section, select the intrusiveness level for the new tests you want to be enabled by default moving forward. The intrusiveness level you select will include the tests for the levels below it. For example, if you select Level 2, then new level 0, level 1, and level 2 tests will be enabled moving forward. After you complete the initial set-up tasks, Cortex XSIAM begins daily attack surface testing scans using the default set of attack surface tests. The default set of tests consists of existing tests with level 0 and level 1 intrusiveness levels. You can now view details about attack surface tests and enable or disable them and view issues that were triggered by positive attack surface testing scans. ## **Manage attack surface tests** View information about the available attack surface tests, and enable or disable tests on the **Vulnerability Testing** page. By default all tests are enabled. 1. Navigate to **Modules** → **Attack Surface** → **Policies** → **Attack Surface Tests**. 2. Filter and sort the list of tests as needed to identify the tests you want to enable or disable. 3. Select one or more tests using the check boxes, and right click to **Enable** or **Disable** them.
Attack surface test field descriptions
FieldDescription
Affected SoftwareSoftware names and versions impacted by this vulnerability.
CWE IDsCommon Weakness Enumeration ID as defined by MITRE.
CreatedWhen Cortex XSIAM released this test.
EPSS Score DescriptionThe Exploit Prediction Scoring System (EPSS) score indicates the likelihood that a vulnerability will be exploited in the wild. Possible values are 0 -100%.the higher the score, the greater the probability that a vulnerability will be exploited.
ReferencesResearch references and supporting documentation.
Remediation GuidanceRecommended steps for remediating or mitigating the vulnerability.
Severity ScoreThe CVE severity score is based on the NIST Common Vulnerability Scoring System (CVSS).
Services Found VulnerableThe number of directly-discovered services owned by your organization that Cortex XSIAM has confirmed vulnerable with this test.
StatusIndicates whether the test is Enabled or Disabled.
Vendor NamesName of the vendor whose product is impacted by the vulnerability.
Vulnerability IDsCVE number or other public identifier for the vulnerability.
## **View issues created from Attack Surface Testing results** Cortex XSIAM creates issues for confirmed positive attack surface test results, for both vulnerabilities and misconfigurations. To view those issues and attack surface testing details, perform the following steps. 1. Navigate to **Modules** → **Attack Surface** → **Attack Surface Issues**. 2. Filter the issues list with **Finding Sources** **=** **Cortex Attack Surface Testing**. 3. To view AST scan details, click on an issue, and then select the **Overview** tab of the issue details panel. The AST scan details appear in the **Attack Surface Testing** section. ## **Source IP addresses for Attack Surface Testing scans** To view the IP address range Cortex XSIAM uses for vulnerability tests, navigate to **Settings** → **Configurations** → **Attack Surface** → **Attack Surface Testing** and refer to the **Source IP Addresses** section. We recommend adding this range to your organization's security tooling allow lists to avoid unnecessary alerting; however, we do not recommend modifying the configuration of your perimeter security controls to allow this traffic to pass. The aim of Attack Surface Testing is to confirm the exploitability of vulnerabilities from an attacker perspective. --- # 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-xsiam/detect-investigate-and-respond-to-threats/attack-surface-management/attack-surface-management-detections/attack-surface-testing.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.