I've had a couple people ask me for some quick tips about responding to an Adversary-in-the-Middle (AITM) successful phish.

Let's make a thread!

PS: Put your pitchforks away. This is to help the orgs that don't have dedicated security pros on staff. Perfectionists UNwelcome! Once the AITM phish has been identified as successful, here's some things you'll want to look at:

1. Signin logs with interactive and non-interactive. If you are a small org, you might not be forwarding them to a SIEM. Download them as far back as you can go.

🧵Let's talk about Illicit Consents - noth internal and external.

Microsoft link can be found here:

I've been calling it "implicit consent" attacks when it's "illicit consent". Oops.

It's important to remember that these attacks can occur internally as well, not just externally. Also, the docs need to be updated. If you are only looking for IsAdminConsent set to True, you risk missing persistence and internal illicit consent attacks using delegated graph API permissions not requiring admin consent on app registrations.

Microsoft also points out how tedious IR is - all the more reason to disable non-admin users ability to create app registrations and consent to most delegated Graph API permissions.

When remediating these attacks, Microsoft points out that "resetting passwords for breached accounts or requiring Multi-Factor Authentication (MFA) on accounts, are not effective against this type of attack". You have to revoke the permissions. Please remember: this type of attack is an MFA bypass.

Microsoft currently recommends using this script to dump all OAuth consent grants and all OAuth apps for all users: https://gist[.]github[.]com/psignoret/41793f8c6211d2df5051d77ca3728c09

What does IR and remediation entail according to Microsoft?

1. Confirm the attack.
This is where it starts to get really hairy:learn.microsoft.com/en-us/microsof… 2. Inventory apps with access to your organization. This entails going through EVERY USER'S APPLICATIONS.

Microsoft suggests having every potentially compromised user to browse to and confirm all their apps. Thankfully, the powershell script is supposed to work here, pheww.myapps.microsoft.com

This tweet is not about Midnight Blizzard. I have no idea what happened at Microsoft. However, I want to take another moment to discuss Graph Delegated Permissions not requiring admin consent in app registrations. The reason this is important is because adversaries have been known to create persistence with these apps, and if you have legacy protocols enabled, they may be able to do more than you want. Also, creating app registrations allows for internal implicit consent attacks for lateral movement and compromise of additional users.

The default configuration of MS-Cloud tenants allow any Member to create app registrations. Moreover, here is a series of screenshots of Graph delegated permissions which do not require admin consent:

First, I want to compliment @Microsoft for being forthright with details. Some of the problems I see in this report, I SEE EVERYWHERE due to VULNERABLE DEFAULTS.

Let's start with creating malicious OAuth applications. By default, ANY USER can create app registrations and consent to Graph permissions as well as sharing 3rd party company data. In tenants where this is hardened, ability to create app registrations require Application Administrator or Cloud-Application Administrator and admins must consent to permissions used by the application whether local or from another tenant. Uncheck this box

What are your most reliable *domain* privilege escalations?

I'll go first:

1. ADCS abuse
2. Over-privileged SCCM NAA account
3. NTLMv1 downgrade I'm surprised nobody has said path hijacks yet 😄

🧵Some of my favorite LDAP queries. I let you all infer which tools to use them with. Most of these are from places around the web, nothing new. Just a list.

1. Find all DCs:
(&(objectCategory=Computer)(userAccountControl:1.2.840.113556.1.4.803:=8192)) 2. Find all Domain Computers:
(objectCategory=Computer)

3. Passwords Don't Expire:
(&(objectClass=User)(objectCategory=Person)(userAccountControl:1.2.840.113556.1.4.803:=56636)(!(userAccountControl:1.2.840.11356.1.4.803:=2)))