Critical Flaw in Azure AD Lets Attackers Steal Credentials

A recent cybersecurity assessment by Resecurity’s HUNTER Team uncovered a high-severity leak when Azure Active Directory (Azure AD) application credentials—specifically the ClientId and ClientSecret—were exposed in a publicly accessible appsettings.json file.

This critical misconfiguration effectively hands attackers the digital keys to the cloud environment, enabling unauthorized token requests against Microsoft’s OAuth 2.0 endpoints and giving adversaries a direct path to Microsoft Graph and Microsoft 365 data.

Misconfiguration Opens the Door to OAuth 2.0 Abuse

In the disclosed scenario, the appsettings.json file contained the full AzureAd configuration block—including "Instance": "https://login.microsoftonline.com/", "TenantId", "ClientId", "RedirectUri", and "ClientSecret"—and was unintentionally served as a static asset by the web server.

Armed with the leaked credentials, an attacker can execute the OAuth 2.0 Client Credentials flow:

bashcurl -X POST \
  -d "grant_type=client_credentials" \
  -d "client_id=<LEAKED_CLIENT_ID>" \
  -d "client_secret=<LEAKED_CLIENT_SECRET>" \
  -d "scope=https://graph.microsoft.com/.default" \
  https://login.microsoftonline.com/<TENANT_ID>/oauth2/v2.0/token

The response returns a Bearer access_token, valid for approximately one hour, which grants programmatic access to Graph API endpoints.

From there, adversaries can enumerate users (GET https://graph.microsoft.com/v1.0/users), list OAuth2PermissionGrants, query sensitive groups (/groups), and harvest directory information for further exploitation.

High-Impact Attack Scenarios and Persistence

Once authenticated, attackers can:

• Retrieve sensitive SharePoint, OneDrive, or Exchange Online data via Graph API calls.
• Enumerate users, groups, and roles, mapping out the tenant’s privilege model.
• Abuse permission grants to escalate privileges or install malicious service principals.
• Deploy rogue applications under the compromised tenant, creating persistence and backdoors.

Combining exposed Azure AD secrets with other leaked storage keys or database credentials in the same file amplifies the risk.

Attackers can pivot to storage account containers or Cosmos DB and extract production data without compromising the additional network.

Defense-In-Depth and Secrets Management

To eliminate this critical attack vector, organizations must adopt robust secrets management and secure deployment practices:

1. Block Public Access to Config Files
   Configure web servers (IIS, Nginx, Apache) to deny requests to *.json, *.config, and *.env files.
2. Remove Secrets from Source
   Leverage managed vaults such as Azure Key Vault, AWS Secrets Manager, or HashiCorp Vault to inject secrets at runtime rather than hard-coding them.
3. Rotate and Invalidate Exposed Credentials
   Immediately regenerate ClientSecret values and rotate any cloud-service keys should a leak occur.
4. Enforce Least Privilege on App Registrations
   Assign minimal Graph API scopes instead of tenant-wide permissions; avoid granting Directory.Read.Unless strictly required.
5. Continuous Security Testing and Monitoring
   Integrate automated scans (SAST/DAST), pen tests, and code reviews to detect leaked configuration files. Enable Azure AD logs and alerts on suspicious service principal authentications.

Exposing appsettings.json With tenant credentials is no mere oversight—it is a direct invitation to cloud compromise.

As cloud adoption accelerates, configuration security must be treated with the same rigor as application logic to prevent tomorrow’s headline breaches.

Find this Story Interesting! Follow us on Google News , LinkedIn and X to Get More Instant Updates