#offensive security

Man, I just realised I got asks heh. God knows how long ago this is from, so: so sorry whoever asked this, I wasn't ignoring you! I'm 41 so of an age where you could spend your teen years hacking and it was chalked up to youthful hijinks and teenage high-spirits (even got a visit from the police and a slap on the wrist haha), but those days are long gone now. It's serious business. What I would recommend is

a) get OSCP (offensive security certified practitioner) certified. it's a well respected cert in the industry. Do not under any circumstance get CEH certified, it's looked on as a negative.

b) attend cons and meet people. meet everyone, but in particular, try and meet women already in the industry, they can help you, offer advice, there are often women only meetups etc. infosec can often suffer from testosterone poisoning so i kinda feel like the support might be valuable. Inevitably you will meet elitist jerks, but there are also a lot of people who want to help beginners.

c) start working on your own projects. this might be building a home lab, completing hackthebox ctf challenges etc. start researching areas that interest you.

I'll be honest, just having the certification isn't enough. When I'm interviewing people I look for passion for the topic and drive for self-directed learning, both of which you need to succeed in this field. I also look for "the attacker mindset" and the ability to solve problems on the fly.

So I got the email every OSCP student wants this morning- I passed OSCP on my first attempt.

In the name of tradition, I’m just writing this to document my thoughts, experiences and my preparation up until enrollment. :)

Background

I’m self-taught in every aspect of IT that I know- from basic networking concepts to programming- and have been doing CTFs on sites such as HackTheBox and VulnHub.

Prior to OSCP, the only professional experience in pentesting I had was a 3 month-long apprenticeship with a local company; even there I didn’t get any real exposure to actual pentesting (thus why it was only 3 months.) 

I don’t have a degree yet either- I’m currently in my first year of Cyber Security (BSc) with Open University.

Preparation

I first heard of OSCP last year when I tried a physical university- there was an ethical hacking society there that were pretty much obsessed with the certification. After hearing of it’s alleged difficulty and reputation in the industry I looked into it and then hopped on the band wagon. I definitely wanted to be an OSCP.

I’d say that I had around 1 and a half years of CTF experience before enrolling, a lot of those machines being based off a list of OSCP-like VMs. I also had experience with buffer overflow at this point (had already hacked Brainpan and completed a majority of the challenges on SmashTheTux.)

I pretty much just decided to go for it one day, unsure of if I was ready or not.

The Course

I opted for 90 days lab time and spent nearly all day everyday hacking the lab machines in that time (probably missed 1-2 weeks altogether). In that time I got almost all the public network apart from dependent machines and two of the hard ones. A few machines from Dev and Admin too.

I barely even looked at the PDF until I went over using Immunity Debugger for buffer overflow but I think it depends on where your knowledge stands as to whether taking the time to do the PDF exercises is worth it or not. Like I said, before enrollment I’d already rooted a fair few machines on other platforms.

The Exam

5AM on Saturday the 17th of October was my exam start time. I had no issues with the proctoring software- lucky considering the proctoring software allegedly has poor Linux support (my OS is Ubuntu.) I thought starting earlier was a good idea as it meant -in the event of things going wrong- that I wouldn’t have to stay up a full extra night. I could have admitted defeat and went to sleep at 5. xD

While I did pass, I do feel the early start wasn’t a wise move: I was extremely tired after a night of tossing and turning, feeling my eyes starting to burn by 12 noon.

My sleep deprivation caused me to make a fair few silly mistakes I wouldn’t have otherwise made too- the buffer overflow took me 2-3 hours all because I didn’t notice I’d tried to set PORT instead of LPORT in my msfvenom payload!

By 8pm the following night I had 60 points under my belt- rooting the 10 point was all I had left to do before I had enough points to pass. By 10pm I had the 10 point- again due to my tiredness I hadn’t been logically trying everything to troubleshoot why things weren’t working as intended (don’t wanna give anything away about any of the exam machines.)

