Fix Insecure Entra ID/Azure AD Default's

Executive Summary

This article will explore the prevalent issue of insecure default configurations in Azure and provide a comprehensive guide on fortifying these vulnerabilities. Additionally, it will introduce a script to identify such flaws, which have been incorporated into Soteria’s 365 Inspect tool for enhanced detection. You can find that tool located here --> https://blog.soteria.io/soteria-365inspect-8fb899ecd532

Addressing Entra ID Vulnerabilities By default, Entra AD permits any authenticated user without privileges to perform actions like creating applications, forming security groups, and accessing comprehensive user profiles and security settings. This level of access is excessive for standard users.

Key Security Measures

• Limit Entra ID Admin Access: Navigate to the Entra ID blade, select User Settings, and enable the ‘Restrict access to Azure AD administration portal’ setting to ‘Yes’.

Control PowerShell Access: Conditional access rules do not limit PowerShell access by default. Use Microsoft Graph to enforce restrictions. The script below sets up service principals for Azure Active Directory and Microsoft Graph PowerShell modules, requiring user or group assignment for usage:

$applications = @("Microsoft Graph PowerShell", "Azure Active Directory PowerShell")

Foreach ($application in $applications){
    $appids = (Get-AzureADServicePrincipal -Filter "DisplayName eq '$application'").AppId

    Foreach ($appid in $appids){
        $servicePrincipal = Get-AzureADServicePrincipal -Filter "appId eq '$appId'"
        if (-not $servicePrincipal) {
            $servicePrincipal = New-AzureADServicePrincipal -AppId $appId
        }
        Set-AzureADServicePrincipal -ObjectId $global:servicePrincipal.ObjectId -AppRoleAssignmentRequired $true
        New-AzureADServiceAppRoleAssignment -ObjectId $global:servicePrincipal.ObjectId -ResourceId $servicePrincipal.ObjectId -Id ([Guid]::Empty.ToString()) -PrincipalId $admin.ObjectID
    }
}

Restrict Group Creation: Prevent non-admin users from creating groups by executing the PowerShell command as a Global Admin:

Set-MsolCompanySettings -UsersPermissionToCreateGroupsEnabled $false

After running this command, regular users will lose the group creation capability.

Further Security Enhancements

• Teams Compatibility: Avoid setting UsersPermissionToReadOtherUsersEnabled to False to maintain Teams functionality. If you are not using Teams, it is save to set this to false.

Prevent Email-Based Subscriptions: Unless necessary, set AllowedToSignupEmailBasedSubscriptions to False:

Set-AzureADMSAuthorizationPolicy -id (Get-AzureADMSAuthorizationPolicy).id -AllowedToSignupEmailBasedSubscriptions $false

Disable Self-Service Join: If not utilized,

set-AllowEmailVerifiedUsersToJoinOrganization to False:

Set-AzureADMSAuthorizationPolicy -id (Get-AzureADMSAuthorizationPolicy).id –AllowEmailVerifiedUsersToJoinOrganization $false

Conditional Access Rule Proposal Create a rule that restricts access to Azure Management consoles for non-administrators:

• Users: Include all except Global Administrators and other Admin Roles.
• Cloud Apps: Target Microsoft Azure Management.
• Conditions: Apply to any device platform and location, enforcing access blockage.

Concluding Insights Adhering to these recommendations will significantly bolster the security of your Entra ID and Azure environment. For those with Microsoft Sentinel, integrating Azure to funnel conditional access logs into Sentinel is advised.

The following KQL query can monitor attempts to sign into Azure PowerShell, particularly from outside the US, revealing potential foreign intrusion efforts:

SigninLogs
| where ResultType == '50076' or ResultType == '50126' or ResultType == '50053'
| project SourceSystem, Identity, AppDisplayName, IPAddress, LocationDetails
| where LocationDetails !contains "US"

Implementing these strategies can prevent common security oversights and strengthen your Azure Active Directory’s defenses.