Proven results

Case Studies

A handful of engagements from the last year, written up the way we'd explain them to the client's team — what we tested, what we found, and what changed afterwards. Names and identifying details are removed; everything else is real.

6
Engagements shown
6
Industries covered
5d–2wk
Typical engagement length
100%
Published by client consent
Showing 6 of 6

Recent Engagements

Anonymised at the client's request. Findings and numbers are unchanged from the final report.

incident_report.log — nbfc_lending Critical
🏦 NBFC — Digital Lending

Loan Files Reachable by Swapping One Number in the URL

engagement --brief

A Gurugram-based NBFC was six weeks from launching its instant personal loan app and needed a pre-launch assessment before its RBI cybersecurity self-audit was due.

cat findings.md

The loan-application API pulled up a customer's file — PAN, salary slips, bank statement — using a plain sequential ID. Logged in as any customer, changing that one number returned someone else's documents. A second issue: the OTP verification endpoint had no attempt limit, so a six-digit OTP could realistically be guessed within its validity window.

"We assumed the frontend hid the ID. It didn't matter — the API never checked who was asking." — Engineering Lead, client team

2
Critical findings
11
Total findings
9d
Engagement length
Web App API Access Control
full-breakdown --show ›
Scope

Customer-facing web app, mobile API layer, and the OTP/authentication service. Grey-box — we were given a normal test account, same as any customer.

What we did

Standard API mapping through the app first, then manual parameter testing on every endpoint that took an ID. The IDOR (an access-control bug where the app trusts an ID in the request instead of checking ownership) on the document endpoint was found on day 2. The OTP rate-limiting gap came up while writing the report, during a re-check of the login flow.

Fix

Ownership checks added server-side on all document and application endpoints; OTP endpoint got a lockout after five attempts plus a cool-down. Both shipped inside the same sprint, verified in a free re-test before launch.

incident_report.log — diagnostics_chain Critical
🏥 Diagnostics Chain

One Reused Password From Every Patient Report

engagement --brief

A diagnostics chain running 18 collection centres across the NCR wanted an internal network assessment ahead of their NABL accreditation renewal — specifically, whether a compromised reception PC could reach patient data.

cat findings.md

The same local administrator password had been set on more than 40 machines during initial rollout and never changed. From one reception PC, that password gave access to a file server holding scanned patient reports as unencrypted PDFs, organised by centre and date — no login required once you were on that share.

40+
Machines, one password
1
Hop to patient data
2wk
Engagement length
Network Active Directory Healthcare
full-breakdown --show ›
Scope

On-site assessment at two of the 18 centres plus the head-office network, simulating a visitor who plugs into a spare LAN port or reception Wi-Fi.

What we did

Passive traffic analysis on day one turned up the shared local admin credential, which had likely been baked into the original PC imaging process years earlier and never rotated. From there it was a straightforward SMB share to the report server — no exploit needed, just the reused password.

Fix

Local admin passwords randomised and rotated per machine using LAPS, patient report share moved behind proper AD group permissions and encrypted at rest. Re-verified from the same reception port two weeks later.

incident_report.log — d2c_fashion Pre-Sale Test
🛍️ D2C Fashion Brand

A Coupon Code That Never Stopped Discounting

engagement --brief

A D2C apparel brand booked a five-day web app test the week before their festive sale went live — a sanity check on checkout and account flows specifically, not a full-scope engagement.

cat findings.md

The coupon-apply endpoint calculated the discount on the server, but trusted a discount percentage sent from the browser instead of looking it up itself — editing that one field applied any discount, including 100%. Separately, the product review form didn't sanitise input, allowing a script to run in other users' browsers, including staff reviewing flagged reviews from the admin panel.

1
Critical logic flaw
7
Total findings
5d
Engagement length
Web App Business Logic XSS
full-breakdown --show ›
Scope

Checkout, cart, coupon, and account flows on the production-mirror staging environment, black-box.

What we did

Intercepted the coupon-apply request with a proxy and adjusted each field in turn — the discount percentage was the one the backend didn't re-verify. The stored XSS in reviews came up during standard input-field fuzzing on day 3.

