My thoughts after my first (real) attempt at Hackthebox

#1

After my previous post I’ve been thinking about the next step,
should I start a series where I implement all OWASP TOP10
vulnerabilities and then break them?

It could’ve happened, but I decided to try myself at hackthebox.
I had an account for almost 2 years, and all I had was 2 user owns in the last two months
(which were so basic), and a couple of challenges done. A good first box seemed to be
SwagShop, simply because I like earning stickers, and I thought this one would be cool
(don’t worry, no spoilers here).

Long story short, after rooting SwagShop I just kept going and rooted another 3-4 boxes, in the span of 3 days.
It was a wild ride, tons of new things to learn, same amount of frustration, but when
I got the flag, it was all worth it - in fact it felt so good, I immediately forgot about
the hours of staring at the screen murmuring

it can’t be that, it just doesn’t work

I’ve went from noob rank to hacker during this time, so I thought it’d be good to capture
what I thought during these few days, what I liked, what were the challenges that I faced, and so on.

The Bad

Enumerating non-web related services (like smb shares, rdp)

I come from a software development background, and more specifically, I’ve been writing software for the web.
This makes it easy for me to have a solid guess of the service if I see ports like 80, 8080, 3000, 3306, 5432 etc - but when nmap returned something like 445 - I had no idea what it was.
In fact this was the first time I’ve explored SMB following this handy guide by @pry0cc .
To ease my own pain, I’ve bookmarked a Wikipedia article that I can use as a reference.

Looking at code requires a totally different mindset

At work we do a lot of pair programming (the bane of my existence) and whatever’s left is reviewed.
If you’ve ever worked as a developer in a team, you know that there are many things to check,
code styling, design patterns, architecture, etc - but this is different, and I had to make that switch.
One of the boxes had some source code online that contained key information of rooting the box. After spending
a good chunk of time on it, I already came up with many points, but none of them were relevant!
The important bit is to read the code and think about what the dev(s) could’ve missed,
if they forgot to catch an exception, or clean up some temporary data 🤷🏻.

This was one of the hardest changes I had to make so far, but one of the most enjoyable ones.

Off by one errors

I mean, we’ve all been there right?
Can you spot what’s wrong with some_command /root/rot.txt? I couldn’t - it was embarrassing.
I cooked up a real cool python script, but did I mess up the operator and used + instead of -? Yes, I totally did.

I’m still thinking about this - but probably for my own scripts, I’ll to stick to TDD - it’s one of the things
that worked really well for me in the past, and I think it’d help me to write more reliable scripts.

The Good

Reimplementing a CVE

What I’ve found to be an absolutely good way to spend my time is to look at an exploit, and then keep rewriting it,
so that a proper script is the end result. The one you can show in your GitHub profile, the one where if you need to make some changes or reuse it on another
service, it’d be a pleasure to do so. It’s also great for learning more in depth about the vulnerability you’re exploiting.

Automate as much as possible

When I first tried SwagShop there were constant resets, and brute forcing attempts, making it hard to even enumerate, let alone proceed.

It👏 was👏 utterly👏 frustrating👏.

Once the box was a bit more stable, I decided to design myself a workflow,
so that I could get back to the part where I was without much effort.
This worked wonders for me in other boxes as well - every time I was in the middle of something and the machine got reset,
I could get back in within a minute and continue where I left off.

For certain boxes this can be as simple as recording the passwords you’ve already obtained, but if you need to do something
in order to get access, I encourage you to automate that bit.

The Ugly

Writing code

I’ve tried - I really did - to write all my scripts in nano/vim/emacs whatever. I just couldn’t bring myself to it.
I’ve been spoiled by great IDEs that’ll tell me how wrong I am, and offer rich refactoring functionality just to mention a few.
I felt like I spent more time doing tasks that are just a shortcut away in my daily work, so I went back to using the IDE for writing scripts.

Applying dev principles

One of the most useful principle I’ve used is to go as slow as possible. I could’ve shaved a few hours off from certain boxes, all I had to
do is just to download a file, run it, :dash: shell… but I didn’t.

If you go slower, you’ll find more things when enumerating, you’ll better understand the problems at hand, and you’ll have a better chance
of remembering the things you’ve done, as opposed to just doing a quick hit and run. I think if you’re not having fun during these boxes, it might
not be worth doing them anyway.

Closing notes

I really enjoyed learning so many new things and techniques,
and I’m definitely looking forward to get better at boxes.

I’d like to thank all the people I’ve talked to
in the last few weeks, they were all amazing and supportive people!

12 Likes

#2

Thanks for your post. I am in a similar boat to yourself, DevSecOps currently from a heavy dev background.
I also had a slow start to HTB, one or 2 boxes then a large gap and now getting back in with a VIP sub, my experiences have been very similar to what you describe here. and I totally agree with the sentiment of going slowly, I have made more progress going slowly through each tool and its output than I ever did running a few in parallel and glancing over their outputs.

2 Likes

#3

Thanks for the feedback, how was the transition to DevSecOps?

1 Like

#4

It was relatively painless, just the realisation that I had been doing the fundamentals in part for many years. Through Software Dev, CI/CD, automated deployments etc.

the transition was largely putting together that knowledge into a marketable skill.

2 Likes

#5

Good stuff! Also enjoyed your previous post on XSS. I’m also on a similar path, digging into infosec after roughly 7 years of web development (Rails, EmberJS, a bit of React). I approached the matter with CTFs and then trying some bounties on HackerOne; I posted my findings up to this point here.

Keep up the good work!

2 Likes

#6

I honestly still haven’t cracked any box yet. I find it extremely frustrating, but right now I just keep trying, give a box an hour or three and if I can’t figure it out then I make a mental note to look up the solution later and learn from it. I hope if I keep that up for a few months that I might be able to crack my very first box soon :smiley:

I usually make really stupid mistakes, like one box I had the username and password and pretty much pwn’d it but I just didn’t realise they were the username and password, so I kept looking and couldn’t find anything. After reading up a walkthrough I felt so stupid.

2 Likes

#7

I totally feel that! I’ll not say “try harder”, but what helped me is that I dedicated a whole day to the first box, and refused to give up until I got user. I’m sure you’re very close to cracking a box, keep it up!

3 Likes

#8

Thanks for the kind words - I must say, I really dig your blog, and the article is great too :wink:

3 Likes

#9

What do you think about trying HTB as a team and blogging about our experience?

2 Likes

#10

Yeah, I’d dig that - I’ll pm you

1 Like

#11

I like your comment on reading the code in a manner differently than you would as a developer. It’s easy to feel like I can’t see the forest through trees at times, typically when writing something I have an idea in mind of what I want to be present, but looking through code for HtB I often find myself looking for what I hope isn’t present.

3 Likes