Backdoor: cos’è, come funziona, come riconoscerla e come difendersi

Una backdoor è un metodo nascosto o non documentato che permette di accedere a un sistema, un’applicazione o un dispositivo aggirando il normale percorso di autenticazione o altri controlli di sicurezza. In alcuni contesti può essere stata prevista intenzionalmente per manutenzione o assistenza; in altri viene installata da un attaccante dopo una compromissione per poter rientrare nel sistema senza ripetere ogni volta l’attacco iniziale.

La distinzione più importante è questa: backdoor non significa automaticamente virus, Trojan o malware. Il termine descrive soprattutto una via di accesso o un meccanismo di bypass. Un Trojan può installare una backdoor, una web shell può funzionare da backdoor su un server e un rootkit può contribuire a nasconderne la presenza, ma sono concetti differenti.

Il NIST definisce una backdoor come un modo non documentato per ottenere accesso a un sistema informatico; nello stesso glossario compare anche una definizione più specifica, legata a programmi malevoli che restano in ascolto di comandi. Questa pluralità di definizioni è utile: impedisce di ridurre il concetto a una sola famiglia di malware.

Capire come funziona una backdoor serve soprattutto a rispondere a tre domande pratiche: come è comparsa, cosa permette di fare e cosa bisogna eliminare per essere ragionevolmente certi che l’accesso non sia ancora disponibile.

Backdoor: cos’è e cosa significa in informatica

La traduzione letterale di back door è “porta sul retro” o “porta di servizio”. L’immagine funziona bene perché descrive un accesso diverso da quello previsto per gli utenti normali.

In un sistema correttamente progettato, l’accesso passa attraverso meccanismi noti: autenticazione, autorizzazione, controllo dei privilegi, logging e altre misure di sicurezza. Una backdoor crea o sfrutta invece un percorso alternativo che consente di bypassare una parte di questi controlli.

Il glossario del Sistema di informazione per la sicurezza della Repubblica descrive il concetto come un sistema, spesso nascosto, utilizzato per aggirare la normale procedura di autenticazione e ottenere accesso a un sistema informatico.

Un accesso nascosto che aggira il percorso normale

Una backdoor può assumere forme molto diverse. Può essere codice inserito in un programma, un account non documentato, un servizio di amministrazione lasciato accessibile, una web shell caricata su un server o un componente malevolo che riceve comandi da remoto.

Quello che accomuna questi casi non è il formato tecnico, ma la funzione: consentire un accesso che il normale modello di sicurezza non dovrebbe permettere o che l’utente non conosce.

Questo spiega perché cercare “il file della backdoor” non è sempre sufficiente. In alcuni incidenti il meccanismo di persistenza è un file; in altri può essere un account, una modifica alla configurazione, un task pianificato, un servizio, un componente del server o più elementi coordinati.

Perché una backdoor non è necessariamente un virus o un Trojan

Nel linguaggio comune vengono usate espressioni come “virus backdoor” o “Trojan backdoor”. Sono query comprensibili, ma tecnicamente possono confondere categorie differenti.

Un Trojan horse è un programma che appare utile o legittimo ma contiene una funzione nascosta potenzialmente malevola. Il NIST descrive il Trojan horse proprio in termini di funzione apparente e funzione nascosta. Un Trojan può quindi essere il mezzo con cui una backdoor viene installata o attivata.

Un virus, invece, è definito soprattutto dalla capacità di replicarsi infettando altri file o programmi. Una backdoor non ha bisogno di replicarsi per essere una backdoor.

Per questo la relazione corretta non è:

backdoor = Trojan = virus

ma, più spesso:

compromissione o software malevolo → installazione/attivazione di una backdoor → accesso successivo dell’attaccante

Backdoor intenzionali, dimenticate e installate da un attaccante

Non tutte le backdoor nascono nello stesso modo.

Una funzione di accesso può essere stata inserita intenzionalmente durante sviluppo, assistenza o manutenzione e diventare pericolosa se rimane attiva, non documentata o protetta in modo inadeguato. In altri casi l’accesso viene creato direttamente dall’attaccante dopo aver sfruttato una vulnerabilità o rubato credenziali.

Dal punto di vista della sicurezza, però, la domanda decisiva è meno filosofica: chi può utilizzare quell’accesso, con quali privilegi, quanto è visibile e può essere revocato in modo affidabile?

Se un meccanismo consente di aggirare i controlli previsti ed è sfruttabile da soggetti non autorizzati, il rischio esiste indipendentemente dal motivo per cui era stato creato.

