Data from Information Repositories

Most organizations keep a large amount of their most useful information in a small number of structured, queryable places: a database, a shared knowledge base, an internal wiki, a code repository. Employees query these systems constantly as an ordinary part of doing their jobs.

This technique covers an adversary reading data directly out of one of these repositories, using access they already have rather than exploiting anything new. Several specific repository types (like a wiki platform or a code hosting service) have their own named sub-techniques; a plain relational database doesn't map to any of those, so activity against a database specifically is correctly classified under this base technique rather than a sub-technique.

Once an attacker has credentials or a session with legitimate access to a repository, whether that's a compromised user account or a service account, they query it the same way any authorized user would. There's no exploit involved in the access itself; the query language and the permissions are exactly what they'd be for anyone else with that access.

What differs from normal use is usually scope and pattern. Where a legitimate user typically runs the same handful of familiar queries relevant to their actual job, an attacker exploring an unfamiliar system tends to query more broadly, touch more tables or documents than their role would suggest, or pull volumes of data well beyond what any single task would require.

Data source: The database engine's own statement log, which records the executed query, the database user and the source connection. Where a network sensor parses the database protocol, its query records corroborate the same read independently of the host.

{
  "db": {
    "name": "ledger_db",
    "statement": "SELECT entry_id, cost_center, posted_on, amount, currency FROM ledger.journal"
  },
  "host": {
    "name": "db-example"
  },
  "user": {
    "name": "svc_ledger"
  },
  "event": {
    "action": "statement",
    "dataset": "postgresql.log"
  },
  "process": {
    "pid": 40817
  }
}

Prebuilt Elastic rule: No dedicated prebuilt rule (depends on the repository's own audit logging)

Since detection depends on audit logging existing in the first place, the first hunting question is simply whether it's enabled and actually reaching the SIEM. Once it is, look at query volume and breadth per account against that account's own historical pattern, not a platform-wide average, since normal usage varies enormously by role.

Timing matters as much as volume: a account querying broadly outside its usual working hours, or immediately following an unusual authentication event, is a stronger combined signal than either fact alone. A source host that doesn't match where that account normally connects from is worth the same scrutiny. Expect two views of one query, both true: the application log sees the external client and records the row count; the database log sees the application server and no row count. A statement line carries no client address; recover it from the same backend's connection record via the process id on every line.

Business users query information repositories all day as a completely ordinary part of their work, and a single unfamiliar-looking query proves very little on its own. Reporting jobs, scheduled exports, and legitimate ad hoc analysis can all look broad or unusual out of context.

The distinguishing signal is whether the account, the volume, and the timing all fit that account's established pattern together. A known reporting service account running its scheduled broad query is routine; the same breadth from a human user account that's never touched those tables before, especially outside normal hours, is not.

• MITRE ATT&CK: T1213 Data from Information Repositories

1 scenario in this catalog covers T1213. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →