Basilisk
BASILISK
[cases_index]REAL ENGAGEMENTS · ANONYMIZED

Before it became a headline, it became a fix.

Tous les cas ci-dessous ont été anonymisés sous NDA. Les chiffres, le secteur et le vecteur sont réels — le nom du client ne l'est pas.

200+
engagements delivered
4,500+
failles exploitables signalées
R$ 180M+
impact potentiel évité
sector
Fintech · Open Finance
vector
API misconfig + IDOR
fix
72h
case/01

Accès complet à la production via une API interne sans authentification

Un point d'accès d'administration était exposé par une mauvaise configuration de la passerelle d'API. Combiné à un IDOR sur les routes de virement, il permettait d'atteindre n'importe quel compte. Détecté au 2e jour de la mission.

impact avoided:48 M R$ de mouvements potentiels bloqués
sector
Healthtech · SaaS
vector
Cloud misconfig
fix
24h
case/02

Exposition de 1,2 M de dossiers médicaux via un bucket S3 de préproduction

Le bucket de préproduction répliquait les données de production sans chiffrement ni contrôle d'accès. Corrigé avant l'audit ISO externe.

impact avoided:Amende RGPD évitée · incident non notifiable
sector
Industry · OT
vector
Segmentation + identifiants hérités
fix
2 weeks
case/03

Déplacement latéral de l'informatique de gestion vers l'usine via un VPN hérité

Mission Red Team partie d'un phishing. Rebond d'un poste d'ingénierie vers le réseau OT via un VPN aux identifiants par défaut. Corrigé par la segmentation, un rebond dédié et l'authentification multifacteur.

impact avoided:Arrêt de ligne estimé à 8 jours évité
sector
E-commerce · B2C
vector
XSS + session sans rotation
fix
96h
case/04

Chaîne d'exploitation : XSS → prise du compte admin → solde

Un XSS réfléchi sur la page de recherche, associé à une politique de cookies trop permissive, permettait de voler la session administrateur. Détecté lors d'un pentest classique.

impact avoided:Fraude bloquée, estimée à 2,3 M R$ par mois

Pourquoi chaque cas ici est anonymisé

Publier le nom d'un client à côté de la faille qu'il a subie l'expose deux fois : une pendant l'incident, une pour toujours. Décrire le vecteur et l'impact enseigne quelque chose ; identifier la victime ne sert que de vitrine — et fausse l'incitation, car l'entreprise prête à autoriser la publication devient celle qui avait le moins à perdre.

  • Nom, marque et tout détail permettant d'identifier l'entreprise restent dehors.
  • Le vecteur technique est conservé, car c'est la partie qui a de la valeur pour qui lit.
  • Rien n'est publié avant que la correction soit achevée et confirmée par contre-test.
  • Tout le matériel passe par l'autorisation du client avant de devenir un texte public.

Des schémas qui reviennent

Des secteurs différents, des architectures différentes, et pourtant les chemins qui fonctionnent se ressemblent. Voici ceux qui reviennent le plus souvent ; ils méritent un regard avant de commander le moindre test.

// un environnement qui ne devrait pas exister

Recette avec copie de la production, ancienne interface d'administration, service lancé pour une démonstration et jamais éteint. Il manque souvent à l'inventaire et se retrouve donc hors de toute protection appliquée au reste.

// autorisation au niveau objet

Le système vérifie que vous êtes authentifié, mais pas que cet enregistrement est le vôtre. C'est la faille que l'outil automatique laisse le plus souvent passer, car la requête paraît parfaitement légitime.

// permission temporaire devenue permanente

Accès large accordé pour débloquer une livraison, avec la promesse de le resserrer ensuite. Des mois plus tard il est toujours là, désormais hérité par des gens qui n'ont jamais su l'avoir.

// un secret au mauvais endroit

Une clé dans une variable d'environnement exposée, un identifiant dans l'historique du dépôt, un jeton dans un fichier de configuration versionné. C'est le chemin le plus court vers l'intérieur et le plus simple à refermer.

// confiance entre systèmes

Deux applications qui s'authentifient par position réseau ou par un secret partagé. Compromettre la moins protégée livre la mieux protégée, et le cloisonnement censé contenir cela a rarement été testé.

// une détection qui n'atteint personne

L'événement a été journalisé, l'alerte a été levée — et elle a atterri dans une file que personne ne lit. Techniquement détecté, pratiquement invisible : la différence n'apparaît que lors d'un exercice sans préavis.

Questions fréquentes

01Pourquoi aucun nom de client ici ?

Parce que l'autorisation de publier viendrait de qui a le moins à perdre, et non de qui a connu le cas le plus instructif. Tout le matériel est anonymisé sous accord de confidentialité, et le vecteur technique — la partie utile — est conservé.

02Servez-vous de référence dans notre processus d'achat ?

Oui, avec l'autorisation des parties concernées. Pour la plupart des processus, toutefois, ce qui tranche est la lettre de clôture de votre propre mission, émise après contre-test : c'est une preuve directe, et non l'avis d'un tiers sur le travail d'un autre.

03Un cas proche du nôtre signifie-t-il que notre test serait identique ?

Non. Le chemin dépend de l'architecture, des intégrations et de décisions qui n'apparaissent que dans votre environnement. Les cas montrent le genre de chose que l'on trouve d'ordinaire, pas un scénario qui se répète.

04Publiez-vous une faille avant qu'elle soit corrigée ?

Jamais. Rien ne devient un texte public avant que la correction soit achevée et confirmée par contre-test, et encore faut-il une autorisation. Le même critère régit notre propre recherche, décrit dans la politique de divulgation responsable.

// contact

Prêt à découvrir vos failles ?

Premier appel de scoping gratuit et couvert par NDA. En 48 heures vous recevez proposition technique, portée et calendrier. Sans formulaires bureaucratiques.