A practitioner guide to executables, libraries, mapped files, handles, and sockets, with the exact commands for all three operating systems.

Executive Summary

Sooner or later every admin and every incident responder asks the same question: what is this process actually using? Maybe a volume will not unmount because something has it busy. Maybe a log file will not delete. Maybe an EDR alert fired on a binary you have never heard of and you need to know which DLLs it pulled in and which files it has open right now.

All three major operating systems can answer that question, but each one answers it differently, and the default tools on each one hide something important. This guide walks through the built-in and free tooling on Linux, macOS, and Windows, explains how to read what they return, and shows where each tool has blind spots.

Prerequisites and Architecture

Assumed Knowledge

• Comfort with a shell (bash/zsh) and PowerShell.
• Basic understanding of processes and PIDs.
• Local admin or sudo rights on the machine you are inspecting. Without them you only see your own processes.

Tooling by Platform

What Does “Using a File” Actually Mean?

When people say a process is “using” a file, they usually mean one of six different things. The operating system tracks each of them separately, which is why one tool rarely shows you the whole picture.

Decoding lsof Output

lsof (list open files) is the common language on Linux and macOS, so it is worth learning its columns once. The FD column is the one that tells you which of the six categories a row belongs to.

Step-by-Step Implementation Workflow

Step 1: Find the PID

Linux and macOS

# Exact name match, print PID and name
pgrep -l nginx

# Linux: show full command line too
pgrep -a nginx

# Both: ps with explicit columns
ps -eo pid,ppid,user,comm | grep -i nginx

Windows (PowerShell)

Get-Process -Name notepad | Select-Object Id, ProcessName, Path

# Classic cmd equivalent
tasklist /fi "imagename eq notepad.exe"

GUI verification: Activity Monitor (macOS) and Task Manager Details tab (Windows) both show a PID column. In Task Manager, right-click the column header and add it if it is hidden.

Step 2: Linux

Linux exposes almost everything through the /proc pseudo-filesystem, so you can answer most questions without installing anything. lsof then wraps it all in one view.

2a. The executable, command line, and working directory

Linux

sudo readlink /proc/<PID>/exe
sudo readlink /proc/<PID>/cwd
sudo tr '\0' ' ' < /proc/<PID>/cmdline; echo

If the binary was deleted after launch, readlink returns the old path with (deleted) appended. The kernel still holds the file, and you can recover it for analysis with sudo cp /proc/<PID>/exe /root/evidence/pid<PID>.bin.

2b. Open file descriptors

Linux

sudo ls -l /proc/<PID>/fd

# Example output (trimmed)
lrwx------ 1 root root 64 Oct 13 10:02 0 -> /dev/null
l-wx------ 1 root root 64 Oct 13 10:02 2 -> /var/log/nginx/error.log
l-wx------ 1 root root 64 Oct 13 10:02 4 -> /var/log/nginx/access.log
lrwx------ 1 root root 64 Oct 13 10:02 6 -> socket:[48211]

# Offset and open flags for a single descriptor
sudo cat /proc/<PID>/fdinfo/4

A socket:[48211] entry is an inode, not an address. Resolve it to an actual connection with sudo ss -tunap | grep 'pid=<PID>,' (TCP/UDP) or sudo ss -xp | grep 'pid=<PID>,' (Unix sockets).

2c. Shared libraries and memory-mapped files

Linux

# Unique mapped files (column 6 is the path)
sudo awk '$6 ~ /^\// {print $6}' /proc/<PID>/maps | sort -u

# Sized view, one line per mapping
sudo pmap -x <PID>

# Mapped files that were deleted or replaced on disk
sudo grep '(deleted)' /proc/<PID>/maps

A library showing (deleted) after a package update is normal and means the process needs a restart to pick up the patched version. A library showing (deleted) from /tmp or /dev/shm is not normal.

2d. Everything at once with lsof

Linux

# Everything for one PID
sudo lsof -n -P -p <PID>

# Executable plus mapped libraries only
sudo lsof -n -P -a -p <PID> -d txt,mem

# Numbered descriptors only (real open files, sockets, pipes)
sudo lsof -n -P -a -p <PID> -d 0-9999

# Network sockets only
sudo lsof -n -P -a -p <PID> -i

2e. Watch file activity live

Linux

sudo strace -f -e trace=%file -p <PID>

# Include descriptor-to-path resolution in the output
sudo strace -f -y -e trace=%file,read,write -p <PID>

Step 3: macOS

macOS has no /proc. lsof is the primary tool, but it has one important gap, and vmmap fills it.

3a. lsof on macOS

macOS

# Everything
sudo lsof -n -P -p <PID>

# Mapped files only (executable, frameworks, fonts, caches)
lsof -a -p <PID> -d txt

# Everything EXCEPT mapped files: real open handles, sockets, cwd
lsof -n -P -a -p <PID> -d '^txt'

# Network only
lsof -n -P -a -p <PID> -i

Here is what the -d txt view looks like against iTerm2, trimmed to the interesting columns:

Example: lsof -a -d txt -p 97070 (trimmed)

FD   SIZE/OFF   NAME
txt  124121456  /Applications/iTerm.app/Contents/MacOS/iTerm2
txt    1123120  /Applications/iTerm.app/.../Sparkle.framework/.../Sparkle
txt    4129840  /usr/lib/dyld
txt     330112  /usr/lib/libobjc-trampolines.dylib
txt    2134132  /System/Library/Fonts/Menlo.ttc
txt    7795064  /System/.../SystemAppearance.bundle/.../DarkAqua.car
txt  192120460  /System/Library/Fonts/Apple Color Emoji.ttc

Notice what is missing: AppKit, Foundation, libSystem, and every other system library. Those are present in memory, but they are not individual files on disk anymore.

3b. Fill the gap: the dyld shared cache and vmmap

macOS

# Every Mach-O image with a __TEXT segment, one per line
vmmap -w <PID> | grep '^__TEXT' | awk '{print $NF}' | sort -u

# Memory summary by region type
vmmap --summary <PID>

Run vmmap with sudo for processes owned by another user. Some Apple platform binaries are protected by SIP and will refuse inspection even from root; that is expected.

3c. GUI view in Activity Monitor

GUI verification: the tab lists the same rows as lsof -p <PID>, including the txt mappings and network sockets.

3d. Watch file activity live

macOS

sudo fs_usage -w -f filesys <PID>

# Filter by name instead of PID
sudo fs_usage -w -f filesys iTerm2

DTrace-based tools such as opensnoop are still installed but are largely blocked while SIP is enabled. fs_usage works without changing SIP.

Step 4: Windows

Windows splits the job across several tools. PowerShell handles the executable and modules, Sysinternals Handle and Process Explorer handle open handles, and Process Monitor handles live activity.

4a. The executable and command line

PowerShell (elevated)

(Get-Process -Id <PID>).Path

Get-CimInstance Win32_Process -Filter "ProcessId = <PID>" |
  Select-Object Name, ExecutablePath, CommandLine, ParentProcessId

4b. Loaded DLLs

PowerShell and cmd

# PowerShell: modules with full path and version
(Get-Process -Id <PID>).Modules |
  Select-Object ModuleName, FileName, FileVersion | Sort-Object FileName

# cmd: built in, no install
tasklist /m /fi "PID eq <PID>"

# Sysinternals ListDLLs: all modules, or unsigned modules only
listdlls64.exe -accepteula <PID>
listdlls64.exe -u <PID>

4c. Open handles (files, registry keys, mutexes)

cmd (elevated)

handle64.exe -accepteula -nobanner -p <PID>

# All handle types: files, keys, sections, mutants, events
handle64.exe -nobanner -a -p <PID>

# Example output (trimmed)
notepad.exe pid: 8120 HOST\manny
   40: File  (RW-)   C:\Windows
  1A4: File  (R-D)   C:\Users\manny\Documents\notes.txt

PowerShell: sockets owned by the PID

Get-NetTCPConnection -OwningProcess <PID>
Get-NetUDPEndpoint -OwningProcess <PID>

4d. GUI views: Process Explorer and Resource Monitor

GUI verification: the DLL pane in Process Explorer should match the module list from step 4b. If it shows more, you are probably looking at mapped data files, which Process Explorer lists alongside DLLs.

4e. Watch file activity live

Step 5: The Reverse Lookup (Who Has This File Open?)

Linux and macOS

# Who has this file open
sudo lsof /var/log/syslog

# Everything open under a directory tree (can be slow)
sudo lsof +D /mnt/usb

# Linux: who is keeping a mount busy, with process names
sudo fuser -vm /mnt/usb

Windows

# Which process has a handle to this file (name fragment works)
handle64.exe -nobanner C:\Logs\app.log

# Which processes loaded this DLL
tasklist /m version.dll
listdlls64.exe -d version.dll

GUI verification: Process Explorer’s Find > Find Handle or DLL (Ctrl+F) and the search box under Resource Monitor’s Associated Handles both search across every process at once.

Cross-Platform Cheat Sheet

Verification and Validation

Finding the files is half the job. In an investigation the next question is whether they are legitimate. These checks confirm the image on disk is what it claims to be and flag the classic red flags.

Verify the Executable

Linux: is it owned by a package and unmodified?

dpkg -S "$(sudo readlink /proc/<PID>/exe)"      # Debian/Ubuntu
rpm -qf "$(sudo readlink /proc/<PID>/exe)"       # RHEL/Fedora
dpkg --verify <package>   # or: rpm -V <package>

macOS: is it signed and notarized?

codesign --verify --deep --strict --verbose=2 /Applications/iTerm.app
codesign -dv --verbose=4 /Applications/iTerm.app 2>&1 | grep -E 'Authority|TeamID'
spctl --assess --verbose /Applications/iTerm.app

