Īsi: vai serveris ir uzlauzts, izmantojot PHP2Shell, nevar nolasīt no vienas pazīmes. Nav publicētu, apstiprinātu Indicators of Compromise; atpazīšana balstās uz uzvedības analīzi. Tipiskas pazīmes ir jauni PHP faili, nezināmi cron uzdevumi un neparasti savienojumi. Pirms kaut ko mainīt, vispirms saglabājiet žurnālus no 20. oktobra.
Vai ir viennozīmīgas PHP2Shell uzbrukuma pazīmes?
Nē, un tā ir godīga atbilde. Daudzām zināmām ievainojamībām ražotāji vai drošības uzņēmumi publicē konkrētas pēdas: failu nosaukumus, kontrolsummas, IP adreses. PHP2Shell šādu apstiprinātu Indicators of Compromise līdz šim nav.
Kas ir zināms: saskaņā ar plašsaziņas līdzekļu ziņojumiem pirmais uzbrukuma mēģinājums tika novērots 17. oktobrī, četras dienas pirms 21. oktobra ielāpiem. Cloudflare ziņoja par turpmākiem mēģinājumiem. Apstiprināti sekmīgi uzbrukumi plašā mērogā pēc BSI datiem sākumā nebija zināmi. Kas starp 17. oktobri un savu ielāpu bija sasniedzams bez aizsardzības, tam tāpēc jāpārbauda, nevis jācer.
Vērtējumā svarīgs ir galvenokārt laika posms. Starp pirmo novēroto uzbrukuma mēģinājumu 17. oktobrī un ielāpiem 21. oktobrī oficiāla atjauninājuma nebija. Katrs publiski pieejams PHP serveris šajā laikā bija potenciāli uzbrucams. Cik ilgi jūsu serveris bija atvērts pēc tam, ir atkarīgs no tā, kad atjauninājums tika instalēts un PHP pārstartēts. Jo ilgāks šis laiks un jo jutīgāki dati, piemēram, klientu konti, pasūtījumi vai pieteikumi, jo rūpīgākai jābūt pārbaudei.
Tipiskas pazīmes, ka serveris ir uzlauzts
Pēc sekmīgas koda izpildes uzbrucēji parasti mēģina nostiprināties un izmantot serveri. No tā rodas pazīmes, kas nav specifiskas PHP2Shell, bet svarīgas katrā ielaušanās pārbaudē:
- Jauni vai mainīti PHP faili, īpaši augšupielāžu, kešatmiņas vai attēlu direktorijos, kur citādi PHP failu nav.
- Nezināmi cron uzdevumi vai ieplānoti uzdevumi, piemēram, tīmekļa servera lietotājam.
- Neparasti izejoši savienojumi ar nezināmām adresēm, liela tīkla slodze vai pasta sūtīšana, ko neviens nav ierosinājis.
- Jauni administratora konti CMS vai veikalā, mainītas paroles, nezināmas SSH atslēgas.
- Neparasta slodze: pastāvīgi augsta CPU noslodze no nezināmiem procesiem, bieži norāde uz kriptoieguvi.
- Redzamas sekas: pāradresācijas uz svešām lapām, surogātpasta lapas Google indeksā, brīdinājumi pārlūkprogrammā vai Search Console.
Neviena no šīm pazīmēm atsevišķi neapliecina ielaušanos, un to neesamība nepierāda pretējo. Izšķirošā ir kopaina.
Pirmās pārbaudes, nesabojājot pēdas
Pirms kaut ko dzēšat vai pārstartējat: saglabājiet žurnālus. Speciālistu prese iesaka saglabāt servera žurnālus no 20. oktobra. Nokopējiet tīmekļa servera, PHP un sistēmas žurnālus drošā vietā ārpus servera.
Pēc tam palīdz tikai lasošas pārbaudes. Ceļi un lietotājvārdi atšķiras pa sistēmām:
# PHP faili, kas mainīti kopš 17.10.
find /var/www -type f -name "*.php" -newermt "2026-10-17" -ls
# PHP faili augšupielāžu direktorijos (piemērs WordPress)
find /var/www -path "*/uploads/*" -name "*.php" -ls
# tīmekļa servera lietotāja un sistēmas cron uzdevumi
crontab -l -u www-data
ls -la /etc/cron.d /etc/cron.daily /var/spool/cron 2>/dev/null
# aktīvie tīkla savienojumi ar procesu
ss -tunp
# pēdējās pieteikšanās
last -n 30
Ņemiet vērā: uzbrucēji var viltot failu laika zīmogus. Neuzkrītošs find rezultāts tāpēc nav attaisnojošs spriedums. Kā mērķtiecīgi izvērtēt žurnālus, apraksta Tīmekļa servera žurnālu izvērtēšana pēc uzbrukuma; kā atrast slēptās piekļuves, Webshell atpazīšana un noņemšana.
Ja atrodat konkrētas norādes, piemēram, nezināmu PHP failu augšupielāžu mapē: neizdzēsiet, neuzstādiet no jauna, nelabojiet lietojumprogrammu „ātri“. Atvienojiet serveri no tīkla vai izolējiet, saglabājiet žurnālus un sistēmas attēlu un sāciet strukturētu incidenta apstrādi.
Ko nedarīt
- Tikai ielāpot un turpināt. Ielāps nenoņem jau ievadītu ļaunprogrammatūru.
- Aizdomīgus failus uzreiz izdzēst. Tā pazūd pierādījumi par to, kas noticis un kuri dati var būt skarti.
- Serveri uzstādīt no jauna, pirms nodrošināta kopija. Cēlonis paliek neskaidrs, un slēptā piekļuve datubāzē vai piekļuves datos pārdzīvo pārinstalēšanu.
- Vecas rezerves kopijas atjaunot bez pārbaudes. Arī rezerves kopija var jau saturēt slēpto piekļuvi.
- Aizmirst piekļuves datus. Pēc koda izpildes datubāzes paroles, API atslēgas un citi piekļuves dati no konfigurācijas failiem var būt aizplūduši. Atjaunojiet tos pēc attīrīšanas, nevis pirms, lai vēl aktīvs uzbrucējs jaunos uzreiz nenolasītu.
Ja aizdomas apstiprinās
Tad runa ir par vairāk nekā tehniku. Kopā ar datu aizsardzības speciālistu pārbaudiet, vai nepieciešams ziņojums saskaņā ar VDAR; termiņš ir 72 stundas no brīža, kad kļuvis zināms, detaļas sadaļā VDAR ziņošanas pienākums. Savlaicīgi informējiet kiberapdrošinātāju, ja tāds ir, un ar advokātu noskaidrojiet, vai jāiesniedz iesniegums policijai. Mēs šajā jautājumā sniedzam vispārīgas norādes, nevis juridisko konsultāciju.
Kā PHP SOS palīdz konkrēti?
Ar mūsu Incident Response mēs aizdomas strukturēti izstrādājam:
- Nodrošināt: žurnāli no 20. oktobra un, kur nepieciešams, sistēmas attēls, pirms kaut kas tiek mainīts.
- Izmeklēt: failu, procesu, savienojumu un kontu uzvedības analīze; vajadzības gadījumā ar pierādījumu vērtību, izmantojot IT forensiku.
- Attīrīt un aizvērt: noņemt slēptās piekļuves, atjaunināt PHP, atjaunot piekļuves datus, nostiprināt serveri.
- Dokumentēt, līdz incidents ir slēgts un dokumentēts, kā pamats datu aizsardzībai, apdrošināšanai un vadībai.
Biežāk uzdotie jautājumi
Vai PHP atjauninājums pierāda, ka mans serveris ir tīrs?
Nē. Ielāps aizver ievainojamību nākotnei, bet nenoņem jau ievadītu ļaunprogrammatūru. Tas arī neko nesaka par to, vai pirms ielāpa kāds nav iekļuvis.
Vai ir skeneris, kas droši atpazīst PHP2Shell uzbrukumus?
Līdz šim nē. Nav publicētu, apstiprinātu Indicators of Compromise, pēc kuriem skeneris varētu mērķtiecīgi meklēt. Ļaunprogrammatūras skeneri atrod zināmus webshell, taču servera novērtējums balstās uz uzvedības analīzi.
Vai man par aizdomām jāziņo datu aizsardzības iestādei?
Tas ir atkarīgs no tā, vai var būt skarti personas dati. VDAR paredz ziņojamiem datu aizsardzības pārkāpumiem 72 stundu termiņu no brīža, kad kļuvis zināms. Noskaidrojiet to savlaicīgi ar datu aizsardzības speciālistu vai advokātu; mēs šajā jautājumā juridisko konsultāciju nesniedzam.
Vai uzlauzto serveri vienkārši uzstādīt no jauna?
Ne kā pirmo soli. Vispirms saglabājiet žurnālus un, ja iespējams, sistēmas attēlu. Kas uzreiz uzstāda no jauna, zaudē pēdas, kas parāda, kas noticis un kuri dati varētu būt skarti.