What is Pentesting?

Protecting your business through hacking is a complex and time-consuming skill. This kind of preventive defense framework has multiple faces and categories, but one of the most known is called Penetration Testing (or Pentesting) - a formal procedure aimed at the discovery of new flaws, risks and vulnerabilities inside a company security matrix, and in a predefined scope. When it comes to pentesting, its actor - the pentester - simulates an attack against a Network, Application, or System, in order to find and exploit the said vulnerabilities, usually in a really loud, noisy way and in combination with Blue Team/Security teams inside the company (if any). However, it's impossible to make an impenetrable Network/Application/System, but the pentester will try their best to make it more difficult to bad actors to break through your fences.

What is the need of a Penetration Test?

As I mentioned before, no Network/Application/System is a fortress. If you check the number of new vulnerabilities entering the market every year, the rates are always increasing and breaking new records. This situation makes it impossible to protect an asset against all kinds of vulnerabilities it's susceptible to, but the asset owners can harden their defenses against them. The expenses a company can suffer from a successful cyberattack can be enormous, costing not only a lot of money, but also their client's trust and their brand's strength. Quoting a book that I really like that investigates the legal and economic aftermath of a cybersecurity breach, you'll only see this message when it is too late. But when it comes to small and medium business, you might not have the opportunity to be "too late", and it might cost your whole business, especially with the findings from CBNC, attesting that 43% of the attacks are aimed against small business, but only 14% are prepared to properly defend themselves.

A penetration tester can expose security holes in that company's protective shell, as well as getting an overall diagnostic on that company security layers. This will, usually, lead to reinforcement and improvement in compliance, defensive mindset and overall security protocols inside the company.

How often should I implement a Penetration Test?

As you already saw here, the numbers of new vulnerabilities are sky-rocketing and breaking new records every year. So performing a new penetration test every year should be a regular practice for companies, just to create a better security standard and re-evaluate the health of their security mechanisms. Besides that, a new pentesting assessment should ideally be performed every time a company adds:

• New network infrastructure
• New application launches
• New offices (especially in new locations)
• New major patches or updates

However it's good to point out that this must not apply to every company, and it usually depends on their presence online, their budget share allocated to security (if any) and their infrastructure. It's important to note that a company that holds most of its infrastructure in a cloud provider might not be able to perform independent penetration tests, relying on the security assessment conducted by the cloud provider itself.

The difference between penetration test and vulnerability assessment/red teaming/bug bounty/CTF

Now that you already know what the basic concepts of a Penetration Test, it's important to also distinguish it from some other security-counterparts. The confusion between any of these different procedures might cause inefficient expenses and lead to unexpected results that might be misleading, causing a scenario where the company will have a wrong evaluation of their security matrix and assets. When it comes to small and medium businesses, these common misconceptions can burn their security budget (or might even be too expensive to even consider be included in the said budget) and still leave holes in the company's shell. So, finally, what all those terms mean?

• Penetration Test

  The Penetration Test is the process in which the pentester conducts an assessment on a target in order to bring the vulnerabilities to light and exploit them. The main objective in a Penetration Test is to observe the network/system/application through the eyes of a malicious actor, overcoming its defenses and finally evaluating the health status of that asset security matrix, providing detailed information on its attack surface, vulnerabilities and their magnitude and how the defensive mechanisms and teams would react to it. Think of Pentesters as mongol riders, being super loud, attacking everything they can and leaving a lot of tracks.

• Vulnerability Assessment

  The Vulnerability Assessment is the process in which the target will be tested, usually with automatic tools and an array of manual tasks, in order to understand and evaluate the security of the assets. Different from pentests, Vulnerability Assessments should be more frequent, in order to constantly update the asset defense and lower its attack surface, especially when new vulnerabilities related to the services or applications used in the target network/application/system is released (and, as you remember, they pop up almost every day!).

