← All field notes
atlassianconfluencesaasdata exfiltration

The wiki that stores your runbooks and your secrets

Confluence and Jira hold architecture, runbooks, and the credentials teams paste into pages. A stolen token or an over-scoped app reads it all, no exploit required. Here is the risk, and the fix.

Attack flow
1Steal an Atlassian token or install a broad app
2Read spaces, pages, and issues
3Search for credentials and architecture
4Export content
5Pivot with what was found
Seen in the wildAccess brokersOpportunistic

The page that documents how everything connects usually documents the passwords too.

What it is

Atlassian Confluence and Jira hold the organization’s documented knowledge: architecture, runbooks, onboarding, and the passwords, keys, and connection strings teams paste into pages and tickets. An attacker with a stolen API token or an over-scoped Connect app reads spaces, pages, and issues, searches for secrets, exports content, and uses what they find to pivot. This is T1528 (steal application access token) with T1213 and T1567.

Why it works

It uses valid APIs, the content is both a map of your environment and a cache of live credentials, and tokens often bypass MFA. No exploit is required.

How to detect it

Look for a token or app reading content at unusual breadth, searches for credential-like terms, bulk exports, and a newly installed broad-scope app, in the Atlassian audit logs.

The fix that holds

Require admin approval for apps and keep them least-scope, keep tokens out of code and rotate them, keep secrets out of pages (use a vault), and alert on bulk reads and broad app installs.

Practice it

We built an Atlassian token-abuse scenario in GraphLattice Range so teams learn to treat the wiki as sensitive and govern its tokens and apps.