Forum Discussion
Issues with setting up AiTM phish prevention using conditional access
We are a managed IT company and AiTM phishes (the ones that reverse proxy the true sign in page and steal session cookies) have been everywhere. We've started experimenting with User-Risk and Sign-In risk policies, and what I thought we had set up made sense to me, but I was doing some more indepth testing and found that what I set up has been basically useless/harmful?
We have the basic conditional access environment:
MFA: MFA enforced for every sign in
Sign-In Risk: MFA Enforced for Risk Signing with Session Control "Every Time" for all levels of sign-in risk
User-Risk: Require password change for Medium/High Risk
My understanding was that particularly, the sign in risk policy, would apply an "Every Time" control to the session cookie, that way when it was stolen via a reverse-proxy, and re-imported to their browser it would request them to sign in again, because in my mind every time their session is reevaluated it should ask them to sign in. This document says to use this control when I want to reauthenticate everytime, which is what I want to have happen when the session has risk.
Issue is it looks like it doing in my environement instead:
- User signs in to reverse proxy link that was sent to them in a phish
- Microsoft sees that there is sign in risk, processes the Sign-In Risk conditional access policy
- Requires Grant Controls "MFA"
- Bad actor at this point would be given this authentication cookie
- Microsoft marks the Sign-in and its associated risk as Remediated because the user "passed mfa".
- Bad actor imports the session cookie to their browser
- Bad actor signs in fine and goes about their day ruining everyone elses
- These subsequent sign ins do not show up as "risky" because the risk associated with it was "remediated" -- which is talked about here
All I am trying to do is impose stringent session controls on these AiTM/reverse-proxy phishing and now I worry that I have been doing more harm than good because I basically set it to "remediate" the risk the very second it occurred.
Any help in pointing me in the right direction is greatly appreciated.
AlexShxW1 Hi Alex,
Register one the these methods:
Windows Hello for Business or FIDO2 Security Key or Azure AD CBA Certificate-Based Authentication (Multi-Factor)
Then you should choose Require Authentication Strength, and choose Phishing-resistant MFA.
As an alternative option, you may Require Hybrid Azure AD Joined Device or Require device to be marked as compliant (this will require Intune, and intune will use a certificate to authenticate the device).
Before creating a policy requiring phishing-resistant multifactor authentication, ensure your administrators have the appropriate methods registered. If you enable this policy without completing this step you risk locking yourself out of your tenant.Reference:
https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-strengths
https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-strengths- Tom-irpBrass ContributorThis is a good read
https://jeffreyappel.nl/aitm-mfa-phishing-attacks-in-combination-with-new-microsoft-protections-2023-edt/
Intune Compliance may be a way to go. Keep in mind that you can have different compliance policies and you determine what is compliant. Best to have the min than none. For example, you might want one for Windows AD Joined but if you have AD registered that are not hybrid joined, you may copy the joined policy and remove the score piece, that way you can get compliant faster. (AD registered will fail scoring-) You also don't want end users or hackers enrolling devices either, so block that. For compliance, set "non compliant immediately."
Same thing for phones, only Intune enrolled devices. (F3 licensing for mobile only users, under 10.9 inch screen, or Business Premium for office people will get you there)
Also, you may consider reading https://argonsys.com/microsoft-cloud/library/cloud-app-security-block-tor-browser-anonymous-ip/. This really is not as intuitive as it seems. To implement this I created a VM and used a user with other conditional access rules removed and signed in via Brave Browser's Tor mode to provoke the app to appear in Cloud Defender. This took me a few hours to get working. Let whomever monitors your stuff know alerts will come in during this process.