• Red Teaming

  If you could imagine a Penetration Test as a mongol rider attack, you can imagine Red Teaming as a long campaing of ninja attacks. A Red Teaming assessment is a more focused, stealthy operation, aiming to understand the core of the security protocols in the company's human, technological and physical assets. After the Vulnerability Assessment and the Penetration Test were performed, a company with a more mature and sophisticated approach to security issues could force and benchmark its security protocols with a Red Teaming Assessment, involving not only technological aspects - as in a penetration test - but also physical components - like computers, telephones, peripherals - and human assets, via Social Engineering.

• Bug Bounty Program

  Bug bounty programs are usually offered by companies with a higher security-allocated budget and a refined Cybersecurity strategy, in order to constantly test and update their endpoints and applications. A Bug Bounty program is highly scalable due to its pay-for-vulnerability model - in contrast to the usual pay-for-time model in Penetration Test cases -, as well as common crowdsourced bug bounty platforms such as Bugcrowd, Hackerone and Intigriti. An outstanding advantage provided by the Bug Bounty Program is that it offers multiple perspectives from different security researchers, and this multicultural, multifaceted approach can result in different approaches on how to exploit an asset, bringing a more real-world touch to the assessment (which is clearly an advantage for companies that have an intense internet presence worldwide).

• CTF

  Capture-the-Flag games (or CTFs) are really good training models for enhancing one's penetration testing skills, but they are not good examples for real-world practices. For starters, usually a CTF consists of attacking a vulnerable-by-design target, finding its vulnerabilities, escalating privileges and finding "flags", pieces of text hidden inside the target. Once you found the flags, your job is done. That's not how it happens on a pentest, where you need to implement post-exploitation techniques, find relevant information inside the exploited target (not only flags) and test every way you can find to breach that asset (in contrast to CTFs, where you are after that one way to exploit the target and get the flags in the shorter amount of time possible). However, no one doubts the efficiency of these games to improve one's hacking skills, which is, of course, a good way to get more people into the minutiae of security attacks, even if they are not penetration testers themselves.

Setting Up a Pentesting Lab

You read about pentesting, understood its concepts and got a brief explanation on other security fields related to that. So, what's next? If you thought "It's time to learn the practicalities of it myself", then you're right! But, before you start practicing in a controlled environment (remember, pentesting a live target without permission is considered a crime), you need to set up your lab, and that's what we are going to do right now.

The first you need to worry about is your operational system. When it comes to Penetration Testing there are multiple options, but the two most popular ones are Kali Linux and ParrotOS. Both of them are Debian-based Linux distributions, with support for either 32-bit or 64-bit architecture, with an outstanding out-of-the-box support for useful pentest-related tools that are going to make your life easier. Just install them, find a legal practicing target and start hacking! No need to install multiple tools (even though some of them could be a nice add if you have a few minutes to spare), no need to spend a lot of time configuring stuff... They are already there!

Once you get more experienced with all the tools you need to better fit your own Methodology, you can start looking for some other options out there, or even create one distribution yourself with every single thing that's necessary to get the job done! But right now I suggest you stick to one of those, for the reasons I explained before. You don't wanna spend a lot of time looking for installation tutorials for every single tool you need, when there's already something out there with all of those tools packed in a single box, ready for use! Before you pick Kali or Parrot, I suggest you take a look and research a bit about the difference between them, especially related to the system requirements. Kali might be a little more greedy, component-wise, but the final decision is up to you.

One more thing: Those are hacking-specialized operational systems, so you are going to handle with all sorts of stuff there, which may include malware analysis. So it's recommend that you run them on a Virtual Machine, on top of your regular OS. However, this approach can be really resource-intensive, requiring 8GB or more of your RAM. So if you don't want to do that, no worries: You can still install one of those systems as your main one, but you need to be extra careful about what you do. But, once again, the final decision is up to you, so before you commit to any final words on any of these subjects, do your own research, think about it yourself and then proceed to do whatever floats your boat!

Installing the Virtual Machine

