NGFW Scan

This playbook handles external and internal scanning alerts. **Attacker's Goals:** Adversaries may attempt to get a listing of services running on remote hosts, including those that may be vulnerable to remote software exploitation. Methods to acquire this information include port scans and vulnerability scans using tools that are brought onto a system. **Investigative Actions:** Investigate the scanner IP address using: * IP enrichment: * NGFW Internal Scan playbook * Endpoint Investigation Plan playbook * Entity enrichment **Response Actions** The playbook's response actions are based on the initial data provided within the alert. In that phase, the playbook will execute: * Automatically block IP address * Report IP address (If configured as true in the playbook inputs) When the playbook executes, it checks for additional activity using the Endpoint Investigation Plan playbook, and another phase, which includes the Containment Plan playbook, is executed. This phase will execute the following containment actions: * Automatically isolate involved endpoint * Manual block indicators * Manual file quarantine * Manual disable user **External resources:** [Mitre technique T1046 - Network Service Scanning](https://attack.mitre.org/techniques/T1046/) [Port Scan](https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR-Analytics-Alert-Reference/Port-Scan)

Pack

Core

Tasks

31

Inputs

• scannerIP — The scanner IP address.
• blockKnownScanner — Whether to block the IP address based on previously seen scanning alerts.
• AutoCloseAlert — Whether to close the alert automatically or manually, after an analyst's review.
• AutoRecovery — Whether to execute the Recovery playbook.
• SOCEmailAddress — The SOC email address.
• reportIPAddress — Whether to report the IP address to AbuseIPDB.
• AutoContainment — Whether to execute automatically or manually the containment plan tasks: * Block indicators * Quarantine file * Disable user
• HostAutoContainment — Whether to execute endpoint isolation automatically or manually.
• ShouldOpenTicket — Whether to open a ticket automatically in a ticketing system. (True/False).
• serviceNowShortDescription — A short description of the ticket.
• serviceNowImpact — The impact for the new ticket. Leave empty for ServiceNow default impact.
• serviceNowUrgency — The urgency of the new ticket. Leave empty for ServiceNow default urgency.
• serviceNowSeverity — The severity of the new ticket. Leave empty for ServiceNow default severity.
• serviceNowTicketType — The ServiceNow ticket type. Options are "incident", "problem", "change_request", "sc_request", "sc_task", or "sc_req_item". Default is "incident".
• serviceNowCategory — The category of the ServiceNow ticket.
• serviceNowAssignmentGroup — The group to which to assign the new ticket.
• ZendeskPriority — The urgency with which the ticket should be addressed. Allowed values are "urgent", "high", "normal", or "low".
• ZendeskRequester — The user who requested this ticket.
• ZendeskStatus — The state of the ticket. Allowed values are "new", "open", "pending", "hold", "solved", or "closed".
• ZendeskSubject — The value of the subject field for this ticket.
• ZendeskTags — The array of tags applied to this ticket.
• ZendeskType — The type of this ticket. Allowed values are "problem", "incident", "question", or "task".
• ZendeskAssigne — The agent currently assigned to the ticket.
• ZendeskCollaborators — The users currently CC'ed on the ticket.
• description — The ticket description.
• addCommentPerEndpoint — Whether to append a new comment to the ticket for each endpoint in the incident. Possible values: True/False.
• CommentToAdd — Comment for the ticket.
• UserVerification — Possible values: True/False. Default: True. Whether to provide user verification for blocking IP addresses.

Commands used

• abuseipdb-report-ip
• closeInvestigation
• ip
• send-mail
• setParentIncidentFields