Proactive Phishing with Azure Sentinel — part 2
In my earlier article, I talked through how to assemble the threat hunting dataset and how to push this data to Azure Sentinel using a Logic App. In this article, we will create an additional Logic App and utilise triggers from detection rules to perform an automated response.
Incident Trigger
Now we have our data within Azure Sentinel we will need to set up a trigger for the second Logic App. This will be done via a detection rule, a detailed article on how to set up detection rules can be found here, and we will focus on the Logic App triggers below.
- Set the timeframe and threshold you would like an incident to be created, using trends from recent attacks to help tweak the trigger, this will form the basis of when we start the Logic App. In the below example we search every hour for the last hours worth of data, we then trigger the Logic App if the threshold of alerts is higher than 50
2. Next, select the Logic App you want to run once this incident has been created, to be able to see your Logic App’s within this section, set the Azure Sentinel trigger from within the Logic App designer
Automation
- We will now run through the Logic App, the first part of this will be a trigger on the above incident creation
2. We then need to get information about the incident and the entities within that alert; this will allow us to extract the information needed and update the incident at a later stage
3. Now we rerun the original query. This is so we can get additional variables we will call upon later in the Logic App, look back at the first article for information on how we run the Microsoft 365 Threat Protection (MTP) query
4. Next, we will obtain a list of emails for the users that are listed in the alert. You can either use the app we registered in part 1 with Azure Active Directory (AAD) or create a new app specifically. As we want to parse the list you retrieve and get emails for a user will have to ensure these permissions have been applied to the app. In this example, we return 50 emails per user and hardcode the organisation details; the ‘Accounts Name’ will be extracted from the Azure Sentinel account entities
5. We can now loop through the emails and gain confidence we are only purging emails that we actually want to purge. We do this by taking the results from the original query (the MTP query) and compare with the emails from each users mailbox. We use two fields, ‘Internet Message ID’ & ‘Subject’, if both match we can be confident that we are only purging the phishing emails we wish too. The VirusTotal API can be used to determine if the URL is known to be malicious. The parsed results will allow us to determine which other actions are appropriate. We can also add an approval step if you wish for this to be semi-automated
6. At this point, we have a high degree of confidence that these emails are involved in a phishing attack and are safe to purge from the system. A nice additional step is to use the Suspicious Email Reporting Service (SERS) from the NCSC. SERS will independently analyse the emails and attempt to take down any associated phishing web sites. A similar service is also available from Microsoft. Permission for forwarding emails are within this Microsoft document
7. Next, we purge the email out of the users' mailbox, permissions to do this are detailed within this Microsoft document
8. Once that’s complete we can update the Azure Sentinel incident with comments and finally close the alert
Device & Identity
So far, in the above example, the automated actions have been focused on ensuring the phishing emails are removed out of users inboxes, hopefully before a user can interact with that email.
But that’s just an assumption and we should verify that.
The below will focus on two elements phishing emails try to exploit. The identity and the device. The identity is the user that’s been targetted by the phishing email, in the below we will use the AAD User Principle Name (UPN). The device in the below will be the physical or virtual end-user compute that the phishing email tried to execute on.
- First, we run the MTP threat hunting query again, but this time on the device events table and include the URL variable from the phishing email
We now know if the phishing email was delivered and if the end-user clicked on the link.
2. We then parse the results and take some key variables for the machine isolation step, this will utilise the Microsoft Defender ATP (MDATP) Logic App plugin
Similarly, we can use the same flow to disable the user account with AAD, this will use the Azure Sentinel account entities from earlier
Microsoft has a great repository of playbooks that can be used within your flows — I will also work to make the above Logic App available.
That’s a wrap! I hope these two articles have given some high-level insight into the capabilities available to security analysts, to help drive towards a more proactive and automated state within your SOC.
Until next time —