Come funziona una backdoor

Il funzionamento concreto cambia in base alla piattaforma, ma la logica generale è abbastanza stabile.

Prima esiste o viene ottenuto un punto d’ingresso. Poi l’attaccante cerca di trasformare quell’accesso temporaneo in qualcosa di più comodo e resistente. Una backdoor può servire proprio a questo: ridurre la necessità di sfruttare di nuovo la vulnerabilità iniziale o ripetere il furto di credenziali.

Bypass dell’autenticazione e dei normali controlli di sicurezza

Il caso più intuitivo è il bypass dell’autenticazione. Invece di passare dal login previsto, l’accesso avviene attraverso un account nascosto, una credenziale incorporata nel software, un endpoint non documentato o un altro percorso.

Ma il bypass non riguarda soltanto username e password. Può coinvolgere controlli applicativi, autorizzazioni, componenti server, firmware o funzionalità amministrative.

Per questo rafforzare il login è importante, ma non basta a neutralizzare una backdoor già presente. L’autenticazione a due fattori riduce molti rischi legati al furto di credenziali e agli accessi abusivi, ma non può correggere da sola un canale alternativo che salta completamente quel processo.

Accesso remoto, privilegi e persistenza

Una backdoor è particolarmente utile a un attaccante quando consente di tornare sul sistema dopo la compromissione iniziale.

Qui entra il concetto di persistenza. In MITRE ATT&CK, per esempio, le web shell sono classificate tra le tecniche che possono essere utilizzate per mantenere l’accesso a un server. Non significa che qualunque backdoor debba essere persistente per definizione, ma la persistenza è uno dei suoi impieghi più importanti in un attacco reale.

Una volta ottenuto l’accesso, ciò che l’attaccante può fare dipende dai privilegi associati al meccanismo. Una backdoor con permessi limitati ha un impatto diverso da una che consente di eseguire comandi come amministratore o di accedere a dati sensibili.

Quando entra in gioco il command and control

Alcune backdoor sono progettate per comunicare con un’infrastruttura di command and control (C2). Il sistema compromesso può ricevere istruzioni, inviare informazioni o mantenere una comunicazione con l’attaccante.

Non bisogna però immaginare sempre un malware che resta in ascolto sulla stessa porta di rete. Le implementazioni possono utilizzare protocolli e canali già ammessi dall’ambiente, comunicazioni in uscita o infrastrutture intermedie.

Per il difensore, il punto è importante: cercare una singola porta “tipica delle backdoor” è un controllo troppo debole. La detection deve combinare processi, file, account, modifiche di sistema e comportamento di rete.

Come può essere introdotta una backdoor in un sistema

Una backdoor può comparire prima della distribuzione di un prodotto oppure dopo che il sistema è già operativo. Separare questi scenari aiuta a evitare una semplificazione frequente: pensare che l’unico percorso sia “scarico un virus e mi installa una backdoor”.

Trojan, installer falsi e software compromesso

Un programma apparentemente legittimo può contenere codice nascosto che apre un accesso remoto o installa altri componenti.

È uno dei casi in cui il termine Trojan è appropriato: l’utente esegue qualcosa che sembra avere uno scopo normale, ma il software svolge anche una funzione non dichiarata.

La difesa non si riduce quindi all’antivirus. Contano la provenienza del software, la verifica degli aggiornamenti, la gestione dei privilegi e la capacità di rilevare comportamenti anomali dopo l’esecuzione.

Vulnerabilità sfruttate e sistemi già compromessi

Un attaccante può prima ottenere l’accesso sfruttando una vulnerabilità e soltanto dopo installare un meccanismo che gli permetta di rientrare.

Questa distinzione è essenziale:

la vulnerabilità o l’exploit possono essere il punto d’ingresso; la backdoor può essere ciò che rimane dopo.

In un’applicazione web, per esempio, una vulnerabilità potrebbe consentire l’esecuzione di codice sul server. Se l’attaccante riesce poi a depositare una web shell, la compromissione iniziale si trasforma in un accesso più stabile.

Lo stesso principio spiega perché correggere la vulnerabilità senza cercare la persistenza già installata può essere insufficiente.

Software, firmware e supply chain

Il meccanismo può trovarsi anche in componenti più profondi rispetto a una normale applicazione: firmware, dispositivi di rete, librerie, aggiornamenti o dipendenze.

Qui la remediation può diventare più complessa, perché reinstallare un singolo programma non garantisce che il punto di accesso sia stato eliminato.

Per organizzazioni e sistemi critici, questo sposta parte della sicurezza verso la fiducia nella supply chain, la provenienza degli aggiornamenti, la verifica dell’integrità e la possibilità concreta di sostituire o ripristinare un componente compromesso.

Funzioni di manutenzione o accessi nascosti lasciati nel prodotto

Un accesso creato per debug, supporto o recupero può diventare un rischio se sopravvive alla fase in cui era necessario oppure se viene protetto da credenziali condivise, statiche o facilmente recuperabili.

Una funzione “nata per aiutare” non diventa automaticamente innocua. Se aggira il normale modello di autorizzazione, deve essere trattata come una superficie di rischio e governata di conseguenza.

Tipi di backdoor: software, web, firmware e accessi nascosti

Non esiste una sola forma tecnica di backdoor. Per il lettore è più utile classificare i casi in base a dove vive il meccanismo di accesso e a cosa permette di fare.

Malware backdoor

In questo scenario un programma malevolo crea deliberatamente un canale di accesso o controllo remoto.

Può ricevere comandi, scaricare altri payload, trasferire dati o eseguire operazioni sul sistema compromesso. È il caso più vicino all’idea comune di “backdoor malware”.

Il rischio principale è che la prima infezione non rappresenti la fine dell’incidente: il componente può servire proprio a conservare un accesso utilizzabile in seguito.

Web shell e backdoor sui server web

Una web shell è uno script o componente collocato su un server web per consentire l’esecuzione di operazioni da remoto. MITRE ATT&CK dedica a questa tecnica la voce T1505.003 Web Shell e descrive il suo utilizzo per mantenere accesso persistente ai server.

Per un sito web compromesso è uno scenario particolarmente rilevante. Il front-end può sembrare normale mentre sul server rimane un file o un componente che permette all’attaccante di rientrare.

La conseguenza pratica è importante: ripristinare la homepage o eliminare il codice visibilmente malevolo non equivale necessariamente a bonificare il server.

Backdoor in firmware e dispositivi

Router, appliance, dispositivi embedded e altri sistemi possono contenere meccanismi di accesso nel firmware o nei componenti di gestione.

In questi casi l’utente può avere meno strumenti per verificare cosa stia realmente eseguendo il dispositivo. Aggiornamenti firmware firmati, supporto del produttore, inventario dei dispositivi e procedure di sostituzione diventano parte della difesa.

Account, servizi e configurazioni usati come accesso persistente

Una backdoor non deve per forza essere un “programma”. Un account amministrativo inatteso, una chiave di accesso non autorizzata, un servizio alterato o una configurazione costruita per garantire il rientro possono svolgere una funzione equivalente.

Questo è uno dei motivi per cui una scansione antimalware, da sola, non chiude sempre l’incidente.

Backdoor, Trojan, RAT, rootkit, web shell ed exploit: quali sono le differenze

Questi termini vengono spesso sovrapposti, ma descrivono cose differenti. Capire la relazione fra loro evita diagnosi sbagliate.

Concetto	Che cos’è	Funzione principale	È una backdoor?
Backdoor	Metodo o meccanismo di accesso alternativo/nascosto	Aggirare controlli e consentire accesso	È il concetto di riferimento
Trojan	Software che appare legittimo o utile ma contiene una funzione nascosta malevola	Indurre l’esecuzione e svolgere funzioni non dichiarate	Può installare o contenere una backdoor
RAT	Software di amministrazione o controllo remoto	Gestire un sistema a distanza	Può essere legittimo oppure usato come componente di accesso malevolo
Rootkit	Insieme di strumenti o modifiche finalizzati soprattutto a occultare attività e mantenere accesso privilegiato	Stealth e persistenza	Può supportare una backdoor, ma non è sinonimo
Web shell	Script/componente lato server accessibile via web	Eseguire operazioni sul server da remoto	Spesso svolge funzione di backdoor
Exploit	Tecnica o codice che sfrutta una vulnerabilità	Ottenere un comportamento o accesso non previsto	Può aprire la strada alla backdoor, ma non coincide con essa

Il NIST definisce un rootkit come un insieme di strumenti che può consentire di nascondere le attività dell’attaccante e mantenere accesso privilegiato. È quindi vicino alla backdoor sul piano della persistenza, ma il suo tratto distintivo è anche l’occultamento.

Un exploit, invece, riguarda lo sfruttamento di una vulnerabilità. Se la falla viene corretta dopo l’attacco, una backdoor già installata può continuare a esistere. Questa è una delle differenze operative più importanti dell’intero argomento.

