dfi suspicious pe что такое
Generic.Malware/Suspicious — что это за вирус, как удалить?
Приветствую. Некоторое антивирусное ПО может найти на ПК файл и посчитать его опасным. Однако отнести его к категории со странным названием, про одно из таких названий сегодня пойдет речь.
Generic.Malware/Suspicious — что это такое?
Группа файлов, являющиеся потенциально опасными, могут быть вирусами либо содержать опасные/вирусные функции.
Данное название использует ПО Malwarebytes при определении угроз, пример:
Файл, который так помечен — может быть и легальным ПО, которое не является вирусом, однако содержит подозрительные функции. Такой файл может быть заблокирован до выяснения причин, он может быть помещен в карантин, откуда его можно восстановить, если вы точно уверены в его безопасности.
Что делать с угрозой Generic.Malware/Suspicious?
Как уже выяснили — это может быть ложная тревога. Поэтому лучше извлечь файла из карантина и вручную проверить:
Проверка на Вирустотал — сперва заходим на сайт, далее выбираем файл:
Далее например может быть такой результат — многие антивирусные движки показали что угроз нет, но 4 — все таки обнаружили:
С Каспером тоже самое — выбираем, нажимаем Проверить:
Далее он проверен будет только Каспером, в результатах будет инфа — результат проверки, дата выпуска антивирусных баз:
Заключение
Добавить комментарий Отменить ответ
Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.
Как создатели вредоносного софта пытаются избежать его обнаружения: разбираем на примере Spy.GmFUToMitm
Специалисты экспертного центра безопасности Positive Technologies (PT Expert Security Center) обнаружили интересный образец вредоносного ПО, распространяющийся в китайском сегменте интернета. Этот софт используется, среди прочего, для осуществления MITM-атак, а главная его особенность заключается в сочетании различных техник ухода от детектирования. Мы решили разобрать их, чтобы показать, как разработчики вредоносного софта скрывают его активность.
С чего все началось
Система анализа сетевого трафика обратила наше внимание на то, что вредоносное приложение регулярно запрашивает изображение с включенным в него дополнительным контентом. Загрузка происходила с легитимного ресурса для хранения изображений — imgsa.baidu.com. К тому же, как выяснилось, это была картинка с зашкаливающим уровнем милоты 🙂 И как же кощунственно после этого выглядела попытка злоумышленников использовать его для сокрытия различных вредоносных нагрузок!
Рис. 1. Изображение, используемое для сокрытия факта доставки полезной нагрузки
Для начала, чтобы собрать исходные данные и сравнить образцы, мы организовали поиск похожих семплов — и обнаружили несколько. Это стало возможным благодаря характерным данным в сетевом взаимодействии и наличию у нас обширной базы вредоносного трафика. В частности, в сетевом трафике можно видеть явный паттерн, закономерность, заключающуюся в повторении одних и тех же действий со стороны вредоносного приложения.
Рис. 2. Сетевой трафик с отмеченными паттернами
Рис. 3. Зашифрованная конфигурация
Расшифровка данных
Расшифровываются полученные данные алгоритмом DES в режиме электронной кодовой книги ключом 0x6a 0x5f 0x6b 0x2a 0x61 0x2d 0x76 0x62, содержащимся в теле вредоносной программы. После расшифрования открытый текст представляет собой строки (рис. 4), каждая из которых содержит ссылку на изображение. Исходя из равенства MD5-хешей, это одно и то же изображение. Видимо, для устойчивости схемы доставки злоумышленники расположили одни и те же данные по разным адресам.
Рис. 4. Пример расшифрованной конфигурации загрузчика
Используя полученные данные, вредоносный загрузчик следующим этапом инициирует скачивание изображения. Отсекает от него первые 5120 байт (утенка и щенка) и использует только полезную нагрузку (рис. 5), которая следует сразу начиная с 5121-го байта.
Рис.5. Пример полезной нагрузки.
После расшифрования данных мы получили очередную конфигурацию формата, аналогичного тому, что был получен на первом шаге. То есть еще одну порцию ссылок на изображения, но на этот раз все MD5-хеши разные и в конце каждой строки есть суффиксы из двух символов:
Рис. 6. Второй набор ссылок и подозрительные суффиксы
Алгоритм работы вредоноса
Теперь это уже настоящие модули полезной нагрузки. Как выяснилось, два символа в конце каждой строки используются для выбора конкретного изображения, то есть конкретной полезной нагрузки. Сперва используется строка с суффиксом «AD» (рис. 7). Данный выбор уже предопределен на этапе создания вредоносной программы. То есть последовательность нагрузок задана заранее в виде двухзначных суффиксов.
Рис. 7. Выбор ссылки с суффиксом «AD»
Скачанное изображение уже содержит вредоносный модуль, это можно сказать хотя бы исходя из его размера. Данные все так же замаскированы под изображения и располагаются по такому же смещению в 5120 байт. Отбросив лишние байты, загрузчик извлекает, проверяет хеш-сумму и затем расшифровывает в PE-файл модуль под названием TkRep.dll.
Рис. 8. Пример зашифрованного модуля в теле изображения и его хеш-сумма
Данная библиотека подгружается во вредоносный процесс и первым делом проверяет среду, в которой запущен модуль:
Рис. 9. Проверка среды виртуализации
Проверяет среди запущенных процессов наличие процессов с именами devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, PCHunter64.exe — а также наличие антивирусных средств.
Рис. 10. Проверка процессов
Делает стандартную проверку на отладку.
Рис. 11. Проверка запуска процесса в контексте отладчика
Проверяет наличие среди открытых пайпов тех, что указаны в таблице.
\\.\FltMouseKb | \\.\GameGuard | \\.\GxWfpFlt |
\\.\XxGamesFilter | \\.\GpeNetSafe | \\.\TeSafe |
\\.\Sdriver | \\.\PowerChange | \\.\xspeed |
\\.\gmMemProt | \\.\diafahbb |
Следующим шагом регистрирует инфицированный узел на сервере злоумышленников, отправляя POST-запросом протокола HTTP информацию о зараженном узле в зашифрованном виде (рис. 12).
Рис. 12. Запрос для регистрации на сервере злоумышленников
Примечательно то, что ответ от сервера всегда содержит одни и те же данные, и более того, клиентом учитывается только код ответа сервера.
Как вредоносный софт скрывает свою активность
В соответствии с заданной последовательностью полезных нагрузок переходим к изучению следующей. Ее суффикс — «AR». Клиент, в соответствии с существующей схемой, скачивает с сервиса хранения изображений Baidu Images очередную конкатенацию изображения с зашифрованной нагрузкой, расшифровывает модуль и запускает его в новом процессе со случайным именем. На наш взгляд, данная функциональность служит для придания вредоносному приложению вида безвредного. Часто это клиент онлайн-игры (рис. 13). И это была очередная техника маскировки.
Рис. 13. Интерфейс онлайн-игры
После проведения этого отвлекающего маневра вредоносный процесс переходит к стадии закрепления на инфицированном узле. Для этого он использует функциональность, схожую с функциональностью rootkit-программ. В частности, внедрение собственного защищенного драйвера в систему.
И вот как это происходит. Из расшифрованной конфигурации выбирается нагрузка с суффиксом «AE». Это библиотека TaskReportDLL.dll. У нее те же функции, как у библиотеки TkRep.dll из предыдущего этапа, — отправить информацию о системе и проверить наличие защитных средств.
Затем скачивается библиотека RealWorkDll.dll. Среди функций RealWorkDll.dll важным является скачивание драйвера, частично защищенного с помощью VMPROTECT, и PE-файла, который этот драйвер установит в системе.
Рис. 14. Путь к базе данных драйвера
Затем удаляются PE-файлы, используемые для установки драйвера, и на этом данный этап закрепления завершен.
Поиск по строке базы данных драйвера привел нас в репозиторий зеркала ресурса rootkit[.]com, в котором был обнаружен экземпляр руткита FUTo с соответствующим именем в пути — «objfre_wxp_x86» (рис. 14). В блоге нашей компании данный руткит рассматривался еще в 2006 году.
Рассмотрим подробнее работу в системе драйвера SDriverBlogx86, установленного модулем RealWorkDll.dll. На первом этапе в сеть уходят регистрационные данные клиента. В качестве запроса применяется POST, но теперь уже на порт с номером 8081 (рис. 15). Видимо, этот порт используется для приема данных, если активность на инфицированной системе достигла этапа активизации руткита «FUTo».
Рис. 15. Запрос на С2 от установленного в системе драйвера
Обращение на сервер злоумышленников происходит в зашифрованном виде, данные до шифрования представляют собой информацию о системе. Разделители полей данных, формат представления и количество полей совпадают у всех модулей (рис. 16).
Рис. 16. Информация о системе для идентификации зараженного узла
Далее механизм работы внедренного в систему драйвера совпадает с инициирующим загрузчиком — с той лишь разницей, что ссылки на изображения на этот раз запрашивались с порта для руткита и путь хранения конфигурации изменился с /koded на /qqwe. Возможно, это как-то связанно с сервисами qq.com и wechat.com.
Список модулей, который получает процесс, содержит список PE-файлов. Но в данном случае вместо двухбуквенного суффикса для выбора нагрузки в конце строки содержится ключ в виде имени файла:
Рис. 17. Конфигурация, получаемая закрепленным в системе драйвером
После загрузки изображений полезная нагрузка также расположена по смещению 5120 байт. Структура полезной нагрузки для установленного драйвера включает в себя ключ из предыдущего списка в виде имени файла, а затем сам PE-файл. В отличие от предыдущих этапов здесь полезная нагрузка не зашифрована.
Рис. 18. Полезная нагрузка, получаемая установленным в системе руткитом
Полученный модуль проверяет наличие процессов с именами devenv.exe, OLLYDBG.EXE, Dbgview.exe, windbg.exe, MSDEV.exe, Delphi32.exe, E.exe, PCHunter32.exe, PCHunter64.exe, а также процессы ZhuDongFangYu, 360Safe, 360Tray.
В процессе работы с помощью GET-запроса скачиваются сертификаты server.crt, server.key, server.der, startcom.crt.
Рис. 19. Запрос на получение сертификатов
Имена классов модуля для проведения MITM-атаки не оставляют сомнений о намерениях злоумышленников (рис. 20).
Рис. 20. Имена классов модуля для проведения MITM-атаки
Заключение
Данное вредоносное ПО состоит из загрузчика, файла маскировки, руткит-драйвера и модуля для проведения атаки «человек посередине». Для скрытой доставки полезной нагрузки ПО применяет технику сращивания данных с изображениями формата JPEG. Для командных серверов злоумышленники регистрируют имена в доменных зонах top, bid, а также на базе облачных платформ.
Вот какие методы маскировки активности использовали разработчики вредоносного софта:
История одного вируса. Сорок антивирусов сочли его безвредным
Архив номеров / 2010 / Выпуск №7-8 (92-93) / История одного вируса. Сорок антивирусов сочли его безвредным
Следующим моим шагом была отправка файла для анализа в различные антивирусные лаборатории. Конечно, я не собирался это делать для всех оставшихся 39 антивирусов, поэтому решил остановиться на наиболее популярных в России разработчиках: Хотел было сюда добавить еще антивирус AVAST, но на сайте разработчика нет не только онлайн-сканера для проверки файлов, но даже возможности отправить для анализа подозрительный файл (по крайней мере я не нашел этой возможности ни в русской секции, ни в английской, ни через поиск). Там, где было возможно, перед отправкой файл был проверен онлайн-сканером на сайте разработчика, чтобы убедиться, что вирус действительно еще не определяется этим антивирусом. Не все из перечисленных выше разработчиков антивирусов предлагают на своем сайте сервис онлайн-сканирования. К таковым относятся только «Антивирус Касперского», DrWeb и Nod32. Файл на проверку был отправлен 16 июня 2010 года в промежутке между 18.00 и 19.00 по московскому времени (UTC+4) последовательно в следующие антивирусные компании. Онлайн-сканер «Лаборатории Касперского» подтвердил, что вирусов в файле нет, и я смог смело отправить файл на анализ. Пока еще это делается с главной страницы – в правом нижнем углу ссылка «Прислать вирус». Тип ссылки периодически меняется с http:// на mailto:// – я несколько раз наталкивался то на одну, то на другую версии. В первом случае ссылка ведет к открытию веб-формы (см. рис. 1), с которой также можно перейти к онлайн-сканированию; во втором случае можно просто написать письмо на адрес newvirus@kaspersky.com, приложив к письму исследуемый файл и сопроводительный текст. Последнее – не обязательно, но я всегда стараюсь так делать, искренне веря, что где-то там, «с другой стороны Интернета», это поможет людям разобраться с файлом. Спустя 5-10 минут на e-mail пришло уведомление о том, что файл принят к обработке и «будет передан вирусному аналитику». Рисунок 1. Форма для сообщения о новом вирусе на сайте «Лаборатория Касперского» Онлайн-сканер DrWeb’а [3], доступный через нижнее меню на главной странице сайта, также не обнаружил в файле ничего подозрительного. Большая зеленая кнопка «отправить файл на анализ» очень к месту располагается прямо на странице онлайн-сканера. Для отправки нужно заполнить небольшую форму (см. рис. 2), в которой надо выбрать отсылаемый файл, указать категорию запроса, оставить адрес электронной почты для связи и комментарий к отсылаемому файлу. После успешной отправки на почтовый ящик приходит уведомление о принятии файла. Рисунок 2. Форма для сообщения о новом вирусе на сайте «Доктор Веб» Почему-то многие системные администраторы не относятся серьезно к антивирусу софтверного гиганта, который, на мой взгляд, достаточно неплохо себя показывает. Зная особенности сайта Microsoft, я не решился искать форму отправки подозрительного файла на сайте, а воспользовался ссылкой из встроенной справки антивируса. Она привела меня в раздел Malware Protection Center, откуда уже несложно было найти в верхнем меню ссылку Submit a sample. По ссылке доступна простенькая форма (см. рис. 3), в которой нужно обязательно указать свое имя и отсылаемый файл, а также опционально заполнить поля адреса электронной почты, используемого продукта и комментарии. Рисунок 3. Форма для сообщения о новом вирусе на сайте Microsoft После отправки можно не закрывать страницу – она будет периодически обновляться и содержать текущую информацию о ходе исследования файла, которая также будет дублироваться и на e-mail, если его указали при отправке файла. Первое уведомление о принятии файла для анализа приходит почти сразу же после отправки. Форма для сообщения о новом вирусе – samples@eset.com. Онлайн-сканер [4] этого популярного антивируса также сообщил о том, что в проверяемом файле вирусов не обнаружено. Безрезультатно поискав на сайте ссылку для отправки файлов на анализ, я решил не бороться с интерфейсом и воспользоваться поиском. По запросу Submit a virus первая же ссылка оказалась тем, что нужно, а именно – инструкцией по отправке. Из нее следовало, что подозрительный файл нужно упаковать в RAR или ZIP-архив, закрыть его паролем infected, после чего вложить в письмо с темой suspected infection, указать в теле письма пароль от архива, опционально добавить описание и комментарии и отправить на адрес samples@eset.com. Что я и сделал. Отправить файл на анализ в Symantec можно, поместив подозрительный файл вручную в карантин (разумеется, с использованием какого-нибудь из продуктов Symantec), а затем из карантина осуществив отправку. Другой вариант – воспользоваться сайтом Symantec. И хотя онлайн-сканера там я не обнаружил, зато через поиск нашел форму для отправки подозрительных файлов (см. рис. 4). В форме обязательно требуется указать не только файл для анализа, но и фамилию/имя и дважды адрес электронной почты. Комментарий опционален. Форма защищена CAPTCHA. Рисунок 4. Форма для сообщения о новом вирусе на сайте Symantec Похоже, файл сначала автоматически проверяется в Symantec по текущей базе, так как спустя 15-20 минут мне пришло уведомление о том, что в результате автоматического сканирования в присланном файле вирусов не обнаружено, и он будет сохранен для дальнейшего анализа. Спустя еще 20 минут пришло письмо, в котором говорилось, что файл принят к обработке. Через час после отправки пришло письмо из Microsoft. Относительно исследуемого файла сообщалось следующее: Changes to detection currently undergoing testing. Я интерпретировал это как то, что это модификация известного вируса, и будет проводиться его дальнейшая проверка. Однако не буду настаивать на том, что я понял фразу правильно, важно здесь то, что вердикт Microsoft еще не окончательный, и надо ждать дальше. Следующее письмо пришло от «Доктор Веб», где сообщалось, что в результате автоматического (!) анализа в присланном файле обнаружен вирус Trojan.Winlock.1897, который будет добавлен в антивирусную базу. Итак, первый антивирус справился с задачей чуть больше, чем за час. Я не знаю принципов работы и настроек DrWeb, но наличие слова «автоматический» в ответе наводит на мысль, что в реальных условиях (а не по сервису Virustotal) данный вирус мог быть обнаружен этим антивирусом при включенном режиме эвристики. Eset хранил настоящее самурайское молчание, даже не посчитав нужным уведомить о принятии файла для анализа. Однако спустя четыре с лишним часа после отправки сообщил, что в присланном файле найден вирус Win32/LockScreen.UE trojan. Спустя восем часов после отправки файла в почте вновь отметился Microsoft, написав, что обнаруженная модификация вируса Trojan:Win32/Calelk.C будет добавлена в антивирусную базу. Оставшиеся двое испытуемых – «Лаборатория Касперского» и Symantec – не пожелали больше сообщать о себе. Это было ожидаемо от Symantec (так как имелся подобный печальный опыт ранее) и несколько неожиданно для «Лаборатории Касперского». Дело в том, что я периодически отправлял файлы для исследования в «Лабораторию Касперского» и в большинстве случаев получал ответ. Иногда ответа не было, но вирусная сигнатура появлялась в базах. Ввиду отсутствия ответа пришлось проверять обнаруживаемость вируса по Virustotal. Вот как развивались события: Чтобы выяснить время, когда антивирус «Лаборатория Касперского» обнаружил этот вирус, я зашел на сайт компании и провел онлайн-сканирование файла. Судя по базе securelist.com, время детектирования – 18 июня 2010 13.51 MSK. Напомню, что файл на анализ был прислан 16 июня 2010 в 18.11 MSK. Как и в прошлый раз, первым среагировал «Доктор Веб», сообщив мне, что присланный вирус уже есть в базе (в этот раз я не делал онлайн-проверку на сайте разработчика, полагаясь на Virustotal). Спустя восем часов после отправки Microsoft опять сообщил о том, что новая модификация вируса будет добавлена в базу. «Лаборатория Касперского» и Symantec в точности повторили прошлые результаты – прислали уведомления о принятии файла для анализа и замолчали. Спустя сутки ни тот ни другой антивирусы все еще не определяли новую модификацию вируса. Для наглядности полученные результаты представлены в таблице 1. Таблица 1. Время обнаружения нового вируса разработчиками антивирусов
Мы видим достаточно оперативную реакцию у первых трех разработчиков, довольно вялую у «Лаборатория Касперского» и просто наплевательское отношение у Symantec. «Лаборатория Касперского» удивила не столько большим временем добавления вируса в базу, сколько тишиной в ответ на отправку файла для анализа. На форуме журнала в разделе «Антивирусы» в одной из веток [5] модератор пишет (орфография сохранена): «Отправляйте недетектящееся [вирусы] в вирлаб используемого антивируса. Этим Вы помогаете не только себе. И пользователи, которые так поступают, помогают не только антивирусным компаниям». Однако при этом хочется получить хоть какой-то ответ от самой антивирусной компании, чтобы знать, что твои усилия не пропали зря. Откуда берут образцы новых вирусов антивирусные компании, которые не содержат на своем сайте возможности получить подозрительные файлы на анализ от пользователей – это еще один любопытный вопрос. Судя по статистике на сайте «Лаборатория Касперского» [6], ежедневно для анализа им присылают десятки тысяч подозрительных файлов. Конечно, я думаю, это не единственный источник информации о новых вирусах. Но все-таки отсутствие такой возможности заставляет более серьезно относиться к слухам о том, что некоторые разработчики антивирусов якобы заимствуют сигнатуры вирусов из баз конкурентов. Не секрет, что в битве вирусов и антивирусов последние всегда чуть-чуть позади, так зачем еще и отворачиваться от потенциальных союзников?
|