ACSC Logo
© GEMXIT
GEMXIT Logo
Agent Foskett Investigation • Microsoft Entra ID • SigninLogs • Legacy Authentication • Conditional Access • KQL

The Account Had MFA — But the Legacy Authentication Attempt Told the Story

MFA was enabled.

The user's normal interactive sign-ins looked protected.
Conditional Access was working.
Nothing obvious suggested an MFA bypass.

Then Agent Foskett stopped looking only at modern authentication.

One field in the sign-in history changed the investigation.

ClientAppUsed showed a legacy authentication attempt.

Discuss identity security Back to investigations
Agent Foskett investigating legacy authentication attempts against an MFA protected Microsoft Entra account
MFA Was Only Part of the Story

An MFA-protected account can still produce authentication telemetry that deserves investigation. The protocol, application, result and Conditional Access outcome all matter.

✓ Review the complete sign-in history
✓ Identify legacy client activity
✓ Scope the IP and wider tenant exposure

The account looked protected

The first review showed what the analyst expected: MFA was configured and the user's ordinary interactive sign-ins contained modern authentication and Conditional Access evidence. But MFA configuration alone does not explain every authentication attempt made against an identity.
MFA enabledThe account was not operating as a simple password-only identity.
Normal sign-ins looked expectedThe familiar interactive activity did not immediately explain the suspicious event.
One protocol stood outA legacy client value appeared in the sign-in telemetry.

Start with the complete sign-in history

Use SigninLogs to review the affected account without filtering too early. Keep ClientAppUsed, authentication requirement, result and Conditional Access status visible so that older client protocols are not hidden by a modern-authentication-only investigation.
complete-signin-history.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(7d)
| where UserPrincipalName =~ User
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          ClientAppUsed,
          IPAddress,
          ResultType,
          ResultDescription,
          AuthenticationRequirement,
          ConditionalAccessStatus
| order by TimeGenerated asc

Look specifically for legacy client protocols

ClientAppUsed can help identify sign-ins associated with older authentication clients and protocols. Search the account history for values such as IMAP, POP, Exchange ActiveSync, Exchange Web Services, MAPI and authenticated SMTP, then examine the result rather than assuming every legacy attempt succeeded.
legacy-client-attempts.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ User
| where ClientAppUsed in
    ("Exchange ActiveSync",
     "Exchange Web Services",
     "IMAP4",
     "MAPI Over HTTP",
     "POP3",
     "Authenticated SMTP")
| project TimeGenerated,
          AppDisplayName,
          ClientAppUsed,
          IPAddress,
          ResultType,
          ResultDescription,
          ConditionalAccessStatus
| order by TimeGenerated asc

The attempt changed the investigation

The important finding was not simply that MFA existed. The sign-in history showed authentication activity using a client path that did not match the user's normal pattern. That created new pivots: which application was targeted, where the attempt originated, whether it succeeded and what Conditional Access did with it.
08:41 — normal sign-inThe user's familiar interactive activity followed the expected authentication path.
09:17 — legacy attemptA different client protocol appeared from an unfamiliar IP address.
09:18 — investigation widenedThe analyst now had an IP, protocol and application to scope.

Was it one attempt or a pattern?

Summarise the account's authentication history by client application, target application and IP address. Repeated failures can tell a different story from one isolated attempt, while any successful result deserves careful validation against policy and expected use.
authentication-pattern.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ User
| summarize Attempts=count(),
            Successful=countif(ResultType == 0),
            Failed=countif(ResultType != 0),
            FirstSeen=min(TimeGenerated),
            LastSeen=max(TimeGenerated)
    by ClientAppUsed,
       AppDisplayName,
       IPAddress
| order by Attempts desc

What else came from the same IP?

The source IP becomes a valuable pivot. Search it across SigninLogs to determine whether the activity targeted only one identity or whether the same infrastructure attempted authentication against multiple accounts.
scope-source-ip.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
let SuspiciousIP = "203.0.113.25";
SigninLogs
| where TimeGenerated > ago(30d)
| where IPAddress == SuspiciousIP
| project TimeGenerated,
          UserPrincipalName,
          AppDisplayName,
          ClientAppUsed,
          ResultType,
          ResultDescription,
          ConditionalAccessStatus
| order by TimeGenerated asc

Build the timeline around protocol and result

Plotting attempts by hour, client type, result and IP helps separate normal user activity from bursts of unusual authentication. This is especially useful when the suspicious activity is mixed into a busy account history.
protocol-timeline.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
let User = "alex@contoso.com";
SigninLogs
| where TimeGenerated > ago(30d)
| where UserPrincipalName =~ User
| extend Status = case(
    ResultType == 0, "Success",
    "Failure")