Fix

Discount value now looked up server-side against the coupon record rather than trusted from the client; review input sanitised and output-encoded. Both fixes deployed two days before the sale, confirmed same-day.

incident_report.log — hrtech_saas Cloud
☁️ HR-Tech SaaS

40,000 Resumes Sitting in a Public S3 Bucket

engagement --brief

A Series A HR-tech SaaS company was preparing evidence for a SOC 2 Type I audit and asked us to review their AWS setup — access controls, storage, and IAM roles.

cat findings.md

A Terraform module had provisioned an S3 bucket storing candidate resumes with public list-and-read access — a one-line misconfiguration introduced during a refactor months earlier and never caught. Separately, the application server's IAM role had permissions far beyond what the app used, including read access to other customers' data tables — a much bigger blast radius than necessary if the server were ever compromised.

1
Public bucket found
~40K
Resumes exposed
6d
Engagement length
AWS Cloud IAM
full-breakdown --show ›
Scope

Full AWS account review — S3, IAM, EC2 security groups, and the CI/CD pipeline that deploys infrastructure changes.

What we did

Config-level review against CIS AWS benchmarks plus manual checks on anything storing customer data. The bucket policy was flagged within the first day; the over-permissioned IAM role took longer, found by mapping what the app actually calls against what its role allows.

Fix

Bucket set to private with access via signed URLs only, IAM role scoped down to least privilege, and a policy check added to the Terraform CI pipeline so a public bucket can't be merged again without a manual override.

incident_report.log — auto_parts_mfg OT / ICS
🏭 Auto-Parts Manufacturer

Office Wi-Fi Was One Hop From the Factory Floor

engagement --brief

A Tier-1 auto-components manufacturer in Faridabad needed to show a key customer that a compromised office laptop couldn't reach production-line controls — a standard requirement in their supplier security audit.

cat findings.md

The office and factory networks were supposed to sit on separate VLANs, but a misconfigured switch port left one production line's segment reachable directly from the general office Wi-Fi. From there, three HMIs (the touchscreen panels operators use to run the machines) were reachable and still using the vendor's default login.

1
Flat network path
3
HMIs exposed
2wk
Engagement length
OT / ICS Network Segmentation
full-breakdown --show ›
Scope

Passive network mapping first — we do not run active exploitation on live production equipment — followed by targeted checks of segmentation boundaries and device authentication, coordinated with the plant's shift schedule.

What we did

Traffic captured from an office access point showed broadcast traffic from the OT segment, which shouldn't have been visible at all. That pointed us to the misconfigured switch port; the default HMI credentials were confirmed with the plant engineer present, not tested live against the running line.

Fix

VLAN configuration corrected and audited across all switch ports, not just the one found; HMI credentials changed and a firewall rule added between office and OT segments. Verified with the plant's own network team present.

incident_report.log — edtech_app Mobile
📱 EdTech App

Student Data Behind a Pinning Bypass

engagement --brief

An EdTech company with roughly 200,000 students on its iOS and Android apps needed a mobile security assessment ahead of a state education board tender that required a clean report.

cat findings.md

The Android build had a backend API key hardcoded directly in the app package — extractable by anyone who downloaded the APK and unzipped it. Certificate pinning was implemented but could be bypassed with a common tooling setup, after which student names, phone numbers, and test scores were visible in plain API responses with no additional encryption.

2
Critical findings
8
Total findings
8d
Engagement length
iOS Android MASVS
full-breakdown --show ›
Scope

Static and dynamic testing of both app builds, plus the backend API endpoints the apps talk to, mapped to OWASP MASVS.

What we did

The hardcoded key turned up in static analysis on day one. Pinning bypass and traffic inspection took another two days of dynamic testing on rooted/jailbroken test devices, standard practice for this kind of assessment.

Fix

API key moved server-side and rotated, pinning implementation hardened, and sensitive fields in API responses reduced to what the screen actually needs. Re-tested on both platforms before the tender submission deadline.

Your turn

Become Our Next
Success Story

Every organisation has vulnerabilities. The question is whether you find them first or an attacker does.

Start Your Engagement Explore Services