Detecting and Mitigating Data from Information Repositories (T1213)

Data from Information Repositories (MITRE ATT&CK T1213) is collection from the tools where an organization stores and shares what it knows. MITRE files it under Collection and lists IaaS, Linux, Office Suite, SaaS, Windows and macOS as platforms.

Teams write down a great deal in these places. An attacker who gets in reads the same pages your new hires read.

It has sub-techniques for Confluence (T1213.001), SharePoint (T1213.002) and code repositories (T1213.003), among others in the family.

How attackers use it

MITRE describes information repositories as tools that store information, usually to help people collaborate. What they hold can help an attacker with later goals such as credential access, lateral movement or defense evasion, or can be the target data itself. Adversaries may also abuse external sharing features to send sensitive documents to recipients outside the organization.

MITRE lists information of value that may be sitting there:

• Policies, procedures and standards
• Physical and logical network diagrams
• System architecture diagrams
• Technical system documentation
• Testing and development credentials
• Work and project schedules
• Source code snippets
• Links to network shares and other internal resources
• Contact and other sensitive information about partners and customers, including personally identifiable information

Common repositories include storage services such as IaaS databases, enterprise databases and customer relationship management databases, collaboration platforms such as SharePoint, Confluence and code repositories, and messaging platforms such as Slack and Microsoft Teams.

MITRE adds that repositories are sometimes improperly secured, typically by allowing overly broad access to all users or even public access to unauthenticated users. That is especially common with cloud-native or cloud-hosted services, and MITRE names AWS RDS, Redis and ElasticSearch as examples.

Examples on the MITRE page include actors collecting files from various information repositories, gathering data from internal service ticketing systems including credentials, and a stealer that gathers information from repositories linked to cryptocurrency wallets and a messaging service.

How to detect it

MITRE's detection strategy is about abnormal volume, abnormal people and abnormal tools.

• File shares, SharePoint and database repositories. Programmatic or excessive access by users who do not usually touch them. That includes unusual access by privileged accounts, enumeration of large numbers of files, and downloads of sensitive content in bursts.
• Command-line scraping. Tools such as curl, rsync, wget or custom Python scripts used against documentation systems or internal REST APIs, and unusual access patterns to knowledge base folders or shared team drives.
• SaaS platforms. Excessive access to internal documentation or exports of source code and data through platforms such as Confluence, GitHub, SharePoint Online or Slack. This includes use of tokens or browser automation from unapproved IP addresses.
• Mounted shares. Access to mounted cloud shares or document repositories through a browser, terminal or Finder by users who do not usually use those resources, including script-based enumeration or mass download.

To do this, turn on audit logging in each repository and send it somewhere you can query. Then build a baseline for how many pages or files a typical user opens per hour. A burst of hundreds of page views from one account, especially an API token, is the signal to look for.

How to reduce the risk

MITRE's mitigations, in plain steps:

• Audit. Review accounts and privileges for critical and sensitive repositories on a schedule. Make sure cloud-hosted databases are not exposed to the public, and that security groups allow only the hosts that need access.
• Encrypt data at rest in databases.
• Use multi-factor authentication.
• Prepare an out-of-band communications channel for incidents, instead of relying on in-network chat applications that an attacker may be reading.
• Set retention policies to archive or delete data you no longer need.
• Apply least privilege, with access control that includes both authentication and authorization.
• Publish a policy on what may be stored in each repository.

Check your own environment

• Which wikis, drives, ticket systems and chat tools hold sensitive material, and who owns each?
• Who has access to each, and when was the last review?
• Are any databases or search clusters reachable from the public internet?
• Do page histories, tickets or chat channels contain passwords or keys?
• Is audit logging enabled and kept long enough to investigate?
• Do you have an incident plan that does not depend on the tools an attacker may already be reading?

One of the most useful exercises is a search. Pick a few words an attacker would search for, such as password, secret, token, VPN and runbook, and see what your own repositories return for an ordinary account.

Quick check

Sources

• MITRE ATT&CK T1213: Data from Information Repositories