lsof lists open files and the processes that hold them, including sockets, directories, and device files. It helps identify which process is using a port, file, or mount point, which is useful during incident response and troubleshooting. Unexpected open handles can reveal hidden services, data access, or persistence.
How lsof maps open files to the processes using them
lsof works by querying kernel-maintained file and socket tables and then correlating that state with process information. The result is a live inventory of which process has which file descriptor open, whether that object is a regular file, directory, character device, socket, or pipe. That makes lsof especially useful when you need to turn an abstract symptom, like “something is listening on this port,” into a specific process and PID.
The practical value is that it shows ownership, not just presence. A port can be open because a service is bound to it, a file can stay busy after deletion, and a mount can remain in use even when the path looks idle. lsof helps explain those situations by exposing the process-to-resource relationship that the operating system is actually enforcing.
Because it reads current kernel state, lsof is a point-in-time diagnostic tool rather than a historical recorder. It is best used when you already know the resource you care about and need to identify the process holding it, or when you want to confirm whether a handle is still active after a restart, unmount, or cleanup attempt.
What lsof shows that matters during troubleshooting
lsof is useful because “open file” in Unix-like systems is broader than most people expect. Network sockets, named pipes, device nodes, and mounted filesystems all appear in the same model. That means the same command can help with a blocked TCP port, a log file that will not rotate, a deleted file that is still consuming disk space, or a filesystem that refuses to unmount because some process still has it open.
Its output is easiest to interpret when you focus on a few fields: the process name, PID, user, file descriptor, and the object type or path. From there, you can decide whether the open handle is expected, whether it belongs to a known service, and whether the access pattern matches the incident or outage you are investigating.
Used well, lsof shortens the gap between symptom and cause. Instead of guessing which daemon is bound to a port or which application is keeping a file alive, you can identify the exact process and then inspect that process further with normal operating system tooling.
For Linux and Unix administration workflows, the same kind of visibility is often paired with broader control guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls, especially when teams need auditability around process activity and access paths.
Why open-handle visibility can expose security issues
Unexpected open files can reveal more than operational noise. A process listening on a port may indicate an unplanned service, a stale management interface, or a persistence mechanism that survived cleanup. A binary or script held open after deletion can point to a running process that is not visible from the filesystem alone. In incident response, those clues matter because they show what is still active, what is still reachable, and what may still be trusted by the system.
The failure mode is usually not lsof itself, but the condition it helps uncover: hidden services, lingering sessions, abandoned files, or an application holding sensitive data longer than intended. On a compromised host, that kind of visibility helps triage whether a process deserves immediate termination, deeper forensic review, or simple administrative cleanup.
It is also useful for spotting misconfiguration. If a service is binding to an unexpected interface, or if a privileged process has access to files it should never need, the open-handle view can expose that drift quickly. For teams that manage non-human service credentials and long-lived automation, the broader pattern of exposed runtime access is closely aligned with the concerns covered in the OWASP Non-Human Identity Top 10, where overprivilege, secret exposure, and stale access paths are recurring failure modes.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Audit Events | Open-handle visibility supports event tracing and incident investigation. |
| AC-6 — Least Privilege | Unexpected open files can expose excess process access to resources. | |
| CM-8 — System Component Inventory | lsof helps identify live process-resource relationships that inform inventory and ownership. | |
| Recommendation — Log and review process and file-access activity that changes system state. Restrict processes to the minimum files, sockets, and devices they need. Maintain accurate inventory of services and their resource bindings. | ||
| CIS Controls v8 | CIS-5 — Account Management | Open handles can indicate overpowered service or user processes that need tighter control. |
| Recommendation — Review process and service accounts that can access sensitive resources. | ||
| MITRE ATT&CK | T1057 — Process Discovery | lsof is often used to enumerate running processes tied to open resources during investigations. |
| T1049 — System Network Connections Discovery | lsof reveals listening sockets and active network endpoints on a host. | |
| Recommendation — Correlate discovered processes with other host telemetry to validate activity. Check discovered sockets against approved services and expected ports. | ||
Practitioner Guidance
What to verify: Treat lsof output as a lead, not proof of benignity. Verify the owning process, its command line, its parent process, and whether the open object is expected for that workload before you close anything.
Decision rule: If the open handle belongs to an internet-facing service, a privileged process, or a deleted file that still matters to the investigation, prioritise containment and process review before routine cleanup. If it is a known service on a known path, confirm whether the handle is part of normal startup or rotation behaviour.
What practitioners underestimate: The most important value of lsof is not just finding a listener, it is revealing stale or invisible runtime state. That makes it useful for both outage work and incident response, especially when the system looks clean from the filesystem but still has active access paths underneath.
Practitioner takeaway: Use lsof to answer one question quickly: which process still owns the resource you care about? Once you know that, the next step is process validation, not blind remediation.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org