Actualitzar un connector vulnerable tanca el punt d’entrada conegut per a peticions futures. No elimina fitxers, usuaris, tasques programades o credencials robades mentre la vulnerabilitat estava oberta.
Considera l’aplicació del pedaç i la neteja posterior a l’explotació com dues fases diferents.
Conserva les dades de l’estat vulnerable
Registra el nom del connector, les versions anterior i nova, l’hora d’actualització i el període durant el qual va estar exposat. Desa els avisos del proveïdor o de l’eina de seguretat i els logs d’accés rellevants.
Conserva fora de línia una còpia del connector anterior i dels fitxers sospitosos per analitzar-los, però impedeix-ne l’execució pública després de recollir les evidències.
No reinstal·lis la versió antiga en un staging connectat a Internet per reproduir l’atac.
Determina què permetia la vulnerabilitat
Consulta l’avís oficial del desenvolupador i fonts fiables de vulnerabilitats. Esbrina si permetia pujar fitxers, crear usuaris, modificar opcions, llegir configuració o executar PHP.
Utilitza aquestes capacitats per definir la investigació. Una pujada de fitxers sense autenticació exigeix comprovacions diferents d’un error d’ajustos reservat a administradors.
No pressuposis que la prova de concepte publicada enumera totes les accions que va fer l’atacant.
Busca artefactes posteriors a l’explotació
Revisa fitxers modificats recentment, PHP dins d’uploads, connectors desconeguts o mu-plugins, wp-config.php, .htaccess i canvis al nucli.
Inspecciona administradors, contrasenyes d’aplicació, WP-Cron, Action Scheduler i scripts o opcions de base. Busca dominis externs i noms de fitxer identificats als logs.
Analitza el contingut sospitós fora de línia; no obris les URL de les portes del darrere en un navegador.
Construeix indicadors específics de l’exposició
Recopila rutes, paràmetres, IP d’origen, noms de fitxer i hores de l’avís del proveïdor, l’informe de l’allotjament i els teus propis registres. Utilitza’ls per localitzar possibles explotacions als logs i als webs veïns.
Tracta els indicadors com a pistes amb context i caducitat. Una IP compartida, un nom PHP genèric o una petició POST ordinària poden ser legítims. Conserva les coincidències i contrasta-les amb canvis de fitxers o base abans de bloquejar rangs amplis o esborrar qualsevol fitxer semblant.
Si els logs no cobreixen el període exposat, documenta aquesta limitació i amplia la revisió de persistència.
Substitueix els components de confiança
Elimina completament el directori compromès i instal·la el paquet apedaçat obtingut d’una font verificada. Reconstrueix el nucli i altres components comercials modificats des de les seves fonts oficials.
Revisa manualment el codi propi en comptes de copiar directoris complets del web infectat. Neteja la persistència a la base amb una còpia prèvia i atribució de cada dada.
Buida les memòries cau d’opcode i de pàgina mitjançant els controls admesos per l’allotjament.
Rota els secrets exposats
Si l’error podia llegir wp-config.php, rota les credencials de base i els salts de WordPress. Revisa allotjament, SFTP, desplegament i secrets API desats al servidor.
Revoca sessions, administradors i contrasenyes d’aplicació desconeguts. Coordina les integracions perquè cap automatització torni a introduir valors antics.
Canviar contrasenyes no elimina una porta del darrere que ja existeix com a fitxer.
Revisa l’explotació a tot el compte
Busca als logs peticions a l’endpoint vulnerable de cada web que executava el connector. Inclou staging, instal·lacions oblidades i permisos compartits de l’allotjament.
El connector de producció pot estar actualitzat mentre una còpia antiga continua vulnerable i pot escriure al mateix compte.
Retira o aïlla les còpies sense suport i assigna una responsabilitat clara sobre les seves actualitzacions.
Verifica el tancament de l’entrada i la persistència
Confirma la versió apedaçada i que el comportament vulnerable ja no existeix mitjançant indicacions segures del proveïdor, mai amb payloads reals contra producció.
Monitoritza fitxers, usuaris, cron i connexions sortints durant més temps que el període anterior de recurrència. Repeteix els símptomes públics originals com a visitant net i documenta tant les troballes com les evidències que ja no estan disponibles.
Comprova que les actualitzacions automàtiques, desplegaments i còpies no conserven el paquet vulnerable. Una restauració posterior podria reobrir silenciosament el mateix accés.
Quan cal una neteja posterior a l’atac
Demana una avaluació si el web va estar exposat abans del pedaç, van aparèixer fitxers o usuaris, o el connector gestionava pujades o autenticació. Comparteix versió, cronologia i símptomes públics sense credencials.
Una resposta completa demostra que l’entrada està corregida i que s’ha eliminat tota persistència creada durant l’exposició.