Как избавиться от скрипт вируса

Script.Virus-есть или нет угроза в файле

#1 antibiotik86

Posters

5 Сообщений:

Добрый день, есть файл программы для редактирования биоса (извлечение биоса из ехе), при его запуске доктор веб пишет что найден и удален скрипт-вирус во временной папке виндовс и удаляет его, при проверке исходного ехе-файла доктор веб пишет что все в порядке и ничего нет, отправил файл на вирус тотал- там десяток антивирусов пишет что есть все таки троян, помогите понять- эта утилита заражена или нет

вот скриншот журнала доктора веба с найденным вирусом

каждый раз при запуске утилиты возникает новый скрипт во временной папке и доктор веб его удаляет

Помогите разобраться с файлом, файл приложил

Прикрепленные файлы:

• B2MB_112.rar682,31К 1 Скачано раз

Сообщение было изменено antibiotik86: 12 Декабрь 2016 — 23:53

#2 Dr.Robot

Helpers

2 831 Сообщений:

1. Если Вы подозреваете у себя на компьютере вирусную активность и хотите получить помощь в этом разделе,

Вам необходимо кроме описания проблемы приложить к письму логи работы трёх программ — сканера Dr. Web (или CureIt!, если антивирус Dr. Web не установлен на Вашем ПК), Hijackthis и DrWeb SysInfo. Где найти эти программы и как сделать логи описано в Инструкции. Без логов помочь Вам не сможет даже самый квалифицированный специалист.

2. Если у Вас при включении компьютера появляется окно с требованием перечислить некоторую сумму денег и при этом блокируется доступ к рабочему столу,

— попытайтесь найти коды разблокировки здесь https://www.drweb.com/xperf/unlocker/
— детально опишите как выглядит это окно (цвет, текст, количество кнопок, появляется ли оно до появления окна приветствия Windows или сразу же после включении компьютера);
— дождаться ответа аналитика или хелпера;

3. Если у Вас зашифрованы файлы,

Внимание! Услуга по расшифровке файлов предоставляется только лицензионным пользователям продуктов Dr.Web, у которых на момент заражения была установлена коммерческая лицензия Dr.Web Security Space не ниже версии 9.0, Антивирус Dr.Web для Windows не ниже версии 9.0 или Dr.Web Enterprise Security Suite не ниже версии 6.0. подробнее.

Что НЕ нужно делать:
— лечить и удалять найденные антивирусом вирусы в автоматическом режиме или самостоятельно. Можно переместить всё найденное в карантин, а после спросить специалистов или не предпринимать никаких действий, а просто сообщить название найденных вирусов;
— переустанавливать операционную систему;
— менять расширение у зашифрованных файлов;
— очищать папки с временными файлами, а также историю браузера;
— использовать самостоятельно без консультации с вирусным аналитиком Dr. Web дешифраторы из «Аптечки сисадмина» Dr. Web;
— использовать дешифраторы рекомендуемые в других темах с аналогичной проблемой.

Что необходимо сделать:
— прислать в вирусную лабораторию Dr. Web https://support.drweb.com/new/free_unlocker/?keyno=&for_decode=1 несколько зашифрованных файлов и, если есть, их не зашифрованные копии в категорию Запрос на лечение. Дожидаться ответа на Вашу почту вирусного аналитика и далее следовать его указаниям ведя с ним переписку по почте. На форуме рекомендуется указать номер тикета вирлаба — это номер Вашего запроса, содержащий строку вида [drweb.com #3219200];

4. При возникновении проблем с интернетом, таких как «не открываются сайты», в браузерах появляются картинки с порно или рекламным содержанием там, где раньше ничего подобного не было, появляются надписи типа «Содержание сайта заблокировано» и пр. нестандартные уведомления необходимо выложить дополнительно к логам из п.1 лог команды ipconfig

Для этого проделайте следующее:

Источник

Очистка заражённых файлов сайта от вредоносного кода

Добрый день, уважаемые Хабраюзеры!

Некоторое время назад, около месяца, на сервере нашей компании появился вирус. На одном из крупных проектов были поражены все *.js файлы. Ситуация обычная — в конец файлов был дописан вредоносный код. Яндекс выдавал предупреждение о заражении сайта и в техотдел пришло задание очистить его. Ситуация разрешилась достаточно быстро, проект был выгружен с чистого репозитория в продакшн, пароли сменили.

Однако вскоре со всех отделов компании в техотдел стали поступать жалобы о заражённых сайтах. Менеджерам жаловались клиенты, сеошники трубили что сайты теряют позиции. Началась настоящая эпидемия. Помимо *.js файлов, заражению подверглись так же *.php файлы, в конец которых был дописан код:

Такому масштабному заражению сервер был подвержен впервые. Мысли по этому поводу были разные, вплоть до бэкдора какого-нибудь недовольного уволенного сотрудника, решившего напакостить. Однако это не подтвердилось. Был написал shell скрипт очищающий *.php файлы, а с *.js файлами справлялись по-прежнему, выгрузкой из чистого репозитория. Пароли учётных записей доступов к сайтам, доступы к фтп — всё было изменено. Перевели всех кто работает с фтп на WinSCP и раздали файлы-ключи доступа.

Сервер потихоньку стал «выздоравливать» а сайты возвращаться в яндекс. Однако кроме более сотни сайтов клиентов на нашем сервере, есть клиенты использующие сторонние хостинги. Доступ по фтп, никакой командной строки и shell. Практически на всех сайтах используется самописная CMS (написанная N-ое количество лет назад) в связке с fckeditor’om или старыми версиями ckeditor’ов. В файл менеджере ckfinder’e проверка авторизованности реализована простым return true; Используй нехочу. Стоит также упомянуть что Множество заражённых *.js файлов выгрузкой чистого репозитория не излечить. Git на таких сайтах нами не используется, а большая часть бэкапов на хостингах хранится максимум 7 дней. А в виду того что сайты расположенные на сторонних хостингах, нами практически не мониторятся, все бэкапы так же были заражены.

В каждый файл вирус добавлял произвольное количество собственных копий, от одной до пяти (мне больше не встречалось) и все они имели различные имена переменных, имена функций и зацепиться за них было невозможно. Единственной неизменной частью кода каждого полиморфа являлся следующий участок кода:

Он и был выбран для поиска вхождений по файлам. Были проверены Jquery библиотеки 1.6.3 и 1.7.2 и в исходном коде совпадений не было обнаружено. Значит последовательность можно было использовать.

Чтобы не возиться вручную с несколькими десятками *.js файлов на каждом сайте, было решено написать скрипт на php. Он должен сканировать все указанные ему файлы на предмет искомой строки. Для расширения кругозора, так сказать, было решено не использовать exec(), system() команды или, к примеру, библиотеку phpseclib. Алгоритм прост до безобразия: Скрипт сканирует все директории начиная от заданной, в поисках указанной строки в файлах поиска. Перед внесением изменений, скрипт бэкапит файл (ну всё же мало ли чего) и удаляет строку, в которой присутствует искомая подстрока. Построчная работа была выбрана в виду того, что вирус в файл записывался в одну строку.

Приведу пример кода вируса в *.js файле: pastebin.com/J0zRduQw

Разбирать его я не стал, кому интересно — в интернете много примеров разбора обфусцированного кода. Поэтому перейду сразу к коду сканера.

Код класса довольно подробно закоментирован, вопросов возникнуть не должно.
Пример использования (первый параметр — стартовая директория поиска, второй — тип файлов, учавствующих в поиске, третий — строка поиска):

Создаём экземпляр сканера.

Прежде чем что-то перезаписывать, стоит посмотреть, есть ли файлы удовлетворяющие условиям поиска.

В случае чего, всегда можно восстановить созданные бэкапы.

Сканер был протестирован на многих сайтах и отрабатывает как нужно, единственная проблема которая возникла у нас на сервере — права владельца файла. Нужно чтобы owner’om файла был www:www. В среднем, на один сайт с нескольким десятком *.js файлов уходило от 5-10 до 20 секунд. И привожу список хостингов, на которых скрипт был успешно протестирован: infobox, agava, jino, mchost, hc. Из всех, самым замедленным был mchost, на остальных всё работало достаточно шустро.

Источник

Бортовой журнал

Полет нормальный. Без происшествий.

Как удалить вредоносные скрипты с сайта и предотвратить повторный взлом

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

Выполнять работу по удалению вредоносных скриптов и проводить анализ причин взлома должен специалист с соответствующими знаниями и опытом:

• Для удаления вредоносных скриптов необходимо знание языка программирования PHP, а также знание «изнутри» популярных CMS (Joomla, WordPress и т. п.) и расширений для них. Эти знания требуются, чтобы отличить скрипты непосредственно CMS и ее расширений от посторонних файлов, а также чтобы при встрече с сомнительными скриптами иметь возможность однозначно определить, какие действия они выполняют.
• Для анализа причин взлома требуется опыт администрирования сервера. Это необходимо для анализа состояния файлов на аккаунте, времени их изменения, а также для сопоставления этих данных с журналами сервера для определения, какие именно действия злоумышленника привели к взлому сайтов.

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

Тем не менее, существует ряд мер, которые в некоторых случаях помогают возобновить безопасную работу сайта без наличия специальных знаний. Ограничением приведенного ниже способа является то, что для возобновления работы сайта требуется наличие его резервной копии, созданной на момент до взлома. Если дата взлома неизвестна, можно попробовать применить этот способ, используя самую раннюю резервную копию из имеющихся. Вторым ограничением, как следствие из первого, является то, что после восстановления сайта будут потеряны данные, добавленные на сайт после создания восстанавливаемой резервной копии (например, новые статьи, изображения или документы). Если требуется восстановить работу сайта, сохранив при этом новые данные, необходимо обратиться к специалисту.

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

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

