How T1114 email collection shows up in intrusions and how to detect it
T1114 Email Collection is the ATT&CK technique for gathering email content from a mail system or mailbox so that an adversary can read, copy or export messages that serve their goal. For a SOC lead, mailbox data is high-value collection material, and it is often gathered after credentials have been obtained, because a valid session or account gives access without needing to exploit anything else. The Collection tactic (TA0009) is defined by ATT&CK as the point where the adversary is trying to gather data of interest to their goal, and email is one of the most common places that data sits. This page uses Enterprise ATT&CK version 20.0 as its reference. T1114 has 3 sub-techniques, and every detection mapping should name the ATT&CK version it targets, because releases can rename, deprecate or revoke techniques. The MITRE ATT&CK tactic page for Collection is the natural starting point for the tactic context.
In intrusions, mailbox collection tends to appear after an account has already been compromised or misused, so the investigation usually starts with identity and access questions rather than with the mail server itself. Typical points of visibility include unusual access to mailboxes by accounts that do not normally read them, bulk reads or exports tied to a single session, and mail activity from service identities or from sign-in contexts the user has not used before. Your first decision is which mail platform and logging sources you can actually query, for example Microsoft 365 unified audit logs, Exchange message tracking, or the audit logs of a self-hosted mail stack. Confirm with your mail platform vendor which mailbox access events are logged, at what granularity, and how long they are retained, because detection quality depends on those answers rather than on the technique description.
Before writing detections, check three things in your environment: that mailbox access auditing is enabled for the accounts that hold regulated or sensitive data, that the audit events are forwarded to your SIEM (for example Wazuh or a Security Onion deployment), and that you have a documented baseline of which accounts and applications legitimately read mailboxes. Map each candidate detection to the data components ATT&CK uses for Collection techniques, such as Process Creation, File Access and Command Execution where endpoint telemetry applies, and record the ATT&CK version and detection strategy identifier beside each rule so it stays traceable through future releases. Mitigations to review for this technique include Encrypt Sensitive Information and Audit, which map to the ATT&CK mitigation identifiers for those controls and should be checked against your own implementation.
Which telemetry reveals email collection and which open-source tool collects it
This table maps the data components most referenced for T1114 Email Collection to the platforms where they apply and the open-source collectors that produce them. Read each row as a question: which log source would show the adversary reading or exporting mailbox content on that platform, and which tool gathers it. Confirm coverage for your platform against the ATT&CK 20.0 bundle before writing detection content.
| Data component | Platform and source | Open-source collector | What it can reveal |
|---|---|---|---|
| Process Creation (DC0032) | Windows and Linux endpoints running mail clients or scripts that touch mailbox stores | Wazuh agent with Sysmon-style endpoint logging on Windows, auditd on Linux | Unexpected mail utilities, scripts or PowerShell sessions launched near mailbox or export activity |
| File Access (DC0055) | Windows, macOS and Linux file systems holding local mail stores such as PST, OST, mbox or Maildir files | Wazuh file integrity and audit rules, auditd watches on mail directories, macOS unified log for file events | Reads of mail archives by processes outside the mail client's normal profile |
| Command Execution (DC0064) | Windows and macOS shells, and Linux shells, used to query or copy mail data | Sysmon-style command logging, auditd execve records, macOS unified log for shell activity | Command lines that enumerate or export mailbox data, or run from an unusual parent process |
| File Creation (DC0039) | Staging directories and exported archives created on endpoints or file servers | Wazuh agent file monitoring, auditd create watches, Sysmon-style file create events on Windows | New exports, copies or archive files appearing where mail data would be staged |
| Network Traffic Content (DC0085) | Mail protocol traffic such as IMAP, POP3, SMTP and Exchange web services on monitored segments | Zeek for protocol logs, Suricata for signature alerts on mail protocols | Bulk mailbox fetches, unusual clients or volumes, and mail access from hosts that do not normally use it |
| Platform coverage (all rows) | Office Suite and SaaS mail services often expose audit logs rather than endpoint telemetry | Confirm ingestion of the mail platform audit log into Wazuh or your SIEM | Mailbox access events that endpoint and network sensors cannot see |
Detection logic for email collection that SOC teams can tune
T1114 Email collection is hard to separate from legitimate mail administration, because the same processes, files and transfers appear during backups, eDiscovery and migrations. The cards below describe five detection ideas, each with the logic, the thresholds to tune and the false positive sources to exclude before alerting.
Unusual processes reading mail stores
Alert when a process that is not a known mail client, sync agent or backup product opens mail store files, such as Outlook data files or mailbox databases, on a user workstation or mail server. The logic is based on process lineage and image path rather than the file name alone. Tune the allowlist per host group, and expect backup agents, migration tools and eDiscovery collectors to be the main false positives. Confirm each allowlisted binary against your change records before suppressing it.
Mail client data access outside user patterns
Flag Office or mail client profile data being read by a session that has no interactive logon, or at hours when the mailbox owner is normally inactive. Baseline each user's usual access window for a period you define, then alert on deviation above a threshold you set. Service accounts used by archiving, journaling and compliance platforms are the usual false positives, so scope the rule to human accounts first.
Command execution against mail data directories
Detect command interpreters or scripting hosts that reference mail data directories or mailbox export parameters in their command lines. The point is to catch scripted collection rather than the mail client itself. Expect administrators running PowerShell-based Exchange or Microsoft 365 exports, and migration runbooks, to trigger this. Require the command to be run from an unexpected parent or account before escalating.
File creation of mail exports
Alert on creation of PST, OST, MBOX or EML bundles, or large archive files containing them, in user profile, temporary or removable locations. Set a size threshold relative to the typical mailbox size in your environment, and alert on several such files written in a short window. Backup jobs, eDiscovery holds and migration staging are the main false positives, so check for the expected staging path and job identifier.
Anomalous network content leaving the host
Watch for large outbound transfers from a host immediately after mail store access, particularly to destinations that have no prior relationship with the business. Correlate network connection creation with the file and process events above, and inspect content where your inspection policy allows it. Cloud sync clients, mail gateways and legitimate archive uploads can generate similar flows, so maintain a destination allowlist and review it at each change window.
How to validate the email collection detection in a lab
This sequence proves that the T1114 Email Collection detection fires on the sub-technique in scope, within a measured time, and that the evidence survives tuning and a later ATT&CK release. It runs in a private cyber range against a test mailbox, never a production mailbox.
Agree scope and rules of engagement
The detection owner, the mailbox owner, the range operator and the SOC lead sign a short written scope before any test begins. The scope names the sub-technique under test (Local Email Collection, Remote Email Collection or Email Forwarding Rule), the test mailboxes, the hosts involved, the start and stop conditions, and who can halt the exercise. The step is done when all four parties have signed and the range team confirms the test mailboxes contain only synthetic messages.
Map the test to the targeted sub-technique
Record which ATT&CK sub-technique the exercise represents and which data components the detection relies on, such as Process Creation, File Access or Command Execution for local collection, and mailbox audit events for remote collection and forwarding rules. Note the ATT&CK version the mapping targets. The output is a one-page mapping that a reviewer can check against the detection's stated coverage, and it shows any gap between what the test exercises and what the rule claims to detect.
Run the emulation on a test mailbox
The red team or range operator runs the agreed emulation against the synthetic test mailbox inside the range, following the approved scope and stopping if any condition in the rules of engagement is met. A second person observes and keeps a timestamped log of each action taken. The step is complete when the log, the scope and the mailbox state match, so the team can later separate what was done from what was detected.
Confirm which alerts fire
The detection engineer checks the SIEM or Wazuh alert queue and the Security Onion or Zeek sources for alerts tied to the test window and the test accounts. Each expected alert is marked as fired, missed, or fired with the wrong severity or fields. The output is a table of expected versus observed alerts. Missing alerts are treated as findings to investigate, not as proof the control works.
Measure time to alert
Using the timestamps from the emulation log and the alert records, the analyst calculates the interval between the first test action and the first matching alert, and records the ingestion delay separately. Compare the result with the detection's documented target, and ask the SOC lead to confirm that target is written down. The step is done when the interval is recorded per alert, with the log source named for each.
Record evidence and close findings
The team stores the scope, mapping, emulation log, raw alert exports and the expected-versus-observed table in the evidence repository, with the date and the ATT&CK version used. Each missed or late alert becomes a tracked finding with an owner. The output is an evidence package that an auditor or internal reviewer can follow from the scope to the result without asking the team to reconstruct it.
Re-test after tuning and version the detection
After the detection is tuned, the same emulation runs again on the same test mailbox so the before and after results can be compared. The detection rule is versioned in source control with a note stating the ATT&CK release it targets, since releases can rename or deprecate techniques and detection strategies. The step is done when the re-test results, the rule version and the ATT&CK version are linked in one record, and the team has confirmed that the tuning did not remove coverage for the other sub-techniques.
Preventive controls that reduce exposure to email collection
T1114 Email collection succeeds when mail content is readable and reachable by an attacker who has gained access to a user account or mail service. The controls below reduce what an attacker can read, how long they can keep reading, and how quickly unusual mailbox access is noticed. Each one needs a named owner, an evidence source and a periodic check in your own mail platform.
Encrypt sensitive information
The ATT&CK mitigation Encrypt Sensitive Information (M1041) asks you to protect mail content and attachments that carry regulated or confidential data. At rest, this means storage encryption under the mail provider's controls or keys you manage. In transit, it means enforcing TLS for mail submission, retrieval and relay between servers. Confirm which encryption modes your mail platform offers, who holds the keys, and whether message-level encryption is available for mail that leaves the organization. Encryption does not stop an attacker who already holds a valid mailbox session, so pair it with the controls below.
Audit mailbox activity
The ATT&CK mitigation Audit (M1047) means enabling and retaining the logs that show who opened, searched, forwarded or exported mail. For T1114, the most useful records are mailbox access events, inbox rule creation or change, and delegated or shared mailbox access. Confirm which mailbox auditing actions your platform records by default, which need explicit enablement, how long records are retained, and whether they reach your SIEM quickly enough to alert. Audit data only helps when someone reviews it, so name that owner and the review cadence.
Train users on mail lures
User Training (M1017) reduces the chance that an attacker obtains mailbox access in the first place. Staff who recognize credential prompts, unexpected sign-in requests and suspicious attachments are more likely to report them early. Training should cover how to report a suspicious message through a path the security team actually monitors. Ask your provider or internal team to show completion records and to describe how simulated phishing results feed back into the program. Keep the content tied to the mail tools staff use every day.
Enforce multi-factor authentication
Multi-factor Authentication (M1032) requires a second factor before a mailbox session is granted, which makes stolen passwords alone insufficient for mailbox access. Pair it with conditional access rules that limit sign-ins by location, device state or risk. Check whether your mail platform still allows legacy authentication protocols that bypass these checks, and block them where your business does not depend on them. Confirm enrollment coverage for administrators, shared mailboxes and service accounts, since these are frequently excluded from policy.
Apply data loss prevention rules
Data Loss Prevention (M1057) uses policies that detect or block sensitive content leaving the organization by mail. For T1114, the most valuable rules flag automatic forwarding to external domains, bulk attachment sending and messages containing regulated identifiers. Confirm which of these conditions your mail platform evaluates, whether policies apply to shared mailboxes and archived mail, and what happens when a rule fires: alert only, quarantine or block. DLP limits exfiltration of collected mail but does not see what an attacker reads inside the mailbox.
Triage and response when an email collection alert fires
When an email collection alert fires for T1114 Email collection, the first decision is whether the activity is authorized. Check with the mailbox owner, the messaging or identity administrator, and any scheduled eDiscovery, migration or backup job that could explain bulk mailbox reads or mail forwarding changes. Only after that check is complete should the team narrow the scope. Then identify the account whose credentials or token appear to be in use, the mailbox or mailboxes accessed, and the host or client application that made the requests. Record the time window of the activity and the sign-in source addresses, because these fields drive every later step. Preserve the relevant evidence before making changes: exported mailbox audit records, identity provider sign-in logs, mail transport logs, and, where the alert came from an endpoint, the process and file artifacts on the host. Use the Wazuh or Security Onion storage you already have, and confirm retention periods with the platform owner before the first log rotation falls inside the investigation window.
Check for related authentication anomalies before containment closes the session. Look for impossible travel, sign-ins from unfamiliar infrastructure, new MFA registrations, changes to inbox rules or forwarding addresses, and OAuth consents granted to unknown applications. Any of these suggests the collection is part of a longer intrusion rather than a single misused session. For containment, revoke active sessions and refresh tokens for the account, reset the password, and re-register MFA methods only after the identity team confirms the new factors belong to the legitimate user. Remove suspicious forwarding rules and revoke application consents. Scope the other mailboxes by querying the same sign-in sources and audit actions for the same time window, the same client identifiers and the same source addresses, and treat any mailbox that shares a delegate or shared-mailbox permission with the affected account as in scope. Finally, decide whether mail content may have left the organization. If forwarding, exported messages or attachments reached an external party, notify legal counsel and the privacy owner promptly, because breach notification duties are set by the regulator and contract terms in your jurisdiction and sector, and the timing clock may start at discovery. Confirm those obligations with counsel rather than assuming them.
Rehearsing email collection detection in a private cyber range
This environment covers Windows endpoints running desktop mail clients and Office suite components, often connected to an on-premises or hosted mail platform. The range should include a small Active Directory domain, at least two Windows workstations, and a set of synthetic test mailboxes with realistic-looking but fictional content, including mail rules and a shared folder that staff would normally use. The facilitator schedules abstract injects such as an unexpected change to mailbox rules, a burst of mailbox reads from an account that does not normally access that mailbox, and an unfamiliar process reading mail data files on one workstation. Good detection means the Process Creation and File Access telemetry reach the SIEM with enough context to tie the activity to a user, host and time, and that an analyst can see the alert within the agreed triage window. Good response means the SOC triages the alert, the identity team confirms whether the account is expected to act, and the endpoint team isolates the host only after the handoff is recorded.
- Test topology: Use fictional mailboxes, a dedicated test tenant or mail server, and workstations enrolled in the range's Wazuh or equivalent agent deployment.
- Inject design: Describe scenario events in words, such as unexpected mailbox access or a rule change, without scripting the actions.
- Detection check: Confirm that the alert names the account, host and mailbox scope, and that false positives from scheduled sync jobs are documented.
- Response handoff: Record who owns the account decision, who owns the host decision, and the time each handoff is expected to happen.
- Evidence: Keep the timeline, the alert record and the handoff notes together for the after-action review.
Check that the rehearsal uses only synthetic data and that every alert in the range has a documented owner before the exercise starts.
This environment covers macOS endpoints where staff use a native mail client, a browser-based webmail session, or a sync agent that stores mail locally. The range should include at least one managed macOS workstation with the unified logging and endpoint agent configured for the team's standard, a test mail account, and a sync path to a central mail server. The facilitator schedules injects such as a local mail store being read by an unexpected application, a configuration change to the mail client, and an unusual sync pattern from a single host. Good detection means endpoint telemetry records process activity and file access against the mail store path, and that the alert gives the analyst enough context to separate normal client behavior from unexpected behavior. Good response means the analyst confirms with the endpoint owner whether the activity is expected, preserves the relevant logs before any change, and escalates to the identity team only if the evidence points to account misuse.
- Test topology: One managed workstation, a test mail account, and a sync path that mirrors the team's production client setup.
- Inject design: Describe mail store reads, client configuration changes and sync anomalies as abstract events for the team to find.
- Detection check: Confirm the alert distinguishes the mail client from other processes and that baseline behavior is recorded before the exercise.
- Response handoff: Assign one owner for log preservation and one owner for the user conversation, and record both in the timeline.
- Evidence: Store exported logs and the baseline snapshot with the exercise record so auditors can trace the decision.
Check that the team has agreed in writing which macOS logs are retained, for how long, and where they are stored, since retention settings differ across deployments.
This environment covers self-hosted mail servers running on Linux, with a mail transfer agent, an IMAP or POP service, and a web administration interface. The range should include a dedicated mail host, a test domain, several synthetic mailboxes, and a logging pipeline that forwards mail service and authentication logs to the SIEM. The facilitator schedules abstract injects such as a large number of mailbox reads in a short window, an administrative change to mailbox settings, and a new client session from an unexpected network location. Good detection means the server logs reach the SIEM with the mailbox identifier, source address and session outcome, and that the alert ties server-side activity to the account in question. Good response means the operations team confirms the scope of affected mailboxes, the security team decides whether to restrict sessions, and the change is recorded before any configuration is altered.
- Test topology: A dedicated mail host, a test domain, synthetic mailboxes and forwarding of service and authentication logs to the SIEM.
- Inject design: Describe bulk reads, admin changes and unusual session origins as scenario events without giving the team a method.
- Detection check: Confirm the alert includes mailbox identifier, source address and session result, and that log forwarding delay is measured.
- Response handoff: Separate the containment decision from the configuration change so the operations owner and the security owner each sign off.
- Evidence: Keep the server log extracts, change records and the containment timeline with the after-action report.
Check that log forwarding has been tested end to end, since a silent gap in the pipeline will hide the very events the exercise is meant to surface.
Questions SOC leads and detection engineers ask about T1114
How do I separate email collection from legitimate eDiscovery?
Start from the identity and the process, not the mailbox alone. Legitimate eDiscovery is usually run by a known service account or a case-management workflow, through a documented request, within a defined window. Email collection by an adversary often appears as an unexpected mail-access process or script on an endpoint, or as an unfamiliar client reading mailbox stores outside normal hours. Build an allowlist of approved eDiscovery accounts, hosts and export tools, and alert on exports that fall outside it. Confirm with your legal and records teams how exports are logged before tuning, because a missing case reference is the most common gap. Keep the allowlist in version control so every change has an owner and a date.
How should we handle ATT&CK version changes to T1114 sub-techniques?
Record the ATT&CK version each rule targets in its metadata, because releases can rename, deprecate or revoke techniques and sub-techniques. A rule written against an older version can lose its mapping without any change to the rule itself. Follow the ATT&CK updates page and, when a release lands, compare the Enterprise STIX bundle for your target version with the one you currently use. Pull the current sub-technique list for T1114 from that bundle and flag any rule whose ID no longer resolves. The DeployOpen pages in this series use Enterprise ATT&CK 20.0, so confirm that version against your own rule repository before you start.
Which data components matter most for detecting email collection?
Three data components usually carry most of the signal for T1114 detections in ATT&CK:
How do we avoid alert fatigue from normal mail clients?
Baseline first. Mail clients, sync agents and backup tools read mailbox data all day, so a rule that fires on any mail-store access will flood the queue. Record which signed binaries, service accounts and hosts touch mail stores over a representative period, then alert on deviations from that baseline rather than on access itself. Aggregate repeated events per host and user within a time window, and assign severity from context such as hour of day, host role and whether the access follows an authentication anomaly. Review suppressions every time a mail client updates, because a new version can change its file paths and command lines and quietly break an allowlist.
How can we test email collection detections without touching production mail?
Use a private cyber range with seeded test mailboxes that hold synthetic data. Illustrative example: a test tenant with a few dozen mailboxes, a set of approved eDiscovery accounts and a documented export procedure, so analysts can see both normal and abnormal activity. Run the behaviors in a controlled sequence, record exactly what each step produced in your telemetry, and check whether each rule fired, at what severity and with what context. Repeat the exercise after every rule change. DeployOpen runs private cyber ranges and security testing, and it can scope a range to match the mail platform you operate, subject to a written scope.
Which ATT&CK mitigations apply to email collection, and what evidence do auditors expect?
The two mitigations ATT&CK maps most often to T1114 are Audit (M1047) and Encrypt Sensitive Information (M1041). Audit points to enabling and retaining the logs that show mailbox access, exports and forwarding changes. Encryption points to protecting mailbox stores and exported archives, along with the keys that protect them. For each control, keep configuration exports, log samples, detection test results and a record of who reviews alerts. DeployOpen prepares these systems and evidence for compliance assessments, but independent auditors and certification bodies decide whether controls meet a standard. Ask your assessor which evidence format they expect before you collect it.
Can our own team run email collection detection, or do we need outside help?
Many teams can run it in-house once the logs are flowing and the rules are documented. Divide the work into four parts: log onboarding into your SIEM or data platform, rule authoring and version tracking, cyber range testing, and ongoing tuning. The first two are often handled by existing detection engineers. Cyber range testing and tuning after mail platform changes are where teams most often run short of time. DeployOpen implements open-source platforms inside your own environment and works under fixed-scope engagements, with ongoing support and continuous testing available as retainers. Agree on who owns each part in writing before any work starts.
How DeployOpen builds email collection detections and range scenarios
DeployOpen starts every T1114 Email collection engagement by agreeing the scope and deliverables in writing before any detection work begins. The first written decision is which ATT&CK version the mapping targets. We record the Enterprise ATT&CK version by name in the deliverable, because releases can rename, deprecate or revoke techniques and sub-techniques, and the T1114 sub-technique mappings (Local Email Collection, Remote Email Collection and Email Forwarding Rule) must be checked against that version. Platform coverage is agreed the same way: which Windows, macOS, Linux and Office Suite sources the client actually collects, and which mail platforms sit in scope. Where a platform's telemetry is not yet collected, the gap is logged as a finding rather than assumed away.
Detections are then built and tuned on the client's own open-source stack, typically Wazuh, Sigma rules and Velociraptor where endpoint collection is in place. The work focuses on the data components the ATT&CK mapping references for this technique, including File Access, Process Creation and Command Execution, and on the baseline of legitimate mail client and mailbox tooling in the client's estate. Tuning runs against that baseline with the mail administrators, so that expected sync and export activity is separated from unexpected access. A mailbox forwarding rule change, which a mail administrator should be able to confirm independently, is treated as a separate detection case from local file access. The client should confirm which audit logs its mail platform produces and how long they are retained, since DeployOpen cannot assume those settings.
Each detection is then exercised in a private cyber range that mirrors the client's mail and endpoint configuration. A purple team exercise runs the agreed scenarios, records which alerts fired, how long triage took and which gaps remain, and feeds the findings back into rule changes. The same run produces the evidence pack: rule versions, test records, configuration exports and response runbook references. DeployOpen prepares this evidence for compliance readiness, but it does not issue audit reports or certifications, and the client should confirm with its assessor which evidence format the assessor expects. Ongoing tuning and repeat testing can be arranged as a retainer after the fixed-scope work closes.
