blacklanternsecurity
Feature Request - Additional auth mechanism
Playing with some other tooling recently ( https://github.com/dirkjanm/ROADtools ) I noticed that my account does not require MFA due to conditional access policies when logging in via a 'device code' page. A bit of an edge case, but still.
Is there something you could do to integrate this functionality into the tool as well? The current user enumeration methods all show MFA being enforced for the user but technically that's not correct.
Whether or not MFA is enabled is determined from the error code returned after an auth attempt, e.g. AADSTS50076. If your account is returning a unique error code that's not currently being accounted for, we can definitely add it.
When you run trevorspray against your account with a correct password, what output do you get?
So this is the output from when it's trying the password side of things and attempting to bypass MFA.
[INFO] Wrote 7 domains to /home/user/.trevorspray/loot/recon_example.com_other_tenant_domains.txt
[INFO] Checking OneDrive instances
[SUCC] Tenant "TENNANCY365" confirmed via OneDrive: https://TENNANCY365-my.sharepoint.com/personal/TESTUSER_TENNANCY_example_com/_layouts/15/onedrive.aspx
[SUCC] Tenant "TENNANCY365" confirmed via OneDrive: https://TENNANCY365-my.sharepoint.com/personal/TESTUSER_TENNANCY_example_com/_layouts/15/onedrive.aspx
[INFO] Enumerating 1 users against https://{tenantname}-my.sharepoint.com/personal/{username}_{domain}/_layouts/15/onedrive.aspx at Sat Feb 22 08:58:11 2025
[INFO] Using domain "example.com" (export TREVOR_domain=<domain> to override)
[INFO] Using tenantname "TENNANCY365" (export TREVOR_tenantname=<tenantname> to override)
[VERB] Waiting for proxy threads to finish
[WARN] [email protected] - Confirmed valid user via OneDrive! (Response code "302")
[INFO] Enumerated 1 valid users against https://{tenantname}-my.sharepoint.com/personal/{username}_{domain}/_layouts/15/onedrive.aspx at Sat Feb 22 08:58:13 2025
[INFO] Spraying 1 users * 1 passwords against https://login.microsoft.com/common/oauth2/token at Sat Feb 22 08:58:13 2025
[VERB] Waiting for proxy threads to finish
[SUCC] [email protected]:PASSWORD - AADSTS50131: Correct password but login was blocked.
[INFO] Running loot module: MSOLLooter
[INFO] Testing IMAP4 MFA bypass for [email protected]
[WARN] IMAP MFA bypass failed for [email protected]: b'LOGIN failed.'
[INFO] Testing SMTP MFA bypass for [email protected]
[VERB] Waiting for proxy threads to finish
[VERB] Waiting for proxy threads to finish
[VERB] Waiting for proxy threads to finish
[WARN] SMTP MFA bypass failed for [email protected]: Connection unexpectedly closed: The read operation timed out
[VERB] Waiting for proxy threads to finish
[VERB] Waiting for proxy threads to finish
[WARN] SMTP MFA bypass failed for [email protected]: Connection unexpectedly closed: The read operation timed out
[INFO] Testing POP3 MFA bypass for [email protected]
[WARN] POP3 MFA bypass failed for [email protected]: b'-ERR Logon failure: unknown user name or bad password.'
[INFO] Testing Exchange Web Services (EWS) MFA bypass for [email protected] (https://outlook.office365.com/EWS/Exchange.asmx)
[VERB] Waiting for proxy threads to finish
[WARN] EWS test failed for [email protected]: Invalid credentials for https://outlook.office365.com/EWS/Exchange.asmx
[INFO] Testing Exchange ActiveSync (EAS) MFA bypass for [email protected]
[INFO] Testing Exchange Online Powershell (EXO) MFA bypass for [email protected]
[INFO] Testing Autodiscover MFA bypass for [email protected]
[INFO] Testing Offline Address Book (OAB) MFA bypass for [email protected]
[WARN] No OAB URL found for [email protected].
[INFO] Testing Azure management for [email protected]
[SUCC] [email protected] can authenticate to the Azure Service Management API - AADSTS50076: The response indicates MFA (Microsoft) is in use.
[WARN] Azure management not enabled for [email protected].
[INFO] Testing Unified Messaging (UM) MFA bypass for [email protected]
[INFO] Finished spraying 2 users against https://login.microsoft.com/common/oauth2/token at Sat Feb 22 08:58:27 2025
[SUCC] [email protected]:PASSWORD
[INFO] 2 valid users written to /home/user/.trevorspray/existent_users.txt
[INFO] 1 valid user/pass combos written to /home/user/.trevorspray/valid_logins.txt
As you can see, it doesn't seem to find any ways through. But, if I manually open a browser and go to microsoft.com/device login with a code generated from ROADTools, it appears the MFA requirements no longer apply. I'm assuming that this is a CAP thing, but it'd be great to have this page also tested when a valid login is detected.
Heck, if you can merge the functionality of RoadTools to mint a PRT for use when a valid login is hit, that'd be even more amazing....
Interesting. Yeah I think that would be a super useful feature. FYSA @aconite33
@infosecconsultant did you verify that when you visited the Device Code page you were doing it in an Incognito window and not an already established session? Want to verify it's being done with a browser that has not authenticated before and does not have an already established session.
@aconite33
Yeah, I did. I've also noticed that I don't need to use the 'device code' page.
If I log in with roadrecon auth -u <[email protected]> and -p <password>
That works just fine as well without any MFA requirements.
Looking at 'My Sign-Ins' in https://mysignins.microsoft.com/ it's showing it as an 'App' Sign-in with the 'App' being Azure Active Directory PowerShell.
@infosecconsultant So I had a bit of time to play with this. I've noticed that in our tenant, we have required MFA enforcement.
However, I have played with it in another tenants and it wasn't. So I don't think it's a black or white configuration. There has to be some configuration that is impacting this configuration if it will let us authenticate or not. I want to do some more investigation in figuring out exactly what setting is allowing this or enforcing MFA.
@aconite33 Thanks for the update. In the environment I noticed this in, the client tenancy had MFA enforced for all the mechanisms that TREVORSpray uses to check if it can log in. However, the tenancy had also configured a MFA bypass in the conditional access policies for logging in via the device code login flow and via the application login flow. That appears to have been an accident on their behalf, but given that it allowed a full MFA bypass, it think it's an authentication case worth testing.
It's also good to note if device code logins are allowed in the first place as they are proving to be very effective phishing mechanisms these days.
CAPS's are definitely the cause of the different authentication flows, but my goal in opening this request was to ensure that TREVORSpray could test valid creds against these endpoints to determine if there is any CAPS misconfiguration that can be leveraged.
Cheers,
Just an update on this, talking to DirkJan he tells me that the auth command normally uses the 'resource owner password credentials (ROPC)' grant: https://learn.microsoft.com/en-us/entra/identity-platform/v2-oauth-ropc
It seems that it only works if there is no MFA requirement so having a CAP that properly enforces MFA would block it. It sounds like my client has MFA only for office 365 instead of all resources.