Hamlet on TryHackMe – Learning by Teaching

This article is about two things: How and why I created the Hamlet room on TryHackMe and why creating learning experiences is, in fact, learning.

Note: If you are only interested in the technical details and/or the offical Hamlet writeup, go straight to the room’s GitHub repository. It contains both information about how the room was created from a technical perspective as well as how it can be solved (Writeup).

Let’s start in the beginning!

A few months ago, just before leaving for a vacation, I decided to create a new room for TryHackMe, one of my absolute favorite education platforms when it comes to cybersecurity and related topics.

A few days ago, on January 14th, 2022, after peer-review and some additional preparation, the room was finally released to the public¹. Today, on the evening of the 18th, more than 600 people have started to work on the room while roughly 4,500 have looked at it. There has been a lively discussion on Discord and the forums, the first writeups are pouring in, and I have been asked many insightful questions by various learners going through the challenge.

In this article, I want to provide some additional background information on what motivated the room and what it, hopefully, teaches. More importantly, I want to briefly discuss why creating learning experiences for others is a learning experience in itself. In doing so, I want to encourage you to create your own educational materials, to teach, and to learn while doing said things!

As I said before, for those interested, there’s also quite a bit of technical documentation available on GitHub.

TryHackMe and the Idea of a Room

While this article is not about TryHackMe, it is important to understand what the platform does and what a room is in this context.

TryHackMe is a gamified educational platform geared towards cybersecurity. While they offer a variety of highly interesting learning opportunities and paths, most of which are completely free, at the core of their offering are so-called rooms. A room, in this sense, is a self-contained learning experience that allows learners to engage with materials and, more importantly, virtual machines.

In most cases, a room allows you to spin up such a virtual computer, designed by the room’s creator(s), for you to play with. This then is accompanied by tasks, learning materials, and often challenges. By solving these challenges, for example, hacking your way through a vulnerable machine, learners can complete the room and gain both experience as well as experience points doing it.

From an educational perspective, rooms are problem-based learning experiences that allow learners to directly interact and experiment with actual live systems. This, of course, allows for close interaction between more theoretical and extremely practical learning activities.

Above, you can see an example of an introductory room on Linux. Here, learners can quickly spin up an actual Linux server, accessible right in the browser, and try to solve real-life problems as they are learning (e.g., in the video) how to do it.

A special type of room, Hamlet is an example, are challenges or CTFs. These rooms usually don’t provide any explicit learning materials but simply access to a (black box) machine. It is then the learner’s task to hack their way through the machine and to collect proof of their success. Usually, this is done by collecting so-called flags that are stored on the system and require, for example, elevated access rights.

Once they succeed, they are awarded points as well as bragging rights. More importantly, however, there is a thriving community of learners documenting their approaches, creating public portfolios of their walkthroughs and solutions. This, combined with lively study rooms on Discord, YouTube videos, and streamers trying to solve CTF rooms live, provides ample opportunity for both individual and collaborative learning, reflecting, and sharing.

Another very important bit is the fact that TryHackMe allows community members to contribute (peer-reviewed) rooms. Detailing this process would go beyond the scope and purpose of this article, but while this volunteer-driven process can be a bit tedious, it clearly leads to a more diverse platform featuring interesting content from a variety of contributors! That said, all of the caveats of user-generated content on a commercial platform obviously apply.

At this point, it is also important to mention that there are many platforms providing similar learning opportunities and services. Some of the more commonly known ones are, for example, HackTheBox and Offensive Security’s Proving Grounds. While they all have their strengths and weaknesses, they provide a completely new way of learning how to hack (and how to defend).

While it is now commonplace to have safe and relatively affordable access to interesting vulnerable machines, I still remember a time in which wanting to try something usually meant either painstakingly building or finding a fitting target yourself first. Having easy access to a variety of virtual machines and labs offers a whole new set of opportunities for both learners and educators.

TryHackMe Hamlet

I created Hamlet for three reasons: (1) I wanted to learn, especially from the technical side, how to create this type of learning experience. (2) I wanted to apply my educational skillset to a hobby in a meaningful way that also, hopefully, helps someone in the community. (3) I wanted to experience the process of creating and ‘managing’ a learning experience on one of my favorite platforms first hand.

Obviously, all of this also provides me a reasonable pretext for lamenting about (cybersecurity) education and (semi-)new types of learning experiences.

