Webshell C99, WSO, b374k : à quoi ça ressemble sur un site

À quoi ça ressemble dans le navigateur

Une UI sombre ou un tableau des années 2000 : arborescence, bouton Upload, champ « Command », parfois un mot de passe (`wso`, `admin`, un hash). Ce n'est pas wp-admin. Si vous tombez dessus en tapant une URL au hasard, fermez, notez l'URL, ne « testez » pas le terminal.

Certains shells sont mini : un champ unique, pas de marque. D'autres imitent un 404. Le HTML source contient souvent `WSO`, `Files-Man`, `uname`, `safe_mode`.

Ne poste pas de commande « pour voir ». Vous aggravez et vous mélangez vos hits aux siens dans les logs. Notez l'URL, l'heure, fermez l'onglet. La suite se fait en SFTP : copie hors serveur, puis retrait pour un 404. Un WSO laissé en 200 « le temps de comprendre l'UI » est une porte ouverte au monde pendant votre curiosité.

Noms de fichiers et camouflages

Les noms `wso[.]php`, `c99[.]php`, `b374k[.]php` existent encore, par paresse. Plus souvent : `radio.php`, `wp-core.php`, `images.php`, un nom de plugin. Voir PHP à la racine.

Le contenu est parfois encodé (base64). Un scan « C99 » rate le one-liner. Une UI WSO classique se reconnaît au HTML si vous l'avez déjà ouverte (preuve). Sinon, un même fichier qui upload, exécute du code et liste les dossiers.

Un shell dans `uploads` avec double extension : même famille, autre article. Cherchez les deux logements.

C99, WSO, b374k : trois familles, même métier

C99 : très vieux, encore copié, souvent lourd, beaucoup de fonctions réseau. WSO (Web Shell by Orb) : encore partout, login, gestionnaire de fichiers. b374k : UI plus « propre », même usage. Les forks changent les noms ; le métier ne change pas : lire, écrire, exécuter.

Vous n'avez pas à identifier la famille pour agir. Ça sert au constat et parfois à un scan de signatures pour trouver les copies. Un fork sans signature se trouve par date et par comportement.

Les « shells » modernes sont des une-lignes. Pas de UI. Plus discrets, même danger. Ne concluez pas « pas de WSO donc pas de shell ».

• UI fichiers + commandes = shell classique.
• One-liner = même urgence, autre recherche.
• La famille importe moins que les copies.

Ce que le shell a déjà pu faire

Lire `wp-config`, dumper la base, poser un admin, poser un second shell, lancer un mineur, envoyer du mail, déposer un kit phishing. Trouver WSO le lundi ne dit pas que rien n'a été fait le dimanche. Partez du principe que les secrets ont été lus : rotaez mots de passe et clés.

Les dates de fichiers dans tout le compte autour des hits du shell : carte de ce qu'il a écrit.

Si un kit bancaire est en ligne, l'exception coupe-d'abord s'applique. Le shell est alors l'outil, le kit le préjudice visiteur.

Trouver les copies, pas l'exemplaire unique

Un WSO en pose un autre sous un nom nouveau à chaque visite. Grep `Files-Man`, `WSO`, `b374k`, `uname -a` dans les PHP récemment touchés. Pesez les fichiers anormaux.

mu-plugins, thème, `wp-admin/includes`. Les copies aiment les dossiers que vous « ne touchez pas ».

La même minute d'upload FTP : grappe. Listez par mtime. Grep `Files-Man`, `WSO`, `b374k` ne suffit pas : les forks changent les chaînes. Pesez les PHP anormaux, ouvrez les dates de la fenêtre du premier hit. Un second shell de 8 Ko sans signature, posé dans `wp-admin/includes`, est le classique oubli après un Wordfence qui n'a flaggé que le fichier `wso[.]php`.

Logs : qui l'a appelé

`access.log` : URL du shell, IP, user-agent, query `?pass=`. Ça date l'usage, pas forcément l'entrée (l'entrée peut être un plugin, le shell est l'étape 2).

Beaucoup de 404 sur `c99[.]php`, `wso[.]php` : scans Internet, pas forcément un fichier présent. Un 200, lui, est le vôtre.

Gardez les extraits. Assureur, hébergeur, plainte. Les logs rotatent vite.

Retirer n'est pas durcir

Copie, retrait, 404. Puis entrée : plugin, mot de passe, voisin. Puis admins, cron, prepend. Un WSO en moins et un admin fantôme en plus : théâtre.

Interdire PHP dans uploads, désinstaller File Manager, 2FA plus tard. L'ordre habituel.

Changer les salts WordPress déconnecte ; ça ne retire pas un shell sur le disque. Partez du principe que `wp-config` a été lu : rotaez base, panel, SMTP, clés. Un WSO trouvé le lundi ne dit rien de ce qui a été dumpé le dimanche. J+1 : le fichier n'est pas revenu. S'il réapparaît, cron ou admin fantôme — pas « WordPress qui se répare tout seul ».

Faux amis : File Manager, Adminer

Un plugin File Manager légitime ressemble à un shell (arborescence, upload). La différence : vous l'avez installé, il a un header plugin, une page dans l'admin. S'il est là sans vous, c'est une porte — souvent pire qu'un WSO parce que « ça a l'air officiel ». Voir File Manager.

Adminer / phpMyAdmin à la racine : même logique. Légitime le temps d'une mig, criminel en 200 public. Voir Adminer public.

Ne les laissez pas « au cas où » après un WSO. Trop de portes de même métier.

Après : J+1 et les listes Google

Si le shell URL a été ouverte par des clients ou signalée, Chrome peut classer le domaine. 404 partout, puis réexamen. 24-72 h. Un WSO retiré et un kit encore là : refus.

J+1 : le fichier n'est pas revenu, pas de 200 sur d'anciens noms. Grep à nouveau.

Vous pouvez déclarer le site. L'URL du shell + la date des logs, c'est le bon début. Ne nous envoyez pas le PHP en pièce jointe ouverte sur un webmail.

• Copie + retrait de toutes les copies.
• Secrets considérés lus.
• Entrée et cron fermés.
• 404 confirmée, J+1 sans réécriture.