Posts Workflow Improvement With Simple Bash Scripts
Post
Cancel

Workflow Improvement With Simple Bash Scripts

Introduction

As a pentester and a CTF player, we enjoy what we do, but at the same time, we try to avoid some hassles and repetitive tasks involved as much as possible. Although some of them are not avoidable (e.g. writing reports 😂), we can make our lives easier by doing things in some more elegant ways. In this article, I will share some small bash tricks that I use to make it a bit more elegant and to increase my productivity.

Organise Workspaces

1
2
3
4
5
6
7
8
workspace() {
    ws="$HOME/$1"
    if [ ! -d "$ws" ]; then
        mkdir "$ws"
    fi
    cd "$ws"
    tmux
}

I use the above bash function to create workspace directories before starting the actual work. It first checks if the directory with the specified name already exists, creates it if it does not, and cd to it. Then it starts a tmux session within that directory. The good thing in this is that every shell spawned in the tmux session will have an initial working directory being that directory. In this way, you can have your in-scope files well organised in the project workspace.

Tmux

Speaking of tmux, it is the terminal multiplexer that I use quite heavily. I won’t write about it becasue you can learn enough to begin using it from this video by IppSec:

Log Terminal Sessions

Sometimes you may find some key information missing in your notes when you try to turn them into a report after a pentest. This situation could be a disaster since you may need to do the exploit again. But it’s common because everyone may forget to write things down when they focus on their exploit during the engagement. Here comes why it’s important to log your terminal sessions. Recently I’m getting used to run script command to do that before I start exploitations. And I would recommend that you begin using it if you haven’t.

Custom Nmap Commands

nmap is a command that we run at the recon phase of almost every engagement. So you definitely don’t want to type the entire command with complicated arguments every time. So I have the following functions defined to facilitate myself a bit.

nmap-default

1
2
3
4
5
6
nmap-default() {
    if [ ! -d recon ]; then
        mkdir recon
    fi
    sudo nmap -sC -sV -oA recon/default "$1"
}

nmap-default is a command I will run whenever I need to run a normal nmap tcp scan. It will enumerate service versions (-sV), run default NSE scripts (-sC), and output all formats (-oA). It runs with sudo to be able to use raw packets, assuring that its default behaviour is a syn scan (-sS) rather than a connect scan (-sT).

Before running the scan, it will first check if a directory named recon already exists in the current working directory. It creates the directory if it does not exist, and this directory will be where all the output files located. This is just another small trick to keep things organised.

nmap-full

1
2
3
4
5
6
7
8
9
10
11
12
13
nmap-full() {
    ports=$(sudo nmap -p- -T4 --min-rate=1000 "$1" | grep ^[0-9] | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
    if [ -z "$ports" ]
    then
        echo "No ports open!"
    else
        echo "Open ports: $ports"
        if [ ! -d recon ]; then
            mkdir recon
        fi
        sudo nmap -sC -sV -oA recon/full -p "$ports" "$1"
    fi
}

nmap-full is a two-phase full port (1-65535) tcp scan. Although it’s not used as often, it is still defined as a function in my shell resource files since it becomes handy when a full port scan is needed. In the first phase it will run a simpler full port scan, trading-off some accuracy for speed (--min-rate=1000 and -T4). Some people may prefer masscan in this phase. But I just find nmap itself can do the job with roughly the same level of speed and higher accuracy and stability. The purpose of the first phase is only to produce a list of open ports. In the second phase, another “heavier” nmap scan with similar options to nmap-default is performed only to this list of open ports. In this way, the scan can achieve both good performance and thoroughness.

Conclusion

These are some of the small tricks how I save myself from hassles and keep things organised. It’s really nothing fancy there. But the “hacky” way is sometimes just as simple. If you have some real [email protected] wanting to share with me, please find me at Github!

This post is licensed under CC BY 4.0 by the author.