Hi , It's Me Maniesh Neupane(Pwn4arn).

 In Pixel Flood Attack,  An attacker attempts to upload a file with a large pixel size that results in consuming server resources in a way that the application may end up crashing. This causes a DoS (Denial of Service) Attack when the server tries to handle the image. How to test for this vulnerability? In order to exploit Pixel Flood Attack, one can try the following steps: 1:) Navigate to https://www.resizepixel.com/ and resize an image with 64250*64250px. 2:) Go to the vulnerable application having the option to upload an image file. 3:) Upload the file generated from “step-1” and observe the server’s response. 4:) If the server takes too long to respond or if the application became inaccessible, confirm with another device, if the lag/accessibility issue happens, the application is vulnerable to pixel flood attack. (If the website’s server gets timed out, it means that the server is vulnerable).              Thank you  !                  Maniesh Neupane🇳🇵 Twitter:    https://twit

 Uber attack methodology: simplified with infographic  ; 1. The hacker socially engineered an Uber employee to steal their credentials. 2. They then accessed Uber's VPN with the stolen credentials to connect to Uber's internal network. 3. While scanning Uber's internal network, the hacker discovered a shared network folder that contained PowerShell scripts. 4. The hacker identified a PowerShell script that included the username and password for an administrative user of a Privileged Access Management (PAM) tool, which stores secrets (e.g. credentials, keys, etc.). For Uber, this contained secrets for many internal systems and applications. 5. The hacker used secrets stored in PAM tools to access Uber's systems and applications. With control of this account, the attacker claimed, they were able to gain access tokens for Uber's cloud infrastructure, including Amazon Web Services, Google's GSuite, VMware's vSphere dashboard, the authentication manager Duo, and

  IDOR - Background Info ; In its simplest and most common form, an IDOR vulnerability arises when the only input required to access or replace content is from the user. In our first example, whats stopping someone from checking another users ID and getting all their information ? This code example demonstrates how this can occur. The server is taking in the users id and directly displaying that information. To fix this the server shouldn't believe the user, but rather extract the session ID and check on the backend. In case of Serverless checks, the application must have a mechanism to check a signature (JWT).               Forced Browsing ; Similar to IDOR, forced browsing can occur if the application exposes a direct reference to a file location. Here an attacker can visit the link and retrieve the image even though it is a private image.         UUID - Safe? Think not.. Consider the server accepts arbitrary uuid's from the user, yet the uuid is too long and random to guess.