OSCP Proof Screenshot Guide

Hey guys! So, you’re diving into the wild world of penetration testing and aiming for that Open Source Intelligence certification, the OSCP. That’s awesome! One of the crucial, and let’s be honest, sometimes slightly confusing, parts of this journey is knowing exactly what kind of proof screenshots you need to nail your exam submission. Getting these right isn’t just about showing off your skills; it’s about clearly demonstrating to the examiners that you’ve successfully compromised the target machines and completed the objectives. In this guide, we’re going to break down exactly what constitutes a good OSCP proof screenshot, why they’re so important, and how to make sure yours are on point. We’ll cover everything from the essential information that needs to be visible to common pitfalls to avoid. So, grab your favorite beverage, get comfy, and let’s get this sorted!

Why Are OSCP Proof Screenshots So Important?

Alright, let’s talk turkey about why these screenshots are a big deal in the OSCP exam. Think of it this way: you’re in a virtual lab, you’ve done some seriously cool hacking, but how do you prove it to someone who wasn’t there with you? That’s where your OSCP proof screenshots come in. They are your irrefutable evidence. The examiners at Offensive Security don’t have time to re-trace every single step you took on a machine. They need a clear, concise, and undeniable record of your success. A well-taken screenshot acts as a mini-report card for each machine, showing that you’ve achieved the required level of access and completed the specific objectives for that box. Without solid proof, even if you technically gained root, your report might fall short. This is especially critical for machines that might be tricky to screenshot or where the compromise might not have an immediately obvious visual indicator. The goal is to make the examiner’s job as easy as possible in verifying your work. They want to see that you understand the implications of your actions, not just that you can type commands. So, investing time in understanding what makes a good screenshot is an investment in passing the exam. It’s your digital handshake, your undeniable testament to your penetration testing prowess. This isn’t just about taking a picture; it’s about strategic documentation. Every pixel should tell a story of your exploit, your privilege escalation, and your ultimate control over the target system. Remember, the report is your primary means of communication, and screenshots are the most powerful visual aids within that report. They are the highlights of your hacking show, showcasing the grand finale. Don’t underestimate their power or importance in the overall assessment of your skills. A machine well-documented with clear, relevant screenshots is a machine that’s much closer to being marked as successfully compromised.

What Makes a Good OSCP Proof Screenshot?

So, what exactly separates a meh screenshot from a hell yeah screenshot? It all comes down to clarity, completeness, and relevance. Firstly, and this is super important , every screenshot must clearly show the IP address of the target machine . This is non-negotiable. You can usually achieve this by running a command like ip addr or ifconfig on the target machine itself, or by showing it in your own attacker machine’s terminal output where it’s interacting with the target. The IP address acts as the anchor, proving which machine you were working on. Next up, you need to demonstrate proof of compromise . This typically means showing that you have achieved a certain level of access, often root or SYSTEM privileges. Commands like whoami or id are your best friends here, clearly displaying the user you are logged in as. For Windows boxes, showing whoami returning NT AUTHORITY\SYSTEM is golden. For Linux, seeing # in your prompt or running whoami as root is key. Don’t just show a shell; show the elevated shell.

Another critical element is showing proof of objective completion . What does this mean? It means you’ve done what the exam requires for that specific machine. This often involves reading a specific flag file. These files usually have names like root.txt or user.txt . You need to show the command you used to access and read the contents of this file, and crucially, the output of that command, displaying the flag itself. Commands like cat /root/root.txt or type C:\Users\Admin\Desktop\flag.txt are standard. Make sure the entire flag is visible, not cut off. We’re talking about full context . This means the command prompt, the command you typed, and the full output, including the flag. Avoid cropping screenshots in a way that removes necessary context. You want to show the entire terminal window or relevant portion that contains all this information. Think about using tools like script in Linux to record your session, which can be invaluable for generating clear, sequential screenshots or even video evidence if needed (though screenshots are typically sufficient). Ensure your screenshots are legible. Blurry images or text that’s too small to read are useless. Adjust your terminal font size if necessary before taking the screenshot. A good rule of thumb is to zoom in on the specific command and its output. High resolution is your friend here. Finally, always timestamp your screenshots if possible, or ensure the context implies the timeline of your actions. While not always explicitly required for every single proof screenshot, having a clear progression of actions helps build a narrative in your report. Remember, the goal is to be undeniable. If an examiner can look at your screenshot and have any doubt about what it shows, it’s probably not good enough.

Essential Elements for Every OSCP Proof Screenshot

Let’s drill down into the nitty-gritty details that absolutely must be present in your OSCP proof screenshots . Guys, if you miss even one of these, you might be leaving points on the table, and nobody wants that during the OSCP exam. The first and foremost is the target machine’s IP address . Seriously, I can’t stress this enough. You need to be able to prove you were interacting with the correct machine. This can be shown by having the IP address displayed in the terminal prompt itself (e.g., user@target-ip:/path$ ), or by running a command like ip a on Linux or ipconfig on Windows within the compromised shell and capturing that output. The key is that the IP address is unambiguous and clearly linked to the actions you’re performing.

Next, we need proof of privilege escalation . This is where you show you’ve moved beyond a low-privilege user. For Linux targets, this means showing that you are root . A command like whoami displaying root , or id showing uid=0(root) gid=0(root) groups=0(root) , is perfect. Often, your terminal prompt will change from $ to # when you achieve root, and capturing that is also excellent proof. For Windows targets, you need to show SYSTEM privileges. Running whoami and seeing NT AUTHORITY\SYSTEM is the standard. Sometimes, you might need to show the output of commands like net user or query user to demonstrate your user context. The objective is to clearly distinguish between a standard user shell and an administrator/root shell.

Then comes the proof of objective completion . This is where you showcase the final prize – the flag! For most OSCP machines, this involves reading a specific file, commonly root.txt or user.txt . You must capture the command used to read the file (e.g., cat /root/root.txt ) and, crucially, the full output of that command, which contains the flag. Do not cut off the flag! Make sure the entire string is visible. If the flag is very long, you might need to scroll up slightly in your terminal before capturing the screenshot to ensure it all fits within a readable frame. It’s also good practice to show the command that lists the files in the directory where the flag resides (e.g., ls -la /root/ ) to prove the file actually exists before you read it. This adds an extra layer of validation. Legibility is paramount. If your text is too small or blurry, the examiners can’t verify your win. Use a clear, readable font size in your terminal and ensure your screenshots are high-resolution. Avoid using overly compressed image formats that degrade quality. PNG is generally a good choice. Finally, context is king . A screenshot should show enough of the terminal window to make sense. This includes the command prompt, the command entered, and the full output. Don’t just crop to the flag itself; show the process. Think of it as telling a mini-story within each image. By including these essential elements, you’re creating robust, undeniable proof of your hacking success.

Common Mistakes to Avoid with OSCP Screenshots

Alright team, let’s talk about the landmines – the common mistakes that can trip you up when taking OSCP proof screenshots . Avoiding these will save you a ton of headache and potential re-submission headaches. First off, the absolute classic: missing the target IP address . This is the cardinal sin, guys. If the IP isn’t visible, how can the examiner be sure you compromised that specific machine? Always double-check that the IP is in the frame, either in the prompt or via a command output. Another frequent blunder is showing a low-privilege shell as proof of compromise . You might have gotten a user shell, but the objective was root. If your screenshot shows username@hostname:/home/user$ and you claim root access, that’s a fail. Make sure you’ve actually escalated privileges and that your whoami or id command clearly reflects root or SYSTEM . Don’t assume the examiner knows you escalated. Show it!

Then there’s the infamous **