gjf
Ассоциация VN
- Сообщения
- 641
- Реакции
- 603
Думаю, большинству не будет секретом механизм работы существующих файловых инфекторов типа Sality и Virut. Безусловно, суть работы таких инфекторов хорошо описана, а потому разработать новую версию легко, отладка её не вызывает проблем. Куда более интересным будет описание нового механизма - заражения файла из загрузчика в MBR. Во-первых, такой вредонос должен быть более сложным, имеется ограничение по длине кода - 62 сектора (7C00H), а кроме того предъявляются особые требования к отсутствию багов - малейшая ошибка может привести к сбою загрузки системы.
Единственным уникальным на данный момент примером такого вредоноса является Trojan:W32/Smitnyl.A, распространяемый по некоторым файлообменым сетям. Его мы и рассмотрим сегодня.
Инфектор Smitnyl.A при запуске заражает MBR через прямой доступ к диску. Он заменяет оригинальную MBR вредоносным вариантом, содержащим в секторе 32 процедуру файлового инфектора.
Рисунки 1 и 2: Перезапись оригинальной MBR, Часть 1 (верх) и 2 (низ)
Почему же автор выбрал такой непростой способ инфицирования исполняемого файла? Вероятно потому, что такой способ позволяет обойти систему защиты файлов Windows (WFP), что позволяет эффективно заражать системные файлы без опасности, что они будут впоследствии восстановлены WFP.
Оригинальная MBR сохраняется в секторе 5, в то время как процедура инфектора размером A00H располагается в секторе 39. Цель инфектора - критичный системный файл userinit.exe.
Рисунки 3: Код вредоносной MBR
Рисунки 4: Код оригинальной MBR
Рисунок 5: Код инфектора в MBR
Рисунок 6: Вредоносный код, внедряемый в userinit.exe
Почему же целью заражения выбран userinit.exe? Вероятно, это сделано по той причине, что userinit.exe - один из первых процессов, стартующих при загрузке системы, что позволяет вредоносу запускаться на ранней стадии, до загрузки ряда файерволов и антивирусов, эффективно выполняя свой функционал. Специалисты могут возразить, что ещё более ранними являются smss.exe, csrss.exe. Что же, возможно столь ранняя загрузка неудобна по причине отсутствия каких-то критичных процессов для вредоноса.
Smitnyl заражает userinit.exe на этапе ранней загрузки системы, когда выполнение кода MBR доходит до 0x7C00, определяется активный раздел из таблицы разделов и смещение стартовой области загрузочного сектора.
Затем производится проверка типа файловой системы.
Рисунок 7: Определение типа загрузочного сектора
В случае, если обнаружена система NTFS, код парсит Master File Table (MFT) и считывает аттрибуты файловой записи $ROOT (.) для нахождения аттрибута $INDEX_ALLOCATION. Эта процедура позволяет найти размещение userint.exe на диске(при условии корректного парсинга MFT). Smitnyl проверяет все пути, начиная от $ROOT до папки System32, где располагается userinit.exe.
Рисунок 8: Обнаружение Userinit.exe, часть 1
Рисунок 9: Обнаружение Userinit.exe, часть 1
Вредонос использует процедуру get_userinit_data_content_addr для нахождения файла userinit.exe, которая затем использует Extended Write Function (номер функции ah=43H) для записи вредоносного содержимого, исходно размещённого в секторе 39. В ходе заражения userinit.exe вредонос также проверят наличие маркера в файле по смещению 0x28. зачем это нужно - будет разъяснено ниже.
Рисунок 10: Обнаружение Userinit.exe, часть 2
Рисунок 11: Обнаружение Userinit.exe, часть 2
В результате загрузки инфицированной машины userinit.exe заражается и затем запускается (уже непосредственно ОС). Одним из способов обнаружения заражения userinit.exe является элементарный просмотр свойств файла.
Рисунки 12 и 13: Свойства userinit.exe, оригинального (выше) и инфицированного (ниже)
К счастью, разницы весьма очевидна.
Давайте теперь посмотрим код заражённого файла.
Рисунок 14: Заражённый Userinit.exe
Тут становится понятным, почему инфектор при заражении искал маркер 0x55AA перед осуществлением инфицирования - это предотвращение повторного заражения. Так что же происходит при запуске заражённого файла? Основная цель - запуск криптованного вредоносного кода, расположенного в секторе 45.
Рисунок 15: Криптованный исполняемый код в секторе 45
Код имеет ряд предварительных процедур, предшествующих декодированию и старту основного функционала.
• Проверка наличия системы защиты интернет 360safe. Если таковая находится - то её отключают.
Рисунок 16: Проверка наличия системы 360safe
• Создание подменного explorer.exe во временной папке - это декодированный исполняемый код.
Рисунок 17: Подменный Explorer.exe
Рисунок 18: Подменный Explorer.exe
• После декодирования, производится запуск %temp%\explorer.exe посредством ShellExecute — userinit.exe выполняет абсолютно аналогичную операцию с оригинальным explorer.exe! Одновременно, производится запуск оригинального explorer.exe посредством Winexec.
Рисунок 19: Выполнение подменного explorer.exe и оригинального explorer.exe
После этого выполняется основной функционал вредоноса - это классический даунлодер, загружающий и выполняющий файлы.
Рисунок 20: Функционал даунлоадера
В итого, благодаря отключению защиты 360safe становится возможным эффективная загрузка и выполнение файлов с удалённого сервера http://[...].perfectexe.com/ и др.
Теперь - о лечении этого вредоноса. Итак, наша система подготовлена и заражена дроппером Smitnyl.A (размер 37 076 байт, MD5 A6E5BAAEAB6C506CB5A08755B025F6A5). После заражения дроппер (как любой уважающий себя дроппер) самоликвидировался, больше никаких модификаций в системе не произошло, за исключением изменения MBR (оригинальная, заражённая). Подчеркну: на данном этапе userinit.exe заражён не был.
А произошло это заражение после перезагрузки системы, когда сразу начал обнаруживаться вредоносный функционал:
Как и обещалось - вредонос работает как даунлоадер и в нашем случае он скачивает свою бэкдор-компоненту.
И вот дальше обнаруживается интересное. На самом деле, фэйковый explorer.exe выполняется единожды при загрузке, скачивает в корень системного диска и запускает контент, после чего выгружается и самоуничтожается:
В итого в системе есть бэкдор, однако ничто не указывает на его источник - Smitnyl.A! Cканирование AVZ системы обнаруживает наличие модуля бэкдора, запущенного как служба, позволяет его удалить, однако новая перезагрузка всё вернёт на свои места:
Обнаружить признак Smirnyl.A можно только если внимательно рассмотреть следующую часть лога:
Тут становится понятно: система не распознала заражённый userinit.exe по базе CRC, а потому вывела её с подозрением (система также не распознала и cmd.exe - но это верно: я сам подменил этот файл для журналирования операций в шелле).
Итак, каково же было лечение?
1. Поскольку userinit.exe при активной системе не задействован, его просто перезаписываем оригинальным файлом из дистрибутива или незаражённой системы.
2. Если на данном этапе провести перезагрузку - userinit.exe будет опять заражён. Поэтому производим восстановление MBRFix, однако это не значит, что не сработают другие варианты.
3. Производим стандартное лечение с помощью скрипта AVZ:
(Скрипт может меняться в зависимости от того, что закачает и запустит даунлоадер).
После перезагрузки система была полностью очищена.
Единственным уникальным на данный момент примером такого вредоноса является Trojan:W32/Smitnyl.A, распространяемый по некоторым файлообменым сетям. Его мы и рассмотрим сегодня.
Инфектор Smitnyl.A при запуске заражает MBR через прямой доступ к диску. Он заменяет оригинальную MBR вредоносным вариантом, содержащим в секторе 32 процедуру файлового инфектора.
Рисунки 1 и 2: Перезапись оригинальной MBR, Часть 1 (верх) и 2 (низ)
Почему же автор выбрал такой непростой способ инфицирования исполняемого файла? Вероятно потому, что такой способ позволяет обойти систему защиты файлов Windows (WFP), что позволяет эффективно заражать системные файлы без опасности, что они будут впоследствии восстановлены WFP.
Оригинальная MBR сохраняется в секторе 5, в то время как процедура инфектора размером A00H располагается в секторе 39. Цель инфектора - критичный системный файл userinit.exe.
Рисунки 3: Код вредоносной MBR
Рисунки 4: Код оригинальной MBR
Рисунок 5: Код инфектора в MBR
Рисунок 6: Вредоносный код, внедряемый в userinit.exe
Почему же целью заражения выбран userinit.exe? Вероятно, это сделано по той причине, что userinit.exe - один из первых процессов, стартующих при загрузке системы, что позволяет вредоносу запускаться на ранней стадии, до загрузки ряда файерволов и антивирусов, эффективно выполняя свой функционал. Специалисты могут возразить, что ещё более ранними являются smss.exe, csrss.exe. Что же, возможно столь ранняя загрузка неудобна по причине отсутствия каких-то критичных процессов для вредоноса.
Smitnyl заражает userinit.exe на этапе ранней загрузки системы, когда выполнение кода MBR доходит до 0x7C00, определяется активный раздел из таблицы разделов и смещение стартовой области загрузочного сектора.
Затем производится проверка типа файловой системы.
Рисунок 7: Определение типа загрузочного сектора
В случае, если обнаружена система NTFS, код парсит Master File Table (MFT) и считывает аттрибуты файловой записи $ROOT (.) для нахождения аттрибута $INDEX_ALLOCATION. Эта процедура позволяет найти размещение userint.exe на диске(при условии корректного парсинга MFT). Smitnyl проверяет все пути, начиная от $ROOT до папки System32, где располагается userinit.exe.
Рисунок 8: Обнаружение Userinit.exe, часть 1
Рисунок 9: Обнаружение Userinit.exe, часть 1
Вредонос использует процедуру get_userinit_data_content_addr для нахождения файла userinit.exe, которая затем использует Extended Write Function (номер функции ah=43H) для записи вредоносного содержимого, исходно размещённого в секторе 39. В ходе заражения userinit.exe вредонос также проверят наличие маркера в файле по смещению 0x28. зачем это нужно - будет разъяснено ниже.
Рисунок 10: Обнаружение Userinit.exe, часть 2
Рисунок 11: Обнаружение Userinit.exe, часть 2
В результате загрузки инфицированной машины userinit.exe заражается и затем запускается (уже непосредственно ОС). Одним из способов обнаружения заражения userinit.exe является элементарный просмотр свойств файла.
Рисунки 12 и 13: Свойства userinit.exe, оригинального (выше) и инфицированного (ниже)
К счастью, разницы весьма очевидна.
Давайте теперь посмотрим код заражённого файла.
Рисунок 14: Заражённый Userinit.exe
Тут становится понятным, почему инфектор при заражении искал маркер 0x55AA перед осуществлением инфицирования - это предотвращение повторного заражения. Так что же происходит при запуске заражённого файла? Основная цель - запуск криптованного вредоносного кода, расположенного в секторе 45.
Рисунок 15: Криптованный исполняемый код в секторе 45
Код имеет ряд предварительных процедур, предшествующих декодированию и старту основного функционала.
• Проверка наличия системы защиты интернет 360safe. Если таковая находится - то её отключают.
Рисунок 16: Проверка наличия системы 360safe
• Создание подменного explorer.exe во временной папке - это декодированный исполняемый код.
Рисунок 17: Подменный Explorer.exe
Рисунок 18: Подменный Explorer.exe
• После декодирования, производится запуск %temp%\explorer.exe посредством ShellExecute — userinit.exe выполняет абсолютно аналогичную операцию с оригинальным explorer.exe! Одновременно, производится запуск оригинального explorer.exe посредством Winexec.
Рисунок 19: Выполнение подменного explorer.exe и оригинального explorer.exe
После этого выполняется основной функционал вредоноса - это классический даунлодер, загружающий и выполняющий файлы.
Рисунок 20: Функционал даунлоадера
В итого, благодаря отключению защиты 360safe становится возможным эффективная загрузка и выполнение файлов с удалённого сервера http://[...].perfectexe.com/ и др.
Теперь - о лечении этого вредоноса. Итак, наша система подготовлена и заражена дроппером Smitnyl.A (размер 37 076 байт, MD5 A6E5BAAEAB6C506CB5A08755B025F6A5). После заражения дроппер (как любой уважающий себя дроппер) самоликвидировался, больше никаких модификаций в системе не произошло, за исключением изменения MBR (оригинальная, заражённая). Подчеркну: на данном этапе userinit.exe заражён не был.
А произошло это заражение после перезагрузки системы, когда сразу начал обнаруживаться вредоносный функционал:
Как и обещалось - вредонос работает как даунлоадер и в нашем случае он скачивает свою бэкдор-компоненту.
И вот дальше обнаруживается интересное. На самом деле, фэйковый explorer.exe выполняется единожды при загрузке, скачивает в корень системного диска и запускает контент, после чего выгружается и самоуничтожается:
Код:
] C:\Documents and Settings\1\] ** New Command Shell [PID:1996]
] del C:\DOCUME~1\1\LOCALS~1\Temp\explorer.exe
] ** New Command Shell [PID:3144]
] del C:\2008.exeВ итого в системе есть бэкдор, однако ничто не указывает на его источник - Smitnyl.A! Cканирование AVZ системы обнаруживает наличие модуля бэкдора, запущенного как служба, позволяет его удалить, однако новая перезагрузка всё вернёт на свои места:
Обнаружить признак Smirnyl.A можно только если внимательно рассмотреть следующую часть лога:
Тут становится понятно: система не распознала заражённый userinit.exe по базе CRC, а потому вывела её с подозрением (система также не распознала и cmd.exe - но это верно: я сам подменил этот файл для журналирования операций в шелле).
Итак, каково же было лечение?
1. Поскольку userinit.exe при активной системе не задействован, его просто перезаписываем оригинальным файлом из дистрибутива или незаражённой системы.
2. Если на данном этапе провести перезагрузку - userinit.exe будет опять заражён. Поэтому производим восстановление MBRFix, однако это не значит, что не сработают другие варианты.
3. Производим стандартное лечение с помощью скрипта AVZ:
Код:
begin
ExecuteFile('net.exe', 'stop tcpip /y', 0, 90000, false);
SearchRootkit(true, true);
SetAVZGuardStatus(True);
QuarantineFile('c:\windows\system32\tjmitrd.dll','');
DeleteFile('c:\windows\system32\tjmitrd.dll');
BC_ImportAll;
ExecuteSysClean;
BC_Activate;
RebootWindows(true);
end.(Скрипт может меняться в зависимости от того, что закачает и запустит даунлоадер).
После перезагрузки система была полностью очищена.
Последнее редактирование модератором:
