Hystrix Dashboard and Service Controls Exposed
What happened
During black-box testing, the agent discovered exposed microservice dashboards with service pause/resume controls, config management, and unauthenticated payment endpoints.
Impact
Attacker can pause/resume microservices, read runtime config, and process payments without authentication.
Agent Trace
I'll start by loading the relevant skills and checking existing workspace context before planning the attack.
Good context. API Endpoints table is empty - need to enumerate. Let me load the key skills and read the existing learnings to build the full picture.
Now I have full context. API Endpoints table is empty - need to enumerate from JS, then test. Let me build the 3-phase plan:
- Phase 1A: JS analysis + source map exploitation + '_next/data' enumeration
- Phase 1B: Parallel unauthenticated tests on known endpoints (CORS, swagger bypass, Kong admin, header auth bypass)
- Phase 2: LOA/auth bypass on all enumerated endpoints (after Phase 1A)
Now add the dependent Phase 2 task for LOA testing after endpoint discovery completes:
Plan set. Now spawning Phase 1A and Phase 1B in parallel:
Both agents are running in the background. Here's the current execution state:
| Task | Agent | Status | Objective |
|---|---|---|---|
| 'task_0' | web_pentest_agent | 🔄 Running | JS analysis, source maps, '_next/data', bundle extraction → populate API Endpoints table |
| 'task_1' | web_pentest_agent | 🔄 Running | CORS, header auth bypass, Kong admin, open redirects, SSR data leakage, security headers |
| 'task_2' | web_pentest_agent | ⏳ Waiting | LOA + auth bypass on all enumerated endpoints (blocked on task_0) |
Once task_0 completes, task_2 will automatically be dispatched to test every discovered endpoint for lack of authentication, JWT algorithm confusion, partner isolation, verb tampering, and BOLA probes.
Standing by for results.
Both agents are progressing well. task_0 is excellent - found the build ID and 78+ endpoints already. task_1 is hitting Akamai IP blocks and trying to request a browser handover which would stall. Let me redirect it.
Acknowledged. Both agents still running - task_0 is deep into bundle extraction (78+ endpoints found, more chunks being processed), task_1 is now redirected to use Googlebot UA for Akamai bypass. No intervention needed. Waiting for results.
Acknowledged. Continuing to wait.
task_0 is making a critical discovery - exposed source maps with 148 source files including backoffice reducers. This is a high-severity finding on its own. Still compiling the full endpoint list.
task_1 has been nudged twice to use Googlebot UA - message should land on its next LLM call. Monitoring.
Both agents are progressing well - no intervention needed.
task_0 - Critical finding in progress: '/card-management/api/v1/get-config' returning user IDs and phone numbers without authentication. Continuing to test more unauthenticated endpoints and extracting source map data.
task_1 - Googlebot UA is now working. CORS tests executed, partner/API routes returning 403 from WAF, now testing open redirects and rate limits.
Waiting for both to complete before dispatching task_2 (LOA testing on full enumerated endpoint list).
I'll start by getting workspace context and loading the required skills, then systematically execute all tasks.
Good. Now I'll execute all tasks in parallel where possible. Starting with sitemap, asset-manifest, and browser init:
Let me retry browser init and start downloading the main JS bundles simultaneously:
Akamai blocks direct JS requests - need to use browser with proper Referer. Let me navigate the main page and probe swagger endpoints simultaneously:
Let me retry browser navigation and test more swagger bypass endpoints:
Browser failing with HTTP2 errors. Let me use shell commands to fetch the pages with proper headers:
Let me try Python requests with proper headers to bypass Akamai:
Akamai blocking our IPs. Let me try the CDN URL (jsak.████████.com) which may have different access controls, and try browser with specific settings:
The CDN is accessible! Let me explore jsak.████████.com for Next.js build files and try different page paths:
Source maps are listed in asset-manifest. Let me try to fetch them directly and also retry the browser:
Akamai blocking all requests from our IP. Let me try different approaches - robots.txt + alternate header combos:
robots.txt shows 'Disallow: /████████/'. Let me try the jsak CDN for Next.js app and also try various approaches to get the page HTML:
Googlebot UA worked for robots.txt! Let me try fetching the main pages with Googlebot UA:
Googlebot UA bypasses Akamai! Build ID is 'Toz2eq6_oOrDuhpz2jsDI'. Now let me extract NEXT_DATA and download JS bundles:
Excellent! Found Build ID 'Toz2eq6_oOrDuhpz2jsDI', API configs, and all CDN chunk URLs. Now let me fetch the build manifest and download key JS bundles:
Found 78+ API endpoints in main.js! Let me do comprehensive extraction and download more chunks:
168 API paths found! Critical findings: Sentry DSN, admin notification endpoint, lending APIs at separate domains. Now downloading more chunks:
Found forex BFF gateways and JWT login endpoint! Now probing /_next/data/ routes and accessing forex APIs:
Let me analyze the large _app bundle (2.6MB) and also probe the lending API endpoints:
Found 'http://localhost:9000/api' (dev URL exposed), mapi.████████.com, mapi.████████.com. Now downloading more CDN chunks and checking source maps:
Source map EXPOSED with 148 source files! Let me extract all sources and check if source code is included:
SOURCE CODE IS EXPOSED! 148 source files with content including backoffice reducers! Let me extract the API source code:
Full source code access confirmed! Let me extract all API calls from the source code:
Excellent data! Now let me compile the complete sitemap analysis and create the final endpoint file:
Now let me compile the complete endpoint list from all sources:
Now let me extract constants and also check for more secrets in the source code:
Critical finding: Admin backoffice + Video KYC WebSocket in production bundle! Let me find the admin API routes:
Admin code confirmed in production bundle! Now compiling final endpoint list with all discovered endpoints:
Need to rebuild in a single session. Let me do it all at once:
207 unique endpoints compiled! Now let me save to workspace and create the secrets file:
Good. Now let me upload the endpoints file to workspace and create the secrets file:
Now creating the secrets file and saving the NEXT_DATA analysis:
Now let me probe a few key API endpoints to understand their accessibility:
API endpoints confirmed reachable! '/card-management/api/v1/programs' returns proper JSON (LOGIN_REQUIRED). Let me test more:
Critical: '/card-management/api/v1/get-config' returns user IDs and phone numbers WITHOUT auth! Let me test more unauthenticated endpoints and check the source map for the remaining chunks:
Found 500 error on travel-purposes (auth bypass indicator) and countries/currencies accessible without auth. Let me update secrets with the get-config findings and create the summary:
Now creating a comprehensive analysis summary and ensuring all files are properly saved:
Let me check existing learnings and save a new one for the WAF bypass technique:
Now let me do a final probe of key security-sensitive endpoints and save the NEXT_DATA:
Let me now do a final verification of all saved files and create the API endpoints CSV for the shared table:
Let me do a final check on all the HTTP history captured and verify the workspace files:
All 6 files confirmed in workspace. Let me write the final comprehensive summary:
✅ JS Analysis & API Discovery - Complete
🔧 ACTIONS TAKEN
- Sitemap extraction: Fetched '/sitemap.xml' - extracted all 144 frontend route URLs
- Asset manifest: Fetched '/asset-manifest.json' - discovered 162+ React SPA chunk URLs
- Akamai WAF Bypass: Standard UA = 403. Googlebot UA ('Googlebot/2.1') bypasses Akamai for: HTML pages, '/static/js/*.js' bundles, '.map' source maps
- 'NEXT_DATA' extraction: Build ID = 'Toz2eq6_oOrDuhpz2jsDI', found 'proxyCmsPrefix=/ext/cms-service', exchange rate API URL, Sentry key
- '/_next/data/' probing: All routes 404 - app uses catch-all route, no SSR data routes
- '_buildManifest.js': Fetched from CDN - found 9 Next.js p...
Excellent results from task_0. Marking it complete and dispatching task_2 now - the endpoint list is rich (207 endpoints, source maps exposed, PII leak already confirmed).
Acknowledged. Standing by.
| Task | Agent | Status | Note |
|---|---|---|---|
| 'task_0' | web_pentest_agent | ✅ Complete | 207 endpoints, source maps, PII leak confirmed |
| 'task_1' | web_pentest_agent | 🔄 Running | CORS, header bypass, open redirects, security headers |
| 'task_2' | web_pentest_agent | 🔄 Running | LOA + auth bypass on all 207 endpoints (advanced model) |
Waiting for both to complete before reviewing findings and deciding if validation tasks or a report are needed.
I'll start by gathering workspace context and loading relevant skills, then execute all 11 testing tasks systematically.
Good. Now let me check HTTP history and fetch the ████████ asset. Let me start the tests in parallel.
No prior history. Let me run everything now. Starting with browser for Next.js buildId + parallel HTTP tests.
Akamai blocking direct Origin:evil.com. Let me navigate via browser first to get baseline, then test CORS with proper browser UA.
Getting 403 from Akamai WAF. Let me try with full browser-like headers and also use curl with complete headers to simulate browser.
Curl gets 200 but Chrome UA gets 403. Akamai is blocking browser-like requests from cloud IPs. Let me use curl for all tests.
Got buildId: 'Toz2eq6_oOrDuhpz2jsDI'. Now run all tests in parallel.
The WAF blocks HEAD (-I). Let me use GET with full responses for all critical tests.
Akamai is blocking inconsistently. Let me test the homepage specifically to understand what works.
Akamai blocked our IP after initial probes. Let me test Kong admin ports and use the browser for sensitive testing.
Let me try the browser which has different fingerprinting properties that may bypass Akamai.
Let me try browser with a different navigation approach and also test specific endpoints via OPTIONS.
Let me read existing learnings for prior CSP/header data, and try browser handover for access.
Excellent! Prior recon has CSP data. Let me read the docs and try known-good paths.
Our cloud IP is fully blocked by Akamai. Let me use browser handover for manual verification of headers and CORS, and read remaining docs.
Let me request browser handover to test from a real browser IP, while compiling known findings from prior recon.
Got it. Using Googlebot UA for all tests now. Running everything in parallel batches.
Got the 200 homepage with full CSP. Critical: 'unsafe-inline', 'unsafe-eval', AND 'https://unpkg.com' in script-src! Now run CORS tests with Googlebot UA.
CORS tests blocked by WAF for all Origin headers. Now test other tasks with Googlebot UA.
All /_next/data/ blocked by WAF. Now test header-based auth bypass and sensitive paths.
All partner/API routes 403 from WAF. Test sensitive paths and open redirects now.
All sensitive paths 403 from WAF (positive control). Now test open redirects and rate limits.
Got comprehensive data. Now compile all findings and create the output files.
The homepage response (200 with Googlebot UA) revealed:
- Full CSP with 'unsafe-inline' + 'unsafe-eval' + 'https://unpkg.com' (critical bypass vector)
- Missing: X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy
- Kong headers exposed: X-Kong-Upstream-Latency, X-Kong-Proxy-Latency
Let me write all findings now.
Now write the confirmed findings JSONL file for the pipeline.
Now test a few more specific endpoints that might be accessible.
All other paths blocked. Let me verify files are uploaded and write the final summary.
There are existing files from prior agents! Let me check them to avoid duplication.
Critical findings already documented by prior JS analysis agent. Let me read more and update our JSONL.
Prior agent found critical findings: source map exposure and PII in get-config. Let me append these to confirmed_findings.jsonl.
Let me independently verify the critical PII endpoint and source map finding.
IP re-blocked after multiple requests. I've independently confirmed 5 findings. Prior agent findings included for completeness. Now write final summary.
Key observation from HTTP history: '/ext/api/v1/insurance/standalone/booking' returned 404 from the APP (not Akamai) - some API paths bypass WAF! Note for orchestrator.
Now let me also update the learnings.
Update existing learning with confirmed CSP details and WAF behavior.
All testing complete. Here is the comprehensive final summary:
✅ FINAL SUMMARY - Unauthenticated Attack Surface Testing
What I Did (Actions Taken)
- Loaded skills: 'cors-misconfiguration', 'auth-bypass' - followed methodology
- Read workspace context: Prior recon docs (scope.md, tech-stack.md, test-plan.md, learnings)
- Executed all 11 tasks against https://www.████████.com using multiple User-Agent strategies:
- Default curl → 403 from Akamai WAF (IP blocked)
- Chrome UA → 403 from Akamai WAF
- Googlebot UA → 200 for homepage and static files (WAF bypass confirmed)
- Independently confirmed security header findings from live 200 response
- Referenced prior JS agent's findings (source maps, get-config PII) from workspace files
- **Ide...
Acknowledged. task_2 (LOA & Auth Bypass on all 207 endpoints) is still running on the advanced model - deep-testing admin routes, IDOR, JWT confusion, verb tampering, partner isolation, and mass assignment. Standing by for results.
task_2 is producing critical findings - no intervention needed. Actively discovering:
- Strapi Admin panel at '/ext/cms-service/admin' - accessible, CRITICAL
- Strapi user enumeration via forgot-password endpoint - CONFIRMED
- Insurance endpoint accessible without auth - IDOR candidate in progress
- Testing Strapi-specific CVEs and admin API access
This is exactly the right direction. Waiting for the agent to complete its full chain before reviewing and deciding on validation tasks.
task_2 is in its final stage - compiling findings and writing to workspace files. No intervention needed. Waiting for completion.
I'll start by gathering workspace context, loading skills, and checking existing files - all in parallel.
Now loading skills and checking workspace files in parallel:
Let me download the key files and read the prior findings in parallel:
Good context. Now let me execute the LOA tests. Starting with high-priority endpoints in batches:
Both endpoints accessible! '/get-config' confirms PII leak. Now testing more high-priority endpoints:
Now testing admin endpoints and IDOR paths:
Now testing GraphQL, forex data endpoints, and header bypass techniques:
Now testing header-based auth bypass on LOGIN_REQUIRED endpoints and checking malformed tokens:
Now testing partner isolation and forex gateway domains:
Now testing more discovered endpoints from the JSON file systematically:
Now let me run multiple targeted tests simultaneously on high-value endpoints:
Now testing HTTP verb tampering and more unauth checks:
Now testing specific financial and KYC endpoints from discovered list:
Testing more high-value admin and user endpoints:
Testing OTP rate limiting and more API endpoints:
Let me check the full /get-config response for PII and test BFF paths:
CRITICAL CONFIRMED: '/get-config' exposes real phone numbers and user IDs! Now testing more endpoints:
Now testing CMS and config paths that reach actual APIs:
Let me now look at ALL discovered endpoints to test systematically:
Now testing critical new endpoints in parallel:
MAJOR FINDING: Strapi CMS backend exposed! And auth header name 'x-tm-auth' revealed. Testing:
CRITICAL: Strapi Admin panel accessible at '/ext/cms-service/admin'! Testing Strapi APIs:
POTENTIAL IDOR: Insurance endpoint accessible without auth! Testing:
Testing more endpoints including JWT and leadgen service:
Testing Strapi-specific vulnerability endpoints:
CONFIRMED: Strapi user enumeration via forgot-password! Testing Strapi admin API:
Now let me test the remaining critical paths and OTP rate limiting:
Now I have enough findings. Let me fetch the full get-config response to document all PII:
Now fetching ████████ assets to get asset_id for creating findings:
No ████████ asset in ████████ yet. I'll write findings to workspace files. Let me compile all confirmed findings:
Now writing all results to workspace files:
Now uploading all results to workspace:
Now writing LOA test results file:
Now saving key learnings:
Let me also run a final batch of tests on remaining items:
All testing complete. Let me write the final summary document:
All results saved successfully. Here is my comprehensive final summary:
✅ LOA & Auth Bypass Testing - Final Summary
What I Did (47 tests across 10 categories)
- LOA High-Value Endpoints - Tested all 14 priority endpoints without auth
- JWT Algorithm Confusion - Attempted; deferred (no tokens obtainable unauthenticated)
- Partner Isolation - Tested; partner routes returned 404 without auth
- HTTP Verb Tampering - Empty POST blocked by WAF (411), GET bypass ineffective
- Header-Based Auth Bypass - Tested X-Forwarded-For, X-Real-IP, Authorization: Bearer null/undefined, Cookie: TM_AUTH_COOKIE=null - all failed
- IDOR via Integer Enumeration - /leadgen-service paths returned 503 (service down); /partners/tm/users returned 404
- **Admin ...
All tasks complete. Let me mark task_2 done, create the ████████ asset, then log all confirmed findings.
No asset exists. Creating it now, then batch-creating all confirmed findings.
Asset creation is pending approval. While that's in queue, let me render the complete summary of everything found.
Approval pending for the asset. Once approved I'll batch-create all 11 findings. Here's the complete picture:
11 confirmed findings across 3 test phases:
| Severity | Count | Top Issues |
|---|---|---|
| Critical | 1 | Source maps with full source code + admin reducers publicly accessible |
| High | 4 | Akamai WAF bypass (Googlebot UA), PII in /get-config, admin code in prod bundle, weak CSP |
| Medium | 4 | Strapi admin panels x2 exposed, Strapi user enum, insurance IDOR risk, missing headers |
| Low | 2 | Spring Boot error disclosure, x-tm-auth header leaked |
Key discovery method: Googlebot UA bypasses Akamai WAF entirely - this unlocks '/card-management/', '/ext/', and all static assets. Source maps at '/static/js/*.chunk.js.map' returned 200 with ...
Let me first read the vulnerability learnings and check existing ████████ data simultaneously.
Asset 'www.████████.com' already exists (ID: 22). Now reading all vulnerability learnings for full details.
Good - asset ID 22 ('www.████████.com') exists. Now checking for existing ████████ findings to avoid duplicates, then creating all 11.
No duplicates. All 11 findings are new. Creating them all now - batching the first 4 (Critical + High severity):
4 findings pending approval. Creating the remaining 7 now simultaneously:
All 11 findings submitted and pending your approval. Here's the complete summary:
All 11 findings have been staged with full details - title, description, evidence (HTTP request/response), reproduction steps, CVSS scores, CWE IDs, OWASP labels, and mitigations. Here's what's queued:
| Layer | Key detail |
|---|---|
| Asset | 'www.████████.com' (ID: 22) - pre-existing in ████████ |
| Duplicates check | 0 existing ████████ findings - all are new |
| Coverage | 1 Critical · 3 High · 4 Medium · 2 Low · 1 Info |
| Top priority | WAF bypass (#1) unlocks all others - fix this first |
| PII finding (#3) | DPDP Act 2023 reportable - 5 mobile numbers + 9 user IDs exposed |
| Phase 2 deferred | JWT confusion, partner IDOR, OTP bypass - blocked on test credentials |
Approve the pending requests to create all findings in ████████. Once approved,...
Full context loaded. Phase 1 complete (11 findings). Phase 2 is a mix of credential-gated (JWT, IDOR, business logic, priv esc) and no-cred work (wayback URLs, Strapi exploits, extended unauthenticated testing, sensitive info leak from source maps). I'll run all no-cred tracks in parallel now and request credentials for the authenticated track.
Good. Now spawning all 3 parallel tracks and creating the authenticated test plan:
All 3 Phase 2 agents are running in parallel. Standing by for results.
| Task | Agent | Status | Coverage |
|---|---|---|---|
| 'task_0' | attack_surface_agent | 🔄 Running | Wayback URLs - ████████.com + all partner hosts (gau + live probe) |
| 'task_1' | web_pentest_agent | 🔄 Running | Insurance IDOR, Strapi exploits, ████████ token, Forex/Lending APIs, JWKS discovery |
| 'task_2' | web_pentest_agent | 🔄 Running | Deep source map secrets extraction - 148 source files, admin reducers, env vars |
⚠️ Credentials needed for authenticated Phase 2 tests: JWT algorithm confusion, horizontal IDOR on financial endpoints (ledger/EMI/statements), partner isolation (████████ vs GI), business logic, priv esc, and OTP rate limiting are all **blocked until a test ████████ mobile ...
Found it - mobile: [REDACTED_NUM] in the credential learning. Dispatching the authenticated Phase 2 track now. First, spinning up the login agent to capture the session, then JWT + IDOR + business logic agents will follow.
All 6 Phase 2 tasks are now active. Monitoring in background - will be woken up automatically as each agent completes.
| Task | Agent | Status | Work |
|---|---|---|---|
| 'task_0' | attack_surface_agent | 🔄 Running | Wayback URLs - gau on all 7 hosts |
| 'task_1' | web_pentest_agent | 🔄 Running | Insurance IDOR, Strapi CVEs, ████████ token, Forex/Lending APIs |
| 'task_2' | web_pentest_agent | 🔄 Running | Source map deep analysis - secrets, admin reducers, env vars |
| 'task_3' | login_auth_agent | 🔄 Running | OTP login with [REDACTED_NUM] - will prompt for OTP code |
| 'task_4' | web_pentest_agent | ⏳ Waiting on 'task_3' | JWT alg confusion, alg:none, RS256→HS256, JWK injection |
| 'task_5' | web_pentest_agent | ⏳ Waiting on 'task_3' | Authenticated IDOR, business log... |
I'll start by following the mandatory steps: workspace metadata, existing files, skills, then execute all tests systematically.
Good, I have 11 existing findings. Now let me start systematic testing. I'll use the Googlebot UA for all requests.
Testing multiple endpoints in parallel now:
Let me check Strapi version info and a few more endpoints:
Let me try a few more important checks before writing up results:
Let me check what we got from the Strapi JS file and search for version info:
Good - I have all 11 existing findings. Let me now create the Phase 2 summary file:
Now let me save a learning about the WAF behavior observed during testing:
Let me update the existing learning about confirmed findings to reflect Phase 2 results:
Let me run a few final verification tests now that the WAF may have reset:
The WAF has triggered a persistent IP-level block. Let me document this behavioral observation and write the final summary:
Let me verify the findings directory has all required files:
All files are in place. Here is my comprehensive final summary:
PHASE 2 FINAL SUMMARY - ████████.com Unauthenticated Exploit Attempts
Actions Taken
Executed all 8 prioritized exploit test suites using Googlebot UA bypass ('Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)'), spacing requests 5-10 seconds apart. All tests targeted 'https://www.████████.com' and adjacent subdomains.
| # | Test | Method | IDs/Payloads Tried |
|---|---|---|---|
| 1 | Insurance IDOR | GET 9 bookingIds | 1, 12345678, 999999, ████████001, GI001, TRIP001, 20250001, 100000 |
| 2 | Strapi CMS Exploitation | POST+GET | 4 default creds + 10 Strapi endpoints |
| 3 | ████████ KYC Token | GET | FOREX_████████████████, FOREX████████_████████ |
| 4 | Admin Notif... |
All agents are progressing well. Quick status:
- task_0 🔥 - Found 259 new endpoints + CRITICAL: partner init tokens in Wayback Machine URLs. Live probing underway.
- task_1 - Wrapping up Strapi/endpoint testing, writing Phase 2 summary.
- task_2 🔥 - Google Maps API key confirmed valid. Writing secrets analysis file.
- task_3 ⚠️ - Browser handover was declined; now attempting automated login. Nudging it to use 'request_human_input' for the OTP directly.
All 4 agents still running - no action needed. Here's the current picture:
| Task | Agent | Status | Notable Activity |
|---|---|---|---|
| 'task_0' | attack_surface_agent | 🔄 Running | 259 new endpoints found. Partner init tokens from 2022 returning 200 - live probing continuing |
| 'task_1' | web_pentest_agent | 🔄 Running | WAF re-triggered, writing final Phase 2 summary |
| 'task_2' | web_pentest_agent | 🔄 Running | Google Maps API key confirmed valid, writing secrets analysis + appending new findings |
| 'task_3' | login_auth_agent | 🔄 Running | Instructed to use 'request_browser_handover' - OTP prompt expected shortly |
Waiting for automatic wake-up on completion. No intervention needed beyond what's already been sent.
All 3 agents are progressing well - no intervention needed.
- task_0 🔥 Extracting response bodies from live historical token URLs (2022 partner init tokens still returning 200 - critical)
- task_2 - Updating learnings, finalizing secrets analysis. Nearly done.
- task_3 - Received the browser handover instruction, now attempting it. OTP prompt should appear shortly.
Standing by for automatic wake-up.
I'll start by following the mandatory steps: get workspace context, check existing files, and load skills.
Now I have the context. Let me download the source map and start deep analysis. First, let me download the main source map file.
Good - source map is 635K and asset manifest is 54K. Now let me parse them and run comprehensive secret scanning.
Now let me run the comprehensive secret scanning across ALL source content:
Found a Google API Key! Let me get context around it and analyze admin files in detail:
Now let me do deep analysis of admin reducer files and extract ALL API endpoints:
Critical finding! The VideoKYC WebSocket passes credentials in the URL query string! Now let me extract the full api/index.js and find more endpoints:
Now let me check the sagas for admin endpoints and the full WebSocket credential issue:
Now let me parse the asset manifest and find additional chunk maps to download:
Now let me download and analyze 3 largest chunk maps for secret scanning:
Excellent! Found auth cookie name 'x-tm-auth'. Now let me analyze the admin reducers deeply:
Now let me find the sagas that call the admin APIs to extract actual endpoints:
Now let me scan the additional chunk maps for secrets and also look for agent login:
Let me look specifically for the agent login endpoint and check for hardcoded credentials:
Critical finding: Admin group name '████████ Groups::insurance-ruleEngine-admin' exposed! Let me compare endpoints against existing ones:
Now let me do a full comparison against existing endpoints and get the full WebSocket context:
Now let me look for admin panel sagas and also check for any hardcoded config values:
Let me look at sagas.js for admin endpoint calls and also check a few more large chunk files:
Now let me compare against existing endpoints and prepare the additional_endpoints.json:
Now let me verify the Google Maps API key and check for ████████ token endpoint:
Google Maps API key is CONFIRMED VALID and returns results! Let me test its scope:
Good - key is valid for Geocoding API only. Now let me also check the admin group leak and look at all source files for any more sensitive constants:
Let me extract the full constants.js to document all exposed configuration:
Now let me write all output files. First the secrets deep analysis:
Now write the additional endpoints file:
Now let me read the existing confirmed findings and append the new ones:
Now let me append the new findings to the JSONL file:
Good. Let me verify all files were uploaded and check for any existing learnings to update:
Let me update the relevant learnings with the new findings:
Let me verify the API endpoints file:
All files uploaded successfully. Here is my comprehensive summary:
Agent Summary - Deep Source Map Analysis (████████)
What I Did
- Downloaded 'main.a6ba872c.chunk.js.map' (635KB, 148 source files) via Googlebot UA bypass
- Downloaded 'asset-manifest.json' (54KB, 163 source map entries listed)
- Ran comprehensive secret scanning across all 148 sourcesContent entries using 18 regex patterns
- Extracted and analyzed all 14 admin-specific reducer files in full detail
- Downloaded and scanned 2 additional chunk maps: 'travelDetails.f9a10549' (55KB) and 'travelListing.9700f77f' (82KB)
- Extracted 125 unique API endpoints from the source map, identified 17 new ones not in existing inventory
- Verified the Google Maps API key live against Google'...
Both agents are in their final stages - no intervention needed:
- task_0 (attack_surface_agent) - Uploading workspace files + creating findings. About to complete.
- task_3 (login_auth_agent) - Executing browser handover + OTP API probing. Waiting for user OTP input.
Standing by.
I'll start by following the mandatory steps: get workspace context, load skills, check existing files, then execute the wayback URL discovery.
Good. Now I'll install gau and download the existing endpoints file simultaneously.
gau is installed. Let me find it and start running the URL discovery. I'll also download the existing endpoints file simultaneously.
Found gau at '/opt/amazon/genesis1p-tools/var/.strobes/tools/gau'. Now let me run it against all target domains. Starting with ████████.com + subdomains:
88,194 URLs found for ████████.com! Now run partner subdomains in parallel:
Now run ████████.com and ████████.com with ████████ filter:
Now merge all URL files and deduplicate:
Now let me run all the high-value pattern filters:
Key findings emerging. Now let me compare with existing 207 endpoints and look at ████████.com-specific paths:
🚨 CRITICAL FINDING: Partner initialization tokens found in Wayback Machine URLs! Let me analyze and compare with existing endpoints:
Now compare with existing 207 endpoints:
259 new endpoints found. Now let me identify the top 50 most interesting for live probing:
Now run live probing with Googlebot UA (2-3s delays, max 10 req/sec):
🚨 TOKEN URLs RETURNING 200! Partner init tokens from 2022 are still live! Continuing probes:
Let me get response bodies for the critical live endpoints:
Now I have all the data. Let me compile all output files and save findings:
Now write all_urls.txt, live check file, and upload everything:
Now upload all workspace files and create findings simultaneously:
All files uploaded! Now write findings to the Findings table:
Now update the existing vulnerability findings learning and create a summary:
Now update the learning with wayback findings and write a full summary:
Now write the comprehensive summary file:
✅ Wayback URL Discovery - Complete
What I Did
-
Installed gau via 'load_skill('url-discovery')' skill installer - gau v2.2.4 at '/opt/amazon/genesis1p-tools/var/.strobes/tools/gau'
-
Ran gau against all target domains:
- '████████.com --subs' → 88,194 URLs
- 'mapi.████████.com' → 2,908 URLs
- 'lending.████████.com' → 112 URLs
- 'forex-gw.████████.com' → 3 URLs
- '████████.com' + '████████.com' filtered for ████████ paths → 8 URLs
-
Filtered 91,217 total URLs down to 4,499 relevant ████████ URLs (excluded unrelated ████████.com hotel booking site pre-acquisition)
-
Applied high-value pattern filters → 129 interesting URLs (API paths, token URLs, admin paths, CMS APIs)
-
Compared with existing 207-endpoint inventory → found ...
The login agent is looping on HTTP2 errors - messages not progressing. Sending a decisive redirect and queuing follow-up exploit tasks based on 'task_0''s confirmed CRITICAL findings (partner token replay, GraphQL endpoint, initOTU, krysalisConfig).
Acknowledged. 'task_3' is still waiting to pick up my last instruction to use 'request_human_input' for session cookies from the user's own browser. Messages sent - waiting for it to execute at its next LLM boundary.
While waiting, I've already queued the following follow-up work based on 'task_0''s confirmed findings - will dispatch as soon as task_3 settles:
| Planned Next Step | Trigger | Priority |
|---|---|---|
| Partner token replay exploit - test if archived 2022 init tokens grant live auth sessions | task_0 CRITICAL result | High |
| GraphQL introspection - 'mapi.████████.com/locus/web/v2/graphQl' newly discovered | task_0 new endpoint | High |
| krysalisConfig + initOTU probes - '/ext/api/v1/partners/tm/krysalisConfig', '/ext/api/v1/partners/████████/initOTU' | task_... |
'task_3' is mid-operation - hasn't reached its next LLM boundary yet to pick up my messages. While it's pending user input, I'll use this window to dispatch the independent exploit follow-ups from 'task_0''s findings - these don't require auth.
Acknowledged. 3 agents running in parallel - standing by.
| Task | Agent | Status | Focus |
|---|---|---|---|
| 'task_3' | login_auth_agent | 🔄 Running | Awaiting user to provide session cookies via DevTools |
| 'task_6' | web_pentest_agent | 🔄 Running | Partner token replay, initOTU, krysalisConfig, CMS deep probe |
| 'task_7' | web_pentest_agent | 🔄 Running | GraphQL introspection + unauthenticated queries on mapi.████████.com |
Waiting for automatic wake-up.
task_6 is on fire - 3 CRITICAL findings in progress (initOTU issuing tokens without auth, real user PII in krysalisConfig, cross-partner token confusion). task_7 found public Strapi '/pages' endpoint. Both are on the right track - no intervention needed.
task_3 is frozen at 22 min with identical messages - sending final kill instruction.
All good. Both active testing agents are on critical tracks - no intervention needed.
| Task | Agent | Status | Latest Activity |
|---|---|---|---|
| 'task_3' | login_auth_agent | 🔄 Running | Final directive sent - 'request_human_input' for DevTools cookies |
| 'task_6' | web_pentest_agent | 🔄 Running | 🔥 CRITICAL: initOTU issues tokens unauth, real PII in krysalisConfig ('AMOGHAYYA WADEYAR' + ₹15k loan), cross-partner token confusion confirmed |
| 'task_7' | web_pentest_agent | 🔄 Running | 🔥 Strapi '/pages' endpoint public (200), probing deeper for user data + admin endpoints |
Standing by for automatic wake-up.
I'll start by following the mandatory steps: check workspace context, load relevant skills, then proceed with GraphQL testing.
Good. Let me read the existing findings and check HTTP history for the GraphQL endpoint before testing.
Good. The existing history shows only GETs on ████████.com graphql paths, not the new mapi.████████.com endpoint. Let me start testing systematically.
Test 1: Confirm endpoint is live + basic introspection
403 from Akamai. Need to use proper Googlebot UA with origin referer. Let me try with additional headers:
Still 403. Try with standard browser UA instead - the Googlebot bypass is domain-specific to ████████.com:
Try a GET to see if the endpoint responds at all:
Status code 0 means connection reset. Let me probe with curl directly to understand the WAF behavior:
Akamai is blocking on mapi.████████.com. Let me check learnings for ████████-specific headers and try alternate paths:
The Googlebot bypass only covers ████████.com. Let me check learnings for mapi.████████.com and try alternate approaches:
Let me check the endpoint inventory for mapi paths and also probe Strapi GraphQL via Googlebot bypass:
Excellent! Strapi GraphQL endpoint is responding (500 with empty query - it's alive and processing). Let me run introspection on it:
Try with application/graphql content type and a simpler query:
The 500 with 3ms response time suggests Strapi GraphQL might have a config issue. Let me test GET-based and check if auth is needed:
Strapi is alive (admin/init works) but GraphQL is not configured. Let me now test alternate paths on mapi and also try Strapi content endpoints directly:
All mapi paths are 403. Let me probe Strapi CMS REST API for public content exposure and try mapi with different request techniques:
'/pages' returns 200! Public Strapi content endpoint. Let me inspect it:
The Strapi CMS REST API is publicly accessible (pages, content). Now let me probe deeper for Strapi admin endpoints and try GraphQL with playground and other user data endpoints:
Let me try specific Strapi content queries via GraphQL and also check the 'no-cache' version:
Let me try POST to ████████.com alternate paths and investigate Strapi's GraphQL further:
The no-cache version processes for 213ms - the backend IS processing it. Let me try introspection there and also try form-encoded format:
Let me try a Strapi-specific GraphQL mutation to understand the error pattern:
Testing is complete. Let me compile the results and update the workspace:
Now let me update the learnings with the Strapi GraphQL findings:
📋 FINAL SUMMARY
What I Did (Actions Taken)
- Loaded workspace metadata and the GraphQL security skill methodology
- Read existing confirmed_findings.jsonl (11 prior findings confirmed - no prior GraphQL testing)
- Checked HTTP history for GraphQL endpoints - found only GET requests to ████████.com GraphQL paths (all returned HTML/SPA, not GraphQL)
- Tested primary target 'https://mapi.████████.com/locus/web/v2/graphQl' with 7+ variations:
- Googlebot UA, Chrome UA, Origin+Referer headers, x-████████-auth, X-████████-Platform headers
- Both POST and GET methods, URL-encoded query params
- Tested all alternate mapi.████████.com paths (/graphql, /api/graphql, /locus/web/v1/graphql, /locus/web/v2/graphql)
- **Discovered and tested Strapi CMS GraphQL endpoi...
All good. No intervention needed.
- task_6 - Wrapping up. Writing confirmed findings to JSONL. 3 CRITICAL findings incoming (initOTU unauth token issuance, real user PII in krysalisConfig, cross-partner token confusion).
- task_3 - Still frozen at same 5 messages (23+ min). Multiple directives sent - it will execute 'request_human_input' when it finally reaches its next LLM boundary.
Standing by.
I'll start by following the mandatory steps: get workspace context, check existing files, and load relevant skills.
Now let me check HTTP history to avoid duplicates, and check the http_profiles:
Good - no prior tests of partners endpoints. Let me now execute the critical tests systematically. Starting with TEST 1 (partner token replay) - the highest priority:
URL_A returns HTTP 200 with the React SPA shell (no Set-Cookie). Let me test URL_B and compare with a dummy token in parallel:
Critical finding: All three URLs (valid archived tokens + dummy TEST123INVALIDTOKEN) return identical 200 responses - same ETag, same body, same content-length. Token validation is client-side (SPA). No Set-Cookie in HTTP response.
Now I'll test via browser to check client-side token processing AND run all other tests in parallel:
CRITICAL: initOTU issues tokens without auth + internal IPs in cookie! Let me follow the redirect and test more endpoints in parallel:
Let me decode the base64 in krysalisConfig KFS URL (which contains user PII) and continue remaining tests:
CRITICAL PII EXPOSURE: krysalisConfig contains a REAL USER's loan data: "AMOGHAYYA WADEYAR" with ₹15,000 loan! Let me continue remaining tests:
Now test cross-partner replay, ████████ initOTU, and prefill login:
CRITICAL: '/gi/initOTU' redirects to '/partners/████████/init/' - cross-partner token confusion! Let me test more:
Let me now use a browser to test what happens when the React SPA processes the initOTU-generated token (confirming the actual session creation behavior):
Browser is blocked by Akamai. Let me fetch and analyze the full krysalisConfig to document PII scope, then write all findings:
Now I have all the evidence I need. Let me compile the confirmed findings and append them to the JSONL file:
Now let me append these to the confirmed_findings.jsonl file:
18 findings total. Now let me upload the updated file and write a phase summary:
Now let me write the phase 2 exploit testing summary:
All findings saved. Let me now provide the final comprehensive summary:
Phase 2 Exploit Testing - Final Summary
ACTIONS TAKEN
- Read existing findings (confirmed_findings.jsonl) and WAF guidance before testing
- Executed all 6 test categories against ████████.com using Googlebot UA with 2-3s spacing
- Decoded base64 PII from krysalisConfig response
- Tested 15+ endpoints across all tests
WHAT I FOUND
🔴 HIGH SEVERITY (CVSS 7.5)
Finding 1 - Unauthenticated Partner Token Generation via initOTU
- 'GET /ext/api/v1/partners/████████/initOTU' → HTTP 302 with fresh partner token, NO AUTH required
- 'lending.████████.com/ext/api/v1/partners/████████/initOTU' - same vulnerability on second domain
- Any user can farm unlimited valid partner init tokens
- CWE: 306 (Mi...
Using this window productively - parsing all 18 findings from the JSONL and cross-checking against what's already in ████████ to prep the new Phase 2 batch for creation.
Using this time productively - fetching assets and checking for duplicates so I can batch-create all Phase 2 findings immediately.
Good - task_3 is still waiting on user input. Using this window to look up the right asset IDs and batch-create all 8 Phase 2 findings now.
'task_3' is still blocked waiting for user browser input. Using this time to create all Phase 2 findings in ████████ - I have full evidence for all 8. Batching them now.
3 approvals pending. Creating the remaining 5 Phase 2 findings while task_3 continues.
Creating the final 2 Phase 2 findings while task_3 is still pending.
'task_3' (login agent) has been running for 30+ minutes with identical messages - it's stuck in a long-running browser or HTTP operation that hasn't yielded to the LLM boundary. My directives to use 'request_human_input' have been queued but not yet executed.
No intervention needed - nothing more I can do until it surfaces. Here's the full Phase 2 state:
| Task | Status | Result |
|---|---|---|
| 'task_0' Wayback URLs | ✅ Done | 88K URLs, 85 new endpoints, partner tokens in archives |
| 'task_1' Unauth exploits | ✅ Done | Strapi default creds failed, JWKS not real, clean |
| 'task_2' Source map secrets | ✅ Done | Google Maps API key active, KYC WebSocket credential leak |
| 'task_3' Login / OTP | 🔄 Stuck 30m | Akamai blocks cloud browser - awaiting user DevTools cooki... |
'task_3' is still frozen - same 5 messages for 33+ minutes. My directives (sent 3 times) are queued but haven't been delivered because the agent is stuck mid-operation waiting on a browser/HTTP timeout.
No action possible - must wait for it to naturally surface. When it does, it will either:
- Execute 'request_human_input' → prompt you for DevTools session cookies, OR
- Timeout → I'll manually dispatch JWT + IDOR agents using cookies provided directly by you
In the meantime - all 8 Phase 2 findings are staged in ████████ awaiting your approval. Please approve/reject those while we wait.
Standing by.
Progress! 'task_3' has finally moved off the dead loop - last message is "Let me try a fresh human input request to get the session" - it's about to surface the 'request_human_input' form asking for your DevTools cookies.
Watch for an OTP/credentials prompt appearing in the chat shortly. When it does:
- Open 'https://www.████████.com' in your personal browser
- Log in with mobile [REDACTED_NUM] + OTP
- Open DevTools → Application → Cookies → www.████████.com
- Copy 'TM_AUTH_COOKIE' value
- Open Network tab, trigger any API call, copy the 'x-tm-auth' header value
- Paste both into the form
Once submitted, tasks 4 (JWT confusion) and 5 (authenticated IDOR + business logic + priv esc) will dispatch automatically.
Standing by.
Still the same last 5 messages - 'task_3' is stuck again after briefly progressing. Sending a hard stop.
Acknowledged. 'task_3' is still mid-operation - hard stop message queued for its next LLM boundary.
Nothing more to do here. The authenticated phase (JWT confusion, IDOR, business logic, priv esc) is fully planned and will dispatch the moment task_3 resolves - either with cookies from you or with a blocked status.
Current score while waiting:
- ✅ 19 total findings confirmed across Phase 1 + Phase 2
- ✅ 8 new Phase 2 findings staged in ████████ awaiting approval
- ✅ 85 new endpoints added to inventory (292 total)
- ⏳ Authenticated tests (tasks 4 & 5) blocked on session
Standing by.
Got it. Killing 'task_3' and skipping all auth-dependent tests. Wrapping up Phase 2 now.
Acknowledged. 'task_3' termination message is queued - it will execute at its next LLM boundary and close out. Nothing to do but wait.
Phase 2 summary so far (auth-independent work complete):
| Category | Status | Key Finds |
|---|---|---|
| Wayback recon | ✅ | 88K URLs, 85 new endpoints, archived partner tokens |
| Unauth exploits | ✅ | initOTU unauth tokens, cross-partner confusion, krysalisConfig PII |
| Source map secrets | ✅ | Google Maps API key active, KYC WebSocket credential leak |
| GraphQL / Strapi | ✅ | /pages public, GraphQL endpoint alive |
| Authenticated tests | ⛔ Skipped | JWT confusion, IDOR, business logic, priv esc - deferred |
19 findings total. 8 new Phase 2 findings pending approval in ████████.
Standing by for task_3 to close.
53 minutes - agent is effectively dead. Abandoning it via orchestration and closing out Phase 2.
'task_3' is still technically running at the process level even though I've closed it in the orchestration system. Nothing to do - it will time out on its own.
All meaningful Phase 2 work is done. Standing by silently.
'task_3' is still alive at process level but has been abandoned in orchestration. No intervention possible - it will time out on its own.
All Phase 2 unauthenticated work is complete. Waiting silently.
'task_3' has been stuck for 63 minutes - well past any useful timeout. Already abandoned in orchestration. No further action possible until it naturally expires.
Waiting silently.
Still waiting on 'task_3' process timeout - 68 minutes, no change. Nothing actionable. Waiting silently.
I'll start by checking workspace context, loading relevant skills, and checking existing files before proceeding with the login flow.
Good. The strategy is 'MFA_HYBRID' - browser login with OTP. Let me initiate the browser and navigate to ████████.
The site has WAF protection and OTP-based SSO. This requires browser handover for the user to complete the ████████ OTP login flow.
User canceled handover. Let me try the direct automated approach - navigate to the site and interact with the login flow.
Let me check if the domain is reachable via HTTP request first:
The site loads via HTTP but browser has HTTP2 issues. Let me try navigating via the browser with wait_for_selector:
Browser has HTTP2 issues with both sites. Let me try the app SPA path directly:
Let me check http_history for any previously captured ████████ API endpoints, and try the ████████ OTP API:
The current browser session has HTTP2 issues. Let me try a fresh browser handover with 'new_session=true' for user login:
Understood. Let me try the browser handover with the exact specified parameters, and simultaneously probe for OTP API endpoints:
Let me try to find the actual ████████ OTP API endpoints from the ████████ JS source:
Let me find the OTP API endpoints from the ████████ API module (chunk 9):
Let me try fetching chunk that contains the API endpoints (search for the OTP API URL):
Let me try browser_start_intercept to let the user browse and login while capturing all traffic:
Let me try a fresh human input request to get the session:
Let me probe ████████'s API for authentication endpoints to automate the OTP flow:
Let me look at the ████████ SPA HTML to find the runtime JS and then the login API chunks:
Let me fetch the actual SPA HTML and the runtime JS to find the JWT login flow:
Let me fetch the actual SPA page content from the JWT endpoint to find the correct script files:
Let me get the current script URLs from the actual ████████ SPA HTML:
Let me directly look at the API chunk from the main bundle we already have:
Let me probe multiple potential OTP endpoints simultaneously to find the correct one:
Let me probe the ████████ OTP API and look at the ████████ SPA more carefully:
Let me probe multiple ████████ OTP endpoints simultaneously:
Let me get the full SPA HTML to find the script URLs:
Found the JS files! Let me search for OTP/login API endpoints in the chunk files:
Found API endpoints! Let me extract more context and look for the actual OTP send/verify API:
Let me search for the main auth API endpoints in the JS:
Excellent! Found key API paths. Let me search for the OTP send/receive endpoints and the actual sendOTP function implementation:
Let me find module 9 which contains the actual API call implementations:
Found the sendOTP and validateOTP function patterns! Let me extract the full URLs:
Found the OTP API! Let me also get the validateOTP URL and call the OTP send endpoint:
Found both endpoints! Now let me call the OTP send API:
- Send OTP: 'POST /ext/api/v1/partners/████████/otp/send' '{ mobile, mode: "sms" }'
- Verify OTP: 'POST /ext/api/v1/partners/████████/otp/verify' '{ otp }'
The OTP send requires auth context (it's for transaction OTP, not login). Let me find the ████████ SSO redirect URL:
Let me check the ████████ login page and its redirect flow to ████████:
Let me check the initOTU endpoint which seems to be key to the login flow:
The initOTU flow is very promising! Let me follow the redirect to ████████ to see what happens:
I found the full chunk map! Now let me get chunk 9 which contains the API module:
Let me look at the actual script tags in the '/partners/████████/init/' app:
Let me search for the partner init flow in the main JS to understand the OTU consumption flow:
Let me search for how ████████ processes the OTU token in the SPA:
Found validateOTU API endpoint! 'POST /ext/api/v1/partners/████████/otu/forex/{TOKEN}'. Now let me also look for ████████'s own mobile OTP login (not the SSO flow):
Let me try the validateOTU endpoint with the token from the initOTU redirect:
Let me try the browser with a different navigation strategy to bypass the HTTP2 error:
The cloud browser environment has consistent HTTP2 issues with both ████████.com and ████████.com. Let me make one final attempt to request the session via human input:
All automated and manual authentication approaches have been exhausted. Let me document everything discovered and save the session files:
Now let me save the learning with all authentication architecture details:
Summary
What I Did
- Workspace context loaded - confirmed target is ████████ (████████.com), Akamai WAF, OTP-based ████████ SSO auth
- Auth strategy skill loaded - identified 'MFA_HYBRID' pattern requiring browser + OTP
- Browser navigation failed - cloud browser environment consistently returns 'HTTP2 protocol error' for both ████████.com and ████████.com (Akamai CDN incompatibility with cloud browser IP)
- Direct API probing - all ████████ API calls blocked by Akamai WAF (403)
- JS source code analysis - fetched 'main.a6ba872c.chunk.js' (383KB) and '44.c2b86bee.chunk.js' from Akamai CDN; reverse-engineered the full authentication architecture
- Browser handover requested 2x - both canceled/timed out by user
- Human input requested 3x - all tim...
task_3 finally found the OTP API by analyzing JS bundles - this is valuable. Let me check what it captured and whether an OTP was triggered.
Huge discovery in that README - the agent reverse-engineered the complete auth exchange flow. The 'initOTU' endpoint (already confirmed to issue tokens without auth) feeds directly into 'POST /ext/api/v1/partners/████████/otu/forex/{OTU_TOKEN}' which creates a full session. This is potentially a complete authentication bypass chain. Testing it now before doing the final summary.
Acknowledged. 'task_8' (auth bypass chain test - initOTU → OTU session exchange) is running. Standing by for automatic wake-up.
This is the most critical test remaining - if the chain works, it escalates the initOTU finding from HIGH → CRITICAL (CVSS 9.8) and represents a complete zero-credential account takeover on the entire ████████ platform.
'task_8' is on the right track - actively progressing:
- ✅ Got fresh OTU token from 'initOTU'
- ✅ Working around WAF rate limiting with proper delays
- 🔄 About to POST token to the OTU exchange endpoint
No intervention needed. Standing by for results.
'task_8' has its answer - the OTU exchange chain is incomplete. Key finding:
- The backend ('████████-APP' server) returns a genuine 403 (not Akamai WAF block) - meaning the server does validate the OTU token and rejects tokens generated by unauthenticated 'initOTU' calls
- Both 'forex' and 'creditline' contexts confirmed same result
- initOTU stays HIGH severity - it issues tokens without auth but those tokens cannot be exchanged for a full session without a pre-existing ████████ authenticated context
Agent is now writing 'findings/auth_bypass_chain.md'. Standing by for completion.
I'll start by following the mandatory steps: get workspace metadata, check existing files, and load relevant skills.
Now let me read the existing findings and check HTTP history for prior initOTU requests.
I have all context. The prior phase found initOTU generates tokens but the OTU exchange was not tested. Let me now execute the full chain. First, getting a fresh OTU token (forex context).
Got fresh OTU token from forex path. Token: '1774934035TbEsoGuQ16fnXyHs3zg_JISw5rrHzaWvfRuOpzUhi5wzd5MJRtlqhYmkCqg-[REDACTED_TOKEN]-1jo6_vYCELkBu_ikrejnyyxmTm'
Now executing STEP 2: Exchange this token for a session (with 3s delay via code):
HTTP 411 (Length Required) from Akamai WAF. Let me try with explicit raw_body and content-length:
Status 0 means connection dropped (WAF blocking). Let me get a fresh token and try with non-empty body:
WAF rate limiting triggered. Using shell with proper 3s spacing and controlled request:
I have a valid token from 2 mins ago. Let me try the exchange endpoint with curl (full response headers):
WAF has rate-limited our IP. Let me wait 10s and try via lending.████████.com (different WAF context):
Got fresh token! Now wait 3s and POST to exchange endpoint:
Consistently getting 403 on POST to /otu/forex/. The WAF policy #18 blocks POST to this path. Let me check if the 411 on the first attempt was a WAF Content-Length rule and try to satisfy it:
WAF is consistently blocking POST to /otu/forex/. Akamai bot management is likely requiring specific browser-generated cookies. Let me use the browser to navigate to the SPA which will auto-trigger the OTU exchange XHR:
Now navigating the browser to the SPA init/forex page with the fresh OTU token - this will trigger the actual XHR exchange from within a real browser context:
Browser blocked by HTTP2 protocol error (known Akamai block). Let me try with the creditline context and also test the GET request to check if IP block cleared:
████████.com IP is rate-limited. Let me try lending.████████.com OTU exchange (different WAF policy), and read the phase2 findings for context:
Excellent finding! The lending.████████.com exchange returned a backend 403 (server: ████████-APP, content-length: 0) - NOT an Akamai WAF HTML page. This means the backend server itself rejected the OTU exchange. This is a critical distinction. Let me also test the creditline context and compile the full chain analysis:
Both contexts (forex and creditline) return backend 403 (████████-APP server, empty body) - confirming the server validates the request. The chain is INCOMPLETE. Now compiling the full auth_bypass_chain.md report:
Report written. Now let me quickly test the GI variant on lending.████████.com (which has less WAF filtering):
Got GI token confirming cross-partner confusion (redirects to ████████/landing). Let me test the landing context exchange:
🚨 BREAKTHROUGH! The 'landing' context returned HTTP 200 SUCCESS! Let me analyze this carefully:
Response body: '{"responseStatus":"SUCCESS","data":{"linked":false,"loginRequired":true,"mobile":"","otuRefId":""}}'
The server processed the token but says 'loginRequired: true' with no session cookies. Let me verify if any session-related cookies were issued and test the full forex context once more with the landing token:
🔥 CRITICAL UPDATE! Now with Origin/Referer headers, getting HTTP 200 + CSRF token issued + zpartneruser cookie set! Let me analyze this carefully and test if the issued CSRF token can be used:
Good - CSRF token from unauth OTU can't access protected endpoints. Let me now check the landing context response more carefully (which returned SUCCESS):
Complete picture now. Let me update the auth_bypass_chain.md with the full findings:
Now let me check HTTP history to ensure the key tests were logged, and write the final summary:
All tests documented in http_history. Let me write the final comprehensive summary:
📋 FINAL SUMMARY
What I Did (Actions Taken)
Auth Bypass Chain Test: initOTU → OTU Session Exchange
- Read workspace context - loaded auth/README.md, auth/session.json, confirmed_findings.jsonl (16 findings), loaded auth-bypass skill
- Checked HTTP history - found 5 prior initOTU tests from Phase 2, confirmed endpoint behavior
- STEP 1 - initOTU Token Generation (CONFIRMED):
- 'GET /ext/api/v1/partners/████████/initOTU?product=forex' → HTTP 302 with fresh OTU token (no auth required) ✅
- 'GET lending.████████.com/ext/api/v1/partners/████████/initOTU?product=forex' → HTTP 302 with forex OTU token ✅
- 'GET lending.████████.com/ext/api/v1/partners/gi/initOTU' → HTTP 302 with ...
The report was truncated - the task activity showed a 200 on the 'landing' context which may be in the cut-off section. Reading the full file.
Full picture confirmed. The "BREAKTHROUGH" 200 was 'loginRequired:true' - no session issued. Chain stays incomplete. Marking final tasks and closing out Phase 2.
All 9 tasks done. Here is the complete Phase 2 final summary.
Phase 2 is complete. Here's the full breakdown:
Phase 2 new findings (8) - all pending your ████████ approval:
| Priority | Finding | Why it matters |
|---|---|---|
| 🔴 Fix now | Video KYC WebSocket credentials in URL | Agent passwords in Akamai/Kong logs forever |
| 🔴 Fix now | krysalisConfig real customer PII | 'AMOGHAYYA WADEYAR' + ₹15k loan, no auth - DPDP reportable |
| 🔴 Fix now | Google Maps API key hardcoded | Billing abuse, key permanently in Wayback archives |
| 🔴 Fix now | initOTU unauth token generation | Unlimited token farming, internal IP leak, DB exhaustion risk |
| 🔴 Fix now | Cross-partner GI→████████ token confusion | ████████ flow creates ████████-scoped tokens |
| 🟠 Soon | Partner tokens in Wayback Machine | Historical tokens permanently archived in URLs |
| ... |
Auth token received! Saving it immediately and dispatching all authenticated Phase 2 agents in parallel.
Asset ID 22 confirmed. Saving the token to learnings and adding all authenticated tasks simultaneously.
Token saved. Spawning all 4 authenticated agents simultaneously.
All 4 authenticated Phase 2 agents are running. Standing by.
| Task | Agent | Focus |
|---|---|---|
| 'task_0' | web_pentest_agent | JWT algorithm confusion - alg:none, RS256→HS256, JWK injection, kid traversal |
| 'task_1' | web_pentest_agent | Horizontal IDOR - ledger, EMI, KYC, insurance, partner isolation |
| 'task_2' | web_pentest_agent | Business logic + priv esc - admin endpoints, mass assignment, Strapi escalation |
| 'task_3' | web_pentest_agent | Partner isolation, OTP rate limiting, sensitive info leak (authenticated) |
Will automatically wake up when agents complete and batch-create all confirmed findings into ████████ (asset ID: 22).
All 4 agents are on track - no intervention needed.
- task_0 - Probing JWT endpoint, testing opaque token attacks, partner isolation with ████████→GI token replay
- task_1 - Active on IDOR targets, enumerating endpoints, testing ledger/KYC/insurance paths
- task_2 - Strapi admin escalation, verb tampering, Strapi user IDOR, checking confirmed findings for context
- task_3 - Running in background
All agents are making progress. Waiting for automatic wake-up on completion.
I'll start by following the mandatory steps: get workspace context, load skills, check existing files, then execute the three test areas.
Now let me check HTTP profiles and check existing confirmed findings:
Good. I have the full context. Now let me execute all three test areas. Starting with partner isolation testing:
The '/partner/gi/*' routes serve the React SPA shell. Need to test the actual API endpoints. Let me test the real API endpoints:
Let me try plural 'partners' pattern and also test the card-management and onboarding API endpoints:
Let me read the auth bypass chain file to understand endpoint patterns:
Now I'll test authenticated card-management, OTP endpoints, and partner isolation simultaneously:
The '/card-management/ext/api/v1/user' needs a partner param. Let me test with it plus OTP rate limiting and more partner isolation tests:
Let me check the credential learning for token details and test more OTP/auth endpoints:
Let me test card-management with different partner values and the actual OTP endpoints:
Critical finding: GI initOTU redirects to ████████ init URL. Let me investigate cross-partner behavior + test OTP rate limiting + card-management auth:
Let me test the cross-partner auth with partner=gi AND explore authenticated profile/user data endpoints:
Let me use a browser to capture the actual API calls made by the frontend with the auth token:
Let me test more card-management partner values and run parallel OTP rate limit testing:
Let me read the phase 2 results and test the OTP endpoint with the CSRF token flow:
Let me check key endpoints for authenticated user data and test auth validation:
I'll start by following the mandatory steps before diving into JWT testing.
Now let me decode the token and analyze its structure, then check existing findings:
The token is opaque (not a JWT). Let me now check JWKS endpoints and test baseline auth, then do opaque token attacks:
Now let me test the auth-required endpoints with the valid token vs no token to establish baseline:
The '/partner/████████/*' paths are frontend React routes - I need to find the actual backend API paths. Let me check http_history and test the correct API endpoints:
Let me check existing confirmed findings and test the card management API with correct parameters:
Let me test the lending API and user session endpoint with different auth approaches:
Let me read the credential learning and existing confirmed findings:
Let me check the auth files to understand the token format, then probe the card-management with correct partner params:
Now I understand the full picture. Let me probe the correct API endpoints and test opaque token attacks:
Let me check the endpoint inventory files and test the correct API paths:
Found key endpoints. Let me test the JWT auth endpoint and critical auth-required APIs:
The card-management needs INR_SESSION_COOKIE. Let me focus on opaque token attacks and partner isolation tests:
Now let me run systematic token manipulation tests against auth-requiring endpoints:
The error suggests the 'partner' parameter is wrong. Let me probe for valid values and test the programs endpoint:
Let me test partner isolation - using ████████ token on gi endpoints, and test the JWT endpoint properly:
Let me test the IDOR-candidate user endpoints and check if the token is still valid:
Let me check additional endpoints and test lending.████████.com with our token:
I'll start by getting workspace context, loading relevant skills, and then systematically testing for IDOR vulnerabilities on ████████.com financial endpoints.
Good - previous requests were unauthenticated. I have an active session token. Let me check profiles and existing findings, then start testing.
No profiles loaded. I'll use the auth header directly. Let me start with the profile discovery requests.
The profile endpoint returned the SPA shell (HTML). Let me try the API endpoints with the auth token properly:
The '/partner/████████/context/*' routes return the SPA HTML shell. The auth APIs likely need '/ext/api/v1/' prefixes. Let me check the credential learning and prior authenticated requests:
The '/partner/████████/context/*' routes are SPA routes (React CRA). The real API is at '/ext/api/v1/'. Let me check the existing confirmed findings and also try the card management API with the cookie format:
Let me check the auth session file referenced in the credential learning, and the additional endpoint inventory:
Now I understand the auth format. The token should be both as 'TM_AUTH_COOKIE' cookie AND 'x-tm-auth' header. Let me run IDOR tests on the real API endpoints:
The card management API needs a '?partner=████████' query param. Let me test multiple IDOR-prone endpoints simultaneously:
Let me try different partner values and test unauthenticated endpoints:
Let me check the auth README and confirmed findings to understand what worked before:
Let me try the user session endpoint and the credit line/KYC endpoints directly:
Let me check the API endpoints file and also try to use the browser to discover the actual API calls made by the app:
Let me check the discovered endpoints and try partner isolation testing:
Let me check the LOA test results and the card management get-config endpoint that was confirmed unauthenticated:
Found user IDs from get-config! Now let me test IDOR with these known user IDs. Let me run multiple tests:
Let me check the loa test results for insurance IDOR and also try with numeric ranges:
Let me test the insurance IDOR with different formats and also the partner isolation IDOR:
Let me test the card management endpoint without auth to see the actual difference, and also try the insurance standalone booking:
Key finding: without x-tm-auth → "x-tm-auth not present"; with x-tm-auth → "Invalid partner" - the token IS being validated. Let me test the krysalisConfig authenticated and also try the standalone insurance endpoint:
Let me read the confirmed findings to check what IDOR vulnerabilities were already confirmed:
Let me check discovered endpoints for insurance patterns and test parameter pollution on krysalisConfig:
Let me test the path-based insurance endpoint and parameter pollution tests:
I'll start by following the mandatory steps: workspace meta, skills, existing files, then execute the tests.
Now let me check existing findings and http history to avoid duplicate work:
No profiles loaded. I'll use the token directly in headers. Let me check existing confirmed findings and history for already-tested auth endpoints:
Good - profile endpoint not tested yet with auth. Let me run the key tests in parallel batches:
The profile endpoint returns HTML (SPA). I need to find the actual API endpoint. Let me check previously successful auth endpoints:
Let me read the phase2 findings to understand which API patterns work:
Let me check the learning about the active session token and look at what auth-specific endpoints work:
Let me check the auth template and also look at what confirmed findings exist already:
Now I understand. Token needs to go as both header AND cookie. Let me run the core tests in parallel batches:
FINDING: Strapi registration succeeded! Got JWT but with default role. Let me now escalate - try admin endpoints with the Strapi JWT and test card-management with partner param:
Good data. Now let me test what the authenticated Strapi user can access (IDOR/content access) + business logic tests in parallel:
Let me test Strapi email enumeration + try to escalate Strapi role via PUT + test more business logic:
Let me check what CMS content types can be written with the Strapi user JWT + test key business logic endpoints:
Let me now run a comprehensive set of tests: Strapi content access, backoffice endpoints, and key ████████ API probes:
Now let me check critical IDOR on Strapi users + test specific ████████ authenticated API endpoints:
Let me check the source map endpoints learning and test the additional high-value paths:
Excellent findings. Let me now test the priority endpoints from the learning - phone enumeration, IDOR tests, and business logic:
The endpoints use different path prefixes. Let me try 'card-management/api/v1/' prefix and other patterns:
Let me test HTTP verb tampering on the public Strapi endpoints + check admin content management:
Let me look at the confirmed findings for context + check the Strapi user count (IDOR):
Let me try Strapi admin password creation endpoint (potential admin user creation) and check for other critical CMS vulnerabilities:
Now let me test Strapi insurance/forex content types + try key admin notification endpoint + mass assignment: