Leaked Azure Client Secret? Rotate the App Secret

An Azure client secret is the password of an application registration in Microsoft Entra ID (formerly Azure AD). A script or service presents it, together with the application’s client ID and tenant ID, to get an access token and act as that application. What it can do is whatever the application was granted: reading directory data through Microsoft Graph, managing Azure resources through role assignments, sending mail. Rotate the secret first, then work out what the application could reach.

Check your GitHub account for leaked secrets — free

Provider: Azure
Severity: Critical
Impact: Cloud infrastructure access
Checked live by LeakWatch: Yes

What an Azure client secret looks like

A secret on its own is not enough to sign in: it only works together with the client ID and the tenant ID, both of which are GUIDs. Those two are identifiers rather than secrets, but they tell an attacker exactly where to use the secret, so they usually appear in the same file.

Secrets created by the portal today contain a recognizable Q~ marker in the middle:

AZURE_CLIENT_ID=<guid>
AZURE_TENANT_ID=<guid>
AZURE_CLIENT_SECRET=…Q~…XXXX    (masked)

Older secrets and ones created through scripts may not contain the marker, so LeakWatch also looks for secret-like values next to names such as client_secret, AZURE_CLIENT_SECRET or clientSecret.

This is a different thing from an AWS key pair, a Google API key or a storage account key. A storage account key or SAS token (sig=…) unlocks one storage account, not an application identity. And a certificate credential on the same app registration is rotated in the same blade but is a private key, not a string secret.

How Azure client secrets get leaked

Environment files for Azure SDKs. The standard variables AZURE_CLIENT_ID, AZURE_TENANT_ID and AZURE_CLIENT_SECRET live in a .env that gets committed.
CI/CD service connections. A secret pasted into a GitHub Actions workflow, an Azure DevOps variable that is not marked secret, or the JSON blob produced by az ad sp create-for-rbac, which prints the secret exactly once.
Infrastructure code. Terraform *.tfvars files and state files, Bicep parameter files, ARM templates and Ansible variables.
App configuration. appsettings.json or application.yml with the secret inline instead of Key Vault.
Support requests and screenshots of the Certificates & secrets page taken right after creating the secret, when the value is still visible.

What to do in the first hour

Add a new secret, then delete the old one. In the Microsoft Entra admin center go to Identity → Applications → App registrations, open the application, then Certificates & secrets → Client secrets. The list does not show the value after creation, so match the leaked one by description, creation date or secret ID. Create a new secret, update the services that use it, then delete the exposed one. Entra supports several active secrets at once, so there is no downtime.
Prefer a credential that cannot leak. For workloads running in Azure, use a managed identity. For GitHub Actions and similar CI, use workload identity federation. Both remove the long-lived secret altogether.
Check what the application can do. Open API permissions and note the application permissions (not delegated ones) and whether admin consent was granted. Then in Azure, open Access control (IAM) on subscriptions or resource groups and look for role assignments held by this application.
Look for the secret being used. In Monitoring & health → Sign-in logs, open the Service principal sign-ins tab and filter by the application ID for the period since the exposure. Unfamiliar IP addresses, locations or resources are the signs. Keep in mind that any token request counts as a sign-in, so unknown activity is a reason to look closer, not proof by itself.
Look for persistence. Open Audit logs and filter on the application. Events such as adding credentials to the application or service principal, changing permissions or granting consent are what an attacker with write access would do to keep a way back. Also check the application’s list of owners.
Rotate what it could reach. If the application could read Key Vault, storage or databases, treat those secrets as exposed and rotate them.
Then clean the repository: remove the value and rewrite history if you want to. See I accidentally pushed an API key to GitHub.

Not sure what else leaked from the same repository? Run a free scan.

Not sure what else leaked? Run a free scan.

Revoke it at Microsoft Entra

Sign in to the Microsoft Entra admin center with an account that owns the application or has an application administrator role. Open App registrations, select the application, go to Certificates & secrets and delete the exposed entry under Client secrets. A deleted secret stops working for new token requests; access tokens already issued remain valid until they expire, which is usually within about an hour. If you cannot find the application, check that you are in the correct tenant (the tenant ID is in the leaked configuration), and look under Enterprise applications for the matching service principal.

How LeakWatch detects it

LeakWatch has three rules for Azure secrets: a context rule for client_secret-style assignments, one for the Q~ format, and one for a newer format of similar shape. This type is checked live, with a condition: the check needs the client ID and tenant ID, which it reads from the text around the secret. It then performs a client-credentials token request, which is the same call your own application makes, and never uses the resulting token to call Graph or Azure. A secret found without its GUIDs is reported as detected, not confirmed live. Note that the token request appears as a service principal sign-in in your logs.

LeakWatch can check whether a detected key is still active with a read-only request to Azure. It never reads your data or spends your credits.

FAQ

Which of the three values is the secret: the client ID, tenant ID or secret?

Only the secret. The client ID and tenant ID are identifiers and are visible in many places. But the secret is what makes them dangerous, so rotating the secret is the fix; there is no need to recreate the application.

Does deleting the secret sign out the attacker immediately?

New token requests fail immediately. Tokens already issued stay valid until they expire, so they can still be used for a short time. That is why checking the sign-in and audit logs afterwards still matters.

What if the secret expired already?

An expired secret cannot be used. But a leak is still worth a look: check whether the same value was reused elsewhere, and whether newer secrets were committed in the same file or commit history.