Process open files are the files, sockets, pipes and other file descriptors that a running process currently has open. They represent active operating system resources, and they can reveal what data the process is reading or writing, as well as which network connections or logs it is using.
What process open files are
Process open files are the live file descriptors a running process currently holds, including files, sockets, pipes, and similar OS resources. They show what the process can read, write, or communicate with at that moment.
Why process open files matter
Open file descriptors are more than bookkeeping. They expose the operating system resources a process is actively using, which makes them useful for understanding runtime behaviour, diagnosing hangs, and spotting unexpected access to data, logs, or network endpoints. A process with an unusual file set can be a sign of a hidden dependency, a misbehaving service, or activity that deserves closer inspection.
They also help explain the boundary between process state and system state. A descriptor can point to a regular file, a FIFO, a socket, a device, or an anonymous resource, so the open-files view often reveals much more than a simple process list.
What they reveal about runtime behaviour
Because file descriptors are live handles, they can show where a process is sending output, which configuration or data files it has loaded, and whether it is connected to local or remote services. That makes them especially useful during troubleshooting, incident response, and forensic triage when you need to reconstruct what a process was doing before it exited or was terminated.
Open sockets are often the most security-relevant part of this picture. They may show an active listener, an outbound connection, or a process tied to a service endpoint that was not expected. Open logs can be just as important, because they may indicate what telemetry the process is producing or which log paths it is touching.
Operational and security implications
Open files can expose data exposure, process compromise, and lateral movement risk when a process inherits access it should not have. If a high-privilege service keeps sensitive files or sockets open longer than necessary, an attacker who gains code execution inside that process may be able to reuse those handles without needing to reopen the resource.
They also matter for availability. Exhausted file descriptors, descriptor leaks, or runaway socket growth can cause services to stall, fail to accept new connections, or behave unpredictably under load. In other words, process open files are both a visibility signal and a stability signal.
How to examine them safely
Practitioners usually inspect open files to answer a narrow question: what is this process actually holding open right now? That inspection is most useful when combined with process ownership, parent-child relationships, listening ports, and recent changes in service behaviour. Used together, these clues help distinguish normal runtime state from suspicious or broken state.
When reviewing them during an incident, treat the file list as a lead, not a conclusion. The descriptors tell you what is open; they do not by themselves explain why it is open or whether the access is authorised. That distinction comes from the surrounding context, such as the process role, its runtime environment, and the expected application behaviour.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Open file activity can support investigation and review of process behaviour. |
| AC-6 — Least Privilege | Unexpected open files often indicate a process has more access than it needs. | |
| Recommendation — Review process and descriptor activity to identify unexpected data access or communication paths. Restrict process permissions so services can open only the files and sockets they require. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Open log handles and unexpected log access are part of monitoring process activity. |
| Recommendation — Monitor and protect logs so process activity remains visible and tamper resistant. | ||
| MITRE ATT&CK | T1057 — Process Discovery | Inspecting open files is a common way to enumerate what a process is doing. |
| Recommendation — Correlate process discovery with open descriptor inspection to spot suspicious runtime behaviour. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitored Environment | Open files and sockets are runtime telemetry used to monitor system behaviour. |
| Recommendation — Continuously monitor process resources so unusual file and socket use is detected early. | ||
Related resources from NHI Mgmt Group
- What should teams do when AI workflows need to process large logs or files?
- What breaks when security teams do not monitor guardrail files and anomalous AI process behavior?
- Why do PowerShell string replacements sometimes fail in scripts that process logs or configuration files?
- What happens when AI coding assistants process rules files that contain hidden malicious instructions?