At this point I was exhausted. Happy with calling it a night, I proceeded to go back and take the necessary screenshots for my report the next day. This took a while- it was 1-2am before I told the proctor I was done and they ended the exam.

Ecstatic that I was halfway to passing, I went to bed eagerly- I still had a report to write.

The Report

The report writing is very tedious and -frankly- not what you want to do after the hacking part of the exam. I was still pretty tired from the day before and I just wanted to get it done.

I didn’t write the best report- I missed out some command output accidentally and had a nightmare formatting the report (this is why sleep matters!) but I had it finished and submitted in 8 hours.

Results

I got the great news today that I’ve passed- I’m now an OSCP! I’m very happy with this after spending so long preparing for it.

What’s Next?

I think I’m going to spend the next three years I’m at university getting deeper into exploit and malware development, maybe privilege escalation techniques too: I have a strong interest in these areas. I’ll probably do the odd CTF now and again just to keep my skill sharp in that area too.

Thoughts and Advice

Now I’m no sort of expert in the field yet; I definitely advice people to spend a fair bit of time on OSCP prep before enrolling.

Google OSCP-like VMs and go through them. Please: do not look at hints. I think this is a vital component to OSCP- the ability to be independent. You won’t have anyone to go to for advice in a real pentest or the exam, after all.

Looking at buffer-overflow prior to the exam is also an idea: it means the concepts of registers, x86 vs x64 and shellcode aren’t completely foreign to you. Like I said above- Brainpan and SmashTheTux are pretty good VMs for this.

I definitely think you should try to get to a point where you don’t need the course PDF beforehand so you can focus all your energy on the labs.

Doing this course has honestly been one of the most difficult things I’ve done- not because the machines themselves are difficult; it’s the pressure (especially if you paid for it out of savings- £1100 is ALOT of money to me!) and the time it takes. It tires you out physically and mentally.

Officially an OSCP! 😎

Another Windows machine down; again, I can’t say this was particularly difficult.

It has a rating of medium but I’m unsure why if I’m honest...Perhaps there’s more resources out on the two attack vectors?

It took me a little longer than I’m happy with but I’m afraid web apps are where I lack at the moment- I spent a considerable amount of time checking for SQL injection, XML-RPC weaknesses and it also doesn’t help that my Kali Linux VM can’t connect to Ruby servers for downloading Ruby libraries (or gems)- after spending some time attempting to solve that issue I simply hopped over to my host to get the bastard rooted. ;P

So, my enum script (since made amendments to this: it wasn’t picking up some files it should have such as robots.txt) and then manual checks:

There are 3 logon forms- one to login, one to register and one for password resets- and some misc web app config files such as CHANGELOG.txt and robots.txt.

CHANGELOG reveals that Drupal is running on version 7.54 while robots shows an array of disallowed URLs.

Firstly, I performed some checks on the present forms and I did discover the existence of user ‘admin’ via the password reset form: existing users can be enumerated as the server will respond with username/email not recognized for non-existent usernames and an error on sending a reset email to valid usernames.

I played around with both this and the login form for a while- tried some classic SQL injection cases and alike; unfortunately for us, we’re temporarily locked out if we enter the incorrect password 5 times.

Now this is a shame for the brute force queen... My first thought with login forms is brute force if there doesn’t seem to be any other vectors present. Taking this as a sign that I was barking up the wrong tree, I moved on to instead seeing if there were any other users on the server by utilizing a username brute force script I have in Bash on the password reset form while I looked around a bit more.

It was around here I ran into drupwn- a Drupal web API enumeration tool written in Python. It’s a bit rubbish to be honest as it has a tendency to hang and requires you to manually stop the running process; it did reveal that my enum script had missed robots.txt and CHANGELOG in it’s execution (since been amended.)

It also revealed the version of Drupal in-use; the script probably just looked through CHANGELOG and grabbed the mentioned version.

