Building Custom Tools for Shits and Giggles And Why Reinventing the Wheel is A Good Thing

Recently, I was on the hiring panel for a SOC analyst position. We received hundreds of applications, with about 10-15 ending in interviews. For the interviews, I read through each resume, and looked at all the linked GitHubs, blogs, and other sites. Something that stuck with me was how every single resume was exactly the same. They all had the same certs, they all had similar degrees, and most of them had nothing interesting in their GitHubs or personal sites. A lot of boilerplate projects that were copied from some other source.

There was one resume that stood out to me. This was entirely due to the interesting project they had worked on, and some of the public documentation they had on their GitHub related to it. Ultimately, that candidate ended up in my top 3 picks.

From everything I’ve seen in the last few years, all cyber students come out of the gate with a Sec+, Net+, CYSA+, and sometimes even an ISC2 associate. These are all fine certs. They tell an employer that you know some things. They’re great for HR filters. The issue for new grads is that everyone has them. They don’t make your resume stand out. I’ve seen many accomplished students struggle because of this. The traditional guidance for many years was to stack certs, and you’ll eventually get a job. These days, especially with all the layoffs and competitiveness I don’t find that to be true.

Instead, what I look for in a resume is your public presence. What tools have you built? What projects have you done? When you made your lab, what constraints did you work around? How did you implement a certain tech stack? Why did you make those decisions? Did you use AI, or did you actually learn the technology? These are the important questions I have that lead to applications standing out. When I see a public repo with hundreds of commits and a readme that explains the thought process behind the project, I get very impressed. Even if the repo is just a simple CLI tool for Caesar cypher implementations.

It’s the demonstration of the thought process, the design, and the problem solving, that I want to see.

Go Forth and Reinvent the Wheel

Often, people looking to get a foothold into cyber ask me about what certs, labs, projects, etc., I think are good resume builders or good learning experiences. My go to answer has typically been the entry level TCM certs (shout out PSAA -> PSAP -> PMRP progression!). However, recently, I’ve had some time to think about this, and while I still think that certificate and training routes are excellent, I also think that the best way to understand something is to build it from the ground up.

For example, anyone can take a VPS, slap cowrie on it, and then pipe the logs to a data lake or SIEM and perform analysis. That’s a great project. You build some infrastructure, you demonstrate knowledge of different tools, how to use them, how they work together, and how you might turn that lab into a real-world threat intelligence feed for an organization. But what if you made the honeypot from scratch? Now that would be a step beyond what everyone else is doing. That would be some cool stuff.

Or say you use PEStudio, CFF Explorer, or one of the other PE analysis tools, and you create a workflow automation that analyzes a PE, extracts some information, and then dumps a report on the suspected threat of the binary. Awesome. Love it. But you know what would be even better? If you read the PE format docs and build your own parser.

One of the first “tools” I built was called Invoke-FileAnalysis. It was a simple PowerShell based toolset for analyzing files. It had four features. It could:

• get strings from a file
• get the file type for like 10 things because I never finished it
• check VirusTotal against the hash of a file

The fourth feature was a PE parser. Of course, when I started developing it, I realized I didn’t know anything about PE files. I knew what they were, and I had a sort of general sense on how they worked, but I didn’t know anything about the structure, the way they’re processed, what an RVA was, any of it.

To really understand what I felt I was missing, I googled “PE file format” and found the Microsoft documentation for the PE file format. This led me down a rabbit hole that ended up producing Invoke-PEAnalysis, which is possibly the most complete documentation I’ve ever created. Certainly not the most complicated project, anyone can look at the file format and write a parser, it’s actually quite simple once you get started.

Essentially, to understand the gap I had identified, I went to the lowest level I could find for PE files, studied it, and then built my own tool to handle and parse the files. Is it a great tool? Not at all. It doesn’t handle PE32+ files, it randomly breaks sometimes, a malformed binary can’t be parsed, and some of the features flat out don’t work on some platforms. I actually had to rewrite a PoSh 5+ edition specifically because some of the features in PoSh 7 are not backwards compatible. However, when I was looking for my first job, this was one of the projects I pointed employers to.

For the documentation, I wanted to ensure that I covered every aspect of the project. The code has all of my original working comments in it, the readme has a full (very, very, long) breakdown of the module, the design philosophy, each function, how the parser works, how PE files are formatted, what I thought could be improved, and why I made certain decisions.

Where I’m going with this is that committing to a project and going all in stands out. Taking a problem, even a problem with existing solutions, and creating your own implementation from the ground up, will always be impressive. It will always lead to you developing new skills, learning new things, and building a deeper understanding of how processes work, why they’re done certain ways, and how they can be improved.

Applying The Hacker Mindset Outside of Tools

Some people will call this desire to understand things from the bottom up the “hacker mindset.” I think it can largely be summarized as:

• Curiosity
• Problem solving
• Challenging existing processes
• Tenacity

There’s also, of course, the desire to break things apart and hopefully put them back together in a functional (but often not) way.

Personally, I think nothing exemplifies the hacker mindset like building your own tools. Something custom to you. My tools aren’t always great, they’re often situational, less efficient than traditional solutions, or simply not as functional. The webservers I’ve made from scratch? They work. Sometimes. In certain specific situations. Would I ever deploy them on my org’s infrastructure? Absolutely not. But you know what? I can tell you right now the best way to build a webserver in PowerShell. Or why you really do want to just use Let’s Encrypt in your Axum server (really, it’s so easy).

Applying this mindset of deep curiosity and a desire to understand how things work is the best tool you can have in your arsenal. When I started my internship, the first thing I did was look at the existing processes and try to find ways to improve them. I identified what I thought of as inefficiencies and discussed with coworkers the struggles they had with various processes. From that, I ended up creating numerous CLI tools, visualization tools, log parsers, web apps, automation, and improved workflows. These early steps led me to get my first job. I was hired on with specific call outs to the things I had done to improve workflows and processes. The hacker mindset I approached my work with directly related to the success I had.

What Does Any of This Actually Mean?

This was supposed to be about building your own tools to understand technology better. To demonstrate how diving deep into something is the best way to learn and understand how it works. It ended up as a long rant about everything but building tools.

I believe in the hacker mindset. The drive that keeps you up at night, chugging energy drinks, and reading through some obscure documentation found on a Chinese forum about ViewState deserialization exploitation. The same mindset that has you look at existing solutions and think “I want to know how this works, how it can be made better, and how I can build my own version of it”.

So, build your own tools. Learn how things work. Go deep into the technology. Do something interesting with it. It doesn’t have to be perfect. It doesn’t have to be better than what exists. Building, documenting, and writing about your work, will make you stand out better than any cert ever could.