Your Firewall Is Fine. Your Identity Layer Is Where Ransomware Gets In.
Your Firewall Is Fine. Your Identity Layer Is Where Ransomware Gets In.
Ransomware operators are not breaking through your perimeter. They are walking through your front door with credentials your identity layer handed them. The firewall audit passed. The network segmentation review came back clean. Meanwhile, an attacker is authenticating to Exchange Online from a residential IP in Eastern Europe because your Conditional Access policy has a stale named location exclusion that nobody touched since 2021.
The Perimeter Assumption Is Costing You Incident Response Fees
The persistent belief that a hardened network perimeter translates to ransomware resistance is operationally dangerous. Modern ransomware groups—ALPHV/BlackCat, Scattered Spider, Black Basta—have publicly documented TTPs that route entirely around network controls. They target identity. Specifically, they target the gaps between what your Conditional Access policies say they enforce and what they actually enforce at runtime.
The attack chain looks like this: credential harvesting via phishing or credential stuffing → MFA fatigue or SIM-swap to bypass second factor → authentication to a cloud workload (Exchange Online, SharePoint, Azure portal) → lateral movement via OAuth app consent or service principal abuse → data exfiltration before or concurrent with encryption payload deployment.
At no point in that chain does a firewall rule matter. The traffic is HTTPS to Microsoft's own infrastructure. It looks identical to legitimate user activity until it doesn't.
The structural insight: Ransomware groups do not need to compromise your network. They need one authenticated session to a cloud workload with sufficient privilege. Every misconfigured Conditional Access policy, every stale MFA registration, and every unmanaged device with cached credentials is a potential session.
---
How MFA Fatigue Becomes an Enrollment Vector
MFA fatigue is not a user education problem. It is an authentication design problem. When your MFA implementation defaults to push notifications without number matching, an attacker with a valid password can generate repeated push requests until a user approves one—either accidentally or out of frustration.
Microsoft enabled number matching for Microsoft Authenticator by default in May 2023 and deprecated the ability to disable it. If your tenant was created before that date and you have not audited your Authentication Methods policy since, you may still have legacy MFA configurations active through ADFS claims rules or per-user MFA settings that predate the Authentication Methods policy framework entirely.
The enrollment vector is equally dangerous. If your tenant allows self-service MFA registration without requiring a Temporary Access Pass (TAP) issued by a privileged administrator, an attacker who compromises a user account before MFA is registered can register their own authenticator device. They now own that identity permanently until someone audits the registration.
Run this KQL query in Microsoft Sentinel or Log Analytics to surface suspicious MFA registrations—specifically registrations that occur from IPs not previously seen in your tenant:
AuditLogs
| where OperationName == "User registered security info"
| extend IPAddress = tostring(parse_json(AdditionalDetails)[0].value)
| extend UserPrincipalName = tostring(TargetResources[0].userPrincipalName)
| join kind=leftanti (
SigninLogs
| where TimeGenerated > ago(30d)
| summarize KnownIPs = make_set(IPAddress) by UserPrincipalName
) on UserPrincipalName
| project TimeGenerated, UserPrincipalName, IPAddress, Result
| order by TimeGenerated descThis query identifies MFA registrations from IP addresses that have no prior sign-in history for that user in the last 30 days. Any result here warrants immediate investigation.
---
Conditional Access Policy Drift: The Configuration Debt Nobody Audits
Conditional Access policies accumulate technical debt faster than almost any other control in an Entra ID tenant. A policy written in 2020 to exclude a legacy application that no longer exists is still sitting in your tenant, still creating an exclusion surface, and still being evaluated at every authentication event.
The specific patterns that ransomware operators probe for:
Named location exclusions — Policies that exclude "trusted locations" where the named location object contains IP ranges that are no longer accurate, or where a VPN IP range was added as trusted and that VPN was decommissioned.
Break-glass account exclusions — Emergency access accounts correctly excluded from MFA policies, but the exclusion scope is too broad. Instead of excluding only the break-glass accounts from a specific policy, the exclusion was applied tenant-wide across all policies.
Legacy authentication not fully blocked — A "block legacy authentication" policy exists but has user or application exclusions that were added for a specific migration project and never removed. Legacy authentication protocols (SMTP AUTH, IMAP, POP3) do not support MFA and are a direct bypass path.
Device compliance gaps — A "require compliant device" policy exists but the device compliance policy in Intune has a grace period of 30 days, meaning non-compliant devices authenticate successfully for a month before enforcement kicks in.
Use this PowerShell block to export all Conditional Access policies with their exclusions for offline review:
Connect-MgGraph -Scopes "Policy.Read.All", "Directory.Read.All"
$policies = Get-MgIdentityConditionalAccessPolicy -All
foreach ($policy in $policies) {
[PSCustomObject]@{
PolicyName = $policy.DisplayName
State = $policy.State
ExcludedUsers = ($policy.Conditions.Users.ExcludeUsers -join ", ")
ExcludedGroups = ($policy.Conditions.Users.ExcludeGroups -join ", ")
ExcludedRoles = ($policy.Conditions.Users.ExcludeRoles -join ", ")
ExcludedLocations = ($policy.Conditions.Locations.ExcludeLocations -join ", ")
ExcludedPlatforms = ($policy.Conditions.Platforms.ExcludePlatforms -join ", ")
GrantControls = ($policy.GrantControls.BuiltInControls -join ", ")
}
} | Export-Csv -Path ".\CA_Policy_Audit_$(Get-Date -Format yyyyMMdd).csv" -NoTypeInformation
Write-Host "Export complete. Review ExcludedUsers and ExcludedLocations columns for stale entries."Run this quarterly. Every exclusion in the output is a question that needs an answer: Is this exclusion still required? Who approved it? When does it expire?
---
Unmanaged Device Enrollment: The Intune Gap Ransomware Operators Know About
Unmanaged device enrollment is one of the most underappreciated ransomware entry points in Microsoft 365 environments. If your Intune enrollment restrictions allow personal device enrollment without requiring a corporate device identifier (hardware hash, enrollment token, or Autopilot assignment), an attacker with valid credentials can enroll a device they control into your MDM environment.
Once enrolled, that device can receive configuration profiles, VPN certificates, Wi-Fi credentials, and email profiles. Depending on your app protection policies, it may also receive access to corporate data through managed apps—all from a device the attacker owns.
The remediation path requires three controls working together:
- Enrollment restrictions in Intune set to block personal device enrollment for Windows and restrict enrollment to Autopilot-registered or pre-staged devices only.
- Conditional Access policy requiring Hybrid Azure AD Joined or Intune Compliant device status for all cloud app access—not just Exchange Online.
- App Protection Policies enforced even for compliant devices, so that even if a device passes compliance evaluation, data cannot be exfiltrated to unmanaged storage.
Check your current enrollment restrictions with this PowerShell block:
Connect-MgGraph -Scopes "DeviceManagementServiceConfig.Read.All"
$restrictions = Get-MgDeviceManagementDeviceEnrollmentConfiguration -All
foreach ($r in $restrictions) {
$detail = Get-MgDeviceManagementDeviceEnrollmentConfiguration -DeviceEnrollmentConfigurationId $r.Id
[PSCustomObject]@{
ConfigName = $detail.DisplayName
Priority = $detail.Priority
ODataType = $detail.AdditionalProperties['@odata.type']
PlatformType = $detail.AdditionalProperties['platformType']
OSMinVersion = $detail.AdditionalProperties['osMinimumVersion']
BlockPersonal = $detail.AdditionalProperties['personalDeviceEnrollmentBlocked']
}
} | Format-Table -AutoSizeAny row where BlockPersonal is False for Windows or iOS/Android platforms in a corporate environment is a configuration that needs a documented business justification or immediate remediation.
---
The Audit Blind Spot Regulators Are Starting to Name
Compliance frameworks—SOC 2, ISO 27001, NIST CSF—have historically focused audit evidence on network controls: firewall rule reviews, segmentation diagrams, penetration test results. Identity governance controls were often satisfied with a checkbox: "MFA is enabled."
That is no longer sufficient, and incident responders are documenting this gap explicitly in post-breach reports. The CISA and FBI joint advisory on Scattered Spider (November 2023) specifically called out SIM swapping, MFA fatigue, and help desk social engineering as the primary initial access vectors—not network exploitation.
The governance gap is measurable: organizations that can produce a firewall change log going back 12 months often cannot produce an equivalent audit trail for Conditional Access policy changes. Entra ID does log policy changes in the Audit Log, but those logs are not always routed to SIEM, not always reviewed, and not always tied to a change management process.
The control you need is Conditional Access policy change alerting in Sentinel:
AuditLogs
| where Category == "Policy"
| where OperationName in (
"Add conditional access policy",
"Update conditional access policy",
"Delete conditional access policy"
)
| extend Actor = tostring(InitiatedBy.user.userPrincipalName)
| extend PolicyName = tostring(TargetResources[0].displayName)
| extend ModifiedProperties = tostring(TargetResources[0].modifiedProperties)
| project TimeGenerated, Actor, OperationName, PolicyName, ModifiedProperties
| order by TimeGenerated descRoute this query as a scheduled alert rule with a 24-hour lookback. Any Conditional Access policy modification that does not correspond to an approved change ticket is an anomaly requiring investigation.
---
Remediation Priorities for Microsoft 365 Environments
The following sequence is ordered by attacker impact reduction, not implementation complexity. Start with the controls that eliminate the highest-value attack paths first.
Block legacy authentication completely. Create a Conditional Access policy targeting all users, all cloud apps, with a client app condition scoped to "Exchange ActiveSync clients" and "Other clients." Set the grant control to Block. Remove all exclusions. If an application breaks, that application needs to be migrated to modern authentication—not excluded from the policy.
Enforce number matching and additional context on Authenticator push. Verify this in the Authentication Methods policy under Entra ID > Protection > Authentication Methods. Confirm that the Microsoft Authenticator method is enabled for all users and that both "Require number matching" and "Show additional context in notifications" are set to Enabled.
Audit and expire stale Conditional Access exclusions. Use the PowerShell export above. For every excluded user, group, or named location, require a documented business justification with an expiry date. Implement this as a recurring access review in Entra ID Governance if your license supports it.
Require Temporary Access Pass for new MFA registration. In Authentication Methods policy, configure the TAP method. Then enforce registration campaign settings that require users to register through a TAP issued by a helpdesk workflow—not through self-service from an unauthenticated state.
Restrict Intune enrollment to managed devices. Set enrollment restrictions to block personal device enrollment for all platforms. For Windows, require Autopilot pre-registration. For iOS and Android, require corporate enrollment profiles with device ownership set to Corporate.
Enable Entra ID Protection risk-based Conditional Access. Create policies that respond to High user risk and High sign-in risk signals with either block or require password change + MFA. These policies catch credential stuffing and impossible travel scenarios that static location-based policies miss entirely.
---
Final Thoughts
The firewall is not the problem. It never was, for this threat category. Ransomware operators targeting Microsoft 365 environments are identity operators. They understand Entra ID, they probe Conditional Access logic, and they know that most tenants have configuration debt that has never been systematically reviewed.
The remediation work described here is not theoretical. It is the same work that incident responders document as missing in post-breach reviews. The difference between an organization that contains a compromised credential in 20 minutes and one that discovers a ransomware deployment three weeks later is almost always the presence or absence of these specific identity controls—enforced, monitored, and audited on a defined schedule.
Your network team's work is not wasted. But if your identity governance program cannot answer "who changed that Conditional Access policy and when," you have an audit gap that is now a documented attacker target.
Fix the identity layer first.
---
