MFA Passed, Session Stolen: What BigBear 2.0 Exposes About Multi-Tenant Incident Response for MSPs

CloudSEK's June report on BigBear 2.0 should be mandatory reading for anyone running Microsoft 365 on behalf of other people. The phishing-as-a-service operation, built on the Evilginx2 framework, harvested 5,137 credential records across 461 organizations in more than 40 countries — including 4,148 session cookies, 1,032 plaintext passwords, and, most damning, 474 completed logins where attackers captured the authenticated session created after the victim passed MFA.

Read that last number again. MFA worked exactly as designed. The push notification was approved by the real user, the sign-in looked completely legitimate, and the attacker walked in anyway — carrying the victim's session cookie out of an adversary-in-the-middle proxy.

If you are a sysadmin protecting one tenant, that is a bad week. If you are an MSP running 20, 40, or 60 client tenants, it is something worse: proof that your detection and response tooling — RMM here, monitoring there, helpdesk over there, patching somewhere else, and a per-tenant M365 admin center — is structurally incapable of catching and containing this class of attack at fleet scale. The phish itself is only half the story. The other half is how long it takes your team to notice, triage, and shut it down.

How BigBear 2.0 Beats MFA Without Ever Breaking It

Evilginx2 places an attacker-controlled reverse proxy between the victim and the real Microsoft login page. The user clicks a lure, lands on a pixel-perfect copy of the sign-in page, and types real credentials into the real page — relayed through the attacker's proxy. The MFA prompt fires. The user approves it on their phone, because as far as they know, they just logged in.

From Microsoft's side, everything is legitimate: correct password, satisfied MFA challenge, issued token. What the user never sees is that the session cookie minted at the end of that flow transits the attacker's proxy first. The attacker imports that cookie into their own browser and inherits the authenticated session — no password guessing, no MFA fatigue, no failed sign-ins to trip a lockout. This is why 474 of BigBear 2.0's records show fully completed post-MFA sessions, and why session revocation is a distinct, non-optional response step that a password reset alone does not cover.

The Problem in Depth: Five Tools, Zero Correlation

Ask yourself the operational question, not just the security question: when this lands in one of your client environments, what actually happens next?

• Your RMM (ConnectWise Automate, NinjaOne, Datto RMM) is endpoint-centric. It knows the workstation is online and patched. It has no idea that the mailbox sitting on that workstation has an active session from a residential ASN in another hemisphere.
• Your monitoring stack (PRTG, SolarWinds, Zabbix) watches uptime, disk, and latency. It does not watch identities. Sign-in anomalies are invisible to it by design.
• Your helpdesk (ConnectWise Manage, HaloPSA, Autotask) holds the "user saw a weird MFA prompt" ticket. Nothing links that ticket to tenant sign-in data, nothing timestamps it against an SLA clock that matters, and closing it is one click — which is exactly what happens.
• Your patching tool knows Client A has 40 endpoints on outdated Office builds. It cannot tell you that legacy authentication is still enabled in that same tenant.
• The M365 admin center — your actual source of truth for identity activity — shows one tenant at a time. At fleet scale, nobody is watching 60 of them in real time.

Concrete scenario, and every MSP tech has lived a version of it: at 4:47 PM, a user at Client A submits "I got an MFA prompt I didn't request." The tech asks if it might have been the VPN. The user isn't sure. Ticket closed at 6:10 PM. Meanwhile the actual attacker session — started at 3:52 PM — never appears anywhere, because nothing watching that tenant talks to anything holding the ticket queue, and no human has time to pull sign-in logs for every vague MFA-prompt ticket across every client.

Why do these gaps exist? Not because technicians are lazy. Because the tooling is siloed by architecture and by era: RMM platforms grew out of endpoint management, monitoring out of network operations, helpdesks out of service desks. Integrations are bolted on through APIs and swivel-chair exports. Per-seat helpdesk licensing discourages wiring everything into it. So the state of the art at too many MSPs is: 12 tabs open across 5 tools to support one client, with Excel as the integration layer.

What It Actually Costs You

• Dwell time measured in days. A stolen session typically sets hiding rules, reads finance threads, and launches invoice fraud long before anyone notices. By the time the client's CFO calls you, the attacker has been reading email for a week.
• MTTR inflation. Reconstructing a timeline from an alert in one system, a ticket in another, and tenant logs in a third — with timestamps that don't agree — turns a 30-minute containment into an afternoon.
• Ticket storms. One BigBear-style campaign hits four clients at once. Now every report is a fresh manual investigation, in four separate tenants, with the same five tools open.
• SLA reporting you can't defend. The alert lived in the monitoring tool, the response lived in the helpdesk, and the clocks never matched. You cannot answer "how fast did we actually respond" with data you trust.
• Burnout. The on-call tech learns about a client breach from the client, not from their own console. That is the moment good technicians start updating their LinkedIn.

How AlertMonitor Closes the Gap

This is the problem AlertMonitor was built for — not as a security bolt-on, but as the operational platform an MSP runs its entire NOC on.