Windows: is it signed?

Get-AuthenticodeSignature -FilePath (Get-Process -Id <PID>).Path |
  Format-List Status, StatusMessage, SignerCertificate

Expected success output: dpkg -S returns a package name and --verify prints nothing; codesign reports valid on disk and satisfies its Designated Requirement and spctl reports accepted; Get-AuthenticodeSignature returns Status : Valid.

Hunt for Red Flags

Linux: deleted, fileless, or temp-dir binaries

sudo ls -l /proc/*/exe 2>/dev/null |
  grep -E '\(deleted\)|memfd:|/tmp/|/dev/shm/'

Linux and macOS: deleted files still held open

sudo lsof -n -P +L1

Windows: modules loaded from user-writable paths

foreach ($p in Get-Process) {
  try { $mods = $p.Modules } catch { continue }
  $mods | Where-Object { $_.FileName -match '\\(Temp|AppData|ProgramData)\\' } |
    Select-Object @{n='PID';e={$p.Id}}, @{n='Proc';e={$p.ProcessName}}, FileName
}

Expected success output: on a clean server the Linux sweep returns nothing. On a workstation the Windows sweep will return legitimate per-user apps (Teams, Slack, browser updaters); look for the ones you cannot explain, and cross-check them with listdlls64.exe -u.

Troubleshooting and Gotchas

1. Permission Denied or Empty Output

Symptom: /proc/<PID>/fd returns permission denied, lsof shows only a few rows, or .Modules throws an access-denied exception.

Cause: you are not elevated, or the target is protected. On Linux, Yama ptrace_scope can also block strace even as the same user. On macOS, SIP protects many Apple processes from vmmap even as root. On Windows, Protected Process Light (PPL) processes such as LSASS with RunAsPPL or Defender’s MsMpEng.exe refuse module enumeration to administrators.

Diagnose

# Linux: 0 = classic, 1 = parent-only, 2 = admin-only, 3 = disabled
cat /proc/sys/kernel/yama/ptrace_scope

# macOS: is SIP enabled?
csrutil status

Resolution: rerun with sudo or an elevated prompt. For PPL and SIP-protected targets, use handle-level tools (Handle, lsof) which still work, or collect a memory image with a proper forensic tool instead of fighting the protection.

2. macOS Seems to Be Missing Libraries

Symptom: lsof shows app frameworks and dyld but no AppKit, Foundation, or libSystem.

Cause: system libraries live inside the dyld shared cache and have no individual file on disk to report.

Resolution: use vmmap -w <PID> as shown in step 3b. Treat lsof on macOS as “files” and vmmap as “images”.

3. PowerShell Cannot Read Modules of a 64-bit Process

Symptom: A 32 bit processes cannot access modules of a 64 bit process.

Cause: you launched the 32-bit PowerShell (SysWOW64).

Diagnose

[Environment]::Is64BitProcess   # False means you are in 32-bit PowerShell

Resolution: open the 64-bit PowerShell or Windows Terminal, or use listdlls64.exe, which handles both architectures.

4. lsof Is Slow or Hangs

Cause: reverse DNS on every socket, port-name lookups, or a stale network mount.

Resolution: always add -n -P. On Linux, add -b to avoid kernel calls that block on unreachable NFS mounts, and send noise such as can't stat() fuse warnings to 2>/dev/null.

5. Disk Is Full but du Cannot Find the Space

Cause: a file was deleted while a process still had it open (classic with rotated logs). The space is not freed until the last descriptor closes.

Resolution: find it with sudo lsof -n -P +L1, then restart or signal the owning service. In an emergency on Linux you can truncate it through the descriptor: sudo truncate -s 0 /proc/<PID>/fd/<FD>.

6. Snapshot Tools Miss Short-Lived Files

Cause: lsof, Handle, and /proc show a moment in time. A file opened and closed in 20 ms will never appear.

Resolution: switch to a tracing tool: strace on Linux, fs_usage on macOS, Process Monitor on Windows.

7. Paths Do Not Exist When You Look for Them (Containers)

Cause: a containerized process sees its own mount namespace, so /app/config.yml in lsof output is relative to the container, not the host.

Resolution: reach the file through the process root, sudo ls -l /proc/<PID>/root/app/config.yml, or enter its namespaces with sudo nsenter -t <PID> -m -p.

Wrapping Up

The mental model is the same everywhere: an executable, its libraries, mapped data, open handles, sockets, and a working directory. What changes is which tool exposes which piece. On Linux, /proc and lsof see nearly everything. On macOS, pair lsof for files with vmmap for images. On Windows, pair PowerShell for modules with Sysinternals Handle for open files. Keep the cheat sheet handy and you will spend less time hunting for the right command and more time answering the actual question.

InfoSecMonkey: No fluff. Just the config that works.