ConnectWise Breach: Proving What an App Did with Microsoft Graph Activity Logs

The ConnectWise supply-chain attack on Microsoft 365 tenants has raised a question I keep hearing from MSPs: if an attacker’s app signed in to a tenant, how do you prove what it did, or didn’t, do?

The honest answer is that Microsoft doesn’t publish one definitive list of “Graph activity that isn’t in the UAL”. What it does document is which log records what. Put those side by side and the gaps become clear. I’ll cover what each log tells you, where the blind spots are, how to switch on Microsoft Graph activity logs, and how to scope the blast radius if you didn’t have them on.

What GCIT showed

Credit to Elliot and the team at GCIT, whose write-up of the ConnectWise Cloud Backup compromise is a model of how to be open about an incident. Their tenant had one successful service principal sign-in from the Cloud Backup app (15 Oct, 144.172.64.128, Python user agent). They proved nothing was done with that token by matching its identifier against 13,682 requests in their Microsoft Graph activity logs. The UAL on its own could never have proved that. They also note that Graph activity logs need Entra ID P1 and have to be switched on before the event.

The three logs and what each one tells you

• Sign-in logs (service principal and managed identity sign-ins are kept separately from interactive sign-ins) tell you that a token was issued, and from where. They don’t tell you what was done with it. One sign-in can mean hundreds of API calls, or none at all, as GCIT found. Retention is 7 days on Entra ID Free and 30 days on P1/P2, so export them. https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
• The unified audit log records audited actions in each workload. It isn’t a record of every API request. A good example is mail: MailItemsAccessed covers all protocols, including REST/Graph and EWS, but it’s only on by default for E3/E5 users. Check your mailbox audit configuration everywhere else. Bind accesses are also aggregated and de-duplicated. https://learn.microsoft.com/en-us/purview/audit-log-investigate-accounts
• Microsoft Graph activity logs (MicrosoftGraphActivityLogs) record every HTTP request Graph processes for your tenant: app ID, service principal, IP, request URI, method, response size, and the token and sign-in identifiers. That’s what lets you join requests to sign-ins. They need Entra ID P1 or P2 and a diagnostic setting that sends them to Log Analytics, Storage or Event Hub. They aren’t retroactive, and delivery usually takes up to 30 minutes, occasionally 2 hours. https://learn.microsoft.com/en-us/graph/microsoft-graph-activity-logs-overview

So where are the blind spots?

Anything read through Graph that the workload doesn’t audit as an action, such as directory and user reads, will only show up in Graph activity logs. And full_access_as_app over EWS isn’t Graph at all, so it won’t appear in Graph activity logs. It would only appear in mailbox auditing. If you don’t have Graph activity logs turned on, “sign-in but no UAL entries” doesn’t prove nothing happened. It means you can’t tell.

On audit retention: Audit Standard is 180 days. Audit Premium (E5) keeps Exchange, SharePoint, OneDrive and Entra records for one year, and up to 10 years with the add-on. https://learn.microsoft.com/en-us/purview/audit-log-retention-policies

What an attacker could do without Graph activity logs

The short answer is anything the app’s granted permissions allow. Without Graph activity logs, most read-only activity leaves no trace at all.

Likely to leave no trace (reads)

• Directory reconnaissance: listing users, groups, admin role holders, devices, apps, Conditional Access policies and licences (Directory.Read.All, Policy.Read.All). Reads like these aren’t recorded in the UAL, which makes them perfect for mapping a tenant before a bigger attack.
• Org intel: org charts, managers, phone numbers and email addresses, all useful for phishing and business email compromise.
• Teams/chat and calendar reads, and some file reads, depending on permissions and audit coverage. SharePoint and OneDrive FileAccessed events usually do appear in the UAL, but bulk reads by an app can be patchy.

Probably visible, if auditing was on

• Mail reads (Mail.Read): these show as MailItemsAccessed, but only if mailbox auditing records that action for the affected mailboxes. If it doesn’t, they’re invisible.
• Writes and changes: sending mail, creating inbox rules, adding app credentials or owners, consenting to new apps, creating users or changing roles, and changing CA policies. These normally appear in the Entra audit log or the UAL, because they’re audited actions rather than reads.

What actually determines the blast radius

1. The app’s application permissions. Check Enterprise applications > the app > Permissions. Something like Mail.Read or Files.Read.All is tenant-wide.
2. The service principal sign-ins: times, IP addresses and how many tokens were issued.
3. The Entra audit log: look for any new credentials, owners or consents on that or other apps, which would show persistence.

The honest bottom line is that without Graph activity logs, a sign-in followed by no UAL entries means you can’t prove what was read. Treat anything that app could read as potentially exposed, rotate its secrets, and remove or scope down its permissions. Then turn on Graph activity logs so next time you can prove it either way.

How to turn on Microsoft Graph activity logs

It takes about 10 minutes per tenant.

Before you start

• Licensing: Microsoft Entra ID P1 or P2 in the tenant (Business Premium includes P1).
• Role: Security Administrator is the least privileged Entra role Microsoft supports for creating diagnostic settings. You also need Azure rights on the destination.
• An Azure subscription with a destination that already exists: a Log Analytics workspace (best for querying), a storage account (cheap long-term archive) or an Event Hub (to stream to a third-party SIEM).
• Cost: P1 doesn’t cover the Azure side, so you pay for what you ingest and store. Microsoft’s rough guide is about 15 GiB a month into Log Analytics per 1,000 users, but it varies a lot with the apps in the tenant. Check the Azure Monitor pricing page and consider a workspace transformation or the Basic table plan to cut costs.
• The logs are NOT retroactive. You only see activity from the moment you switch them on, so do it before you need them.

Step 1: Create a Log Analytics workspace

1. In the Azure portal, go to Log Analytics workspaces > Create.
2. Pick the subscription, a resource group, a name and a region, then Review + Create.

Step 2: Turn on the diagnostic setting (GUI)

1. Sign in to the Microsoft Entra admin centre as at least a Security Administrator.
2. Browse to Entra ID > Monitoring & health > Diagnostic settings.
3. Select Add diagnostic setting and give it a name.
4. Tick MicrosoftGraphActivityLogs. While you’re there, also tick ServicePrincipalSignInLogs, SignInLogs and AuditLogs, so you can correlate them.
5. Tick Send to Log Analytics workspace and choose your subscription and workspace.
6. Save.

Step 2 (alternative): PowerShell

There’s no dedicated Entra cmdlet for this. New-AzDiagnosticSetting targets Azure resources, not the tenant. Instead, you PUT to the Azure Resource Manager endpoint for microsoft.aadiam/diagnosticSettings with Invoke-AzRestMethod:

Connect-AzAccount
$ws = "/subscriptions/<SUB-ID>/resourceGroups/<RG>/providers/Microsoft.OperationalInsights/workspaces/<WORKSPACE>"
$body = @{
  properties = @{
    workspaceId = $ws
    logs = @(
      @{ category = "MicrosoftGraphActivityLogs"; enabled = $true },
      @{ category = "ServicePrincipalSignInLogs"; enabled = $true }
    )
  }
} | ConvertTo-Json -Depth 5
Invoke-AzRestMethod -Method PUT -Payload $body `
  -Uri "https://management.azure.com/providers/microsoft.aadiam/diagnosticSettings/GraphActivity?api-version=2017-04-01"

The Azure CLI equivalent is az rest --method put --url "<same URL>" --body @body.json.

Step 3: Check it’s working

Microsoft says delivery is usually within 30 minutes, but allow time for the table to first appear (Entra’s docs allow up to three days). Then run:

MicrosoftGraphActivityLogs
| where TimeGenerated > ago(1d)
| summarize Requests = count() by AppId, ServicePrincipalId
| sort by Requests desc

To tie Graph calls back to a service principal sign-in, which is exactly the GCIT approach:

MicrosoftGraphActivityLogs
| where TimeGenerated > ago(7d)
| join kind=leftouter (AADServicePrincipalSignInLogs | where TimeGenerated > ago(7d))
    on $left.SignInActivityId == $right.UniqueTokenIdentifier
| project TimeGenerated, AppId, ServicePrincipalName, IPAddress, RequestMethod, RequestUri, ResponseStatusCode

Tips

• Set retention on the workspace (or per table) to suit your incident response needs. If you need it for years, also archive to storage.
• Do this per customer tenant. A Graph activity log only covers the resource tenant, so you won’t see a multitenant app’s activity in other tenants.
• Diagnostic settings can’t filter Graph logs. Use a workspace transformation if volume is an issue.

References: Graph activity logs overview and Configure Entra diagnostic settings.

What I’d do today, with the tools we have

1. Turn on Graph activity logs now in every tenant with P1 (Business Premium has it). It’s cheap insurance.
2. Export sign-in logs, including service principal sign-ins, beyond 30 days.
3. Confirm MailItemsAccessed is being audited on every mailbox.
4. Cut app permissions down. Use Exchange RBAC for Applications and Sites.Selected instead of tenant-wide Mail.* and Sites.* grants. https://learn.microsoft.com/en-us/exchange/permissions-exo/application-rbac
5. Use Defender for Cloud Apps app governance where you have it, so you get alerts on unusual app behaviour. https://learn.microsoft.com/en-us/defender-cloud-apps/app-governance-manage-app-governance

Shared responsibility

This is the shared responsibility point again. The vendor protects its credential, Microsoft provides the logs, and we as MSPs own the decision to let that app in, which means having the logging on before we need it. My cw-skykick-exposure-check.ps1 script will help you with the exposure side. Graph activity logs are what answer “what did it actually touch?”