Skip to content
LinuxForensics

ExecutionFile accessAnti-forensics

/tmp, /var/tmp and /dev/shm: Linux Staging Directories

World-writable Linux directories attackers use to stage tools: tmpfs versus disk, cleanup ages, noexec, memfd fileless execution and what survives reboot.

Location
/tmp, /var/tmp, /dev/shm, /run/user/<uid>
Distributions
Proves
That files were dropped or run from world-writable locations, by which user and when
Timestamps
Inode times (mtime, ctime, atime, birth where supported) in the filesystem's native precision; tmpfs keeps them in RAM only
Access
Any user can write; root needed to read other users' files (mode 1777 with sticky bit)
Retention
tmpfs: lost at reboot; disk: until cleaned by systemd-tmpfiles ages (upstream 10 days /tmp, 30 days /var/tmp) or deleted
Collection
UAC, Velociraptor, tar, AVML

Tools

Compare all tools

What it is

Every Linux system has directories that any user may write to: /tmp, /var/tmp and the shared-memory mount /dev/shm, plus per-user runtime directories under /run/user/<uid>. Attackers use them to download tools, unpack payloads, write scanner output and run binaries, because they are always present and usually writable even from a compromised web server account. The forensic value depends on one question first: is the directory on disk or on tmpfs (RAM)?

Where it lives

DirectoryTypical backingSurvives rebootNotes
/tmptmpfs on Fedora, Arch, openSUSE Tumbleweed and Debian 13 new installs; disk on Ubuntu, RHEL and Debian 12 and earlierOnly if on diskMode 1777 (sticky bit)
/var/tmpDisk on all mainstream distributionsYesIntended for files that persist across reboots
/dev/shmtmpfs (POSIX shared memory)NoFrequently used for fileless staging
/run/user/<uid>tmpfs created per logged-in user by systemd-logindNoRemoved when the user's last session ends
/run/lock, /var/locktmpfsNoOccasionally abused

Confirm on the host: findmnt /tmp /var/tmp /dev/shm (live) or /etc/fstab plus systemctl is-enabled tmp.mount and the files in /usr/lib/tmpfiles.d/, /etc/tmpfiles.d/ (image).

What it proves

  • A file existed in a world-writable location, with its owner UID, permissions and timestamps: often the dropped tool itself.
  • The executing account: files owned by www-data, apache or nginx in /tmp point to web application compromise.
  • Execution from these paths when correlated with /proc (exe, cwd), shell history, audit EXECVE records or cron entries.
  • Fileless execution: a process whose /proc/<pid>/exe points to /memfd:<name> (deleted) ran from an anonymous memory file created with memfd_create, which never touches a directory at all.
  • Not proven: absence. Cleanup timers, reboots on tmpfs and attacker deletion all remove files routinely.

Key fields

ItemMeaning
Owner UID / GIDAccount that created the file
ModeExecutable bits on dropped files; setuid bits are a red flag
Hidden namesLeading dot, spaces, or names imitating system files (.X11-unix look-alikes, .ICE-unix)
Mount optionsnoexec, nosuid, nodev on /tmp and /dev/shm (hardening; noexec does not stop interpreters such as bash script or python file)
tmpfiles.d lineType, path, mode, owner, age: q /tmp 1777 root root 10d in upstream systemd

Timestamps

Disk-backed directories keep the normal inode times of their filesystem (nanosecond mtime, ctime, atime and birth time on ext4 and XFS v5; see ext4 timestamps). tmpfs also tracks these times, but only in memory; stat on a live system shows them, including birth time on recent kernels. systemd-tmpfiles ages files by their most recent atime, mtime and ctime, so reading a file can keep it alive.

Retention

  • tmpfs (/dev/shm, /run/user, /tmp where applicable): everything is lost at reboot or unmount. Capture live or through a memory image.
  • systemd-tmpfiles-clean.timer runs daily and removes entries older than the configured age. Upstream defaults are 10 days for /tmp and 30 days for /var/tmp; Debian 13 adopts them for new installs, while upgraded Debian systems get an /etc/tmpfiles.d/tmp.conf preserving the old behaviour. Always read the actual configuration on the image.
  • Deleted files on disk may be recoverable from unallocated space or the filesystem journal for a while.

Collection

# live: list with full timestamps before anything is cleaned
find /tmp /var/tmp /dev/shm /run/user -xdev -printf '%M %u %g %s %TY-%Tm-%Td %TT %CY-%Cm-%Cd %CT %p\n' 2>/dev/null
# archive tmpfs content (it will not survive a reboot)
tar -cpzf /media/ir/host01-shm.tgz --xattrs /dev/shm /tmp
  • UAC collects file listings (bodyfile) across the filesystem and can copy suspicious files; its live-response process artifacts copy binaries of processes whose executable was deleted, which catches self-deleting droppers.
  • Velociraptor Linux.Search.FileFinder or Generic.Forensic.Timeline over these paths on many hosts.
  • Take memory (AVML or LiME) when /dev/shm or memfd execution is suspected.

Parsing

On a disk image, build a timeline of the directories with The Sleuth Kit (fls -r -m / <image> > body; mactime -b body) or Plaso, then filter for /tmp, /var/tmp and deleted entries. debugfs -R 'stat <path>' on ext4 shows the four timestamps and the deletion time of a deleted inode.

Investigator tips

  • Look for executables, ELF headers and scripts: find /tmp /var/tmp /dev/shm -type f -perm -u+x and file on each result.
  • Files owned by service accounts, especially the web server user, are strong indicators of initial access through an application.
  • A /tmp mounted noexec does not prevent bash /tmp/x.sh or python3 /tmp/x.py; check how the file was executed.
  • Correlate file birth times with cron jobs and journal entries: droppers are often re-fetched by a scheduled task after cleanup.
  • On live hosts, ls -l /proc/*/exe | grep -E 'memfd|deleted' catches fileless and self-deleted binaries that no directory listing will show.
  • Remember the sticky bit: users can create files in /tmp but cannot delete other users' files there, so an attacker deleting root-owned files needed root.

See also