Phishing attacks continue to be a major threat to organizations of all sizes, with cybercriminals becoming increasingly sophisticated in their methods. As a result, security teams are faced with the daunting task of investigating and responding to a growing number of phishing alerts. Fortunately, automation is emerging as a powerful tool to help these teams streamline their workflows, increase efficiency, and improve response times. By leveraging automation, security teams can rapidly investigate and remediate phishing attacks, reducing the risk of data breaches and other security incidents. In this blog post, we’ll explore how automation between a suite of Microsoft tools can be used to investigate and respond to phishing alerts.
In this example, we’re reviewing a suspicious email forwarded to the SOC by an employee. In the event overview, we can see the original email contained as a .eml file:
On ingestion, the original email content from the .eml file is extracted and uploaded to the event overview, shown below:
Other information, such as the recipient, sender, original attachment, and email header information are also extracted to be used in the investigation.
The Playbook
Using Office 365, Microsft Entra ID (Azure Active Directory), 365 Defender, Defender for Endpoint, Microsoft Sentinel, and Intune, we can collect information related to the recipient, sender, device, and file that will help us determine the right next steps.
From Entra ID, we can pull in the activity logs of the employee who reported the email. The playbook task compiles the category of action, the time it was taken, and the result (success or failure):
From Microsoft 365 Defender, we can search for other emails sent to this user. Here we’ve included the timestamp, sender email address, sender IPv4, recipient email address, subject line, and internet message ID:
As you can see, there are two other suspicious emails from the same sender. This tells us that a campaign is underway.
As mentioned above, the original email contained a file. The hash for this file can be used to search for other devices that may have received this email:
Here we can see the ID, DNS name, and last IP address for potentially affected devices:
Then, we can run a search in Microsoft Sentinel for any related security events. We’re looking for events within the last 24 hours from any computer returned by the query above:
Finally, we can look for the device’s compliance state in Microsoft Intune. In this case, the device has not violated any of our policies:
The Analysis
Now we’ll take a look at the data displayed in the incident overview. We’ll make inferences from it and decide how to proceed. First, we’ll take a look at the incident notes, which shows us a summary of the actions that have been completed by the playbook and what actions are outstanding. We can see that the triage process has been completed and that there are pending tasks waiting for review:
Additionally, within the incident notes, the email authentication results have been collected. Here we can see that the DKIM and SPF checks have passed:
Further down in the incident overview, we see the data collected by the incident playbook. From Microsft Entra ID (Azure Active Directory), we have information on the user and a list of recent activities including the action, time, and result. All of these actions look expected for the user, so we can’t conclude there is a sign of compromise:
To determine if this is a single email or part of a larger campaign, we search for other emails in 365 Defender and see two with similar subject lines. This means that this is likely a persistent threat.
Finally, we search Defender for Endpoint for other devices that may have received the email, and check Microsoft Sentinel for any Security Events related to these devices.
Remediation
Based on these results we can deduce that it is a campaign targeting one user. Since the email was forwarded to us and we aren’t seeing suspicious activity on the activity logs, we will not take any serious response actions like resetting the user’s account or device. Instead, we will delete the emails from their inbox and block the sender.
Conclusion
The playbook used six Microsoft tools to gather contextual information on a phishing alert, including user activity logs, related security events, and the affected device’s compliance state. This information is automatically collected and displayed to the analyst in under 60 seconds from when the incident is created in D3. Multiplied across the astronomical number of phishing alerts that teams regularly receive, this can save thousands of hours over the course of the year.
If you’re interested in other D3 Smart SOAR use cases, see our playbooks for Trojans and Remote File Downloads here:
