ENGAGEMENT OBSERVATIONS
Security Assessment Case Studies
Explore real-world anonymized security testing scenarios demonstrating how our offensive methodologies uncover critical vulnerabilities, prevent business disruption, and verify engineering fixes.
Multi-Tenant Isolation & BOLA Vulnerability Remediation
Identifying and fixing a critical Broken Object-Level Authorization (BOLA) vulnerability allowing tenant data cross-contamination.
1. Challenge & Background
A rapidly growing multi-tenant B2B analytics platform was preparing for SOC 2 Type II audit and enterprise customer security reviews. The development team needed independent offensive testing of their core GraphQL and REST API endpoints to ensure tenant data isolation.
2. Engagement Scope
- Customer web portal & admin dashboards
- Authenticated GraphQL API & REST microservices
- Role-based access control (RBAC) tiers (Viewer, Editor, Tenant Admin)
- Third-party webhook ingestion endpoints
3. Testing Approach
RajSecure conducted an authenticated grey-box security assessment with two distinct tenant test accounts. Our offensive testing mapped all entity IDs across projects, analytics reports, and billing data to evaluate authorization boundaries on mutating and query endpoints.
4. Primary Technical Finding
Discovered a critical Broken Object-Level Authorization (BOLA / IDOR) vulnerability in the GraphQL report export query. By substituting the tenant project UUID with a target organization’s UUID, a standard viewer in Tenant A could retrieve confidential financial reports and analytics data belonging to Tenant B without authorization.
5. Business Risk & Impact
If exploited by a malicious actor, the vulnerability would have resulted in complete cross-tenant confidentiality breach, regulatory non-compliance, and severe reputational damage during enterprise procurement reviews.
6. Engineering Remediation
Provided engineering team with a scoped resolver pattern enforcing database-level tenant ID validation before executing object queries, along with automated integration test templates.
7. Verified Retest Result
Within 14 days, the client deployed the fix. RajSecure re-tested the endpoint with modified UUID payloads, confirming the flaw was completely mitigated and returning proper HTTP 403 Forbidden responses.
Financial Transaction Logic & Race Condition Assessment
Uncovering concurrency and double-spend logic risks in microservice-based transaction processing.
1. Challenge & Background
A digital wallet and payment processor required rigorous offensive security testing before rolling out instant peer-to-peer transfers and multi-currency conversion features.
2. Engagement Scope
- Core payment checkout & withdrawal APIs
- Multi-currency balance conversion engine
- Two-Factor Authentication (2FA) verification workflows
- API rate-limiting & idempotency token handling
3. Testing Approach
Conducted deep business-logic testing using concurrent multi-threaded request bursts, parameter tampering, and edge-case currency conversion rounding manipulations across staging test environments.
4. Primary Technical Finding
Identified a high-severity concurrency race condition in the withdrawal request endpoint. Due to non-atomic balance verification and asynchronous ledger commits, sending 10 simultaneous withdrawal requests within a 5ms window allowed a test balance to be debited twice before the account lock engaged.
5. Business Risk & Impact
Potential double-spending vulnerability and direct financial loss if exploited at scale by fraudulent actors manipulating automated withdrawal scripts.
6. Engineering Remediation
Guided the backend team in implementing distributed atomic locking (Redis Redlock) and database row-level locking on balance transactions, paired with mandatory idempotent request headers.
7. Verified Retest Result
Comprehensive multi-threaded retesting confirmed that subsequent concurrent requests were properly serialized and rejected, eliminating the double-spend vulnerability.
Cloud IAM Policy Chaining & IMDS SSRF Privilege Escalation
Preventing compute-to-cloud admin takeover by chaining an internal SSRF vulnerability with over-privileged IAM roles.
1. Challenge & Background
An AI platform hosting custom model inference workers on AWS Kubernetes (EKS) sought a comprehensive cloud security and attack path assessment.
2. Engagement Scope
- AWS cloud infrastructure & EKS cluster configurations
- IAM roles for service accounts (IRSA) & instance profiles
- Public-facing document processing worker API
- S3 model weights and customer dataset buckets
3. Testing Approach
Combined external web application security testing with internal cloud posture review to map realistic attack paths from external inputs to internal cloud assets.
4. Primary Technical Finding
Discovered a blind SSRF in the document processing endpoint that allowed accessing the EC2 Instance Metadata Service (IMDSv1). By retrieving temporary security credentials from the instance profile, an attacker gained an over-privileged IAM role with `iam:PassRole` and `lambda:CreateFunction` permissions, enabling full escalation to AWS AdministratorAccess.
5. Business Risk & Impact
Complete compromise of AWS infrastructure, including unauthorized access to proprietary AI model weights, customer datasets, and cloud billing resources.
6. Engineering Remediation
Enforced IMDSv2 with hop-limit 1, migrated EKS pods to least-privilege IAM Roles for Service Accounts (IRSA), removed wildcard PassRole policies, and implemented strict URL whitelist validation on the document parser.
7. Verified Retest Result
Re-evaluated metadata access and IAM role boundaries. Verified that metadata access was blocked and service account tokens were strictly restricted to necessary S3 read-only prefixes.
Evaluate Your Organization's Attack Surface
Schedule a technical security assessment to identify vulnerabilities before they can be exploited.