A security-focused guide to the find command — covering SUID/SGID binary auditing, world-writable file detection, recently modified system binary detection, and filesystem forensics for incident response.

What is the find command for security?

The find command searches for files and directories based on conditions — name, type, permissions, ownership, timestamps, size, and more — and can execute actions on matching files. For security purposes, it is the primary tool for filesystem auditing: finding all SUID/SGID binaries that could be exploited for privilege escalation, identifying world-writable directories where attackers can stage files, detecting recently modified system binaries that may indicate compromise, and locating files owned by unexpected users. Unlike dedicated file integrity tools like AIDE or Tripwire, find requires no prior baseline installation or database initialization — it can be used immediately on any Linux system for one-time security checks or integrated into automated monitoring scripts and cron jobs.

Syntax

find [path] [conditions] [actions]
find / -perm /4000 -type f -ls 2>/dev/null
find / -perm -0002 -type f 2>/dev/null
find /usr /bin /sbin -newer /etc/os-release -type f 2>/dev/null
find / -nouser -o -nogroup 2>/dev/null

Key permission filters: -perm /4000 matches SUID bit set; -perm /2000 matches SGID; -perm /6000 matches either; -perm -0002 matches world-writable (others have write bit). -newer file matches files modified more recently than the reference file. -nouser and -nogroup find orphaned files with no valid owner.

Key Options and Conditions

Flag / ParameterDescriptionSecurity Note
-perm /4000Match files with SUID bit set (any of the specified bits)SUID root binaries execute as root regardless of who runs them — audit these regularly
-perm /2000Match files with SGID bit setSGID on directories causes new files to inherit the directory's group — audit unexpected SGID directories
-perm -0002Match world-writable files (all specified bits must be set)World-writable files outside /tmp and /var/tmp are almost always a security misconfiguration
-nouserMatch files with no valid owner (orphaned after user deletion)Orphaned files can be accessed by a new user if they receive the same UID as the deleted account
-newer fileMatch files modified more recently than the specified reference fileUse with /etc/os-release or package manager database to find binaries modified after OS installation
-mtime -NMatch files modified in the last N daysDuring incident response, find all files modified in the last 24h to identify attacker artifacts
-exec cmd {} \;Execute a command on each matching fileCombine with ls, stat, or sha256sum to get additional metadata on matches
-lsPrint detailed listing (equivalent to ls -dils) for each match—

Common Use Cases

Find All SUID Files Outside Expected System Directories

A new SUID binary outside /bin, /usr/bin, /usr/sbin, or similar standard paths is a critical finding — it may be a privilege escalation tool planted by an attacker or an improperly installed third-party application. Build a baseline of expected SUID binaries and compare against this output regularly.

find / -user root -perm -4000 -type f -ls 2>/dev/null | sort -k11
find / -perm /6000 -type f -ls 2>/dev/null | grep -v '/usr/\|/bin/\|/sbin/'

Find World-Writable Files and Directories

World-writable files outside shared directories like /tmp are almost always a misconfiguration. In web server directories, they represent direct code injection opportunities. In system directories, they allow any user to modify files executed by privileged services.

find / -perm -0002 -type f -not -path '/proc/*' -not -path '/sys/*' -ls 2>/dev/null
find /var/www -perm -0002 -type d 2>/dev/null

Find Recently Modified System Binaries (Post-Compromise Check)

System binaries modified after the initial OS installation date are a primary indicator of rootkit installation or binary replacement. Using a known reference file (e.g., the OS release file, package manager cache) as the comparison baseline, find all binary files modified more recently.

find /bin /usr/bin /usr/sbin /sbin -newer /etc/os-release -type f -ls 2>/dev/null
find /lib /lib64 /usr/lib -newer /etc/os-release -type f -name '*.so*' -ls 2>/dev/null

Security Relevance: Filesystem State as Security Evidence

