Case file

Linux shell operations and Bash automation

Operator baseline on a Linux host: shell inventory, filesystem navigation, and Bash automation used to gate access and search logs under elevated privileges.

Foundations22 minLinux · CLI · Bash · Scripting
  • Establish CLI control on a Linux workstation before any service exploitation. The shell is the primary interface once GUI access is unavailable.

  • Confirm working directory, change context, list contents, read files, and extract patterns with grep before touching services.

  • Identify the active login shell, enumerate /etc/shells, and switch into zsh for the session. Compare Bash, Fish, and Zsh capabilities for operator tooling.

  • Create a Bash script with a shebang, capture user input into a variable, set the executable bit, and invoke it from the current directory.

  • Demonstrate iteration with a for-loop and authorization gating with an if/else branch, including comments for maintainability.

  • Collect username, company, and PIN in a three-iteration loop; authorize only when all three values match the expected triple.

  • Escalate to root, configure a keyword search against /var/log, and locate the matching hit in authentication.log.

01

Engagement context

Establish CLI control on a Linux workstation before any service exploitation. The shell is the primary interface once GUI access is unavailable.

This case documents foundational operator work on a Linux lab host. We validated shell identity, navigated the filesystem, compared available login shells, and delivered Bash scripts for interactive input, iteration, conditional authorization, and keyword search across system logs. The same primitives appear in every later Linux engagement when we land a reverse shell or SSH session.

Security impact

Operators who cannot move confidently in a shell cannot triage hosts, collect evidence, or automate repeatable checks. This baseline is a prerequisite for every Linux assessment we run.

02

Filesystem orientation

Confirm working directory, change context, list contents, read files, and extract patterns with grep before touching services.

Sessions open in the user home directory. We printed the working directory, changed into Desktop, listed entries, and read a sample file. Pattern search with grep is the same technique we later apply to dictionaries, configs, and log corpora.

Orient and inspect the working tree

OPERATOR · NAVIGATION

savvy@lab:~$ pwd

/home/user

savvy@lab:~$ cd Desktop

savvy@lab:~/Desktop$ ls

Desktop Documents Downloads Music Pictures Public Templates Videos

savvy@lab:~$ cat filename.txt

this is a sample file

this is the second line of the file

Extract matching lines from a corpus

OPERATOR · GREP

savvy@lab:~$ grep FLAG dictionary.txt

The flag is FLAG

Operator defaults

Default login shell on most distributions: Bash. Directory listing: ls. In-file search: grep.

03

Shell inventory and session switch

Identify the active login shell, enumerate /etc/shells, and switch into zsh for the session. Compare Bash, Fish, and Zsh capabilities for operator tooling.

We recorded $SHELL, listed valid login shells, and entered zsh. Bash remains the default on most distributions and is our scripting target. Fish provides syntax highlighting and spell correction out of the box. Zsh combines advanced completion with heavy customization. Permanent default changes use chsh -s.

Active shell and available interpreters

OPERATOR · SHELL INVENTORY

savvy@lab:~$ echo $SHELL

/bin/bash

savvy@lab:~$ cat /etc/shells

# /etc/shells: valid login shells

/bin/sh

/bin/bash

/usr/bin/bash

/bin/rbash

/usr/bin/rbash

/bin/dash

/usr/bin/dash

/usr/bin/tmux

/usr/bin/screen

/bin/zsh

/usr/bin/zsh

savvy@lab:~$ zsh

lab%

Capability notes

Out-of-the-box syntax highlighting: fish. No auto spell correction: bash. Command history replay: history or arrow keys.

04

Script bootstrap: shebang, variables, execute

Create a Bash script with a shebang, capture user input into a variable, set the executable bit, and invoke it from the current directory.

Automation starts as a file of commands. We authored first_script.sh with #!/bin/bash, prompted for a name, and echoed a welcome line. Execution requires chmod +x and an explicit ./ path so the shell does not search PATH for a local file.

Create the script file

OPERATOR · EDITOR

savvy@lab:~$ nano first_script.sh

SCRIPT

first_script.sh

#!/bin/bash
echo "Hey, what's your name?"
read name
echo "Welcome, $name"
Permission then local execution

OPERATOR · EXECUTE

savvy@lab:~$ chmod +x first_script.sh

savvy@lab:~$ ./first_script.sh

Hey, what's your name?

John

Welcome, John

05

Control flow: loops and conditionals

Demonstrate iteration with a for-loop and authorization gating with an if/else branch, including comments for maintainability.

Loops encode repetitive operator tasks. Conditionals encode policy. We validated both patterns before composing them into a multi-field authentication script.

SCRIPT

loop_script.sh

#!/bin/bash
for i in {1..10};
do
  echo $i
done
Partial output — full run emits 1 through 10

OPERATOR · LOOP

savvy@lab:~$ ./loop_script.sh

1

2

3

# … through 10

SCRIPT

conditional_script.sh

#!/bin/bash

# Gate disclosure on an authorized identity.
echo "Please enter your name first:"
read name

if [ "$name" = "Stewart" ]; then
  echo "Welcome Stewart! Here is the secret: LAB_Script"
else
  echo "Sorry! You are not authorized to access the secret."
fi
Authorized identity vs denied identity

OPERATOR · CONDITIONAL

savvy@lab:~$ ./conditional_script.sh

Please enter your name first:

Stewart

Welcome Stewart! Here is the secret: LAB_Script

# —

savvy@lab:~$ ./conditional_script.sh

Please enter your name first:

Alex

Sorry! You are not authorized to access the secret.

06

Multi-factor locker authorization script

Collect username, company, and PIN in a three-iteration loop; authorize only when all three values match the expected triple.

We implemented a locker gate that prompts for three fields and evaluates them with a compound condition. Failed PIN attempts are denied without disclosing which field failed — appropriate for an access-control demo, insufficient for production auth (no rate limiting, no hashing).

SCRIPT

locker_script.sh

#!/bin/bash

username=""
companyname=""
pin=""

for i in {1..3}; do
  if [ "$i" -eq 1 ]; then
    echo "Enter your Username:"
    read username
  elif [ "$i" -eq 2 ]; then
    echo "Enter your Company name:"
    read companyname
  else
    echo "Enter your PIN:"
    read pin
  fi
done

if [ "$username" = "John" ] && [ "$companyname" = "Savvy" ] && [ "$pin" = "7385" ]; then
  echo "Authentication Successful. You can now access your locker, John."
else
  echo "Authentication Denied!!"
fi
Denied attempt with incorrect PIN

OPERATOR · LOCKER

savvy@lab:~$ ./locker_script.sh

Enter your Username:

John

Enter your Company name:

Savvy

Enter your PIN:

1349

Authentication Denied!!

Authorized triple (lab only)

Username John · Company Savvy · PIN 7385. Treat as lab credentials — not a production pattern.

07

Elevated log search

Escalate to root, configure a keyword search against /var/log, and locate the matching hit in authentication.log.

A search script in /home/user required the keyword and target directory before scanning *.log files. Full visibility under /var/log required root. We escalated with sudo su, filled the empty parameters, and confirmed the match in authentication.log.

Obtain root for log corpus access

OPERATOR · ESCALATION

savvy@lab:~$ sudo su

[sudo] password for user:

root@lab:~#

Search parameters

Keyword: lab-flag01-script · Directory: /var/log · Hit file: authentication.log

Remediation note

Limit sudo to least privilege, restrict world-readable logs that contain secrets, and prefer structured log pipelines with access controls over ad-hoc root greps in production.