Summary of "Linux Process Running with Hidden Binary Name Attack"

Main ideas / lessons

Hidden files/binaries on Linux (dot-prefix)
- On Linux, naming a file with a period (.) as the first character makes it “hidden” from normal directory listings.
- Typical behavior: using a standard directory listing command won’t show these dotfiles unless you use a special flag.
Why malware uses this tactic
- Malware (especially low-grade threats like cryptominers) may name dropped executables with a leading dot to make casual inspection harder.
- The same tactic can also be used by more advanced malware, so it’s not a guarantee that the threat is “only low grade.”
Hidden process execution is highly suspicious
- After the binary is dropped, attackers often run the process using the hidden dot-prefixed name.
- Seeing a running process whose command name/path looks like a hidden file is presented as a strong indicator that investigation is needed.
Sandfly used for detection context
- The video demonstrates findings using Sandfly, described as an agentless Linux endpoint detection and response product.
- Sandfly can monitor (per the subtitles): SSH keys, password auditing, drift detection, and more.
- Demonstration target: a Raspberry Pi (embedded device), noted as being frequently targeted and suitable for monitoring.

Methodology / step-by-step investigation (as shown)

A) What Sandfly reported (conceptual findings)

Investigate alerts and focus on suspicious items:
- Found a hidden executable file under /tmp:
  - /tmp/.X0-lock
- Verified that a process is running with the hidden name:
  - Process name/command: .X0-lock
  - Example PID mentioned: 14721
- The process appears suspicious due to:
  - Hidden name (dot-prefix)
  - Command-line flags (described as suspicious)
  - Network behavior: TCP listening on port 1337
- Sandfly provides “raw result” data including:
  - File/process metadata (timestamps, ownership, permissions)
  - Inode and flags (including potential special permissions like immutability)
  - Hashes (SHA1/SHA256) for malware lookup
  - Process environment info
  - File descriptors
  - Network port information

B) Command-line verification and manual investigation (performed in the demo)

List hidden files in /tmp
- Go to the directory:
  - cd /tmp
- Run:
  - ls -al
- Explanation:
  - Without -al, dot-prefixed files may not appear.
  - With ls -al, hidden files and attributes become visible.
- Observations from ls -al:
  - Visible hidden files include:
    - .X0-lock
    - .X0-1ock (notable subtle difference)
      - The subtitles note the difference is likely the character “1” instead of “L” to hide or confuse identification.
- Size difference noted:
  - .X0-lock is described as 11 bytes
  - .X0-1ock is described as 67K bytes
Identify the suspicious file type
- Use:
  - file <filename>
- Result described:
  - The larger variant is an ELF executable
  - Identified as ARM (appropriate for the Raspberry Pi)
Hash the file for lookup
- Use:
  - sha1sum <filename>
- Purpose:
  - Potentially compare hashes against malware databases (noted as not super reliable).
Inspect open files and network activity for the running PID
- Use:
  - lsof -p 14721
- Explanation:
  - Confirms:
    - Current working directory (expected /tmp)
    - Libraries loaded
    - Open resources
    - Listening network port (consistent with earlier findings)
Alternative deeper manual inspection via /proc
- Navigate to process info:
  - /proc/<PID> (example uses PID 14721)
- Use ls -al inside:
  - /proc/14721
- Check file descriptors via:
  - cd /proc/14721/fd
- Then list open socket/file descriptors as part of deeper analysis.
- For sockets, the subtitles suggest using:
  - netstat or the ip command.

Key conclusions emphasized

A hidden process/binary (dot-prefixed) in locations like /tmp is very suspicious and “up to no good” per the video’s framing.
The video claims that 99% of the time you should treat a hidden binary/process running on the system as malicious.
There is a small caveat:
- Occasionally, some legitimate programs may start with a dot-prefixed name, but it’s described as uncommon and generally a “dumb idea,” so investigators should still pay close attention.

Speakers / sources featured

Craig Rowland — Founder, Sandfly Security (speaker)
Sandfly Security — described source/product used for the detection demonstration (agentless Linux EDR/response; monitors SSH keys, password auditing, drift detection, etc.)
Raspberry Pi — target device used in the demonstration (no person speaker)