Skip to content
HACKTECH

Work

Findings that mattered.

Client names and identifying details are removed from every write-up.

Fintech

Under two weeks

Clearing an investor security review in under two weeks

The problem

Investor due diligence asked for evidence that payment and onboarding flows had been tested by an independent party. The team had strong functional QA but no adversarial testing capability, and no report to hand to the investors' technical advisor. The investment was waiting on it.

How we worked

We ran a combined web and mobile assessment mapped to OWASP ASVS, with the API treated as a first-class target rather than an afterthought. Alongside the technical work we sat down with the product owners for a tabletop review of the fraud escalation path: who gets paged, what they can see, and what they are authorised to reverse.

What changed

Six high-risk findings were closed before the report was final, including an authorisation gap that allowed one tenant to enumerate another's invoice metadata. We supplied an assurance memo written for the investors' advisor, and a phased MFA rollout plan the team executed over the following quarter.

6

high-risk findings closed

<2 weeks

scope to final report

0

findings disputed at retest

Representative findings

  • CriticalCross-tenant invoice enumeration

    Sequential identifiers on a billing endpoint returned metadata for other tenants' invoices without an authorisation check.

  • HighPassword reset token reuse

    Reset tokens remained valid after use and did not expire on password change.

  • HighMobile client trusted server-supplied amounts

    A modified response could alter the displayed transaction total before user confirmation.

  • Web application
  • Mobile application
  • Payment API

Healthcare IoT

Under two weeks

Removing anonymous control access from clinical devices

The problem

Several hospital customers reported intermittent downtime on a device management API and escalated it as a reliability problem. Reviewing the pattern suggested something else: unauthenticated configuration endpoints were reachable from the clinical network, and were being hit by scanners.

How we worked

We combined a cloud configuration review with firmware analysis, then paired directly with the vendor's DevOps engineers rather than handing over a document. IAM policies were tightened against a privilege-escalation graph we built during the review, and we helped implement signed command validation so the devices would reject unauthenticated instructions outright.

What changed

Anonymous control access was eliminated. The false-alarm rate that had been driving the reliability complaints dropped sharply once scanner traffic stopped reaching device endpoints.

0

unauthenticated control endpoints remaining

~70%

reduction in false alarms

3

IAM escalation paths closed

Representative findings

  • CriticalUnauthenticated device configuration endpoint

    Configuration and restart commands were accepted without any authentication from the clinical network segment.

  • HighOver-permissive instance role

    A device gateway role could read every customer's telemetry bucket, not just its own tenant's.

  • MediumFirmware shipped with a static shared key

    The same symmetric key was present across the device fleet, so compromising one unit compromised the scheme.

  • Cloud
  • Device firmware
  • Management API

Logistics SaaS

About a month

Hardening partner SSO before go-live

The problem

Ahead of a launch, the customer trust team flagged partner accounts appearing with extra privileges that no administrator had assigned. They needed external validation of the identity layer before go-live, and their support engineers had no consistent triage process for this class of alert.

How we worked

We ran a purple-team engagement: adversarial simulation against the partner identity flows with the defenders watching, plus a full audit of the SCIM provisioning path where the privilege drift turned out to originate. We then ran triage workshops for the support and trust engineers using the actual alerts from the simulation.

What changed

The provisioning flaw was a group-mapping rule that granted attributes additively and never revoked them. Once fixed, privilege-misuse alerts fell by roughly 60%, and more than forty staff went into the launch with a rehearsed triage playbook rather than an untested one.

~60%

fewer privilege-misuse alerts

40+

staff trained on triage

1 month

start to go-live readiness

Representative findings

  • CriticalSCIM group mapping never revoked attributes

    Role changes added entitlements but did not remove superseded ones, so privileges accumulated silently over time.

  • HighSSO assertion audience not validated

    An assertion issued for one service provider was accepted by another in the same tenant.

  • MediumNo alerting on out-of-band entitlement change

    Privilege grants made outside the normal admin flow produced no log event the trust team could see.

  • Partner SSO
  • SCIM provisioning
  • Purple team
  • Training

One finding, exactly as we report it

Anonymised from a real report. Every finding ships with reproduction steps, impact in business terms, and remediation an engineer can act on without a follow-up call.

HT-04

Critical · 8.7 base (CVSS 4.0), raised to Critical for cross-tenant scope

Insecure direct object reference in billing API

Fixed and verified at retest

The invoice endpoint resolved records by a sequential identifier without verifying that the requesting principal owned the target tenant. Any unauthenticated caller could enumerate invoice metadata across the entire customer base.

Reproduction

  1. Authenticate as any tenant and capture a request to GET /invoices/{id}.
  2. Remove the Authorization header and replay the request.
  3. Decrement {id} and observe metadata returned for records belonging to other tenants.

Impact

Full disclosure of invoice metadata across all tenants: customer names, billing amounts, and subscription tier. Sufficient for competitor intelligence gathering and for targeted invoice fraud against named customers.

Remediation

Enforce tenant scoping in authorisation middleware rather than per-handler, so that new endpoints inherit the check by default. Replace sequential identifiers with UUIDv7. Add a contract test asserting that cross-tenant reads return 404 rather than 403, so the endpoint does not confirm record existence.

Timeline

  • Day 2Identified during authenticated API review
  • 25 minutes laterEscalated to client under critical-finding clause
  • Day 4Middleware fix deployed to production
  • Day 6Retested and confirmed remediated

Your product, tested the same way

A 45-minute scoping call ends with a fixed quote and a proposed start date; the written scope follows by email.