Proactive Phishing with Azure Sentinel — part 1
If you are a security professional in a large enterprise, you will be well versed with phishing attacks and the detrimental effects it can pose on your organisation.
A great way of tackling this problem is to use the ‘defence in depth’ methodology. This relies on you deploying multiple detections and mitigations for the different layers of the attack chain. This will include thinking about the opportunities to address phishing from user education all the way through to the point when the final payload attempts to execute.
But what if we could take a more proactive approach? In this first of two articles, I’ll give you a quick overview of using proactive threat hunting around themes and behaviours associated with emerging phishing campaigns.
TL;DR — using Microsoft 365 Threat Protection (MTP), Azure Sentinel & Logic Apps we will look to create a full end to end security orchestration, automation and response (SOAR) for dealing with phishing attacks via email.
This article will focus on threat hunting within MTP and then the integration with Azure Sentinel. The second article will focus on automated responses for high confidence phishing attacks, including submitting to organisations such as the NCSC using the Suspicious Email Reporting Service (SERS), we will also explore the use of automated actions on the device and/or identity.
Threat Hunting
If you are familiar with Microsoft Defender ATP (MDATP) or KQL in general, you will have a good understanding of the schema in MTP. MTP currently pulls signals from Office ATP, MDATP and Microsoft Cloud App Security (MCAS). This gives analysts the ability to hunt across signals from multiple alert providers and take actions against multiple entities. Centralising signals from multiple products into a signal schema provides opportunities for security analysts to become proactive in threat hunting. A great blog on the importance of proactive threat hunting is available here.
To start we will need to identify a trend/campaign that’s interesting, ensuring we capture enough data for analysts to investigate at a later stage. For this example, we will simply join two tables together and look for emails with more than 0 URLs, and emails that contain links to ‘docs.google’. We will then add some context around known events and senders within the organisation to help reduce alert fatigue.
EmailEvents| where UrlCount > 0| join (EmailUrlInfo| where Url contains "docs.google") on NetworkMessageId| project Subject, Url, SenderMailFromAddress, SenderFromAddress, SenderMailFromDomain, RecipientEmailAddress, Timestamp| order by Timestamp desc
Next, we need to get the results into Azure Sentinel. Now at the time of writing this blog, there was no documentation or connectors available to send data from MTP. So, with a little jiggery-pokery (basically viewing the HTTP headers) I found the endpoint for which these queries communicate with.
Endpoint;
Payload;
As we’ve now assembled our hunting dataset, we can move onto applying some logic and perform some automated actions.
Logic App
We can now build a Logic App to communicate with the endpoint and then finally run the query and fire the data to Azure Sentinel.
The Logic App we will use is simple but will require a few initial items to be set up. To authenticate and be able to run queries we will first need to register an application with Azure Active Directory (AAD). Once registered we will then give the Logic App permissions to read security alerts and ‘Run advanced queries', we will also need to ensure ‘Audience’ is set to “https://securitycenter.microsoft.com/mdp”. The following blog explains the steps required. Once you’ve received a bearer token, check the claims are correct with https://jwt.ms/, use the token from the threat hunting step as a reference.
Next, we will go through each step of the Logic App.
- Set a recurrence on how often you’d like to run the query against the endpoint
2. Gather some additional variables for building the HTTP request later
3a. Build the HTTP request part 1
use the previously gathered variables for the start and end times, the body and the headers will be the same as we saw from the HTTP headers in the threat hunting step
3b. HTTP request part 2
fill the authentication part of the request with details from the Application you registered against AAD
4. Next, we need to parse the payload, this can be done by simply uploading a sample payload to generate the schema
5. Finally, we send the results to Azure Sentinel
whatever you name the ‘Custom Log Name’ will be what we use to find the events in Azure Sentinel under ‘Custom Logs’.
Once the data starts to flow into Azure Sentinel you will want to create a function to parse the data further to ensure only the relevant fields and naming schemes you care about is available for the analyst to investigate, a great blog detailing how this is done is available here.
Response
The response will come in two forms, manually driven flow by analysts or via an automated flow by an additional Logic App. In this blog, we will focus on the manual flow, I will blog about an automated flow next time.
Within Azure Sentinel create a rule to trigger an incident whenever these events flow in from the Logic App. Ensure you map custom entities such as URL and Account. Set the lookback time to match with the query look back.
Once an alert triggers analysts can investigate and detonate the suspicious URLs within the portal. This will give analysts a single pane to understand and make decisions on whether this is a phishing attack or legitimate event.
Part 1 fin.
Hopefully, part 1 has given you a high-level overview and steer on some of the advance threat hunting capabilities which can enable SOC teams to become more proactive against potential email phishing attacks.
Next article I will demonstrate automated actions against high confidence phishing attacks.