I did look into these files but robots had alot of entries that -as an inexperienced web app hacker- would have taken me hours to manually test while CHANGELOG revealed nothing but the version of Drupal in-use.

With the version of Drupal identified, however, this did mean that searching for public exploits was a great deal easier. I took to searchsploit -a native Kali Linux tool- and discovered several Drupal exploits:

Here we see mentioned Drupalgeddon3 and 2; by process of elimination we know 3 wouldn’t work due to a lack of valid credentials. If any, the vulnerability in question is exploited by Drupalg2.

Drupalgeddon2 (https://github.com/dreadlocked/Drupalgeddon2) is a remote-code execution vulnerability resulting from a lack of input validation on form API AJAX requests. This allows users to inject malicious payloads -in the form of renderable arrays- into the create user form.

In the case of the registration form, this applies to the mail parameter- by setting the values of indexes [#post_render][] to exec, [#type] to markup and ][#markup] to our desired system command we gain RCE (I briefly just tried to exploit this manually but I simply used dev tools within FireFox browser, probably would have succeeded if I’d tried through Burp Proxy or similar!)

It was at this point that I had to switch over to my host to finish up; honestly at this point the bulk of enumeration is complete.

drupalgeddon2>> whoami nt authority\iusr

iusr is essentially Window’s version of an ‘anonymous’ user that is utilized by default by IIS servers in order to access the required system files.

We can grab the user flag from Users/dimitris/Desktop instantly; thankfully there’s further privilege escalation needed for complete admin access!

By following any WIndows privesc cheatsheet, you should check out the privileges on the logged in account and see that we have an interesting one named ‘SeImpersonatePrivilege’- the ability to impersonate a client after authentication.

From previous reading I was aware that this Windows privilege basically means we’re system as there is a well known privesc technique for this called Juicy Potato- the last step is simply seeing how we can download files onto the victim and finding the relevant CISID for our Windows version. Bastard is a Windows 2008 server- as revealed by checking systeminfo.

After some trial and error, I managed to utilize CertUtil:

CertUtil was originally intended to be used to display CA (Certificate Authority) config information and to also make any neccessary alterations to CA components (basically an administrative tool for all things CA related :3)

Part of CertUtil’s functionality includes the ability to download files... Don’t ask me why they thought this was safe. I guess it was in the event of needing third party CA templates (basically pre-config of CA via certificate templates)?

With netcat and JuicyPotato now on our victim, we are able to exploit this privilege for a reverse shell.

This vulnerability is famously named Rotten Potato and -at a simple level- involves tricking AUTHORITY/SYSTEM into authenticating via NTLM to a TCP endpoint under our control.

This authentication process is then captured via a local MITM attack utilizing several Windows API calls. Finally -with one of the relevant privileges- we use the captured token for impersonation, thus gaining the ability to execute commands as SYSTEM.

For those who didn’t guess by the screenshot, a reverse shell is established through our run of jp.exe (I was running a nc listener on port 6969 to receive the connection) and we are able to read root.txt from Administrator’s Desktop directory.

The CLSID I used was obtained from https://github.com/ohpe/juicy-potato/tree/master/CLSID/Windows_Server_2008_R2_Enterprise.

DevOops is allegedly more difficult than OSCP but good practice; i actually found it quite easy. Probably because the vulnerabilities to exploit are pointed out.

An nmap scan reveals Gunicorn to be listening on port 5000- this is already a hint at the second attack required for the user flag as this was the same type of server I had to target for root access to Symfonos 4. Basic directory brute force further reveals the presence of three files- upload, the root of the server (index.html) and feed.

Index hints that the server uses Python at the back-end: apparently the root is feed.py while feed simply loads a png image and upload reveals a simple upload file form with reference to XML elements.

With so little to explore, it was quickly obvious that the upload form is probably vulnerable to some form of attack. I started by uploading txt and png files to observe the results- the page is simply reloaded.

This is when I thought to try uploading an XML file to the server- particularly with the hint towards what XML elements to use. 10 minutes research later and I’d put together a simple test.xml file.

I didn’t immediately jump to trying the above file: I firstly confirmed this was a vulnerability by trying to view /etc/passwd which was returned in the content element upon upload of the file.

After this, I spent half an hour or so seeing if RCE was possible through external entity attack; while it could have been if PHP was in use, it isn’t obviously so in the case of Python. This is when I remembered feed.py.

Feed.py revealed the insecure use of pickle on user supplied POST data to /newpost. After facing similar with JSON pickles in the past, I was aware that RCE was possible through this vulnerability and began working towards a reverse shell.

I learned here that things should always be tested locally first before testing them remotely: I was fiddling around with the reverse shell for an hour or two and constantly receiving error 500s. When I tried ti loally and it worked, i knew it was likely that there was something else wrong with my payload.

After 10-20 minutes, I discovered that adding the Content-Type header and setting it to text/html resulted in successful delivery of the payload (I confirmed this with a simple ping at first.)

Now I just needed to get a working payload- netcat was on the victim but a nc reverse shell resulted in immediate disconnection meaning the process was being terminated for some reason on their end. After some trial and error, I uncovered the following working payload:

I created this script from a few I found on Google. The pickle vulnerability arises form the manner in which pickle deserializes data (translating a byte stream to an object in the case of Python, an object being a list or dictionary etc.)

Objects with pickle are serialized using dumps or dump while they are deserialized using load/loads.

To achieve RCE through pickle, however, we must use the __reduce__function:  it requires a callable object and an optional tuple of arguments for the called object, thus providing this to the Pickle process will executable the mentioned callable object along with the provided arguments.

The above revere shell succeeded and I had a foothold on the system as Roosa. I could have probably read the user flag back in the external entity attack; I thought I’d save it for when I had achieved RCE.

The root flag is very easy- simple enumeration of Roosa’s home directory reveals a GitHub project called ‘blogfeed’ and the presence of an RSA private key used for the project’s integration. I had my suspicions this key may be relevant and thus saved it for further use later.

Further basic enumeraton (specifically of .bash_history) shows us that Roosa screwed up at one point and accidentally submitted a relevant private key to the GitHub project. Although not an expert, I use GitHub myself and thus am aware that previous commits can be viewed.

Some research showed that it is possible to view patches (I simply refer to it as changes but hey ho) to a GitHub repo via the git log -p command. Executing this reveals the original key submitted to the repo.

From here I discovered that an RSA private key can be used in place of a password for SSH access... Perhaps we have root’s private key here? I tried this with ssh -i old-key [email protected] and sure enough we have root access.

I enjoyed this machine but I don’t feel it should be of medium difficulty- it actually took me longer on the user flag.

In today's fast changing threat landscape, traditional vulnerability assessments just are not enough. Organizations need professionals who can actively simulate real world cyber attacks to find hidden security gaps before malicious actors do. This comprehensive training video is designed to take you from a foundational understanding of offensive security to executing sophisticated, multi layered simulation campaigns.

We will break down the exact methodologies used by top tier elite offensive security professionals, including advanced reconnaissance, evasion techniques, and post exploitation maneuvers. Whether you are an experienced penetration tester looking to level up your skill set or an enterprise defender wanting to understand the mindset of an attacker, this guide offers step by step breakdowns and real world scenarios. You will walk away with actionable strategies, a solid understanding of modern attack frameworks, and the confidence to design robust defensive countermeasures for your organization.

What You Will Learn

00:00 - Introduction to Elite Offensive Security Mindset

04:15 - Developing an Effective Adversarial Simulation Strategy

12:40 - Advanced Red Team Tactics for Modern Enterprise Networks

22:15 - Living off the Land and Evasion Techniques

35:50 - Constructing Actionable Red Team Reports for Stakeholders

Watch Full Video: