DC0048: Named Pipe Metadata
Contextual data about a named pipe on a system, including pipe name and creating process (ex: Sysmon EIDs 17-18)
*Data Collection Measures:*
- Windows: - Sysmon Event ID 17: Logs the creation of a named pipe. - Sysmon Event ID 18: Logs connection attempts to a named pipe. - Windows Security Event ID 5145: Logs access attempts to named pipes via SMB shares. - ETW (Event Tracing for Windows): Provides deep telemetry into named pipe interactions. - Linux/macOS: - AuditD (`mkfifo`, `open`, `read`, `write` syscalls): Tracks FIFO (named pipe) creation and usage. - Lsof (`lsof -p
Analyst context for executives and security teams
Named Pipe Metadata is defensive evidence about inter-process communication paths, such as the pipe name and the process that created or connected to it. Its value is not that every named pipe is suspicious; it helps SOC and incident response teams understand which processes are communicating locally or over SMB-backed pipe access and whether that activity fits the environment. For leaders, this is a coverage question: do endpoint, Windows, Linux/macOS, EDR, and forensic workflows preserve enough pipe context to investigate suspicious process-to-process behavior when an incident occurs?
Executive priority
Treat this as an incident readiness and telemetry assurance item. Named pipe evidence can support investigations involving process relationships and lateral or local communication patterns, but ATT&CK provides no tactic, technique relationship, or detection logic for this data component here. Security leaders should ask whether logging and retention are sufficient to reconstruct named pipe creation, connection, and access attempts, and whether that evidence is available to the SOC and IR teams during containment decisions.
Technical view
Validate that named pipe context is collected where relevant: pipe name, creating process, connecting process or access attempt, timestamp, host, user context when available, and process lineage from adjacent endpoint telemetry. MITRE lists Windows collection via Sysmon Event IDs 17 and 18, Windows Security Event ID 5145 for named pipe access attempts via SMB shares, ETW for deeper interactions, Linux/macOS collection through AuditD syscall coverage for FIFO creation and use, lsof/strace for investigative visibility, EDR process tracking, and memory forensics such as Volatility pipescan or Rekall. Because no official detection analytic is provided and no relationships are supplied, teams should use this component as supporting evidence rather than a standalone alert source.
Likely telemetry
- Sysmon Event ID 17 for named pipe creation
- Sysmon Event ID 18 for named pipe connection attempts
- Windows Security Event ID 5145 for access attempts to named pipes via SMB shares
- ETW telemetry for named pipe interactions
- AuditD records for mkfifo, open, read, and write syscall activity related to FIFOs on Linux/macOS
Detection direction
- First confirm telemetry availability and normalization before writing alerts: pipe name, process identity, host, user, and timing are the minimum fields needed for useful triage.
- Use named pipe metadata to enrich process and access investigations, not as a high-confidence detection by itself, because ATT&CK provides no official detection guidance for this object.
- Tune for environmental baselines: many operating system, application, and administrative workflows legitimately use named pipes or FIFOs, so false positives are likely without process and host context.
- Validate Windows coverage separately for local pipe creation/connection and SMB share pipe access, since Sysmon, Security Event 5145, and ETW expose different slices of behavior.
- For Linux/macOS, distinguish continuous monitoring such as AuditD from point-in-time investigative tools such as lsof or strace.
Mitigation priorities
- Prioritize collection and retention of named pipe metadata on systems where endpoint investigation quality matters most.
- Ensure EDR or endpoint logging captures process context around pipe creation and connection rather than only pipe names.
- For Windows environments, validate Sysmon, Security Event 5145, and ETW coverage according to operational need and retention requirements.
- For Linux/macOS environments, validate AuditD rules or equivalent monitoring for FIFO creation and use where feasible.
- Document how SOC and IR teams pivot from named pipe evidence to process lineage, user context, host role, and timeline reconstruction.
Analyst notes and limits
This ATT&CK object is a data component, not a technique. It describes the kind of evidence defenders may collect: contextual data about a named pipe, including pipe name and creating process. The supplied object has no tactics, no platforms in the platform field, no official detection text, and no relationship context, so this take focuses on telemetry validation and investigation value rather than threat behavior or attribution.
Coverage and decision value depend on local logging configuration, endpoint tooling, retention, and analyst access. The supplied ATT&CK fields do not identify specific techniques that use this data component, do not provide detection analytics, and do not support claims about active exploitation, adversary groups, or guaranteed detection outcomes.
Named Pipe Metadata
Contextual data about a named pipe on a system, including pipe name and creating process (ex: Sysmon EIDs 17-18)
*Data Collection Measures:*
- Windows: - Sysmon Event ID 17: Logs the creation of a named pipe. - Sysmon Event ID 18: Logs connection attempts to a named pipe. - Windows Security Event ID 5145: Logs access attempts to named pipes via SMB shares. - ETW (Event Tracing for Windows): Provides deep telemetry into named pipe interactions. - Linux/macOS: - AuditD (`mkfifo`, `open`, `read`, `write` syscalls): Tracks FIFO (named pipe) creation and usage. - Lsof (`lsof -p
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 | 2.0 | Current bundle | 3a02c9e661a7… |
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 DC0048Open 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.