Avaluació inicial sense contrasenyes Pressupost abans d’intervenir Un especialista responsable de principi a fi

Persistence Reinfection

El malware torna després de restaurar una còpia neta

Descobreix per què torna el malware després d'una còpia revisant antiguitat, codi vulnerable, credencials, cron i persistència del compte.

Una còpia pot semblar neta perquè la redirecció o spam encara no s’havia activat. Pot contenir una porta posterior adormida, connector vulnerable, administrador robat o tasca. L’atacant també pot romandre fora mitjançant hosting, DNS o una web veïna.

No repeteixis la mateixa restauració sense conservar la cronologia de reinfecció.

Defineix què significava neta

Registra data, font, fitxers i base inclosos i com es va provar. Un escàner o una portada normal no són suficients.

Comprova si inclou:

  • arrel completa i ocults;
  • base i usuaris;
  • mu-plugins;
  • uploads i PHP desconegut;
  • cron o hosting;
  • webs veïnes.

Conserva l’estat reinfectat abans de sobreescriure de nou.

Defineix també quines dades comercials no es poden perdre entre la data de la còpia i el tall: comandes, formularis, usuaris, reserves o comentaris. Restaurar tot el bolcat antic pot netejar codi i esborrar activitat legítima. Planifica una migració selectiva i revisada quan existeixi aquesta diferència.

Construeix una cronologia precisa

Anota final de restauració, canvis DNS o memòria cau i primer símptoma. Registra actualitzacions, inicis de sessió, cron i peticions intermèdies.

Si apareix immediatament, pot ser als fitxers, base o memòria cau. Després d’un interval, revisa cron i accessos externs. Després de la primera petició, es pot activar sota demanda.

Utilitza una zona horària comuna mantenint les dates originals.

Registra qui va poder accedir durant la finestra i quins secrets van continuar vigents. Si el mateix administrador, SFTP o token de desplegament va continuar actiu, la reinfecció no demostra que la còpia estigués contaminada; pot reflectir un accés extern encara obert.

Analitza la còpia sense connexió

Restaura en un entorn aïllat sense xarxa pública. Compara nucli i paquets, revisa codi propi, base i esdeveniments programats.

No obris pàgines sospitoses al navegador habitual ni permetis correus, webhooks o tasques externes.

Calcula hashes de fitxers inesperats i posa’ls en quarantena. Tracta la còpia com a evidència no fiable, no com un release desplegable.

Apedaça abans de publicar

Actualitza o substitueix nucli, connectors i temes vulnerables des de fonts verificades dins de l’aïllament. Retira components sense suport i revisa càrregues i autenticació pròpies.

Neteja usuaris, contrasenyes d’aplicació, opcions, cron i scripts de base. Rota salts i credencials en ordre.

No exposis la versió antiga ni per a una prova breu.

Desactiva correus, pagaments, webhooks i cron externs a l’entorn aïllat. Substitueix els secrets per valors de prova perquè una tasca adormida no contacti amb clients o sistemes reals durant la revisió.

Verifica la procedència de la còpia

Confirma quin sistema va crear l’arxiu i si es va executar dins del WordPress compromès. Un connector pot empaquetar fidelment malware i algú amb panell pot substituir la còpia o canviar la retenció.

Compara hashes amb registres del proveïdor. Revisa destinació, claus de xifratge i compte de restauració. Si no és fiable, reconstrueix aplicacions i migra només contingut revisat.

Revisa persistència externa

Inspecciona usuaris i sessions del panell, FTP o SFTP, claus de desplegament, cron de servidor, correu, DNS i CDN. Revisa cada instal·lació compartida.

Una còpia neta no revoca cPanel robat ni una porta posterior a staging.

Coordina la rotació amb dispositius i automatització per no tornar a robar secrets nous.

Fes la rotació començant pel correu de recuperació i els panells mestres i després per credencials dependents. Documenta qui actualitza cada integració i confirma que el valor anterior deixa de funcionar sense escriure’l a l’informe.

Tracta memòria cau i diversos orígens

La CDN pot conservar una resposta infectada i un balancejador restaurar només un node. Compara origen i ruta pública amb mètodes autoritzats.

Purga després de verificar l’origen i confirma codi i configuració a cada node.

Una resposta neta intermitent no prova res.

Abans del tall, compara hashes, configuració i versió de base a tots els orígens. Congela escriptures durant la sincronització final per evitar que el node antic accepti comandes o formularis que no arribin al reconstruït.

Verifica més enllà de l’interval anterior

Repeteix dispositiu, referrer i ruta originals i monitoritza fitxers i base. Executa cron i fluxos administratius permesos.

Observa més temps que l’interval entre restauració i reinfecció. Revisa usuaris, tasques, connexions i alertes.

Assaja una restauració addicional de la nova còpia neta en aïllament. Així demostres que la recuperació següent no depèn de fitxers temporals o secrets presents només al servidor reparat.

Quan demanar neteja de reinfecció

Demana ajuda si fallen diverses restauracions o no es confia en la còpia. Envia cronologia, símptomes públics i data, no l’arxiu ni credencials.

Una recuperació fiable neteja abans de desplegar, tanca accessos externs i demostra que la ruta original ja no funciona.

ABANS D’ENVIAR LA SOL·LICITUD

Preguntes freqüents.

Demaneu contrasenyes al formulari?+

No. El formulari públic no demana mai accessos. Les dades segures es demanen només després d’aprovar l’abast i el pressupost.

Qui revisa la incidència?+

La sol·licitud arriba a Jordi Ensenyat, fundador de Code Barcelona i especialista en WordPress amb més de 15 anys d’experiència.

Es canvia res abans del pressupost?+

No. Primer es revisen els símptomes visibles i es defineix l’abast. La intervenció comença després de l’aprovació i amb una via de recuperació preparada.

Treballeu amb webs en anglès i fora d’Espanya?+

Sí. WP Repair atén incidències de WordPress i WooCommerce en català, castellà i anglès mitjançant un servei remot.

Avaluar la meva incidència