Cosa può fare un attaccante attraverso una backdoor

La presenza di una backdoor non determina automaticamente un unico tipo di danno. L’impatto dipende dai privilegi disponibili, dalla posizione del sistema nella rete e dalle funzionalità del meccanismo.

Eseguire azioni con i privilegi ottenuti

Se l’accesso consente esecuzione di comandi, l’attaccante può operare entro i privilegi del processo o dell’account compromesso.

Con privilegi elevati il rischio cresce: diventa più facile modificare configurazioni, creare altri account, accedere a dati protetti o installare ulteriori componenti.

Rubare dati e credenziali

Una backdoor può essere utilizzata per accedere a file, database, credenziali o informazioni presenti sul dispositivo.

Il furto non deve essere necessariamente immediato. Un accesso persistente può permettere all’attaccante di osservare il sistema nel tempo e scegliere quando esfiltrare dati o ampliare la compromissione.

Installare altri malware o ransomware

Una volta ottenuto un canale affidabile, l’attaccante può usarlo come punto di distribuzione per altri strumenti malevoli.

Per questo, durante la risposta a un incidente, non basta classificare il primo artefatto trovato. È necessario ricostruire quali altri cambiamenti sono avvenuti dopo l’accesso iniziale.

Muoversi verso altri sistemi o usare il dispositivo in una botnet

Un host compromesso può diventare un punto di partenza verso altre risorse della rete, soprattutto se possiede credenziali, trust o connettività utili.

In altri scenari il dispositivo può essere arruolato in una rete controllata da terzi. Questo non significa che tutte le backdoor creino una botnet, ma il controllo remoto persistente può essere uno degli elementi che rende possibile quel tipo di abuso.

Come riconoscere una possibile backdoor

Non esiste un singolo sintomo che dimostri da solo la presenza di una backdoor. La detection è più affidabile quando combina segnali diversi e li confronta con una baseline del sistema.

Processi, file, servizi e account inattesi

Fra i segnali da verificare ci sono:

• nuovi file in directory sensibili o in percorsi dell’applicazione;
• processi non riconosciuti o avviati da processi che normalmente non dovrebbero generare shell o interpreti;
• account amministrativi inattesi;
• servizi, task o meccanismi di avvio modificati;
• file che ricompaiono dopo essere stati rimossi;
• modifiche non spiegate a configurazioni e permessi.

Per le web shell, la strategia di detection MITRE ATT&CK considera particolarmente interessante la relazione tra creazione di file nelle directory web e successiva esecuzione di comandi da parte del processo del web server.

Connessioni e traffico di rete anomali

Connessioni verso destinazioni insolite, traffico periodico non spiegato, comunicazioni fuori dagli orari o dai pattern normali e richieste anomale verso endpoint web possono contribuire all’indagine.

Il criterio, però, deve essere comportamentale. Molti sistemi legittimi comunicano con servizi esterni e una singola connessione non è una prova.

Serve correlare rete, host, identità e applicazione.

Modifiche che ricompaiono dopo una pulizia

Un segnale particolarmente sospetto è la ricomparsa dello stesso problema dopo una bonifica apparentemente riuscita.

Se elimini un file compromesso e poco dopo ricompare, le possibilità includono una vulnerabilità ancora sfruttabile, credenziali ancora compromesse o un altro meccanismo di persistenza rimasto nel sistema.

È proprio il tipo di scenario in cui conviene passare dalla semplice “rimozione del malware” alla ricostruzione completa della catena dell’incidente.

Perché un singolo indicatore non dimostra da solo la presenza di una backdoor

Un processo sconosciuto può essere legittimo. Un file modificato può dipendere da un aggiornamento. Una connessione remota può appartenere a un servizio cloud autorizzato.

La diagnosi migliore cerca convergenza di indicatori: cosa è cambiato, quando, da quale processo, con quale identità, verso quale destinazione e dopo quale evento iniziale.

In sicurezza, un falso positivo può far perdere tempo; un falso senso di certezza può lasciare aperto il vero punto d’ingresso.

Come rilevare e rimuovere una backdoor in sicurezza

Quando esiste un sospetto credibile, la priorità non è cancellare il primo file strano che trovi. È capire il perimetro della compromissione e impedire che la pulizia distrugga informazioni utili o lasci attivo un secondo accesso.

Le raccomandazioni di NIST SP 800-61 Rev. 3 trattano la risposta agli incidenti come parte della gestione complessiva del rischio e, nella fase di eradicazione, richiamano esplicitamente la necessità di eliminare meccanismi di persistenza e punti d’ingresso, oltre a correggere le vulnerabilità sfruttate.

Prima contenere il sistema e conservare le informazioni utili

Se il sistema è ancora sotto controllo dell’attaccante, il contenimento serve a ridurre il rischio di ulteriori danni mentre si prepara la remediation.

La scelta concreta dipende dal contesto: disconnettere brutalmente un server critico può avere conseguenze operative o distruggere parte dell’evidenza volatile. Nei casi aziendali importanti è preferibile che la decisione sia coordinata con chi gestisce incident response, infrastruttura e continuità operativa.

Individuare accesso, persistenza e causa originaria

La domanda da chiudere non è soltanto “qual è il file malevolo?”, ma:

come è entrato l’attaccante → cosa ha modificato → come può rientrare → quali sistemi e identità sono coinvolti

Se manca uno di questi passaggi, la pulizia può essere incompleta.

Revocare credenziali e accessi compromessi

Password, token, chiavi, sessioni e account devono essere valutati in base al perimetro dell’incidente.

Cambiare una password può essere inutile se l’attaccante possiede già un altro account amministrativo o una chiave persistente. Allo stesso modo, attivare 2FA dopo l’incidente è utile per rafforzare gli accessi legittimi, ma non elimina un bypass già installato.

Ripristinare o ricostruire da una base affidabile

Quando l’integrità del sistema non può essere stabilita con sufficiente fiducia, ricostruire da una base nota e affidabile può essere più sicuro che inseguire ogni singola modifica.

NIST include fra le azioni di recovery il ripristino da backup puliti, la ricostruzione dei sistemi, la sostituzione dei file compromessi, l’installazione delle patch e il cambio delle credenziali.

Il backup, quindi, è fondamentale per il recovery ma deve essere realmente pulito. Ripristinare una copia che contiene già la compromissione riporta online anche il problema.

Perché eliminare soltanto il file sospetto può non bastare

Una backdoor visibile potrebbe essere solo uno dei meccanismi installati.

Un attaccante può creare accessi ridondanti: più file, account, chiavi o modifiche. Inoltre il punto d’ingresso originario potrebbe essere ancora presente.

Per questo la chiusura dell’incidente dovrebbe richiedere almeno quattro verifiche:

1. persistenza rimossa;
2. vulnerabilità o causa iniziale corretta;
3. credenziali e accessi compromessi revocati;
4. monitoraggio post-ripristino senza nuovi indicatori coerenti con la compromissione.

Backdoor nei siti web e WordPress: il caso delle web shell

Su WordPress il problema è particolarmente concreto perché un attaccante che ottiene la possibilità di scrivere o modificare file PHP sul server può tentare di mantenere l’accesso anche dopo la vulnerabilità iniziale.

MITRE descrive le web shell come script collocati su server web per consentire accesso e operazioni da remoto. Su un sito WordPress questo può tradursi in file nascosti o camuffati nel core, nei plugin, nei temi, negli upload o in altre directory scrivibili.

Come una web shell mantiene l’accesso a un server compromesso

Il meccanismo di base è semplice da capire anche senza entrare nel codice offensivo: il server esegue un componente che l’attaccante riesce a richiamare da remoto e che gli consente di svolgere operazioni non autorizzate.

Il problema è che una web shell può assomigliare a un normale file dell’applicazione oppure essere inserita in codice legittimo modificato.

Per questo controllare soltanto il nome dei file è insufficiente. Servono integrità, confronto con versioni pulite, log, comportamento dei processi e conoscenza di cosa dovrebbe realmente essere presente sul server.

File, database, utenti e task possono diventare meccanismi di persistenza

In WordPress l’attenzione va oltre i file PHP.

Un incidente può coinvolgere utenti amministrativi, credenziali FTP/SFTP o hosting, chiavi, database, task pianificati, plugin modificati, file di configurazione e altri componenti dell’ambiente.

È il motivo per cui la nostra guida su WordPress hackerato e ripristino di un sito compromesso tratta la bonifica come un processo più ampio della semplice cancellazione del malware.

Perché un sito può essere compromesso di nuovo dopo una bonifica incompleta

Se il sito viene “pulito” ma non viene chiusa la vulnerabilità o revocato l’accesso usato dall’attaccante, la reinfezione non è sorprendente: il percorso è ancora disponibile.

Lo stesso vale se resta una seconda backdoor non individuata.

Per la prevenzione conviene quindi ragionare per livelli: aggiornamenti, gestione dei privilegi, autenticazione, monitoraggio, backup e protezione applicativa. La guida alla sicurezza WordPress affronta l’intero modello, mentre un Web Application Firewall può ridurre alcune categorie di richieste malevole ma non garantisce la rimozione di una backdoor già presente sul server.

Come prevenire backdoor e accessi persistenti

La prevenzione migliore non consiste in un singolo prodotto. Riduce le occasioni di ingresso, limita i privilegi disponibili e aumenta la probabilità di accorgersi rapidamente di una modifica non autorizzata.

Aggiornamenti, vulnerabilità e software proveniente da fonti affidabili

Core, applicazioni, plugin, dipendenze, sistemi operativi e firmware devono essere mantenuti entro versioni supportate e corretti quando emergono vulnerabilità rilevanti.

Gli aggiornamenti non impediscono qualsiasi backdoor, ma riducono una classe importante di ingressi: quelli che partono da vulnerabilità già note e correggibili.

Anche la provenienza conta. Software pirata, pacchetti modificati, repository non affidabili e aggiornamenti non verificati ampliano la superficie di rischio.

Privilegi minimi, password uniche e autenticazione a più fattori

Il principio del minimo privilegio limita ciò che un account o processo compromesso può fare.

Password uniche e robuste riducono il riuso di credenziali rubate; la 2FA aggiunge un ulteriore ostacolo agli accessi basati sulle sole password.

Sono difese importanti contro l’accesso iniziale, ma è bene mantenere il confine concettuale: una backdoor che bypassa il normale login può rendere irrilevante quel controllo specifico. Ecco perché access security e integrity monitoring devono lavorare insieme.

Gli attacchi di brute force sono un buon esempio della differenza: colpiscono il percorso di autenticazione tentando credenziali; una backdoor può invece evitare quel percorso.

Monitoraggio di file, account, processi e traffico

La capacità di individuare variazioni rispetto alla baseline è essenziale.

Per un server significa sapere quali file e servizi dovrebbero esistere, quali processi sono normali, quali account hanno privilegi e quali destinazioni di rete sono previste.

Per un sito WordPress significa anche controllare modifiche ai file, nuovi amministratori, plugin inattesi, anomalie nei log e cambiamenti che non coincidono con attività di manutenzione note.

EDR, antimalware e WAF: cosa possono fare e cosa non possono fare

Gli strumenti di endpoint detection and response e gli antimalware possono rilevare file, processi e comportamenti sospetti. Un WAF può bloccare molte richieste malevole dirette a un’applicazione web.

Sono strati utili, non garanzie assolute.

Un WAF non ripulisce automaticamente un server già compromesso. Un antivirus può non vedere una configurazione abusata o un account nascosto. Un EDR produce segnali che devono essere interpretati nel contesto.

La difesa più robusta è quindi a strati, con controlli che coprono accesso, vulnerabilità, integrità, comportamento e recovery.

Backup: fondamentale per il recovery, ma non previene una backdoor

Un backup non blocca un attacco e non rileva una backdoor.

Serve però a recuperare dati e sistemi quando è possibile individuare una copia precedente alla compromissione. Per essere realmente utile deve essere protetto, testato e separato abbastanza dall’ambiente di produzione da non essere modificabile dallo stesso attaccante.

La domanda da fare prima del ripristino è: questa copia è precedente alla compromissione oppure contiene già il meccanismo che stiamo cercando di eliminare?

Conclusione

Una backdoor non è semplicemente “un virus che fa entrare gli hacker”. È un concetto più ampio: un percorso di accesso nascosto, alternativo o non documentato che aggira il normale modello di sicurezza.

Può essere introdotta da un malware, installata dopo lo sfruttamento di una vulnerabilità, nascosta in una web shell, associata a un account o presente più in profondità nel software o nel firmware. Ed è proprio questa varietà a renderla insidiosa.

Se sospetti una compromissione, la priorità non è trovare un nome da assegnare al file sospetto. Devi ricostruire punto d’ingresso, persistenza, privilegi e perimetro, quindi eliminare tutti i meccanismi di accesso, correggere la causa originaria e verificare il sistema dopo il ripristino.

Per un sito WordPress, quando non puoi stabilire con sufficiente certezza che la bonifica sia completa, affidarti a una rimozione professionale del malware WordPress può essere più prudente che continuare a eliminare singoli file senza conoscere l’intera catena della compromissione.