Microsoft 365 Entra ID security incident

What Did the Backup App Read? The Log That Could Tell You Had to Be On Already

After the ConnectWise Cloud Backup (SkyKick) credential was used against Microsoft 365 tenants, every affected organisation gets the same question: what did it read? Mail reads are usually audited. Directory reads are not, unless Microsoft Graph activity logs were on before the incident.

Marc Dekeyser |

What Did the Backup App Read? The Log That Could Tell You Had to Be On Already

Someone in your organisation is going to ask it this week. Possibly your CISO, possibly a board member who saw the headline. “Okay, the backup app was compromised. What did they take?”

And ConnectWise has already told you it can’t answer that for you. Its advisory says Cloud Backup “does not provide the downstream security visibility needed for us to determine independently whether a particular partner or customer tenant experienced unauthorized activity.” That’s an honest sentence. It also hands the question straight back to you.

So the question is yours. Can you answer it?

Quick recap, for the three people who missed it

On 15 October a certificate belonging to ConnectWise Cloud Backup (the app formerly known as SkyKick Backup) was used to request Microsoft Graph tokens, tenant after tenant, from one IP address. Huntress counted almost 1,000 Entra tenants with sign-in activity from that address, over 300 of them successful, and 162 with unauthorized sign-ins confirmed by the evening of 16 October. In at least one tenant a second ConnectWise app made itself Global Administrator, and new client secrets appeared on two other apps.

No user password, no MFA prompt, no user at all; the app’s own credential was the thing that leaked. Merill Fernando’s video explains the multi-tenant mechanics and the Huntress write-up has the IOCs. I’m not going to redo either.

I want to talk about the morning after.

Three kinds of reading, three different answers

A backup app is allowed to read nearly everything, because that is its job. Mailboxes, OneDrive, SharePoint, Teams, depending on what each tenant consented to. And to find all of that it reads the directory: users, groups, who owns what. Microsoft’s assessment says the actor likely abused previously granted permissions “including Directory.ReadWrite.All”.

So “what did it read” splits into parts, and each part has a different log behind it.

Mail. Probably answerable. The MailItemsAccessed audit action covers every mail protocol including REST, and Microsoft documents it as enabled by default for users with an E3 or E5 licence. If your mailboxes are licensed that way, the unified audit log records individual message access by InternetMessageId. (Aggregated in two-minute windows, and sync access is logged per folder rather than per message, but it’s there.)

Files. SharePoint and OneDrive keep their own audit records. Go look; that part is a separate afternoon.

The directory. This is the one that hurts. Huntress, in its own write-up: “Directory reads through Microsoft Graph leave no audit trail.” That’s true of the logs every tenant has by default. The Entra audit log records changes. Reads don’t change anything, so nothing is written. Which users exist, which groups they’re in, which apps hold which roles, which service principals already carry credentials. A complete map of your tenant, and the default logs are silent about whether someone took it.

And that map is not an academic loss. Look at what happened next in this incident: secrets were added to two specific, already trusted apps in a partner tenant. Huntress hasn’t said how those apps were chosen, or even tied that step to the same operator yet. But if I wanted to choose which apps to backdoor, a directory read is exactly where I’d start.

The log that would have answered it

Microsoft Graph activity logs. They record every HTTP request Graph receives for your tenant: the app ID, the service principal, the IP address, the request URI, the response code, the user agent, and whether the client authenticated with a secret or a certificate (ClientAuthMethod 2 means certificate). It also records the response size. What it does not record is the response itself. So you get a line along the lines of “service principal X, from 144.172.64.128, GET /users, 200, so many bytes, python-requests”, and you don’t get the list of users that came back. That’s a limitation, until you compare it with nothing at all. Knowing it paged through your users and app registrations is an answer. Not knowing whether it asked is not.

The catch is in the setup. You need an Entra ID P1 or P2 licence, and you have to route the logs somewhere through diagnostic settings: a Log Analytics workspace, a storage account or an Event Hub. Microsoft’s own docs describe it as something tenant admins “turn on.”

So it records from the day you turn it on. If that day was after 15 October, the reads that mattered are gone, and nothing will bring them back.

“But that’s going to cost a fortune in Log Analytics”

It can. Microsoft’s estimate for a 1,000-user tenant is about 15 GiB a month into Azure Monitor Logs, and around 1,200 GiB at 100,000 users. Price that at Analytics-tier ingestion and finance will have opinions. Fair.

Now look at the other column in that same table. Storage: 14 GiB a month at 1,000 users. A storage account as a diagnostic-settings destination is cheap by comparison (price it for your region and retention, but it won’t be the Log Analytics number), and it does one job, which is to exist when someone asks the question.

My position, and I’m aware it’s a slightly lazy one: send Graph activity logs to a storage account today, in every tenant you own that has a third-party app with application permissions. Don’t build detections on it yet. Don’t put it in the SIEM yet. Just make sure that the next time a vendor’s key leaks, the answer to “what did they read” is a query you run rather than a shrug you deliver. Log Analytics, Basic plans, workspace transformations: argue about those later. Later is fine. Before the incident is the only part that isn’t.

(Yes, I see the irony of telling people to turn on a log after the incident that proved they needed it. That’s how every log gets turned on.)

One limitation, so nobody oversells this

Graph activity logs show you what happened in your tenant. Microsoft says plainly that they don’t “allow you to see the activities of a multitenant application in another tenant.” If you’re an MSP with customer tenants under GDAP, the logging has to be on in each customer tenant. Yours tells you nothing about theirs. Which is the same lesson again, multiplied by your customer list.

It also prevents nothing. The token still gets issued and the secret still gets added. Stopping those is a job for other controls; the tenant-wide app management policy that blocks password addition on applications and service principals would have rejected those secrets unless an exception covered those apps, and that’s worth turning on this week too. But prevention gets the attention after every incident. Evidence never does, and evidence is what you get asked for.

What I’d check on Monday

  • Entra ID > Monitoring & health > Diagnostic settings. Is MicrosoftGraphActivityLogs going anywhere? If not, that’s the first fix, and it’s one diagnostic setting.
  • Before 15 October, did it go anywhere? If yes, query for the ConnectWise Cloud Backup app ID 506e08f9-6e9a-4da4-942b-a099a03644ae and the IP 144.172.64.128, then work through the rest of the Huntress IOC list (other ConnectWise app IDs, the user agents). A hit tells you which endpoints were called. A clean result on two indicators rules out less than it feels like.
  • If not, write down now that directory reads can’t be ruled in or out. “We don’t know” is an acceptable answer to a board. Discovering it in week three is not.

The vendor told you it can’t see into your tenant. Fine. The question is whether you can.

Sources and verification (checked 18 October 2026)

Note on the numbers: several outlets report 173 tenants. That figure doesn’t appear in the Huntress write-up; this piece uses Huntress’s own counts. The incident is still developing.

Want a second pair of eyes on it?

Ask for a free second opinion