Live Active security incident? Get immediate response
MITRE ATT&CK® Detection Strategy

DET0358: Programmatic and Excessive Access to Confluence Documentation

This detection strategy matters because Confluence can hold high-value business and technical knowledge: policies, procedures, standards, network and syste...

EnterpriseDET0358Detection StrategyObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This detection strategy matters because Confluence can hold high-value business and technical knowledge: policies, procedures, standards, network and system architecture diagrams, technical documentation, and sometimes development or testing credentials. Programmatic or excessive access to that content can be an early warning that a SaaS knowledge base is being mined for collection rather than used normally. For leaders, the practical question is whether Confluence access patterns are visible enough to distinguish routine collaboration from bulk or automated harvesting.

Executive priority

Treat this as a knowledge-protection and incident-readiness priority for SaaS documentation. Confluence often concentrates operational context that can accelerate an intrusion or expose sensitive internal design information. Security leaders should ask whether Confluence audit evidence is retained, whether access is least-privilege, whether sensitive documentation is governed, and whether the SOC has a defined escalation path when unusually broad or automated documentation access is observed. This is also relevant to compliance readiness because the ability to show who accessed sensitive documentation, when, and at what scale is often necessary during investigations and audits.

Technical view

DET0358 is a detection strategy for T1213.001 Confluence, which is associated with the collection tactic on SaaS platforms. Because the official ATT&CK object provides no detection text, teams should validate coverage around the relationship context: excessive, broad, or programmatic access to Confluence documentation. Practical validation should focus on whether Confluence audit logs, authentication context, user identity, source address, API or automation indicators, page/view/export activity, and volume-over-time baselines are available to the SOC. Detection engineering should separate normal high-volume users, migrations, indexing, backups, integrations, and administrative activity from unusual access to many spaces, sensitive pages, or documentation categories over short periods.

Likely telemetry

  • Confluence audit logs for page views, exports, downloads, searches, space access, and administrative actions
  • SaaS authentication and session logs tied to Confluence access
  • Identity provider sign-in logs, including user, source IP, device, MFA status where available, and session timing
  • API token, service account, or integration activity associated with Confluence
  • Network or proxy logs showing automated or high-volume access to Confluence URLs where available

Detection direction

  • Confirm that Confluence audit logging is enabled, retained, and forwarded to the SIEM or detection platform with user and object-level detail sufficient for investigation.
  • Build baselines for normal Confluence usage by role, team, service account, integration, and time period before alerting on volume alone.
  • Look for combinations of signals such as unusually high page views, broad space traversal, repeated exports, access to architecture or credential-related documentation, or API-style access from identities that do not normally behave that way.
  • Tune out expected bulk activity such as content migrations, backup jobs, search indexing, approved integrations, and administrative reviews, but require those activities to be attributable to known accounts and change records.
  • Correlate Confluence access anomalies with identity events such as new device, unusual source location, recent permission changes, or suspicious session behavior.

Mitigation priorities

  • Apply least-privilege access to Confluence spaces and pages, especially documentation containing architecture, network diagrams, procedures, standards, or credentials.
  • Reduce sensitive content exposure by removing or securing development and testing credentials and other secrets from documentation repositories.
  • Require strong identity controls for Confluence access, including appropriate MFA and governance for service accounts, API tokens, and integrations.
  • Establish audit log retention and SIEM ingestion sufficient to investigate historical documentation access.
  • Define approved bulk-access use cases such as migrations, backups, and indexing so detection logic can distinguish authorized automation from suspicious collection.
Analyst notes and limits

The ATT&CK object is a detection strategy, not a technique description, and it detects T1213.001 Confluence. The supplied official description and official detection fields are not provided, so this take is based on the object name, its external reference, and the relationship to the Confluence collection technique. Local Confluence configuration, audit logging level, identity provider integration, and content sensitivity determine how actionable this detection can be.

Platforms and tactics are not specified on DET0358 itself; the related technique identifies SaaS and collection. No official detection logic, analytics, thresholds, or data sources were supplied. This summary does not assert active exploitation, attribution, customer exposure, or guaranteed detection coverage.

Official MITRE ATT&CK definition

Programmatic and Excessive Access to Confluence Documentation

No official description is available in the imported ATT&CK source object.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

How security teams should use this page

Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.

ATT&CK relationship table

Techniques used

This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.

1 rows
Domain ID Name Relationship / procedure
Enterprise T1213.001 Confluence Sub-technique This object detects Confluence.
Relationship explorer

All related ATT&CK context

Change history

Object version and sync metadata

The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
d4b0db02e8e95e6e...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle d4b0db02e8e9…
Raw source

Mirrored ATT&CK source object

The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack DET0358
    Open source URL
Source and licensing

Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.