Azure AD Vulnerability Leaks Credentials, Lets Attackers Deploy Malicious Apps

Exposing an ASP.NET Core appsettings.json file containing Azure Active Directory (Azure AD) credentials poses a critical attack vector, effectively handing adversaries the keys to an organization’s cloud environment.

During a recent cybersecurity assessment by Resecurity’s HUNTER Team, researchers discovered that a publicly accessible appsettings.json file had exposed the ClientId and ClientSecret of an Azure AD application, allowing any attacker to authenticate directly against Microsoft’s OAuth 2.0 endpoints and act as a trusted application.

High-Severity Impact

With the leaked ClientId and ClientSecret, attackers can request OAuth 2.0 tokens via the Client Credentials flow, obtaining a Bearer token that grants access to Microsoft Graph APIs. Depending on the application’s assigned Graph permissions, this token enables:

• Retrieval of sensitive data from SharePoint, OneDrive, and Exchange Online
• Enumeration of users, groups, and directory roles in Azure AD
• Abuse of Graph API calls for privilege escalation or persistence
• Deployment of malicious applications under the tenant

Because the file was served without access controls, any automated scan or determined adversary could harvest these secrets and immediately compromise cloud accounts, exfiltrate data, or move laterally into production services.

This vulnerability typifies common misconfigurations and poor secrets management in cloud-native apps. In local development, developers often store sensitive values—such as ClientId, ClientSecret, storage keys, or database passwords—in plain configuration files. Problems arise when:

• Servers are misconfigured to serve static files, unintentionally exposing JSON configs.
• Deployment pipelines push internal configuration files to production without access restrictions.
• Teams bypass secure vaults (Azure Key Vault, AWS Secrets Manager) and hardcode secrets.
• Lack of regular security testing or code reviews allows exposed files to go unnoticed.
• Overreliance on secrecy assumes that “no one will find” internal files, ignoring automated crawling tools.

Anatomy of the Leak

In ASP.NET Core applications, appsettings.json is the primary configuration file, storing connection strings, API keys, cloud credentials, logging settings, feature flags, and, in the AzureAd section, fields like Instance, TenantId, ClientId, RedirectUri, and ClientSecret.

When publicly accessible, these values become a launchpad for adversaries to impersonate legitimate applications.

1. Token Acquisition. Attacker submits a POST to Azure AD’s /oauth2/v2.0/token endpoint with the leaked ClientId and ClientSecret to obtain a Bearer token.
2. User Enumeration. Using the token, the attacker calls GET https://graph.microsoft.com/v1.0/users to list all tenant users, harvesting names, email addresses, and object IDs.
3. Permission Grants. A subsequent GET https://graph.microsoft.com/v1.0/oauth2PermissionGrants reveals which permissions the compromised app holds.
4. Group Enumeration. A call to GET https://graph.microsoft.com/v1.0/groups exposes organizational groups, highlighting targets in high-privilege clusters such as Global Administrators.

With these capabilities, adversaries can exfiltrate data, escalate privileges, register rogue applications for persistent access, and even tamper with cloud resources.

Organizations must enforce strict file-access controls, exclude configuration files from public hosting, and adopt robust secret management practices.

Migrating secrets to secure vaults, integrating automated scanning for exposed credentials, conducting regular penetration tests, and enforcing least-privilege Graph permissions will greatly reduce the risk of such leaks.

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