As I said before, Hamlet is a CTF room that challenges learners to find their way through the system I devised. On a high level, this Shakespeare/Hamlet-inspired room allows learners to explore an uncommon web application used in linguistic/NLP research (WebAnno). Cleverly exploiting some misconfigurations, the learners gain access to a Docker container from which they eventually have to escape in order to get full access to the underlying system. Aside from this main path, the system also contains some additional services to explore and experiment with.

The learning objectives, which can also be found on GitHub, are the following. Hacking your way through this room, you will learn how to …

• navigate and exploit specialized and uncommon software (WebAnno).
• creatively leverage the intended capabilities of an application in an attack.
• create custom wordlists from websites.
• leverage PHP web shells.
• do some basic Linux privilege escalation.
• escape from a Docker container that runs --privileged.
• work with yescrypt hashes.
• work in an environment with ufw enabled in conjunction with Docker.
• combine different services/angles within one attack.

While these are quite detailed and provide a good idea of what the room is all about, I followed three more fundamental ideas and educational goals in designing it.

Firstly, I wanted to create a room that did not focus on a single known exploit and/or a single service. Instead, to solve this room, learners need to understand the whole system and a vulnerability stemming from two services that are working together in a way that can be exploited.

Hamlet essentially is all about understanding that, more often than not, there are multiple moving parts to a system and that uncovering their relationship is key to leveraging and/or exploiting that system.

I believe that this is important as many rooms and CTFs focus on identifying a vulnerable service before finding and applying a fitting public exploit. While this certainly is an important skill, there is room for rooms (pun intended) that provide an opportunity to think about interconnected systems. Also, this provides an opportunity for learners to step out of the mindset that every service found in a CTF necessarily has to be vulnerable and exploitable in the sense of a CVE.

Secondly, I wanted to create a room that is useful as a stepping stone from easier challenges. Hamlet is meant for beginners wanting to challenge themselves. In particular, I purposefully threw in some common technical challenges that hinder learners from simply applying their muscle memory and copy-pasting commands. These, for example, include an active firewall, FTP that only supports passive mode, a rather uncommon hashing algorithm, as well as an uncommon web application to begin with.

Many CTFs strip away a lot of the pain and troubleshooting that comes with ‘real’ systems, and for a good reason. While I am definitely not saying that Hamlet is realistic in that sense, it forces less-experienced learners to do a bit of troubleshooting and ad-hoc learning.

Thirdly, I wanted to create a room, a system, that is complex enough to allow for experimentation and for taking alternative paths. While there is an argument to be made for extremely linear and straightforward rooms, Hamlet purposefully can be approached from different angles. This, hopefully, provides learners with an opportunity to test their methodology and to experiment with different solutions. Also, even though Hamlet does not necessarily try to be real, it hopefully teaches that real systems often do not have an overly obvious and straightforward path. Nevertheless, Hamlet is very solveable and I did my best to not make it frustrating in any way. That said, ‘frustrating’ learning experiences, especially in this particular field of study, are most likely necessary.

Of course, as the name suggests, the room also has a narrative component to it. Hamlet, the room, not the play, follows a loose narrative concept that is based on the idea that a group of researchers is studying Shakespeare’s Hamlet. Also, there are some explicit Hamlet references ‘hidden’ in the room, and one of the Docker containers is narratively labeled as a Play-Within-A-Play. Ultimately, knowledge of the plot may even foreshadow some of the challenges within the room.

The reason for this is to find a balance between a fun and somewhat entertaining challenge and a technical scenario that is at least plausible. While it can be debated whether such rooms should have somewhat silly components – Hamlet has at least one – I believe that any educational experience can benefit from some playfulness.

Now, if you are interested in how all of these goals translated into an actual virtual machine, have a look at the official walkthrough which demonstrates the intended path through Hamlet. Of course, you can also have a look at any of the community’s writeups, as I am sure that some of them are better than my own!

It Is All About Learning

After this lengthy discussion of Hamlet, I want to come to my most important reason for creating Hamlet in the first place: Learning!

I am convinced that creating learning experiences for others is, in fact, learning. While we could go down a long and winded theoretical rabbit hole, I simply want to posit that teaching and learning cannot be separated as clearly as many believe. Teaching is learning, and learning more often than not also involves teaching others in one way or another.

When looking at creating this specific type of learning experience, there are at least three phases of learning specifically for the creator! Having gone through the process, I want to briefly discuss each of these in the following.

1. Room Design and Creation (Pre-Release)

