One of the top 5 questions I regularly get is how to react on Alert/Incident XYZ in Defender. Today, I will investigate one specific use case:
With Microsoft 365 Defender, we not only know that a phishing link was received but also that the user clicked on it – however, what we do not know is: if the user provided his credentials to the shady site he clicked on.
How do we handle such alerts? Either we ask the user, if he provided the credentials or we assume he did and reset his password. I do not like any of these approaches, they seem way too ‘simpleminded’, since we have a lot of data we can analyze to come to the right conclusions.
Let us elaborate the scenarios:
As discussed, the user clicks on the link and provides his credentials. The attacker will catch the password and will use it (and the user’s UPN) to logon to e.g., Office 365.
If MFA for the user is enabled, then there will be an MFA prompt on the user’s device. If not, not.
Either way: we will see a successful or an unsuccessful login by the attacker sometime after. And this is one way, that we can use to get alerted and to conclude that the user has provided his credentials.
Note: timing is an issue here of course. Once the attacker has stolen the password, we do not know when he will use it. On the other hand: the chance that a user confirms an MFA prompt are better 'within context' - and the only time the attacker knows for sure the user is in the process of a logon process, is when he intercepts the password. With that we can conclude - and this is also my experience from real life - that the attacker will most likely try to use the password immediately.
The login attempt by the attacker will most likely differ from the baseline of user logins. Azure AD user risk state will The login attempt by the attacker will most likely differ from the baseline of user logins. Azure AD user risk state will help us to judge the logons straight after a click on a phishing link, but we also need some more data to get the whole picture:
This result table gives us an overview of people that clicked on phishing links in the past days. Therefore, we use the following query:
It also tells us about the RiskState of the user from Azure AD (none). Then it investigates all sign-ins of this user within 8 hours after he clicked on the phishing link.
In the “SignInAfterClickErrorCode” column, we get a summary of the AAD sign-in errors of the user in question for the 8 hours after the click on the phishing link. Here is a list of those error
You You can also try to export these codes into a gist and make a live lookup from KQL like I did here.
Now, let us have a look at the next two columns:
Each user can appear in multiple lines in this results table. Either because he logged in from multiple countries in the 8 hours after the click, or because he logged in (or tried to) from different devices.
The “logonDistributionByCountry” column counts the logon distribution of the user by country over the last 30 days. With that we get a good overview, from which countries the user normally signs in. This can be achieved with the following KQL query:
The last three columns give us information about the devices, the user used during logon within the 8 hours after the click (Device column) and compares it to the devices, the user normally logs on from (logonDistributionByDevice), including the count() of SignIns:
For the logonDistributionByDevice, the query hasFor the logonDistributionByDevice, the query has only to be adjusted slightly:
Now we must bring all the information together:
All of the KQL can be found here: https://github.com/jangeisbauer/AdvancedHunting/tree/master/Phish%20Hunting
As you can see, the query is filtering for non-AAD-joined devices and for sign-ins within 8 hours after the click event.
With these results, we get a good impression if the user provided the credentials, and the attacker was able to sign-in.
Next, we can hunt for additional Alerts from the involved Users and Devices:
Again, those queries are looking for phishing click events and then searching for associated alerts for the involved users and devices.
I hope you liked this article and learned something about the possibilities around hunting for phish or at least got some inspiration. If you have additional ideas on how to hunt for phish – let me know 🙂
If you are interested in frequency analysis of phishing URLs check Mehmet’s blog over here.
Also, if you think about how to make the users aware that they are providing credentials to a not trustworthy site – this article might be interesting for you too: https://emptydc.com/2021/06/22/pink-thumb