Guide Red TeamTests d’intrusion autorisés · Red Team · Purple Team
Domaines
WordPress — audit autorisé · domaine V13

WordPress — audit autorisé

Auditer une installation WordPress de laboratoire ou explicitement autorisée en combinant inventaire passif, validation manuelle, configuration et gestion des extensions. Le contrôle est ici appliqué spécifiquement à « WordPress — audit autorisé ».

En bref

  • Objectif : Auditer une installation WordPress de laboratoire ou explicitement autorisée en combinant inventaire passif, validation manuelle, configuration et gestion des extensions.
  • Méthode : progresser de l’inventaire vers une validation limitée, puis documenter la correction et le retest.
  • Sécurité : utiliser uniquement des actifs détenus ou explicitement couverts par le mandat.
Architecture du domaine WordPress — audit autorisé
Organisation du domaine « WordPress — audit autorisé » autour des contrôles et livrables essentiels.

Chapitres

Architecture WordPress et surface d’attaque

Comprendre le cœur, les extensions, les thèmes, les uploads, REST API, cron et fichiers de configuration avant de lancer un scanner.

Déployer un laboratoire WordPress isolé

Créer une instance Docker locale avec une base dédiée et des données synthétiques pour reproduire les contrôles.

Wordpresscan : usage legacy et limites

Utiliser le projet fourni uniquement pour comprendre sa logique de détection Python 2, puis privilégier WPScan pour un audit maintenu.

WPScan : inventaire passif et contrôlé

Identifier version, plugins et thèmes avec une détection passive ou mixte et un débit limité.

Validation manuelle des versions et composants

Recouper les résultats des scanners avec les fichiers publics, en-têtes, sources HTML et changelogs éditeur.

REST API, utilisateurs et exposition de données

Vérifier les routes publiques et l’exposition des auteurs sans transformer l’audit en énumération de comptes à attaquer.

Configuration, permissions et durcissement

Contrôler wp-config.php, permissions, listing, XML-RPC, debug, clés salées, HTTPS et mises à jour.

Rapport WordPress, priorisation et retest

Relier chaque composant vulnérable à son exposition, à sa preuve et à une action de mise à jour ou suppression.

Méthode de lecture

  1. Commencer par les chapitres de préparation et d’inventaire.
  2. Exécuter les commandes sur une cible de laboratoire avec une limite de débit explicite.
  3. Conserver les versions, requêtes, sorties et captures utiles.
  4. Valider manuellement les résultats avant de conclure.
  5. Terminer par la correction, le nettoyage et le retest.

Objectifs et compétences du domaine

Le domaine « WordPress — audit autorisé » regroupe les compétences nécessaires pour préparer, exécuter et restituer les contrôles associés. Il ne doit pas être lu comme une suite d’outils indépendants : les chapitres décrivent un même workflow, depuis le cadrage jusqu’au retest.

La lecture recommandée commence par les concepts et l’architecture, continue avec l’installation ou la prise en main, puis se termine par les exercices, l’interprétation et la remédiation. Dans ce domaine, la qualité dépend surtout de la requête de référence, le point d’entrée modifié, le contexte d’encodage et les différences entre réponse normale et réponse testée.

  • Expliquer les mécanismes essentiels du domaine « WordPress — audit autorisé ».
  • Préparer un laboratoire cohérent et limité au périmètre autorisé.
  • Choisir l’outil ou la technique en fonction de la question posée.
  • Conserver des preuves reproductibles et compréhensibles.
  • Transformer les constats en corrections et critères de retest.

Parcours de lecture recommandé

Le parcours ci-dessous évite de commencer directement par les commandes. Pour « WordPress — audit autorisé », il est préférable de comprendre les préconditions, d’effectuer un inventaire de base et seulement ensuite d’utiliser les outils spécialisés.

  1. Lire d’abord la définition, le périmètre et les limites du domaine.
  2. Installer ou vérifier les outils dans une VM ou un conteneur dédié.
  3. Réaliser l’exercice le plus simple avec une sortie attendue connue.
  4. Comparer les résultats avec une seconde source ou une vérification manuelle.
  5. Étudier les erreurs fréquentes avant d’augmenter la portée ou le débit.
  6. Terminer par le reporting, le nettoyage et le retest.

Points de vigilance

Les points suivants doivent rester visibles pendant toute mission portant sur « WordPress — audit autorisé ». Ils évitent les conclusions trop rapides et les actions inutiles.

  • Vigilance — tester plusieurs paramètres en même temps.
  • Vigilance — confondre erreur applicative et vulnérabilité.
  • Vigilance — laisser le scanner sortir du périmètre.
  • Vigilance — ne pas tenir compte de l’authentification ou du rôle.
  • Vigilance — documenter un payload sans expliquer pourquoi il démontre le problème.

Ce qu’un bon livrable doit contenir

Le livrable du domaine « WordPress — audit autorisé » doit permettre à une équipe technique de reproduire l’observation et à un responsable de comprendre le risque sans relire toutes les sorties d’outil.

  • le périmètre et les exclusions ;
  • les versions, comptes et configurations de test ;
  • la méthode et les paramètres réellement utilisés ;
  • les preuves brutes et leur interprétation ;
  • les limites et hypothèses ;
  • la recommandation, le responsable et le critère de retest.

Références

Chaque chapitre cite ses sources officielles et le corpus documentaire utilisé.

Aurelien Guidi CyberSecurity Specialist

Parcours conseillé

Le domaine « WordPress — audit autorisé » se lit comme un parcours. Commencez par la préparation et les limites du mandat, poursuivez par l’inventaire en lecture seule, puis utilisez les chapitres techniques uniquement pour confirmer une hypothèse précise. Les sujets suivants constituent les principaux points d’entrée :

  • Architecture WordPress et surface d’attaque
  • Déployer un laboratoire WordPress isolé
  • Wordpresscan : usage legacy et limites
  • WPScan : inventaire passif et contrôlé
  • Validation manuelle des versions et composants
  • REST API, utilisateurs et exposition de données

Les sorties brutes sont conservées avant toute reformulation. Chaque constat doit indiquer l’actif, le rôle, la version, la date, la méthode de confirmation et la correction attendue. Le retest reprend les mêmes entrées afin de vérifier la disparition du risque sans créer de régression. Dans « site », cette étape est interprétée pour le chapitre « WordPress — audit autorisé ».

Rechercher dans le guide