EtherHiding — Blockchain comme infrastructure C2 indestructible (APT nord-coréen)¶
Resume¶
EtherHiding est une technique documentée par Google Mandiant : le groupe nord-coréen UNC5342 (lié à Lazarus/BlueNoroff) stocke des instructions C2 dans des smart contracts Ethereum/BNB. Le malware est livré via phishing ou fausse offre d'emploi, puis récupère ses payloads depuis la blockchain. L'immuabilité de la chaîne rend l'infrastructure C2 indestructible par les défenses classiques (takedown, sinkholing). Mise à jour du payload : 1,37$ par modification. Objectifs : vol de wallets crypto, espionnage.
Analyse critique¶
Sur l'article (CrispyBull) : vrai sur le fond, vulgarisé dans la forme. Trois exagérations à corriger :
- "La blockchain distribue des virus" — faux. La blockchain stocke les instructions C2, pas le malware lui-même. Le vecteur d'infection initial reste du phishing ou du social engineering classique. Rien ne s'exécute depuis la blockchain.
- "Impossible à arrêter" — exagéré. On peut bloquer les appels RPC Ethereum côté endpoint, détecter les comportements suspects (connexions inhabituelles à des nodes), sandboxer les scripts suspects.
- "Nouveau type révolutionnaire" — non. DNS-as-C2, GitHub-as-C2, Twitter-as-C2 existent depuis des années. EtherHiding y ajoute l'immuabilité et un coût de suppression infini — c'est une évolution du bulletproof hosting, pas un nouveau concept.
Ce qui est réellement nouveau : un État nation utilise la résistance à la censure de la blockchain comme propriété défensive pour son infrastructure offensive. L'immuabilité, conçue pour la confiance décentralisée, devient une propriété adversariale quand utilisée comme serveur de commande.
Pertinence ProbatioVault¶
Impact modéré — deux angles distincts.
Angle 1 — Immunité structurelle de l'architecture : ProbatioVault n'ancre que des hash (SHA3-256, racines Merkle). Un hash n'est ni exécutable, ni interprétable, ni récupérable. Même accès total à la blockchain = zéro information sur le contenu probatoire. Architecture structurellement orthogonale aux risques EtherHiding.
| ProbatioVault | EtherHiding | |
|---|---|---|
| Stocké on-chain | Hash SHA3-256 / Merkle root | Code exécutable C2 |
| Exécutable | Non | Oui |
| Reconstruction possible | Non (one-way) | Oui |
| Rôle | Ancrage d'intégrité | Serveur de commande |
Angle 2 — Pattern "verifier attestation" (insight actionnable) : L'article soulève une question indirectement intéressante pour ProbatioVault : si la blockchain est un registre permanent, peut-on y ancrer non seulement les preuves mais aussi l'outil qui permet de les vérifier ?
Le pattern correct serait : - Vérificateur open source, versionné, build déterministe - Hash de la release ancré on-chain - Dans chaque ProofEnvelope : champs verifier_version + verifier_hash + verifier_signature - Référence au dépôt public (pas le code on-chain — trop coûteux, immuabilité pénible)
Résultat : la preuve devient auto-suffisante indépendamment de la plateforme. Elle répond à "que se passe-t-il si ProbatioVault disparaît dans 10 ans ?" — le vérificateur est public, son intégrité est ancrée, la preuve reste vérifiable.
Ce pattern n'est pas dans la spec actuelle. À documenter comme user story future (ProofEnvelope + Verifier attestation).