Identity Attacks That Succeed Against MFA

Introduction

A detection estate is worth what it catches, and what is worth catching is what prevention does not stop. You will finish this section able to name the four attack families this course is built around, say what each one does to a tenant with every prevention control enabled, and explain why none of them involves guessing a password.

The overwhelming majority of identity attacks are password spray and brute force. Published figures put the share above 97 per cent, and those attacks are solved. Any second factor stops them: a push notification, an SMS code, a hardware key. A tenant with MFA switched on is not meaningfully exposed to the 97 per cent, and building detections for it is building detections for something a control already handles.

That leaves the remainder, and the remainder is what this course is about. The attacks in the scenario have one property in common that makes them worth a course: they succeed against an estate where every prevention control is working correctly, because none of them attempts the thing prevention is watching.

"Solved" is not "impossible". Password spray still succeeds against tenants with no MFA, against accounts excluded from the policy, and against protocols where no interactive challenge can be presented. Section 0.1's estate had 31 rules aimed at it.

There is also a reporting effect worth noticing. Because spray is loud and constant, a detection estate aimed at it produces a healthy-looking stream of alerts and a healthy-looking rate of true positives, none of which describes exposure to anything in the scenario. Volume of caught attacks is not a measure of coverage.

What has changed is that the answer is a control rather than a detection. If spray reaches a tenant, the finding is that a population is uncovered, and the fix is coverage rather than a better rule. That is a different kind of work from watching, and it belongs to the course about controls rather than to this one.

This is the argument for detection existing at all, and it is worth holding onto precisely because it is unfashionable. A great deal of security spending is prevention, and prevention is genuinely better than detection when it applies. The question is never whether to prevent, it is what remains once you have. This course starts from that remainder and does not revisit the part already answered.

The practical version of that is a question to ask of any rule you inherit: what would have to be true of the estate for this to be the most useful thing to watch. Frequently the answer describes a tenant from several years ago, and the rule is a fossil of a boundary that has since moved.

The four families this course is organized around are not a taxonomy of everything, they are the set that reaches a well-configured tenant. Positioning them by which control they defeat is more useful than listing them.

The axis is worth reading before the labels. On the left, prevention is sufficient: a control exists, it is widely deployed, and an attack meeting it stops. In the middle, prevention is available but conditional, so the attack succeeds where a specific control has not been deployed. On the right, prevention is not involved at all, because the activity the attacker performs is activity the system is designed to permit.

Almost everything worth a detection rule sits in the right two thirds, and everything in the rightmost band shares a property that makes detection difficult rather than merely necessary: there is no control decision recorded anywhere, because no control was consulted.

Token theft is the middle case and the only one where prevention still has something to say. A stolen session token replays without any authentication happening, so MFA is irrelevant once the token exists, but phishing-resistant methods prevent the theft in the first place by refusing to authenticate against a proxy. It sits in the amber band because a control exists and most estates have not deployed it.

Consent phishing is on the right because the user agrees. An application asks for permission, a person grants it, and Entra ID records a legitimate authorization. No control was bypassed and none failed. id02 and id04 between them cover this and the detection is a change-detection problem rather than an authentication one.

Workload compromise is on the right because there is no interactive session to apply a control to. A service principal authenticates with a secret and no policy in the standard Conditional Access set reaches it, which is id01's subject.

Standing privilege is on the right because the account is already authorized. An attacker who obtains a Global Administrator credential that never expires does not have to defeat anything, and id03 treats this as a governance problem with a detection attached.

The shared property is worth stating on its own because it explains a specific organizational blindness. Every one of the attacks on the right of that axis operates on something other than a credential: a token, a consent grant, a secret held by an application, or an assignment made months ago.

That matters because password security is where identity security programs concentrate. MFA registration rates, password policies, banned password lists, phishing training. Those are all real work, they are all worth doing, and a tenant can be excellent at every one of them while being wide open to everything in the scenario.

There is a second reason this blindness persists, which is that credential security has clean metrics and the alternatives do not. The proportion of users with a phishing-resistant method registered is a number you can produce in one query, watch improve quarter on quarter, and put in front of a board. The proportion of consent grants that somebody can account for is a number nobody holds, is laborious to establish, and gets worse the harder you look.

There is a third factor, which is that credential work has an owner and the alternatives frequently do not. MFA registration belongs to identity operations. Consent governance belongs to whoever notices, which in most organizations is nobody until an incident makes it somebody.

Programs move toward measurable things. That is not a criticism of the people running them, it is a description of what happens when a reporting cycle meets two problems of unequal tractability.

The organizational consequence is that the reporting looks good. A quarterly identity report showing 98 per cent MFA registration and zero successful password attacks is accurate and describes an estate that lost a mailbox, a subscription and eleven days of Graph access. Nothing in the report is wrong. It is measuring the part that was already solved.

That is the coverage argument in miniature, and section 0.9 takes it up properly with the numbers that would have described the other side: consent grants nobody can account for, service principals with credentials older than the people who created them, and standing privileged assignments with no expiry. None of those is hard to count. All of them are harder to look at than a registration rate, which is the whole reason they go uncounted.

Every attack in the scenario was logged completely. That is the useful fact about all four families: Entra ID is a thorough recorder, and nothing here is a visibility gap in the sense of data that does not exist. It is a gap between data that exists and rules that look at it.

Token theft leaves non-interactive sign-ins from an address with no history for that account, and per section 0.2 it leaves nothing at all in the interactive table after the initial theft.

Connect-MgGraph -Scopes "Policy.Read.All"

Get-MgIdentityConditionalAccessPolicy -All |
  Where-Object { $_.Conditions.ClientApplications.IncludeServicePrincipals } |
  Select-Object DisplayName, State

# (no output)
#
# Every policy in this tenant is scoped to users. Incident 2 needed one of these.

No output is the finding, and it is a two-minute check that most estates have never run. Per section 0.2 an empty result and a healthy result look identical, which is why this is worth running rather than assuming.

Consent phishing leaves an AuditLogs entry for the consent, and then service principal sign-ins by the application, and then whatever the application does in the workload's own logs. Three sources, three different tables, one event.

Workload compromise leaves service principal sign-ins from a new address and frequently an AuditLogs entry where a credential was added shortly before. That pairing is the detection and section 0.5 explains why neither half works alone.

That last point about three sources for one event is the shape to internalize, because it recurs across all four families. Entra ID records identity operations in the table matching the KIND of operation rather than the incident: authentication in the sign-in tables, change in the audit table, and everything the resulting access then does in the workload's own telemetry, which is not an identity table at all.

An attack is therefore never in one place. A consent grant that leads to mailbox access appears as an audit entry, then as service principal sign-ins, then as Exchange activity in a table this course does not cover, and joining those is the work id07 teaches with Defender XDR.

Standing privilege leaves an AuditLogs entry when the assignment was made, which may be a year in the past and outside your retention, and then nothing whatsoever. It is the hardest of the four to detect after the fact and the easiest to find by looking at current state rather than at events.

The three losses in the scenario are below as they were recorded, one row per incident, with what the estate's controls were doing at the time.

Take them in order and notice how ordinary each one is at the moment it happens. The consent is a person clicking a button on a Microsoft-hosted page that is doing exactly what it says. The service principal authentication is an application using a credential it legitimately holds. The token replay is a refresh request identical in structure to the several hundred that user's clients make every day.

Read the control column rather than the attack column. In all three the controls did exactly what they were configured to do, and in none of them was that relevant to the outcome. The compliant-device requirement was enforced and the attacker was using a legitimately compliant device belonging to the user. The phishing-resistant MFA requirement was enforced and never evaluated, because no interactive sign-in occurred.

That is the pattern the whole course rests on: an estate can be correct and lose, and the record of it being correct is what makes the loss hard to see.

It also explains why the post-incident review in each of these cases is unsatisfying. There is no misconfiguration to point at, no control to blame, and no policy to tighten that would have changed the outcome. The honest finding is that the estate had no detection aimed at the thing that happened, which reads as a weaker conclusion than "somebody left a policy off" and is a more serious one. A misconfiguration is a fix somebody can complete this week. A missing detection is a program, with a budget line and an owner, and it is the harder thing to propose in the room after an incident because it sounds like an admission that nothing was watching.

The four families map onto the course unevenly, because the amount of detection work each needs is not proportional to how often it happens.

Token theft gets the most attention in id04, because it produces the most evidence and the evidence is the most ambiguous. A refresh from a new address is either a user on holiday or a stolen token, and separating them is a genuine skill.

Consent and application abuse is split: id02 covers external identities and the trust boundary that lets an outside application in, and id04 covers detecting the grant itself. It appears twice because the prevention question and the detection question have different answers.

Workload compromise is id01 almost entirely, and it is placed first in the course for a reason worth knowing: it is the population most estates cannot see at all, so it is the fastest route to a finding in a tenant you have just been given.

Standing privilege is id03, treated as governance rather than as detection, because the useful intervention is removing the assignment rather than watching it.

There is one family deliberately absent from this course and it is worth naming so its absence is a decision rather than a gap. On-premises attacks against Active Directory, Kerberos, ADCS and delegation are a large and important subject and they are a different discipline. Where they touch the cloud, and they do, it is through synchronization and through Defender for Identity signal reaching the tenant, which id07 covers as a source rather than as a subject.

If your estate is hybrid, that boundary matters and this course does not pretend to cover the other side of it.

Half an hour with your own rule inventory, and the answer usually surprises people who built it.

The next section takes the hardest property these attacks share, which is that the evidence for them looks identical to the evidence for ordinary administration.