Attaque de cheval de Troie par porte dérobée contre un laboratoire de fabrication

Cet incident décrit une attaque complexe et de grande envergure basée sur des logiciels malveillants contre les systèmes de laboratoire de fabrication d'un grand fabricant de produits électroniques. Le laboratoire était une grande installation intégrée de test et de développement avec un nombre important de serveurs Windows et de machines de développement répartis sur plusieurs sites de construction. L’attaque était un cheval de Troie de porte dérobée qui était à l’époque une variante nouvelle et inconnue. On ne sait pas s’il s’agissait d’une attaque dirigée ni l’intention de l’attaque. Initialement, il semblait qu'un seul serveur avait été infecté puis nettoyé automatiquement par son logiciel antivirus. L'inspection des journaux antivirus sur ce serveur a indiqué que le virus avait été supprimé. Malheureusement, une enquête ultérieure a prouvé que ce n’était pas le cas. Le virus avait créé un fichier nommé administrateur.txt qui contenait une liste d'adresses IP de toutes les machines du laboratoire, ainsi que tous les noms de compte pour chaque machine enregistrée et le mot de passe de ce compte. La plupart des comptes enregistrés étaient des comptes d'administrateur local avec des mots de passe vides ou des mots de passe composés de l'expression “password”. Le virus avait configuré un serveur FTP et envoyait ces informations vers un emplacement inconnu. Le serveur a été déconnecté et le fichier Administrator.txt a été imprimé. Un autre serveur rencontrait des problèmes similaires et une décision a été prise de déconnecter ce serveur du réseau car il contenait probablement un virus. Cependant, les utilisateurs ont refusé car ils ne pouvaient pas économiser le temps d'arrêt. La direction a donc été invitée à déconnecter les machines de laboratoire infectées, ce qui entraînerait une diminution de la production et donc des coûts. En quelques heures, au moins la moitié des machines du laboratoire se sont révélées infectées et ont été déconnectées du réseau (avec arrêts de production). À partir de là, le problème a été aggravé et des sociétés ont été contactées pour partager des informations. Les fournisseurs de support réseau et bureautique de l’entreprise ont été informés de la situation et un appel a été lancé au service de sécurité du réseau de l’organisation. Un représentant du fournisseur de logiciels antivirus a également été contacté. Le problème a été considéré comme maîtrisé en fin de journée mais n’a pas été résolu. Près d’une semaine s’est écoulée et il fallait désespérément trouver une solution immédiate. Les ingénieurs ont décidé de provoquer l’équivalent d’une mutinerie en reconfigurant les bancs d’essai avec les machines reliées aux hubs et aux commutateurs pour la connectivité. Il n'y avait aucun accès aux serveurs DNS, aucun processus de communication et aucune documentation pour modifier les nombreux mots de passe intégrés. Aucun correctif officiel n'était encore disponible et certaines ressources précieuses n'étaient pas correctement sauvegardées. En fin de compte, les utilisateurs ont été aidés avec des solutions de contournement jusqu'à ce que le réseau et toutes les ressources associées soient opérationnels.

Au total, environ 3 semaines de temps de développement et d'innombrables autres heures ont été perdues, bien que le nombre réel ne soit pas connu.