---
{
  "title": "Data from Information Repositories",
  "summary": "Collection from information repositories targets collaboration and knowledge systems where organizations accumulate valuable material.",
  "topic": "soc",
  "level": "Intermediate",
  "updated": "2026-10-12",
  "published": "2026-10-04",
  "units": [
    6
  ],
  "aliases": [
    "T1213"
  ],
  "sources": [
    {
      "title": "MITRE ATT&CK T1213: Data from Information Repositories",
      "url": "https://attack.mitre.org/techniques/T1213"
    }
  ],
  "editorialVersion": 2
}
---

## Collaboration systems accumulate valuable information

Collection from information repositories targets systems where an organization stores knowledge and working material. Examples include documentation platforms, code repositories, customer-management systems, and messaging services. Such repositories can contain business information, architecture details, contacts, and references to other resources.

Access may occur through a normal application interface or an API. The fact that a genuine account successfully retrieved material does not establish that the use was authorized. Investigate the account's control, granted scope, and the business purpose of the activity.

## A documentation account reads broadly

At a fictional academy, a staff identity begins accessing technical pages and project records far outside its normal role. The analyst checks resource identifiers, actions, timestamps, application grants, and any export or sharing events. They compare the pattern with approved onboarding, migration, and search-indexing work.

Broad reading may be legitimate for a new project. The team asks the owner to explain the scope and checks whether the activity matches that explanation. Counts can be misleading when one operation returns many items or when repeated requests retrieve the same material.

The investigation also reviews the information's sensitivity. A page containing network diagrams has different implications from a public-style announcement, while a document containing an exposed credential may require separate identity action.

## Follow permissions and sharing

Repository access can involve inherited groups, delegated applications, shared links, or direct assignments. Identify the actual path used rather than assuming that the visible username had ordinary interactive access. A service identity may retrieve data on behalf of an integration.

External sharing is a separate event worth examining. A document read, a bulk export, and a new sharing permission represent different stages and effects. [[data-from-cloud-storage]] covers related storage collection, while [[exfiltration]] asks whether information crossed the intended boundary.

Available audit detail varies by product and configuration. Record whether the source shows views, downloads, searches, exports, or only general sign-ins. Do not infer detailed content access from authentication alone.

## Limit exposure and preserve the trail

Restrict unauthorized grants or identities as justified, preserve relevant audit records, and review other repositories reachable through the same access. Coordinate with application owners because removing a widely used integration can interrupt normal work.

For practice, compare a sanctioned knowledge-base migration with an unexplained export by a dormant account. Identify the owner, source, scope, output, and access-path evidence needed for a decision. Write a conclusion distinguishing confirmed retrieval from possible downstream use. [[logs-and-telemetry]] and [[incident-reporting]] make those boundaries explicit rather than treating every unusual repository query as proven theft.

## Related concepts

- [[mitre-attack]]
- [[incident-response]]
- [[transfer-data-to-cloud-account]]
- [[unsecured-credentials]]