Many cybersecurity incidents do not start with sophisticated malware or advanced exploits. Instead, they often begin with simple misconfigurations and poor credential practices. When these weaknesses combine, attackers can move from reconnaissance to full data compromise surprisingly quickly.
This case study details an incident involving:
- An exposed Spring Boot Actuator endpoint
- Plaintext credentials stored in a spreadsheet
- A risky authentication method (ROPC)
These vulnerabilities ultimately allowed attackers to compromise a SharePoint service account of the target organization and exfiltrate data from SharePoint Online.
**Phase 1: Exposed Spring Boot Actuator**
Spring Boot is a Java framework designed to make building production-ready web applications and microservices fast and simple. On the other hand, Spring Boot Actuator is a built-in module that provides operational information about a running Spring Boot application. In this incident, Spring Boot Actuator endpoints were exposed without authentication. The requests returned an HTTP 200 status code and revealed sensitive information.
Figure 1: Spring Boot Actuator logs
Download Although no plaintext credentials were revealed, the /configprops endpoint exposed valuable information, including a configuration block related to SharePoint integration.
The exposed configuration revealed:
- The username of the SharePoint service account
- The SharePoint host URL
- Site name: Dynamic365
- Configuration source: application.yml
- Password field: masked (******)
Even though the password was masked, the threat actor learned that a valid account existed and that the credentials were stored in application.yml. This information served as valuable reconnaissance data that narrowed their attack surface.
**Phase 2: Plaintext secrets in a spreadsheet**
During our investigation, analysts discovered that sensitive secrets for an internal application were stored in plaintext within a spreadsheet. The spreadsheet contained credentials related to the internal Azure AD application, which we will refer to as [REDACTED]-2024 in this entry, specifically the following values:
- client-id
- client-secret
- secret-id
These values corresponded to the authentication credentials used by [REDACTED]-2024 to request tokens from Azure AD. Application secrets function similarly to passwords: anyone who possesses the client ID and client secret of an application can attempt to authenticate as that application and request tokens from Azure AD.
Because these secrets were stored in a spreadsheet:
- They could be easily copied or leaked
- They could bypass any centralized secret management controls
- Anyone with access to the file could impersonate the application
This is a common operational security issue when development or testing credentials are documented informally for convenience.
**Phase 3: Authentication abuse – ROPC login**
ROPC allows an application to sign in the user by directly handling their password. Instead of redirecting the user to a login page, the application collects the credentials and sends them to the identity provider.
Typical ROPC Flow
1. An application sends a request containing the:
- client-id
- client-secret
- username
- password
to the identity provider (Azure AD/Entra ID).
2. The identity provider validates the credentials.
3. If valid, it returns an access token.
4. The application uses the token to access APIs such as Microsoft Graph, SharePoint Online, or OneDrive.
The threat actor’s first two attempts to authenticate resulted in errors due to a missing client_assertion or client secret. The first attempt was via Dynamics 365 Finance and Operations.