Phishing and Malspam IRP

And How to Automate It

Phishing is to this day still the most common method of attack pattern utilized by threat actors of all kinds, and even increased 11% according the Verizon’s 2021 Data Breach Investigations Report. They attribute the activity of course to the COVID-19 lockdowns that occurred worldwide, sending us into the home offices many still inhabit to this day.

In every SOC I’ve worked in and conversed with, phishing has always been, quite frankly, a pain in the ass. In my current role as a systems engineer that works with SOAR technologies, it is clear how imperative we get Phishing response right so we don’t have to deal with it anymore when it comes time for one of our users to click on the link.

I prepared this process about a year ago for a Fortune 500 organization I worked with who were starting fresh (new team, new SOC, brand new tools), and wanted to share this out to the public at large to help the adoption and understand of just how to approach phishing at a broad level, that should work for many organizations.

So, let’s begin…

Defining The Incident Response Process

To keep things straight forward, I’m going to be using the SAN’s Incident Response Process (IRP). If you want to understand my opinion on using it over any other, you can read about it here.

1. Preparation

2. Identification

3. Containment

4. Eradication

5. Recovery

6. Lessons Learned

Phase 1: Preparation

Preparation is the action of compiling a list of assets and stakeholders that are involved in the IRP. We should be specific if the risk tolerance allows for a distinction between what I have called Inactive Phishing (phishing that occurs normally and uncontrollably; in a fashion that users do not interact with and poses no immediate risk) and Active Phishing (an imminent threat posed when a user or users interact with a phishing email). If so, this designates two levels of response depending on the results of us triaging the sample.

There also must be a standard method of communication in which who should be contacted in the event of Phishing. This can include a reporting user, users who are identified as part of the incident through triage, the SOC, and any stakeholders or those who are responsible for remediation actions, especially if your SOC is compartmentalized from certain functions (email admins needed to delete emails, firewall engineers implement blocks, etc).

Phase 2: Identification

Identification of a phishing incident usually occurs when a user reports an email to the dedicated email inbox in which the SOC can then review and triage to determine if the email is in fact a phishing attempt. There are also standard prevention and detection mechanisms that can find phishing such as O365 and Gmail Suite providing spam protection and quarantine features, or in-line email firewalls such as IronPort. These can either be set to alert or send an email to the monitored inbox for processing, remediation, or release.

Identification should be relegated to the appropriate analysts, and an incident should be declared based upon the facts of the case and whether or not, as stated earlier, there is a differentiation between active and inactive phishing.

Through analysis, the analyst should determine the scope of the incident by investigating how many users were targeted with the email in question. There should be due diligence when investigating mutators to a phishing email. Mutators are shifts in indicators of compromise (IOC’s) that circumvent static detection and prevention mechanisms by making changes to the IOC’s. These mutators can occur with the sender, the subject line, the body of the email, and the return address. All of these factors can be mutated in some way to avoid detection while still having effects on the target.

Phase 3: Containment

Containment on phishing occurs in two parts:

• Part 1: Neutralize the threat actor’s ability to send emails. This is easier said than done, and requires tracking of the threat actor’s email IOC’s. Once a list is obtained, the process of preventing further emails from entering the environment can prevent the spread. There is a chance that this is an impossible task, as a clever actor will simply randomly generate subject lines, bodies, and sender details to prevent blocking of their attack. This is very popular with Sextortion Email Campaigns. The best tactic against this kind of threat is vigilance, and blocking of unique, unused Unicode characters to have a chance to block outliers, and a strong Phishing Training that emphasizes users contact the SOC over these kinds of incidents.

• Part 2: Neutralize the threat actor’s ability to have users detonate a file or click the link. This is an easier method to handle compared to part 1, as all it requires is the analysis of the IOC’s within the email to determine where the phishing link goes to (an IP address or domain name), while blocking the file requires action on part of the existing endpoint protection platform (EPP), endpoint detection and response (EDR) platform, or extended detection and response platform (XDR). If there’s nothing to detonate in the email (link or file), chances are it was either stripped by your email firewall or the attacker didn’t run their script right.

If a user or host is found to be compromised in the process of investigating, the analyst should pivot from a phishing process to a compromise of information process in which the host is quarantined and the user’s account is locked to prevent further action until it is determined what kind of compromise occurred.

