Add MT.1186: Require explicit assignment for high-privilege first-party Entra apps#1985
Add MT.1186: Require explicit assignment for high-privilege first-party Entra apps#1985BakkerJan wants to merge 3 commits into
Conversation
…ty Entra apps Checks appRoleAssignmentRequired for 9 high-privilege, pre-consented first-party Microsoft service principals (Azure PowerShell, Azure CLI, Microsoft Graph Command Line Tools, Graph Explorer, Azure AD PowerShell, Teams PowerShell, Exchange Online PowerShell, SharePoint Online Management Shell, Power Platform CLI). These carry broad delegated permissions and are commonly used to enumerate or exfiltrate tenant data once an attacker has a foothold on any single user account, but MT.1075 explicitly excludes Microsoft-owned apps from its equivalent check, leaving this gap uncovered. Reserved via maester365#697 (comment).
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughChangesHigh-Privilege Service Principal Test
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@powershell/public/maester/entra/Test-MtHighPrivilegeServicePrincipalsForAllUsers.ps1`:
- Around line 79-85: Update the $isOpen and status logic in
Test-MtHighPrivilegeServicePrincipalsForAllUsers so appRoleAssignmentRequired is
evaluated independently of accountEnabled and disabled service principals with
assignment disabled cannot pass as “Assignment required.” Preserve open-to-all
detection for enabled principals, and report disabled principals with a distinct
non-compliant status when appropriate.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro Plus
Run ID: 9d15dca5-77df-43f2-a136-74cd7b253bee
📒 Files selected for processing (5)
powershell/Maester.psd1powershell/public/maester/entra/Test-MtHighPrivilegeServicePrincipalsForAllUsers.mdpowershell/public/maester/entra/Test-MtHighPrivilegeServicePrincipalsForAllUsers.ps1tests/Maester/Entra/Test-MtHighPrivilegeServicePrincipalsForAllUsers.Tests.ps1tests/maester-config.json
Up to standards ✅🟢 Issues
|
appRoleAssignmentRequired was only evaluated when accountEnabled was also true, so a disabled app with assignment not configured was mislabeled 'Assignment required' and the test passed despite the misconfiguration - it would silently become open to all users the moment the app is re-enabled. Evaluate appRoleAssignmentRequired independently and report disabled-but-unassigned apps under a distinct, non-compliant status. Addresses CodeRabbit review comment on maester365#1985.
|
This one is bound to disrupt a few people when orgs turn it on, but it still makes sense! 🫡 Should Azure Developer CLI also be included on the list? |
Yeah agree. Hopefully it will also stop a few attackers 😊 Isn't Azure Developer CLI the same app ID as Microsoft Azure CLI? (4b07795-8ddb-461a-bbee-02f9e1bf7b46) |
Oh, I don't know / haven't checked! If it is, it would be worth noting that the same app ID is used for both the |
Summary
Adds
Test-MtHighPrivilegeServicePrincipalsForAllUsers(MT.1186, High severity), which checksappRoleAssignmentRequiredon a curated list of 9 high-privilege, first-party Microsoft service principals:Connect-MgGraphand the Microsoft Graph CLI)pac)These apps are pre-consented in most tenants and carry broad delegated permissions (e.g.
Directory.AccessAsUser.All,Application.ReadWrite.All,Group.ReadWrite.All, or full workload-admin impersonation for Exchange/SharePoint). Left open to all users, any compromised or malicious account can use them without any further consent prompt to enumerate directory data or administer that workload directly — a common first step in privilege escalation and data exfiltration.This is distinct from the existing MT.1075 (
Test-MtServicePrincipalsForAllUsers), which explicitly excludes Microsoft-owned apps viaappOwnerOrganizationIdfiltering. MT.1186 targets exactly the Microsoft-owned apps that MT.1075 skips.The app list and their granted delegated scopes were verified against Microsoft's own first-party app reference and cross-checked with Dirk-jan Mollema's ROADtools first-party scopes dataset rather than relying on memory, since incorrect app IDs would make the check useless.
The result table splits flagged apps ("Open to all users") from the rest ("Other monitored apps") so the actionable items surface first, and links each app to its Entra admin center Properties blade with a hover tooltip explaining the specific risky permission it holds. Apps not provisioned in a given tenant are reported as "Not present in tenant" rather than silently skipped.
Reserved via #697 (comment).
Test plan
Invoke-ScriptAnalyzeragainst the new function file — no issues./build/Build-LocalMaester.ps1— builds and loads cleanly./powershell/tests/pester.ps1— full QA suite, no failuresInvoke-Maester -Tag "MT.1186"against a live tenant — confirmed pass/fail/skip states render correctlyReference
Summary by CodeRabbit