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
Go here and check ALL your app registrations and associated permissions. Make sure you know what they are!
CHANGE THESE!
And FFS, ALL ADMINS SHOULD HAVE PHISHING RESISTANT MFA!
Also, stop signing in from unmanaged devices with privileged accounts! You check private email or browse to a sight and get hacked, attacker gains access to your admin tokens and tenant! Use a dedicated secured device to access your MS Cloud as an admin.
And start doing governance! Yes, I'm talking to you @Microsoft - who has a governance product line. Use the software you create!
And if you don't believe me that these attacks are common and not just Cozy Bear, you really should check out @AlteredSecurity 's CARTP and CARTE classes.
Make sure users can request admin consent!
@cnotin @Microsoft There's too many different configurations and ways that could have happened that I dint want to make anymore assumptions. That's why I chose to talk about creating an OAuth app.
@NickCerny @inversecos Mostly.
@cnotin @Microsoft I don't need to 'spalined over and over and over again. Sigh
@cnotin @Microsoft I'm talking about a persistence mechanism is see on almost all IR engagements
@cnotin @Microsoft Maybe people should open their minds more instead of always "correcting me" and maybe they will learn more.
@cnotin @Microsoft This is ALSO why I highlighted EXACTLY WHAT I'M TALKING ABOUT so when the 'splainers showed up, they can reference the VERY FIRST PIC on the thread
@cnotin @Microsoft This thread is not a post-mortum. It's simply to supply quick tips to mitigate app registrations by low privileged users for persistence. That is all. The Graph permissions I'm discussing are clearly delegated but here is a screen shot for hthose not familiar:
@NathanMcNulty @cnotin @Microsoft
• • •
Missing some Tweet in this thread? You can try to
force a refresh
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.
2. Download the Unified Audit logs in . This is where we are going to find out what the attacker did i. Outlook, Teams, SharePoint, OneDrive, Power Automate, etc. Get everything for the compromised user..compliance.microsoft.com
🧵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?
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
3. Determine the scope of the attack. This is ALSO hairy. Why? Think about shared mailboxes and geolocation auditing limitations. You have to configure shared mailboxes to not allow users to login directly to the shared mailbox. How many orgs do you think do that? We all love defaults and expect some security from them, right?
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:
@n00py1 While you are not seeing over-priv'd SCCM NAA, I'm not seeing crackable passwords with kerberos which I didn't expect as everyone tells me it is still very much a thing. I see ESC1 and ESC8 almost every time too.
🧵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)