I have spent a lot of time around security professionals, but I am not sure that I would consider myself one of them. Maybe a better way to say that is that I am a not traditional security professional. In a field as diverse as information security, maybe the idea of a traditional security professional is a myth. I have worked with security teams to build or integrate their tools and platforms. I have implemented a SIEM and managed all the processes for ingesting and visualizing the data in it for a large company. I have been involved in forensic investigations, incident response, and I have hunted rogue activity within an environment. These things sound like security stuff, but I come from the development and operations side of the house. The security teams were my customer, in many cases they were my most valuable, if not only customer. I never reported to anyone with security in their title, but I have been in a lot of meetings with those folks to help solve problems.
Last year I moved across the country to take on a new role as a Senior Security Consultant within Set Solution’s Data Analytics practice. My day-to-day role deals with Splunk, Elastic and other data analytics platforms. My work here at Set is adjacent to security in much the same way that my previous roles were, my customers tend to be the security groups within an organization. I work with our customers to solve their problems related to data ingestion and analysis. I am not the person that gets sent out to execute a penetration test or roll out an EDR platform. I am one of the folks that gets the call to help an organization capture the data from those tools, and then normalize and transform that data into actionable information. My job deals with making sense out of the mountains of data that machines and tools generate.
With that said, when I took this job, I decided I should learn more about the tools and systems that were generating all that data that I deal with. I started exploring the security field and reading pretty much anything I could get my hands on. I started to learn about security tools, products, and practices that form the baseline for how security should be done. Many of the tools are expensive and only make sense at a certain scale. One does not deploy a next-gen firewall, identity and access management, data protection and encryption platforms for their desktop system at home. I guess you could, but it would be like using a ship mounted rail gun to kill a mosquito.
I wanted to learn about products, techniques, and best practices but I kept running into little challenges. Having skipped that right-of-passage that is the SOC/NOC support desk, I have not really had a chance to see this stuff in action. To get data about what an attack looks like, you basically need to witness an attack on your stuff. To see how a defensive product works, you need to install it on something, and then attack that thing to see how it responds. Or you could give it a public IP on an AWS VPC and wait like 30 minutes. Even then, most of those attacks are not useful, because they are bots.
Cortana scripting language by Christiaan Colen is licensed under CC BY-SA
I started thinking about how to learn better, I thought about how to build things that I could attack. I broke the news to my wife that I needed to buy some hardware to set up a lab to learn how to hack stuff. You can imagine what that conversation was like. My wife is a remarkably tolerant person, she knows what I do, and she supports most of my wild ideas, but this one took some explaining. After debates, deliberations, and many rationalizations about how this would be a good thing for my career, I took a trip to the nerd-heaven that is otherwise known as Micro Center. I bought a few Raspberry Pi micro-computers, a desktop PC to run VMs, cables, and other stuff that looked like fun. It was a good day.
I built a domain controller, and some utility server VMs. I built a local certificate authority and learned how to generate my own certificates and then how to use them. I configured a small development Splunk instance so that I could collect data about what I was going to be doing. I spent some time figuring out how to take the next step to get started. Security is a broad field, there are a ton of places to get started. There are so many places to get started that I had a hard time deciding how to take the first step. I got stuck there for a little while. As it turns out, just buying stuff and building things doesn’t get you down the security-journey path. Who’d of thought?
It was about this time that every security company in the country was gearing up for National Security Awareness Month events in October. Set Solutions was planning a Capture the Flag event. I had read about these CTF things and assumed they were well outside my capabilities. I didn’t know what a flag was, and I absolutely had no idea how to capture one. To test our CTF before opening it up to the public, the engineering team was asked to beta test the challenges and the platform that we would be using. This would be a dry run of the event, for internal team members only.
I volunteered to help with the beta test mostly to help justify all the hardware I had bought, and I figured I would probably learn something useful along the way. We would have a week to complete 20 challenges. I hoped to answer at least one question, and not finish in last place. We have “real” security people on this team, so I wasn’t thinking about winning. I’m just a noob, not even a script kiddie because I don’t know where those scripts are. I over prepared for the CTF, reading all the things I could find about people’s first CTF experiences. I worked myself into a bit of a panic, convincing myself that I was going to fail horribly, and my bosses would realize that I don’t know anything, and they would fire me, and I just got to Texas in the middle of the pandemic, and I was going to be homeless and die of exposure to that nuclear ball of hate that some people call the Sun. I am occasionally slightly dramatic, and sometimes I go way too far down the rabbit hole.
Anyway, the day the CTF beta test started, I woke up early. Let’s be honest, I slept like five hours because I was freaking out about failing. The challenges open, and I get started. I boot up Kali, and then spent 4 hours trying to answer the first question. Half a dozen folks on the team completed 5-8 challenges before I got my first challenge completed. I had to google pretty much everything that I encountered during the event. I woke up at 3-4am each day, and when I was not doing real work or sleeping, I was working on the challenges. I would oscillate between imposter syndrome despair when I couldn’t complete a challenge, and Jack on the bow of the Titanic when I finally got something completed.
Working though the challenges and figuring out how these things work was an eye-opening experience for me. Some challenges I did well on. Others were very difficult to even know how to begin. Everything was an opportunity to learn something new, and I really enjoy the acquisition of new knowledge.
To my surprise, I was the first person to answer all the questions. A large part of this is because I put a ridiculous amount of time into it. I also bought almost all the available hints for the challenges. In this game, hints were optional, and they cost score points. Since I had no intention of winning, I took a lot of hints so that I could keep moving through the challenges. Despite being an emotional roller coaster and the sleep deprivation, it was an enjoyable experience. I ended up taking second place. I was very happy, and I am still proud of that accomplishment.
After the event ended, I started looking for more things that I could do that were CTF-like. The CTF was too stressful and time consuming to be sustainable, or healthy. I chose HackTheBox as my first learning platform. I thought it would be challenging, and I was not wrong. As a beginner, I found it to be a little too challenging. Before too long, I started splitting my time between HackTheBox and TryHackMe. TryHackMe has more guided-scenario content, and the challenges are more bite-sized. After a few weeks, I could see some progress. Things were not easy, but they were getting easier.
I decided at the end of last year that 2021 was going to be the “year of hack”. 365 straight days, putting at least a little bit of time in every day doing some form of studying or practice related to pentesting. I also decided to go for the OSCP certification. It will take me at least a year to prepare for it, but I think I can do it. I am not working towards OSPC because I want to be a pentester. In fact, I don’t want to be a pentester. I don’t want to break other people’s stuff, even accidentally. I want to learn pentesting because I want to be able to attack stuff that I build, so that I can capture that data to see what the attacks look like. Essentially, I want data, and I love learning new things. This path has no shortage of either. There are probably easier ways to do this, but this way sounds fun to me.
Code Quality by xkcd is licensed under CC BY-NC 2.5
With that backstory out of the way, I have come to the point of this new series. This Journey of Learning series will be about techniques that I am learning on my journey to the OSCP. Instead of doing writeups about the challenges, I will be focusing on how these red team techniques can be applied in my role here at Set, as part of our Data Analytics practice. For each post in this series, I am going to focus on one technique that is likely to be seen during the OSCP (or PEN-200) exam. I will build a vulnerable app or server to demonstrate the technique. I am going to instrument the app and its server(s) so that I can capture the data to build detection and correlation searches with. I will be using Splunk and our RAISE Framework for Splunk for the data-analytics parts because it is one area where I feel like I know what I am doing. I am sure I will learn something about Splunk and data analytics along the way too.
This will be an 8-part series, running throughout this year. The topics I am planning to cover are seen in the OSCP exam, and in the real world. Admittedly, some of them are not so obvious in the real world. The topics include Server-Side Template Injection, SQL injection, kernel exploits, and privilege escalation techniques for Windows and Linux. I will also spend some time writing about the various tools used in pentesting, and how they can be used both offensively and defensively.
I am still learning. I will always be learning. I learn best by doing something and then explaining it to other people. I hope you will come along with me on my journey, even if it is just to tell me what I am getting wrong. I don’t know if I can top the frozen vegetable analogy for analyzing modem data, but I’ll give it my best shot.
***
This blog was written by Greg Porterfield, Senior Security Consultant at Set Solutions.