Thought Process Behind Creating the Box Delivery

Delivery was the second box I created for Hack The Box, and it was also the first box of 2021. A little-known factoid about this box is that it coincided with me joining Hack The Box as an employee. I wanted to start off my employment and the year with an easy machine as I’ve always thought of them being the most difficult to make. It may sound odd because easy boxes are relatively short compared to any of the other difficulties. However, it is really challenging to come up with something that both beginners and professionals can learn from. 

I had remembered reading an article back in 2017 about taking advantage of help desks in order to get a company email address, which can be used to trick computers into thinking you are an employee. I loved this idea because it was attacking a workflow, not a complex application. Chances are if an experienced person didn’t read that article they aren’t knowledgeable about this type of attack, which means both gurus and beginners will likely have the same experience.

Admittedly, this attack has become mostly mitigated because cloud services utilise better authentication processes. Five years ago, it wasn’t uncommon for these types of services to have all their users create accounts on their platform using company email addresses, then send a validation email to that email in order to verify they work at the company. Now most companies will utilise OAUTH/SAML workflows (those “Log in with [Google/Facebook/etc]” buttons), which set up a relationship between the identification provider and service. This is a win-win for everyone involved:

• Users don’t have another password to remember
• The users organisation has increased visibility on login attempts
• Cloud services have less sensitive information in their databases, which means less liability if they were compromised

Oddly enough, some services will still charge extra for this type of authentication and companies opt for the cheaper way which may leave them vulnerable to this attack!

Pretext

One of the biggest changes in Red Teaming/Hacking over the last decade is how much companies depend on the cloud or “Software as a Service'' applications. Before “the cloud”, most company services such as email, internal documentation, helpdesk, etc ran on-premise, to be accessed from the company’s building or through a VPN. The overhead of running all these services meant that in most cases patching was neglected and penetration testers found ways to gain access and then exploit the service through a known exploit. This is probably how most people think a red teamers day goes, when instead a lot more time is spent on enumerating 3rd party services and finding out what can be done with a single user credential.

With the switch to cloud, Software as a Service became more common and companies no longer had to maintain infrastructure. This limits the ability to just throw an exploit as the likelihood of it being unpatched is nearly non-existent. However, since it is no longer on company infrastructure, these services can be accessed by anyone on the internet meaning a single bad credential can lead to the wrong people gaining access to these services. It is shocking how often data on these third parties leads to a complete compromise of the domain.

The Foothold

This is what I intended to showcase with Delivery. The foothold to this box wasn’t a bad credential but instead two cloud services that when combined created an exploitable workflow. I learned about this misconfiguration years ago with the “How I Hacked Hundreds of Companies Through Their Helpdesk” post. A lot of SaaS applications allow authentication based upon having an @Company.com email, which makes sense since there aren’t a lot of situations where users can get email addresses. However, it’s not uncommon for a company help desk system to allow users to update tickets over email, and this can lead to non-employees getting read access to emails sent to an address on the company domain. Which is how I had configured this box, the main difficulty was that we can’t use any cloud resources, so instead of Slack I had installed Mattermost which is an on-premise alternative.

By creating a ticket on the helpdesk, you could now read emails from <ticket_id>@delivery.htb, which enabled the ability to create a Mattermost account and read chat rooms that were limited to employee’s only. For this box, one of these chatrooms has SSH Credentials to the Delivery and from here it becomes a cracking challenge to get root.

 

Real-Life Cracking

The next step of this box is a simple Cracking Challenge where you are supposed to create a wordlist based upon previously cracked passwords and that is the password for root. Generally speaking, whenever I perform a password audit my overall process looks like:

1. Start by gathering passwords from every configuration file I can find. Password reuse within an organization is a huge issue and always makes for a great find.You’d be surprised how often a configuration file on an internet accessible webserver contains a password that leads to Domain Administrator access.
2. Pair up this wordlist with some Hashcat Rule files like InsidePro-PasswordsPro.rule. These rule files manipulate each entry in RockYou by adding a digit/symbol to the end, converting it to 13375p34k, etc. 
3. Download a large wordlist to do a generic crack, I used to use hashes.org but that site appears to be offline. It looks like hashmob is a good successor. Again use the rule lists to achieve best results.
4. Take your cracking results from hashcat.potfile, and repeat the process using all of your successfully cracked passwords. You would be surprised at how many more passwords you can crack this way. 

Bonus Tip: If you are doing an audit against Active Directory, choose the options that extract password history. Active Directory has a default password history of 24, which means it will remember the last 24 passwords of a user in order to make sure they don’t set it again. By extracting the password history, you may get lucky and crack an older less secure password of a user that enables you to crack their recent secure passwords. If you want to learn how to do this, I'd highly recommend going to ippsec.rocks and searching for password history.

Typically for HackTheBox Machines, we limit cracking to things that will break quickly in rockyou.txt unless there is a very clear hint to attempt to crack it differently. Without this, players could spend hours going down cracking rabbit holes on any box not knowing when to give up, and that just isn’t a fun experience. In Delivery, to make sure that everyone had the necessary starting point, I left a comment in Mattermost hinting at what password and rule to start with. My hope was people used that experience of cracking with a custom wordlist to create a similar process as the one I outlined above.

Conclusion

Hope you enjoyed hearing about my thought process on creating this box. If you solved this box and didn’t have similar takeaways. I would highly recommend spending more time looking at the box after rooting and chatting about the box in our Discord to make sure you’re getting everything you can out of the box. 

If you want to watch me talk about the box as I solve it, the video can be found here. For the best experience, I highly recommend becoming a VIP member which enables you to play along as you watch the video. You can find it here.