☁️Azure Entra IDIdentityConfigPrivileged Access

Azure Identity Security: Why MFA Alone Is Not Enough

Admin accounts without MFA and disabled Security Defaults are the most exploited Azure identity misconfigurations. Learn how phishing bypasses MFA and how to enforce phishing-resistant authentication.

ES
EtcSec Security Team
5 min read
Azure Identity Security: Why MFA Alone Is Not Enough

What Is Azure Identity Security?

Azure Entra ID (formerly Azure AD) is the identity backbone for Microsoft 365, Azure, and thousands of SaaS applications. Every user, every admin, every automated process authenticates through it. When identity controls are misconfigured, attackers can bypass MFA, escalate privileges, and take over cloud environments with nothing more than a stolen password.

The two most critical Azure identity misconfigurations are MFA not enforced for administrators and Security Defaults disabled. Both represent a fundamental failure of the first line of defense — and both are trivially exploitable with off-the-shelf phishing kits.


How It Works

Azure identity security rests on two foundational controls:

MFA (Multi-Factor Authentication) requires a second factor — phone app, FIDO2 key, SMS — in addition to the password. Even if an attacker obtains a password via phishing or credential stuffing, MFA prevents authentication without the second factor.

Security Defaults are Microsoft's baseline security settings for Entra ID tenants — a pre-configured set of policies that enable MFA for admins, block legacy authentication, and require MFA for risky sign-ins. They are free, enabled by one toggle, and provide immediate uplift for tenants with no existing Conditional Access policies.

When neither is configured, any admin account is one phishing email away from full compromise.


The Attack Chain

Step 1 - Identify Admin Accounts Without MFA

Connect-MgGraph -Scopes "Directory.Read.All", "UserAuthenticationMethod.Read.All"

# List all admins with no MFA methods registered
$adminRoleIds = (Get-MgDirectoryRole | Where-Object DisplayName -match "Admin").Id
foreach ($roleId in $adminRoleIds) {
    Get-MgDirectoryRoleMember -DirectoryRoleId $roleId |
        ForEach-Object {
            $methods = Get-MgUserAuthenticationMethod -UserId $_.Id
            if ($methods.Count -le 1) {  # Only password, no MFA
                [PSCustomObject]@{
                    User = $_.AdditionalProperties.userPrincipalName
                    Role = $roleId
                    MFAMethods = $methods.Count
                }
            }
        }
}

Step 2 - Phish the Admin Account

Attackers use adversary-in-the-middle (AiTM) phishing proxies like Evilginx2 or Modlishka to intercept not just the password but the session cookie — bypassing even MFA-protected accounts:

# Evilginx2 — AiTM phishing for Microsoft 365
# Captures session tokens that bypass MFA entirely
# Requires: registered domain + SSL cert + Evilginx configured for O365 phishlet

For accounts without MFA, even a basic phishing page suffices.

Step 3 - Authenticate as Admin

With the stolen credential (or session token), the attacker authenticates to the Azure portal or Microsoft Graph:

# Using stolen session cookie — bypasses MFA entirely
# Import cookie into browser or use with API tools
curl -H "Authorization: Bearer {stolen_token}" https://graph.microsoft.com/v1.0/me

Step 4 - Establish Persistence

# Create backdoor Global Admin account
New-MgUser -DisplayName "IT Support" -UserPrincipalName "[email protected]" `
    -PasswordProfile @{Password="BackdoorP@ss123!"} -AccountEnabled $true

New-MgDirectoryRoleMemberByRef -DirectoryRoleId $globalAdminRoleId `
    -OdataId "https://graph.microsoft.com/v1.0/directoryObjects/$newUserId"

Detection

Microsoft Entra Sign-in Logs

SignalWhat to Look For
MFA resultSign-ins with mfaDetail: null for admin accounts
Token issuer typeAzureAD with no MFA challenge — baseline violation
Risk levelHigh-risk sign-ins that completed without MFA step-up
Session token reuseSame token used from different IPs/locations rapidly

SIEM Detection Query (Elastic KQL)

azure.signinlogs.properties.authentication_details.authentication_method: "Previously satisfied" AND
azure.signinlogs.properties.user_roles: "*Admin*" AND
azure.signinlogs.properties.risk_level_during_sign_in: ("high" OR "medium")
# Detect new Global Admin assignments
azure.auditlogs.operation_name: "Add member to role" AND
azure.auditlogs.properties.target_resources.modified_properties.new_value: "*Global Administrator*"

💡 Tip: Enable Microsoft Entra ID Identity Protection. It detects AiTM phishing, impossible travel, token anomalies, and other identity-based attack signals in real time — for free on P2 licenses.


Remediation

⚠️ Critical: Enable Security Defaults or Conditional Access MFA immediately. This is the single highest-impact action you can take for Azure identity security.

Option 1: Enable Security Defaults (No License Required)

Entra ID > Properties > Manage Security Defaults > Enable Security Defaults = Yes

Security Defaults enable:

  • MFA required for all admins
  • MFA required for all users during risky sign-ins
  • Legacy authentication blocked
  • MFA required for Azure management

⚠️ Note: Security Defaults and Conditional Access are mutually exclusive. If you have Conditional Access policies, use those instead.

Policy: Require MFA for All Admins
- Users: All users assigned to any admin role
- Cloud apps: All cloud apps
- Grant: Require MFA + Require compliant device

Enforce Phishing-Resistant MFA for Admins

For highest-value accounts, standard TOTP MFA can be bypassed by AiTM. Use phishing-resistant methods:

Entra ID > Authentication Methods > FIDO2 Security Keys = Enabled
Entra ID > Authentication Methods > Certificate-Based Authentication = Enabled

Conditional Access: Require authentication strength = Phishing-resistant MFA
(For Global Admin, Privileged Role Admin, Security Admin)

Enable Identity Protection

Entra ID > Security > Identity Protection:
- User risk policy: Medium and above → Require password change
- Sign-in risk policy: Medium and above → Require MFA

How EtcSec Detects This

EtcSec audits Azure identity security controls on every scan.

MFA_NOT_ENFORCED_ADMINS identifies admin accounts with no MFA methods registered — accounts that are one phishing email away from full tenant compromise.

AZ_SECURITY_DEFAULTS_DISABLED flags tenants where Security Defaults are off and no equivalent Conditional Access policies have been configured, indicating a fundamental identity security gap.

Both findings appear at the top of the EtcSec Azure report given their direct impact on tenant security.

ℹ️ Note: EtcSec audits Azure identity controls automatically. Run a free audit to see which admin accounts in your tenant lack MFA.

Related articles: Azure Conditional Access Gaps | Azure Privileged Access

EtcSec

© 2026 EtcSec. All rights reserved.

Azure Identity Security: MFA and Security Defaults | EtcSec — EtcSec Blog | EtcSec