Le 15 mai 2015, trois comptes en banque sont ouverts auprès de la Rizal Commercial Banking Corporation (RCBC), et restent inactifs jusqu'au 4 février 2016. Quelques mois plus tard, les autorités découvrent que ces comptes sont faux, et que les cybercriminels à leur origine ont planifié leur attaque près d'un an à l'avance pour tenter de subtiliser un milliard de dollars à la Banque Centrale du Bangladesh (BCB). Mais une faute d'orthographe révèle le pot aux roses et permet aux pirates de ne dérober au final que 81 millions de dollars.

 Connaître SWIFT et son rôle dans les transactions monétaires entre institutions financières, ainsi qu'avec les banques centrales pour mieux comprendre cette attaque -

La coopérative de services financiers SWIFT appartient à ses propres membres et propose un réseau sécurisé via lequel les banques peuvent émettre et recevoir des transactions monétaires. Elle contrôle et gère de façon centralisée son réseau du même nom, et chaque banque membre peut s'y connecter en toute sécurité via ses propres systèmes pour le transfert d'argent. Cependant, avant de pouvoir envoyer ou recevoir des fonds, une banque doit d'abord recevoir un certificat numérique unique de la part de SWIFT ; pour qu'un nouveau certificat soit émis, les banques membres doivent effectuer plusieurs démarches pour le compte de leurs nouveaux utilisateurs autorisés, en vue de contrôler et de valider leur identité, de vérifier leur lien avec la banque et les autorisations qui leur sont octroyées.

Une fois le certificat créé et provisionné, la banque membre a pour mission d'en sécuriser au maximum les identifiants ultra-sensibles. Ainsi, lorsqu'une banque veut envoyer une nouvelle demande de transfert de fonds vers un autre établissement bancaire, l'utilisateur approuvé doit faire vérifier et authentifier son certificat numérique par le réseau SWIFT. Celui-ci établit ensuite, via son canal SWIFTNet, un tunnel crypté par lequel la demande est envoyée dans un premier temps à partir de la banque membre émettrice vers SWIFTNet, puis de ce dernier vers le destinataire. Ceci garantit l'intégrité des demandes et écarte tout risque d'attaque de type « intermédiaire ». Bien que ce processus soit en lui-même sécurisé, il reste vulnérable aux éventuelles défaillances des banques membres. Si l'une d'elles ne sécurise pas correctement ses systèmes et les comptes qui se connectent à SWIFTNet, les pirates informatiques pourront se déguiser en utilisateurs autorisés et réaliser des transactions sur SWIFTNet, sans pour autant pirater le réseau en lui-même.

Comment les pirates se sont infiltrés dans les systèmes

Lors du piratage de la BCB, les hackers ont tout d'abord infiltré le périmètre informatique à l'aide d'un malware, probablement par une technique d'hameçonnage ou via une infection par téléchargement « drive-by ». Une fois à l'intérieur, les pirates ont pu dérober des identifiants dans les systèmes infectés, les utiliser pour se déplacer latéralement dans le réseau informatique et s'immiscer ainsi dans les systèmes connectés à SWIFT appartenant à et gérés par la BCB. Ces derniers étaient configurés avec le logiciel SWIFTNet Link (SNL) qui permettait aux machines de se connecter de façon sécurisée au réseau SWIFT. Ainsi, une fois à l'intérieur des systèmes connectés à SWIFT, les pirates ont pu opérer exclusivement à l'aide de comptes administrateurs locaux.

 Les banques centrales séparent généralement les systèmes connectés à SWIFT du reste de leur réseau informatique, et jusqu'en octobre 2015, il en était de même pour la BCB. Cependant, au mois d'octobre, celle-ci a lancé un nouveau service baptisé Real Time Gross Settlement (RTGS), dont les systèmes au moment de la configuration ont été directement connectés au réseau informatique et aux systèmes reliés à SWIFT. Cela a ainsi supprimé le cloisonnement mis en place, offrant aux pirates informatiques une passerelle directe entre les réseaux IT et les systèmes SWIFTNet Link.

