I took the Offensive Security Certified Professional (OSCP) exam on 21st June 2023 10am and managed to finish the boxes and verify them before requesting the exam to end at around 11pm. The OSCP exam is 23 hours 45 minutes long but you can end it earlier as long as you are comfortable.

My body was asking me to sleep but the adrenaline rush refused to let me so I worked on the report until 4am before hitting the bed. Cleaned up the report and submitted it at 2.30pm. I managed to clear all boxes and have the 10 bonus points from the PEN-200-2023 challenges.

Offensive Security emailed me on 24th June 2023 5:23pm to inform me that I passed! Phew!

So the timeline wise is:

21st June 2023 (Wednesday)
- 09:45am – Start of verification for proctored exam
- 10:00am – Start of OSCP (planned)
- 10:23am – Received exam package
- 10:30am – Started OSCP exam (scroll to the bottom for why)
- 11:00pm – Ended OSCP exam (you can end the exam earlier instead of the actual 23 hours 45 mins)
22nd June 2023 (Thursday)
- 2:30pm – Submitted report
24th June 2023 (Friday)
- 5:23pm – Received email that I passed OSCP

I did the PEN-200 and OSCP with a MacBook Pro (13-inch, M1, 2020) with 8GB RAM so I thought that I should document the ups and downs of using a MacOS machine, particularly one with ARM architecture, for it.

My Setup

I am using a MacBook Pro (13-inch, M1, 2020) with 8GB RAM on Ventura. As for the setup, I am running:

	Main Kali	John/ Hashcat Kali	Kali	Windows 11
Architecture	ARM		Intel/AMD64
Engine	VMware Fusion		UTM
vCPU	2	4	2	2
RAM (GB)	2	3
Storage (GB)	80	20	20	40
Networking	Bridged	NAT

I am also using Joplin for note-taking.

At any single point in time, I can only running maximum of two virtual machines with the Main Kali as the fixed VM. So either I am brute-forcing a hash (on John, Hashcat VM) or I am compiling a x86_x64 binary (on Kali (Emulated Intel)) or investigating a program (Windows 11 (AMD64)). Although 2GB plus 3GB equals 5GB of RAM (which is less than 8GB that the MBP has), trust me, the mouse pointer will start stuttering. Why so? Joplin and Chrome on the host OS are memory hoggers.

In recent years, I didn’t feel the need for RAM as much as any burst requirements on resources can be easily handled on the cloud.

Need to crunch massive data? Spin up a spot AWS EC2 instance
Need GPU for that CUDA under the hood algorithm? Spin up a spot AWS EC2 instance.

That was what I believed until I encountered OSCP. Well, I didn’t regret using an 8GB machine for it as it is just short term usage.

But of course, 16GB would be better and 32GB will be luxurious. Who would say no to a fluid smooth machine?

Issues with cross-compiling for x86_x64 on ARM

Let’s face it. A large handful of the servers and clients out there are still on the x86_x64 architecture. If you are not leveraging LOLbins, you will need to bring in x86_x64 tools to your target as part of your process. At times, you also need to compile public exploits and run them on your target. At the time of writing, the Kali’s gcc (for arm architecture) cannot compile for x86_x64 arch (at least I cannot do it) and Clang (on Ventura) throws numerous errors. The good thing is that Kali’s mingw handles the cross-compiling of C code for Windows without breaking a sweat. However, .sln are slightly more complex.

Some tools like Kerbrute only releases x86_x64 variants. However, there are always alternatives to these tools so just have to adapt.

Solution (at least partial)

My (partial) solution to this is to pre-compile the required exploits on an x64 machine. There are free Linux instances that you can use for a short period of time like AWS, Oracle Cloud, etc. The free credits are more than enough to compile some of the usual stuffs in your workflow like:

CVE-2022-2588
CVE-2022-0847 (DirtyPipe)
CVE-2021-4034 (PwnKit)
CVE-2021-3156 (Baron Samedit)
Redis Module for Command Execution
Linux SUID program
alpine images for abusing lxd group

Yes, I pre-compiled the above in several flavours:

x86 (dynamic linking) and x86 (with static libraries linking)
x64 (dynamic linking) and x64 (with static libraries linking)

Issues with running x86_x64 binaries

What? After issues with cross-compiling. Why do I need to run x86_x64 binaries?

At times, there are programs that are triggered by root or LocalSystem and you might want to introduce your own crafted libraries (i.e., .dll, .so) or overwrite some registry values so that your codes get launched under the same privilege. Before you can do that, you will need to understand the behaviour of these programs.

So this becomes the issue – if you cannot run these x86_x64 programs on your ARM machine, how can you analyse its behaviour?

Solution

Tap on the power of emulation, particularly UTM. With it, you can emulate x86_x64 on Apple Silicon. You can run Windows 11 (x64) Evaluation and even Kali Linux (x64) on it albeit slow cos UTM is emulating the x86_x64 instruction set. That is why I don’t run my workhorse Kali on it.

With 8GB RAM on my host machine, I only boot it up and use it for the required period and shut it down. Not a great experience seeing the VM crawl.

Issues with VMware Fusion’s NAT driver

My observation is that the NAT driver or implementation for VMware Fusion (for MacOS) has some issues with throughput. I reckon that most people just leave the VM’s networking at the default setting of NAT. Me too, at least for only until three (3) weeks before the exam.

While my Kali VM is on NAT setting, I could not run “nmap at T4” nor can I run “gobuster at -t 50”. They will just complain that sync timing is off, or throw errors stating that the target did not respond within the defined period.

Solution

One fine day, I decided to switch it to “Bridged (Autodetect)”. The networking is literally flying after that. I could comfortably run “nmap -p- T4” concurrently for a couple of hosts. I could also run “gobuster at -t 50” for at least two hosts concurrently. This certainly sped up the initial enumeration.

Issues with Janus WebRTC Plugin for Screen Recording

Well, this is an exam day issue. MacOS is really great at protecting your privacy and security to that extent that it prevents application from recording your screen. Not great for proctored examinations.

Solution

Before the exam, do yourself a favour by requesting for a test session to get these technical issues sorted out.

You will should do the following:

If you are using browser other than Firefox, install the Janus WebRTC Plugin/Extension
Find a testing target (e.g., this) to ensure you can share your screen
Update your MacOS’s Privacy and Security settings. Settings > Privacy & Security > Screen Recording > enable for the browser that you are using for the exam.

I fumbled during my exam day. Along with my home connectivity issue with WebRTC, I started the exam 30 minutes late. Yes, I started at 10:30am, not great for the start of the stressful exam. To make it worst, instead of my home broadband, I had to use my mobile Internet for the exam.

Final words

I hope the issues and solutions above will help you in some way or another if you are also using a Mac with M1/M2 like me. It is doable, just that these information are not properly document anywhere.