Comment détecter une backdoor sur son serveur FiveM ?

Contexte

Vous gérez un serveur FiveM (GTA RP) et vous avez un doute ? Votre serveur se comporte bizarrement, des logs étranges apparaissent dans la console, votre serveur crashe sans raison apparente, ou des actions inhabituelles s'exécutent en jeu. Avant de paniquer, il faut savoir lire les signes d'une backdoor pour confirmer ou infirmer vos craintes.

Ce guide vous explique comment reconnaître les comportements typiques d'une backdoor sur un serveur FiveM, comment réagir, et quoi faire si vos doutes se confirment.

Qu'est-ce qu'une backdoor sur FiveM ?

Une backdoor (porte dérobée) est un morceau de code malveillant dissimulé dans une ressource FiveM apparemment légitime. Elle permet à son auteur d'accéder à votre serveur sans votre autorisation, d'exécuter des commandes, de voler des données, ou d'injecter du code malveillant dans d'autres ressources de votre serveur pour mieux se cacher.

Dans la grande majorité des cas, les backdoors FiveM proviennent de ressources "leakées" (revendues ou redistribuées sans l'accord du créateur original). C'est le premier endroit où chercher quand vous suspectez quelque chose.

Les comportements typiques d'une backdoor

Une backdoor FiveM cherche généralement à faire trois choses principales.

1. Lire vos fichiers de configuration (notamment server.cfg qui contient vos mots de passe MySQL et clés API)
2. Écrire dans d'autres ressources de votre serveur pour injecter du code malveillant ailleurs et persister même si la ressource d'origine est supprimée
3. Exécuter des commandes système pour étendre son contrôle au serveur entier

Si vous observez un ou plusieurs de ces comportements dans vos logs, vous avez très probablement une backdoor active.

Reconnaître les logs suspects

FiveM dispose d'un système de permissions strict qui logue et bloque certaines actions sensibles. Quand une ressource essaie de faire quelque chose qu'elle ne devrait pas, vous verrez des messages très précis dans la console de votre serveur.

Lecture/écriture de fichiers hors du dossier de la ressource

Une ressource légitime n'a aucune raison d'aller lire ou écrire dans le dossier d'une autre ressource ou dans la racine de votre serveur. Si vous voyez ce type de message.

[c-scripting-node] Filesystem write permission check from 'NOM_RESSOURCE' for permission fs.write on resource '/home/container/resources/[autre_ressource]/fichier.lua' - write not allowed

[c-scripting-node] Filesystem permission check from 'NOM_RESSOURCE' for permission fs.read on resource './server.cfg' - no device found

C'est un signal très fort de backdoor. Une ressource saine se contente de lire ses propres fichiers, pas ceux des autres et encore moins votre server.cfg.

Sondage de plusieurs chemins d'installation possibles

Une variante fréquente consiste à tester successivement plusieurs chemins d'installation FiveM classiques, sans savoir à l'avance lequel est utilisé sur le serveur ciblé. Notre support a par exemple déjà observé ce cas précis chez un client.

[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/home/fivem/server/resources' - no device found
[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/home/fivem/server-data/resources' - no device found
[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/opt/fivem/server/resources' - no device found
[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/opt/fxserver/resources' - no device found
[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/srv/fivem/resources' - no device found
[c-scripting-node] Filesystem permission check from 'signal' for permission fs.read on resource '/root/FXServer/server-data/resources' - no device found

Ici, la ressource portait le nom signal, ce qui n'a rien d'officiel ni de rassurant en soi. Une ressource légitime connaît son propre dossier d'installation, elle n'a aucune raison de tester une liste de chemins classiques utilisés par différents hébergeurs ou installations FiveM à la recherche du dossier resources. Ce comportement est caractéristique d'un code qui cherche à se localiser sur un serveur inconnu pour ensuite naviguer dans l'arborescence complète.

Tentative d'exécution de commandes système

Si vous voyez ce type de log.

[c-scripting-node] Child process permission check from 'NOM_RESSOURCE' for permission child on resource '/bin/sh' - child spawn not allowed

C'est extrêmement grave. La ressource essaie d'ouvrir un shell sur votre serveur, ce qui n'a strictement aucun intérêt pour une ressource FiveM normale. C'est l'un des comportements les plus caractéristiques d'une backdoor cherchant à prendre le contrôle de votre serveur.

Crash brutal du serveur

D'après les retours de notre support, un autre comportement suspect que nous remarquons régulièrement est le crash brutal du serveur FiveM, souvent accompagné de logs de ce type.

║ STDERR║ Assertion failed: fd_to_send >= 0 (../deps/uv/src/unix/stream.c: uv__try_write: 791)
║ TXADMIN║ Restarting server: Server process close detected.

Si votre serveur redémarre brutalement plusieurs fois par jour sans raison apparente, et que vous voyez ce genre d'erreur dans la console, c'est un fort indicateur qu'une ressource malveillante essaie d'exécuter du code qui fait planter le processus FiveM. Combiné aux autres signes (tentatives de lecture/écriture, child process), le diagnostic ne fait que peu de doute.

Autres signes à surveiller

D'autres comportements doivent vous alerter, même sans message explicite dans les logs.

• Joueurs qui obtiennent soudainement les permissions admin sans intervention de votre part
• Messages étranges qui apparaissent dans le chat sans qu'aucun script légitime ne les envoie
• Données qui disparaissent ou se modifient dans la base de données (argent, inventaire, véhicules)
• Connexions inhabituelles dans les logs (identifiants Steam/Discord inconnus avec des permissions élevées)
• Ressources qui apparaissent ou se modifient seules sur votre serveur
• Pics d'utilisation CPU ou réseau inexpliqués

Inspecter les fichiers d'une ressource suspecte

Avant même d'installer une ressource, ou si vous suspectez qu'une ressource déjà installée est compromise, prenez le temps d'ouvrir et de parcourir ses fichiers. C'est souvent là que se cachent les vraies surprises.

Vérifier le fxmanifest.lua

Le fichier fxmanifest.lua liste tous les fichiers chargés par la ressource (côté client, côté serveur, fichiers partagés). Ouvrez-le et lisez attentivement chaque ligne.

client_scripts {
    'client/main.lua',
    'client/aafdsd.js',  -- ⚠️ Suspect
}

server_scripts {
    'server/main.lua',
    'server/x9d2k.js',   -- ⚠️ Suspect
}

Si vous voyez des fichiers avec des noms aléatoires ou incompréhensibles (aafdsd.js, xk2j9.lua, _temp.js, etc.) au milieu de fichiers aux noms cohérents (main.lua, config.lua, inventory.js), c'est un drapeau rouge majeur. Aucun développeur sérieux ne nomme ses fichiers comme ça. C'est presque toujours du code malveillant qu'on a essayé de glisser discrètement.

Vérifier le contenu de chaque fichier

Ouvrez chaque fichier .lua, .js ou .json listé dans le fxmanifest.lua et regardez son contenu. Voici les signes les plus parlants.

• Code obfusqué dans une ressource gratuite ou leakée (variables et fonctions remplacées par des chaînes incompréhensibles comme _0x4a8f, aA9Z_x, ou des longues chaînes encodées en base64)
• Fonctions inutilement complexes dans une ressource pourtant simple
• Appels suspects à des modules comme child_process, fs, http, net sans raison apparente
• URLs inconnues vers des serveurs externes ou des Discord webhooks
• Code commenté ou désactivé qui ne devrait pas être là

Attention aux fichiers qui semblent courts

Une technique très répandue consiste à faire passer un fichier pour court alors qu'il contient du code malveillant caché plus bas.

Le créateur de la backdoor place son code visible au début (quelques dizaines ou centaines de lignes qui ont l'air normales), puis ajoute des milliers de lignes vides pour pousser la charge utile tout en bas du fichier. Quand vous ouvrez le fichier dans un éditeur, vous voyez la fin du code apparent et vous pensez que c'est tout, sans vous douter qu'en descendant la barre de défilement, des milliers de lignes vides cachent un autre bloc de code malveillant.

Que faire si vous suspectez une backdoor ?

Si les signes ci-dessus correspondent à ce que vous observez, voici la marche à suivre.

1. Identifiez la ressource coupable

Dans les logs, repérez le nom de la ressource qui apparaît dans les messages suspects (entre apostrophes). C'est votre point de départ.

2. Arrêtez immédiatement la ressource

Depuis la console FiveM, stoppez la ressource suspecte.

stop NOM_RESSOURCE

Puis commentez sa ligne ensure dans votre server.cfg pour qu'elle ne se relance pas au prochain redémarrage.

3. Sauvegardez les logs

Avant toute autre action, sauvegardez l'intégralité de la console du serveur dans un fichier texte. Ces logs sont essentiels pour analyser l'étendue de l'infection et déterminer quelles informations ont pu être volées.

4. Changez tous vos mots de passe

Si la backdoor a eu accès à votre server.cfg, considérez tous vos identifiants comme compromis.

• Mot de passe MySQL (depuis votre panel Winheberg, option Rotate password)
• Clés API (Discord, Steam, services tiers)
• Mot de passe de votre compte Winheberg
• Tout autre secret présent dans server.cfg

5. Analysez votre base de données

Vérifiez si des données ont été modifiées ou exfiltrées.

• Comptes admin ajoutés récemment
• Modifications anormales sur les tables sensibles (users, permissions, bans)
• Tables inconnues qui auraient été créées par la backdoor

6. Supprimez la ressource

Une fois les preuves sauvegardées, supprimez complètement le dossier de la ressource compromise. Ne vous contentez pas de la désactiver, car une partie du code peut encore s'exécuter dans certaines conditions.

Existe-t-il des outils pour scanner les ressources ?

La communauté FiveM a développé plusieurs scanners de ressources capables de détecter automatiquement les patterns malveillants connus (obfuscation, appels suspects, code suspect, etc.). D'après les retours de notre support, ces outils marchent plutôt bien, mais avec quelques limites importantes.

• Il faut trouver une ressource de scan fiable et maintenue activement, car les patterns évoluent
• Les techniques utilisées par les créateurs de backdoors évoluent constamment. Ce qui passait au scan il y a 6 mois peut désormais être détecté, et inversement, une nouvelle technique peut passer sous les radars
• Un scan qui ne détecte rien ne garantit pas qu'il n'y a pas de backdoor, c'est juste un indice de plus

Winheberg peut vous aider à investiguer

Si vous avez un doute sérieux sur une backdoor, notre équipe peut effectuer une investigation réseau sur votre serveur. Nous pouvons notamment vérifier les éléments suivants.

• Si votre serveur communique avec des adresses IP suspectes liées à des backdoors connues
• Si des flux de données sortants anormaux indiquent une exfiltration en cours
• Quelles connexions entrantes se sont établies avec votre serveur récemment

Cette analyse permet de confirmer ou écarter la présence d'une backdoor active et d'évaluer l'étendue d'une éventuelle compromission. Contactez notre support en précisant que vous suspectez une backdoor, et nous lancerons l'investigation rapidement.

Comment éviter les backdoors à l'avenir

La meilleure défense contre les backdoors reste la prévention. Quelques règles à appliquer systématiquement.

• Téléchargez vos ressources uniquement depuis des sources officielles (Tebex, GitHub des auteurs reconnus, FiveM Releases sur Cfx.re)
• N'utilisez pas de ressources leakées. Au-delà du risque massif de backdoor, c'est aussi un manque de respect envers les développeurs qui passent des dizaines d'heures à concevoir ces ressources. Soutenir les créateurs, c'est aussi protéger votre propre serveur
• Lisez le code des ressources avant de les installer (au moins les fichiers .lua principaux et le fxmanifest.lua)
• Méfiez-vous des fichiers obfusqués ou compilés (.luac, code volontairement illisible) si la ressource est gratuite ou leakée. Un développeur qui partage son travail gratuitement n'a aucune raison de cacher son code
• Surveillez régulièrement vos logs pour détecter les comportements suspects au plus tôt
• Mettez à jour vos artifacts FiveM régulièrement pour bénéficier des dernières protections (voir notre guide sur le changement de version FiveM)
• Faites des sauvegardes régulières de votre serveur et de votre base de données

Besoin d'aide ?

Si vous avez le moindre doute sur une backdoor active sur votre serveur, notre équipe est là. Mieux vaut une alerte pour rien qu'une compromission qui s'installe dans la durée. Ouvrez un ticket dans le département Technique depuis votre espace client, renseignez le champ Produit lié avec le serveur concerné, et joignez les logs suspects à votre demande pour accélérer notre analyse.

Restez vigilant et bonne chance pour protéger votre serveur 🔒