On the one hand, designing and creating a room is an interesting technical challenge. This holds true whether we are talking about setting up a virtual machine according to the necessary specifications, making an obscure vulnerability tangible for learners, or configuring a system so that it works as intended.

However, designing interesting and purposefully vulnerable systems is even harder than actually building them. While I could discuss the issues involved at length, I want to focus on one particular issue: We are designing a challenge for hackers, for people who thrive on creatively (mis-)using whatever they are presented.

When designing a challenge room, this means thinking about every single component from a variety of perspectives and in terms of how it could be used differently from what you anticipated. Doing this, I have learned so much more than I would have ever anticipated!

Of course, as with writing, having a team of peer-reviewers and testers also is both challenging and rewarding. After I submitted my first draft of the room, I wanted to be done; I wanted it to be good! Of course, testers had their legitimate issues and I had to go back, and back, and back. Naturally, while being a horrible process that I will never fully embrace, peer-review and feedback led to a better product and quite a bit of learning on my part.

2. Talking to Learners and Answering Questions (Release)

Quickly after Hamlet was published publicly, the questions started to pour in! Many learners wanted hints, while others wanted to discuss how they solved a particular piece of the puzzle (in a completely unintended way).

Just as with any other kind of teaching or learning, these interactions can be a true treasure trove. Repeatedly explaining steps and providing hints to diverse learners (e.g., vastly different levels of experience) forces you to really think about the design of the room as well as the choices you have made. Furthermore, even in just a couple of days, there were a number of comments and questions that led to highly interesting discussions about details and angles I had never even thought of!

Most astoundingly, during these conversations, I learned so much about my own creation that I spun up the virtual machine multiple times in order to verify or test what students had suggested or experienced. Some of these suggestions and questions then directly influenced what I would put into the official writeup.

3. Reading and Watching Writeups and Discussions (Post-Release)

While the room is still very young, the community has already started documenting their questions and approaches. Looking at these writeups and at the discussions on Discord and in the forums is astounding and humbling! Within a few hours, people have found solutions that are way more elegant than mine, and others have created custom tools to solve parts of the challenge.

As an educator and as a creator, it is always beautiful to see people voluntarily spending time on whatever you created. However, especially in this instance, it is also me benefitting from watching people way more experienced than me tackle a challenge I have devised! This is a fantastic learning opportunity as the room becomes a two-way street, a means to develop and share ideas as well as knowledge.

This is also why I published Hamlet as well as the documentation under the permissive MIT Licence. Feel free to use, copy, modify, etc. the material as you see fit!

Verifying Goals and Conclusion

This type of community involvement and feedback, even in just these first three days, allows me to look back at my educational goals outlined above. Based on the questions and feedback I have received, learners seem to struggle, in the most positive sense of the word, with three things in particular:

1. A lot of learners got stuck when they were not able to find a vulnerability in the core web application. Once told that they have to look at misconfigurations and multiple systems at once, it immediately clicked for them.
2. A lot of learners struggled with some of the smaller technical challenges that, for example, hinder you from using tools with their default settings. This includes, for example, a web server that cannot handle many concurrent requests and a hashing algorithm that is not autodetected by john or hashcat.
3. A lot of learners thought that the machine was broken or that something was fundamentally wrong about the challenge once certain methods and approaches, for example, getting a reverse shell, did not immediately work as expected.

One way these initial insights can be interpreted is that CTF challenges seem to foster a specific methodology and mindset. Specifically, they often teach that every system is vulnerable and that focusing on single components is the way to go. Of course, real systems are not designed to be ‘solved’ and usually require a lot more lateral thinking, thorough documentation, and creative troubleshooting. Often, and that’s a good thing, they are not vulnerable at all. Hence, I strongly believe that there is a lot of potential in creating learning experiences that foster these types of competencies and provide an opportunity for reflection. Hamlet is not that experience, but it tries to make learners stop and think.

In conclusion, rooms (or labs, or boxes, or machines) can be fantastic learning experiences for both those creating them as well as for those experimenting with them. However, this often has less to do with how they work technically and more with the community collectively creating and engaging with this content, constantly providing diverse opportunities for learning.

1. Hamlet is a subscription-only room. This means that only paid members of TryHackMe are able to work with it. While I would have preferred a public room, the free compute instances cannot handle the load of the room’s virtual machine. Addition: As of January 26th, Hamlet is, in fact, a free room as TryHackMe have been nice enough to provide more compute resources for the room. ↩