So let's get our hands dirty and start installing our tools! The first thing you'll need is a Virtual Machine. The best, free options out there are VMWare Workstation and Oracle VM VirtualBox. Once again, I recommend you do your own research to choose whatever is the best for you, but for the matters of this post I'll stick to VirtualBox. It's my favorite from those two options and I run it on every setup I use at home, basically because I got familiar with it during my graduation and things seem natural and seamless for me when it comes to configure a new machine on it. That being said, the first thing you'll need to install it is visit their website on https://www.virtualbox.org/wiki/Downloads.

Choose the platform package related to your host machine, then click on it and once the pop message shows up, save it. In my case, I'm on a Windows machine, so you might see something more or less like this:

Now it's downloaded, just click on the file and execute it.

Click on "Next" when prompted, until you reach the "Install" button. Then proceed to click on it as well, and wait for the installation wizard to complete its process.

Once it's done, just open Virtual Box and you'll be ready for the next step!

Installing your Operational System

For the purposes of this tutorial, we'll choose Kali Linux over ParrotOS, again for familiarity reasons. I've been working on Kali for a couple of years now, and I'm just more familiarized with it. However, in the past few months I've been closely watching ParrotOS release after release, and in the near future I might switch my main pentesting operational system, simply because the features and UX pleases me more than the latest Kali releases. That being said, let's head over to Offensive Security website and download our Virtual Machine-ready Kali Linux release on https://www.offensive-security.com/kali-linux-vm-vmware-virtualbox-image-download/ and click on the VirtualBox Images tab (be careful not to click on the Kali Linux VMWare Images tab!).

Once you're done downloading the Kali image, let's configure it in the VirtualBox. Open VirtualBox and then click on New on the top menu or in Machine → New (alternatively, you can also press Ctrl+N).

It will pop up the "Name and Operating System" screen, which has some pre-filled fields in it. Usually it comes with a default Windows configuration, but we need to change it to our Kali image. In the Name field you can write whatever you want. It will be your identifier for all the Virtual Machines you'll have in your Virtual Box, but for organizational reasons, let's call it Kali Linux. Select the folder where you want you VM information and snapshots to be saved inside the Machine Folder field. For Type you select Linux and finally Debian (64-bit) or Debian (32-bit), depending on you own machine's architecture. Once everything is more or less like in the screenshot below, hit Next.

Up next is the Memory Size screen, where you're going to select how much RAM resources you are going to allocate to your Virtual Machine. If you have enough RAM to allocate at least 8GB to Kali Linux, most things are going to run smoothly and you won't have a lot of trouble. If you don't have 8GB to allocate, I sugest you switch to ParrotOS or install Kali as a LiveUSB. You can also run with less than 8GB, but it might get super slow and cranky halfway through your pentesting assessments. Once you decided which option suits you best, hit on Next and let's move to the next section.

In the Hard Disk screen we just need to select Create a virtual hard disk now and hit Create.

This will pop up the Hard Disk File Type screen, and in this one we select VDI (VirtualBox Disk Image).

The following section is the Storage on Physical Hard Disk screen, and in this one we'll select dynamically allocated.

For the File Location and Size screen, we gotta select how much of our actual hard disk will our Virtual Machine be able to use. I like to select 80GB, especially because Kali Linux already comes packed with most of the tools you need to do your job, so you won't be downloading new stuff like crazy.

Once you click on create, the pop-up screen will fade and you'll be back on the home Virtual Machine menu.

With the wizard completely done, let's click on Settings (Ctrl + S)

As the Settings screen pop-up for us, let's click on General and then on Advanced, and change both the Shared Clipboard and Drag'n'Drop options to Bidirectional.

Then we change to the System tab on the left side menu, and then on the Motherboard tab we need to be sure to select only Hard Disk and Optical as boot options, and use the up and down arrows to make the boot order be: Hard Disk first and Optical second.

Still on the System Settings we move to the Processor tab and select the Processor usage to 2 CPUs and enable PAE/NX on the Extended Features checkbox.

The on the Display settings we go to the Screen tab and move Video Memory all the way up to 128MB.

On the Network Settings we gotta select the type of Network connection our Virtual Machine will have, and there are three main options when it comes to Pentesting: NAT, Bridged and Host-Only. NAT will leave your machine running as if it was on your own home network with your host machine acting like a wireless router, while the guest machines will be in a private subnet. This is optimal to your VMs connect to other VMs and also to the outside world, however your host will filter that connection.