Beware the Containment lag time, which is the time between when an incident is identified and containment is in place. With phishing, there is a window in which more users can receive the email after the scope of the incident is adjudicated but containment is not implemented. A secondary sweep should be considered after containment is implemented to ensure no further emails were able to enter the environment. You can also leverage War-Room type dashboards and reporting built on the fly to insert IOC’s into a feed to give you real time analytics on developments and prorogation. These are easily configured in SIEM and SOAR tools, even some XDR tools as well. Senior SOC team members should consider making a ‘Template’ Dashboard that analysts have the ability to duplicate then drop IOC’s into for that specific incident, or an incident layout that provides these kinds of feeds to visualize the attack overtime (which it’s fun to watch the actor’s emails getting dropped after containment is in play).

Phase 4: Eradication

Eradicating phishing is as simple as destroying the emails in question. This step can be done by just simply advising users to delete the email in the inbox, reaching out to the email admin to remove them, or setting up an automated process in which the emails are purged from the environment automatically.

Extra considerations should be added when malicious email attachments are present, as they can be downloaded to a host and will be required to be remediated as well (for example, Outlook will download these files from the email service and store them as .TMP files which can be unpacked into whatever format the file is). An EPP/EDR/XDR tool should assist in the ability to scan for and purge these files from hosts, as well as determine if there was execution. If execution is determined to have occurred, the file should be analyzed and processed to determine its functionality in order to apply an appropriate response and remediation to the host, including and up-to reprovisioning or destroying the host. At this point, if the file detonated, they’re likely in, and you need to get them out. If the attacker did this all in an automated fashion, you may get lucky before they realized they’ve popped a user, so you want to quarantine that host as soon as possible and kick that user.

Phase 5: Recovery

Users involved in interacting with the email and compromising accounts and machines should go through a process to recover their accounts and be advised on measures to be given loaner devices, if needed and the original machines are required to be vetted before being recommissioned. In addition, users should undergo remedial training to understand combating the risks of phishing in the future. To be honest, based off conversations with some researchers during one of my university programs, they found that retraining is usually only about 50% effective on ensuring they don’t click again, so take that with a grain of salt.

Hosts determined to have had execution should be restored from backups, reprovisioned, or destroyed and a new unit issued to the user (this is all based on risk tolerance established by the organization, or it may be based on an analysis of how far/deep the malware established itself on the host).

Phase 6: Lessons Learned

While phishing will likely be the most routine incident in any environment, it is still important to derive any additional lessons learned and make refinements to the process as it continues to be implemented. Things to consider should be:

• Is our response process effective still?

• Is anything causing a bottleneck in our response?

• Are we still communicating to the appropriate stakeholders?

• Are there phases of the IRP that are not performing to their fullest potential?

• Do we still have the appropriate permissions, authority, resources, tools, and visibility to tackle these incidents?

• Summarizing our people, processes, and technologies, what should be sustained, what should be removed, and what should be improved?

Automating with SOAR

The ability to automate phishing analysis along with IOC enrichment can save valuable time in the initial triage and investigation of emails. Walking through the process again, we can cover how SOAR will automate and tackle phishing in the form of milestones and how it can adopt and automate over time as the process is refined.

Milestone 1: Implementation and Introduction

In order to begin writing playbooks and automating your security operations, SOAR should be implemented and introduced to the environment and to the team that will be working with it. There will be a process to configure the installation and integrations, along with having an introduction session with the team who will be operating the SOAR tool. This will assist in operators getting comfortable with performing activities and daily operations inside the platform, which will assist in the development of not only Phishing playbooks but others as well.

Milestone 2: Prepare and Identify Malice

In the preparation phase, this will be the phase that the playbook for phishing is established. Stakeholders will define the process in which they are comfortable with how phishing should be automated, either in whole or in part, and then have their technical point-of-contact implement the playbook and test its functionality for live deployment.

