Chad Secures

I secure Microsoft clouds for a living. Just sharing what I see in real tenants: Entra, Zero Trust, M365, Azure. Husband, dad of 3, lake guy.

[Chad Secures @ChadSecures]

I've spent years securing M365 Tenants and Azure for real companies.

Most breaches I see don't come from fancy hacks. They come from a sign-in policy someone forgot, an admin account with no MFA, or a guest user that wasn't removed.

So, I'm going to start sharing what I actually find in real tenants: Entra, Conditional Access, Zero Trust, and the fixes that matter and make an actual impact.

No fluff, no vendor pitch. Follow along if you run IT or security for a company that uses Microsoft tools.

[Chad Secures @ChadSecures]

What I'd check in your tenant today after this week's Entra service principal campaign:

1. Entra admin center > App registrations > All applications. Note every app that has a client secret.
2. Any secret with no named owner gets one or gets deleted.
3. Sign-in logs > Service principal sign-ins, last 7 days. Look for a failed secret (AADSTS7000215 or 7000222) followed by a success from the same app.
4. Move what you can to a certificate or managed identity.
5. Deleting a secret doesn't kill tokens already issued. Revoke those too.

More on how I work through tenants is in my pinned post.

[Chad Secures @ChadSecures]

@CagJ201 @AzureSupport With no other admin in the tenant, Microsoft support is the only way back in, so keep pushing that ticket. For next time: one break-glass account excluded from every CA policy, and build new policies in report-only first.

[Chad Secures @ChadSecures]

@sankar2704 The sponsor is the part I'd push hardest on. Same lesson as the service principal campaign this week: identities with no named owner are the ones still holding old secrets.

[Chad Secures @ChadSecures]

@The_Cyber_News The part admins miss: user Conditional Access never sees these sign-ins. Pull the list of app registrations with client secrets today and ask who owns each one. No owner, no secret.

[Chad Secures @ChadSecures]

@HuntressLabs @todylsecurity For anyone hunting this: the tell in service principal sign-in logs is a failed secret (AADSTS7000215 or 7000222) and then a success from the same app seconds later. And rotating the secret doesn't kill tokens already issued, so revoke too.

[Chad Secures @ChadSecures]

Huntress and Todyl are tracking someone signing into Entra as service principals with stolen app secrets since Nov 1.

No MFA prompt. No user Conditional Access. Nothing for a user to click.

If your MFA rollout stopped at people, it stopped halfway. Every client secret in your tenant is a password nobody rotates.

[Chad Secures @ChadSecures]

Conditional Access is not default-deny.

If no policy matches a sign-in, it goes through. Scope your MFA policy to Windows and macOS, and a sign-in from Linux or an unknown platform walks right past it.

Every tenant needs one baseline policy: all users, all resources, any platform, only break-glass excluded. Everything else layers on top.

What does your baseline policy require?

[Chad Secures @ChadSecures]

@MSFTMechanics Before migrating, I'd pull a month of sign-in log hits per policy. Anything that hasn't applied to anyone is either dead or scoped wrong, and you don't want to carry that into a plan.

[Chad Secures @ChadSecures]

@buckleyplanet Useful. First thing I'd want to know is whether these show up in sign-in logs as their own resource, so I can run them report-only before an organizer locks out half the meeting.

[Chad Secures @ChadSecures]

@bastienperez_ This cleans up onboarding a lot. Until it lands, TAP is the bridge. Either way I'd keep a CA policy on "Register security information" so nobody adds a method from somewhere you don't trust.

[Chad Secures @ChadSecures]

@david_obrien Good series. The one I'd add: exclusions copied from policy to policy. One "temporary" group excluded from five policies is a bigger hole than a missing platform.

[Chad Secures @ChadSecures]

@buckleyplanet Worth checking Conditional Access too. If one of these groups sits in an include or exclude, the policy keeps pointing at a frozen list. Anyone who was excluded stays excluded.

[Chad Secures @ChadSecures]

Today's the day Entra dynamic groups with memberOf rules stop updating. They just freeze where they are.

The part I'd worry about is Conditional Access. If one of those groups sits in an include or an exclude, the policy is now aimed at a stale list. Leavers stay excluded. New hires miss the policy.

What I'd do this morning:
1. Find them: Get-MgGroup -Filter "groupTypes/any(c:c eq 'DynamicMembership')" -All -Property DisplayName,Id,MembershipRule | Where-Object MembershipRule -match 'memberOf'
2. Search your CA policies for those group IDs, includes and excludes both
3. Check license assignments and access packages that use them
4. Rewrite each rule on user attributes, or switch it to assigned and give it an owner

More of what I see in real tenants on my profile.

[Chad Secures @ChadSecures]

@NathanMcNulty I agree. I also think that we’ll say this again in 30 more years and our kids will look back and think the same. Nostalgia

[Chad Secures @ChadSecures]

@buckleyplanet @ragnarh @JoyOfSharePoint I agree, users should be able to track
usage and understand how to use tokens efficiently.

[Chad Secures @ChadSecures]

@SawyerMerritt Get a free month of Full Self-Driving (Supervised) when you use my link. https://t.co/2PGev83IDN

[Chad Secures @ChadSecures]

@chadrik916 Exactly. I find myself excluding some admins, but that is okay if they understand how it works. The real risk are users that fall victim to Phishing attack

[Chad Secures @ChadSecures]

Two device code phishing kits made the rounds this week. Neither needs a fake login page. The victim types a code into the real Microsoft page and hands over tokens. MFA passes.

Here's how I'd shut it off without breaking anyone:

1. Sign-in logs, filter Authentication protocol to Device code, last 30 days
2. Write down who actually uses it (usually meeting room devices or an admin CLI)
3. New Conditional Access policy: Conditions, Authentication flows, Device code flow. All users, Block
4. Exclude break glass and the real users from step 2
5. Report-only for a week, then enable

More of these real-tenant fixes on my profile. Anyone found a legit device code user they didn't expect?

[Chad Secures @ChadSecures]

@Lagunalab25 @grok The frustration usually comes from prompting too often, not from strict policy. Phishing-resistant methods plus compliant devices let you be strict and prompt less. Passwordless helps a lot, but account recovery and helpdesk resets are where it falls apart.

[Chad Secures @ChadSecures]

@MSFTMechanics Agent risk as a shared condition is a nice touch. I'd run this in report-only first. Most admins won't trust a block on agents until they've watched a few weeks of what it would have hit.