Essayez de rassembler autant d'informations que possible. Voyez si l'hôte peut vous donner un journal montrant toutes les connexions FTP qui ont été établies sur votre compte. Vous pouvez les utiliser pour voir si c'était même une connexion FTP qui a été utilisée pour effectuer le changement et éventuellement obtenir une adresse IP.

Si vous utilisez un logiciel prêt à l'emploi comme Wordpress, Drupal ou tout autre logiciel que vous n'avez pas codé, il peut y avoir des vulnérabilités dans le code de téléchargement qui permettent ce type de modification. S'il est personnalisé, vérifiez tous les endroits où vous autorisez les utilisateurs à télécharger des fichiers ou à modifier des fichiers existants.

La deuxième chose serait de faire un dump du site tel quel et de tout vérifier pour d'autres modifications. Ce n'est peut-être qu'une seule modification qu'ils ont apportée, mais s'ils sont entrés via FTP, qui sait ce qu'il y a d'autre là-haut.

Remettez votre site dans un bon état connu et, si nécessaire, mettez à niveau vers la dernière version.

Il y a un niveau de rendement que vous devez également prendre en compte. Est-ce que les dégâts valent la peine d'essayer de retrouver la personne ou est-ce quelque chose où vous vivez et apprenez et utilisez des mots de passe plus forts ?

Le site est-il simplement HTML statique ? c'est-à-dire qu'il n'a pas réussi à coder lui-même une page de téléchargement permettant à quiconque passe par là de télécharger des scripts/pages compromis ?

Pourquoi ne pas demander à webhost4life s'ils ont des journaux FTP disponibles et leur signaler le problème. On ne sait jamais, ils peuvent être assez réceptifs et découvrir pour vous exactement ce qui s'est passé ?

Je travaille pour un hébergeur partagé et nous apprécions toujours les rapports de ce type et pouvons généralement identifier le vecteur exact de l'attaque et indiquer où le client s'est trompé.

Vous mentionnez que votre père utilisait un outil de publication de site Web.

Si l'outil de publication publie depuis son ordinateur vers le serveur, il se peut que ses fichiers locaux soient propres et qu'il ait juste besoin de republier vers le serveur.

Il devrait voir s'il existe une autre méthode de connexion à son serveur que le simple FTP, cependant... ce n'est pas très sécurisé car il envoie son mot de passe en texte clair sur Internet.

Nous avions apparemment été piratés par les mêmes gars ! Ou des bots, dans notre cas. Ils ont utilisé l'injection SQL dans l'URL sur certains anciens sites ASP classiques que plus personne ne maintient. Nous avons trouvé des adresses IP attaquantes et les avons bloquées dans IIS. Maintenant, nous devons refactoriser tous les anciens ASP. Donc, mon conseil est de jeter d'abord un coup d'œil aux journaux IIS, pour trouver si le problème vient du code de votre site ou de la configuration du serveur.

Débranchez le serveur Web sans l'arrêter pour éviter les scripts d'arrêt. Analysez le disque dur via un autre ordinateur en tant que lecteur de données et voyez si vous pouvez déterminer le coupable à l'aide de fichiers journaux et d'éléments de cette nature. Vérifiez que le code est sûr, puis restaurez-le à partir d'une sauvegarde.

Cela est arrivé récemment à un de mes clients qui était hébergé sur ipower. Je ne sais pas si votre environnement d'hébergement était basé sur Apache, mais s'il était sûr de vérifier les fichiers .htaccess que vous n'avez pas créés, en particulier au-dessus de la racine Web et à l'intérieur des répertoires d'images, car ils ont tendance à y injecter de la méchanceté. également (ils redirigeaient les personnes en fonction de leur provenance dans la référence). Vérifiez également tout code que vous avez créé pour le code que vous n'avez pas écrit.