Host-Only is accessible, as it implies, only by the host machine your VM is running on. This is an optimal network situation to be isolated from the outside world and experiment on private test web servers and malware analysis (since it cannot connect to malicious hackers in the wild).

Bridged runs your VM in the same network as your host, and it can be accessed by all computers in the host network.

Usually NAT will be okay for all pentesting purposes, but sometimes you want to use an exploit that needs to connect to your computer, and in this case NAT might cause some trouble. You can switch to Bridged if that's the case, since it offers a more "down to earth" type of connection to the outside world.

When you're done, click on OK and go back to the home menu. Your VM information will look more or less like this one

Then we click on Start on the top menu, and it will pop up another screen, asking for you the select the start-up disk. Since we're going to use the Kali image we downloaded, click on the folder icon with the arrow up in front of it.

This will open a new pop-up, and then we need to click on Add, to add a new disk image. Navigate to where you ISO file is stored, and click on it.

Once you've located your file, just hit Start and you'll be done with your process! Time to open your Kali Machine and get started!

Building Your Pentest Methodology

Before jumping into practice, let's agree on the structure of our penetration test. Whatever you (and other penetration testers) will do along the way may vary, but the structure is usually the same. You can find detailed information on pentest-standard.org and other sources, but I'll summarize it here:

Now, to provide a deeper dive into all these different phases, let's select a room on TryHackMe where we can legally utilize all tools and explain the structure step-by-step, and how to build your methodology through it.

Phase 1 - Pre-Engagement Phase

The pre-engagement phase represents the first contact between the client and the pentester. The objective of this phase is to define the scope of the penetration test, as well to explain to client predefine a time estimative for the whole assessment. Some questions must be asked and a good understanding of the scope must be perfectly determined.

In our example, we are going to test our methodology with TryHackMe's Ultratech. Considering our pre-engagement discussions, our scope would be the machine's IP: 10.10.148.123 and the time estimative would be the box's expiration time, 1h (52m 14s here in the screenshot).

Phase 2 - Information Gathering

This is arguably the most important step in a penetration test. During this phase the pentester will collect intelligence on the target defined in the scope, in order to understand the target's attack surface and start to strategize on their attack vector. As it's stated in the Pentest Standard, "The more information you are able to gather during this phase, the more vectors of attack you may be able to use in the future".

In our case, let's start figuring out how many open ports there are in our target. To do so, we can run rustscan via a docker container using:

docker run -it --rm --name rustscan rustscan/rustscan -a 10.10.148.123

Let me explain this command to you:

• docker run -it —rm —name - activates the docker container I am using rustscan from.
• rustscan - Rustscan is a powerful and superfast network scan tool, way better and faster than the traditional and well-known Nmap when used to identify open ports. When running a professional pentest (that will probably have a few days or weeks as time estimative) you can run rustscan multiple times and also an Nmap or other tools (like hand-crafted Python scripts) to be really sure which ports are open.
• /rustscan - Rustscan's version, defining which container will be selected and utilized (in this case, since there are no special version predefined, it's running the latest).
• 10.10.148.123 - Our target IP.

Since Rustscan is not packed natively inside Kali Linux, you might find useful information on how to install it in the official documentation https://hub.docker.com/r/rustscan/rustscan

If you want to run nmap as well for an all-ports scanning, you can run:

nmap -sC -sV -p- 10.10.180.145

• nmap - Activates nmap
• -sC - Will run nmap's script reconnaissance, identifying which scripts might be useful against each of your findings.
• -sV - Will determine which service version is running on each of the open ports.
• -p- - Will run the nmap against all 65,535 ports available for communication. This is why it takes so long to be done, but when it's done you'll have proper information on all the available ports, instead of the standard top most common ports outcome you'll get running a simple -p.

The outcome from Rustscan will return:

So now we know we have ports 21, 22, 8081 and 31331 open. In my methodology, after running Rustscan, I like to run a complete Nmap focused on the open ports, which will return detailed information on the ports that I already know that are open.

