When a GDAP vendor is breached, check your own tenant

On 7 November 2026, MSP Process told its partners that an attacker had access to one of its storage accounts between 09:56 and 14:40 UTC. That storage held what MSP Process needs to run its GDAP features (Authenticator, Password Reset and Contacts sync) for partners. MSP Process asked partners to treat it as compromised.

We've investigated across the partner tenants we monitor and contacted affected partners directly. The checks below apply to any third-party tool you've connected to GDAP, not just this one.

What was exposed

For each partner, MSP Process held three things:

• The client ID and secret of the Entra app the partner connected to MSP Process.
• The refresh token for the admin account that connected it.
• The partner's GDAP relationships: customer tenant names and IDs, and the roles granted.

Together, that's a map of your customers and a set of keys to them. MSP Process's own guidance listed permissions such as AppRoleAssignment.ReadWrite.All, Application.ReadWrite.All and Directory.ReadWrite.All. With those, someone could give an app more permissions, add secrets to other apps, or change group memberships, including the security groups your GDAP access is assigned to.

What we saw

For a small number of partners, MSP Process apps were used from an address that wasn't MSP Process'. The pattern was the same each time:

• One address, 172.169.63.30, used several partners' app secrets within the same few seconds. That looks scripted.
• The first attempts, from about 10:28 UTC, failed with "invalid client secret" and "missing service principal" errors.
• About an hour later, between 11:30 and 11:31 UTC, the same address got Microsoft Graph tokens using each app's secret.
• Where it tried an admin's stored refresh token, the attempt failed because the token had already expired through inactivity.

We found no changes made by those apps afterwards: no new users, app permissions, secrets, roles or GDAP group changes. Sign-in and audit logs can't show what was read with those tokens. Only Microsoft Graph activity logs record this information, and most tenants don't have them turned on.

Look in your own tenant first

Every one of those sign-ins was logged in the MSP's own tenant, where the app is registered, not in a customer tenant. That's where a partner app's own token requests are recorded.

It's also the tenant many MSPs watch least. Customer tenants are consistently monitored, and alerts are set up for suspicious behavior, while the MSP's own tenant often isn't connected to anything. The partners we could check properly were the ones whose own tenant we already monitored. For everyone else, any evidence sits only in their own Entra logs.

What to check now

If you use MSP Process, or any tool that holds an app secret and an admin token for your GDAP relationships, check your Entra logs soon. Entra keeps sign-in logs for 7 days on Entra ID Free and 30 days on P1 or P2.

In the Entra admin center, in the tenant where the app is registered:

1. Go to App registrations, find the app you connected to the vendor, and note its application (client) ID.
2. Open Sign-in logs, then the Service principal sign-ins tab. Filter by that application ID from 09:56 UTC on 7 November.
3. Look for any IP address other than the vendor's. For MSP Process, that's 64.236.54.139.
4. Repeat on the User sign-ins (non-interactive) tab. That's where use of an admin's refresh token shows up.
5. In Audit logs, filter by the app as the initiator and look for new credentials, app role assignments, group membership changes or new users.

If you send Entra logs to Log Analytics or Sentinel, these queries do the same job. Swap in your own app ID.

AADServicePrincipalSignInLogs
| where TimeGenerated > datetime(2026-11-07T09:56:00Z)
| where AppId == "<your app ID>"
| where IPAddress != "64.236.54.139"
| project TimeGenerated, IPAddress, ResultType, ResultDescription, ResourceDisplayName, UniqueTokenIdentifier
AADNonInteractiveUserSignInLogs
| where TimeGenerated > datetime(2026-11-07T09:56:00Z)
| where AppId == "<your app ID>"
| where IPAddress != "64.236.54.139"
| project TimeGenerated, UserPrincipalName, IPAddress, ResultType, ResultDescription
MicrosoftGraphActivityLogs
| where TimeGenerated > datetime(2026-11-07T09:56:00Z)
| where AppId == "<your app ID>"
| where IPAddress != "64.236.54.139"
| summarize Requests = count() by RequestMethod, RequestUri, IPAddress

The last query only works if Graph activity logs were already flowing to Log Analytics on 7 November. If the first query finds a token, its UniqueTokenIdentifier matches SignInActivityId in the Graph activity logs, so you can see exactly what that token did.

What to do either way

The vendor has asked partners to treat these credentials as compromised, so we'd do this whether or not you find anything:

1. Delete the app's client secret. Only add a new one once the vendor confirms it's safe to reconnect.
2. Disable the app's service principal in your own tenant and in any customer tenants where it's installed, until you reconnect.
3. Revoke sessions for the admin account that connected the app.
4. Check the security groups your GDAP relationships are assigned to for members you don't recognise.
5. Check the app hasn't been given new permissions or credentials since 7 November.

Step 1 does most of the work. A refresh token issued to an app like this can't be redeemed without the app's secret, so deleting the secret shuts off both.

What we'd change for next time

• Ask why a tool needs each permission. AppRoleAssignment.ReadWrite.All on its own lets an app grant itself almost any other permission.
• Prefer certificates to client secrets where the vendor supports them, and keep secret lifetimes short.
• Restrict where the app can sign in from, where you can. Conditional Access for workload identities (Workload Identities Premium) can limit a service principal to known IP addresses. It only covers single-tenant apps registered in your tenant, so most multi-tenant partner apps fall outside it.
• Turn on Microsoft Graph activity logs before you need them. They're the only record of what an app token actually read.
• Monitor your own MSP tenant as closely as your customers'. It's where your GDAP access and your vendors' apps live.
• Ask your vendors three questions. Where are our credentials stored, and how are they protected? Which IP addresses will connect on our behalf? How quickly will you tell us if something goes wrong?

172.169.63.30 is a shared Microsoft Azure address, and we've seen unrelated apps use it too. Treat a match as a lead, not proof, and don't rely on blocking it.

If you find something

If you see activity from an unexpected address, or anything else that doesn't look right, we're happy to go through it with you. inforcer partners can reach out to their Partner Success Manager or start a chat in the platform.

And if you've seen something we haven't, please share it. Incidents like this move fast, and the more MSPs compare notes, the quicker everyone gets on top of them.