Skip to content
HACKTECH

Work

Findings that mattered, written up honestly.

Client names withheld, numbers kept defensible. Each write-up is the shape of the real engagement: the problem, the approach, and what was different afterwards.

Fintech · Seed stage

Under two weeks

Clearing a Series A security review in under two weeks

The problem

Due diligence for a Series A round 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 round was waiting on it.

Our approach

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 authorization 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

  • critCross-tenant invoice enumeration

    Sequential identifiers on a billing endpoint returned metadata for other tenants' invoices without an authorization 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 applicationMobile applicationPayment 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.

Our approach

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, and the vendor renewed its largest hospital contract with the assessment report attached to the security questionnaire.

0

unauthenticated control endpoints remaining

~70%

reduction in false alarms

3

IAM escalation paths closed

Representative findings

  • critUnauthenticated 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.

  • medFirmware shipped with a static shared key

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

CloudDevice firmwareManagement API

Logistics SaaS · Scale-up

About a month

Hardening partner SSO before a regional launch

The problem

Ahead of a regional launch, the customer trust team flagged partner accounts appearing with elevated 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.

Our approach

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

  • critSCIM 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.

  • medNo 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 SSOSCIM provisioningPurple teamTraining

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-2024-0417

Critical · 9.1 (CVSS 4.0)

Insecure direct object reference in billing API

Fixed — 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 /api/v2/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 authorization 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 2, 14:20Identified during authenticated API review
  • Day 2, 14:45Escalated to client under critical-finding clause
  • Day 4Middleware fix deployed to production
  • Day 6Retested and confirmed remediated
Get a report like this for your product