It’s been a hot minute since my last post, I know
This post will be broken up into three parts:
* a brief synopsis of how I got here from where I was
* What a SysAdmin (in my opinion) needs to do in order to be competitive as a pentester.
* An inside look at an actual pentesting scenario
To quickly summarise my exposure to IT before pivoting to Sec…
…I have close to 10 years under my belt - which may SEEM like a lot, however most of the time was spent on Helpdesk, incident management and pressing buttons in a sequence to patch large scale environments. Only 3 of those years were spent accumulating hard technical skills, starting when someone took a chance by giving me an opportunity to land in what I would actually call my first real job in IT as a Network Technician. This job, after 7 years finally ignited my passion for tech, up until then it was “just a job” and I was always looking for something better. (Thank you Michael AKA BIG MICK)
During those three years I quickly progressed to being a System Engineer at another company, and shortly after was contracted out to do SysAdmin work at an Airport, where I learnt A LOT.
I genuinely believe that the reason I progressed so fast was because I was studying for my OSCP alongside this work period, this is a whole separate point of discussion, and I already have a writeup HERE which includes a more detailed breakdown of all the stuff I just rambled on about.
So let’s begin
Towards the tail end of my OSCP attempts, I could feel that it would not be long until I passed. That, coupled with dissatisfaction with my current employer led me to start scoping out Junior Security roles.
Now this is where it gets interesting.
There seems to be some perpetual cycle where many places do not want to hire Juniors, as it costs money to dedicate seniors to help them NOT be juniors.
But no one wants to employ juniors…
so the market is therefore starved for seniors…
So the only option is to hire juniors…
But there are not enough seniors to train the juniors…
And thus I realised that to get into this industry, it was going to take more than simply handing out CV’s that said “ME ALMOST HAVE OSCP, ME KNOW HOW 2 HAK PLS HIRE ME” And so I got in touch with a recruiter who is an absolute legend of a bloke: Paul from the Decipher Bureau. Although Paul did not get me my first job in Sec directly I would not have had a chance to work for the company I am at now if it wasn’t for this guy.
Initially, as I did not yet have my OSCP, getting interviews was tough for the recruiter, something he was honest about. Nevertheless he did try, but it wasn’t until I finally passed that he was able to get an interview at a rather large company. By this time I also had my blog going (mainly for the purpose of submitting SLAE32 assignments) which also made me slightly competitive as a junior candidate. I completed 2 rounds successfully (according to feedback was at offer stage) however due to a merger/covid, recruitment (for Juniors) was frozen. The fact I was able to secure an interview in the first place was confidence-boosting however, and it also gave me an opportunity to be invited to the sectalks slack group - something I was not even aware existed.
During the 8 or so months it took to hear back from the larger company, I continued to work on my blog, upskill via any online resource I could find (will link at end of this post), engage actively with the community via entering study groups and posting my blogs, and participating in CTFs. All of these steps were crucial to giving me the exposure, inside knowledge, skills, and connections needed to both secure and pass the interview for my first pentesting job. Funnily enough around the same time this opportunity came up, the ORIGINAL company now fully merged requested a final interview, which I felt I did quite well at however they could not go through with the offer due to my lack of experience(?)
As things are meant to be however, the company I work for now was more than happy to bring me onboard for a rather large and complex long term project after just one interview. Now, I think it is important to consider that it really was not just the hours worth of time that I put in during this one interview, this was simply the final piece of 8 months of hard, focused work. I cannot stress the importance of community engagement enough - even if you lurk in any chats or forums you can find - you WILL learn.
cp /home/General_IT_person/skillset/* > /home/pentester/
This part is directly aimed at traditional SysAdmins who want to move into Offensive Security at a competitive level. Step 1: Unless you are already tearing through HTB or have years of CTF experience under your belt, you have to start studying for your OSCP right now, yes it is an entry level certificate, but it is entry level to one of the hardest tech jobs out there, and you need the experience of the 24 hour exam to help train your mind.
The rest: While we have our own skillset and knowledge of networks, business needs/stakeholder engagement as well as core AD knowledge - we are at a massive disadvantage, and that is: We are not devs, and as such we do not possess the mindset of a dev, which let me tell you a seasoned dev will navigate through problems faster than you can say “let me google it”. They are professionals at being in situations where they do not know/understand the deeper machinations of a technology, and bringing themselves up to speed in a short amount of time - it’s kinda their job. Many times I have worked with colleagues who think that is acceptable to solve an issue by running someone else’s command/code or following the steps they found on a forum.
This leads to broken and insecure environments. It may expand your repertoire of “fixes”, but not your knowledge. When you understand how things work, you can break/subvert/navigate around them. This also leads me to my next point, which will be controversial among some people…
You have a LOT of catching up to do (I am reminded of my skillgap every day), and being able to fix broken exploits à la OSCP is simply not good enough. An example why will be provided in the last section of the post. I recognised this early on and put myself through a beginners Python course before starting online coding challenges and writing tools from Black Hat Python. In addition to this I took a course on Linux assembly which catapulted my understanding of program logic at a deeper level. From here I have dabbled in various other languages to the point I can pick up almost any language and slowly build something adhoc.
In addition to the above, you are going to have to become comfortable with web-technology to the point you know enough to learn on the job. I have never been to Uni or done any real IT course so for me this took a while, I started by creating my own web server, which I then turned into a Vulnhub submission. This taught me how each component in a stack works, it’s purpose, how they interact, and how they work.
Next I targeted learning specific attacks, I would spin up DVWA and use online challenges to go hard against XSS, SQLi etc until I not only knew how to trigger them but could read existing code and know WHY it worked and WHERE to inject. This is a necessity IMO. The last thing I did ties both this and the coding paragraph together: I wrote a very, very basic exploit in Python to launch against DVWA. (As a side note I DID also begin the AWAE course, however after stopping for the third time to do a deep dive into a particular subject I decided that while the short amount I had worked through was invaluable, I would revisit it at a later stage)
This might seem like a lot of work however once you get the ball rolling things start falling into place faster and faster, just keep going. Do not look at this as one entire process, look at it as completing levels until you reach the boss.
An example of why all this is important:
SO after having this wall of text peer reviewed a couple of times it became very clear that in our modern-day world of instant gratification and short-attention spans, this post was too long, as such, the final point (An inside look at an actual pentesting scenario) is in a separate post HERE