nmap -T4 -A -Pn -v -p 21,22,8081,31331 10.10.148.123

• nmap - Activates nmap
• -T4 - Defines how fast nmap will perform the scan. The speed varies between T1 and T5, the latter being the fastest as well. However, it's important to note that it's also a very "noisy" approach, probably being easily detected by a mildly secure target. Normally it's not ideal to use such a fast speed in a real-world target, but it can be also a good tactic to try to run the same nmap scan with different speeds, in order to have a better understanding on the target's defenses, and what it can really identify.
• -A - Enables OS detection, version detection, script scanning, and traceroute.
• -Pn - Treats all hosts as online -- skip host discovery.
• -v Increases verbosity level, returning more detailed information on each step of the scan
• -p - Defines which ports will be scanned. If it's not specified, it will run against the top 1000 most common ports. In this case, we are specifing the ports with the findings we got in the previous step.
• 21,22,8081,31331 - The ports we found out with Rustscan.
• 10.10.148.123 - Our target's IP.

The core information outcome from the nmap scan is detailed in the screenshot below.

Phase 3 - Enumeration

One can argue that Information Gathering and Enumeration are the same steps. I would add that the process of gathering information can be extensive and even include the Phase 4 - Vulnerability Analysis in the process. No matter how you call those phases, one thing should be learned before all of this: Gather as much information as possible. Enumerate every port you find, analyze and model your threats as much as you can. This will make your life easier in the following steps, and this will also provide a lot of useful and valuable information to your client: At the end of the day, it's your job to inform them as much as you can, so the more you get out of this big Discovery Phase, the better.

Now that any naming issues have been disclaimed, let's move on with our analysis. We know the open ports already, so let's start exploring them. In my personal methodology, I like to address any HTTP Ports to see if they have a functional website from where I can extract more information. So let's start with our target's IP + 8081 (the first open HTTP Port from our scan).

As you can see, this particular website looks like it's just a work-in-progress. Let's keep this as a note, and try the other open HTTP Port, 31331

Now we have something cool here! This looks like a more complete, production-ready website. As a pentester, it's our job to explore every corner of this website looking for potential input areas, hidden information and every sorts of alluring things we can add to our report. In my case, I like to explore hidden directories first, since there are a lot more than meets the eye when it comes to web applications. Common practices such as running GoBuster or DirBuster can be really useful, but I like to start simple before running my big, brute-forcing guns. The more you explore web applications, the more you'll notice a pattern when it comes to hidden directories, and then you can also start writing your own personal list of directories you can start checking out for. In my case, considering how important it is for applications nowadays to have a good SEO policy in their websites, I like to start from a very common robots.txt file.

But first, what is a robots.txt file? To make it short, when Google bots are scrapping your website after keywords to enhance your SEO strategy and put it in the front page in every google search, they will look for what they need in every directory. However, you can indicate to them which directories they should NOT look for any keyword, and the way you indicate it to them is by configuring these directories in the robots.txt file. The reasons may vary, but usually the directories found in this file are really important for administrative work in the website, and they are also hidden from the public eye, which means that some really good intel can be found there. Some other files and folders that can bring you good information are admin, login and upload pages. But let's start with :31331/robots.txt to see what we can get.

Nice! We got some cool information about the site map, so let's go after it now.

A lot more information for us! Now we know about 2 pages we can explore (index.html is just the landing page), and we didn't even had to run a brute-forcing tool for that!

Looking for the what.html page, we can notice that it's just a work in progress page. We can look for any hidden in the source code, but apparently there are nothing outstanding hanging there.

When we go after that partners.html page, however, there is a login form there, just chilling. Login forms are amazing doors to the inner workings of a company, and exploiting them can be a really damaging.

Now, if we look in the source code, we are able to see some intriguing findings.

Here we have a link to an api.js script, and after clicking on it, we are able to find the script's code.

There is a really cool line of code here, and this is the following:

const url =http://${getAPIURL()}/ping?ip=${window.location.hostname}``

According to the code, it will try to ping the API to check if it's working. We can look for more information on this, by tweaking the parameters a bit and running it on our browser. Let's first it try with:

http://10.10.147.25:31331/ping?ip=10.9.208.115

Let me explain what I changed here. I switched the **${getAPIURL()}** field to our target's IP + the HTTP Port we are at right now. And I changed the **${window.location.hostname}** parameter to our machine's IP, in order to test if it can ping back our machine.

Hmmmm, apparently it didn't work as expected. However, if you remember, there are another HTTP Port open in this application, the 8081. Let's try with this one now by running

http://10.10.147.25:8081/ping?ip=10.9.208.115

Okay, this is way better! The output confirms that we can actually run and see terminal commands in our web browser! Now let's run a ls, the Linux command to list all the files in a given directory, with:

http://10.10.147.25:8081/ping?ip=ls``

It's a similar command from what we've used before, but now with a ls at the end instead of our machine's IP parameter.

Now we have some more information about a database related to our target application, that can be really useful for us.

So let's start exploring this database by running a cat on it. The whole command would be cat utech.db.sqlite, so we need to write http://10.10.147.25:8081/ping?ip=cat utech.db.sqlite`` in our browser, which returns:

Awesome! Now we have some (hashed) credentials that we can use. I mean, as soon as we decode them. So let's start creating some new files to store them in our machine.

To crack the hashes, first we gotta know which hashing algorithms were used to hash them in the first place. We can run hash-identifier f357a0c52799563c7c7b76c1e7543a32 in order to retrieve information about it.

hash-identifier has disclosed that it's possibly a MD5 hash that we are dealing with.

To look for a reverse lookup (since hashes are impossible to crack) we can go to https://md5hashing.net/hash. This website is linked to a database of hashes and their original values, and it compares whatever string it gets as input with values stored in the database in order to "decrypt" them.

Nice, so now we have full credentials for one of the users! r00t:n100906 is something we can use later, for sure. Now, let's repeat the same steps with the other user.

And then, finally:

However, now we didn't get a decrypted value from this. Which is okay, not all values can be stored in the decryption database, and sometimes - even if you have a specified wordlist with all the possible values for a credential - you won't get a result from it. That's a good point for the company (even though leaving hashes accessible to malicious actors is a massive negative point), so for brevity reasons we can move on to the next phase.

Phase 4 - Vulnerability Analysis

In this phase the pentester will leverage the systems and applications and their correspondent vulnerabilities. They will analyze the scope for each attack vector found out until this moment, and they will consider the best way to exploit them. In our case, we know that our target runs a FTP on port 21 and a SSH on port 22. It also runs some websites and, most importantly, even a login page. You can abuse your Google-Fu skills, and also get any information available and use https://www.exploit-db.com/ or searchsploit on the command line. In my personal taste I like to try low-hanging fruits first, or simply the obvious stuff. It's pretty common to overengineer your attack and try some extreme techniques, but sometimes you just need to keep it simple to attest that your target system isn't that secure.

That being said, we stand here with a lot of useful information about our target system already, including some credentials and three possible places where we can use them to move on to the Exploitation Phase: FTP, SSH and the login page. With that in mind, let's do as I said and try those.

Phase 5 - Exploitation Phase

The Exploitation phase is the moment where you gather all the information acquired in the previous phases, and apply them with the sole objective of bypassing the target system's defenses and establish access to it. As I mentioned before, if the Vulnerability Analysis Phase was carefully planned, this current phase should be a precise attack. With our plan to use the credentials in mind, let's go and execute it.

By going to the :31331/partners.html, which is a login page, we use the credentials we found during the Enumeration phase, but it leads to a dead end.

That's okay. We keep this as a note, and move on to our second vector, the SSH on port 22. By using the credentials there, we can get into the system!

Those credentials can also be used to log into the FTP service, as showed in the screenshot below.

Okay, now that we have access in multiple fronts, we can say that we performed a successful Exploitation Phase.

Phase 6 - Post-Exploitation Phase