Une fois à l'intérieur des systèmes connectés à SWIFT, les pirates ont installé l'outil « SysMon in SWIFTLIVE » pour surveiller l'ensemble des activités. Les pirates ont alors découvert que chaque demande envoyée ou reçue était automatiquement redirigée vers une imprimante. Afin de rester discrets et dissimuler leurs activités, les pirates ont donc utilisé leurs accès privilégiés pour déployer un malware avancé qui a désactivé l'imprimante connectée. Les employés de la banque ayant constaté qu'une imprimante ne fonctionnait plus, ont simplement supposé qu'il s'agissait d'une erreur d'imprimante et non du signe d'une attaque en cours. Une fois à l'intérieur des systèmes, les pirates ont alors pu subtiliser les certificats numériques nécessaires ainsi que les mots de passe utilisés par la BCB pour en protéger l'accès dont le système à authentification unique est très facile à pirater. Les hackers ont alors pu envoyer des messages financiers via les systèmes sécurisés et à accès contrôlé SWIFTNet, en se faisant passer pour des utilisateurs autorisés.

Résultats de l'attaques et versements des paiements

Les pirates sous identités légitimes ont demandé 35 transferts d'une valeur de 951 millions de dollars authentifiées par SWIFTN et envoyées à la Réserve fédérale américaine. Interpellée par le nombre important de demandes émises, celle-ci a contacté la BCB pour vérifier, mais l'activité ayant lieu durant le weekend personne n'était en mesure de répondre. Les messages SWIFT étant généralement fiables, la Réserve fédérale a alors commencé à traiter les demandes sans attendre le lundi matin.

Les quatre premières demandes de transfert, d'une valeur totale de 81 millions de dollars, ont ainsi été envoyées vers quatre faux comptes bancaires chez RCBC aux Philippines. Une fois versé, l'argent a ensuite été transféré vers un compte bancaire ouvert le jour-même, puis envoyé à une société de transfert d'argent, et ensuite distribué entre une société de casinos, un hôtel et une société de loisirs. La majeure partie de cette somme d'argent reste introuvable, car sa trace s'arrête là. La cinquième demande, d'une valeur de 20 millions de dollars, a également été exécutée par la Réserve fédérale de New York sans trop de questions, mais a été identifiée par la Deutsche Bank (une banque intermédiaire pour cette transaction) comme suspecte. Le destinataire était en effet repris sous l'appellation « Shalika Fandation ».

L'orthographe de « Fandation » a éveillé les premiers soupçons, et après analyse plus approfondie, aucune trace d'une Fondation Shalika au Sri Lanka n'a été trouvée. A ce moment, l'argent avait déjà été transféré vers la société bancaire Pan Asia, mais Deutsche Bank a pu stopper les paiements de la transaction, permettant ainsi à Pan Asia d'empêcher la distribution des fonds. De ce fait, lorsque le piratage a été mis à jour, Pan Asia a pu restituer les 20 millions de dollars à leur propriétaire légitime. Cette faute d'orthographe épinglée par la Deutsche Bank a poussé la Réserve fédérale de New York à contacter la BCB au sujet des 30 autres transactions. C'est alors que cette dernière a découvert le pot aux roses ; l'imprimante qui avait été désactivée a alors été restaurée, et les 35 transactions ont été imprimées. A ce jour, la Banque du Bangladesh n'a pas encore pu récupérer les 81 millions de dollars, mais le préjudice est minime par rapport aux 951 millions de dollars qui auraient dû être dérobés. Si les pirates n'avaient pas fait cette faute de frappe, la Banque Centrale du Bangladesh aurait perdu près d'un milliard de dollars américains.

Cette attaque, qui nécessite une grande préparation, a eu de graves conséquences, même si les méthodes utilisées n'étaient pas très sophistiquées. Si la banque avait veillé à déployer les bons outils et les bonnes politiques, tout ceci aurait pu être évité. Un contrôle proactif des comptes à privilèges aurait pu fortement compliquer la tâche des pirates informatiques ; ils auraient tout d'abord eu beaucoup de mal à intégrer l'environnement SWIFT, et les outils de détection avancés auraient probablement détecté des connexions anormales qui auraient immédiatement été signalées à l'équipe de sécurité.