IAMERICA Profile picture
Freelance Security Consultant: AD, MS Cloud, Purple Team, EDR, Initial Access. Your perception is not my reality.
Feb 3 5 tweets 3 min read
🧵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…Image 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.comImage
Feb 3 11 tweets 3 min read
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:Image Image
Jan 26 16 tweets 3 min read
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.Image Uncheck this box Image
Jul 25, 2023 5 tweets 1 min read
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 😄
Mar 21, 2023 9 tweets 1 min read
🧵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)))