This phase is the proof that a well-executed penetration test won't finish once the pentester obtained access to the machine. Now it's time to move on and try to (if previously agreed on the pre-engagement phase, of course) 1) Observe which sensitive files that can be accessed by a possible attacker 2) Try to escalate privileges 3) Cause denial of service 4) Maintain and persist access for later exploitation.

We can start looking around for critical files, but a good way a CTF-based box such as the ones we can find on TryHackMe and HackTheBox emulates these files is by using flags. One has to keep in mind that flags alone are not what you will see on a real-world scenario. That being said, let's try to look for the root user SSH private key, as specified by the original box exercise.

To check which programs can be accessed by the super user on Linux, I like to run sudo -l. This can be a good way to enumerate attacking vectors for you to escalate your privileges to the root user. However, in this specific case, this didn't work.

As we can see in the screenshot above, the r00t user (just a regular user, not the actual root user) is part of a docker group, which can be a way to escalate privileges. We can check this out and confirm our theory by running LinEnum, that we can find on https://raw.githubusercontent.com/rebootuser/LinEnum/master/LinEnum.sh. Once we access it, we just need to copy the raw code, move back to the r00t base directory, create a linenum.sh file (using nano or vim, for example) and paste it there, save the file and make it executable by running chmod +x linenum.sh ****

We can now run ./linenum.sh > lin to run the script and save the information in a newly created lin file. It might take a while, but once it's done we just need to open that file to get the following outcome:

As the script mentioned there, looks like we're hosting Docker, and we could possibly misuse this group's permissions.

An awesome resource for privilage escalation is the GTFOBins, and it has a specific section just for docker exploitation, as we can find here - https://gtfobins.github.io/gtfobins/docker/#sudo

This one specifically explains how we can move to sudo by misusing Docker permissions, and we just need to run a simple command:

sudo docker run -v /:/mnt --rm -it alpine chroot /mnt sh

However, this command will try to get a vanilla docker box - alpine - and in our case it won't work properly. With a simple tweak, however, we can change this. We just need to switch from alpine to bash and remove the sudo command, since we're not currently running as sudo*:*

docker run -v /:/mnt --rm -it bash chroot /mnt sh

After a short wait, the exploit concludes and we have sucessfully escalated our privileges

Now that we are running out the highest of the privileges, we can start looking for useful information - as it's mentioned as the main objective of the post-exploitation phase.

Here we can find some critical, sensitive information, such as this private.txt file and the SSH keys. This is an awesome finding, and for the context and scope of this box, it also concludes our post-exploitation phase.

Phase 7 - Reporting Phase

This is the point where you are going to conclude all processes, findings, attacking vectors and analysis from your whole penetration test assessment, in a clear, objective language that will make it easy to understand for the stakeholders that will use it to lead their decision-making process in the company. This is arguably the second most important Phase in the whole process, sometimes even more important than the Information Gathering Phase, because if it's not clear, the whole assessment won't be useful at all to the company.

There are a lot of models and layouts for you to create your own reports, but the most important aspect of it is the need to be understood. Details are also important here, and a good guideline can be found at http://www.pentest-standard.org/index.php/Reporting

Conclusion

This concludes this post, which was written with the intention to kickstart people into Pentesting and Cybersecurity. However, this isn't a final read, just a suggestion on how you can start developing your own methodology. I recommend you start researching on other people's methodologies, as well as practice a lot of techniques on CTFs and even bug bounties. This will get the gears spinning and making things easier to understand in the long run.

I wrote another post on how to get people started in Cybersecurity that can be useful for you to get a bit of a direction, so if you need to start somewhere, you can go there. And keep in mind that Cybersecurity is an ever-evolving field, so never stop learning. Try new stuff everyday, read a lot, get new perspectives on subjects you thought you had mastered, and stay humble! You'll never know everything, so be respectful with people that are just starting. Help them and try to learn something from them as well, because I do believe everyone has something to teach to someone else, no matter their levels of experience.

Keep on practicing, and connect with me on Twitter to ask any questions and give some feedback (or just chat!)