Fardeen A. 🇮🇳 🇵🇸
1.5K posts

Fardeen A. 🇮🇳 🇵🇸
@insecrez
🌐| Security Engineer 🐞| Part-Time EH ⚡️| Memer 🫂| Need professional help.? Book now 👇👇









Your choosing the wrong programs if your getting dupes on 9+ CVSS reports, or your scoring them wrong. The vast majority of programs have SLAs to fix High and Criticals (most companies have to fix criticals in 7 days or less, highs in 30 days or less), and if they arent fixing them that fast, you are wasting your time because they dont care about security (they are also likely violating their own published docs in their SOC 2 and other Audit stuff, which is another indicator they dont care about security).



Only a psycho can sleep at 3am & wake up at 7am












Critical: Client-Side Encryption Collapse site.com ↓ some_javascript.js ↓ Line no 80519 → encObj + base64 key ↓ atob(val) → "Encoded_Password" ↓ CryptoJS.AES.decrypt(encObj, passphrase) ↓ 55 configuration properties → 107 operational secrets exposed → Azure AD client_secret → OAuth client_credentials flow → RSA public keys → Forge encrypted /enc/ API requests → HMAC key → Backend-accepted payload signing → Direct Line token → Production chatbot access → Monitoring / RUM keys → Telemetry manipulation → Auth0 + reCAPTCHA config → Auth flow manipulation → 31+ encrypted authentication endpoints mapped ↓ Use extracted Azure AD credentials ↓ Request token from Microsoft OAuth endpoint (client_credentials) ↓ Receive valid JWT with high-privilege role (e.g., AllAccess) ↓ “Super token” accepted by backend across protected API routes (No user interaction required, role-based authorization granted) ↓ All sensitive authentication and account endpoints were wrapped in client-side hybrid encryption → Every request payload encrypted in browser → AES-256-CBC used for body encryption → RSA-OAEP used to wrap per-request AES key → Server accepts any request that decrypts successfully → Decryption success treated as implicit authorization ↓ Reverse-engineer encryption module (@**6246) → Algorithm: AES-256-CBC + RSA-OAEP (SHA-512) → Random 32-byte AES key per request → IV derived client-side → AES key wrapped with embedded RSA public key (promocode_pem) → Final format: { "key": base64(RSA_key), "body": hex(AES_ciphertext) } ↓ Hook JSON.stringify + XMLHttpRequest ↓ Capture plaintext BEFORE encryption (credentials, OTPs, tokens) Capture encrypted wrapper AFTER encryption Capture correlated server responses ↓ Analyze MFA implementation ↓ IP-based rate limiting only (lockout resets on IP change) OTP expiration not strictly enforced server-side Encrypted payload fields trusted after decryption ↓ Mass takeover method ↓ 1. Trigger MFA or password reset 2. Rotate IP to bypass rate limiting 3. Reuse or brute-force OTP under weak enforcement 4. Complete password reset flow 5. Authenticate as victim 6. Capture decrypted OTP and auth tokens via runtime hook 7. Reuse valid 2FA tokens for subsequent authenticated requests ↓ Full attack chain achieved: → Extract secrets from client bundle → Generate high-privilege JWT (“super token”) → Read any plaintext request (credentials, PII, tokens) → Forge any encrypted request the server will accept → Bypass MFA protections via IP rotation → Reset victim passwords → Decrypt authentication flows in runtime → Mass account takeover







