Live Active security incident? Get immediate response
MITRE ATT&CK® Analytic

AN0634: Analytic 0634

Unusual daemons or user processes binding/listening on ports outside of standard ranges, or initiating client connections using mismatched protocol/port pairings.

EnterpriseAN0634AnalyticObject v1.0 Modified
Glexia's Take

Analyst context for executives and security teams

Analyst confidence Medium

This analytic is about spotting Linux systems where unexpected daemons or user processes listen on unusual ports, or where network connections use protocol and port combinations that do not match normal expectations. For leaders, the value is not the port number itself; it is whether the organization can recognize when a Linux workload starts exposing an unexpected service or communicating in a way that may bypass assumptions in monitoring, firewall rules, or incident triage.

Executive priority

Prioritize this as a control-validation question for Linux server and workload resilience: do security teams know which services should listen, which ports are approved, and which protocol/port pairings are normal for critical systems? This supports incident response readiness, change governance, compliance evidence around network exposure, and SOC coverage validation. Because ATT&CK provides no tactic, relationship, or detection implementation for this analytic, it should be treated as a detection engineering and asset-baseline opportunity rather than proof of a specific threat campaign or impact scenario.

Technical view

For SOC and detection teams, validate whether Linux telemetry can identify processes that bind or listen on ports outside expected ranges and client connections where the observed protocol does not align with the port convention. Useful implementation depends on local baselines: approved daemon inventory, expected listening sockets per host role, known application exceptions, and network/service ownership. Tuning should separate legitimate administrative, development, containerized, or custom application services from unexpected listeners or mismatched protocol behavior. No ATT&CK relationship context is supplied, so correlation should be driven by local host criticality, recent change records, user/process ownership, and surrounding network activity.

Likely telemetry

  • Linux process execution and process ownership metadata
  • Listening socket and bound port inventory on Linux hosts
  • Network connection metadata including source, destination, port, and protocol
  • Service or daemon inventory and host role baseline
  • Change management or deployment records for expected service exposure

Detection direction

  • Baseline expected listening daemons and ports by Linux host role rather than relying only on global allow/deny port lists.
  • Alert on new or rare user processes binding/listening on non-standard ports, especially when not explained by approved change activity.
  • Validate protocol/port mismatches against environment-specific exceptions to reduce false positives from custom applications, proxies, tunnels, test services, or container workloads.
  • Correlate unusual listeners with process lineage, account context, package/service ownership, and recent configuration changes where telemetry exists.
  • Review monitoring blind spots for ephemeral cloud workloads, containers, unmanaged Linux servers, and hosts where socket or network telemetry is not retained.

Mitigation priorities

  • Maintain an approved service and port inventory for Linux systems, especially business-critical servers and externally reachable workloads.
  • Use network segmentation and host firewall policy to limit which services may listen or accept connections based on system role.
  • Strengthen change control so new listening services and custom protocol/port use are documented and reviewable by security teams.
  • Ensure Linux endpoint, network flow, and asset telemetry are retained long enough to support incident triage.
  • Regularly reconcile observed listening ports against expected configuration to identify drift.
Analyst notes and limits

This object is a detection analytic, not a technique. The supplied ATT&CK fields identify Linux as the platform and describe the analytic behavior, but do not provide tactics, relationships, or an official detection implementation. Glexia interpretation therefore focuses on defensive validation: baselining, telemetry confirmation, tuning, and operational use in SOC and incident response workflows.

No official detection logic, related ATT&CK techniques, tactics, data sources, procedures, or mitigations were supplied. Local environment knowledge is required to define standard port ranges, expected daemons, approved custom services, and acceptable protocol/port exceptions. This take should not be read as evidence of active exploitation, attribution, or guaranteed detection coverage.

Official MITRE ATT&CK definition

Analytic 0634

Unusual daemons or user processes binding/listening on ports outside of standard ranges, or initiating client connections using mismatched protocol/port pairings.

View the same entry on attack.mitre.org (MITRE-hosted reference; in-page links above use the Glexia ATT&CK library.)

Glexia analysis

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.

Relationship explorer

All related ATT&CK context

No relationships are available in the current normalized data for this object.

Change history

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 .

ATT&CK release
19.1
Object version
1.0
Created
Modified
Raw hash
0603c8052f94b4d7...
Imported snapshots across ATT&CK releases (1)
Release Bundle imported Object version Modified Status Raw hash
19.1 1.0 Current bundle 0603c8052f94…
Raw source

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.

Source references

External references and citations

MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.

  1. [1]
    mitre-attack AN0634
    Open source URL
Source and licensing

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.