In identification, SOAR will have an inbox established in which it will monitor for email submissions from users who have suspected phishing emails to submit or plug in additional tools to email detection and prevention services/devices that will alert and execute the playbook in the same fashion. SOAR will then conduct an extraction of all indicators it can locate, such as IP addresses, URL’s, hashes, etc. Then, SOAR will enrich the data and check for known malicious indicators. This process can be started simply with an API key to a resource such as VirusTotal, but further data can be added with the integration of other feeds as well to manage IOC’s and their risk scoring (whether we use SOAR to manage our IOC’s or we plugin a third party TIM/TIP).

If no malicious detections occurred, SOAR can be instructed to check further with things such as domain distance for proximity to known malicious domains, run the file in a sandbox, verify the hostname URL is correct, and if all else confirms the email is benign, it can inform the sender that it is safe to interact with, or, it can alert an analyst for manual investigation to provide further confirmation.

If the email does contain hits on malicious indicators, SOAR can generate a report and alert an analyst that malicious indicators are present in the email. The routine testing and refinement of this process will continue until the stakeholders are comfortable with SOAR being able to handle the identification of malicious emails with a low false positive/negative rate.

Milestone 3: Identify Scope

In this milestone, an extension of the identify phase is conducted, which improves upon SOAR’s ability to identify the scope of the incident. This is done by taking the original email and its indicators and searching the IOC’s in the environment for propagation.

This milestone requires tie-ins to the email service and the EPP to check for both the existence of emails and malicious files. SOAR can be automated to take the information it extracted and enriched and feed it to the appropriate tool or service in order to search for the IOC’s further. This allows scope to be established and determine if any additional users were targeted by the email.

At this stage, this process would be rolled into the original report, which now provides the full scope of the incident in question, and an alert that would be sent to analysts to conduct the remediation of the email.

Beyond Detection and Analysis

SOAR can go beyond the ability to just detect and analyze phishing, and could also automate the entire IRP. Below are bonus milestones that can be conducted in order to further automate the phishing process in your enterprise. These milestones would require further integration and access with devices such as the EPP, email platform, firewalls, and more.

Bonus Milestone 1: Contain

In the containment phase, SOAR can be instructed to send an email to the user to confirm the malicious email and to not interact with it. Next, it can then be instructed to automate the process in which IOC’s are blocked by adding them to distributed IOC block lists that security appliances such as firewalls, web proxies, EPP, and email security devices can update from, where possible. If the lists cannot be automatically extracted from, an alert can be sent to analysts to conduct manual blocking procedures on the IOC’s.

In addition, SOAR can automate the process of locking any user account that is identified to have web traffic matching that of a malicious URL, indicating they may have given their credentials to the threat actor. In this case, anywhere a user did go to the malicious URL, that user can have their account disabled until a password reset is conducted.

Finally, where there is identification of a malicious file on a host, SOAR can automate the process to quarantine the host until an investigation can be conducted to determine if the host has been compromised.

Adding these additional steps to the playbook would flesh out the automation of the containment phase, at which point once containment is performed, a report is generated for analysts to review and conduct further eradication and recovery.

Bonus Milestone 2: Eradicate

In the Eradication phase, SOAR will take all known instances of the email that it identified in the identification phase and automatically delete them, or advise an analyst that they exist and require manual purging from the environment. In addition, if there is a malicious attachment involved, you can use SOAR to automate the process of locating and purging the file across the enterprise by integrating your EPP.

Bonus Milestone 3: Recover and Review

In the recovery phase, users involved with interacting with the malicious URL can receive an email from SOAR to reset their credentials.

Finally, if all of the IRP is automated, SOAR can generate an Incident Summary report and submit it for review and to have lessons learned conducted by the senior team members and leadership to determine if the actions performed were effective and satisfactory to the organization’s goals regarding security incident remediation.

Takeaways

SOAR is both a very easy concept but a complicated technology. With that in mind, it’s easy to get caught up in all the ideas to automate anything and everything, but the best approach in my experience tends to circle around already built processes that humans perform end-to-end with little to no errors, then allowing SOAR to repeat those steps in the same manner to provide the same output. This saves time, resources, and circumvents a lot of the frustrations that come with change management.

In tandem with SOAR, phishing can be reduce to more than a few reviews a day, rather than hundreds of inundated alerts plastering analysts and reducing their available hours to perform actual analysis and leveraging critical skillsets that analysts should be doing.