5 Years of InfoSec Focused Homelabbing

About the Project

Five years ago, on September 22 2019, I published my first blog post titled “New Homelab”. This began a journey in documenting side-projects done on nights and weekends to build skills in Reverse Engineering, Malware Analysis, and other InfoSec disciplines. While originally created to build a resume of projects for future employers, it evolved into a platform that afforded me opportunities to teach workshops at leading security conferences, land a new job, compete in a international malware analysis competition, contribute to large offensive security projects, and even have my own content referenced in other researcher’s offensive security blogs and workshops. For all of those who have supported me, shared my content, left a Reddit or Youtube comment, you have no idea how much of an impact that has had on me.

For those thinking of starting your own blog, you should.

This is not an article that will suggest what hypervisor to run, what hardware to buy or how to heat your home with the exhaust from your Dell R710. There’s plenty of other videos, and writeups out there to guide you on those areas.

This blog post is an outline of my approach in developing side projects, specifically in the InfoSec space that I have greatly benefited from in hopes of inspiring you, dear reader to do the same.

Applied Learning: Going from Idea to Blog Post

I, and likely you have a backlog of books, articles, Humble Bundle deals, and U-Demy courses that have piled up over the years. When you do identify time to dive into the backlog of $THINGS_TO_READ consider how you could immediately play with some of these concepts you’re learning in almost a “REPL” like fashion. This is often my starting point for a blog post. By identifying a way to immediately apply what you’re learning or experimenting with, you can get those neurons firing and help make technical concepts stick and test assumptions you may have about a given topic/tool/API/etc… This is an easy concept to understand with programming languages, but allow me to demonstrate with something I came across on Twitter earlier this year.

Earlier this year when Microsoft announced their “Recall” project which takes screenshots of an end-user’s desktop every so often. The response on X/Twitter from the InfoSec crowd highlighted how big of an issue this is for end users, and many individuals started creating YouTube videos/PoC demos to play with this new feature. These demos highlighted how sensitive data such as passwords and API tokens could be later obtained should an attacker compromise a machine. Security nightmare aside, I thought “I could probably do to this on Linux with a one-liner”. Which then leads to the question of “well how would you?”. A rudimentary one-liner of a command-line screenshot utility “scrot” combined with Google’s OCR engine Tesseract did just the trick, and with that I had a toy example to play with.

scrot | tesseract >> recall.log

Tesseract will extract text from images and I now can wrap this in a while true loop and have my own janky version of Recall. Now lets allow this idea to spiral:

How could we port this to Win32 API calls that send screenshots to a Flask app that wraps interaction with Tesseract?

What if this was running in the background on a honeypot server monitoring those who might RDP into a host?"

Lets throw it into Kubernetes for good measure. - my inner monologue

From a simple seedling of an idea demonstrated in a one line bash script to an API backend running in a Kubernetes cluster YOU have the power to make this as ridiculous as you’d like. Creating toy examples around thought exercises about a given subject is how I developed the idea for “Weapons of Text Destruction”, a talk on how to use Vim as a post-exploitation tool. While there’s probably no one out there using Vim as their post-exploitation toolkit of choice, you could, and it’s that creative thought process that I have found to be my most valuable asset in this profession.

Not everything you blog about and build in your homelab needs to be production grade or realistic for enterprise environments. Part of the fun I have with homelab experiments, is developing systems which give you weird edge cases or ridiculous scenarios. These projects usually end up as great conversation pieces during interviews or in the worst case scenario a fun story to share over beers. The key takeaway here is to do projects you think are fun. When learning is fun, you’ll learn more. When your homelab feels like a job, stop.

From CTFs to CVEs

A common response in the InfoSec industry to those looking to develop skills in Reverse Engineering/Malware Analysis/ Software Exploitation is to “do CTFs”. The idea here is to get more exposure to assembly language, vulnerable coding practices, encryption methods, etc… this way you can identify said issues in real world software. Unfortunately, I’ve found that this advice can be incorrectly interpreted as “do CTFs 24/7”. This is a sure fire way to burn yourself out, and become disinterested in the field. I’d like to suggest a new approach to optimize your time with CTFs to extract the most value of your time investment in them.

  1. Review old CTFs

If the CTF is an annual event, you may be able to browse and attempt previous challenges (if there’s an archive), and review associated writeups when you get stuck. Its also valuable to familiarize yourself with the types of challenges a given CTF puts on. Some may be more PWN heavy while others may have a larger crypto section. For upcoming CTFs that look interesting, check if CTFtime has an archive page for said event. Large events like DEF CON’s CTF have great archives to explore. There’s also always random github repos that may contain an original challenge from a CTF you’re looking at.

