You don’t need to hack a government agency when its API credentials are already public.

While browsing public Postman workspaces, I found a collection belonging to an Asian municipal government agency responsible for emergency services and public safety. Inside that collection, accessible to anyone, was a client_id and client_secret for their Microsoft Power BI environment. No authentication required. No access controls. Fully indexed and searchable.

I had access to their operational data before I finished my coffee.

No phishing. No exploit. No foothold to establish, no privileges to escalate. The attack chain that normally takes days — reconnaissance, initial access, persistence, lateral movement — was completely irrelevant. One credential pair skipped it all.

What followed wasn’t access to a demo environment or sample data. It was live emergency dispatch records, active personnel files, and operational data belonging to a public institution responsible for keeping people safe.

This is not a story about a sophisticated attack. It’s about what happens when API secrets are treated as application config — and why Microsoft Power BI, often overlooked, is the crown jewel that most organisations forget to protect.

Why Power BI Is the Crown Jewel

Most organisations think about data security at the source — the database, the data warehouse, the application. Power BI sits one layer above all of that.

Power BI is Microsoft’s business intelligence platform. It connects to dozens of data sources simultaneously — finance systems, CRM platforms, HR databases, operational tools — and aggregates them into reports and dashboards that executives use to make decisions. It is, by design, a single pane of glass across the entire organisation’s data landscape, which is exactly what makes it dangerous when credentials are exposed.

Compromising a finance database gives you finance data. Compromising a CRM system gives you access to customer records. Compromising Power BI can give you both — along with HR metrics, sales pipelines, operational KPIs, and whatever else the organisation has connected to it. An attacker who gains access to Power BI doesn’t need to map the data estate. Someone already did that work and called it a dashboard.

Despite this, Power BI rarely features in threat models. Security teams focus on perimeter controls, identity providers, and cloud infrastructure. Business intelligence platforms are treated as internal tools rather than as attack surfaces — which is precisely why they are attractive targets.

The Power BI REST API makes this exposure programmatic. With a valid service principal — an application identity authenticated via client_id and client_secret - an attacker can enumerate workspaces, list reports and dashboards, query underlying datasets, and extract data at scale. No GUI required. No user interaction. Just API calls.

When those credentials end up in a public Postman workspace, the blast radius is immediate.

What the Kill Chain Normally Looks Like — and What Got Skipped

Before getting into what I found and what it unlocked, it’s worth stepping back to understand what didn’t happen.

A typical attack against an enterprise target follows a predictable chain. The attacker starts with reconnaissance — mapping the target’s infrastructure, identifying employees, and enumerating exposed services. From there, initial access: a phishing campaign, an exploited vulnerability, a brute-forced credential. Once inside, persistence mechanisms are established so access survives reboots and detection attempts. Privilege escalation follows — moving from a low-privilege foothold to something more useful. Then the lateral movement, pivoting across systems until the attacker reaches the data they came for.

Each stage takes time. Each stage creates noise. Each stage is a detection opportunity.

Leaked API credentials skip all of it.

There is no reconnaissance phase because the credentials are already public. There is no initial access challenge because the API accepts the token without question. There is no persistence to establish, no privileges to escalate, and no lateral movement required. The attacker arrives directly at the target — authenticated, authorised, and indistinguishable from a legitimate service account.

The diagram below illustrates what this looks like in practice. A six-stage attack chain on the left. Three steps on the right. Same destination.

This is what makes credential exposure categorically different from most other vulnerability classes. It doesn’t weaken the kill chain — it eliminates it. And when the destination is Power BI, the attacker doesn’t just reach a system. They reach every system the organisation chose to connect to.

From Credentials to Data: No Enumeration Needed

The first step was straightforward: validate that the credentials were still active.

Power BI uses Microsoft’s OAuth 2.0 client credentials flow for service principal authentication. To obtain an access token, you send a POST request to Microsoft’s Azure AD token endpoint, passing the client_id, client_secret, and tenant_id. If the credentials are valid, the response returns a bearer token. The entire exchange takes seconds.

The token came back immediately. The credentials were live.

Defender note: Token requests to login.microsoftonline.com from suspicious IP addresses or outside business hours are a detection signal. Service principal authentication events are logged in Azure AD - if no one is monitoring them, this step is invisible.

With a valid token, the next call was to the Power BI REST API to list all workspaces to which the service principal had access. The response returned workspace names, IDs, and metadata — a ready-made map of the organisation’s entire Power BI environment: no guessing, no enumeration, no trial and error. The API handed it over in a single call.

From there, listing reports and dashboards within each workspace took one additional request per workspace. Within minutes, the full inventory was visible: report names, dataset references, owners, and last-modified timestamps. Enough to understand what data the organisation tracks, how it is structured, and who is responsible for it.

The final step was querying the underlying datasets directly. The Power BI REST API supports DAX queries — the query language Power BI uses to retrieve data from connected sources. Submitting a query against an exposed dataset returns the actual data: figures, records, metrics, whatever the dataset contains.

No GUI. No dashboard login. No user interaction of any kind. Just a sequence of authenticated API calls, each building on the last.

It took 10 minutes from a valid token to a dataset query.

Defender note: Power BI has a dedicated audit log, available via the Microsoft 365 compliance centre, that records dataset exports, DAX queries, and workspace access. Most organisations have it disabled or unmonitored. If enabled, every step above generates a log entry tied to the service principal identity.

What the Data Actually Looked Like

The datasets accessible via the exposed credentials did not contain sample data or synthetic records. They contained live operational information belonging to a public institution responsible for emergency response.

The first dataset that surfaced was an emergency dispatch log. Each record contained a case number, timestamp, case type, service category, incident address, assigned dispatch unit, and response duration. This was not historical archive data — the most recent entries were timestamped within hours of access. An attacker with this information would have a real-time view of emergency response operations: where units were deployed, how long responses took, and which areas generated the highest call volumes.

The second category was personnel statistics — aggregated data broken down by office, covering headcount, average age, average years of service, and gender distribution. Enough to map the organisational structure of an emergency services agency and identify staffing patterns across operational units.

The third and most sensitive dataset contained individual personnel records. Each record included full name, employee ID, national identification number, date of birth, job title, unit assignment, office location, and employment start date. This was not a summary or an aggregate — it was a row-level export of a human resources system, one record per employee.

The combination of operational dispatch data and individual personnel records represents a significant exposure. Dispatch logs reveal how an emergency services agency operates in real time. Personnel records reveal who works there, when they started, and how to identify them. Together, they create a profile of an organisation that exists to protect the public, exposed by a single credential pair left in a public Postman workspace.

None of this required exploiting a vulnerability. The API worked exactly as designed.

The Real Risk Isn’t the API

The Power BI API worked exactly as designed. It authenticated a valid service principal, returned the data it was authorised to access, and logged nothing because the audit log was disabled. There was no vulnerability to patch. No misconfiguration to remediate. The system functioned correctly — the problem was entirely upstream.

A client_id and client_secret were treated as application config rather than secrets - committed to a Postman collection, published to a public workspace, and left indexed and searchable.

This is the actual attack surface — not the API, not Power BI, not Microsoft. The attack surface is the assumption that credentials embedded in developer tooling are safe because they are not in the codebase. This finding is not an outlier. Over 18 months of monitoring public Postman workspaces, the pattern is consistent: organisations of every size and sector leave live credentials exposed in plain sight. The full scope of that research is documented in Secrets in the Wild: 2025.

What organisations should do:

Audit public Postman workspaces now. Search for your organisation’s domain, product names, and known service identifiers. If credentials appear, rotate them immediately — do not wait for confirmation of exploitation.

Enable Power BI audit logging via the Microsoft 365 compliance centre. Dataset exports, DAX queries, and workspace access events should be monitored and alerted on. Service principal activity outside business hours or from unexpected IP ranges warrants immediate investigation.

Treat service principal credentials as secrets, not config. They belong in a secrets manager — Azure Key Vault, HashiCorp Vault, or equivalent — not in Postman collections, README files, or environment variables committed to version control. The broader implications of exposed service principals — including how the same credential type can be abused across Microsoft Graph API endpoints — are covered in detail in Microsoft Graph API Attack Surface: OAuth Flows, Abused Endpoints, and What Defenders Miss.

Review service principal permissions regularly. Least privilege applies here as it does everywhere. A service principal that only needs to read one dataset should not have access to every workspace in the tenant.

The data accessible in this case belonged to a public institution responsible for emergency response. The people whose records were exposed did not make a mistake. Their employer did not make a mistake. A credential ended up where it should not have been — and the rest required no skill at all.