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

Hosting Dns Containment

Què preguntar a l’allotjament durant un incident de malware WordPress

Demana evidències, contenció, abast, accés de recuperació i criteris de validació durant un incident WordPress.

L’allotjament pot detectar fitxers, suspendre el compte o restaurar una còpia, però el proveïdor i qui neteja WordPress observen capes diferents. Les preguntes precises conserven evidència i eviten el cicle d’«escàner net» seguit de reinfecció.

Obre un únic tiquet des del canal verificat i registra hores i zones horàries.

Pregunta què va activar l’alerta

Demana rutes exactes, noms de detecció, primera i última aparició, hashes i si es va observar phishing, descàrregues, spam, abús de recursos o connexions sortints.

Pregunta si els fitxers es van eliminar, posar en quarantena o només informar. Conserva l’informe original.

No demanis mostres malicioses per correu; utilitza el procés segur de quarantena o recuperació.

Aclareix l’abast del compte i servidor

Pregunta quina subscripció, usuari del sistema i webs estan afectats i si hi ha indicadors similars al servidor. Confirma si va funcionar l’aïllament.

Demana la revisió dels accessos de panell, FTP, SFTP, SSH, gestor de fitxers i API. Pregunta per cron privilegiat i directives PHP prepend sospitoses.

El client d’un allotjament compartit pot no veure evidències disponibles per al proveïdor.

Demana la conservació dels logs

Sol·licita retenir logs d’accés i error web, PHP, autenticació, canvis de fitxer, correu i panell durant la finestra de l’incident.

Confirma la durada de retenció, la zona horària i el mètode segur d’exportació. Poden contenir dades personals o tokens, així que demana només els camps rellevants i protegeix la còpia.

No activis retroactivament logs detallats de cossos en una botiga en funcionament.

Acorda contenció i accés de recuperació

Esbrina si el compte està suspès, en només lectura o disponible per SFTP, SSH o quarantena. Pregunta com servir un avís net sense executar PHP infectat.

Demana instantànies de fitxers i bases abans de reparar. L’accés de recuperació ha de ser individual i temporal.

No demanis reactivar públicament tot només per entrar a wp-admin.

Comprèn els criteris de reparació

Pregunta quina evidència exigeix el proveïdor per tornar a analitzar i reactivar: rutes eliminades, components actualitzats, rotació, revisió de tot el compte i període d’observació.

Esbrina com apel·lar falsos positius en codi propi o comercial legítim.

Superar l’escàner de l’allotjament no substitueix revisar base, usuaris, cron i via d’entrada.

Pregunta què no pot verificar

Aclareix si l’escàner inspecciona files de base, usuaris, cron, contrasenyes d’aplicació, CDN, Workers, DNS, comptes de correu i gestors d’etiquetes. Pregunta si atribueix escriptures o només detecta contingut després.

Registra les evidències no disponibles i les llacunes de retenció. Així, tancar el tiquet com a «net» no es confondrà amb una prova sobre capes mai examinades.

Pregunta qui és responsable del sistema operatiu, el servidor web i l’aïllament, i com escalar si diversos usuaris mostren el mateix indicador.

Consulta les còpies amb cura

Demana dates, origen, integritat i cobertura de fitxers i bases. Pregunta si les còpies antigues van ser analitzades o poden contenir el mateix indicador.

No sobreescriguis l’estat actual sense una instantània. Restaura primer en aïllament, mai directament sobre producció.

Confirma que els backups són fora de directoris públics.

Coordina correu, DNS i CDN

Pregunta si van aparèixer bústies o reenviaments, canvis DNS o spam sortint. Si el proveïdor gestiona DNS o CDN, demana logs i exportacions de configuració.

Comprova si la memòria cau serveix HTML infectat després de netejar l’origen.

Protegeix el correu del propietari utilitzat per restablir l’allotjament.

Tanca amb un traspàs escrit

Lliura un resum: causa o evidències, webs netejats, paquets substituïts, accions sobre credencials, aïllament i verificació. Demana el resultat final de l’anàlisi i les limitacions restants.

Demana ajuda especialitzada si no ofereixen recuperació, hi ha diverses subscripcions o pot existir compromís privilegiat. Sol·licita un número d’incident i conserva la resposta amb el manifest.

Una bona coordinació produeix una cronologia compartida i un límit net verificat, no anàlisis duplicades sense explicació.

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