Появился код в index.php

Да кто его знает что за Ганстер там пошкодничал , часто еще бекдоры ставят - тут надо с чистого бекапа востанавливать

---------- Добавлено 17.12.2014 в 22:22 ----------

Скачайте скрипт Айболит и проверте на шелы и прочее

видимо вы еще не все нашли, просто куки устанавливать смысла нет, их надо где то использовать, а значит где-то ещё вставки должны быть

А что, и он тоже собирается? 😮😡

Неужели придётся переходить на поиск маилру... 🙅

Можно попробовать запросить фтп логи у хостера, как ни странно, но фтп пароли уводят/подбирают может и не часто, но случаи есть. Обычно конечно подбор стандартных паролей работает.

Второе - посмотреть дату модификации файлов, если код замечен недавно, и сайт активно не редактируется (именно скрипты сайта) то это может помочь. Руками конечно это сложно проверить, т.к у CMS как правило 100500 файлов. Поэтому лучше чтобы хостер отправил список файлов, которые были изменены за последнюю неделю скажем, или когда вы заметили внедрение в скрипт. Так можно будет найти и другие скрипты, в которое мог быть внедрен код, а также и сам шел.

начните со смены паролей, всех паролей... Проверьте айболитом сайт и по совету MaksimAlekseev запросите список последних изменных файлов, или сами сделайте если есть доступ к shell

Если есть возможность, лучше сайт из бекапа развернуть на дату когда гадости с большей вероятности не было.

А зараженный скачать и по изучать на досуге :)

а если в бекапе была уязвимость? и еще такой момент. сайт мог быть взломан давно, хакер массово мог залить на кучу уязвимых сайтов вебшел или бекдор, через который потом вставлять вредоносный код. был случай когда код на сайте менялся время от времени. зараза лежала в одном из файлов шаблона и никак не проявлялась антивирусом

В том виде, в каком вы представили, этот код не имеет смысла и зловредности. Может вы не полностью процитировали?

Не имеет смысла также прописывать эти куки на самом виду в index.php и затем делать где-то еще вставки. Всё бы делалось в одном месте и поглубже.

Если вы после обнаружения не редактировали сами этот файл, то вам нужно определить ctime этого файла. Узнаете точную дату и время вставки. Именно ctime. Есть еще atime и mtime, но они бесполезны, ибо легко подделываются. После этого командой find найти у каких еще файлов менялся ctime в эту дату. Полезно также посмотреть лог апача за указанную дату и примерное время. Какие были запросы, особенно запросы типа POST. POST-запросы предшествующие времени изменения файла, как правило, конкретно укажут вам файл с шелом. Но чистить все это бесполезно. Нужно искать уязвимость, в противном случае все это повторится в любое время заново.