Bash Scripting for Automation

Bash (Bourne Again SHell) is both a command-line interpreter and a scripting language. A bash script is a plain text file containing a series of commands that the shell executes sequentially. Scripts automate tasks that would otherwise be performed manually, saving time and reducing errors. For penetration testers, scripts are essential for:

When a bash script is executed, the shell reads the file line by line. Each line is parsed into commands, arguments, and operators. The shell then forks a child process to execute each command, unless the command is a built-in (like echo or cd). Redirection operators (>, >>, <, |) modify file descriptors before execution. Environment variables and local variables are expanded using ${} or $. The exit status of each command is stored in $?, which can be checked by conditionals.

Shebang: The first line of a script is #!/bin/bash, which tells the system which interpreter to use. If missing, the script runs under the current shell, which may cause compatibility issues.

Variables: Declared as VAR=value (no spaces around =). Accessed as $VAR or ${VAR}. By default, variables are global within the script. Local variables can be declared with local inside functions.

Arrays: Indexed arrays use arr=(item1 item2); associative arrays (bash 4+) use declare -A arr. Access elements with ${arr[index]}.

Special Variables: - $0 – script name - $1, $2, ... – positional parameters - $# – number of arguments - $@ – all arguments as separate words - $* – all arguments as a single string - $? – exit status of last command (0 success, non-zero failure) - $$ – process ID of the current script

Exit Codes: By convention, exit code 0 means success, 1-255 indicates failure. The script can exit with a specific code using exit N.

if-elif-else:

if [ condition ]; then
    commands
elif [ condition ]; then
    commands
else
    commands
fi

Conditions use [ ] (test command) or [[ ]] (extended test with regex). Common tests: - -f file – file exists and is regular - -d dir – directory exists - -z string – string is empty - -n string – string is not empty - string1 = string2 – string equality - num1 -eq num2 – numeric equality

for loop:

for var in list; do
    commands
done

The list can be a space-separated list, a range {1..5}, or a command substitution $(command).

while loop:

while [ condition ]; do
    commands
done

until loop:

until [ condition ]; do
    commands
done

Functions group commands for reuse:

function_name() {
    commands
    [return N]
}

Arguments are passed as positional parameters inside the function. Use local to avoid variable pollution.

Capture output of a command into a variable:

current_date=$(date)
# or backticks: `date`

Integer arithmetic uses $(( expression )):

a=$(( 5 + 3 * 2 ))

Use set -e to exit on error, set -u to treat unset variables as errors, set -o pipefail to catch errors in pipes. Trap signals with trap 'commands' SIGNAL.

Mass scanning:

#!/bin/bash
for ip in $(cat targets.txt); do
    nmap -sV $ip >> scan_results.txt
done

Parsing Nmap output:

#!/bin/bash
# Extract open ports from Nmap grepable output
grep -oP '\d+/open' $1 | cut -d'/' -f1

Automated exploitation:

#!/bin/bash
# Run multiple exploits against a target
for exploit in /usr/share/exploitdb/exploits/*.py; do
    python3 $exploit -t $1
    if [ $? -eq 0 ]; then
        echo "Exploit $exploit succeeded"
        break
    fi
done

Data extraction and reporting:

#!/bin/bash
# Extract IP:port from probe results
cat probe.txt | awk '{print $1":"$2}' > live_hosts.txt

Bash scripts often call other tools (nmap, curl, netcat, etc.) and parse their output. They can also interact with databases via CLI clients, send emails, and generate reports. On the PT0-002 exam, you may be asked to interpret or complete a script that uses common pentesting tools. Understanding how to chain commands and handle output is crucial.

In enterprise penetration testing, bash scripting is indispensable for automating reconnaissance and post-exploitation tasks. For example, during a large-scale external assessment, a tester may need to scan hundreds of IP addresses across multiple subnets. Writing a manual Nmap command for each host is impractical. Instead, a bash script can read a list of targets from a file, run Nmap with specific options (e.g., -sV -p1-1000), and output results to individual files or a consolidated report. The script can also parse Nmap's grepable output to extract open ports and services, then feed those into further tools like Nikto or SQLmap. This automation reduces the time from hours to minutes.

Another scenario is during internal network testing where a tester needs to enumerate SMB shares, check for null sessions, and test default credentials. A bash script can loop through a list of IPs, run smbclient -L //ip -N, check the exit code, and log successful enumerations. If a share is accessible, the script can attempt to mount it and download files. This automation ensures consistent testing across many hosts and reduces the chance of missing a critical finding.

A common mistake in production scripts is failing to handle errors. For instance, if a script uses nmap -oG - $target and the target is unreachable, the output may be empty, causing downstream commands to fail. Without error checking, the script may continue with corrupted data. Similarly, not quoting variables can lead to word splitting issues when filenames or IPs contain spaces. Performance considerations include running too many parallel processes (e.g., backgrounding multiple Nmap scans) which can overload the network or the testing machine. Using xargs -P or GNU parallel can control concurrency. Finally, scripts should be idempotent where possible, so re-running them doesn't cause unintended side effects.