The filesystem state is a record of system history. Every file has timestamps, permission bits, and ownership that encode information about how and when it was placed there. Attackers who gain access to a Linux system leave filesystem artifacts: SUID binaries in unusual locations, modified system libraries for persistence (shared object injection), world-writable cron directories with malicious scripts, and files with no valid owner from a deleted attacker account. The find command with appropriate conditions is the most direct way to detect these artifacts without relying on application-layer monitoring that an attacker can disable. The key disciplines are: knowing your baseline (what SUID binaries are expected on a clean system), knowing the reference timestamp (when was the OS installed or last patched), and acting on any deviation from that baseline as a potential security finding.

  • find / on a busy server is I/O intensive — run during off-peak hours and redirect stderr to /dev/null to suppress /proc and /sys permission errors
  • SUID binaries outside standard system paths that appeared after OS installation require immediate investigation — they are rare in legitimate software
  • World-writable directories outside /tmp should not exist — any found in web roots, config directories, or application paths require immediate remediation
  • Files with no owner (-nouser) have a numeric UID that can be claimed by a new account — an attacker may delete their account and rely on an orphaned UID to re-access files
  • find -exec with chmod or chown is powerful but irreversible — test with -ls first to verify what you intend to modify

Practical Examples

Complete SUID/SGID audit with full details

find / -type f \( -perm -4000 -o -perm -2000 \) -ls 2>/dev/null | sort -k11

Finds all SUID and SGID files system-wide and prints detailed listing including inode, permissions, link count, owner, group, size, and modification date. Sort by path (column 11) for easier comparison against a known-good baseline.

Find all files modified in the last 24 hours in key system directories

find /etc /bin /usr/bin /usr/sbin /sbin /lib /lib64 /usr/lib -mtime -1 -type f -ls 2>/dev/null

Lists all regular files modified in the last 24 hours across critical system directories. Run this immediately after detecting suspicious activity to identify what the attacker created, replaced, or modified. Any unexpected entries require investigation — legitimate changes should correlate with a package update or deployment event.

Find files owned by a specific UID (useful when user account was deleted)

find / -uid 1001 -ls 2>/dev/null | head -50

Finds all files owned by a specific numeric UID. Useful when investigating files left by a deleted attacker account. The UID still owns the files even after the account is deleted, making them orphaned but recoverable. Substitute 1001 with the UID of the deleted account identified from audit logs.

Troubleshooting Common Issues

Problem: find produces massive stderr output with 'Permission denied' errors

Solution: Redirect stderr to /dev/null: find / ... 2>/dev/null. The permission errors are expected — find cannot traverse directories it cannot read, and /proc, /sys, and /run contain pseudo-files that are not readable by all processes. The valid results still appear on stdout.

Problem: find -newer returns unexpected results (too many or too few files)

Solution: The reference file’s modification time may not reflect what you expect. Use stat /etc/os-release to verify its mtime. For a more precise baseline, use -mtime -N with a specific day count, or use -newermt 'YYYY-MM-DD' for a specific calendar date.

Problem: find -perm /4000 returns no results on a system that should have SUID binaries

Solution: Verify the find command syntax for your distribution. Some older find versions require -perm +4000 instead of -perm /4000. Also check if you are running on a filesystem mounted with nosuid: mount | grep nosuid — SUID bits on a nosuid filesystem are ignored and may not be listed.

Summary

The find command with security-focused conditions is an immediately available filesystem auditing tool that requires no installation and no prior baseline configuration. Master the three critical security use cases — SUID/SGID binary enumeration, world-writable file detection, and recently modified system binary detection — and integrate them into regular security checks or post-incident investigation procedures on every Linux server you manage. Combined with stat for timestamp analysis and sha256sum for hash verification, find provides a complete manual file integrity toolkit.

  • Run find / -user root -perm -4000 -type f -ls 2>/dev/null on every new server to establish your SUID binary baseline
  • Any file in /bin, /usr/bin, or /usr/lib modified after OS installation that was not from a package update is a critical investigation item
  • World-writable files outside /tmp are almost always a misconfiguration — remove world-write bit with chmod o-w and investigate the cause

Do You Have an Inventory of SUID Binaries on Your Servers?

INTRAM performs filesystem security audits as part of every managed server engagement — auditing SUID binaries, world-writable files, and recently modified system paths across your entire infrastructure.

Request a Filesystem Audit

Let’s assess what your business actually needs.

We will use these details only to understand your request and reply appropriately.