- TTP Catalog
- Collection
- T1114.002
T1114.002
Remote Email Collection
What it is
Modern mailboxes aren't just read from a single desktop client sitting on one machine. Webmail, mobile apps, third-party integrations, delegated access for an assistant or a shared team inbox: authorized remote access to a mailbox is normal, constant, and happens from a wide variety of client applications and locations, often without the account owner's mailbox client ever changing at all.
This technique is about an adversary using that same remote-access capability, once they have valid credentials or a valid session token, to reach into a mailbox from outside the user's usual pattern and read its contents directly, rather than needing to be on the user's own device.
How adversaries use it
With a compromised credential or a stolen OAuth token, an attacker connects to the mailbox the same way any legitimate remote client would, through the same standard protocols the platform exposes for exactly this purpose. There's no exploit required; the access is, from the platform's point of view, indistinguishable from an authorized login using a slightly different client.
From there, the attacker can search, read, and often export message content directly, looking for anything valuable: credentials sent in cleartext, financial details, sensitive attachments, or simply enough context to make a follow-up social-engineering attempt convincing. Because this happens over the same channels real remote access uses, the access itself frequently doesn't stand out from the flood of ordinary mailbox activity a busy account generates.
Detect it in Elastic
Data source: The mail server's own IMAP session log: login records naming the authenticating account, the authentication method and the source address, plus per-message access records showing which messages were opened. Note this is distinct from the SMTP delivery log on the same server, which shows how mail arrived, not who read it.
Key fields
Two events carry this technique: the mailbox login (who authenticated, how, from where) and the reads that follow (which messages were opened). In Microsoft 365 both are Unified Audit Log records, event.dataset: "o365.audit", with MailItemsAccessed as the read; on a Dovecot IMAP server they are the imap-login line and the mail_log flag-change lines. Key fields: source.ip and the client application (present on the login only, so join reads to their login on the session id), the account (o365.audit.UserId or dovecot.user), the authentication mechanism (dovecot.method), and per read the mailbox and message identifiers (dovecot.mailbox, dovecot.uid, dovecot.subject).
Example event
{
"host": {
"name": "mail-example"
},
"event": {
"dataset": "dovecot.imap"
},
"source": {
"ip": "10.0.44.17"
},
"dovecot": {
"user": "j.doe",
"method": "PLAIN",
"service": "imap-login",
"session": "aBcDeFgHiJkLmNoP"
}
}Prebuilt Elastic rule: M365 Exchange Mailbox Accessed by Unusual Client (Microsoft 365 only)
Hunt guidance
Start from the client identity, not the fact that access happened at all: compare the client application and, where available, the source location against that specific account's own established pattern, not a platform-wide average, since normal remote-access habits vary enormously by role and by person. A cleartext-password login from a new address is a finding on its own.
Volume is the second, complementary signal. A mailbox suddenly experiencing an unusually large number of item-accesses in a short window, especially spanning many different messages or folders rather than a handful someone would realistically be working through, points toward bulk collection rather than someone reading their own inbox. Correlating an unusual client with an unusual volume, together, is a much stronger signal than either alone. Prebuilt coverage exists only for Microsoft 365; self-hosted IMAP needs its own rule on login address and per-session read volume.
Ruling out legitimate activity
Remote mailbox access is one of the most routine things a real account does. A new phone, a new laptop, switching from a desktop client to webmail, a delegate or assistant with legitimate access, or a sanctioned third-party integration (a CRM, a scheduling tool) can all introduce a "new" client application without anything being wrong.
The distinguishing signal is the combination of factors, not any single one: a genuinely new client is unremarkable on its own; a new client accessing an unusually large volume of messages, or accessing from a location or at a time inconsistent with that person's normal pattern, is a different and much more specific story.
References
Practice it
1 scenario in this catalog covers T1114.002. We don't name it — identifying the technique is part of what a scenario grades. Explore the dashboard →