AN1955: Analytic 1955
Monitor and analyze traffic patterns and packet inspection associated to protocol(s) that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)). Depending on the specific method of phishing, the detections can vary. Monitor for suspicious email activity, such as numerous accounts receiving messages from a single unusual/unknown sender. Filtering based on DKIM+SPF or header analysis can help detect when the email sender is spoofed.[1][2] When it comes to following links, monitor for references to uncategorized or known-bad sites. URL inspection within email (including expanding shortened links) can also help detect links leading to known malicious sites. Monitor social media traffic for suspicious activity, including messages requesting information as well as abnormal file or data transfers (especially those involving unknown, or otherwise suspicious accounts).
Monitor call logs from corporate devices to identify patterns of potential voice phishing, such as calls to/from known malicious phone numbers. Monitor network data for uncommon data flows. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.
Analyst context for executives and security teams
AN1955 is a broad detection analytic for spotting suspicious communications before or around user targeting: malformed or unusual protocol traffic, spoofed or suspicious email, risky links, suspicious social media messages, unusual voice-call patterns, and processes making network connections they normally do not make. Its business value is not a single alert rule; it is a coverage checklist for whether the organization can see and correlate the communications channels attackers may use to reach users or establish suspicious traffic patterns.
Executive priority
Treat this as a readiness test for phishing-resistant operations and communications monitoring. Leaders should ask whether email authentication evidence, URL inspection, network-flow visibility, endpoint process context, social messaging governance, and corporate call-log review are available to the SOC and usable during incidents. The priority is business continuity and incident decision-making: if these evidence sources are missing or siloed, teams may struggle to validate suspicious outreach, contain compromised accounts, or prove control effectiveness for audit and compliance purposes.
Technical view
For SOC, detection engineering, and IR teams, validate visibility across the evidence types named in the analytic: packet or protocol inspection for traffic that violates expected standards or flows; email sender/header analysis including DKIM and SPF results; URL inspection and expansion of shortened links; monitoring for messages from unusual or unknown senders to many accounts; social media traffic or message activity where corporate monitoring is authorized; corporate device call logs for suspicious voice-phishing patterns; and endpoint process plus command-line context for processes initiating uncommon network connections. Because no tactic or formal detection logic is supplied, this should be implemented as a set of correlation and triage requirements rather than a single deterministic rule.
Likely telemetry
- Network traffic metadata and packet/protocol inspection records
- Network flow records showing uncommon or first-seen communications
- Email gateway logs, sender headers, DKIM results, and SPF results
- URL inspection results from email, including expanded shortened links
- Known-bad or uncategorized site reputation data used during email/link analysis
Detection direction
- Validate that email detections can identify many recipients receiving messages from a single unusual or unknown sender and can surface spoofing indicators from DKIM, SPF, and header analysis.
- Tune network analytics for traffic that does not match expected protocol standards or established flows, while accounting for legitimate but unusual applications, scanners, and troubleshooting tools.
- Correlate uncommon network connections with process name, process lineage, and command-line arguments to identify files or processes that do not normally initiate connections for the relevant protocol.
- Confirm URL analysis expands shortened links and distinguishes uncategorized, newly seen, and known-bad destinations without over-relying on reputation alone.
- If social media or call-log monitoring is in scope, define privacy, legal, and ownership boundaries before using that telemetry operationally.
Mitigation priorities
- Prioritize email authentication and anti-spoofing controls using DKIM, SPF, and header-based analysis as supported by the cited references.
- Ensure email security workflows inspect links, expand shortened URLs, and preserve message metadata needed for incident response.
- Maintain network and endpoint telemetry that allows correlation between anomalous traffic patterns and the local process or command line responsible for the connection.
- Define SOC playbooks for suspicious email, link-click, social message, and voice-phishing reports so analysts can pivot across communications, endpoint, and network evidence.
- Review monitoring coverage for corporate communications channels and document exclusions for compliance and risk acceptance.
Analyst notes and limits
The ATT&CK object is a detection analytic with a broad official description and no separate official detection field, tactics, or relationship context supplied. It is most useful as a validation framework for communications and network anomaly visibility associated with phishing-like delivery methods and suspicious traffic patterns. Local baselines are essential because several suggested signals depend on what is normal for the organization’s users, applications, protocols, and communications channels.
No relationships, tactics, aliases, or concrete rule logic were supplied. The platform is listed only as PRE, and no active exploitation, actor attribution, impact, or guaranteed detection coverage is stated. Any implementation must be adapted to local telemetry availability, legal/privacy constraints, managed versus unmanaged assets, and the organization’s approved monitoring scope.
Analytic 1955
Monitor and analyze traffic patterns and packet inspection associated to protocol(s) that do not follow the expected protocol standards and traffic flows (e.g extraneous packets that do not belong to established flows, gratuitous or anomalous traffic patterns, anomalous syntax, or structure). Consider correlation with process monitoring and command line to detect anomalous processes execution and command line arguments associated to traffic patterns (e.g. monitor anomalies in use of files that do not normally initiate connections for respective protocol(s)). Depending on the specific method of phishing, the detections can vary. Monitor for suspicious email activity, such as numerous accounts receiving messages from a single unusual/unknown sender. Filtering based on DKIM+SPF or header analysis can help detect when the email sender is spoofed.[1][2] When it comes to following links, monitor for references to uncategorized or known-bad sites. URL inspection within email (including expanding shortened links) can also help detect links leading to known malicious sites. Monitor social media traffic for suspicious activity, including messages requesting information as well as abnormal file or data transfers (especially those involving unknown, or otherwise suspicious accounts).
Monitor call logs from corporate devices to identify patterns of potential voice phishing, such as calls to/from known malicious phone numbers. Monitor network data for uncommon data flows. Processes utilizing the network that do not normally have network communication or have never been seen before are suspicious.
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 | c346c2d3bb3a… |
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]
Microsoft Anti Spoofing
Microsoft. (2020, October 13). Anti-spoofing protection in EOP. Retrieved October 19, 2020.
Open source URL -
[2]
ACSC Email Spoofing
Australian Cyber Security Centre. (2012, December). Mitigating Spoofed Emails Using Sender Policy Framework. Retrieved November 17, 2024.
Open source URL -
[3]
mitre-attack AN1955Open 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.