lsof is a Unix utility that lists open files and the processes holding them. Because sockets are treated as files, it can reveal which processes are using network connections, logs or sensitive data files. Investigators use it to find unexpected access, blocked deletions and processes keeping files open after compromise.
What lsof Actually Tells You
lsof is most useful because it turns open-file state into an operational view of live process activity. On Unix systems that matters for ordinary files, logs, sockets, pipes and deleted-but-still-open files, which means it can expose process behavior that is otherwise hidden.
For investigators, that makes lsof a fast way to answer practical questions: what is holding a file open, which process is still writing to a log, and which daemon owns an unexpected network connection. Used well, it is less about “finding files” than about understanding which processes still have a claim on them.
Why Open Files Become a Security Signal
Open files are not inherently suspicious, but they become a security signal when they do not match expected runtime behavior. A process holding a sensitive file open after it should have exited, or maintaining access to a deleted file, can indicate persistence, data exposure, or simple operational failure.
Because sockets are represented as files, lsof can also show which processes are bound to network listeners or established connections. That makes it useful during incident triage, because it connects process identity to file activity and network exposure in one view.
Common Investigation Patterns
One of the most common uses of lsof is to explain why a file cannot be removed, rotated, or replaced. If a log, configuration file, or binary is still open, the filesystem may show the name as deleted while the process continues to use the underlying inode.
It is also used to spot unexpected associations between processes and resources. For example, a service that should not be touching a data file, or a shell left attached to an unusual TTY or pipe, can indicate misuse, misconfiguration, or compromise. For Linux hardening and related file-access hygiene, see the Linux Server Hardening Guide.
How lsof Fits into Incident Response
In incident response, lsof helps answer a narrow but important question: what is active right now? That makes it valuable for confirming whether a suspicious process still has file handles, whether a payload is still reachable through a mounted path, or whether a service is continuing to use a socket that should have been closed.
It is not a replacement for logs, endpoint telemetry, or deeper forensics, but it is often one of the quickest ways to validate whether a process is still interacting with sensitive material. Pairing process-to-file visibility with broader host controls such as the CIS Benchmarks helps reduce the chance that abnormal file access goes unnoticed.
Risk and Threat Considerations
Open-file visibility matters because attackers can abuse long-lived processes, stale handles and deleted-but-open files to keep access alive after cleanup attempts. If defenders do not check what still has a file or socket open, they can miss active compromise, blocked remediation, or covert access to sensitive data.
Failure mechanism: A process retains access through an open descriptor even after the file is renamed, deleted or rotated, allowing continued use of content or continued network activity.
Impact: Sensitive data can remain exposed, cleanup can fail, and investigators can misread the host state unless they correlate the open handle with the owning process.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | lsof supports reviewing live process and file activity to investigate suspicious access. |
| SI-4 — System Monitoring | The utility helps monitor live host activity and unexpected resource use. | |
| Recommendation — Correlate open-file findings with audit records to confirm which process touched sensitive resources. Use host monitoring to flag unusual file handles, listeners and deleted-but-open objects. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Open-file and log-handle visibility supports detecting when services keep logs or files open unexpectedly. |
| CIS-10 — Malware Defenses | Investigators use lsof during compromise review to spot suspicious processes and persistence on a host. | |
| Recommendation — Verify that logging and file-access telemetry can reveal stale or unexpected open handles. Inspect suspicious processes for unexpected file and socket activity during malware triage. | ||
| ISO/IEC 27001:2022 | A.8.16 — Monitoring activities | Open-file state is a host monitoring signal used to detect abnormal process behavior. |
| Recommendation — Include live file-handle checks in host monitoring and incident investigation procedures. | ||
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 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org