After some discussions with peers from other organizations, I was surprised by the lack of automation and end-to-end process for managing phishing incidents. So, without much preamble, let’s jump in to what an IR playbook would look like that relies heavily on automation.
Scenario:
Acme runs their email on the cloud (eg: O365) and already has an anti-phishing filter service deployed that effectively blocks most phishing as well as spam emails. For emails that do get past these filters, Acme has deployed a button on their corporate email client that allows employees to report emails that appear suspicious. The button packages the suspicious email it as an attachment is an email to a central mailbox that is monitored by the IR Team. It also sends the reported email to the Deleted Items folder, or the Junk Folder.
Other security tools at your disposal
- Demisto for SOAR
- McAfee AV for Endpoint Protection
- Defender ATP for EDR
As the head of IR Team, you are tasked with creating the end-to-end response place for phishing emails.You are also asked to deploy automation as part of this incident response plan with the goal of reducing manual effort and the response time for a small IR Team.
Overview:
The playbook kicks off with a suspicious email that has been reported in by an Employee. Remember that this is an email that made it past your enterprise spam and phishing filter. As shown below, the blue boxes represent automation actions, orange denotes employee actions, green indicates IR team actions and the white box is an action by a system.
The first sub-process that kicks in is Email Classification. For brevity’s sake, I will link the Email Classification sub-process to a new article and focus on the parts after. Once the Email has been classified as either Genuine or Spam, the automation engine can respond back to the Employee using a pre-built email template (one that provides generic guidance, some tips to identify malicious emails and possibly a section to include analysis comments). The real action starts when an email is identified as malicious.
The playbook branches into two parallel paths. One is a mostly manual sub-process to Check for Spear-Phishing campaign (since this is an involved topic, this will also be a separate article). The other branches off to two automated sub-processes for Contain URL clicks and Contain malicious File. Note that while the flowchart depicts them as either/or based on decision of the threat vector, it’s possible for an email to contain both, in which case both sub-processes would need to be kicked off.
Contain URL clicks sub-process
This sub-process will rely on integrations with the following systems
- Proxy Server
- O365 ATP for Safelinks (URL report)
- Defender ATP
- Threat Intel
These integrations cover all users who may have clicked the bad URL over the corporate network, as well as outside the corporate network via the mail-server (OWA)and the end-user computer.
In addition, a parallel branch identifies if there are malicious files associated with the URL. At this point, you may decide to check the connection status of the URL before initiating the sub-process of malicious files. However, since this is an automation, the cost of running a check on the presence of associated malicious files should be low even before a verified connection to the URL is determined.
From the integrated log sources, it should be easy to check if there are any instances of a successful connection to the URL/Domain. If all attempts were blocked, the automation engine moves on. If not, the automation engine can compile the list of users/machines who may have potentially clicked on the URL. Once the scope of machines is defined, gather any malware/EDR alerts for that machine within the URL click time-frame to be reviewed by an analyst and also the sign-on logs for the users. In parallel initiate a full scan on the machines.
Contain malicious File
This sub-process is very similar to the sub-process above in principle. The goal is to identify presence of the files associated with a phishing email in your organization. At the same time, Threat Intel integration enables checking for any URLs/Domains associated with the malicious file, triggering off the Contain URL clicks sub-process to check for any connections.
The automation engine uses McAfee and Defender ATP to check for presence of the file on end-user computers. If all execution attempts were blocked, the automation engine can move on. Otherwise, similar to the process above
- Check for other alerts from McAfee AV and D-ATP for the given list of machines
- Check proxy logs for connections to bad URLs/Domain.
Both the sub-processes should yield data enriched reports for analysts to be able to take quick decisions on further actions required. It’s important to realize that not only is Phishing a constantly changing and and ongoing problem, but that users and machines which have been found to be compromised before are at a high risk of falling prey to phishing again. They need to be added to a list of high risk user/machine list. Hence, the last part of the playbook deals with repeated infection:
- If the user/machine was not previously on a high risk list, then add the user/machine to the list for the next 30–45 days. Users/machines should be removed from this list after a 30–45 day expiration period.
- If the machine was previously in the high risk list, the machine should be re-imaged. A re-imaged machine continues to be on high risk list till the expiration period.
- If the user was previously in the high risk list, reset the password. And where applicable, sign-up the user for security awareness training.
All these steps look complex and time-consuming, but in reality, with an automation engine like Demisto, all these steps can be kicked of and completed within 10–20 minutes. Multiple IR processes can run in parallel, with the end result being that the Analyst gets a rich report to take informed decision on the path forward.