• Multi-tenant by default. One unified NOC view across every client simultaneously, with isolated per-client dashboards underneath for compliance and reporting. Triage happens on one screen, not in 60 admin centers.
• Per-client alert routing and SLA thresholds. Identity-related and anomaly alerts route straight to your senior techs with a tighter SLA clock than "printer offline at Client C." The right person gets paged, with context attached, on the first pass.
• Alert-to-ticket without the copy-paste. Alerts flow into the integrated helpdesk with client, device, and timeline already attached. Every action is time-stamped in one data model — which means your SLA reports finally come from a single source of truth instead of a reconciliation spreadsheet.
• RMM actions from the alert itself. Force remediation, isolate an endpoint, restart a service — from the alert, in the same console. No context-switching at 2 AM.
• Patch state as a fleet-wide risk lens. See instantly which clients still run endpoints on outdated Office builds or unpatched OS versions, push the fix, and verify compliance — from the same platform that raised the alert and holds the ticket.

Old workflow: user report → helpdesk ticket → manual tenant log pull → RMM check → patch report in a fourth tool → spreadsheet. Hours, five tools, no audit trail. AlertMonitor workflow: alert fires → ticket opens with context → technician acts from the same pane → SLA clock runs itself. Minutes, one console, complete timeline.

Practical Steps You Can Take Today

The steps below work in any environment. The operational point is to run them across every tenant, from one place, with tickets and SLAs attached — which is what AlertMonitor exists to do.

1. Audit MFA registration across every tenant

BigBear 2.0 harvested plaintext passwords for 1,032 accounts. Any of them without a second factor is a working login waiting to happen.

Connect-MgGraph -Scopes 'UserAuthenticationMethod.Read.All'

$report = foreach ($user in Get-MgUser -All -Property Id,UserPrincipalName,DisplayName) {
    $methods = Get-MgUserAuthenticationMethod -UserId $user.Id -ErrorAction SilentlyContinue
    $real = $methods.AdditionalProperties.Values |
        ForEach-Object { $_.'@odata.type' } |
        Where-Object { $_ -notmatch 'passwordAuthenticationMethod' }
    if (-not $real) {
        [PSCustomObject]@{
            UPN  = $user.UserPrincipalName
            Name = $user.DisplayName
        }
    }
}
$report | Export-Csv .\UsersWithoutMFA.csv -NoTypeInformation

Run it per tenant, fix the gaps, and repeat monthly. At fleet scale, this is exactly the kind of recurring, per-client check that belongs on an AlertMonitor-monitored schedule with a ticket generated for every client that fails.

2. Kill legacy authentication org-wide

Basic auth is the phisher's fallback: even when MFA is enforced on modern endpoints, legacy protocols (IMAP, POP, SMTP AUTH, MAPI) can still accept password-only access. Audit every tenant first:

# clients.csv columns: TenantId, AppId, CertificateThumbprint, Domain
$clients = Import-Csv .\clients.csv

$audit = foreach ($c in $clients) {
    Connect-ExchangeOnline -AppId $c.AppId -Organization $c.Domain `
        -CertificateThumbprint $c.CertificateThumbprint -ShowBanner:$false

    [PSCustomObject]@{
        Client        = $c.Domain
        DefaultPolicy = (Get-OrganizationConfig).DefaultAuthenticationPolicy
    }
    Disconnect-ExchangeOnline -Confirm:$false
}
$audit | Export-Csv .\BasicAuthAudit.csv -NoTypeInformation

Then remediate any tenant still running on defaults:

Connect-ExchangeOnline -UserPrincipalName 'admin@clientdomain.com'

New-AuthenticationPolicy -Name 'Block Basic Auth' -AllowBasicAuthImap:$false `
    -AllowBasicAuthPop:$false -AllowBasicAuthSmtp:$false `
    -AllowBasicAuthMapi:$false -AllowBasicAuthActiveSync:$false

Set-OrganizationConfig -DefaultAuthenticationPolicy 'Block Basic Auth'

3. Build a session-revocation runbook

This is the step most teams skip, and it is the one BigBear 2.0 makes mandatory. A password reset does not reliably kill a stolen session cookie. Revoking sessions does.

Connect-MgGraph -Scopes 'User.RevokeSessions.All','User.ReadWrite.All'

# Invalidate every active M365 session for the affected user
Revoke-MgUserSignInSession -UserId 'compromised.user@clientdomain.com'

# Force a password change on next sign-in
Update-MgUser -UserId 'compromised.user@clientdomain.com' `
    -PasswordProfile @{ ForceChangePasswordNextSignIn = $true }

Write this into a standard ticket template. In AlertMonitor, the suspected-phish report creates the ticket, the runbook steps are the checklist, and the SLA clock proves to the client you contained it inside the window you promised.

4. Standardize phishing intake and response

Dedicated reporting mailbox or button → auto-created ticket → routed to security-capable techs → runbook → documented closure. If your intake lives in a shared inbox and your response lives in tribal knowledge, your MTTR is whatever the most tired technician happens to remember that night.

5. Use patch compliance as a cross-client risk lens

Post-incident, the first question from the client will be "were we exposed, and where?" If patch state, endpoint health, and tenant hygiene live in one platform, the answer is a report — not a two-day scavenger hunt across four consoles.

The Takeaway

BigBear 2.0 didn't defeat MFA. It defeated the assumption that MFA is a finish line, and it thrived in the operational gaps that fragmented tooling leaves open. Your defense is not one more console — it is fewer consoles, faster routing, and a response that starts the second the alert fires instead of the second a user calls. That is a monitoring, RMM, helpdesk, and patching problem. It is one platform's problem. It is ours.

Related Resources

AlertMonitor MSP Operations & Team Efficiency AlertMonitor Platform Overview Book a Demo MSP Operations & Team Efficiency Resources