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

Trobar Entrada Persistència

Com documentar el punt d’entrada més probable sense endevinar

Documenta l'entrada probable utilitzant cronologies, versions, peticions, comptes, nivells de confiança i explicacions alternatives.

Els informes acostumen a convertir el primer símptoma en causa: «el plugin estava desactualitzat» o «la contrasenya era feble». Una conclusió útil connecta els esdeveniments fiables amb una capacitat i declara què no es pot provar.

Construeix una cronologia, compara hipòtesis i assigna confiança.

Separa fets i interpretacions

Són fets la versió instal·lada, ruta i estat de petició, login correcte, hora de creació d’usuari, hash o canvi de fitxer i alerta del proveïdor. Les interpretacions els connecten amb una possible entrada.

Etiqueta cada afirmació. No utilitzis la data de detecció de l’escàner com a hora de l’atac sense logs. Treballa en una zona horària i referencia les fonts.

Defineix l’activitat més antiga

Retrocedeix des de redireccions, spam o administradors fins al primer fitxer, compte, petició o configuració. Compara amb l’última còpia fiable i la retenció de logs.

Accions posteriors poden utilitzar logins normals o eines pujades i ocultar l’origen. No confonguis el payload més visible amb l’entrada. Registra el límit d’evidència disponible.

Construeix hipòtesis candidates

Inclou explotació anònima de plugin, sessió WordPress robada, hosting/SFTP, eina MySQL pública, presa del correu o desplegament insegur de staging.

Per a cada opció, llista evidència esperada i present. Afegeix alternatives legítimes com un desplegament autoritzat o una migració fallida. No reprodueixis exploits a producció.

Valida si s’aplica la vulnerabilitat

Per a plugins o temes, registra versió, font, estat actiu, configuració, requisits i cronologia de divulgació.

Un avís per a una altra versió o que exigeix administrador no explica per si sol execució anònima. Ser vulnerable demostra exposició, no explotació. Referencia l’avís fiable a l’informe intern.

Correlaciona comptes

Revisa usuaris, sessions, restabliments, claus i contrasenyes d’aplicació a WordPress, hosting, correu i DNS. Compara accessos correctes amb canvis maliciosos.

IP o país són context, no prova d’identitat. VPN, xarxes compartides i sessions robades compliquen l’atribució. Conserva IDs abans de revocar.

Correlaciona evidència tècnica

Relaciona peticions web, canvis de fitxers o base, cron, correu i dominis sortints. Utilitza hashes, IDs i hores sense compartir payloads o clients.

Les dates de fitxers es poden manipular i MySQL pot utilitzar una altra zona horària. Prefereix diverses fonts independents i declara buits de logging.

Busca contradiccions

Pregunta si cada causa existia abans de la primera activitat i si atorgava els permisos observats. Revisa zona horària, deriva del rellotge, dates restaurades i rotació.

Si el plugin es va instal·lar després del primer usuari maliciós, no va ser l’entrada original. Si un accés al hosting precedeix tot WordPress, els logs d’aplicació potser només mostren accions posteriors. Registra les contradiccions.

Assigna confiança i alternatives

Utilitza expressions com confirmat, molt probable, plausible o indeterminat amb una justificació breu. Inclou l’alternativa més forta i l’evidència que permetria distingir-la.

No converteixis etiquetes en percentatges sense mètode. No anomenis una persona quan només identifiques un compte. Actualitza la conclusió si arriben logs nous.

Fes l’informe reproduïble

Referencia noms de logs, criteris de cerca, hashes, avisos i IDs de captures perquè un altre tècnic pugui verificar. Desa originals per separat i restringits.

No enganxis payloads ni dades personals a la narrativa. Els exemples censurats han de conservar hores i IDs de correlació. Defineix data de revisió si falten dades del proveïdor o dispositiu.

Connecta la conclusió amb controls

Indica què es va apedaçar o retirar, credencials rotades, persistència revisada, sistemes afectats i monitorització afegida. Tanca totes les rutes plausibles d’alt impacte, no només la hipòtesi preferida.

Conserva evidències segons el procés i minimitza dades personals. Si la causa afecta l’abast legal o hi ha reinfecció, demana revisió especialitzada compartint cronologies, versions i fonts censurades, mai exploits o claus.

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