Bounty Haunted

I may have disappeared again, but at least I have a very good reason (and it’s not cancer this time!!). These last few weeks I’ve been ultra-focused on finishing the Bug Bounty Hunter path in HackTheBox, so that I can take the certification exam ASAP. I needed it ASAP because I need to start looking for a job, and I need THAT because, besides the general issue of being unemployed for a year and a half, I currently reside in the USA, and need to find employment in a completely foreign job market, and this is rather terrifying. I figured, what better to bump up my chances than a shiny certification in my CV. So I studied while packing, selling our home contents, fighting jet lag and strep, experiencing culture shock and homesickness. A bit over a week ago I wrapped the last module, and thought it was no use postponing the certification exam. So I went all in and clicked the big green “Start Exam” button.

This isn’t a writeup, so I’m not going to elaborate on how the exam went and what it included. From what I read online, it’s a fairly standard PT certification exam, even if slightly on the harder side. Instead, I want to do a proper post-mortem on this attempt, in preparation for the next one and for any other future engagements. This is a good opportunity to learn from my mistakes, improve my thought process and work process, and also brush up on my retrospective techniques, which will probably be useful in a corporate setting.

The Knowledge Gap

First and foremost, I’ll admit, I was woefully unprepared. While the course modules provide a decent hands-on experience with most exploitation methods, they are, for the most part, quite basic. Most importantly, however, the module assessments, by virtue of them being related in a module, always disclose WHAT you need to look for, even if the HOW part is a bit more elaborate. There’s a very big jump from that to blindly approaching a webapp. The first day I was pretty overwhelmed, and even after grabbing a few flags I would often get stuck, not knowing what to do next, or why some thing I tried didn’t work the way I expected it to.

The remediation for this issue is simple - practice practice practice. PortSwigger has nice “mystery” labs, there are CTFs and challenges and tons of resources. I realize now that I used to avoid these things because I always felt inadequate over how fast I’d look for a writeup. Well, now I feel a lot more confident in my knowledge and abilities, and even if I do require a hint or 10 for a particular challenge, I will be able to fit it into the appropriate context, instead of memorizing another “spell”. Which brings me to my next conclusion…

Spellbooks Aren’t Enough

When I was employed reversing Android apps, I had this idea that we’re all wizards with spellbooks. Mine was a list of useful commands and their flags - how to run a recursive word search in a directory, or see all running apps on a connected device. Often I didn’t know what each flag did or why it was there, I just knew that I needed to “cast” this “spell” to get a particular effect. After a while I learned other devs had similar things - python scratch files for shortcuts to our tooling system, personal branches with hundreds of commits, many things people wrote for themselves but quite a few that were “inherited” from wizards of old.

My logseq knowledge base, as described in my previous post, was pretty much that - a collection of payloads, webshells, tool execution examples and other such spells that I would copy and paste as needed. Setting aside the inefficiency of hopping between windows and pages, which will be addressed in another section, this approach is simply lacking. Referring to my notes because I know I tend to mix up characters and want to get it right is fine, but in many cases, not knowing how a payload works means I can’t alter it, make it fit my purpose better, debug it when it doesn’t behave as expected. A wizard with little understanding of how magic works is not much of a wizard, even if they have a spellbook.

This is another case of practice makes perfect, and I can beef it up by paying more attention to the spells I do have, taking them apart, understanding which part does what and why. It’s also a good idea to learn more php and JavaScript, so I might add that to my TODO list.

Repetition Legitimizes…?

Riding on the wave of my initial enthusiasm, I ran a whole bunch of diagnostics, fuzzers and automated tools on various targets. Then, 3 days later, half my time was spent asking “wait, have I tried this already?” followed by, obviously, trying it again, because what if I didn’t? I’m sure at least 30% of my efforts were repetitions of things I already tried. Somewhere near day 4 of the exam, when I was already burnt out and couldn’t look a browser in the eye, I took the time to sort out my notes. There, I found many leads and loose ends, descriptions of attacks, and other information that would have been useful had it been more accessible.

The root cause of this issue is, I think, twofold: my approach to the target was unsystematic, and my notes were disorganized.

The first issue has, of course, been addressed by the security community, with multiple guides and methodologies available online for anyone willing to look for them (which I, of course, didn’t). The OWASP Web Security Testing Guide is fairly comprehensive, with checklists and flowcharts and all that good stuff. There is also the PTES wiki. My preparation for future engagements will include going over these resources, and making sure I’m not flailing around.

The issue of organization is more of a personal thing - I’m sure every pentester and bug bounty hunter has out there has their own approach to documentation, from elaborate systems to just remembering everything. Being mnemonically challenged, I require a system (and this is a complete necessity, and not just me being a systematization freak, no sir, no way). I have haphazardly devised the beginning of such a system during lulls in the exam, but it definitely needs more work. And more work it shall get, and be sure to see a follow-up post all about it. For now I can amouse your bouche by saying it includes logseq templates and properties, and lots of querying. Yum!

Shortcuts to Mushrooms

This whole week, my Mac was carrying a heavy load. One desktop with logseq, split between my documentation and my course notes; another desktop with an ever-growing number of Chrome tabs containing various references and StackExchange threads; my main working desktop, with way too many windows to fit on a laptop screen - a browser with my targets, burp suite, a terminal with several Kali tabs, VSCode open on SecLists, the occasional finder window. It was a mess, it was confusing, and I did it all with a trackpad, because I’m just not very leet. In the amount of time lost in hopping between desktops and looking for that window that has the thing I need, I probably could have finished the bunny stuffie I’m knitting for my daughter.

Luckily for me, I happen to share my life with the king of tooling and leetness. Just by coexisting in the same space with him while he is working, I already have some ideas I’d like to implement. One thing I often found myself referencing, either from my notes or from Google, was various scripts and bash “spells” to transform some sort of data (like checking a list of passwords against a known hash, or manipulating wordlists to fit a purpose). Another thing I wasted time on was manual tasks, like starting a VPN+tunnel setup to access the targets from both my Kali docker and my local browser (which required running commands from 2 different terminal tabs). Well, my husband has this thing where anytime he does a task more than once, he automates it into a custom bash command. I tried this on an actual task I was about to do manually - combine password files generated by CUPP for several personas - using Claude as my scripting expert, and now I am a believer.

#!/bin/bash

if [ $# -lt 2 ]; then
    echo "Error: Not enough arguments"
    echo "Usage: $0 output_file.txt input_file1.txt input_file2.txt ..."
    echo "   Or: $0 output_file.txt *.txt"
    exit 1
fi

OUTPUT_FILE="$1"

if [ -f "$OUTPUT_FILE" ]; then
    read -p "Output file '$OUTPUT_FILE' already exists. Overwrite? (y/n): " CONFIRM
    if [[ ! $CONFIRM =~ ^[Yy]$ ]]; then
        echo "Operation cancelled."
        exit 0
    fi
fi

> "$OUTPUT_FILE"

COUNT=0

for FILE in "$@"; do
    if [ ! -f "$FILE" ]; then
        echo "Warning: File '$FILE' does not exist or is not a regular file. Skipping."
        continue
    fi
    
    if [ ! -r "$FILE" ]; then
        echo "Warning: Cannot read file '$FILE'. Skipping."
        continue
    fi
    
    echo "=== Content from: $FILE ===" >> "$OUTPUT_FILE"
    cat "$FILE" >> "$OUTPUT_FILE"   
    echo "" >> "$OUTPUT_FILE"
    
    ((COUNT++))
    
    echo "Added: $FILE"
done

echo "Concatenation complete. $COUNT files merged into '$OUTPUT_FILE'."

I wrote down some ideas of tasks I’d like to automate, and I’m sure more will come up as I continue my journey. I used to be quite the purist, refusing to use AI for fear of over-reliance, but I think this is an exception I’m willing to make.

Another point, of course, is just my plain lack of leetness. I’m not good with keyboard shortcuts, in fact, I can barely even touch-type. My reliance on the trackpad has never bothered me as much as it did this past week, both due to the time it wasted and the pain it caused to my poor wrist. This one is another thing to add to my daily practice.

Don’t Lose Sight

Back when I could effortlessly hold IPs and commands and shortcuts in my head, I’d probably get very discouraged over failing a test. The past few years, while robbing me of some faculties, have taught me a very important lesson: failing is just another step along the way. I enjoy pentesting and bug busting, I enjoy learning new things, not much has changed other than me gaining some more experience.

Peace and Love