Security teams can detect lsof by monitoring for its execution on hosts where process and file inspection is unusual, such as servers that should not need interactive troubleshooting tools. Because it enumerates open files and network sockets, review who ran it, from where, and what they collected. Pair command auditing with least-privilege controls.
What lsof activity looks like in telemetry
Detection starts with understanding that lsof is a legitimate administration tool, but it is also a useful discovery utility for an intruder who wants to map what is running, which files are open, and which sockets are active. On a normal workstation, interactive use may be expected; on production servers, jump hosts, and restricted workloads, it is often a stronger signal when the command appears at all, especially outside approved maintenance windows.
Focus on process creation and command-line telemetry rather than the binary name alone. A user launching lsof from an unusual parent process, from a remote shell, or with flags that enumerate broad filesystem or network state is more informative than a simple execution count. That context helps separate routine troubleshooting from reconnaissance.
Because the tool can reveal high-value operational detail, the stronger detection pattern is not just “lsof ran”, but “who ran it, from where, and what else happened around it.” That means correlating process logs, shell history where available, and endpoint telemetry with the host role and the operator’s normal job function. The same command can be benign on an administrator workstation and suspicious on a database server or container node.
Where the signal becomes more useful
Detection improves when teams combine command auditing with host hardening and user-behaviour baselines. If a server rarely needs interactive troubleshooting, any appearance of lsof should be treated as a possible precursor to deeper enumeration. That is especially true when it appears alongside other discovery commands, privilege checks, or attempts to locate configuration, secrets, or live connections.
Monitoring should also account for wrappers and aliases. An attacker does not need to call the binary in an obvious way if they can invoke it through a script, package manager, remote execution tool, or a renamed copy placed on disk. Good telemetry catches the command line, execution path, and the process tree, not just a filename match.
For teams using general detection content as a model, the same idea appears in broader operational monitoring guidance from NIST Cybersecurity Framework 2.0 and in adversary-technique mapping through MITRE ATT&CK Enterprise Matrix. Both help frame lsof as a discovery behavior that belongs in detection engineering, not as a standalone alert.
How to investigate and reduce the blast radius
If lsof appears in an unexpected place, investigate the surrounding activity before deciding whether it is harmless. Check the account, session origin, time of day, and whether the host is meant to support ad hoc troubleshooting. Review whether the command was followed by file reads, network enumeration, privilege escalation attempts, or access to sensitive application paths. If the tool was used to inspect sockets, that may indicate the operator was mapping lateral movement opportunities or looking for exposed services.
Containment is usually simple but should be deliberate. Restrict interactive access on servers that do not need it, enforce least-privilege execution, and make sure privileged troubleshooting is time-bound and auditable. If you discover lsof running under an account that should not have that visibility, treat that as an access-control issue as much as a detection event.
Command auditing works best when paired with controls that limit who can run investigative utilities in the first place. A practical reference point is NIST SP 800-53 Rev 5 Security and Privacy Controls, especially the audit, access control, and configuration-management families that support both prevention and detection.
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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | DE.CM-01 — Networks and network services are monitored | lsof reveals live connections that belong in ongoing monitoring. |
| PR.AA-05 — Access permissions and authorizations are managed, incorporating the principle of least privilege and separation of duties | Unexpected lsof use often indicates excessive host visibility or privilege. | |
| Recommendation — Correlate unusual lsof execution with host and network monitoring for discovery activity. Restrict who can run inspection utilities on sensitive hosts. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Command auditing is the core detection method for unusual lsof execution. |
| AC-6 — Least Privilege | lsof should be limited to users and systems that truly need broad process visibility. | |
| Recommendation — Review shell and process audit records for anomalous lsof usage. Limit interactive troubleshooting rights on production systems. | ||
| MITRE ATT&CK | T1057 — Process Discovery | lsof is commonly used to inspect running processes and associated resources. |
| Recommendation — Map suspicious lsof activity to process-discovery detections and hunt for follow-on recon. | ||
Practitioner Guidance
What to verify: Baseline where lsof is normal and where it is not, then verify that your telemetry includes command line, parent process, user, host role, and remote origin. A binary-name alert without that context will miss the difference between routine admin work and reconnaissance.
What to prioritise: Prioritise servers, jump boxes, and production environments where interactive troubleshooting should be rare. On those assets, treat unexplained lsof use as a discovery signal that deserves follow-up even if no other malicious activity is visible yet.
Decision rule: If the command appears on a host that should not need it, or under an account that should not have broad visibility into open files and sockets, investigate immediately and review whether the account’s permissions are already too broad.
Practitioner takeaway: The most useful detection is not the command by itself, but the mismatch between the command, the operator, and the host’s expected administrative model.
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