OSCP Exam Report
OSCP Exam Report
OSCP Exam Report
OSID: OS-XXXXX
[email protected]
v1.0
CONFIDENTIAL 1
Table of Contents
3 Methodologies ..................................................................................... 6
3.1 Information Gathering ....................................................................................... 6
3.2 Service Enumeration ........................................................................................... 6
3.3 Penetration .......................................................................................................... 6
3.4 Maintaining Access ............................................................................................. 6
3.5 House Cleaning .................................................................................................... 7
1.1 Introduction
The Offensive Security Lab and Exam penetration test report contains all efforts that were conducted
in order to pass the Offensive Security course. This report should contain all items that were used to
pass the overall exam and it will be graded from a standpoint of correctness and fullness to all aspects
of the exam. The purpose of this report is to ensure that the student has a full understanding of
penetration testing methodologies as well as the technical knowledge to pass the qualifications for the
Offensive Security Certified Professional.
1.2 Objective
The objective of this assessment is to perform an internal penetration test against the Offensive
Security Lab and Exam network. The student is tasked with following methodical approach in
obtaining access to the objective goals. This test should simulate an actual penetration test and how
you would start from beginning to end, including the overall report. An ex-ample page has already
been created for you at the latter portions of this document that should give you ample information
on what is expected to pass this course. Use the sample report as a guideline to get you through the
reporting.
1.3 Requirements
The student will be required to fill out this penetration testing report fully and to include the following
sections:
When performing the internal penetration test, there were several alarming vulnerabilities that were
identified on Offensive Security’s network. When performing the attacks, John was able to gain access
to multiple machines, primarily due to outdated patches and poor security configurations. During the
testing, John had administrative level access to multiple systems. All systems were successfully
exploited and access granted.
2.1 Recommendations
John recommends patching the vulnerabilities identified during the testing to ensure that an attacker
cannot exploit these systems in the future. One thing to remember is that these systems require
frequent patching and once patched, should remain on a regular patch program to protect additional
vulnerabilities that are discovered at a later date.
Exam Network:
• 172.16.203.133
• 172.16.203.134
• 172.16.203.135
• 172.16.203.136
3.3 Penetration
The penetration testing portions of the assessment focus heavily on gaining access to a variety of
systems. During this penetration test, John was able to successfully gain access to 10 out of the 50
systems.
John added administrator and root level accounts on all systems compromised. In addition to the
administrative/root access, a Metasploit meterpreter service was installed on the machine to ensure
that additional access could be established.
After the trophies on both the lab network and exam network were completed, John removed all user
accounts and passwords as well as the Meterpreter services installed on the system. Offensive Security
should not have to remove any user accounts or services from the system.
Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Service Enumeration
FTP Enumeration Upon manual enumeration of the available FTP service, John noticed it was running
an outdated version 2.3.4 that is prone to the remote buffer overflow vulnerability.
Initial Access
Vulnerability Explanation: Ability Server 2.34 is subject to a buffer overflow vulnerability in STOR
field. Attackers can use this vulnerability to cause arbitrary remote code execution and take completely
control over the system.
Vulnerability Fix: The publishers of the Ability Server have issued a patch to fix this known issue. It
can be found here: http://www.code-crafters.com/abilityserver/
Steps to reproduce the attack: The operating system was different from the known public exploit. A
rewritten exploit was needed in order for successful code execution to occur. Once the exploit was
rewritten, a targeted attack was performed on the system which gave John full administrative access
over the system.
###################################
# Ability Server 2.34 FTP STOR Buffer Overflow # Advanced, secure and easy to
use FTP Server. # 21 Oct 2004 - muts ###################################
# D:\BO>ability-2.34-ftp-stor.py ###################################
# D:\data\tools>nc -v 127.0.0.1 4444
# localhost [127.0.0.1] 4444 (?) open
# Microsoft Windows XP [Version 5.1.2600]
# (C) Copyright 1985-2001 Microsoft Corp.
# D:\Program Files\abilitywebserver> ###################################
import ftplib
from ftplib import FTP
ftp = FTP('127.0.0.1')
ftp.login('ftp','ftp')
print "\nEvil Buffer sent..."
print "\nTry connecting with netcat to port 4444 on the remote machine." except:
print "\nCould not Connect to FTP Server."
try:
ftp.transfercmd("STOR " + buffer)
except:
print "\nDone."
Vulnerability Explation: After establishing a foothold on target, John noticed there were several
applications running locally, one of them, a custom web application on port 80 was prone to SQL
Injection attacks. Using Chisel for port forwarding, John was able to access the web application. When
performing the penetration test, John noticed error-based MySQL Injection on the taxid query string
parameter. While enumerating table data, John was able to successfully extract the database root
account login and password credentials that were unencrypted that also matched username and
password accounts for the administrative user account on the system and John was able to log in
remotely using RDP. This allowed for a successful breach of the operating system as well as all data
contained on the system.
Vulnerability Fix: Since this is a custom web application, a specific update will not properly solve this
issue. The application will need to be programmed to properly sanitize user-input data, ensure that
the user is running off of a limited user account, and that any sensitive data stored within the SQL
database is properly encrypted. Custom error messages are highly recommended, as it becomes more
challenging for the attacker to exploit a given weakness if errors are not being presented back to
them.
Screenshot:
Figure 1 - Screenshot
Post-Exploitation
Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Service Enumeration
Initial Access
Vulnerability Explanation: The user account on the Ajla host was protected by a trivial password that
was cracked within 5 minutes of brute-forcing.
Vulnerability Fix: The SSH service should be configured to not accept password-based logins and the
user account itself should contain a unique password not contained in the publicly available wordlists.
Steps to reproduce the attack: om the initial service scan John discovered that this host is called Ajla.
After adding the target’s IP to the /etc/hosts file, the Hydra tool was run against the SSH service using
the machine’s DNS name instead of its IP. With the extracted password at hand John was able to log in
as ajla using SSH.
Figure 3 - Screenshot
Vulnerability Explation: sudo group allows any user in this group to escalate privileges to the root if
they know the user’s password.
Vulnerability Fix: The SSH service should be configured to not accept password-based logins and the
user account itself should contain a unique password not contained in the publicly available wordlists.
Steps to reproduce the attack: John spotted that the ajla user was a member of the sudo group
immediately upon logging in and using the “id” command. And knowing user’s password, he only
needed to use a single command “sudo su” in order to obtain a root shell.
Figure 4 - Screenshot
Post-Exploitation
After collecting the proof files and establishing a backdoor using SSH, John began the enumeration of
the filesystem for the presence of interesting files. He noticed that there was a mounted share
John began the lateral movement by establishing a reverse dynamic port forwarding using SSH. First,
he generated a new pair of SSH keys and added those to the authorized_keys file on his Kali VM, then
he just needed to issue a single SSH port forwarding command:
With the dynamic reverse tunnel established, John only needed to edit the /etc/proxychains.conf to use
the port 1080.
Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Service Enumeration
Initial Access
Steps to reproduce the attack: with the credentials at hand and a reverse tunnel established, John
connected to an RDP session using proxychains accepting the certificate when prompted and entering
the retrieved password afterward.
Post-Exploitation
John noticed the presence of the Thunderbird program on the user’s desktop, and while checking
Alex’s inbox he found the email from a local administrator Roger:
Vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Service Enumeration
Initial Access
Steps to reproduce the attack: John was able to reuse a temporary password that the administrator
left for Alex.
Figure 7 - Screenshot
Post-Exploitation