| summarize Attempts=count()
    by bin(TimeGenerated, 1h),
       ClientAppUsed,
       Status,
       IPAddress
| order by TimeGenerated asc

Is legacy authentication appearing elsewhere?

Once the account-level investigation is understood, widen the question to the tenant. If legacy client activity exists elsewhere, determine whether it is expected business use, stale configuration or something that should be reduced through identity policy.
tenant-legacy-auth-scope.kql
  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
SigninLogs
| where TimeGenerated > ago(30d)
| where ClientAppUsed in
    ("Exchange ActiveSync",
     "Exchange Web Services",
     "IMAP4",
     "MAPI Over HTTP",
     "POP3",
     "Authenticated SMTP")
| summarize Attempts=count(),
            Users=dcount(UserPrincipalName),
            Successful=countif(ResultType == 0)
    by ClientAppUsed
| order by Attempts desc

MFA does not make every authentication path equivalent

The investigation should distinguish account protection from individual authentication events. MFA being enabled is important context, but the analyst still needs to understand which client protocol was used, whether the attempt succeeded and how Conditional Access evaluated it.
Identity configurationShows how the account is intended to be protected.
Sign-in telemetryShows what authentication was actually attempted.
Policy outcomeShows how Conditional Access handled the observed sign-in.

What the evidence can and cannot prove

A legacy client value in SigninLogs proves that the corresponding authentication path was observed. It does not automatically prove an MFA bypass, successful compromise or malicious intent. ResultType, Conditional Access status, source context and wider account activity determine what conclusion the evidence supports.
ProvenThe account received authentication activity through a legacy client path.
InvestigateThe source IP, result, target application and surrounding attempts determine the significance.
Do not overclaimMFA enabled plus a legacy attempt does not by itself mean MFA was bypassed.

Agent Foskett's investigation mindset

Do not let a security control become the conclusion. “The account has MFA” is useful context, but it is not an explanation for every authentication event. Follow the protocol, result, IP and policy outcome until the sign-in makes sense.
Check the controlConfirm how the identity is configured and protected.
Check the eventDetermine which authentication path was actually attempted.
Check the scopeEstablish whether the activity affected one user or appeared elsewhere in the tenant.

Investigation findings

The account had MFA and its normal interactive sign-ins looked expected, but SigninLogs contained authentication activity using a legacy client protocol from an unfamiliar source. That evidence did not prove MFA had been bypassed. Instead, it exposed an authentication path that required separate analysis of the result, Conditional Access evaluation, source IP and wider tenant activity. The legacy attempt was the clue that stopped the investigation from ending at “MFA is enabled.”
MFA was presentThe identity had an important protection control in place.
The protocol was unusualThe sign-in history contained a client path outside the user's expected pattern.
The evidence needed contextProtocol, result, policy and source together determined the real significance.

Related Agent Foskett investigations

Continue with Microsoft Entra ID, MFA and Conditional Access investigations.
The MFA Was On — Just Not EverywhereInvestigate why MFA coverage needs to be understood across authentication paths and applications. The Conditional Access Result Said Success — But That Wasn't the Whole StoryLook beyond a single Conditional Access result when reconstructing identity activity. Agent Foskett AcademyBuild practical Microsoft security investigation and KQL skills.
MFA was enabled. The protocol still deserved an investigation.
Security controls provide context. Sign-in telemetry tells you what was actually attempted.
Continue the Investigation

Final thought

MFA is one of the most important identity protections available, but investigators should never use its presence as a reason to stop asking questions. When an authentication event does not fit the user's normal pattern, inspect the client protocol, result, source and policy evaluation. Sometimes the clue is not that MFA failed. It is that somebody tried a different door.
Which client was used?ClientAppUsed can expose authentication paths hidden inside a busy sign-in history.
Did the attempt succeed?Keep failed and successful authentication clearly separated.
What did policy do?Use Conditional Access and surrounding telemetry before drawing the final conclusion.
Develop IT. Protect IT.
GEMXIT PTY LTD | GEMXIT UK LTD
Talk to GEMXIT
ACSC Logo

GEMXIT PTY LTD  |  GEMXIT UK LTD  |  © GEMXIT

The Account Had MFA — But the Legacy Authentication Attempt Told the Story

This Agent Foskett investigation explores Microsoft Entra ID SigninLogs, legacy authentication clients, MFA, Conditional Access, source-IP scoping and KQL.

Microsoft Entra Legacy Authentication Investigation

The investigation starts with an MFA-protected identity and follows an unusual legacy client authentication attempt through protocol, result, IP address and policy evidence.

SigninLogs, MFA, Conditional Access And KQL

MFA configuration is important context, but each authentication event still needs to be understood on its own evidence. ClientAppUsed and sign-in results help analysts identify unexpected authentication paths.