Another positive element about this strategy is that you get to plan it on YOUR time and not the events time. You don’t need to spend your entire weekend poking at a forensics challenge. I personally have found when I don’t feel like I’m “up against the clock” of the event, I can extract more from the problem at hand.

  1. Engage with the CTF Community

Most CTFs have an associated Slack or Discord for their event. Engage with the challenge creators and fellow competitors to not only build your network (it’s a small world after all!), but also to chat with post-competition to understand why something didn’t work as you expected it to. I’ve blogged about reverse engineering challenges where I was stuck during the competition, but afterwards a fellow competitor shared a bit of insight that unlocked the “ah ha!” moment. If you look at these events as opportunities to learn vs simply trying to get to number 1 on the leader board, you’re likely to enjoy the event more.

  1. Poke at CVEs

Now CTFs are a way to learn a bunch of different skills, but its not the only way. Everyday new vulnerabilities are identified and reported by companies and researchers alike in the form of CVEs. While each CVE blurb varies in quality and content, for Open Source projects, you have the ability to go and grab the patch, and perform root cause analysis on the underlying vulnerability. If you, dear reader create a blog post detailing root cause analysis of a given vulnerability along with strategies for remediation then congratulations! You have just performed a common task of a AppSec engineer/security consultant/$OTHER_JOB_ROLE_HERE. This is real world experience and you didn’t have to pay >1k for some certification. Isn’t that neat! As an added bonus, in some “root the box” style CTFs, you may see reuse of the vulnerabilities you analyzed.

For the super ambitious, try to create a PoC to exploit the vulnerability or build a utility to scan for said vulnerabilities. Some of the early Log4J scanners released by large companies were nothing more than a series of bash scripts.

Doubling down on the CTF-to-CVE front, I’d also recommend looking for end-of-life (EOL) devices. Old routers and IoT devices are relatively inexpensive on eBay and once again make for fun adventures in rediscovering vulnerabilities from documented CVEs. From my “Old CVEs Leading to New Vulns” blog post, I discovered the router had the yet another command injection in a different section of code that was not mentioned in the CVE at all. This router cost me less than $20 USD and I can confidently say the blog post and experience in diving into that firmware has paid off more than $20 USD.

  1. There is No Wrong Choice

CTFs, CVEs, Malware Analysis, whatever your subject of interest is there is no wrong choice in what to spend time on. You’re exploring and developing your technical skills in a way that’s hopefully intellectually stimulating and may impact your career in ways you cannot currently see. If it is interesting to you, explore it. There are no points awarded for doing things you don’t like in your free time. When CTFs start to feel like a job, stop.

New Techniques with Old Books

Note: I am in no way sponsored by or affiliated with No Starch Press, but damn do I love that publisher.

A final thought I’d like to share is the under appreciated value of aging technical books. One book I regularly recommend to those looking to learn Malware Analysis in a structured format, is Practical Malware Analysis. While its over ten years old, it’s one of the most comprehensive books I’ve found to date on analyzing malicious code. The techniques you learn in this book about network traffic monitoring, reverse engineering, unpacking malware, etc… are still very relevant today. Where the book is showing its age is the largely within the toolset and frameworks used for conducting analysis. Instead of thinking of this as “outdated content”, think of this as a way to port the techniques the book is teaching to modern reverse engineering tools. For example:

  • Ollydbg can be replaced with x64dbg
  • IDA, while still available could be replaced with Binary Ninja, Ghidra or Cutter
  • Windows malware can be replaced with Linux 😉

This hits on an early point I made in this blog post about “applying knowledge”. Use what you know with things you’re currently learning to bridge and solidify concepts. Rather than dismissing books/articles for their age, look at the sections that have aged as opportunities to adapt them to modern tooling. A practical example from my experience has been going through Designing BSD Rootkits and porting their code samples from 2007 to a modern 2024 FreeBSD release. This was much easier than I thought (shoutout to BSD for making their codebase super easy to hack on) and has left me with a fun artifact for a Hack Fortress event.

Conclusion

Writing blog posts is a practical exercise in documenting and sharing with others lessons learned in a given subject. Effective technical communication is a critical component of almost any job role, and just another reason to register that domain today and start your homelab blog. When learning is fun, you’ll learn more. When your homelab feels like a job, stop.

Here’s to 5 more years of Arch Cloud Labs 🍺!