Очередность действий важна, поэтому необходимо выполнять их именно в том порядке, в котором они расположены ниже.

1. Сразу после обнаружения взлома сайта необходимо полностью заблокировать к нему доступ посетителей. Это, во-первых, помешает злоумышленнику вести вредоносную деятельность на сайте, а во-вторых, не позволит ему препятствовать проведению восстановительных работ. Этот шаг очень важен, так как удаление вредоносных скриптов и устранение причины взлома не происходит одномоментно — как правило, на это требуется несколько часов. Если сайт останется доступным извне, злоумышленник сможет произвести повторную загрузку скриптов в тот раздел сайта, который уже был очищен. При этом злоумышленник может использовать различные IP-адреса для подключения, поэтому запрет доступа только для списка IP-адресов не даст результата. Чтобы гарантированно очистить сайт от найденных вредоносных скриптов, необходимо полностью закрыть для злоумышленника возможность обращения к сайту, что можно сделать только с помощью полной блокировки сайта для любых посетителей. Обратитесь в службу технической поддержки хостинга, на котором размещается ваш сайт, чтобы произвести блокировку.
2. После блокировки сайта необходимо проверить компьютеры, с которых производилась работа с сайтом, современным антивирусом с обновленными вирусными базами. Если сайт был взломан путем кражи паролей от аккаунта с помощью вируса, необходимо убедиться, что дальнейшая работа со взломанным сайтом ведется с компьютера, на котором вирусы отсутствуют, иначе после смены паролей доступа они снова могут быть украдены.
3. После блокировки сайта и проверки на вирусы необходимо изменить все пароли доступа к аккаунту: доступы через FTP, через SSH, а также доступы к панели управления хостингом. Если злоумышленник получал доступ к файлам аккаунта одним из этих способов, после смены паролей он больше не сможет сделать это.
4. После смены паролей необходимо уничтожить все процессы сервера, работающие от имени аккаунта, на котором обслуживается сайт. Запущенные злоумышленником в фоновом режиме процессы, не будучи уничтожены, смогут после проведения восстановительных работ повторно разместить вредоносные скрипты на сайте. Чтобы этого не произошло, все процессы, запущенные до блокировки сайта, должны быть уничтожены. Сайт в этот момент уже должен быть заблокирован, чтобы злоумышленник не смог запустить новые процессы, обратившись к одному из своих скриптов на сайте. Для уничтожения запущенных на аккаунте процессов обратитесь в службу технической поддержки хостинга, на котором размещается ваш сайт.
5. Теперь проникновение на сайт извне невозможно и можно приступать к его восстановлению.
6. Перед дальнейшими действиями удалите все существующие файлы сайта, чтобы среди них гарантированно не осталось вредоносных скриптов, или скриптов CMS, в которые злоумышленник внедрил вредоносный код. Этот шаг также важен, так как при восстановлении сайта из резервной копии не всегда удаляются файлы, которые существовали до восстановления. Если после восстановления из резервной копии на сайте останутся старые вредоносные скрипты, злоумышленник сможет повторно проникнуть на сайт. Избежать этого можно, удалив все файлы сайта перед проведением восстановления.
7. После удаления всех файлов сайта восстановите сайт из резервной копии, созданной до его взлома. Часто достаточно восстановить только файлы сайта, однако если после их восстановления в работе сайта наблюдаются ошибки, необходимо восстановить сайт полностью: и файлы и базу данных.
8. После восстановления из резервной копии обновите используемые версии системы управления сайтом(CMS) и ее расширений до последних. Это необходимо, чтобы исключить присутствие на сайте известных уязвимостей, через которые он может быть взломан. Как правило, обновление можно произвести через раздел администрирования CMS. Для получения полных инструкций по обновлению CMS необходимо обратиться на сайт разработчика системы. Важно обновить не только саму CMS, но и все ее расширения, так как часто взлом происходит через уязвимость, присутствующую в одном из расширений CMS (например, плагины, темы оформления, виджеты и пр.). В этот момент еще нельзя снимать блокировку сайта для посетителей, так как он может быть еще уязвим. Чтобы получить доступ к сайту для обновления, обратитесь в техническую поддержку хостинга, на котором размещается ваш сайт, и попросите разрешить доступ к сайту только с IP-адреса вашего компьютера. Узнать ваш IP-адрес вы можете, например, на inet.yandex.ru.
9. После обновления системы управления сайтом и ее расширений зайдите в раздел администрирования сайта и измените пароль доступа администратора к нему. Убедитесь, что среди пользователей сайта нет других пользователей с административными привилегиями (они могли быть добавлены злоумышленником), а если таковые обнаружатся — удалите их.
10. Теперь, когда сайт восстановлен из резервной копии и не содержит вредоносных скриптов, CMS и ее расширения обновлены до последних версий, в которых отсутствуют уязвимости, а пароли доступа к сайту и аккаунту хостинга изменены, можно вновь открыть сайт для посетителей.

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

Источник