Pokud se napadení vrátilo, tak ideální je, se vrátit k záloze (před napadením pokud taková existuje). Git umožní porovnat obsah souborů…

Pokud taková možnost není, pak:

• Podrobně a důkladně projít celý adresář "sites", včetně files a zbavit se všeho podezřelého.
• Změnit všechny přístupy na hostingu…  (ftp, databáze …).
• Změnit hesla u všech uživatelů (hlavně u těch s admin rolemi)
• Jak nahráváte nový kód na web? Předpokládám že FTP? Přejděte na hosting kde je git.

Jestli existuje automatický tool na kontrolu DB netuším. Ale projděte ji manuálně, jestli tam není přímo extra tabulka co tam nemá co dělat.

Přistupujte k tomu tak, že web po napadení je kompletně kompromitován a to že opravíte původní chybu, neznamená, že si útočník nevyrobil zadní vrátka někde jinde.

O ostatní weby na lokále bych se tolik nebál…

Podle jména toho souboru "libasset.php" jsem našel tenhle článek, jsou tam nějaké další typy a odkazy. https://www.sitelock.com/blog/drupalgeddon-2-exploit/

Jeste bych pridal:

• contrib kod zkontrolovat s https://www.drupal.org/project/hacked
• spustit plny audit, procist vysledky https://www.drupal.org/project/site_audit
• proskenovat web modulem https://www.drupal.org/project/drupalgeddon

Chvili po drupalgeddonu jsem mel prednasku o zachrane drupalu: https://www.slideshare.net/radimklaska/hacknut-drupal-web-a-co-te Samotna zachrana zacina na slidu 15.

Drupalgeddon byl zradny ve vice vecech:

- nepotreboval nic menit v souborech
- nevytvarel nove tabulky v DB, pouze nove zaznamy v menu_router (mel jsem SQL select, ktery dokazal vybrat podezrele veci, bylo v nem neco jako "LIKE '%access%callback:%true%'.
- ostatni weby muzou byt taky komplet kompromitovane - nelze odpovedet bez znalosti konkretniho pripadu (napr jeden DB user pro vice databazi, jak je to na disku atd...
- files adresar by mel byt nastaven tak aby nevykonaval nikdy PHP kod a pak je jedno co tam utocnik nahraje pokud se bavime o kompromitaci serveru.