DET0135: Detection of Mail Protocol-Based C2 Activity (SMTP, IMAP, POP3)
This detection strategy matters because mail protocols such as SMTP, IMAP, and POP3 can be used as command-and-control channels that blend into normal emai...
Analyst context for executives and security teams
This detection strategy matters because mail protocols such as SMTP, IMAP, and POP3 can be used as command-and-control channels that blend into normal email-related traffic. For leaders, the decision point is whether the organization can distinguish legitimate mail flows from unusual systems using mail protocols for remote tasking or data exchange, especially where email traffic is broadly allowed through network controls.
Executive priority
Prioritize this as a command-and-control visibility and control question, not just an email security question. Executives should ask whether SOC and network teams know which hosts are expected to send or receive SMTP/IMAP/POP3 traffic, whether exceptions are documented, and whether incident responders can quickly investigate suspicious mail-protocol activity across Windows, Linux, macOS, and network-device environments referenced by the related ATT&CK technique.
Technical view
The supplied ATT&CK object is a detection strategy for Mail Protocol-Based C2 Activity and is related to T1071.003 Mail Protocols under command and control. Because the object provides no official detection text or platform list, defenders should anchor validation on the related technique: application-layer mail protocols including SMTP/S, POP3/S, and IMAP may carry commands and results between a client and server. SOC teams should validate monitoring for unusual mail-protocol clients, unexpected destinations, non-mail hosts initiating mail sessions, abnormal frequency or timing, and protocol use that does not match approved mail architecture.
Likely telemetry
- Network flow records for SMTP, SMTPS, IMAP, IMAPS, POP3, and POP3S traffic
- DNS queries and resolved destinations associated with mail-protocol connections
- Proxy, firewall, secure web gateway, and network security device logs where mail protocols are inspected or allowed
- Email gateway and mail server connection/authentication logs
- Endpoint process-to-network connection telemetry showing which process initiated mail-protocol traffic
Detection direction
- Baseline approved mail-protocol paths: endpoints to corporate mail services, mail relays to external services, and any sanctioned application use of SMTP/IMAP/POP3.
- Alert on mail-protocol traffic from systems that should not initiate it, such as servers, appliances, network devices, or endpoints outside expected mail-client patterns.
- Correlate network activity with endpoint process telemetry to distinguish legitimate mail clients or services from unusual binaries initiating SMTP/IMAP/POP3 sessions.
- Tune for environmental false positives such as monitoring tools, ticketing systems, application servers, scanners, multifunction devices, and legacy systems that legitimately use SMTP.
- Watch for blind spots where encrypted variants, direct-to-internet egress, unmanaged assets, or incomplete mail server logging reduce inspection and attribution.
Mitigation priorities
- Document and enforce approved mail-protocol egress paths, preferring controlled mail relays and sanctioned mail services over unrestricted direct connections.
- Restrict SMTP/IMAP/POP3 access from systems that do not require it, using network segmentation and egress filtering where feasible.
- Maintain an inventory of applications, devices, and services authorized to use mail protocols so detection teams can tune alerts without suppressing meaningful anomalies.
- Ensure incident response playbooks include triage of mail-protocol C2 hypotheses: source host, initiating process, destination, authentication context, message timing, and related network activity.
- Use the detection strategy as compliance and audit evidence by demonstrating that command-and-control monitoring covers common business protocols, not only obviously malicious ports.
Analyst notes and limits
This take is based on DET0135 and its relationship to ATT&CK technique T1071.003 Mail Protocols. The most useful defensive work is local validation: identify expected mail-protocol behavior, confirm telemetry collection, and test whether the SOC can investigate unexpected mail-protocol sessions end to end.
The official object does not provide a description, detection text, tactics, or platforms. Platform and tactic context comes from the related technique only. No active exploitation, actor attribution, specific tools, or guaranteed detection coverage is asserted.
Detection of Mail Protocol-Based C2 Activity (SMTP, IMAP, POP3)
No official description is available in the imported ATT&CK source object.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| Enterprise | T1071.003 | Mail Protocols Sub-technique | This object detects Mail Protocols. |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | 286692937385… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack DET0135Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.