{"id":2693,"date":"2026-07-07T12:23:08","date_gmt":"2026-07-07T10:23:08","guid":{"rendered":"https:\/\/darioiannascoli.it\/blog\/mu-plugins-backdoor-prevention-directory-hardening-hash-verification-incident-response\/"},"modified":"2026-07-07T12:23:08","modified_gmt":"2026-07-07T10:23:08","slug":"mu-plugins-backdoor-prevention-directory-hardening-hash-verification-incident-response","status":"publish","type":"post","link":"https:\/\/darioiannascoli.it\/blog\/mu-plugins-backdoor-prevention-directory-hardening-hash-verification-incident-response\/","title":{"rendered":"Come Prevenire e Rilevare Backdoor MU-Plugins: La Mia Procedura Directory Hardening, Integrity Monitoring con Hash Verification e Incident Response per WordPress Enterprise"},"content":{"rendered":"

Nel mio lavoro di system administrator e WordPress security specialist, ho affrontato diversi incidenti legati a backdoor nascosti nella directory mu-plugins<\/strong>. In questa guida vi condivido la mia procedura completa di hardening, rilevamento e risposta agli incidenti che applico quotidianamente nei miei ambienti enterprise.<\/p>\n

Il problema \u00e8 critico:<\/strong> I must-use plugins<\/em> si caricano automaticamente e non possono essere disattivati dal pannello WordPress. Se compromessi, garantiscono persistenza garantita agli attaccanti. Nel 2026 ho visto campagne sofisticate che sfruttano esattamente questa vulnerabilit\u00e0, nascondendo payload nel database WordPress sotto opzioni come _hdra_core<\/code>.<\/p>\n

Perch\u00e9 MU-Plugins Sono il Bersaglio Preferito degli Attaccanti<\/h2>\n

La directory \/wp-content\/mu-plugins\/ \u00e8 il bersaglio di sofisticate campagne di backdoor. I MU-plugins eseguono automaticamente su ogni caricamento della pagina senza apparire nell’elenco dei plugin del pannello admin. La maggior parte degli amministratori non esamina mai la directory mu-plugins.<\/cite><\/p>\n

La mia esperienza conferma: nascondendo il codice in MU-Plugins e memorizzando i payload nel database, gli attaccanti aggiran i tipici scan di sicurezza e mantengono l’accesso anche dopo i tentativi di pulizia.<\/cite><\/p>\n

Ho osservato anche campagne multi-stage dove il backdoor \u00e8 segmentato in due parti: uno dropper di deployment nel functions.php del tema, e un backdoor completo depositato come MU-Plugin. Un altro MU-Plugin \u00e8 utilizzato per nascondere l’utente admin backdoor e per registrare l’attivit\u00e0 di accesso.<\/cite><\/p>\n

Step 1: Hardening della Directory MU-Plugins<\/h2>\n

La mia procedura inizia con il bloccaggio della directory a livello server<\/strong>. Per Apache\/LiteSpeed uso questo approccio:<\/p>\n

Creare .htaccess in \/wp-content\/mu-plugins\/:<\/strong><\/p>\n

# Disable directory listing\n<IfModule mod_autoindex.c>\n  Options -Indexes\n<\/IfModule>\n\n# Disable PHP execution in mu-plugins\n<Files *.php>\n  Deny from all\n<\/Files>\n\n# But allow ONLY legitimate MU plugin files\n<Files \"*.php\">\n  Allow from all\n<\/Files>\n\n# Restrict access to backups and temporary files\n<FilesMatch \".(bak|tmp|old|swp|sql)$\">\n  Deny from all\n<\/FilesMatch>\n<\/code><\/pre>\n
Nota:<\/strong> Nel mio scenario enterprise, ho preferito un approccio diverso: bloccare completamente la directory e caricare i MU-plugins via wp-config.php<\/code> invece che dalla directory standard.<\/p>\n
Per Nginx<\/strong>, aggiungo al blocco server:<\/p>\n
location \/wp-content\/mu-plugins\/ {\n  access_log off;\n  log_not_found off;\n  deny all;\n}\n<\/code><\/pre>\n
I permessi dei file devono essere impostati a 644 e quelli delle cartelle a 755 per garantire che i file siano scrivibili solo dall’account utente. Su server condivisi, i permessi di wp-config.php dovrebbero essere 750.<\/cite><\/p>\n
Applico questo comando da SSH:<\/p>\n
find \/var\/www\/html\/wp-content\/mu-plugins -type f -exec chmod 644 {} ;\nfind \/var\/www\/html\/wp-content\/mu-plugins -type d -exec chmod 755 {} ;\nchown -R www-data:www-data \/var\/www\/html\/wp-content\/mu-plugins\n<\/code><\/pre>\n
Step 2: File Integrity Monitoring con Hash Verification<\/h2>\n
Il monitoraggio dell’integrit\u00e0 dei file \u00e8 essenziale<\/strong> per rilevare modifiche non autorizzate. Il File Integrity Monitoring \u00e8 una tecnologia di sicurezza che aiuta a rilevare modifiche non autorizzate a file e directory su un sistema. Funziona creando una baseline di stati “noti come buoni” per i file, poi confronta continuamente o periodicamente lo stato attuale di quei file rispetto a questa baseline.<\/cite><\/p>\n
Nella mia implementazione enterprise uso SHA-256 hashing<\/strong> per una baseline di sicurezza pi\u00f9 forte di MD5.<\/p>\n
Creare lo Script di Baseline SHA-256<\/h3>\n
Creo uno script bash che generi hash dei MU-plugins e li memorizzi in un file protetto:<\/p>\n
#!\/bin\/bash\n# wp-mu-integrity-baseline.sh\n# Genera hash SHA-256 di tutti i file MU-plugins\n\nBASELINE_FILE=\"\/var\/backups\/wp-mu-baseline.txt\"\nMU_PLUGINS_DIR=\"\/var\/www\/html\/wp-content\/mu-plugins\"\n\n# Genera hash SHA-256 per ogni file\nfind \"$MU_PLUGINS_DIR\" -type f -name \"*.php\" | while read file; do\n  sha256sum \"$file\" >> \"$BASELINE_FILE\"\ndone\n\n# Proteggi il file di baseline\nchmod 600 \"$BASELINE_FILE\"\nchown root:root \"$BASELINE_FILE\"\n\necho \"Baseline generato: $BASELINE_FILE\"\n<\/code><\/pre>\n
Script di Verifica Integrit\u00e0 Automatico<\/h3>\n
Eseguo questo script ogni ora via crontab per rilevare modifiche:<\/p>\n
#!\/bin\/bash\n# wp-mu-integrity-check.sh\n# Verifica modifiche ai file MU-plugins\n\nBASELINE_FILE=\"\/var\/backups\/wp-mu-baseline.txt\"\nMU_PLUGINS_DIR=\"\/var\/www\/html\/wp-content\/mu-plugins\"\nLOG_FILE=\"\/var\/log\/wp-mu-integrity.log\"\nALERT_EMAIL=\"security@mysite.com\"\n\n# Verifica i file contro il baseline\nchanged_files=$()\n\nfind \"$MU_PLUGINS_DIR\" -type f -name \"*.php\" | while read file; do\n  current_hash=$(sha256sum \"$file\" | awk '{print $1}')\n  baseline_hash=$(grep \"$file\" \"$BASELINE_FILE\" | awk '{print $1}')\n  \n  if [ \"$current_hash\" != \"$baseline_hash\" ]; then\n    echo \"[ALERT] File modificato: $file\" >> \"$LOG_FILE\"\n    echo \"Hash atteso: $baseline_hash\" >> \"$LOG_FILE\"\n    echo \"Hash attuale: $current_hash\" >> \"$LOG_FILE\"\n    echo \"Data: $(date '+%Y-%m-%d %H:%M:%S')\" >> \"$LOG_FILE\"\n    \n    # Invia alert\n    echo \"ALERT: MU-Plugin modificato - $file\" | mail -s \"Security Alert: MU-Plugins Integrity Check Failed\" \"$ALERT_EMAIL\"\n  fi\ndone\n\n# Cerifica anche nuovi file non autorizzati\nfind \"$MU_PLUGINS_DIR\" -type f -name \"*.php\" | while read file; do\n  if ! grep -q \"$file\" \"$BASELINE_FILE\"; then\n    echo \"[CRITICAL] Nuovo file non autorizzato: $file\" >> \"$LOG_FILE\"\n    echo \"Data: $(date '+%Y-%m-%d %H:%M:%S')\" >> \"$LOG_FILE\"\n    echo \"CRITICAL: Nuovo file MU-Plugin non autorizzato - $file\" | mail -s \"SECURITY INCIDENT: Unauthorized MU-Plugin File\" \"$ALERT_EMAIL\"\n  fi\ndone\n<\/code><\/pre>\n
Aggiungo a crontab:<\/strong><\/p>\n
0 * * * * \/usr\/local\/bin\/wp-mu-integrity-check.sh\n<\/code><\/pre>\n
Sistemi di monitoraggio moderni come l’84EM File Integrity Checker forniscono monitoraggio automatico della sicurezza verificando i checksum SHA-256 di ogni file in un’installazione WordPress. Il plugin esegue scansioni pianificate in background, rileva modifiche non autorizzate e fornisce notifiche immediate.<\/cite><\/p>\n
Step 3: Monitoraggio delle Opzioni del Database<\/h2>\n
Ho scoperto che molti backdoor MU-plugins memorizzano payload nel database WordPress<\/strong> per aggirare i controlli del filesystem. La mia procedura include il monitoraggio delle opzioni sospette.<\/p>\n
Script di Verifica Database per Backdoor<\/h3>\n
Creo uno script PHP che verifica le opzioni WordPress per segni di compromissione:<\/p>\n
<?php\n\/\/ wp-mu-db-integrity-check.php\n\/\/ Cerca backdoor memorizzati nel database\n\nglobal $wpdb;\n\n\/\/ Opzioni sospette associate a backdoor noti\n$suspicious_options = array(\n  '_hdra_core',         \/\/ Backdoor MU-plugin 2025-2026\n  'wpos_analytics',     \/\/ Essential Plugin attack\n  '_transient_update',  \/\/ Payload storage\n  'siteurl_backup',     \/\/ Backup nascosto di opzioni critiche\n  'home_backup',\n  '_cronjob_queue',     \/\/ Task queue nascosta\n);\n\n$wpdb->show_errors();\n\nforeach ( $suspicious_options as $option ) {\n  $value = $wpdb->get_var( $wpdb->prepare(\n    \"SELECT option_value FROM $wpdb->options WHERE option_name = %s\",\n    $option\n  ) );\n  \n  if ( ! empty( $value ) ) {\n    \/\/ Verifica se contiene base64 o serialized PHP objects (indizio di backdoor)\n    if ( preg_match( '\/^[A-Za-z0-9+\/=]+$\/m', $value ) || is_serialized( $value ) ) {\n      error_log( \"[SECURITY ALERT] Suspicious option detected: $option\" );\n      error_log( \"Value: \" . substr( $value, 0, 200 ) );\n      \n      \/\/ Invia notifica\n      wp_mail(\n        get_option( 'admin_email' ),\n        '[SECURITY] Suspicious Database Option Detected',\n        \"Option: $optionnValue excerpt: \" . substr( $value, 0, 500 )\n      );\n    }\n  }\n}\n\n\/\/ Verifica anche wp_posts per iframe nascosti o redirect\n$suspicious_posts = $wpdb->get_results(\n  \"SELECT ID, post_content FROM $wpdb->posts \n   WHERE post_content LIKE '%eval(%' \n   OR post_content LIKE '%base64_decode%'\n   OR post_content LIKE '%system(%'\n   LIMIT 50\"\n);\n\nif ( ! empty( $suspicious_posts ) ) {\n  error_log( '[CRITICAL] Suspicious code detected in posts: ' . count( $suspicious_posts ) );\n}\n?>\n<\/code><\/pre>\n
Il backdoor memorizza il payload nella tabella delle opzioni WordPress sotto la chiave “_hdra_core”, aggirando efficacemente gli scan di sicurezza basati su filesystem che si concentrano principalmente su modifiche ai file.<\/cite><\/p>\n
Step 4: Monitoraggio e Auditing dei wp-cron<\/h2>\n
Ho notato che i backdoor MU-plugins creano wp-cron jobs nascosti<\/strong> che si ripristinano automaticamente se rimossi. La mia procedura include il monitoraggio dei cron jobs:<\/p>\n
<?php\n\/\/ wp-cron-monitor.php\n\/\/ Monitora wp-cron per task sospetti\n\nglobal $wpdb;\n\n\/\/ Ottieni tutti i scheduled events\n$crons = _get_cron_array();\n\nforeach ( $crons as $timestamp => $cron ) {\n  foreach ( $cron as $hook => $hook_data ) {\n    \/\/ Flag su hook sospetti\n    if ( strpos( $hook, 'hdra' ) !== false ||\n         strpos( $hook, 'malware' ) !== false ||\n         strpos( $hook, 'backdoor' ) !== false ||\n         strpos( $hook, 'persist' ) !== false ||\n         strpos( $hook, 'restore' ) !== false ) {\n      \n      error_log( \"[CRITICAL] Suspicious cron job: $hook at timestamp $timestamp\" );\n      wp_unschedule_hook( $hook );\n    }\n  }\n}\n?>\n<\/code><\/pre>\n
Step 5: Incident Response Playbook per MU-Plugin Backdoor<\/h2>\n
Se scopro un backdoor MU-plugin, eseguo questa procedura in sequenza e senza fretta<\/strong>:<\/p>\n
Fase 1: Detection e Isolamento (0-15 minuti)<\/h3>\n
    \n
  1. Isola il sito:<\/strong> Metto il sito in manutenzione con una pagina statica. Non uso plugin per questo passo, poich\u00e9 potrebbero essere compromessi.<\/li>\n
  2. Blocca tutti gli admin tranne me:<\/strong> Cambio temporaneamente il database password nel wp-config.php cos\u00ec solo il mio utente pu\u00f2 accedere.<\/li>\n
  3. Raccolgo prove:<\/strong> Backup immediato della directory wp-content\/mu-plugins e di wp-config.php per analisi forense.<\/li>\n<\/ol>\n
    Fase 2: Triage e Analisi (15-45 minuti)<\/h3>\n
    Un file integrity monitor confronta la firma digitale di ogni file sul sito con una firma precedentemente salvata, rendendo facile individuare file modificati o aggiunti. Questo \u00e8 molto utile in un ambiente WordPress.<\/cite><\/p>\n
    Applico:<\/p>\n
    # Elenca tutti i file nella directory mu-plugins con hash\nfind \/var\/www\/html\/wp-content\/mu-plugins -type f -exec ls -lh {} ; | awk '{print $9, $5, $6, $7, $8}'\n\n# Confronta i file contro il baseline noto\nsha256sum \/var\/www\/html\/wp-content\/mu-plugins\/*.php > \/tmp\/current-hash.txt\ndiff \/var\/backups\/wp-mu-baseline.txt \/tmp\/current-hash.txt\n<\/code><\/pre>\n
    Esamino manualmente il codice di ogni file PHP cercando segni di backdoor:<\/p>\n
    # Cerca base64_decode, eval, system, exec\ngrep -r \"base64_decode|\\x\" \/var\/www\/html\/wp-content\/mu-plugins\/ --include=\"*.php\"\ngrep -r \"eval|(|exec|(|system|(\" \/var\/www\/html\/wp-content\/mu-plugins\/ --include=\"*.php\"\n<\/code><\/pre>\n
    Fase 3: Eradication (45-90 minuti)<\/h3>\n
    L’eradicazione rimuove completamente la minaccia. Questo include la pulizia del malware, la chiusura dei buchi di sicurezza e l’aggiornamento dei componenti vulnerabili.<\/cite><\/p>\n
    Nel mio caso:<\/p>\n
      \n
    1. Rimuovo i file compromessi:<\/strong> Cancello SOLO i file MU-plugin legittimi, poi li reinstallo da backup pulito o da zero.<\/li>\n
    2. Pulisco il database:<\/strong> Cancello le opzioni sospette e i wp-cron non autorizzati:<\/li>\n<\/ol>\n
      <?php\n\/\/ Pulire il database da backdoor\nglobal $wpdb;\n\n\/\/ Elimina opzioni sospette\n$wpdb->query( \n  \"DELETE FROM $wpdb->options WHERE option_name LIKE '%hdra%' OR option_name LIKE '%backdoor%'\"\n);\n\n\/\/ Verifica la password dell'admin\n$admin = get_user_by( 'login', 'admin' );\nif ( $admin ) {\n  \/\/ Se la password \u00e8 stata cambiata di recente da attaccanti, resettala\n  wp_set_password( 'TemporaryPassword123!@#', $admin->ID );\n  error_log( 'Admin password reset' );\n}\n\n\/\/ Cancella tutti gli utenti creati nelle ultime 24 ore (a parte te)\n$recent_users = $wpdb->get_results(\n  \"SELECT ID FROM $wpdb->users WHERE user_registered > DATE_SUB(NOW(), INTERVAL 1 DAY) \n   AND user_login != 'your-username'\"\n);\n\nforeach ( $recent_users as $user ) {\n  wp_delete_user( $user->ID, 1 );\n}\n?>\n<\/code><\/pre>\n
        \n
      1. Rigenero le chiavi di sicurezza WordPress:<\/strong> Cambio tutti i salti in wp-config.php.<\/li>\n
      2. Forzo il logout di tutti gli utenti:<\/strong> Invalido tutte le sessioni attive.<\/li>\n<\/ol>\n
        <?php\n\/\/ Invalida tutte le sessioni WordPress\nglobal $wpdb;\n$wpdb->query( \"TRUNCATE TABLE $wpdb->usermeta WHERE meta_key = '_session_tokens'\" );\n?>\n<\/code><\/pre>\n
        Fase 4: Recovery e Verifica (90-120 minuti)<\/h3>\n
        Il recovery ripristina le operazioni normali da backup puliti o sistemi ricostruiti.<\/cite><\/p>\n
          \n
        1. Ripristino il sito da backup pulito:<\/strong> Uso backup da prima dell’infezione.<\/li>\n
        2. Aggiorno WordPress, tema e plugin:<\/strong> Applico tutti gli aggiornamenti di sicurezza.<\/li>\n
        3. Eseguo scansioni di verifica:<\/strong> Eseguo Wordfence con sensibilit\u00e0 massima per rilevare backdoor rimanenti.<\/li>\n
        4. Rigenero il baseline di integrit\u00e0 file:<\/strong> Creo un nuovo file di baseline SHA-256 post-pulizia.<\/li>\n<\/ol>\n
          Step 6: Prevenzione Continuativa<\/h2>\n
          Monitoraggio Continuativo<\/h3>\n
          Nel mio setup enterprise implemento:<\/p>\n