Basilisk
BASILISK
[cases_index]REAL ENGAGEMENTS · ANONYMIZED

Before it became a headline, it became a fix.

All cases below were anonymized under NDA. Numbers, sector and vector are real — client name is not.

200+
engagements delivered
4,500+
exploitable flaws reported
R$ 180M+
potential impact avoided
sector
Fintech · Open Finance
vector
API misconfig + IDOR
fix
72h
case/01

Full access to production via unauthenticated internal API

Admin endpoint exposed by API gateway misconfig. Combined with IDOR in transfer routes, allowed pivot to any account. Identified on day 2 of the engagement.

impact avoided:R$ 48M in potential movement blocked
sector
Healthtech · SaaS
vector
Cloud misconfig
fix
24h
case/02

Exposure of 1.2M health records via staging S3 bucket

Staging bucket replicated production data without encryption or access control. Fixed before external ISO audit.

impact avoided:GDPR fine avoided · non-reportable incident
sector
Industry · OT
vector
Segmentation + legacy credentials
fix
2 weeks
case/03

Lateral movement from IT to industrial plant via legacy VPN

Red Team engagement starting from phishing. Pivot from engineering station to OT network via VPN with default credentials. Fixed with segmentation + jump host + MFA.

impact avoided:Prevented line stoppage estimated in 8 days
sector
E-commerce · B2C
vector
XSS + session without rotation
fix
96h
case/04

Exploit chain: XSS → admin account takeover → balance

Reflected XSS on search page combined with permissive cookie policy allowed admin session theft. Identified in standard pentest.

impact avoided:Fraud blocked, estimated R$ 2.3M/month

Why every case here is anonymised

Publishing a customer's name alongside the flaw they had exposes them twice: once during the incident and once permanently. Describing the vector and the impact teaches something; identifying the victim is just a shop window — and it skews the incentive, because the company willing to authorise disclosure becomes the one with least to lose.

  • Names, brands and any detail that could identify the company stay out.
  • The technical vector is kept, because that is the part with value for the reader.
  • Nothing is published before remediation is complete and confirmed by retest.
  • All material goes through customer authorisation before it becomes public text.

Patterns that keep recurring

Different sectors, different architectures — and still the routes that work look alike. These are the ones that come up most often, and they are worth looking at before commissioning any test.

// an environment that should not exist

Staging with a copy of production, an old admin panel, a service spun up for a demo and never switched off. It is usually missing from the inventory and therefore outside every protection applied to everything else.

// object-level authorisation

The system checks that you are authenticated but not that the record is yours. It is the flaw automated tooling misses most often, because the request looks perfectly legitimate.

// permanent temporary permission

Broad access granted to unblock a delivery, with a promise to tighten it later. Months on it is still there, now inherited by people who never knew they had it.

// a secret in the wrong place

A key in an exposed environment variable, a credential in repository history, a token in a versioned config file. It is the shortest path in and the easiest to close.

// trust between systems

Two applications that authenticate to each other by network position or a shared secret. Compromising the less protected one delivers the better protected one, and the segmentation meant to contain that has rarely been tested.

// detection that reaches nobody

The event was logged, the alert fired — and landed in a queue nobody reads. Technically detected, practically invisible: the difference only shows up in an unannounced exercise.

Frequently asked questions

01Why is there no customer name here?

Because authorisation to publish would come from whoever has least to lose, not from whoever had the most instructive case. All material is anonymised under a confidentiality agreement, and the technical vector — the useful part — is preserved.

02Will you act as a reference in our procurement process?

Yes, subject to authorisation from the parties involved. For most processes, though, what settles it is the closing letter from your own engagement, issued after retest: that is direct evidence, rather than a third party's opinion about someone else's work.

03Does a case similar to ours mean our test would look the same?

No. The route depends on architecture, integrations and decisions that only surface in your environment. The cases show the kind of thing that tends to be found, not a script that repeats.

04Do you publish a flaw before it is fixed?

Never. Nothing becomes public text before remediation is complete and confirmed by retest, and even then only with authorisation. The same criterion governs our own research, set out in the responsible disclosure policy.

// contact

Ready to uncover your flaws?

First scoping call is free and covered by NDA. Within 48 hours you receive technical proposal, scope and timeline. No bureaucratic forms.