AN0380: Analytic 0380
Detects non-interactive or script-driven email transmission using tools like `sendmail`, `mailx`, or custom SMTP scripts by background processes, especially when sending attachments or large payloads.
Analyst context for executives and security teams
This analytic is about spotting Linux systems that send email non-interactively, such as background jobs or scripts using sendmail, mailx, or custom SMTP code, especially when attachments or large payloads are involved. For leaders, the value is not the tool name; it is whether servers can quietly transmit data outside normal user-driven mail flows and whether the SOC can prove that such activity is expected, governed, and observable.
Executive priority
Prioritize this as a control-validation item for Linux server estates that handle sensitive data, operational logs, reports, or automated business workflows. The key business question is: which systems are allowed to send email directly, with attachments or large payloads, and can security teams distinguish approved automation from suspicious background activity? This supports incident decision-making, audit evidence around outbound data handling, and resilience planning for systems that may bypass centralized mail controls.
Technical view
For SOC and detection engineering teams, validate visibility into Linux process execution and outbound email behavior from non-interactive contexts. Focus on sendmail, mailx, and script-driven SMTP activity launched by background processes, scheduled jobs, service accounts, or application runtimes. Because the ATT&CK object does not provide detection logic or tactic mapping, local baselining is essential: identify legitimate automated mail senders, expected attachment patterns, normal payload sizes, destinations, and parent processes before alerting aggressively.
Likely telemetry
- Linux process execution events with command line, parent process, user, working directory, and timestamp
- Mail transfer agent logs or local mail command logs where available
- Outbound SMTP network connection metadata from Linux hosts
- Scheduled task or service execution context, such as cron-like or service-managed background execution evidence
- File metadata associated with attachments or unusually large payloads, where collected by endpoint or mail telemetry
Detection direction
- Inventory approved Linux hosts and processes that are permitted to send automated email directly.
- Baseline sendmail, mailx, and scripted SMTP usage by parent process, user, destination, frequency, attachment presence, and payload size.
- Tune for non-interactive or background process execution rather than only tool invocation, since legitimate administrative and application workflows may use the same utilities.
- Review large attachments or payloads in context of expected business jobs, report generation, backups, and monitoring workflows to reduce false positives.
- Correlate process telemetry with SMTP network activity and local mail logs to separate actual transmission from failed or benign command execution.
Mitigation priorities
- Define which Linux systems and service accounts are authorized to send email directly.
- Route approved automated email through governed mail infrastructure where feasible so logging, policy, and review are consistent.
- Restrict or monitor direct outbound SMTP from systems without a business need.
- Harden service accounts and scheduled/background job ownership so unexpected mail-sending behavior can be investigated quickly.
- Maintain documentation of approved automated email workflows to support SOC triage and compliance evidence.
Analyst notes and limits
The supplied object is a detection analytic for Linux and describes non-interactive or script-driven email transmission using sendmail, mailx, or custom SMTP scripts, especially with attachments or large payloads. No ATT&CK tactic, relationship context, or official detection logic was supplied, so this take frames practical validation and governance rather than asserting a specific adversary objective.
This assessment is limited to the official STIX fields, the MITRE external reference, and the absence of relationship context. It does not establish active exploitation, attribution, impact, or existing detection coverage. Local environment evidence is required to distinguish legitimate automated email from suspicious activity.
Analytic 0380
Detects non-interactive or script-driven email transmission using tools like `sendmail`, `mailx`, or custom SMTP scripts by background processes, especially when sending attachments or large payloads.
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.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
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 | 524c8a9cc6c0… |
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 AN0380Open 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.