How T1213 data from information repositories shows up in intrusions
T1213 lets an adversary gather data of interest from the information repositories an organization already runs. Under the Collection tactic (TA0009), MITRE describes the adversary as trying to gather data of interest to its goal. T1213 covers the case where that data sits in shared systems such as internal wikis, code hosting, ticketing, collaboration platforms and SaaS repositories. In intrusions, this usually appears after an attacker already holds a valid session or token, because these repositories are built to be read by many staff and automated tools. Reading company knowledge can therefore be one of the quietest stages of an intrusion. The MITRE ATT&CK tactic page for Collection gives the definition that detection content should reflect.
For the SOC lead, the difficulty is that these repositories are queried all day by engineers, support staff, bots and integrations, so a single read looks normal. What separates an intrusion is the pattern: an account that has never browsed a space suddenly enumerating many pages, a service token used from an unfamiliar network, or a bulk export of a project's history. Decide now which repositories hold material an adversary would want, such as design documents, source trees, runbooks and customer records. Then confirm with each platform's administrators that read and export events reach your log pipeline and are retained long enough to establish a baseline. Illustrative: if a contractor's wiki activity from the week before an incident rolls off the logs after one day, that baseline cannot be rebuilt later.
Map every detection and coverage claim to a named ATT&CK version. This page uses Enterprise ATT&CK version 20.0, and T1213 with its six sub-techniques is tied to that release. Technique IDs, sub-technique IDs and the data components that detection strategies reference can change between releases, because MITRE can rename, deprecate or revoke content. Check the ATT&CK updates page for changes since the version your rules were written against. Confirm which version your SIEM rules, coverage reports and audit evidence cite, and review the version 20.0 content before you rely on any T1213 mapping.
Which telemetry reveals T1213 on each platform
This table maps the data components most useful for T1213 to the platforms in scope and names the open-source collector that typically captures each signal. Read it as a starting point: confirm each data component against the v20.0 STIX bundle before writing detection content, because the mapping for a given platform depends on what your environment actually logs.
| Platform or source | Primary telemetry | Signal to look for | Open-source collector |
|---|---|---|---|
| Linux servers and wiki hosts | Process Creation (DC0032), File Access (DC0055) | Unusual interactive shells or scripts reading content directories and wiki or document stores outside normal service accounts | Wazuh agent, Velociraptor |
| Windows file servers and document stores | File Access (DC0055), Command Execution (DC0064) | Bulk reads of shared repository paths by accounts that do not normally touch them, followed by command-line tooling | Wazuh agent, Velociraptor |
| macOS endpoints | Process Creation (DC0032), File Access (DC0055) | Non-standard processes enumerating synced or shared document folders and knowledge base caches | Wazuh agent, Velociraptor |
| Repository and collaboration SaaS | Audit log events for repository access (confirm event names with the vendor) | Repository reads, exports or downloads by unexpected identities, unusual hours or high page or file counts | Log forwarding to Wazuh or Security Onion |
| Network traffic to internal repositories | Network Connection Creation (DC0082), Network Traffic Content (DC0085) | Sessions to repository APIs or web interfaces from hosts that do not usually query them, with large response volumes | Zeek, Suricata, Security Onion |
| Data copied out of repositories | File Creation (DC0039) | New archives or exports written to staging paths shortly after repository reads | Wazuh agent, Velociraptor |
| Confirmation step | Data component definitions and sub-technique mapping | Check each DC ID and its platform list against the v20.0 STIX bundle before tuning rules | Enterprise ATT&CK v20.0 STIX bundle |
Detection logic for T1213 that SOC teams can tune
T1213 activity looks like normal work until its volume, source, or scope departs from a baseline. The cards below describe five detection ideas built on Process Creation, File Access and Command Execution telemetry, each with the thresholds to tune and the benign activity that will trigger it.
Read volume and breadth per identity
Count distinct repositories, documents, or pages each identity reads within a rolling window, and compare that count with the identity's own history. A sudden jump in distinct objects read matters more than raw read count, because a busy engineer reads many files from one project. Tune the threshold per role, starting from a baseline of at least several weeks. Expect false positives from backup agents, search indexers, and migration jobs that touch every object once.
Access from unfamiliar hosts or sessions
Flag repository reads where the source host, client application, or session is new for that identity, especially when the session starts with an unmanaged device or a client type the user has never used. Join the access log with asset inventory to confirm whether the host is managed. Expect false positives from new laptops, contractor onboarding, and VPN exit changes, so pair the rule with a short recency window and an allowlist that is reviewed, not assumed.
Bulk export and download patterns
Alert on repeated export, archive, or download actions that complete in a short interval, particularly when they follow a burst of reads. Command Execution and Process Creation telemetry on endpoints can show scripted retrieval tools running against repository endpoints, which is a stronger signal than a browser download. Tune against each team's normal export cadence. Scheduled reporting, eDiscovery collections, and legal holds generate large exports on predictable schedules, so match them against change calendars before escalating.
Access outside normal project scope
Compare each read against the projects, sites, or spaces the identity is assigned to in the directory or access management system. A read outside assigned scope is a stronger lead than a read inside it, even at low volume. Confirm the scope source of truth before tuning, since stale group memberships will create noise. Expect false positives during reorganizations, cross-team incident response, and audits, where broad read access is granted for a defined purpose.
Service accounts reading content they do not own
Service accounts should read a fixed set of repositories tied to their function. Alert when a service identity reads content outside that set, or when an interactive user logs in with a service identity. Map each service account to an owner and an expected object list before enabling the rule. Expect false positives from integration platforms, sync connectors, and backup or migration tooling that were added without updating the expected list, so treat new connectors as a change to review.
How to validate a T1213 detection before you trust it
This sequence proves that a detection for T1213 Data from Information Repositories fires on controlled repository access, with the fields analysts need, within an acceptable alert delay, and that the results are recorded against the ATT&CK version the rules target. It turns a rule that looks correct on paper into evidence that can be defended to auditors and the data owner.
Agree scope and rules of engagement with the data owner
Before any test, the security engineering lead and the owner of each information repository in scope (for example, a document management system, a collaboration suite or a SaaS knowledge base) agree in writing which repositories, which test accounts, which time window and which access patterns are allowed. The owner also confirms how to stop the test and who is notified if a control behaves unexpectedly. The step is done when the signed scope lists every repository, account and pattern, and the owner has named a contact for stopping the exercise.
Prepare isolated test accounts and repository data
Create dedicated test identities and seed each in-scope repository with synthetic records that carry no real personal or business data, labeled so that any access to them is unambiguous in logs. Confirm that the accounts have only the permissions the scenario needs, so the test reflects a realistic misuse path without touching production content. Record the account names, repository identifiers and seeded record set in the test plan. The step is done when a baseline export of the logs shows the seeded activity is the only activity from these accounts.
Run controlled repository access patterns
The red or purple team runs a fixed set of repository access patterns on the test accounts, such as bulk listing, repeated retrieval of many records in a short window, access outside normal working hours and access from an unusual host or session. Each pattern is written as a numbered test case with an expected result and a unique run identifier so that every event can be traced back to it. The step is done when every test case has been executed once and its run identifier, start time and end time are logged in the test record.
Confirm each detection fires with the expected fields
Analysts check the alerts and the underlying events for each test case and compare them with the expected result. For each detection, they verify that the alert appears, that the relevant fields are populated (account, repository, object, action, source address and timestamp, using the field names the log pipeline actually produces) and that the detection's ATT&CK mapping is shown. A detection that fires without the fields needed to triage it is recorded as a partial pass. The step is done when every test case has a pass, partial pass or miss status with the evidence attached.
Measure time to alert for each case
For each test case, the team calculates the gap between the first test event and the moment the alert reaches the analyst queue, using the timestamps recorded in the run log and in the SIEM. The owner and the security lead agree in advance what delay is acceptable for each scenario, and any case that exceeds it is flagged for tuning. Delays caused by log shipping or ingestion are separated from delays caused by rule logic so the fix targets the right component. The step is done when each case has a measured delay and a documented threshold it was judged against.
Record misses and noise against the targeted ATT&CK version
The team records every missed test case, every partial pass and every benign event that triggered an alert during the window, with the rule identifier, rule version and the ATT&CK version the mapping targets. Storing the results with the ATT&CK version matters because releases can rename, deprecate or revoke techniques and detection strategies, so a result is only meaningful against the version it was tested for. Noise is sorted by cause, such as a legitimate backup job or an administrator's export. The step is done when the results file names the ATT&CK version, the rule versions and a list of open gaps with owners.
Re-run the test after every rule change
Each time a detection is edited, its thresholds change or the log source is altered, the same test cases run again against the same test accounts and seeded data, and the results are compared with the previous run. The security lead signs off only when the changed rule passes every case it previously passed and no new noise appears. Any change to the ATT&CK mapping triggers a review of the test plan against the new version. The step is done when the regression comparison is filed with the rule change record and the sign-off names the reviewer.
Preventive controls that reduce T1213 exposure
T1213 succeeds when an adversary with valid access can reach collections of internal documentation, tickets, wiki pages or repository content and read them without friction. The controls below narrow what is readable, who can read it, and how often that access is logged, so that detection has a meaningful baseline to work against.
Encrypt sensitive information
ATT&CK mitigation M1041 covers protecting sensitive data at rest and in transit so that stored documentation, repository content and exports are not readable as plain text by anyone who reaches the storage layer. For T1213, the practical question is which wikis, ticket archives and repositories hold credentials, customer data or architecture details, and whether their storage and backups are encrypted with keys managed outside the application. Confirm key ownership, rotation, and whether application-level secrets are kept out of the content itself.
Audit access to repositories
ATT&CK mitigation M1047 concerns enabling and reviewing audit logging so that reads of information repositories are recorded, not just writes. For T1213, the audit trail must show which account searched, opened or exported content, from which host, and at what volume. Assessors typically ask for evidence that audit logs are enabled on each repository in scope, forwarded to a central store, and reviewed against a documented baseline. Confirm that read events, not only administrative changes, are captured for each platform.
Restrict access with user account management
ATT&CK mitigation M1018 limits the accounts that can reach information repositories to those with a current business need. For T1213, excess group membership and inherited permissions on wikis, document libraries and code hosts widen the set of data a single compromised account can collect. Ask for access reviews on a defined schedule, removal of dormant and service accounts with broad read scope, and evidence that repository permissions map to documented roles.
Require multi-factor authentication
ATT&CK mitigation M1032 requires a second factor for interactive sign-in to repositories and the identity provider behind them. For T1213, the attacker's first step is often a valid session or password, so a second factor raises the cost of reusing stolen credentials. Confirm that the factor applies to web, API and token-based access where supported, that legacy authentication paths are disabled, and that exceptions are documented and reviewed.
Train users on information handling
ATT&CK mitigation M1017 addresses user behavior, including recognizing phishing that harvests credentials and handling documents that should not be copied into personal storage or shared channels. For T1213, staff who understand which repositories hold sensitive content are less likely to export or forward it casually. Ask for role-based training records, the content covered, and whether training is tied to the sensitive repositories actually in scope.
Apply data loss prevention controls
ATT&CK mitigation M1057 covers monitoring and restricting the movement of sensitive data out of managed systems. For T1213, DLP policies can flag bulk exports, uploads of repository content to unmanaged destinations, or copies of tagged documents. Confirm which platforms the policies cover, whether they inspect content or only metadata, and how alerts feed into the same review process used for repository audit logs. Expect false positives to need tuning before they are reliable.
Triage steps when a T1213 alert fires
The first decision on a T1213 alert is whether the access was authorized, and that answer depends on establishing who acted, through which session, and from which source host. Start by matching the alerting account to a known owner and role in your identity provider, then check whether the session was created by an expected sign-in path, such as a managed device or an approved application integration. Confirm the source address and host against your asset inventory and recent change records. Repository access by a service account with no matching ticket or scheduled job is a stronger signal than a single unusual query by a named analyst, so record which of these two situations you are in before you take any action that could disrupt business work.
Next, determine the scope of what was touched. For each affected repository, such as a wiki, document library, code host, ticketing system or shared drive, pull the file access, search and export records for the session window and list the sites, projects or record classes involved. Note whether content was only listed, opened, downloaded or shared outside the tenant, because those actions carry different data exposure. Where a repository offers an audit log export, keep the native format and its hash alongside your case notes. The retained scope tells you which data owners to involve and whether a privacy or legal review is needed under your own policies and any applicable regulation. Those obligations are yours to confirm with counsel and your privacy office, not something this alert settles.
Containment should match confidence. If the session is unexplained, revoke it and rotate any tokens, API keys or application passwords the account or integration holds, then suspend access for the account until the owner confirms the activity. Before revoking, preserve the relevant identity sign-in logs, repository audit logs, endpoint process records and the source host's volatile evidence if your procedure requires it, because revocation can change what the platform shows later. Notify the data owner with the affected repositories and time window, and record each decision with a time and name. Once the case closes, feed the outcome back into rule tuning: add confirmed service accounts and approved tooling to allow lists with an expiry, and adjust thresholds based on what the false positives actually were.
Rehearsing T1213 detection in a private cyber range
A private range for this path mirrors a self-hosted wiki or code platform running on Linux inside an isolated network segment, with a reverse proxy, a database host and a central log collector such as Wazuh or Security Onion. The facilitator seeds the platform with synthetic spaces, pages and repositories that carry canary strings, along with a few service accounts and standard user roles. Injects are kept high level: a user account with broader read access than its role requires, a bulk export or API pull from an unusual source host, and a page tree read in a short window outside normal working hours.
- Range topology: Separate the platform, the database and the log collector onto distinct hosts so that host-level and application-level events can be correlated during the exercise.
- Synthetic content: Use fictional runbooks, architecture notes and configuration pages with unique markers, so the team can confirm exactly which records were read.
- Accounts: Create a standard editor, a read-only auditor and a service account, and record which of them the exercise may use.
- Good detection: Within the alert timeline, the team should see the authentication event, the API or export activity and the file or database access tied to the same identity and source address.
- Good response: The case record should capture the identity, the affected spaces, the time window and the containment action, such as disabling the token or restricting the account.
Check that the range can produce the application audit events your platform emits, and confirm with the vendor which events are written by default and which need configuration.
This path models a Windows file server or Microsoft-style document store joined to a test domain, with Sysmon or an equivalent endpoint agent forwarding events to the collector. The facilitator builds a synthetic document library with folder hierarchies, sensitivity labels and a small set of shared mailboxes or sites, and creates a user who normally works in one department. Injects describe a user opening a large number of documents outside their usual folders, a scripted enumeration of a share from an endpoint that rarely accesses it, and a copy of a folder into a new location shortly afterward.
- Range topology: Place the document store, one administrative workstation and one user workstation in separate subnets, with the collector on a management segment.
- Synthetic content: Name documents with unique tokens and vary file types, so access events can be matched to specific items without touching production data.
- Accounts: Provision a standard user, a help desk account and a service account with read rights, and document which role the exercise will use for each inject.
- Good detection: Responders should correlate file access events on the share with process creation on the source endpoint and with authentication events for the same account.
- Good response: The case record should list the folders touched, the hosts involved, the account state changes and the decision to isolate the workstation or suspend the account.
Confirm with your platform owner which file auditing policies are enabled on the range, because access events are not written for every object without them.
The SaaS path uses a tenant from the provider or a sandbox tenant the client controls, with audit logs exported to the collector through the vendor's supported connector. The facilitator creates synthetic workspaces, knowledge bases and sharing links, then assigns roles that include an administrator, a standard member and a guest. Injects are framed as audit events: a guest account viewing a large set of pages, a sharing link created for an internal space and then used from an unfamiliar location, and an integration token added by a user who has no reason to add one.
- Range topology: Route the exported audit stream through the same log pipeline used in production, so that parsing and retention issues surface during the exercise.
- Synthetic content: Populate the workspace with fictional pages and labels that carry unique markers, and record their identifiers before the exercise starts.
- Accounts: Use a guest, a member and an administrator, and make sure the exercise plan states which account each inject uses.
- Good detection: Responders should match page view or export events to the account, the sharing change and the session origin within one alert timeline.
- Good response: The case record should name the affected workspace, the link or token created, the revocation steps taken and the owner who approved them.
Confirm with the SaaS provider which audit event types are available on your plan, how long they are retained and whether the export is near real time, because these limits determine what a responder can see.
Questions SOC leads ask about detecting T1213
How do I separate T1213 activity from normal wiki and code search?
Separate them by who is searching, what they are searching for, and how much they take. Normal use is usually a short session by a known identity against a bounded set of spaces or repositories, while T1213 tends to show a broad sweep of pages, tickets or repositories, often by an identity that rarely queries that content, or at an unusual hour. Build a baseline per platform from your own audit logs for a few weeks, then alert on deviations such as volume per identity, first-time access to restricted spaces, or bulk export actions. Expect false positives from migrations, audits and legitimate reporting, and keep an allow list owned by the content team.
How should I handle T1213 sub-technique coverage across platforms?
Map each sub-technique to the platforms you actually run, then record which data sources give you visibility on each one. T1213 has six sub-techniques, and the telemetry that reveals them differs between Linux, Windows, macOS and SaaS applications, so one generic rule rarely covers them all. Keep a coverage matrix in your detection-as-code repository with columns for platform, sub-technique, data component, log source and detection status. Mark gaps honestly, because a SaaS audit feed that is not forwarded to your SIEM is a gap regardless of what the vendor offers.
How do I version T1213 detection mappings across ATT&CK releases?
Pin every detection to the ATT&CK version it was written against and record that version in the rule metadata. MITRE releases new versions regularly and can rename, deprecate or revoke techniques, and ATT&CK v18 moved detections into detection strategies and analytics with DET IDs and changed data components with DC IDs. Load the STIX bundle for your target version from the attack-stix-data repository, diff it against the previous one, and review every affected rule before you upgrade your mapping. Treat the mapping file as a versioned artifact so auditors can see which coverage claim applied on which date.
How do I test T1213 detections without using production data?
Test with synthetic content that mirrors the structure of your real spaces, repositories and file shares, not with live records. Create a seeded set of dummy wiki pages, code repositories and documents in a staging tenant or a private cyber range, then run scripted, approved emulation of collection behaviour and confirm that the expected events reach your SIEM with the expected fields. Keep the test identities separate, label every test event so it can be filtered, and record the results as evidence. Illustrative example: a staging wiki with 200 seeded pages lets you measure whether a bulk export triggers your threshold without exposing a single customer record.
How do I measure T1213 detection coverage in a way auditors accept?
Measure coverage as the share of T1213 sub-techniques and in-scope platforms that have a tested detection and a working log source, not as a count of rules. For each cell in your matrix, record the rule identifier, the ATT&CK version, the last successful test date and the alert destination. Track freshness as well, since a rule that has not been tested after a log format change is weaker than its label suggests. Share the matrix with the SOC and compliance team, and be clear that it shows readiness and test evidence, not an independent assessment, which only an auditor can give.
Which T1213 detection gaps do teams usually find first?
Teams most often find gaps in SaaS and collaboration platforms, where audit logs exist but are not forwarded, retained or parsed. The second common gap is missing identity context, so an alert shows a service account reading many pages without showing the owner or the change ticket. Check whether each platform records read and export events, not only edits, because many collection actions are reads. Confirm these points with each vendor and in your own environment, since log availability depends on license tier and configuration.
Can my own team run T1213 detection and cyber range exercises?
Yes, a capable internal team can build and run these detections, provided it has access to the relevant audit logs, a SIEM it controls, and time to maintain rules after each platform upgrade. The work that usually strains internal teams is the recurring part: keeping the coverage matrix current, reviewing rules against each ATT&CK release, and rehearsing response with the people who would act on an alert. DeployOpen plans, implements and tests self-hosted open-source platforms in your environment and runs private cyber ranges, and scope is agreed in writing before work starts. Ask any partner to show how the work would be handed over so your team can maintain it afterwards.
How DeployOpen builds T1213 detections and range exercises
Each engagement starts with a written scope that names the information repositories in use, the ATT&CK version being targeted and the telemetry the client can actually provide. The cards below follow that scope from collector deployment through rules, purple team exercises and cyber range rehearsal. Outcomes depend on the agreed scope, and DeployOpen does not issue audit reports or certifications.
Scope the repositories and version
We start by listing which information repositories hold data of interest for T1213 Data from information repositories, such as wiki platforms, document management, ticketing and source hosting, and which of them run on Linux, Windows, macOS or SaaS. The scope records the ATT&CK version the detection mappings target, because releases can rename or deprecate techniques. Clients should confirm which repositories are in scope, who owns each one, and which logs the owners can export.
Map telemetry to data components
Detection strategies for this technique most often draw on Process Creation, File Access and Command Execution, with Network Traffic Content and Network Connection Creation for SaaS and web-hosted repositories. We check which of these the client already collects and where gaps sit, such as missing audit policy on a file share or no API log export from a SaaS tenant. Gaps are written down as explicit risks rather than assumed away.
Implement collectors in your environment
Open-source collectors and agents are deployed inside the client's own cloud accounts, data centers or air-gapped networks, with log forwarding to the client's SIEM. For self-hosted repositories, we configure audit logging of read and export actions and confirm retention settings with the client. Collector configuration is documented so the client's team can maintain it after handover.
Write and tune detection rules
Rules are written as Sigma-style logic and converted for the client's SIEM, such as Wazuh or Security Onion. Typical logic flags bulk reads of a repository by one account, exports outside normal working hours, and access from unfamiliar hosts. Each rule is tuned against the client's baseline with a documented false positive review, and the rule records the ATT&CK technique and sub-technique it targets.
Run purple team exercises
Security engineers and the client's responders run agreed exercises against a test copy of the repositories, with the exercise plan approved in advance. The exercise records which actions were performed, which alerts fired, and how long the triage took. Findings feed back into rule tuning and into the response runbook, and the client keeps the exercise evidence.
Build cyber range scenarios
We build a private cyber range scenario that reproduces the client's repository stack with synthetic data, so that detections can be rehearsed without touching production. Clients should confirm which repository platforms are reproducible in the range, how sensitive data is replaced, and who controls range access and cleanup. Scenarios are reviewed with the client before they are used in training.
