🎯 Goal

Move beyond simply using Linux commands and understand:

  • how Bash resolves and executes commands
  • why commands are not always binaries
  • how filesystem metadata can be queried
  • how find can be used for investigation
  • security implications of command resolution and file timestamps

🧪 What I Did

Studied Effective Shell – Understanding Commands

Learned that when typing a command in Bash, the shell does not immediately execute a program.

Instead, Bash resolves commands using this priority chain:

Alias → Function → Builtin → Executable ($PATH)

Verified command origins using:

type ls
command -V ls

Key realization:

A command name is an abstraction — the shell determines what actually runs.

Understood the Four Types of Commands

Executables (External Programs)

Programs stored on disk such as:

/bin/ls
/usr/bin/grep
/usr/bin/cat

Execution flow:

Shell → PATH lookup → spawn process → execute binary

External programs cannot modify the shell environment, which is why commands like cd must be builtins.

Builtins

Commands implemented directly inside Bash:

cd
echo
export
exit
history

Characteristics:

  • no subprocess creation
  • faster execution
  • able to modify shell state

Functions

User-defined shell commands:

hello() {
  echo "hi"
}

Functions can override system commands if defined with the same name.

Aliases

Simple command substitution:

alias ll="ls -alF"

Aliases are useful interactively but unreliable in scripts.

Command Hijacking Concept

Because of the command resolution order, commands may not run what users expect.

Example concepts:

alias sudo='echo logging...; sudo'

or

ssh() {
  echo "captured usage"
  /usr/bin/ssh "$@"
}

First debugging rule learned:

type <command>

Always confirm what actually executes.

Studied Effective Shell – Finding Files

My mental model shifted from:

manual directory navigation

to:

filesystem metadata queries

Core syntax:

find [path] [expression]

find recursively walks directories and evaluates conditions left-to-right.

Practical Exercise with find

Executed:

find ~/.ssh -ctime -30

Returned SSH-related files whose metadata changed within the last 30 days.

File Timestamp Investigation

Checked timestamps using:

stat ~/.ssh/authorized_keys

Key Linux timestamps:

Attribute Meaning Changes When
mtime modify time file contents change
ctime change time metadata changes
atime access time file is read

Important correction:

ctime is not creation time.
Linux normally does not store true file creation timestamps.

What Updates ctime

Examples:

  • permission changes (chmod)
  • ownership changes (chown)
  • renaming a file
  • modifying contents
  • changing link counts

This makes ctime useful during investigations.

🔐 Key Cybersecurity Connections

Detecting SSH Persistence

Attackers often maintain access by adding SSH keys:

echo attacker_key >> ~/.ssh/authorized_keys

Possible detection method:

find /home -name authorized_keys -ctime -1

Recent metadata changes can indicate unauthorized modifications.

Filesystem Hunting

Examples of investigative queries:

Find recently modified configuration files:

find /etc -ctime -2

Locate unusually large files:

find / -type f -size +100M

Identify world-writable files:

find / -perm -002

These techniques map directly to incident response workflows.

Command Resolution as an Attack Surface

Because Bash checks aliases and functions before executables:

  • commands can be overridden
  • PATH manipulation can redirect execution
  • persistence can hide in shell configuration files

Understanding command origin is critical during security analysis.

⚠️ Challenges

  • initially assumed commands mapped directly to binaries
  • confused ctime with creation time
  • adjusting to metadata-based filesystem thinking
  • understanding command resolution order

These issues were resolved through experimentation.

🧠 What I Learned

  • the shell is an execution engine, not just a launcher
  • commands are dynamically resolved
  • find acts like a filesystem query language
  • metadata timelines are valuable during investigations
  • hidden files are naming conventions, not security

⏭️ Next Steps

  • practice combining multiple find conditions
  • learn safe usage of:
-exec {} \;
  • explore command bypass techniques:
command <cmd>
\cmd
  • continue strengthening execution-flow mental models

💭 Reflection

Today marked a shift from mechanically using Linux commands to understanding how command execution actually works.

Commands are no longer perceived as fixed binaries but as dynamically resolved execution paths.

The filesystem increasingly feels like structured data that can be queried and investigated — an important mindset for cybersecurity work.

🧩 Lessons Learned

What worked

  • hands-on experimentation with find, stat, and type
  • breaking execution into internal mechanisms

What broke

  • assuming commands always mapped directly to binaries
  • misunderstanding file timestamps

Why it broke

  • relying on interface-level understanding rather than system behavior

Fix / takeaway

  • always verify command origin
  • treat the filesystem as queryable metadata rather than just folders and filenames