Hey, I'm Andy and I'm an Information Security Professional. I focus mainly on offensive security, red team operations and adversary simulations, security research and exploit development.
This page is a collection of topics I've studied and practiced during my transition from software engineering to offensive security, including my notes from a variety of certifications (such as OSCP and OSWA), and cheat sheets I use on a day to day basis as I conduct penetration tests or vulnerability assessments.
The intention is to further expand this page and document new subjects as I gain more knowledge and experience in security areas.
As for the transition to the infosec, I've documented the whole journey on my personal blog - stop by and have a look.
Latest Blog Posts
2024-01-17 - Getting a Black Belt in Wi-Fu - OWSP Review
2023-11-02 - XSS in NASAs Open MCT v3.0.2 - data exfiltration
2023-10-19 - My Journey to Finding My First 0day/CVE
2023-10-13 - Yamcs Vulnerability Assessment
2023-10-12 - Prototype Pollution in NASAs Open MCT CVE-2023-45282
2023-08-05 - How I Failed OSWA Exam
2023-07-23 - Mid-career Transition to Infosec 0x07
2023-03-19 - Mid-career Transition to Infosec 0x06
2023-01-16 - Mid-career Transition to Infosec 0x05
2023-01-12 - ADwalk: simple PowerShell script to enumate Active Directory
2022-12-20 - clif: simple command-line application fuzzer
2022-12-12 - nansi: simple tool for task automation
2022-09-01 - Mid-career Transition to Infosec 0x04
2022-08-10 - Mid-career Transition to Infosec 0x03
2022-04-27 - Mid-career Transition to Infosec 0x02
2022-03-10 - Mid-career Transition to Infosec 0x01
My Infosec Trophies
Certificates
Offensive Security Certified Professional (OSCP)
Offensive Security Web Assessor (OSWA)
Offensive Security Wireless Professional (OSWP)
CVEs
CVE-2023-47311 6.1 MEDIUM
CVE-2023-46471 5.4 MEDIUM
CVE-2023-46470 5.4 MEDIUM
CVE-2023-45885 5.4 MEDIUM
CVE-2023-45884 6.5 MEDIUM
CVE-2023-45282 7.5 HIGH
CVE-2023-45281 6.1 MEDIUM
CVE-2023-45280 5.4 MEDIUM
CVE-2023-45279 5.4 MEDIUM
CVE-2023-45278 9.1 CRITICAL
CVE-2023-45277 7.5 HIGH
CTFs
Tools I developped
clif
Simple command-line application fuzzer.
ADwalk
Simple PowerShell script to enumate Active Directory.
nansi
Simple tool for task automation.
fspell
CLI tool allowing for an easy browsing and searching of your favourite spells without leaving your terminal.
Other
Full list of repositories can be found on my GitHub.
Exploits I've developped or controbited to
Karaf v4.4.3 Console RCE
OSGi v3.8-3.18 Console RCE
OSGi v3.7.2 Console RCE
Blog
2024-01-17 - Getting a Black Belt in Wi-Fu - OSWP Review
2023-11-02 - XSS in NASAs Open MCT v3.0.2 - data exfiltration
2023-10-19 - My Journey to Finding My First 0day/CVE
2023-10-13 - Yamcs Vulnerability Assessment
2023-10-12 - Prototype Pollution in NASAs Open MCT CVE-2023-45282
2023-08-05 - How I Failed OSWA Exam
2023-07-23 - Mid-career Transition to Infosec 0x07
2023-03-19 - Mid-career Transition to Infosec 0x06
2023-01-16 - Mid-career Transition to Infosec 0x05
2023-01-12 - ADwalk: simple PowerShell script to enumate Active Directory
2022-12-20 - clif: simple command-line application fuzzer
2022-12-12 - nansi: simple tool for task automation
2022-09-01 - Mid-career Transition to Infosec 0x04
2022-08-10 - Mid-career Transition to Infosec 0x03
2022-04-27 - Mid-career Transition to Infosec 0x02
2022-03-10 - Mid-career Transition to Infosec 0x01
Security Articles
2023-11-02 - XSS in NASAs Open MCT v3.0.2 - data exfiltration
2023-10-13 - Yamcs Vulnerability Assessment
2023-10-12 - Prototype Pollution in NASAs Open MCT CVE-2023-45282
Personal (still infosec)
2024-01-17 - Getting a Black Belt in Wi-Fu - OSWP Review
2023-10-19 - My Journey to Finding My First 0day/CVE
2023-08-05 - How I Failed OSWA Exam
2023-01-12 - ADwalk: simple PowerShell script to enumate Active Directory
2022-12-20 - clif: simple command-line application fuzzer
2022-12-12 - nansi: simple tool for task automation
Getting a Black Belt in Wi-Fu - OSWP Review
So, I started digging into various security aspects of Wi-Fi. Initially, Google was my go-to buddy, but then I thought a more organized approach would be cool. Since I still had the OffSec Unlimited Subscription back then, I decided to take a shot at the PEN-210.
PEN-200
I kicked off the PEN-210 with a pretty limited knowledge of anything wireless. As I went through the training material, I was shocked at how much I didn't know – from the nitty-gritty of IEEE 802.11 standards, network setups, frequencies, encryption, to various attack vectors and the whole arsenal of tools to conquer different Wi-Fi networks. There was a good amount of reading involved, and I'll admit, I've already forgotten half of those details. It's not the kind of stuff you use every day, so it doesn't exactly stick in your brain. But now, I'm aware of these things, and I can always look them up in my notes or ask our good friend Google.
Now, I know the OffSec training library like the back of my hand, and one thing that caught me off guard was the absence of a PEN-210 lab. Instead, they recommend which Access Point and wireless card you should grab. At first, it seems like a major hurdle. If you want to dive into the exercises, you've got to get the hardware first. But when it came to actually doing the exercises, setting up the lab environment yourself (with a real Access Point and configuring it) turned out to be a pretty cool learning experience. I learned a ton, understood exactly what I was setting up, and why I was hacking it in that particular way.
Now, let's talk about the technical stuff – you know, the exciting part where you actually get to do things. You'll tackle exercises to practice wielding different tools, cracking authentication hashes, launching rogue access point attacks, going after WPS networks, WPA/WPA2 and WPA Enterprise networks, and even messing with captive portals. For a wireless newbie like me, it was a good bit of fun.
Exercise
I managed to run all the exercises in the training material using a LinkSys AC1200 router and an Alfa AWUS036NHA WLAN adapter. These aren't the exact makes and models you necessarily need, but they're surprisingly affordable and tick all the boxes for practicing for OSWP.
Since there's no lab ready-made for you, I strongly suggest putting in the effort to create your own setup, especially for the exercises in the key areas of the training. This way, you ensure that when the exam rolls around, it won't be the first time you're executing a specific attack.
Exam
Just like any other 200-level OffSec course, the OSWP exam is an open-book, proctored affair. But here's the kicker – unlike its course cousins, the OSWP exam only lasts for 3.5 hours. It throws three challenges at you (one is a must, the other two are your call), each involving cracking into different networks. Once you're in, the goal is to grab a flag from a server chillin' on another host connected to the same network.
To ace the exam, you've gotta nail the mandatory challenge and pick off one of the optional ones. Post-exam, you've got an extra 24 hours to wrap up and shoot over your pentest report, just like the drill with all the other OffSec courses.
Conclusion
Whenever I dive into a new training, my go-to move is to check out the syllabus and figure out if it's going to dish out some fresh skills. In this case, a whopping 95% of the content was totally new to me, making it totally worth my study time. But here's the thing – after chatting with some seasoned hackers, it turns out most of them already had this knowledge. I'm pretty sure they could breeze through the exam without breaking a sweat.
Right now, you can't snag the PEN-210 on its own – it only comes bundled with the Learn One subscription or some other training package. But still, unless you already feel like a Wi-Fu black belt, I'd strongly suggest giving the course pages a good read. The exam is like a bonus round to test all the cool stuff you've learned. While it's awesome to get an official badge, I get that many might skip it and focus their study time on the main course they got with Learn One.
Resources
My Journey to Finding My First 0day/CVE
I've dreamed of discovering a 0day vulnerability and getting a CVE assigned to it since I started my transition to Offensive Security. In my mind, being able to find previously unknown vulnerabilities was a way to validate my skills and abilities as a security researcher. Unfortunately, for the same exact reasons, I only started actively hunting for vulnerabilities a couple of months ago, after I changed my role, and security research is now part of my job. Almost two years passed between the time I added "finding a 0day" to my list of goals and the time I actually attempted to do it. But why? The short answer is: I didn't know that I could.
The concept of discovering a 0day vulnerability remained at the top of my goal list for so long that it became something of a holy grail for me, almost unattainable. I believed that I didn't know enough to even begin, and the idea of starting felt like a waste of time because I thought I wouldn't find anything anyway. It seemed more sensible to concentrate on studying and progressing in my transition to information security.
Initially, I felt pressured to learn quickly and formally establish myself as an information security professional before embarking on 0day hunting. However, as time passed, I relinquished that pressure and became accustomed to the idea that achieving this goal might or might not happen at some point down the road. The human mind is peculiar, and it can sometimes play tricks on you, as it did in this case, leading me to deceive myself.
Things began to change when I stumbled upon a very interesting article written by 0xBoku: Beginner's Guide to 0day/CVE AppSec Research. In this article, he described his journey and how he started hunting for 0days as part of his preparation for OSWE. By that time, I had already obtained the OSCP certification, was working towards OSWA, and had slowly begun to explore OSWE training materials. However, even as I started preparing for OSWE, I still didn't feel confident enough to venture out and search for 0days.
I started my new role almost four months ago, and for two of those months, I worked on various R&D projects in the field of offensive security. Around two months into the job, I was assigned a vulnerability assessment of a software product. At that point, I was well into my OSWE training and believed this was an excellent opportunity to put my skills to the test.
During the first couple of days of the assessment, I discovered my first 0day vulnerability in the NASA Mission Control System. It's been a few weeks now, and I've completed the assessment of NASA's system, finished reviewing another product, and currently have 8 confirmed CVEs with a few more awaiting publication.
You can probably imagine the excitement I felt after finding that first 0day. I had finally achieved a goal that had been at the top of my list for the last two years. It was indeed a significant accomplishment for me. However, now that the initial excitement has settled, I thought I'd take a moment to reflect on this journey and attempt to answer the most obvious question: What took it so long?
I've spent some time trying to retrace the steps I've taken over those two years and have summarized them into three main categories.
Lack of confidence
Some people refer to it as imposter syndrome, but I'm not a fan of the word "imposter." I believe it's important to recognize that how we feel about ourselves can influence whether we take action or not, but it doesn't necessarily reflect our ability to do something. In my case, I was convinced that I needed to reach a certain level of knowledge and experience before I could begin finding 0day in software products. It took me a very long time before I actually tried, and even then, I only did so because my boss requested it. A lack of confidence can be blinding, and despite looking at the signs indicating that I was ready, I still couldn't see it.
Apply what you've learned
One of the main reasons I decided to pursue OffSec training courses is the fact that they are highly technical and consistently require you to apply the knowledge you gain by studying the training material. I'm an advocate of this approach, and I found these courses very appealing and convenient because I could solely focus on OffSec's guidance without having to figure out how to apply the new knowledge to gain practical experience. However, for me personally, this comfort became a hindrance and led to procrastination in my 0day hunting efforts, without feeling too guilty about it. Don't get me wrong; if I had to choose again, I'd still opt for OffSec training every time. However, if I had to start over, I would be more mindful of the need to balance training with real-world application.
Hack what you know
There are many ways to get started; you can obtain software from sources like SourceCodester or GitHub and begin searching for vulnerabilities. However, I believe it would be more beneficial if you started with software that you already know or have used.
In my case, as I mentioned in my mid-career transition to infosec story, I had extensive software engineering experience in the space sector. This background was particularly helpful when I was tasked with assessing an existing Mission Control System. I had previously seen and even used this software, and I had no trouble setting it up. Since I was familiar with the space industry and the functions of the ground segment, I didn't need to spend time figuring out what the software did or how it worked. I can attribute the fact that I found my first vulnerability within a matter of hours to my prior knowledge of the software.
Of course, I consider myself fortunate because the software I'm referring to is developed by NASA and is used in various space missions and organizations. This system is an attractive target for research. You may not be as lucky, but don't worry; the key consideration when selecting a target is that the software has some user base.
That's it! I believe these are the main lessons I've learned from my incredibly long journey to finding my first 0day. If you're considering embarking on the path of 0day hunting, I hope you find this writeup helpful. I'm also interested in hearing about your experiences in this field, so please consider sharing them with me and others.
How I Failed OSWA Exam
After obtaining my OSCP certification, I considered a couple of options for my next certification. The main ones I had in mind were OSED and OSWE. However, although I was a little tired after completing the OSCP, I didn't want to take a break. Instead, I decided to relax a bit by going for something that would be easier to achieve. While browsing through the OffSec library for other 200-level courses, I came across OSWA, which seemed like a good opportunity to delve deeper into web penetration testing.
What is OSWA?
OSWA stands for Offensive Security Web Assessor, and it is a certification that validates the skills acquired during the WEB-200 course. The course focuses on Web Penetration Testing from a black-box testing perspective. It covers various vulnerability classes and provides insights into how they function from both an attacker and defender standpoint.
Training material and labs
Similar to other OffSec courses, WEB-200 includes training materials (PDFs and videos), interactive exercises that accompany each training module (where students can start a virtual machine, perform specific actions to obtain a flag, and submit it through the portal), and a set of lab machines. The interactive exercises are contextualized within the training material, while the lab machines are standalone systems with no hints about the vulnerabilities or attack vectors they expose. Each lab machine contains two flags: one displayed upon obtaining administrator-level access to the web application and the other in a proof.txt file hidden somewhere on the system. The lab environment simulates real-world web pentesting, combining challenging scenarios with CTF-like elements. The lab size keeps expanding over time, and OffSec introduces frequent small changes to enhance the course content. When I started working on WEB-200, there were 6 boxes, and by the time I finished it, there were already 8. So, by the time you read this, there might be more machines.
The exam
The OSWA exam is a standard 24-hour test with five standalone boxes to assess the candidate's skills. After completing the exam, participants have an additional 24 hours to prepare and submit the report. The exam machines are similar to those encountered in the lab, but with different vulnerabilities and exploitation techniques. The rules for obtaining the flags in the exam are the same as those in the lab environment, though they may change over time, so it's crucial to refer to the official Exam Guide pages for the latest information.
My experience with OSWA
Initially, I believed OSWA would be an easy and quick success, but I soon realized I had underestimated its difficulty. While I was already familiar with most web vulnerability classes and had some black-box web pentesting experience, the WEB-200 course introduced numerous variations and challenges I had never encountered before. The difficulty level was high, emphasizing not only technical skills but also the ability to think creatively. I approached the training with a similar strategy as I did for OSCP, starting with easy machines and seeking help from forums and the Discord community. However, I discovered that this approach was not suitable for OSWA due to the limited number of lab machines available. Asking for help too often deprived me of the opportunity to figure things out independently.
Unfortunately, I failed my first OSWA attempt, and upon returning to the lab, I realized that I had forgotten certain concepts because I relied too much on external help instead of solving challenges on my own. I paid the price during the exam. Nevertheless, I learned from this experience and scheduled a second attempt after a 3-week cooldown period (my subscription allows for a 2-week cooldown). During this time, I thoroughly reviewed all training materials and completed the lab again, this time without seeking any assistance, even tackling the new machines added later. Ultimately, I successfully passed the second attempt and can now officially call myself an Offensive Security Web Assessor. I firmly believe that if I had put more effort into solving all lab machines independently and not underestimated the course's difficulty initially, I could have passed on my first try. Lesson learned.
Now, I'm looking forward to moving on to WEB-300 and CRTO, both of which I need for work, and I'm incredibly excited about them!
ADwalk: simple PowerShell script to enumate Active Directory
One of the things that became apparent to me (which also came as a surprise) since I've started my journey with offensive security was that Windows systems and Active Directory are absolutely everywhere. Most of the systems you will ever get to hack as an offensive security professional are going to be on Windows.
Probably the best tool for AD enumeration out there is the PowerView, however, to start using it you need to first transfer it to the target machine, just to do some basic enumerations, which sometimes is not ideal and can be problematic. I've noticed that often instead, a pentester will write a small script in PowerShell to start a simple enumeration of AD, just to see if there's anything there worth the attention. I've started practicing this approach myself and I find it much quicker - once I'm on a target system with access to PowerShell, I can write a short code and run it on that system to get the basic detains about AD.
Having this in mind, I've created a small PowerShell tool, called adwalk, which allows me to do just that. The main purpose of it is to display all OUs (Organization Units) in the Active Directory you are currently connected to, but you can also supply a filter in case you're looking for something specific, like an SQL server. Here's how it works:
Here an example of how to use it:
PS C:\> .\adwalk -filter "serviceprincipalname=*sql*"
Here's a quick demo:
For more details, head to the GitHub repo.
clif: simple command-line application fuzzer
clif is a command-line application fuzzer, pretty much what a wfuzz or ffuf are for web. It was inspired by sudo vulnerability CVE-2021-3156 and the fact that, for some reasons, Google's alf-fuzz doesn't allow for unlimited argument or option specification. Since I try to practice my Rust whenever there's an opportunity to develop something that I actually might use, I decided to create my own fuzzer.
Here are a few examples of what it can do:
# throw wordlist.txt as input
clif -e my_program -w wordlist.txt
# throw wordlist.txt as -p argument
clif -e my_program -w wordlist.txt -a "-p FUZZ"
# throw numbers from range 100..100000000 as the first argument
clif -e my_program -n 100..100000000 -a "-n FUZZ"
# throw a string with length from range 10..100 as the first argument
clif -e my_program -s 10..100
For more details, head to the GitHub repo.
Here's a quick demo
nansi - simple tool for task automation
Since I've started getting into infosec, I have been using virtual machines for absolutely anything and everything. Sometimes that's because I want to have a clean setup, e.g. my Kali with some additional hacking tools; or maybe it's a Windows system on which I want to test my exploit and also needs to be pre-configured. It also happens that I simply have no other choice and have to spin up a new system, like in case of the Bug Bounty programs, which made me experience first hand the ISP response to some strange network traffic - just by blocking it.
Setting up a new VM quickly became a very boring and repetitive task, and so I decided that I need to automate this process. Here's what I need: simple command runner, quick and easy. I've tried automating the process with bash first but soon realized that with the level of control I want those commands to run, bash is not going to be the best choice. The next thing that crossed my mind was to set up Ansible, since I remember using it at some point in the past, but the moment I started setting it up I realized that this thing blew into an immense giant and using it for what I need is an overkill (not to mention the huge waste of time).
All this led me to take a step back and think what exactly do I need:
- simple command runner
- OS independent
- possibility of defining dependencies between those commands (i.e., if command D depends on command B and command B fails its execution, command D won't execute)
After a few minutes of googling and not finding anything half decent, I decided to quickly make my own. I called it nansi as 'not ansible'. It took me a few hours of figuring some things out and actually codding it. It was also a great opportunity to practice my Rust :)
Now to get me started with a new VM or a Bug Bounty target, I just need to spin up a Kali or Ubuntu on my favorite VPS provider and run one command to install all my hacking tools.
Here's a short description:
nansi is a simple tool for task automation. Its primary functionality is to execute a sequence of commands in a defined order. It was inspired by what Dockerfile is and what ansible is not.
Here's also a link to GitHub repo.
Mid-career Transition to Infosec
2023-07-23 - Mid-career Transition to Infosec 0x07
2023-03-19 - Mid-career Transition to Infosec 0x06
2023-01-16 - Mid-career Transition to Infosec 0x05
2022-09-01 - Mid-career Transition to Infosec 0x04
2022-08-10 - Mid-career Transition to Infosec 0x03
2022-04-27 - Mid-career Transition to Infosec 0x02
2022-03-10 - Mid-career Transition to Infosec 0x01
Mid-career Traisition to Infosec #0x07
In March 2022, I released the first part of this blog series. Today, 15 months and 7 posts later, I write to share the exciting news that I have recently embarked on a new chapter as a Cyber Security Engineer. In my new role, I will be focusing on offensive security and engaging in a variety of impactful activities, including red teaming, adversary simulations, and security research.
You're probably wondering now, how did it happen? Have I finished the transition and completed all the training? Have I been applying to different jobs and eventually got one? None of that has happened yet - my training is far from done, and I haven't started applying to infosec jobs. So, how did it all come about?
As I mentioned in part 005 of this series, at some point, I decided to go out and share the news about what I was up to, my goals, and the steps I was taking to achieve them. This is when I also decided to publish this blog series, talk to friends, people I worked with at that time (and those I used to work with in the past), and even my (now former) employer. I was very open and honest about my aspirations, and I would share them with anyone who would listen. Surprisingly, as soon as I started sharing my desire to move into infosec, I began receiving some job offers, and eventually, I decided to go for the one that I thought was the most suitable for me.
Of course, this would not have been possible without hard work and dedication. As you know, my approach was to obtain the most difficult certifications available, as they would prove that I'm ready for the job. However, if I had kept my goals and aspirations just to myself, I would still be stuck in my old job.
Is the transition finished?
Well, I could say that my transition is finished since I've moved into infosec. But let's be honest, I've just entered a field that focuses on life-long learning. Whatever you know today is never enough, and with new technology emerging every day, there is a constant need to hack/secure it as well.
What's next?
I'm starting the new role, so this will be my main focus, especially since I want to gain as much experience as possible, as soon as possible. I'm still going through the OffSec trainings. I aspire to become OSCE3 (by obtaining OSEP, OSWE, and OSED), so this is what I will focus on in my personal time. Although in one of my previous posts I hinted that I was starting to train for OSED, in the end, I decided to further enhance my web penetration testing skills and went for OSWA. I recently passed the exam, but I will write about it in another post. Currently, I'm preparing for OSWE.
What will happen to this blog?
I want to take this blog series and summarize it in one coherent blog post. I would like to collect all the most important bits and pieces and write some sort of guide about how to transition to infosec. Throughout my journey, I've met many people trying to get into the industry, and quite a few of them are doing this mid-career too, so I think they might find this useful. Additionally, I will continue writing here, and while these will be standalone posts, they will focus on offensive security-related subjects.
If you are still reading this, thank you for staying with me throughout this journey. Your support means a lot to me. And if you also go through a similar journey of your own, don't be afraid to reach out to me or others in the field - most of us are a friendly bunch!
Mid-career Traisition to Infosec #0x06
I got my OSCP! :)
If you have read any of my previous posts, you know that it's been a long road, but after more than a year of training and preparation, I finally manned up to schedule the exam for the 11th of March 2023. Thanks to the Internet, I had no idea what to expect - some people say it is extremely difficult and fail, some say it is super easy and pass it in 8h. It is very subjective, depending on your experience and luck. For me, it was somewhat difficult. I haven't pwned all the machines but had enough to feel confident that I passed and finished it a few hours before the deadline. I didn't have bonus points. I don't believe in bonuses, so I didn't prepare or submit the lab report. I decided to focus on learning and applying the content instead. This doesn't mean I didn't do the exercises, though. I did all of them (which was part of my learning and applying), just didn't bother to prepare the report.
Going to the exam, I remembered what most of the OffSec student mentors were saying: the exam should not take the whole 24h. You should take your time for all the other things you normally do during the day. If you struggle with this schedule, it means that you probably need more practice. Following this advice, I decided to take it easy and, instead of thinking "I have to pass", I thought "let's see if I'm good enough, or if I need more practice".
The exam started at 5:00 am (there were no normal hours available...) so obviously, I didn't get enough sleep before jumping in. It didn't matter though, because throughout those 23:45 hours of hacking, more than half of it I spent on naps, preparing the food and eating, and of course, a few nice walks with my dog. Don't get me wrong, it was both physically and mentally exhausting, and again, to me personally it wasn't easy at all. But, having the right mindset and taking care of myself helped.
What's next on my upskill plan? Since I have the Learn Unlimited subscription at OffSec (thanks to my current employer), I will go for another training. As per my previous posts, I will try to focus on security research, so I will start with EXP-301. That being said, I also got Red Team Operator training and I think that it's going to be an interesting and very useful experience (not to mention another badge on my CV).
Mid-career Traisition to Infosec #0x05
Progress Report.
Over the last couple of months, I've been going through the Offensive Security Labs and HackTheBox, and I think I'm doing pretty ok. I don't have too much trouble with the easy and medium ones. Of course, there are those exceptions where a box is marked as easy, and you just have no idea how to approach it, but again, these are exceptions. So, I finally got the courage to schedule the OSCP exam. The exam is scheduled now for March 11th. I was trying to book it as soon as possible, but there were no free slots for the weekends, which was a prerequisite for me. That's ok, there are still plenty of boxes I can go through on HTB or OffSec labs to practice, but I've super excited and can't wait for the challenge day!
There's one more thing I wanted to mention, in the context of the transition to infosec. I've recently had an opportunity to meet and chat with Ted Harrington (the guy who wrote Hackable), and he suggested something important. He said that the moment I'm sure about what I want to do, I should go out and start talking about it publicly, let people know what I'm up to and how much I want it. I started writing this blog series almost a year ago but never published it, I was waiting for the transition to be complete. Ted is the one who encouraged me to make it public immediately. He said that this way I'm letting people know that I'm serious about it and am open to new opportunities. I was skeptical about it at first, after all, I wasn't feeling strong enough to start applying for new opportunities, but I did it. I also started showing my interest on LinkedIn a little bit more, posting some posts about my tools and whatnot. I immediately noticed the interest of people, which I wouldn't even think of in this context, which was quite encouraging to stay on track and keep pushing through my upskill plan. A couple of months after when I started being more active, I suddenly started getting some job offers in infosec! Unfortunately, all of them were more on the defensive side, and since I'm interested in offensive security, I did take up any of them. But just the fact that a guy like me, with no real-world experience in the sector, is getting infosec job offers - I was shocked but it also encouraged me even more to continue. There's a shortage of infosec talent out there, but for people like me, it's good news.
Ted's advice was so simple but so powerful that I have to pass it on. If you also try to get to infosec, don't wait for your story to be successful. Go out with anything you've got now, and build upon it. Tell people what you're up to and how you plan to achieve it. There's a high chance that someone who reads it will either get inspired by what you do or even decide to help you in achieving your goal.
Mid-career Traisition to Infosec #0x04
Progress Report.
My OSCP journey takes definitely longer than I anticipated, and due to other obligations, I didn't manage to complete it within the Learn One time frame. That being said, I had extended the lab time and and now I'm going through the remaining boxes (so far I've gone through around half of them). Not planning to extend it further and attempt the exam soon after the access ends.
Throughout the last couple of months I've made significant progress in my upskill plan, not only because of the OSCP prep work but in general in the context of infosec. Improving my sysadmin (both Linux and Windows) and network skills was very helpful. Getting into PEN-200 I thought I had all the basics covered, but the reality is that I didn't know how much I don't know. All that dump of knowledge, which with practice I converted into an actual skill, significantly boosted my confidence.
Also made progress in the plan itself. Since I finally decided to go for a combination of Security Research and pantesting (or even Red Team Operations), I've signed up for the EXP-301 Learn One. Haven't started it yet because I'm still hacking the offsec lab, but I had a quick look at the content and I absolutely love it. It is gonna be an immense effort for me (I know very little technically about this subject) and so I've decided to quickly finish the OSCP and then fully focus on OSED.
I also have an update on the roles I listed in part #002 and described a little in part #003. I've recently read an interesting book, Hackable by Ted Harrington, where he explains the difference between pentesting, vulnerability scanning and vulnerability assessment. From this source I gathered that the purpose of Pentest is to find out if you can compromise the system (find a way in, escalate privileges, pivot to other machines in the network, etc. – everything they teach us on PEN-200). Vulnerability assessment is the activity of taking a product or service (that a company offers) and trying to find a vulnerability in it, usually by white-box testing. Vulnerability scanning is a brief scan of a network and services to see if you can find something that is affected by known vulnerabilities.
It is now clearer to me that Pentest/Vulnerability Assessment are what interest me (apart from the Security Research). However, it is now two people who work in infosec (which I know personally) and have experience with pentesting, said to me that although by definition Pentesting is very interesting, in reality (or what the companies implement) it can be very boring and daunting activity. Based on the definitions of Pentesting and Vulnerability Assessment I've described in one of the previous posts, practical Pentesting is more like a Vulnerabilities Assessment in respect to the number of details you have to pay attention to and report about, but without getting into too much depth when it comes to looking for vulnerabilities in a custom software. What does this mean in practice? As a pentester you probably go through all services and report your findings, even if they don't lead to getting root access. On the other hand, if there's a custom application running there (like a company's product) and you don't find any obvious issues with it (usually by back-box testing), you move on. This unfortunately sounds to me like a typical vulnerability scan and not a proper pentest, and although it wouldn't be wise to generalize it in this context, it is definitely something to watch out for before getting into Pentesting professionally.
Now back to PEN-200 lab, still a few boxes to get through!
Mid-career Traisition to Infosec #0x03
It's been a couple of months since I've written the last post here. At this point, I'm well into the second half of my yearly PEN-200 subscription. As I've been progressing, I've also been trying to pay attention to the points I listed at the end of the previous post. It was an intense couple of months of going through the training material and hacking the PEN-200 lab boxes, and I've also had the opportunity to learn and try different areas of the offensive security, which means I think I can answer some of those questions now.
1. What different areas of offensive security are out there
Based on what I've learned so far, I wasn't that much off when I listed the offensive security areas in my previous post. But I realized a few very important things which I'll discuss below:
Pentesting is very broad, but it can be divided into many different areas of testing: web, application, system (things like Linux or Windows administration, e.g. Active Directory), IoT, network, physical, people, and probably more. I believe that working as a pentester, you need to be well-rounded in many of these areas, but from what I see there's a split between testing the IT (web, network, etc.) and social (physical, people). Let's take an external pentest of a company, assuming that you have been given some initial info (e.g. website URL), you need to be able to find your way around the network and web to properly enumerate the target and hopefully get a foothold. Sometimes, however, you can't get through the web, but you see there are other services running on that host, so you enumerate those and find some exploits which you can use to get in. Imagine then that the exploit is just a PoC (proof of concept) and it is for a binary application that has a BOF (Buffer Overflow) vulnerability and is running on Windows, you need to be able to modify the exploit, so you need to know some binary exploitation (reverse engineering and exploit development) aspects. I could continue giving you examples for a while, but I think you get the point - pentesting could require from you to be familiar with one are of offensive security, but also all of them (and the latter is true in most of the cases).
All other areas are more of specializations (e.g. web pentesting, appsec, reverse engineering, etc.), which you can utilize in pentesting, or as standalone activities, e.g. if you are a security researcher with focus on finding 0-day vulnerabilities, you need to master the reverse engineering and some exploit development.
2. Which one of them do I like the most.
Since the split between different areas is not clear, and often they overlap with each other, also the answer to this question won't be clear. That being said, I've been having a great time going through the PEN-200 boxes, in some cases tearing them apart like there were small cans of tuna, in other cases spending days banging my head against the wall and not getting anywhere, but the later are the ones that teach me the most. However, I really got into binary exploitation and I absolutely love it.
3. What are the roles associated with that particular area.
I think the most adequate role associated to this area is Security Researcher. Basically, it is someone who is looking at the system and tries to find vulnerabilities in it. It sounds just like a pentester, you may be thinking, but it actually is not. The difference is that a pentester checks if it is possible to get into your system and by what means - e.g. they check if a given service is vulnerable to something or misconfigured, and if that's the case they try to exploit it. They test many services mostly in a black-box approach, and if they don't find anything, they move on. Security Researcher on the other hand is somewhat much more focused role. They pick one system, which doesn't even need to be currently in use by a customer, they look at the code (if it is a white-box type) or tear it apart (throw a bunch of weird input at it or reverse engineering it) and try to find vulnerabilities that could be exploited. In some cases, this leads to finding new vulnerabilities that aren't known, called 0-days. Every new vulnerability gets a new CVE number, which for you as a hacker is a type of trophy - what a way to build a portfolio! :)
4. What are the next steps in terms of upskilling in the area of my choice.
At this stage of my upskilling, I think I will start leaning towards a Security Researcher role. I very much like the overall idea of researching new vulnerabilities in some software and, what's also very important, I'm a software guy so should have no problem finding my way around the code. There are many different types of security research I could focus on, though, even within the software itself. For instance, I could focus on web, but also go more for binary applications. Based on what I have gotten to try so far, mainly due to my OSCP training, I can tell you that I really got into binary exploitation. There's something very appealing to me in finding a crash in an application, whether it is on Linux or Windows, which then leads to binary exploitation, e.g. exploiting the buffer overflow. So far I've had a blast attaching a debugger to that thing and going through the assembly instructions one by one figuring out what the developer wanted to do and how I can abuse it. The only trouble with that is my very limited knowledge and lack of any experience in this area. I know it's software, but I really have idea about many other aspects, e.g. reverse engineering. That being said, I've had tried enough of it to know that I want to go in this direction. I've decided to proceed with this in the same way as I did when figuring out how to start with offensive security: done some research about it and, since I want to get my feet wet as soon as possible and start practicing, I think the best approach for me is to signup for EXP-301 and get OSED (Offensive Security Exploit Development) certificate.
5. What other areas are relevant, which it is worth to explore in this context.
Reviewing EXP-301 made me realize that going for it not only will help me develop my skills towards security research and reverse engineering, but also get some foundation in the area of exploit development.
Knowing myself, I'm very much drown into the things that are difficult (and Security Research + Reverse Engineering + Exploit Development is one of those things) to the point that it clouds my judgment, and I'm no longer sure whether I like it because I like the process of doing it, or just because it's so damn hard and the reward is great. Nevertheless, I think I will strive to become a well-rounded pentester and specialize in reverse engineering and exploit development. Combining my old passion to software development with the new one to offensive security seems like a done deal, no need to look for more, I'm hooked!
Mid-career Traisition to Infosec #0x02
Every planning activity I like to start by taking a step back, trying to get the big picture, and defining in one sentence: what is that I want to achieve exactly. So, let's see.
"I want to shift my career from whatever I'm currently doing to something that is offensive security related."
That's at a pretty high level, but I think I could refine it a little by adding:
"Preferably, I would like this to be also related to software engineering since it's my background, and also I just happen to like it."
Ok, so that's more or less my goal. It is still high level, I know, but it's good enough for now.
Next, I will try to recap where I stand in achieving this goal. As I already mentioned, my background is in software engineering, so I'm not exactly an IT beginner. But what does that mean exactly? Again, let's try to refine it a little.
I'm a software engineer with 15 years of experience, 5 of which I spent on actual coding (mainly in C++ and Java) and the remaining 10 years working as a TPM. It is also worth noting that I spent the last few years running the same project using the same development stack. Although these were multiple projects, the software and most of its functionality are identical. So, although I picked up some software engineering, project management, and leadership skills, I'm not up to date with the latest tech. Of course, it's not like I was doing nothing all those years. Over time I picked up many different programming languages and frameworks, but it was primarily out of curiosity and by no means I'm an expert or even proficient enough in any of them.
Knowing more or less what I want and having a clear idea of where I'm currently at in terms of skills that could help in achieving my goal, let's try to narrow down the roles (or areas) of the offensive security which I could focus on. At this point, it would be helpful to have two lists, one in order of things that I like the most and the other by the least effort I think I would have to make to get good at (knowing my strengths and weaknesses).
Things I think I'd like to do:
1. Pentesting
1. Red Teaming
1. Exploit Development
1. Reverse Engineering
1. Security Researching
1. Application Security
I didn't get the numbering wrong; it is all exciting. Also, if you try to read the definitions or job descriptions of some of those roles/areas, they are super confusing; they often overlap with each other or, in many cases, at least complement one another - difficult to decide which one I like the most. For instance, regarding the difference between Pentesting and Red Teaming, I dare you to get a single, concise description from more than two people. The same goes for Security Researching and Reverse Engineering.
Not a good start, but let's continue. Let's now try to map this list to my skills and experience, and see if I can get a more precise outcome.
Things I think I'd learn quickly:
1. Pentesting
I think I'm a well-rounded IT professional, knowing some sysadmin stuff, networking, scripting, and software development.
2. Application security
since I have decent software engineering experience, I think I would "only" need to pick up some infosec practices.
3. Exploit Development
although different from AppSec, I think I could do a decent job developing something - I like and know how to code after all. I would "only" need to pick up the other bits and pieces (e.g., reverse engineering and deep dive into OS/kernel internals).
4. Reversing Engineering
I don't think anyone is doing just that, so I'd combine it with Exploit Development (of course, I could be completely wrong).
5. Security Researching
well, I'd need to be good in all of the above, wouldn't I?
6. Red Teaming
just the fact that no two people can give me a concise definition means that either I'm asking the wrong people, or it is another role that requires knowledge and experience in all of the above.
Writing those two lists down already made me realize how little I know about this field. Also, I'm almost 100% sure there are many more areas and roles in offensive security which I don't know about, yet. It brings me to only one conclusion, if I'm serious about all this, I won't be able to do it on my own. I need to get some guidance and a decent education. Time to split the plan into two: upskill and transition. Let's start with the upskill plan.
Upskill Plan
How do I get up to speed with all offsec-related stuff? Quick Google search, and I see a few things:
- Almost no one is considering getting a degree unless it is someone 17 years old who wants to get a degree anyway (and even then, people recommend them to get a regular CS degree and pivot later to infosec)
- Certs in infosec are huge. I initially thought it was because maybe it was just cool to have them. But diving deeper into the subject, infosec is one of few disciplines where certifications are also significant for employers. I know what you're thinking: these are for the defensive side of infosec. I remember thinking that, but I could not be more wrong.
So, it looks like the certs are very important. In fact, in the offensive security field they are sometimes more critical than a relevant degree.
In the future, I will dive deep to understand why, and I think I have an answer (it will be in another post), but for now, let's go back to building the upskill plan.
Certification
There are many to choose from, but doing some research, you can divide them into a couple of categories:
- easy, entry-level (e.g., eJPT or CEH)
- advanced (e.g. eCPPT)
- industry-standard, shiny "bling bling" - the stuff that people make a tattoo of on their back (e.g., OSCP) That tattoo thing is a joke, of course (or is it?), but you get the point.
Before I continue, a few words of caution. First, there are many more certification options, but you should probably google them and see what's best for you. Second, whatever I write next is subjective and applies to my situation only. I'm not saying that my approach was the best, what I'm saying is that it was the best for me. I will describe my thought process while choosing my first cert, and I hope it will help you make your own decision, too.
At this point, I'm still focused on learning as much as possible, not on what certifications to put on my CV. So, as you can imagine, I initially thought of signing up for the easiest one and climbing my way up to get the holy grail - OSCP. However, while I was researching about it, I noticed that all those certification bodies also offer very comprehensive study and training plans. It led me to shift my approach by 180°, and instead of looking at the certs in the order from the easiest, I turned the list upside down and started with the most extensive and difficult one. My only guideline was the list of prerequisites a student should meet before signing up.
So, since I knew I could afford it and met all prerequisites, I decided to go for OSCP. Of course, I had to make a leap of faith that the requirements were accurate and that the training materials were good enough to prepare and guide me from 0 to hero, but that was it. Next thing I know, I'm a Learn One subscriber at Offensive Security - OSCP baby! Although I signed up for it before deciding to shift to offensive security, I would do the same if I had to do it again.
I also hope that this training will give me an overall idea about what other offsec areas are out there and where to go next in terms of further education/certification. Ideally, it will enable me to kick off the transition phase by either slowly shifting internally within my organization, helping find a part-time internship, or even joining a Bug Bounty program.
To summarize, apart from all the research I've done on the subject, it looks like the actual first step I should make is to complete my OSCP, and I should also use this opportunity to answer the following questions as I go through it:
1. What different areas of offensive security are out there
2. Which one of them do I like the most
3. What are the roles associated with that particular area
4. What are the next steps in terms of upskilling in the area of my choice
5. What other relevant areas are worth exploring
That's pretty much the plan I have. Note that everything I discuss in this post is related to the upskill plan. The transition, however, is an entirely different story. I already know that it is not going to be easy and a change will have an impact on both my personal and professional life. So, I think that the best thing I can do is to look at it critically and approach it the same way as the upskill plan, hopefully with a little more knowledge about the industry. I will write about it in the future. For the time being, I'll focus on hacking the OSCP!
Mid-career Traisition to Infosec #0x01
If ten years ago you told me that in ten years I would be thinking of changing my career, I would say that you've no idea what you're talking about. After all, I've finally got into a place I've always dreamt of: a good and well-paid job in one of the world's top organizations in the space sector. Given that it took me a couple of years to get there, my mind was 100% set about it, and I was pretty sure I knew what I wanted to do until retirement.
Without getting into the details of why I decided to change (at least not at this time), I find myself writing this blog post ten years later. I think it is safe to say that the first lesson I've learned is to never say never.
But before I get into the subject of the 'mid-career transition to infosec' and tell you what my grand plan is, there are a couple of things I wanted to get out of the way.
First of all, a quick disclaimer - I haven't transitioned yet. In fact, it's been only a few months since I've decided and painted my new target, and only now I'm finally starting to have an idea (although still in an early draft) of what the transition plan will look like.
On the other hand, it's not like I'm starting just now. I'm halfway through my OSCP (which I will describe in future posts), and this post series (or at least the first couple of posts) is written partially based on the experience I have already gained.
Another thing I want to mention upfront is that I'm going to skip a few initial steps of this adventure. Those are: why did I choose infosec (offensive security in particular), what was my thought process there, what else was I considering, etc.; that's because it doesn't bring much to this conversation and, since it's a longer story to tell, I think it deserves a dedicated post.
Writing a blog is one of the steps on my transition plan and there are several reasons for that. For one, writing things down helps visualize them and I think that visualizing your goal is one of the most critical steps in achieving it. Second, it makes me go through my plan multiple times and forces me to think about whether it makes sense, what else I should think of doing, and what I should avoid doing. Future posts will summarize my progress in this endeavor, which should help me stay in check and give me yet another opportunity to review the next steps and the overall direction I'm going towards. I will approach it more like a diary where I can put my thoughts as I progress. I also don't think I will publish it immediately, but only once I make an actual progress, feel more confident that I can achieve my goals and see that what I do actually works.
So far in my journey I haven't encountered many people who have done what I'm trying to do, but that doesn't mean there are none. Although most of the stories you hear are about getting into infosec straight after university, I'm sure many people are trying (or would like) to switch their careers in their 30s or even later. If you are one of those folks, I hope this blog series will come in handy even if it doesn't provide a clear path through to reach your goal (everyone's way will look differently) - at least you know that you're not alone (and if you reach out, I will know I'm not alone either).
Lastly, one of the things I've learned about pentesting over the last few months is that there's this rule which says, "If you didn't write it down, it didn't happened." Maybe it works the other way, too: "if I write it down, it will happen."