Când am preluat site-ul unei clinici stomatologice, se deschidea și părea să funcționeze normal. Paginile erau disponibile, iar autentificarea în WordPress funcționa. La verificarea serverului am găsit însă scripturi malițioase, cod ascuns în folderul unui plugin și șapte administratori suspecți.
Mai jos explicăm cum am descoperit atacul și am curățat site-ul. Analizăm și 12 semne care pot ajuta proprietarul sau specialistul să observe o problemă similară.
Cum s-a transformat o verificare regulată a accesului într-o investigație
După transferul proiectului, am verificat accesul și apoi am trecut la fișierele și setările serverului.
Fișierele care nu se află în distribuția oficială au fost găsite în folderele sistemului WordPress. Alături era un fișier de setări .htaccess: permitea serverului să execute scripturi cu o extensie non-standard.
Am studiat conținutul fișierelor. Scripturile primeau comenzi din exterior și le executau pe server. Erau backdoor-uri: mecanisme ascunse de acces la site.
Verificarea a continuat. Într-un subfolder al unui plugin am găsit încă un fișier malițios de aproximativ 538 KB. Acesta conținea un bloc codificat, încărcat și executat drept cod PHP. Am verificat apoi utilizatorii WordPress și am descoperit șapte conturi suspecte cu drepturi de administrator.
Pentru a reconstitui istoricul infectării, am comparat descoperirile cu datele fișierelor și jurnalele de acces. Metadatele indicau modificări la sfârșitul lunii iunie, iar jurnalele din august conțineau solicitări către adrese caracteristice backdoor-urilor. Fișierele malițioase au rămas chiar și după actualizarea WordPress.
Am confirmat astfel existența backdoor-urilor și a unor accesări administrative nejustificate. Nu am putut stabili punctul inițial de intrare pe baza datelor strânse. Nici datele fișierelor nu dovedesc ziua exactă a atacului: pot fi modificate.
12 semne care ajută la descoperirea unui atac
Am găsit primele patru semne în acest proiect. Restul au fost incluse în lista de verificare pentru verificarea altor site-uri.
1. Administratorii necunoscuți au apărut în panoul de administrare
Fiecare cont cu drepturi complete trebuie să aibă un titular cunoscut. Un utilizator necunoscut poate fi un furnizor anterior, de aceea trebuie stabilit cine l-a creat și de ce.
După verificare am eliminat șapte administratori suspecți și am păstrat conturile necesare pentru lucru.
2. Există fișiere străine în folderele de sistem
Scripturile noi și directoarele necunoscute din nucleul WordPress necesită verificare. Fișierele noastre standard au fost verificate față de originalul, dar au existat unele rău intenționate lângă ele.
Verificarea sumelor de control WordPress permite compararea fișierelor nucleului cu distribuția oficială. Pluginurile, temele, fișierele încărcate și baza de date trebuie verificate separat.
3. Codul de neînțeles este ascuns în pluginul sau folderul cu teme
Motiv pentru a arunca o privire mai atentă: un fișier PHP necunoscut printre imagini și stiluri, blocuri lungi codificate, cod care încarcă sau execută alt conținut.
Așa arăta una dintre descoperirile noastre. Totuși, simpla codificare nu dovedește infectarea: trebuie analizat ce face programul. Nici găsirea unui backdoor într-un folder de plugin nu dovedește că atacul s-a produs prin acel plugin.
4. Setările serverului au fost modificate fără știrea dvs
Redirecționările sau regulile altcuiva pot apărea în .htaccess care permit executarea fișierelor cu extensii neobișnuite.
Aceste reguli permiteau executarea scripturilor malițioase. La curățare am verificat atât backdoor-urile, cât și regulile care le permiteau să ruleze.
5. Apar scripturi executabile în folderul fișierelor încărcate
Directorul cu fotografii și documente trebuie verificat pentru programe necunoscute. Analiza extensiilor nu este suficientă: executarea depinde și de setările serverului.
În timpul curățării am verificat separat fișierele încărcate și am interzis executarea tipurilor periculoase în acel folder.
6. În căutare au apărut pagini pe care nimeni nu le-a publicat
De exemplu, site-ul web al clinicii este găsit pentru întrebări despre cazinouri sau produsele altor persoane. Verificarea începe cu adrese specifice: ce se deschide pe ele, de unde provine conținutul, dacă este în panoul de administrare.
O adresă URL necunoscută poate fi o pagină veche sau un duplicat. O adresă lungă și sfârșitul -2 nu indică în sine hacking.
7. Vizitatorii sunt redirecționați către site-uri terțe
Proprietarul vede pagina obișnuită, dar un vizitator dintr-un motor de căutare ajunge la reclame sau la alt site. Merită comparate accesările din căutare cu cele directe și verificat site-ul pe mobil și fără autentificare.
Aceste redirecționări sunt descrise în ajutorul de securitate Google.
8. Browserul, motorul de căutare sau găzduirea raportează o amenințare
Notificarea trebuie verificată: ce fișier sau adresa a declanșat-o, ce anume a fost detectat.
Google Search Console are o secțiune „Probleme de securitate” pentru aceasta. Poate afișa exemple de pagini infectate, dar lista nu este neapărat completă. De asemenea, absența avertismentelor nu confirmă curățenia serverului.
9. Au apărut sarcini programate necunoscute
Sarcinile de fundal sunt folosite pentru copii de rezervă, notificări și actualizări. Suspiciunea este ridicată de sarcinile al căror scop nu le poate explica nimeni, mai ales dacă rulează un fișier necunoscut.
Trebuie să verificați atât sarcinile WordPress, cât și programul din panoul de găzduire. Acestea sunt liste diferite.
10. Serverul creează o încărcare inexplicabilă sau trimite e-mailuri nedorite
Site-ul încetinește fără creșterea vizitelor, găzduirea semnalează trimiterea de mesaje, iar consumul de resurse crește brusc.
Cauza poate fi un program malițios, o eroare de plugin sau o copie de siguranță care consumă multe resurse. Jurnalele și analiza proceselor arată ce fișier rulează și ce face.
11. Jurnalele conțin apeluri către scripturi suspecte
În acest proiect au existat astfel de solicitări. Înainte de curățare, backdoor-urile găsite erau accesibile și prin HTTP.
Faptul că un bot accesează un fișier inexistent nu dovedește că atacul a reușit. Nici măcar un răspuns 200 OK nu demonstrează că a fost executată comanda. Solicitările trebuie corelate cu conținutul fișierului și cu alte evenimente de pe server.
12. După ștergere, fișierele sau paginile străine apar din nou
Trebuie căutat un acces rămas activ: alt backdoor, un administrator necunoscut, o sarcină de fundal sau date de autentificare furate.
Dacă ștergeți doar fișierul care apare, problema poate să reapară. Trebuie să aflăm cine sau ce îl restaurează.
Folosind această listă, este convenabil să colectați întrebări pentru verificare. Numărul de potriviri nu determină diagnosticul: hacking-ul este confirmat de fișiere, acțiuni și modificări specifice.
Cum am curățat site-ul
Mai întâi am păstrat dovezile investigației. Am mutat fișierele malițioase într-o carantină cu acces restricționat, în afara directorului public. Am salvat acolo și setările originale și informațiile despre fișiere. Înainte de ștergerea utilizatorilor am făcut o copie a bazei de date.
Această ordine păstrează dovezile și permite verificarea modificărilor dacă apar probleme după restaurare. Și instrucțiunile WordPress pentru un site compromis recomandă salvarea stării înainte de curățare.
Am restaurat apoi fișierele: am reinstalat nucleul WordPress din pachetul oficial, am înlocuit pluginul infectat printr-o actualizare oficială și am eliminat directorul vechi și neutilizat al altui plugin. Am actualizat componentele pentru care existau pachete disponibile. Nu am considerat actualizate pluginurile comerciale cu restricții de actualizare.
Am eliminat cei șapte administratori suspecți, am încheiat sesiunile vechi ale utilizatorilor păstrați și am schimbat cheile secrete de autentificare WordPress. Schimbarea acestor chei nu înlocuiește schimbarea parolelor.
Protecția fișierelor a fost consolidată separat:
- am interzis executarea scripturilor în folderul fișierelor încărcate;
- am limitat încărcarea tipurilor de fișiere periculoase;
- am dezactivat editarea fișierelor din administrare;
- am limitat accesul la fișierele de configurare și de sistem;
- am dezactivat înregistrarea utilizatorilor care nu era necesară.
Aceste setări reduc șansele de reinfecție. Acestea funcționează împreună cu actualizările și controlul accesului, așa cum este descris în Cele mai bune practici de securitate WordPress.
Ce a arătat re-verificarea
După curățare, fișierele nucleului au corespuns sumelor de control oficiale. Adresele cunoscute ale backdoor-urilor returnau 404, iar pagina principală și autentificarea WordPress funcționau. Noua căutare nu a identificat fișierele malițioase descoperite anterior sau semnele de infectare verificate.
Baza de date a trecut și o verificare a structurii. Acest rezultat confirmă funcționalitatea sa tehnică, dar în sine nu indică absența conținutului rău intenționat.
Am confirmat eliminarea backdoor-urilor descoperite și funcționarea site-ului după modificări. Pentru închiderea completă a incidentului trebuie verificate separat accesările compromise, sarcinile găzduirii și starea tuturor componentelor. O verificare reușită a nucleului nu este suficientă.
De unde să începeți dacă observați semne similare
Pentru a contacta un specialist sau asistență pentru găzduire, este util să colectați exemple specifice: adresa unei pagini suspecte, o captură de ecran a unui avertisment, ora redirecționării, numele unui utilizator necunoscut. Apoi salvați jurnalele și o copie a stării curente a site-ului separat de backup-urile curate cunoscute.
Dacă un site redirecționează deja vizitatorii sau distribuie conținut rău intenționat, accesul la paginile periculoase ar trebui limitat rapid. Ștergerea în masă a fișierelor la întâmplare poate distruge site-ul și poate distruge urmele care ar putea ajuta la rezolvarea acestuia.
Site-ul se deschidea înainte de verificare. Am găsit backdoor-urile prin compararea fișierelor, analiza setărilor și verificarea administratorilor. De aceea, când preluăm un proiect, verificăm și disponibilitatea paginilor, și conținutul serverului.