Here’s my submission on response automation for Palo Alto Networks WildFire Submission results.
Background: Zero-day exploits and APTs are very serious cyberthreats. Palo Alto Networks WildFire provides cloud-based sample sandboxing and produces a verdict in a few minutes. Due to the nature of the Palo Alto Networks threat intelligence cloud, samples are submitted for analysis only if they are unique and have never before been analyzed by Wildfire. If you see a ‘malicious’ result from a submission, it means the host is not only infected, it’s infected with a piece of malware that’s never been seen before. This could indicate a targeted attack with a piece of malware specifically crafted to penetrate your organization. Response times in these situations are critical, especially considering that by the time you’ve received the verdict, the malware already has a several minute head start. The difference in immediate action versus opening a ticket and waiting for helpdesk or a SOC engineer to reach out could be the difference between a single infected host and an entire network of ransomware or cryptominers.
The goal of this automation is to take immediate action to quarantine the infected host, while also providing the user an indication of what’s going on and instructions to contact the IT helpdesk.
Note: While this submission is focused on what I know (Palo Alto Networks), the same process could be used to ingest logs from an endpoint solution, a SIEM correlation engine, or anything you want.
Here’s my flow chart:
• For any Wildfire submissions returned with a “benign” verdict, send an email notification and a slack alert to the SOC or security team responsible (just so they know a unique file has been detected).
• For any Wildfire submissions returned with a “grayware” verdict, send an email, a slack alert and open a medium-priority IT ticket for follow up to determine if any remediation is required.
• For any Wildfire submissions returned with a “malicious” verdict, send an email, a slack alert, open a critical-priority IT ticket and run the “quarantine” playbook on the infected workstation.
Here’s my lab topology:
In our scenario, Wildfire has returned a “malicious” verdict for a file downloaded 10 minutes ago by 192.168.1.100. Our playbook will effectively quarantine the host and redirect any HTTP/HTTPS requests to an internal server hosting a notification page informing the user of the infection.
Here’s how I configured the Palo Alto Networks firewall.
I’ve created a dynamic address group which will accept API calls to populate values without the need to log into the firewall or do any config changes or commits. This dynamic group is configured to populate any value containing the keyword “Quarantine” made with a valid API call.
Here is a tag I created as a keyword in PANOS (“Quarantine”):
From the incoming syslog message, we parse 3 values: type=wildfire, verdict=malicious, and the victim IP address. We extract the victim IP and make an API call to populate it into the quarantine group.
Here’s the API call I make to the firewall to populate the dynamic address group.
Essentially, this is saying “Add “192.168.1.100” to any dynamic groups configured to include the keyword “Quarantine” (ie, the “WF-Quarantine-Group” dynamic address group)”.
Here is the security policy I have already running on my firewall:
• Rule 1 permits the infected host to resolve DNS, as we need the infected workstation to be able to resolve an IP before it can make an HTTP/HTTPS request which we can intercept.
• Rule 2 permits the infected host to make HTTP/HTTPS requests, however, we will be 302 redirecting any requests made (see the authentication policy below) so they won’t be able to get anywhere other than our notification web server.
• Rule 3 denies all other traffic.
Here is the authentication policy:
• Rule 1 says if the infected host makes a tcp/80 or tcp/443 request to anywhere, redirect it.
Here is the captive portal config:
We are essentially saying “if the above authentication policy is hit, redirect the request to 172.16.0.2, where we have a simple web server hosting a page that says “Your workstation has been compromised and network access has been automatically restricted. Contact IT immediately to restore service.”
The final result is an automatically quarantined infection, critical alerts to the appropriate teams, and hopefully the end user is calling helpdesk for remediation before anyone in IT ever realize a ticket was opened.
