When I took my OSCP exam, I had less than two years of professional experience in the security space. While I did some of my own learning in terms of webapp testing, hackthebox scenarios, and the PWK (Pentesting with Kali) material, it doesn’t replace working alongside your peers on a security team. I did, and still do, consider myself incredibly fortunate to have even landed a security job with zero experience, but I noticed that a lot of other OSCP/PWK students are not so lucky.
Many OSCP/PWK students take the exam because they want to break into security or penetration testing from zero-to-hero. Sure you have seasoned professionals that also take the OSCP to cement their knowledge, but given it’s an “entry-level” and “basic” certification it caters to newer security folks. This, however, causes a large problem for those who don’t want to be really proficient in what they do whether it be penetration testing or some other security-related function.
So that’s the focus here:
- What you miss from the PWK material
- What jumping-off points there will be for you
You’re going to lack system hardening experience
On a scale of 1-10 (10 being the hardest), it’s a “1” to scrutinize someone else’s security as an attacker because you never have to set it up. If you’re on this site you’ve probably noticed it’s a WordPress site running somewhere in the cloud, but the real work is making sure I have this publicly facing in a way that it can’t become compromised. This is where understanding basic system hardening and application security comes into place.
When it comes to gaining experience, you just need to do it.
- Build an application, even if it’s a WordPress site you configure, and deploy it somewhere
- Preferably offline in a local VM for now…
- Thread model it!
- Pick a methodology such as STRIDE and thread model your setup
- Identify gaps in the architecture, application, or anything else that could make it susceptible to attack
- Attack it!
- That’s right, attack your own services as if you’ve never seen them before
- Record your findings like any other test
- Patch it!
- Patch your system and application. Use industry guidelines like NIST for hardening guidelines as well
You’re going to lack modern DevOps/DevSecOps practices
While you may still come across them, traditional LAMP deployments are going away. Just like how cloud-based services are becoming the norm, application deployment and orchestration have changed to container-based workloads and it’s important to know how they can also be abused. You may have heard about Docker or LXD, but what about Kubernetes or AWS EKS?
Working with containerized workloads has its own set of challenges inherently because of how applications are deployed and scaled within a cloud environment. Suddenly, getting “root” on a server isn’t that big of a deal to install a crypto-miner because the compromised pod is one of thousands of pods. The question becomes, “how do you further abuse a container to compromise more of the cluster or network?”
- Become familiar with Docker, Kubernetes, etc.
- Docker is free, minikube is free – take advantage of it
- Kubernetes Goat is a great jumping-off point because it provides a misconfigured cluster for you to walk through
- Sometimes it’s not “testing”, but be prepared to audit Terraform (by HashiCorp) or kuberntes service files for misconfigurations
- If you break something in the Kubernetes Goat, look at its “scenario” files to understand “why”
You’re going to lack cloud-based experience
Lots of modern companies no longer “on-prem” solutions backed by physical data centers that the companies own. Sure, lots of companies have traditional networks, but there are gobs of companies using IaaS (Infrastructure as a Service)/Cloud providers to run their workload needs. I’m talking about AWS (Amazon Web Service), GCP (Google Cloud Platform), and Azure. So, what’s the difference? The big difference in my experience is that there are lots of cloud-specific technologies at use that can’t always be abused in the same way. Let’s take a few technologies in AWS for example.
- Amazon’s S3 storage solution pops up in the news due to misconfigurations. A simple “bucket”/”folder” to store data can divulge so much information if misconfigured properly or exposed to the public.
- IAM (Identity Access Manager) allows resources to speak with each other if they have the assigned policy. Would you know how a compromised EC2 instance can interact with a Lambda if it came up?
- RDS (Relational Database Service) serves up a MySQL, PostgreSQL, or Aurora instance with its own configurations. Would you know how to audit and evaluate it?
- Would you know how to deploy your own AWS resources in the cloud?
- Pick a cloud provider, learn their services
- Which one doesn’t matter because most offer the same basics (computing, storage, networking) so figure out what services are important and how they translate to other providers.
- Example: A physical server is AWS’s EC2 which is also GCP’s Compute Engine
- Become familiar with common misconfigurations and attack vectors
- HackTricks has a wonderful set of commands, shortcuts, etc to help you become familiar with cloud environments from an attacker’s perspective.
- Take a course and deploy something!
- The caveat here is that this option can be incredibly costly. There are plenty of horror stories on Reddit about AWS bills – they’re all true so be careful if you decide to deploy something to the cloud.
Finally, you’re going to lack a specialization
The OSCP isn’t an end-goal, it’s the beginning of a new adversarial mindset and should be treated as such. The curiosity, dedication, and persistence can be applied to anything in the security space so it’s important to think about where you might want to go after your OSCP exam. Here are some questions I wish someone asked me before making the jump into professional penetration testing?
- Is this something you want to do day after day for a living or is this just for fun?
- Do you want to be a penetration tester?
- If you already work in security, is this a transition you’re willing to make for your career?
- What comes after pentesting?
- Have you thought about specializing in an area of pentesting?
- Web? Network? Reverse Engineering? Forensics? Mobile? Automotive? Physical security?
- Do you want to do consulting work or be an in-house security expert for a company?
- If consulting, are you prepared to jump from client to client?
Another question you may want to consider is,
“how do I take the lessons learned from my OSCP experience and apply them to my current role?”
Chances are that your hands-on experience will take you far in other areas of security or software. “Thinking outside the box” in a OSCP/PWK-like manner isn’t something most professionals get a chance to do and it’s a great opportunity to apply yourself when it comes to other security jobs like:
- Application Security
- How can I abuse this application for my own purposes?
- Security Architecture
- How do I design an environment to minimize what an attacker could do?
- Security Compliance and Auditing
- Given a policy requirement, how effective will this control be in our own environment?
- Security Engineering
- What tool or automation can I build to simulate an attacker or further the needs of the organization?
Wrapping up and closing thoughts
During your OSCP journey, always question “what’s next” if you’re using this as a chance to break into security. Security is not only difficult, but its breadth is massive in terms of what you can learn and be exposed to. Always be hungry for what’s next, be open-minded, and prepared to roll with the punches.