Looks like a good time for a thread on token theft :)
Not all MFA is of the same quality, and anything using OTP (SMS, hardware/software tokens) or Push (MS Authenticator, Duo, etc.) is susceptible to AITM attacks
That doesn't mean it's useless, but it's becoming less useful
Ideally, we want to move to phishing resistant authentication
In this category, Entra ID supports FIDO2 Security keys, Hello for Business, and Certificate Based Authentication. Microsoft Authenticator and passkeys are coming soon.
Let's start with Hello for Business!
Hello for Business is FIDO2 certified, and you can think of it as certificate based authentication with hardware attestation
In addition to being very secure, it's also a great user experience
For AD users, implement cloud Kerberos trust for on-prem SSO
Coming soon, we will have a similar experience on macOS - sign in to your Entra ID account with Touch ID at the logon screen, passwordless and phishing resistant
This leverages the Microsoft Enterprise SSO extension and Apple's new Platform SSO features
FIDO2 security keys are excellent as a primary or supplemental solution
They work just like Hello for Business with cloud trust for on-prem SSO
They are also supported on mobile and personal devices where other options might not work
The downside is cost and replacement
Due to PKI requirements, I recommend Hello/security keys over certificate based authentication for most, but it's still an excellent auth method
That covers user authentication options, but those all take time to plan and roll out
So what can we do right now? Glad you asked!
A good way to break AITM is to use device based authentication
When a device registers or joins Entra ID, it creates a certificate which is used to authenticate. This breaks AITM as the proxy can't answer that challenge.
Use require hybrid join, compliant, or filter for devices
Compliance is amazing because we can enforce a level of assurance on devices, and it helps reduce the number of policies we have to create per each platform
Also, be sure to block attackers from enrolling their own devices to work around your controls ;)
Finally, use policies that block based on location. Yes, attackers can spin up resources in your country, but they often don't... You can make fun of me for this, but it works 🤷♂️
Here's a similar thread I did that has some device side recommendations too:
I have a more comprehensive blog article I'm working on, but a few folks have asked about examples, so until then!
This will be KQL heavy because it's what I have and use, but this thread will have examples for both process execution as well as network telemetry for FW rules :)
// PowerShell execution (including renamed binaries) excluding SYSTEM, UPN per device
DeviceProcessEvents
| where InitiatingProcessAccountSid != @"S-1-5-18"
| where ProcessVersionInfoOriginalFileName == "PowerShell.EXE"
| summarize count()by InitiatingProcessAccountUpn,DeviceName
Some places may run PowerShell scripts as standard users to perform automation tasks (ex. shortcut creation), so it's important to audit before creating AppLocker policies
Say we can't prevent PowerShell as standard user, but we might be able to block network calls. Here's how.