AN1983: Analytic 1983
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)). Consider monitoring social media activity related to your organization. Suspicious activity may include personas claiming to work for your organization or recently created/modified accounts making numerous connection requests to accounts affiliated with your organization. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access (ex: Spearphishing via Service).
Analyst context for executives and security teams
AN1983 is a detection analytic focused on spotting suspicious protocol behavior and organization-related social media activity that may precede or support initial access attempts. Its business value is in validating whether the organization can notice abnormal network traffic patterns and suspicious external personas before they become an incident-response problem.
Executive priority
Treat this as a coverage-validation item for early warning and incident readiness rather than a standalone control. Leaders should ask whether network inspection, endpoint process context, and social media monitoring are actually collected, reviewed, and tied to escalation procedures. This can support resilience, audit evidence, and prioritization of monitoring gaps around initial access scenarios such as spearphishing via service.
Technical view
For SOC and detection engineering teams, validate monitoring for protocol traffic that does not match expected standards or flows, including extraneous packets, gratuitous or anomalous traffic, and abnormal syntax or structure. Where available, correlate network anomalies with process execution, command-line arguments, and files that do not normally initiate connections for the relevant protocols. Also assess whether suspicious social media activity tied to the organization is reviewed, such as personas claiming employment or newly created or modified accounts sending many connection requests to organization-affiliated accounts.
Likely telemetry
- Network traffic metadata and flow records
- Packet capture or packet inspection outputs
- Protocol parsing or network security monitoring alerts
- Endpoint process execution telemetry
- Command-line telemetry
Detection direction
- Establish what “expected” protocol standards and traffic flows look like in the local environment before alerting on anomalies.
- Tune for traffic that is structurally or syntactically anomalous, not just high-volume or unknown traffic.
- Correlate network anomalies with process and command-line context to reduce weak standalone network alerts.
- Validate whether social media monitoring has a defined triage path for suspected employee impersonation or suspicious connection-request campaigns.
- Account for false positives from legitimate nonstandard implementations, testing activity, protocol misclassification, or authorized social media activity.
Mitigation priorities
- Prioritize visibility first: confirm packet inspection, flow monitoring, and endpoint process telemetry are collected where relevant.
- Document expected protocol behaviors for important services so anomalies can be assessed consistently.
- Create escalation procedures connecting SOC, incident response, communications, and identity teams for suspicious organization-related social media activity.
- Use the analytic to inform initial-access readiness exercises, especially scenarios involving spearphishing via service.
- Maintain evidence of monitoring coverage and triage outcomes for compliance and control-assurance discussions.
Analyst notes and limits
This object is a MITRE detection analytic, not a technique. The supplied object lists platform PRE, has no tactic specified, and provides no relationship context. The description supports both network/protocol anomaly monitoring and social media monitoring related to the organization.
Official detection logic is not provided, and no relationships are supplied. Local baselines, telemetry availability, and operating procedures are required to determine whether this analytic is actionable in a specific environment. No active exploitation, attribution, or guaranteed detection coverage is implied.
Analytic 1983
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)). Consider monitoring social media activity related to your organization. Suspicious activity may include personas claiming to work for your organization or recently created/modified accounts making numerous connection requests to accounts affiliated with your organization. Detection efforts may be focused on related stages of the adversary lifecycle, such as during Initial Access (ex: Spearphishing via Service).
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 | d14acc3788cd… |
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 AN1983Open 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.