Post-mortem de Steakhouse révèle une usurpation DNS causée par le contournement de l'authentification à deux facteurs du registrar

ambcryptoPublié le 2026-04-10Dernière mise à jour le 2026-04-10

Résumé

L'incident de sécurité du 30 mars chez Steakhouse a été causé par une prise de contrôle du domaine via son bureau d'enregistrement, OVHcloud. Les attaquants ont réussi à contourner l'authentification à deux facteurs (2FA) par ingénierie sociale en se faisant passer pour le propriétaire du compte auprès du support. Cela leur a permis de supprimer la sécurité, de prendre le contrôle complet du compte et de rediriger les enregistrements DNS vers un site de phishing contenant un "wallet drainer". Bien que le site frauduleux ait été actif environ quatre heures, aucun fonds utilisateur n'a été perdu grâce aux protections des portefeuilles et à la réaction rapide de l'équipe. Le protocole on-chain est resté sécurisé. Cet incident met en lumière la vulnérabilité des infrastructures hors chaîne et le risque des fournisseurs tiers comme points de faille uniques. Steakhouse a depuis migré vers un registrar plus sécurisé, mis en place une surveillance DNS et renforcé ses contrôles de sécurité.

Un post-mortem de Steakhouse a apporté un nouvel éclairage sur un incident de sécurité survenu le 30 mars. Des attaquants ont brièvement détourné son domaine pour héberger un site de phishing, exposant une faille critique dans l'infrastructure hors chaîne plutôt que dans les systèmes on-chain.

L'équipe a confirmé que l'attaque provenait d'une tentative d'ingénierie sociale réussie ciblant son bureau d'enregistrement de domaines, OVHcloud. Cela a permis à l'attaquant de contourner l'authentification à deux facteurs et de prendre le contrôle des enregistrements DNS.

L'ingénierie sociale a conduit à une prise de contrôle complète du compte

Selon le rapport, l'attaquant a contacté le service d'assistance du registrar, s'est fait passer pour le propriétaire du compte et a convaincu un agent de support de supprimer l'authentification à deux facteurs matérielle.

Une fois l'accès obtenu, l'attaquant a rapidement exécuté une série d'actions automatisées. Cela comprenait la suppression des identifiants de sécurité existants, l'enregistrement de nouveaux appareils d'authentification et la redirection des enregistrements DNS vers une infrastructure sous son contrôle.

Cela a permis le déploiement d'un site web cloné de Steakhouse intégrant un « wallet drainer » (draineur de portefeuille), qui est resté accessible par intermittence pendant environ quatre heures.

Site de phishing actif, mais les fonds sont restés en sécurité

Malgré la gravité de la violation, Steakhouse a déclaré qu'aucun fonds utilisateur n'avait été perdu et qu'aucune transaction malveillante n'avait été confirmée.

La compromission était limitée à la couche domaine. Les coffres-forts on-chain et les contrats intelligents, qui fonctionnent indépendamment de l'interface, n'ont pas été affectés. Le protocole a souligné qu'il ne détient aucune clé administrateur permettant d'accéder aux dépôts des utilisateurs.

Les protections des portefeuilles navigateur de fournisseurs tels que MetaMask et Phantom ont rapidement signalé le site de phishing, tandis que l'équipe a émis un avertissement public dans les 30 minutes suivant la détection de l'incident.

Le post-mortem met en lumière le risque lié aux fournisseurs et les points de défaillance uniques

Le rapport pointe un échec clé dans les hypothèses de sécurité de Steakhouse : la dépendance à un seul registrar dont les processus de support pouvaient contourner les protections matérielles.

La possibilité de désactiver l'authentification à deux facteurs via un simple appel téléphonique, sans vérification hors bande robuste, a effectivement transformé une fuite d'identifiants en une prise de contrôle complète de compte.

Steakhouse a reconnu qu'il n'avait pas correctement évalué ce risque, décrivant le registrar comme un « point de défaillance unique » dans son infrastructure.

Les vulnérabilités hors chaîne restent un maillon faible

L'incident souligne un problème plus large dans la sécurité crypto : des protections on-chain solides n'éliminent pas les risques dans l'infrastructure environnante.

Bien que les contrats intelligents et les coffres-forts soient restés sécurisés, le contrôle du DNS a permis à l'attaquant de cibler les utilisateurs via le phishing, une méthode de plus en plus courante dans l'écosystème.

L'attaque a également impliqué des outils cohérents avec des opérations de « drainer-as-a-service » (draineur en tant que service), mettant en évidence la façon dont les attaquants continuent de combiner l'ingénierie sociale avec des kits d'exploitation prêts à l'emploi.

Mises à niveau de sécurité et prochaines étapes

Suite à l'incident, Steakhouse a migré vers un registrar plus sécurisé. Il a mis en œuvre une surveillance continue du DNS, a procédé à une rotation des identifiants et a lancé un examen plus large des pratiques de sécurité des fournisseurs.

L'équipe a également introduit des contrôles plus stricts pour la gestion de domaine, y compris l'imposition de clés matérielles et des verrouillages au niveau du registrar.


Résumé final

  • Le post-mortem de Steakhouse révèle qu'un contournement de la 2FA au niveau du registrar a permis une usurpation DNS, exposant les utilisateurs au phishing malgré des systèmes on-chain sécurisés.
  • L'incident souligne comment l'infrastructure hors chaîne et la sécurité des fournisseurs restent des vulnérabilités critiques dans les écosystèmes crypto.

Questions liées

QQuel a été la cause principale de l'incident de sécurité survenu chez Steakhouse le 30 mars ?

AL'attaque a été causée par une tentative d'ingénierie sociale réussie visant le bureau d'enregistrement de domaines OVHcloud, permettant à l'attaquant de contourner l'authentification à deux facteurs et de prendre le contrôle des enregistrements DNS.

QComment l'attaquant a-t-il réussi à contourner l'authentification à deux facteurs ?

AL'attaquant a contacté le service client du bureau d'enregistrement, s'est fait passer pour le propriétaire du compte et a convaincu un agent de support de désactiver l'authentification à deux facteurs matérielle.

QEst-ce que des fonds utilisateur ont été perdus lors de cet incident ?

ANon, aucun fonds utilisateur n'a été perdu et aucune transaction malveillante n'a été confirmée. Les coffres on-chain et les smart contracts n'ont pas été affectés.

QQuelles leçons Steakhouse a-t-il tirées de cet incident en matière de sécurité ?

ASteakhouse a reconnu que sa dépendance à un seul bureau d'enregistrement constituait un point de défaillance unique. L'entreprise a migré vers un registrar plus sécurisé, mis en place une surveillance DNS continue et renforcé les contrôles de gestion de domaine.

QQuel type de vulnérabilité cet incident met-il en évidence dans l'écosystème crypto ?

AL'incident souligne que les vulnérabilités hors chaîne (off-chain) et la sécurité des fournisseurs restent des points faibles critiques, même lorsque les protections on-chain sont solides.

Lectures associées

Trading

Spot
Futures
活动图片