EvilProxy AiTM— Part 2 Detection

Adversary in the Middle using EvilProxy is growing as a Phishing threat, with its ability to steal MFA tokens it is fast becoming the only method to Phish.

This is a 2 part blog post – see part 1 for a walkthrough of the attack in my honey tenant:

https://medium.com/@martinconnarty/adversary-in-the-middle-part-1-walkthrough-2c91fb00197

Here are a few ideas I’ve developed. As always this will change as I learn more.

Your Tenant Image

Many of the Adversary in the Middle pages that I’ve observed utilise a feature which loads the background image of the victim’s tenant (if it exists of course!). As defenders, given we have access to the right type of logs (Web proxy logs with URLs and Referrers) we can do some detections!

An AiTM page will often pull in the image directly from authcdn (https://aadcdn.msauthimages.net/<unique_tenant_id>/logintenantbranding/0/illustration?ts=)

How do you find your tenant ID? Simply:

1. Go to say https://login.microsoftonline.com
2. Open developer tools (Ctrl+Shift+I)
3. Open the network tab:

4. Enter or select your email — this will cause the background to load:

5. Select the URL that you see for ‘illustration?ts…’ — right click and ‘Copy link address’

6. You should find it like something like:

https://aadcdn.msauthimages.net/52ksdjfklj-kdr3246598sgljsdlfk-j2-k287s84lsj3j/logintenantbranding/0/illustration?ts=638307426057595200

7. The unqiue tenant string (yes I’ve changed mine!) will be this bit:
“52ksdjfklj-kdr3246598sgljsdlfk-j2-k287s84lsj3j”

Mitigate first — Use an overlay on your background image

I would first suggest you use an overlay on your background image (set here: https://entra.microsoft.com/#view/Microsoft_AAD_UsersAndTenants/CompanyBrandingOverview.ReactView)

If you can get your users to check the URL every time they see a login page then it might stop a lot of these. Perhaps something like this:

Feel free to steal!

This leads to something like:

Looking for suspect referrers — for direct access

If we baseline the referrers in Web Proxy logs — we will often observe that they are usually legitimate, Microsoft pages such as https://login.microsoftonline.com/

If we see anything else, we should look into it/create a new rule.

| tstats `summariesonly` count from datamodel=Web where Web.url="https://aadcdn.msauthimages.net/<thisisyourtenantid>/logintenantbranding/0/illustration?*" AND NOT Web.http_referrer IN ("login.microsoftonline.com/*") by Web.user Web.http_referrer

Look for suspect requests — where it’s proxied

In one example of an AiTM page, instead of the victim’s browser reaching out directly to the image, the site visited it. However, we could see in the logs the same tenantid. This was unusual and something we could look for:

| tstats `summariesonly` count from datamodel=Web where Web.url="*<thisisyourtenantid>*" AND Web.dest!="aadcdn.msauthimages.net" by Web.user Web.dest Web.url

Note: With both of these, I would imagine future versions of AiTM kits will adapt accordingly and so the chase will continue. Ensuring users get in the habit of checking the URL bar is going to be far more robust.

Look for the requests in Azure Logs

This is a bit trickier, however in the examples I’ve seen, there’s often atypical applications or locations in the attempts. From what I’ve seen, they’re often multiple locations in a short span of time, and around the time of a phishing click.

TBD — Splunk rule to look for unusual spikes of locations for a user. Something like (note TBD!):

| index=azure category=SignInLogs | bucket span=5m | stats dc(src) as srccount by user _time | where srccount>5