So you passed OSCP – Now What?
You’ve decided that you want to get into Penetration Testing. You’ve taken and passed your OSCP, and you’re wondering where to take your skills from here. The OSCP course is fantastic and does a great job teaching a lot of Penetration Testing methods and mindsets but there is still much to learn. Here are some things I think you should focus on if you plan on doing this as a job full time.
Harness your Social Engineering
One of the most valuable weapons a Pen Tester or Red Teamer can have is effective social engineering skills. Many people discount Social Engineering because they think it’s easy to trick users. Yesteryear many organizations hosted everything in their server room or datacenter, which meant services they exposed to the internet were likely linked to their production trusted network. Cloud services have become so cheap and attractive that a good chunk of businesses expose little (to anything) to the internet from their office network. This reduced attack surface means that you’ll often need to resort to social engineering a user to get your foothold.
In many cases, it may not be difficult to trick a user to execute a file however there are correct ways and incorrect ways of performing this task.
Ultimately the goals of your Social Engineering campaign are :
- Manipulate a user into executing your payload
- Ensure the user does not report the incident as suspicious
- Payload does not trigger any defences such as Antivirus or Intrusion Detection Systems
It’s not uncommon for someone to click on a macro-enabled MS Word document only to realize that they’ve been conned. Even though their computer doesn’t display any odd symptoms, they may still report that incident to IT and if the Blue Team becomes aware then your campaign might be hosed. A successful SE campaign will ensure that the user does not inform IT. This can be accomplished any number of ways but you don’t get many chances to get this part right. If you alert employees or they become suspicious then your assessment might be finished before you even get started.
Command And Control Infrastructure
Meterpreter shells are great, however they don’t scale well. In the “real world” infected machines don’t dial back directly to the attackers computer, but rather a Command and Control Infrastructure (C2). While you can certainly conduct Pen Tests and Red Team assessments without a C2, almost any sophisticated engagement will require a C2 with some sort of beaconing system.
There are a number of options to choose from, however the de-facto standard for C2 in industry is Cobalt Strike. The Cobalt Strike website has great video resources on understanding how to set up an effective infrastructure for C2 but I’ll summarize here.
There are any number of ways to set up your infrastructure, however the following is a guideline for a longer term engagement.
- Phishing / Staging Server – Servers used to launch phishing campaigns and host your payloads. These should be thought as expendable as they will likely be burned at some point during your engagement.
- Call Back / Command Servers – The servers that you will work off to issue commands to the infected machines. These are highly prized and should be extremely well secured and should only accept connections from redirector servers or specific IP addresses.
- Redirector Servers – Once you have an implant (or hopefully multiple implants) in an organization it needs to phone home. You don’t want your target network ever communicating with your actual Call Back / Command Servers. If the Blue Team discovers where your Call Back servers are then you’re pooched. Redirector Servers will redirect the traffic from your targeted network to your call back servers to help keep your network unknown from your target.
When creating your C2 infrastructure you need to ensure that your hardening the boxes as much as possible. Imagine exfiltrating a clients information and then having another actor compromise your C2? That would spell disaster. In addition to the information above you should be sure to host your servers in as many different geographic locations / VPS’s as money will allow. There is a lot that can be written about C2 servers, but this is a very quick primer.
Hone your stealth
OSCP does a great job introducing students to antivirus evasion, and there are a litany of good tutorials on this subject. That is, however, only one defence system you’ll need to evade during an engagement. You’ll also likely have to contend with intrusion detection systems, egress firewall inspection, data loss prevention systems etc. When you were doing your OSCP course you may not have been so concerned with how “loud” your actions were, but you’ll need to start considering that. Just as the Kali mantra goes, “The quieter you become, the more you can hear”.
Throughout your engagement you should be as stealthy as possible. The following are some considerations.
- Initial entry point – making sure you don’t alarm systems, or the user you may have targetted
- Lateral Movement – WMI is more stealthy than PSExec and PowerShell is more logging friendly than ever before
- You should aim to do as much work in memory as possible and avoid writing to disk wherever possible
- Learning to build your own tools can be invaluable as it will allow you to make low-level API calls for whatever system you’re working on. The added benefit is that it’s unlikely your code will be recognized by any AV thus far which will help with evasion.
A Shift in Mental Attitude
When you’re working on a machine, or lab, that you know is vulnerable you know it’s vulnerable. Because you have the knowledge that the machine definitely has a security flaw you can sit there and poke at it for hours because you know that eventually you can crack the box. This is not the case in real world scenarios.
The reality is that, unlike in a lab setting, you don’t know that the machine you’re working on has an entry point, escalation method, etc. You could pour hours into a machine and make no progress and you may question yourself. The “Try Harder” mantra is valuable, but not every box has an entry point and it’s important to realize this. Enumerate and research and enumerate some more, but it’s important to recognize that not every production box is hackable. The mindset can be very defeating but it’s important to learn to deal with that emotion. On the flip side, it’s important not to give up because “I don’t know if I can crack this machine” or “I don’t know if there’s a method for exploitation”. You’ve got to keep plugging away knowing that everything you do on that particular machine / engagement / client may come up with no results.
Always be Learning
The last point is that you should always be learning. If you want a career in IT and Information Security you need to prepare to be a perpetual student. Luckily there are a massive number of amazing resources out there to help you learn and keep your skills sharp.
Some of my favourites are :
- PentesterLab.com (great for advanced web application hacking)
I hope this was a useful article and helps shed some light as what lies next in your pentesting careers.