Il malware non arriva dall'hosting (quasi sempre): dove guardare davvero

Il sito si reinfetta, il titolare cambia hosting, e due mesi dopo il problema è di nuovo lì. Lo abbiamo visto decine di volte. Il cambio di hosting è la versione informatica del cambiare auto quando il problema era la patente.

Perché succede? Perché il malware non sceglie l'hosting: sceglie la vulnerabilità. E le vulnerabilità che vediamo sfruttare ogni settimana viaggiano con il sito, non con il server.

Da dove entra davvero il malware: le evidenze

Nei log di accesso di una compromissione tipica trovi, in ordine di frequenza:

1. POST ripetuti su endpoint di plugin vulnerabili, spesso settimane prima che qualcuno se ne accorga. CVE pubblicate con exploit pubblici vengono scansionate in massa entro ore dalla divulgazione.
2. Brute force o credential stuffing su xmlrpc.php e wp-login.php: migliaia di tentativi con credenziali rubate altrove (altro servizio, altro data breach).
3. Attività da account legittimi: l'attaccante è già entrato con una password valida comprata o rubata. Nei log sembra un amministratore che lavora di notte.
4. Upload di file PHP tramite form o uploader mal configurati.

Nessuna di queste quattro vie dipende dal server. Un hosting impeccabile non può impedirti di installare un plugin nulled né forzare un aggiornamento che rimandi da otto mesi.

Quando invece l'hosting è davvero il problema

Esistono casi in cui la responsabilità del provider è concreta. Sono meno frequenti, ma vanno riconosciuti:

Scenario	Segnale distintivo	Cosa richiedere
Isolamento insufficiente su shared	Altri siti sullo stesso server infetti con lo stesso malware, ingresso fuori da wp-content	Migrazione o piano isolato
Versioni PHP/EOL o pannelli obsoleti	Vulnerabilità note del pannello (cPanel/Plesk) nei log	Aggiornamento documentato o cambio provider
Backup corrotti o mancanti	Ripristini falliti, dump troncati, "Dump completed" assente	Verifica contrattuale dei backup
Configurazione server errata	Directory listing attivo, permessi globali aperti, error_reporting esposto	Ticket con richiesta scritta di correzione
Compromissione lato infrastruttura	File infetti fuori dallo spazio utente, cron di sistema manipolati	Escalation formale al provider

Nota il criterio pratico: se l'intrusione passa da wp-content e da wp-login, la responsabilità è applicativa; se passa dal sistema sotto lo spazio del sito, la discussione con l'hosting è legittima. Ma questa distinzione si dimostra solo con i log, non con la sensazione.

Come attribuire l'ingresso: il metodo in tre passaggi

Prima di accusare chiunque, serve una diagnosi. Tre fonti di evidenza bastano nella maggior parte dei casi.

1. Timestamp dei file infetti

La data di modifica dei primi file malevoli stabilisce il terminus ante quem della compromissione. Attenzione: gli attaccanti falsificano i timestamp, quindi usa questo dato insieme agli altri, mai da solo.

grep " POST " access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -30