Вирус который записывает свой код в главную загрузочную запись master boot record диска это
Знаете ли вы, что есть вирусы, которые, даже если вы отформатируете компьютер, все равно останутся на вашем компьютере? Иногда они оседают в MBR (Главная загрузочная запись) вашего жесткого диска, или будучи "руткитов"застрял в одном из разделов жесткого диска!
Удалить "Руткит"было бы непросто даже при использовании самого лучшего антивируса (Касперский, Avast Free, . ) ! Потому что "Руткит может быть установлен в другом программном обеспечении, библиотеке или ядре операционной системы." (Wikipedia).
Как Троянская MBR"руткит делает системные ресурсы доступными на одной или даже нескольких машинах, иногда используя «цель» в качестве посредника для другой атаки; либо шпион, доступ к данным, хранящимся или передаваемым на целевой машине"(Википедия).
В этом руководстве вы узнаете, как удалить с вашего компьютера вирусы и трояны, застрявшие в MBR, и «руткиты» с помощью некоторых бесплатных программ!
Примечание: . Руткиты может сделать ваш компьютер очень медленным, поэтому, если ваш компьютер работает медленно даже после оптимизации и сканирования, это руководство также поможет вам!
Как избавиться от вирусов после форматирования:
2. Просканируйте вашу систему на наличие вредоносных руткитов с помощью GMER:
После загрузки откройте приложение, дважды щелкнув исполняемый файл.
Убедитесь, что вы проверили все пункты в списке справа для полного сканирования, проверьте буквы жестких дисков (рекомендуется все буквы поставить галочкой) для полного сканирования!
Нажмите на кнопку "Scan"чтобы начать сканирование немедленно!
Если программа сообщает вам, что обнаружила системные изменения, выполните полное сканирование еще раз, нажав "Да".
После завершения сканирования вы можете просмотреть более подробную информацию, нажав на значок ">>>".
Перемещайтесь между вкладками и посмотрите, есть ли красные линии, обозначающие наличие Руткиты в твоей машине!
Примечание: Не удаляйте файлы, отмеченные красным цветом, это могут быть системные файлы или руткиты для антивируса, установленного на вашем компьютере!
Удалить их Руткиты и перезагрузите компьютер!
Я здесь, чтобы ответить на ваши вопросы, не стесняйтесь их задавать
В последнее время в Интернете получил массовое распространение ранее неизвестный червь — Win32/Zimuse, нацеленный на повреждение главной загрузочной записи MBR (Master Boot Record) на жестком диске.
Примечательно то, что данная угроза изначально была в шутку создана для заражения одного небольшого сообщества словацких байкеров. Возможно, это были происки конкурирующего с ними мотоклуба. Однако сегодня червь уже вышел из-под контроля его авторов и активно распространяется по всему миру. При этом 90% всех инфицированных пользователей сначала находились на территории Словакии. Но теперь по количеству заражений лидируют также США, Таиланд и Испания, с небольшим отставанием Италия, Чехия и другие европейские страны.
Win32/Zimuse повреждает главную загрузочную запись MBR на всех обнаруженных им жестких дисках. Это делает недоступными для пользователя все данные, находящиеся на жестком диске.
Червь распространяется двумя способами: в виде приложения на вполне легальных веб-ресурсах, которое имитирует поведение самораспаковывающегося zip-архива или в виде программы IQ-теста, а также на сменных USB-носителях. Именно второй способ повлиял на быстрый рост его распространения.
После запуска программ IQ-тест пользователи могут наблюдать текстовое послание на чешском языке, что еще раз подтверждает происходение этого червя из Восточной Европы.
На сегодняшний день червь известен в двух вариантах — Win32/Zimuse.A и Win32/Zimuse.B. Они отличаются методом распространения и временем активации. Варианту «А» необходимо 10 дней до начала распространения через USB-устройства, второму — лишь 7 дней с момента заражения.
Подобного рода инцидент уже был ранее известен с вирусом OneHalf, который наделал много шума в середине девяностых. В то время многие антивирусные программы были бессильны перед данной угрозой. OneHalf заражал MBR и шифровал пользовательские данные. Многие варианты лечения этого вируса приводили к повреждению загрузочного сектора и потере данных. В процессе расследования и поиска авторов OneHalf большинство фактов указывало на то, что его распространение началось именно в Словакии и, вероятнее всего, автор был тоже оттуда.
Пользователи антивирусных продуктов ESET NOD32 Antivirus и ESET NOD32 Smart Security защищены от угрозы Win32/Zimuse, а для всех остальных компания ESET разработала специальную утилиту, которая позволяет избавиться от червя Zimuse Removal Tool.
В последние несколько лет увеличилось распространение вредоносных программ (буткитов), модифицирующих загрузочные сектора в процессе заражения системы. Среди самых видных представителей — TDL4, Olmasco и Rovnix. Каждый из них использует различные способы заражения жесткого диска, это либо модификация главной загрузочной записи (MBR), либо модификация первых секторов загрузочного раздела, т. е. VBR или IPL (первые сектора тома, куда передается управление из MBR — Volume Boot Record/Initial Program Loader). Наглядно эти семейства показаны на рисунке ниже.
Рис. 1. Схема различных семейств буткитов и методов заражения диска.
Существует несколько причин использования буткитов в современных угрозах:
● Возможность запуска вредоносного кода раньше кода ОС, что дает неоспоримые преимущества и позволяет контролировать процесс загрузки ОС.
● Как следствие первого пункта, позволяет обходить систему мониторинга целостности ключевых компонентов ядра — PatchGuard (практически единственный способ обеспечить выживаемость руткита в x64-среде).
● Возможность глубоко скрывать свой код и, таким образом, делать его невидимым для AV-сканеров.
● Буткит имеет посекторную архитектуру хранения своего тела на диске, что дает возможность выносить свой вредоносный код и код полезной нагрузки далеко за пределы файловой системы и даже разделов диска, делая почти невозможным его обнаружение.
● Безопасная установка руткита в системе.
В отчете ESET по угрозам и трендам за 2012 г., мы указали, что буткиты являются одним из ключевых технических трендов прошедшего года. Наши эксперты отслеживают появление новых сложных угроз. Мы также не обошли стороной и Win32/Gapz, так как он содержит ряд технических особенностей, которые делают его действительно интересным. Александр Матросов и Евгений Родионов проделали большую работу, занимаясь анализом этого буткита. Сегодняшний наш пост посвящен этому анализу.
Начнем с дроппера — компонента, который является изначальным носителем кода буткита и отвечает за его установку в системе. Мы детектируем его как: Win32/Gapz.X, X-версия. Мы обнаружили три его версии, A, B и C. Ниже в таблице приведены их характеристики:
Рис. 2.
В соответствии с нашими наблюдениями, первая известная версия дроппера была скомпилирована в апреле прошлого года и содержала много отладочной информации, т. е. не подразумевалась для массового распространения. Вполне вероятно, что Win32/Gapz начали массово распространять в конце лета или начале сентября прошедшего года. Для поднятия своих привилегий в системе Win32/Gapz использует LPE-эксплойты и COM Elevation метод.
В процессе анализа мы обнаружили, что заражению Win32/Gapz подвержены: 32-битные Windows XP SP2 и выше (исключая Windows Vista и Vista SP1) и 64-битные Windows XP SP2 и выше. Обсуждаемая версия дроппера Win32/Gapz способна заражать Windows XP и Windows 7, включая x64 версии, однако на Windows 8 буткит-часть не работает должным образом и после заражения часть, надлежащая к исполнению в режиме ядра, не исполнялась.
Рис. 3. Часть кода дроппера, проверяющая версию ОС.
Дроппер, устанавливающий буткит в систему, тщательно продуман и способен обойти современные проактивные защиты (HIPS), а также поднимать свои привилегии до уровня системы. Кроме того, он содержит хитрый метод внедрения кода в адресное пространство процесса. Файл дроппера экспортирует из себя несколько функций, которые указаны ниже на рисунке.
Рис. 4. Функции, экспортируемые исполняемым файлом дроппера.
Есть три экспортируемые функции, на которые следует обратить внимание: start, icmnf и isyspf. Краткое описание:
● start — точка входа в дроппер, осуществляет его внедрение в адресное пространство доверенного процесса explorer.exe;
● icmnf — отвечает за повышение (эскалацию) привилегий;
● isyspf — выполняет заражение жертвы кодом буткита.
Код дроппера использует специальную секцию, которая спроецирована в адресное пространство процесса explorer. Через эту секцию он загружает шелл-код в этот процесс и далее, с помощью специально сформированного API-вызова, производит его активацию. Соответственно, после того, как шелл-код активирован, он подгружает образ дроппера в адресное пространство процесса explorer, вызывает функцию повышения привилегий и инициирует процедуру заражения кодом буткита, записывая его на диск.
Рис. 5. Стадии выполнения дроппера и заражения жертвы кодом буткита.
После того, как дроппер заразил систему буткитом, его задача исполнена, и он удаляет свой файл с диска.
Вредоносный код MBR
Мы обнаружили две модификации буткита Win32/Gapz, которые различаются методами заражения диска жертвы. Самая ранняя модификация появилась в начале лета 2012 г., эта версия была нацелена на заражение MBR. Другая, более поздняя модификация, которая заражает VBR, была замечена в конце осени 2012 г.
Рис. 6. Две модификации Win32/Gapz, нацеленные на заражения MBR и VBR.
Давайте рассмотрим более раннюю модификацию буткита, которая нацелена на заражение MBR, подробнее. В этом случае, код буткита можно разбить на несколько частей:
● вредоносный MBR;
● код режима ядра и полезная нагрузка, внедряемая в процессы.
Вредоносный код сохраняет свой код режима ядра и полезную нагрузку либо перед самым первым разделом, либо после последнего раздела на жестком диске. Такой подход очень похож на тот, который использовался в бутките Rovnix, за исключением того, что Rovnix заражает VBR.
Что касается буткит части Win32/Gapz, то в ней нет ничего необычного: как только код из вредоносного MBR исполнился, он восстанавливает оригинальный код в памяти и читает следующие секторы жесткого диска, содержащие код для последующего исполнения, на который и передается управление. Код буткита перехватывает обработчик прерывания 0x13, int 13h и отслеживает, таким образом, загрузку ниже перечисленных модулей ОС для установки туда перехватов:
● ntldr (на системах до Windows Vista)
● bootmgr (на системах Vista+)
● winload.exe (на системах Vista+)
Код буткита идентифицирует каждый из вышеперечисленных модулей, используя специальные последовательности байт. Ниже перечислен список функций, которые буткит перехватывает в этих модулях:
Как только вредоносный код обнаруживает, что конкретный модуль читается с жесткого диска, он модифицирует его таким образом, чтобы вернуть себе контроль после того, как процессор переключится в защищенный режим. Буткит устанавливает перехваты на загрузчик ядра ОС: это либо ntldr в устаревших системах до Windows Vista, либо bootmgr в Vista и выше. В случае с bootmgr, он также перехватывает функцию OslArchTransferToKernel в winload.exe.
Рис. 7. Перехватчик функции OslArchTransferToKernel в winload.exe.
Следующий этап, это установка перехвата на функцию IoInitSystem, которая вызывается в процессе инициализации ОС. Она перехватывается вредоносным кодом либо из ntldr, либо из winload.exe, в зависимости от версии ОС.
Рис. 8. Код перехвата, устанавливаемого на функцию IoInitSystem.
После того, как вредоносный код из IoInitSystem был исполнен, буткит восстанавливает модифицированные байты в образе ядра ntoskrnl и передает управление оригинальной IoInitSystem. Перед передачей управления оригинальному коду, буткит перезаписывает адрес возврата в стеке на свою функцию, которая, соответственно, будет исполнена по завершении исполнения IoInitSystem. С помощью такого трюка вредоносный код получает управление после того, как ядро ОС будет инициализировано. Далее вредоносный код считывает остальную свою часть с жесткого диска и создает отдельный системный поток, который исполняет эти инструкции и в завершении возвращает управление ядру. В этой части буткита, которая исполняется в режиме ядра, реализуется руткит-функционал, внедрение полезной нагрузки в процессы и взаимодействие с C&C сервером.
Вредоносный код VBR
Как мы уже упоминали, последняя модификация Win32/Gapz заражает VBR тома, который помечен как активный в MBR (Volume Boot Record — первые сектора тома, в которых прописана служебная информация, а также VBR-код, на который передается управление из MBR и который отвечает за дальнейшую загрузку ОС). Буткит использует оригинальный подход для заражения VBR с последующей передачей управления своему коду. Для того чтобы быть более скрытным и незаметным, он модифицирует только несколько байт оригинальной VBR. Суть такого подхода заключается в том, что он модифицирует значение поля «Hidden Sectors» в поле служебной структуры VBR, при этом оставляя код VBR и код IPL нетронутым! IPL, Initial Program Loader — код, на который передается управление после исполнения кода VBR, он отвечает за поиск загрузчика в рамках файловой системы тома и передает на него управление. В состав VBR включены следующие части:
● Bootstrap-код (VBR-код), отвечающий за загрузку IPL.
● BIOS Parameter Block (BPB) — структура данных, хранящая блок параметров NTFS.
● Текстовые строки, отображаемые пользователю в случае ошибки.
● 0xAA55 — стандартная двухбайтовая сигнатура, маркер служебного сектора.
Рис. 9. Схема первого сектора VBR.
В случае с Win32/Gapz, наиболее интересным местом для анализа является BPB и особенно поле «Hidden Sectors». Это поле содержит количество секторов, предшествующих IPL (т. е. смещение до IPL в секторах, с помощью которого код из VBR определяет, куда передавать управление далее) и хранящихся на NTFS-томе, как показано ниже.
Рис. 10. Структура NTFS-тома.
Таким образом, в процессе загрузки на чистой системе, VBR-код считывает 15 секторов, начиная со смещения, указанного в «Hidden Sectors», и передает туда управление. Этим и пользуется буткит для передачи управления на себя. Он перезаписывает это значение, указывая смещение в секторах до своего вредоносного кода, хранящегося на диске. После заражения том выглядит так:
Рис. 11. Модифицированное буткитом значение «Hidden Sectors» приводит к тому, что код VBR передает управление на код буткита, а не на IPL.
В случае заражения системы, VBR-код вызывает на исполнение код буткита вместо легального IPL. Код буткита, как уже упоминалось, записывается либо перед самым первым разделом диска, либо после последнего. В остальном код буткита, по существу, ничем не отличается от версии с MBR-инфектором.
Вредоносный код режима ядра
Основное предназначение непосредственно той части, которая и называется буткитом, описанной выше, заключается в загрузке вредоносного кода режима ядра или руткита в системное адресное пространство, обходя ограничения, накладываемые ОС для такого привилегированного кода. Мы уже упоминали, что этот загружаемый буткитом код, содержит в себе руткит для скрытия своего присутствия, механизм работы с управляющим сервером C&C, а также полезную нагрузку (payload), которая предназначена для внедрения в процессы.
В отличие от Rovnix, TDL4 и других распространенных буткитов, вредоносный код режима ядра в Win32/Gapz не имеет структуры исполняемого PE-файла. Вместо этого он структурирован особым образом. Код состоит из 12 объединенных между собой блоков, каждый из которых имеет заголовок — структуру, которая хранит служебную информацию о нем. Она имеет следующий вид:
Каждый из блоков реализует определенный функционал: внедрение полезной нагрузки, взаимодействие с C&C серверами, самозащиту и так далее. Функционал кода режима ядра является достаточно сложным и может быть рассмотрен отдельно (выходит за рамки этого поста).
Bootkits vs. Microsoft ELAM
В этой части нашего поста мы хотим остановиться на специальном средстве, которое Microsoft решили использовать для борьбы с различного рода угрозами, особенно, руткитами и буткитами, которые пытаются загрузить себя раньше других драйверов в системе. Средство называется ELAM, Early Launch Anti-Malware Module и поставляется в составе ОС, начиная с Windows 8. По сути ELAM – это драйвер, предоставляемый антивирусным вендором, которому гарантирован приоритет при загрузке драйверов режима ядра. С точки зрения же ядра ОС, ELAM представляет собой API для антивирусных драйверов, а также набор правил, которых такому драйверу следует придерживаться. Одна из главных возможностей этого средства заключается в том, что он гарантированно позволяет AV-драйверу загружаться раньше остальных драйверов в системе и, таким образом, выходить за рамки обычных правил автозагрузки, регламентируемых для остальных драйверов.
Мы отмечаем, что ELAM сам по себе не может быть так эффективен для борьбы с буткитами, поскольку это часть ядра ОС, а буткит получает управление гораздо раньше.
Рис. 12. Мы видим, что буткит может компрометировать систему с активным ELAM, делая его бесполезным инструментом. Поскольку буткит загружается раньше инициализации ОС, он будет уже находиться в памяти на тот момент, когда ELAM получит управление.
В то же время, следует отметить, что ELAM является частью декларируемой Microsoft концепции или схемы «Безопасной загрузки» — Secure Boot. В случае с Secure Boot, программное обеспечение, встроенное в UEFI (такое ПО получает управление как только компьютер начал свою работу) может контролировать целостность и легитимность кода, на который передается управление в процессе выполнения кода, предшествующего выполнению основного кода ОС. Концепция Secure Boot, совместно с новым стандартом UEFI, призвана предотвратить компрометацию критичных структур данных ОС/UEFI со стороны буткитов.
Ситуация следующая. Есть винт на 160Гб. На нем 2 раздела — 40Гб и 120Гб. С целью установки убунты как второй системы была произведена разбивка 120Гб -> 100+10+2+8.
Далее, с целью отката изменений, были объединены диски (10, 2 и 8) обратно в один 20Гб и отформатирован в NTFS. В нагрузку к этому, были проведены операции с MBR, результатом которой явилась ее смерть.
Итоги
Дураку понятно, что это начало веселой ночи.
Далее, под катом, решения вопроса.
1. Восстановление таблицы разделов
1.1. Parted magic
Данный LiveCD\USB дистрибутив, размером в 100Мб несет в себе огромную кучу софта, для работы с дисками. От разбивки, до восстановления.
Из них всех, нам нужны будут gpart, testdisk, fdisk и ms-sys.
1.2. Gpart
gpart — это утилита, сканирующая по-секторно диск на наличие разделов, которые присутствуют на носителе, но отсутствуют в таблице. В своей работе, она игнорирует уже существующую таблицу (если присутствует). Программа разаботана немецким программистом Michail Brzitwa и больше им не поддерживается. Вялотекущая разработка ведется командами Fedora и Debian. Текущая версия — 0.1h.
Утилита позволяет наиболее быстро и легко восстановить таблицу разделов, но она несет в себе несколько недостатков. Во-первых, разработка была давно заброшена, во-вторых, она иногда не совсем корректно определяет разделы.
gpart может работать в 2-х режимах. Это быстрый анализ и подробное сканирование. В некоторых случаях, первого режима достаточно. Мы же будем смотреть на второй.
gpart -if /dev/sda
-i — интерактивный режим. На каждую найденную партицию будет задан вопрос, сохранять ее, либо пропустить.
-f — полный скан диска.
После, довольно продолжительного времени, будет создан отчет с возможными разделами. Его-то и нужно обязательно максимально внимательно просмотреть перед записью.
Пример отчета (не мой):
Если все ОК, то соглашаемся на запись в таблицу разделов, скрещиваем пальцы и перезагружаемся.
В моем случае, программа определила разделы, которые были до разбивки (40 и 120), что не подходило и заставило искать альтернативные способы восстановления.
1.3. testdisk
Note: подробнее эта утилита описана в этом посте, здесь не буду повторяться.
Эта утилита аналогична предыдущей, но имеет ряд плюсов:
1. более свежая и активно поддерживается;
2. субъективно, работает намного быстрее;
3. функциональнее;
4. есть простой консольный интерфейс на базе ncurses.
Поехали!
1. в первом окне выбираем Create a new log file;
2. выбираем нужный диск (/dev/sda) -> Proceed;
3. отмечаем тип разделов как Intel;
4. выбираем Analyse current partition structure and search for lost partitions;
5. если найденные разделы верны, жмем Backup и переходим к пункту 6, есть возможность быстро пересканировать диск, если где-то ошибка (Quick search);
6. здесь уже виден зеленый список с разделами. Если ок, то записываем, иначе запускаем Deep search.;
В моем случае, результат был аналогичен результату gpart, что есть некорректен.
Запустив Deep search, выждав около 40 минут я получил ответ, от которого на душе так нехило отлегло.
Было найдено несколько партиций, которые накладывались одна на другую (это были изначальная (до манипуляций) 120Гб и новая, на 100Гб). Отметив ненужную, как удаленную, я записал таблицу на диск и перезагрузился. К счастью, все обошлось и компьютер вернулся к состоянию, который был изначально, а я мог с чистой совестью лечь спать.
3. Восстановление MBR
Для этой задачи, у нас в арсенале есть тулза ms-sys.
Сперва узнаем, что с нашей MBR.
ms-sys /dev/sda
/dev/sda has an x86 boot sector
it is unknown boot sector
Теперь видно, что на данном диске нет загрузочного сектора.
Утилита может работать с MBR различных операционных систем. Список можно получить, запустив программу без агрументов. В моем случае, необходим был от Windows 7.
Записываем MBR на диск:
ms-sys -7 /dev/sda
Windows 7 master boot record successfully written to /dev/sda
Проверяем:
ms-sys /dev/sda
it is Microsof 7 master boot record, like the one this
program creates with the switch -7 on a hard disk device.
Вот и все, нужная MBR установлена и можно перезагружаться.
3. Outro
Этот пост пример того, как на пустом месте можно создать себе проблему и полночи заниматься не тем, чем надо. Но это дало неоценимый опыт, который я постарался изложить здесь.
Возможно, кому-нибудь он пригодится. Ведь в такую ситуацию попасть очень не сложно, а детального мануала особо-то и нет.
Тишина. Компьютер не работает. Хозяева периодически бросают на него печальный взгляд и вздыхают. Мальчик Миша, десяти лет, сообщает о том, что надо заплатить деньги какому-то абоненту МТС, чтобы он включил им компьютер. Печально. А я все-таки попробую сделать это бесплатно. Нажимаю кнопку питания с мыслью, что и сам бы не отказался от вкусного ужина, но, наверное, опять все сделаю быстро, так что вряд ли успеют накормить.
Потребуется загрузочный диск. Вирус в нулевом секторе жесткого диска получает управление после того, как BIOS (Basic Input/Output System, ну я прям сегодня как википедия!) проверяет установленный порядок загрузки с обнаруженных устройств. Значит, загрузка с CD вирусом отключена быть не может, если только он не прописался в саму BIOS, что большая редкость в последнее время. Достаю диск с ERD Commander, загружаюсь с него и сразу жму кнопку, исправляющую ошибки в MBR. Диск больше не нужен. Windows запускается, абонент МТС денег не просит.
Переходим к плановому осмотру. Process Explorer вместо стандартного диспетчера задач должен показать нам всех местных жителей с паспортными данными и адресами прописки. На первый взгляд - ничего лишнего. Но под подозрение натренированного взгляда попадают два процесса svchost.exe, запущенные из-под explorer.exe со странной командной строкой: "-k netsvcs". Во-первых, svchost должен запускаться из-под services.exe, а во-вторых, в командной строке должно быть указано еще и имя самого процесса, т.е. "svchost.exe -k netsvc". Вирусописатели оказались не внимательными к деталям, забыли плащ-невидимку накинуть на голову.
В скрипт для AVZ вписал всех нарушителей, выполнил. Вирус в MBR оказался обычным алчным вымогателем, драйвер с постоянно меняющейся внешностью и фамилией путем перехвата системных функций операционной системы пытался обмануть пользователя, неумело маскируя имена своих процессов под svchost.exe. И браузеры теперь загружаются нормально даже без помощи Администратора. Победа накануне Дня Победы, а праздничным ужином так и не накормили.
Тишина. Компьютер не работает. Хозяева периодически бросают на него печальный взгляд и вздыхают. Мальчик Миша, десяти лет, сообщает о том, что надо заплатить деньги какому-то абоненту МТС, чтобы он включил им компьютер. Печально. А я все-таки попробую сделать это бесплатно. Нажимаю кнопку питания с мыслью, что и сам бы не отказался от вкусного ужина, но, наверное, опять все сделаю быстро, так что вряд ли успеют накормить.
Потребуется загрузочный диск. Вирус в нулевом секторе жесткого диска получает управление после того, как BIOS (Basic Input/Output System, ну я прям сегодня как википедия!) проверяет установленный порядок загрузки с обнаруженных устройств. Значит, загрузка с CD вирусом отключена быть не может, если только он не прописался в саму BIOS, что большая редкость в последнее время. Достаю диск с ERD Commander, загружаюсь с него и сразу жму кнопку, исправляющую ошибки в MBR. Диск больше не нужен. Windows запускается, абонент МТС денег не просит.
Переходим к плановому осмотру. Process Explorer вместо стандартного диспетчера задач должен показать нам всех местных жителей с паспортными данными и адресами прописки. На первый взгляд - ничего лишнего. Но под подозрение натренированного взгляда попадают два процесса svchost.exe, запущенные из-под explorer.exe со странной командной строкой: "-k netsvcs". Во-первых, svchost.exe должен запускаться из-под services.exe, как я уже об этом писал, а во-вторых, в командной строке должно быть указано еще и имя самого процесса, т.е. "svchost.exe -k netsvc". Вирусописатели оказались не внимательными к деталям, забыли под плащ-невидимку спрятать плащ-палатку.
В скрипт для AVZ вписал всех нарушителей, выполнил. Вирус в MBR оказался обычным алчным вымогателем, драйвер с постоянно меняющейся внешностью и фамилией путем перехвата системных функций операционной системы пытался обмануть пользователя, неумело маскируя имена своих процессов под svchost.exe. И браузеры теперь загружаются нормально даже без помощи Администратора. Победа накануне Дня Победы, а праздничным ужином так и не накормили.
1. Очистите MBR с помощью aswMBR:
Когда загрузка завершится, дважды щелкните файл . EXE залить программу lancer le.
Оставьте выбор типа сканирования »Быстрое сканирование"и нажмите кнопку"Scan", чтобы начать сканирование.
Программа выделит вредоносные файлы красным цветом, затем нажмите кнопку "Fixmbr".
Подтвердите, нажав "да".
Закройте программу, нажав "Выход"!
А теперь перейдем ко второй части этого урока!
Читайте также: