Bootkit Remover - Бесплатные программы (freeware) - Форумы Anti-Malware.ru Перейти к содержанию

Recommended Posts

d_olex

Мы выпустили универсальную утилиту для удаления буткитов (включая Sinowal/Mebroot всех версий, Stoned Bootkit и все возможные в будущем вариации на тему заражения MBR). Читать описание и скачать утилиту можно здесь:

http://www.esagelab.ru/resources.php?s=bootkit_remover.

Далее – предыстория.

Буткиты, как разновидность широко распространенных вредоносных программ, появились in the wild в начале 2008-го года в лице семейства троянцев Sinowal (или Mebroot, по классификации других вендоров) и стали настоящей головной болью для антивирусной индустрии.

К тому же, недавно был представлен концептуальный буткит – Stoned Bootkit. Это послужило поводом для проведения небольшого исследования (см.ниже) с целью выяснить, как справляются антивирусы со старой доброй угрозой и ее новыми вариациями, а результаты тестирования, в свою очередь, послужили поводом для разработки простой и универсальной утилиты для лечения любых заражений MBR.

Предыстория

Современный буткит, фактически, представляет собой продолжение идей старых-добрых загрузочных вирусов времён DOS под NT платформу. Их история началась с презентации eEye Digital Security на конференции Black Hat USA в 2005-м году, в ходе которой был представлен концепт, запускающийся из главного загрузочного сектора и содержащий в качестве "полезной нагрузки" NDIS-бекдор, который позволял удалённо выполнять произвольный код на захваченном хосте:

http://www.blackhat.com/presentations/bh-u...s-05-soeder.pdf

Именно этот код и взяли за основу авторы троянца Sinowal, дополнив его функционалом по загрузке драйвера и механизмами сокрытия вредоносной активности, сделавшими удаление данного буткита делом совсем нетривиальным. Что из себя представляет Sinowal?

1. В процессе заражения компьютера дроппер буткита модифицирует код главной загрузочной записи (MBR). Работающий в системе троянец не виден в качестве файла, он "живёт" исключительно в MBR и первых секторах диска, которые не относятся к какому-либо разделу.

2. Во время загрузки системы, MBR-код буткита перехватывает процедуру чтения ядра операционной системы с диска, для осуществления патчинга вызова функции IoInitSystem рядом с точкой входа. После этого (так же как и в случае с легитимным загрузочным кодом) дальнейшее управление процессом загрузки передаётся загрузочному коду системного раздела, который, в свою очередь, считывает и запускает загрузчик операционной системы (ntldr).

3. По завершению второй стадии загрузки, загрузчик операционной системы передаёт управление ядру, но из-за установленного перехвата вызова IoInitSystem выполняется код буткита, который осуществляет проецирование в память драйвера с основным функционалом троянца.

4. Драйвер троянца устанавливает перехваты на драйвера дисковой подсистемы, которые, при попытке чтения модифицированного MBR, возвращают сохранённую копию оригинального загрузочного сектора.

5. На более поздних этапах инициализации и работы системы в процессы пользовательского режима драйвером внедряется код, который осуществляет взаимодействие троянца с командным центром а так же представляет собой spyware, ориентированный на кражу аккаунтов для доступа к системам онлайн-банкинга.

Неудивительно, что появление подобного зловреда вызвало бурную реакцию всего security-сообщества, ведь до этого, буткиты воспринимали исключительно как интересные концепты, которые вряд ли получат развитие в виде реальных угроз.

Первое развёрнутое описание (а заодно и первая работающая утилита, позволяющая удалять буткита) были опубликованы автором популярного антируткита GMER на своём сайте:

http://www2.gmer.net/mbr/

Несколько позже, интересными публикациями отличились и эксперты Лаборатории Касперского, вслед за которыми детектирование первого семейства Sinowal-а добавили в свои продукты и другие крупные антивирусные вендоры:

http://www.securelist.com/ru/analysis/2040...tkit_vyzov_2008

http://www.securelist.com/ru/analysis/2040..._I_kvartal_2008

Второе, актуальное и по сей день, поколение Sinowal-а увидело свет в марте 2009-го года:

http://www.securelist.com/ru/analysis/204007655/Butkit_2009

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

Тестирование

Задачей тестирования было проверить, насколько качественно антивирусы детектируют и лечат вредоносные программы, модифицирующие MBR, и насколько они готовы к появлению новых угроз такого типа. Для этого, во-первых, необходимо выяснить, каким образом антивирусы детектируют вредоносный код в MBR: сигнатурно или универсально. Сигнатурное детектирование бессильно против новых модификаций старой угрозы. Во-вторых, необходимо протестировать антивирусы с уже появившейся «новой угрозой».

К сожалению, у меня не было ни времени ни желания тестировать все несколько десятков антивирусов от разных компаний, поэтому, в тестирование попали только те, которые по информации от самих вендоров и слухам с форума anti-malware.ru способны детектировать и/или лечить второе поколение Sinowal-а.

Итак, перед нами:

* McAfee VirusScan 13.15.101

* Dr.Web CureIt! 5.0.2.9230

* Kaspersky Antivirus 2009 9.0.0.463

* ESET NOD32 4.0.437.0

* Avast Pro 4.8.1356.0

* Symantec Trojan.Mebroot Removal Tool 1.0.1.0

* F-Secure BlackLight 2.2.1092.0

Кроме того, в тестировании приняла участие бесплатная утилита-антируткит RootRepeal версии 1.3.5.0.

Перейдём к делу.

Тестирование производилось на VMware, с установленной Windows XP Professional SP2. Всего было развёрнуто три разных тестовых стенда.

1. Самый обычный сампл Sinowal-а второго поколения, дроппер которого датирован концом мая 2009-го года:

http://www.virustotal.com/analisis/b29a3d8...4130-1243663256

2. Модифицированная версия Sinowal-а которая была полученна следующим образом: я дизассемблировал код загрузочной записи руткита, прочитанный с зараженной машины, модифицировал его, разбавив мусорными xor-ами и nop-ами и с целью сбития сигнатуры, и после ассембилрования записал обратно на диск. Код доступен для скачивания здесь:

http://www.esagelab.com/files/sinowal-b_modified.zip.

sinowal-b_modified.jpg

Модифицированный загрузочный код буткита (добавленные инструкции выделены).

3. Stoned Bootkit. Это очередной концептуальный буткит, который был представлен на конференции BlackHat в этом году. Публично доступная версия буткита является сильно урезанной: кроме инфектора и, собственно, загрузочного кода в ней фактически ничего нет. Дополнительная информация доступна на сайте проекта: http://www.stoned-vienna.com/.

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

Пример лога:

==============================================>Stealth==============================================0x8122CB80 Page with executable code [ ETHREAD 0x81400DA8 ] TID: 256, size: 1152 bytes0x811E9B29 Page with executable code [ ETHREAD 0x813C9DA8 ] TID: 652, size: 1239 bytes0x811E6B13 Page with executable code [ ETHREAD 0x813D25D0 ] TID: 656, size: 1261 bytes0x811BAB07 Page with executable code [ ETHREAD 0x81416570 ] TID: 744, size: 1273 bytes0x81202AF1 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 1295 bytes0x81208A55 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 1451 bytes0x811DA9B1 Page with executable code [ ETHREAD 0x815BB8F8 ] TID: 684, size: 1615 bytes0x811E78F8 Page with executable code [ ETHREAD 0x813D25D0 ] TID: 656, size: 1800 bytes0x811E87B9 Page with executable code [ ETHREAD 0x813C9DA8 ] TID: 652, size: 2119 bytes0x811BB6B2 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 2382 bytes0x811C3581 Page with executable code [ ETHREAD 0x81661A90 ] TID: 748, size: 2687 bytes0x811DE4A3 Page with executable code [ ETHREAD 0x817CB810 ] TID: 24, size: 2909 bytes0x8120648C Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 2932 bytes0x811E841F Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 3041 bytes0x8121F419 Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 3047 bytes0x8121E3CA Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 3126 bytes0x811EC3B6 Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 3146 bytes0x811FE321 Page with executable code [ ETHREAD 0x813F3B20 ] TID: 252, size: 3295 bytes0x811FE25E Page with executable code [ ETHREAD 0x81400B20 ] TID: 264, size: 3490 bytes0x811FB20A Page with executable code [ ETHREAD 0x813F3B20 ] TID: 252, size: 3574 bytes0x8120EA80 Unknown thread object [ ETHREAD 0x813F3DA8 ] TID: 248, size: 592 bytes0x811FB187 Unknown thread object [ ETHREAD 0x813F3B20 ] TID: 252, size: 592 bytes0x8122CAF7 Unknown thread object [ ETHREAD 0x81400DA8 ] TID: 256, size: 592 bytes0x811FE119 Unknown thread object [ ETHREAD 0x81400B20 ] TID: 264, size: 592 bytes0x8123FDF0 Unknown thread object [ ETHREAD 0x816EB030 ] TID: 560, size: 592 bytes0x811C3417 Unknown thread object [ ETHREAD 0x8165BDA8 ] TID: 648, size: 592 bytes0x811C0D7C Page with executable code [ ETHREAD 0x815BC570 ] TID: 752, size: 644 bytes0x811D5D2D Page with executable code [ ETHREAD 0x815BCDA8 ] TID: 660, size: 723 bytes0x8120ED0B Page with executable code [ ETHREAD 0x813F3DA8 ] TID: 248, size: 757 bytes

Кроме того, для диагностики системы использовалась и утилита собственной разработки, речь о которой пойдёт в конце поста.

Результаты тестирования привожу в виде таблицы (детектирование/удаление).

bootkits_table.gif

В таблице не фигурируют утилиты и продукты от Avast, Symantec и F-Secure, так как они провалили тест, отказавшись впринципе детектировать что-либо из использовавшихся самплов. Но результаты по остальным оказались весьма интересные, и с ходу вызывают достаточно много вопросов.

1. Почему в первом тесте NOD32 не смог вылечить активное заражение?

Если честно, для меня самого это осталось загадкой, особенно с учётом того, что ESET зарелизил отдельную утилиту-ремовер, замечательно справляющуюся с удалением не модифицированного Sinowal-а обеих поколений. Однако, в силу того что среднестатистический пользователь вряд ли додумается найти и использовать эту утилиту, я посчитал более справедливым включить в тестирование именно "большой" продукт.

2. Почему во втором тесте большинство продуктов от антивирусных компаний смогли детектировать буткит, но не смогли с ним ничего сделать?

На самом деле, речь идёт всего-лишь о детекте драйвера буткита в памяти, а не вредоносного кода в главной загрузочной записи. Полная бесполезность подобного детектирования очевидна.

3. А почему антивирусы не смогли детектировать модифицированный загрузочный код буткита?

Это звучит пугающе, но загрузочный код детектируется исключительно сигнатурно. Да, вы не ослышались, это полный и невообразимый [песец]: активный руткит, который легко идентифицировать по подменённому загрузочному коду (при попытке его считывания стандартными средствами) напрочь игнорируется, если сгнатуры этого самого загрузочного кода нет в базе. Удивительно, но всего за десять минут работы мы смогли проапгрейдить версию зловреда почти пятимесячной давности таким образом, что удалить её не смог ни один антивирус.

4. Но ведь RootRepeal замечательно справляется с удалением буткита в первых двух тестах?

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

5. Почему почти никто не детектирует и не лечит Stoned Bootkit?

С RootRepeal-ом всё просто: это антируткит, и его задачей является исключительно детектирование аномалий. Stoned никак не скрывает свой код в MBR, из-за этого и игнорируется антируткитом. Однако, подобная формулировка не сможет служить оправданием в случае с антивирусами.

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

Выводы, опираясь на приведенные мной факты, можете сделать сами, но то, что антивирусная индустрия в техническом плане не готова в полной мере защищать пользователей от нового вида угроз - более чем очевидно. Радует лишь тот факт, что участвовавшие в тестировании продукты хоть как-то детектируют распотраненные in the wild сапмплы, ведь подавляющие большинство других вендоров тихо отмалчивается вообще игнорируя проблемы.

Утилита

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

Её главные отличительные особенности:

- Корректно детектирует и лечит активное заражение как распространенных in the wild буткитов (включая все модификации Sinowal/Mebroot), так и неизвестных зловредов подобного класса.

- Протестирована и работает на 32-х и 64-х разрядных операционных системах Microsoft Windows XP, Server 2003, Vista, Server 2008 и Windows 7 (RC1 и RTM).

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

bootkit_remover.jpg

Bootkit Remover нашел активный Sinowal-b.

Ремовер простой в использовании.

Утилита работает из командной строки (необходимы права администратора).

Проверка MBR для всех физических накопителей:

> remover.exe

В отчете сканирования выводится один из трех вердиктов для каждого физического накопителя:

OK (DOS/Win32 Boot code found) - MBR содержит оригинальный загрузочный код операционной системы DOS/Windows.

Unknown boot code - MBR содержит неизвестный загрузочный код. На практике это может означать то, что в системе присутствует буткит который не скрывает модифицированный загрузочный код. Кроме того, подобный статус будет выводится в случае использования какого-либо нестандартного мененджера загрузки (например, GRUB).

Controlled by rootkit! - в системе обнаружен активный буткит, который препятствует чтению модифицированного загрузочного кода стандартными средствами (именно так детектируется Sinowal/Mebroot).

Восстановление оригинального загрузочного кода Windows:

> remover.exe fix <device>

... где <device> - это системное имя физического накопителя, на котором вы хотите восстановить загрузочный код (например, \\.\PhysicalDrive0).

Дамп загрузочного кода в консоль или в файл:

> remover.exe dump <device> [output_file]

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

*** ВНИМАНИЕ!

При перезаписи MBR всегда существует небольшой риск нанести вред операционной системе. Поэтому, перед тем как использовать утилиту Bootkit Remover, обязательно приготовьте загрузочный установочный диск с используемой версией Windows, с помощью которого (Recovery Console) можно восстановить MBR в случае его повреждения.

Скачать утилиту можно здесь: http://www.esagelab.com/files/bootkit_remover.rar

По вопросам работы ремовера связываться со мной лучше всего по е-mail: dmitry@esagelab.ru

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

UPD:

EsetInspector, после запуска сервисного скрипта, смог успешно излечить Sinowal.b и Stoned Bootkit, однако, модифицированную версию Sinowal-а попросту не увидел.

Спасибо юзерам santy и VNE за информацию.

  • Upvote 5

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
santy

EsetInspector в составе ESET NOD32 детектирует, и удаляет Stoned Bootkit через исполнение сервисного скрипта.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
OlegAndr

Я не понял - а код буткита в паблике - это как понимать? Умышленное написание и распространение вирусов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Lafiel

EPIC FAIL.

На тестовой машине было установлено два винчестера:

HDD0 (загрузочный WinXP, OS WinXP)

HDD1 (загрузочный Win7, OS Win7)

Компьютер запустили с HDD0, соответственно загрузилась WinXP.

С помощь WinHex на HDD1 был изменен загрузочный сектор(просто занулен).

После чего запущена данная утилита и бут сектор был востановлен,

вот только он почему-то оказался от WinXP, а не от Win7.

Напрашивается подозрение, что тулза просто определяет, под какой ОС она запущена,

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

Вот мне интересно, у меня на машине стоит Linux и WinXP, а загрузочник GRUB(Linux),

так получается из под XP она мне его затрет на стандартный загрузочник XP и мой

GRUB будет нервно курить в сторонке?! Надо бы это проверить ... предварительно забэкапив всю систему.

В целом тулза конечно полезная, но уж слишком ненадежная для нетривиального пользователя.

И уж тем более никак не панацея от всех буткитов.

Поделиться сообщением


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

Ммм... fixmbr с блек джеком и шлюхами?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
d_olex
EPIC FAIL.

lolwut? Так может VBA32 умеет mebroot лечить?

тулза просто определяет, под какой ОС она запущена, и пишет в загрузочную область соответствующий загрузчик

Спасибо, Капитан Очевидность)

К сожалению, по-другому никак: по очереди маунтить все партиции на целевом накопителе и смотреть что за ОС туда утсановленна - ещё менее надёжно. Возможно, в следующем билде опциональную возможность выбора буткода для конкретной ОС мы предоставим юзеру.

В целом тулза конечно полезная, но уж слишком ненадежная для нетривиального пользователя.

Да, в мануале к тулзе действительно стоит указать, что восстановление бутсектора рекомендуется делать только на том накопителе, с партиции которого запущенна рабочая ОС, но это не даёт адекватного повода судить о надёжности/не_надёжности впринципе: если юзер будет включать голову перед тем как что-то затирать, то всё будет ок

И уж тем более никак не панацея от всех буткитов.

От каких конкретно, например?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
d_olex
Ммм... fixmbr с блек джеком и шлюхами?

Вроде того: не требует таскать с собой пачку загрузочных дисков под все возможные версии Windows и может показывать состояние MBR, помимо, собственно, лечения.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Guest VNE
santy Дата Сегодня, 12:39

EsetInspector в составе ESET NOD32 детектирует, и удаляет Stoned Bootkit через исполнение сервисного скрипта.

Подтверждаю!

http://www.eset.eu/encyclopaedia/win32-sto...otkit-dr?lng=en

http://www.virustotal.com/ru/analisis/6e9d...8a69-1253609893

f56493ab142cb8ae5bdd673f52f277f1.png

be1723786ee0722d8bd4cd29776e7b51.png

Напротив mebroot поставил + ;)

d8ac5e370c0116a17d7536e15d21d2c9.png

Выполнил, пере-загрузился!

Чисто. ;)

086a5818ac911f7d79be27e50d6a7c25.png

Скрипт лечения -прикрепил.

Второе и первое поколение mebroot тоже лечит. ;)

Rootkit: @Trojan.Win32/Mebroot *1,0*, Rootkit: @Trojan.Win32/Mebroot *2,0*

SysInspector_VRT_ПК_090922_2301.zip

SysInspector_VRT_ПК_090922_2301.zip

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
d_olex

VNE

В архиве из аттача обнаружил только отчёт сисинспектора, гугл тоже ничего вразумительного не выдал, где же найти заветный скрипт для удаления?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Guest VNE

fdd2dc539603e1c79450645aec991660.pngbf8a4ff41c576afb126fe04a2386077c.png

Eset Sysinspector-> файл-> запустить сценарий службы-> открываем SysInspector-VRT-ПК-090922-2301.txt :)

91af91dc360d78ff1d3e2731d7bf7f23.png

63fd1533eaae48f955c8c9f76d9880d8.png

Запустить!

Сценарий обслуживания является вспомогательным средством для пользователей программы ESET SysInspector. Он предназначен для удаления из системы нежелательных объектов.

Сценарий обслуживания позволяет пользователям целиком или частично экспортировать журнал SysInspector. После экспорта пользователь может выбрать и отметить объекты для удаления. Затем можно запустить сценарий с отредактированным журналом для удаления отмеченных объектов.

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

Пример.

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

Загрузите ESET SysInspector и создайте новый снимок состояния компьютера.

Щелкните первый элемент в разделе слева (в древовидной структуре), нажмите клавишу CTRL, а затем выберите последний объект, чтобы отметить все элементы в списке. Отпустите клавишу CTRL.

Щелкните выделенные объекты правой кнопкой и выберите команду контекстного меню «Экспортировать в сценарий обслуживания».

Выбранные объекты будут экспортированы в новый журнал.

Далее следует наиболее важный шаг всей процедуры: откройте созданный журнал и измените атрибут «–» на «+» для всех объектов, подлежащих удалению. Убедитесь, что не отмечены объекты, жизненно важные для работы операционной системы.

Откройте ESET SysInspector, щелкните «Файл» > «Загрузить сценарий обслуживания» и введите путь к своему сценарию.

Нажмите «OK», чтобы запустить сценарий.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Lafiel
т каких конкретно, например?

Ну уж точно не от

"все возможные в будущем вариации на тему заражения MBR"

Лично я бы не рискнул заглядывать даже в недалекое будущее буткитов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
d_olex

VNE:

Несколько неочевидный способ, ожидал что-то схожее со скриптами AVZ)

Значит, провёл тестирование.

Действительно, EsetInspector после запуска сервисного скрипта, смог успешно излечить Sinowal.b и Stoned Bootkit, однако, модифицированную версию Sinowal-а попросту не увидел/не показал:

0b97d9dca69d50f0c627f21b018a7a64.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Guest VNE

Кстати, у вас старые базы.. :)

Последняя версия обновлений: 4477.

ESS 4.0.467.0

База данных сигнатур вирусов: 4477 (20091002)

Модуль обновления: 1029 (20090623)

Модуль резидентного сканирования: 1241 (20091001)

Модуль расширенной эвристики: 1098 (20090924)

Модуль поддержки архивов: 1103 (20090923)

Модуль очистки: 1045 (20091001)

Модуль Anti-Stealth: 1012 (20090526)

Модуль персонального файервола: 1052 (20090922)

Модуль защиты от спама: 1012 (20090608)

Модуль состояния системы: 1213 (20090902)

Модуль поддержки самозащиты : 1009 (20090917)

У меня так: настройки-> обновления-> включить тестовый режим. :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
chk
тулза просто определяет, под какой ОС она запущена, и пишет в загрузочную область соответствующий загрузчик
Спасибо, Капитан Очевидность)

К сожалению, по-другому никак: по очереди маунтить все партиции на целевом накопителе и смотреть что за ОС туда утсановленна - ещё менее надёжно.

Ога. При этом - антивирусная индустрия полные лохе, хоть ряд продуктов и умеет восстанавливать "оригинальный" бут сектор, а у вас аж целый Bootkit Remover, который перетирает буты, даже если никаких буткитов на машине нет. Конгениально, гггг

P.S.

Спасибо юзерам santy и VNE за информацию.

Можно написать проще: Спасибо Веталег (тм)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Umnik

d_olex

Сразу не было времени сказать. Не нарушайте правила, маты запрещены.

Машем Виталегу ручкой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
priv8v
Можно написать проще: Спасибо Веталег (тм)

santy не виталег

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
ASMax
И уж тем более никак не панацея от всех буткитов.

От каких конкретно, например?

От тех, которые прикроют лавочку со scsi-запросами. :)

ЗЫ: Кстати, если система вернет вам достаточно большое число накопителей, то утилита упадет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
d_olex
От тех, которые прикроют лавочку со scsi-запросами. :)

ЗЫ: Кстати, если система вернет вам достаточно большое число накопителей, то утилита упадет.

Кроме того, что реализовано в утилите, я знаю ещё минимум два способа взаимодействия с диском на секторном уровне, которые никто не перехватывает. Если вдруг они исчерпают себя - это будет очень замечательным поводом для написания дженерик-анхукера под storage devices stack.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Андрей-001

Коллеги, не будет ли лучшим решением, не критиковать представленную тут работу, а объединить свои умные головы для достижения максимального успеха?

Думаю, что ВАМ ВСЕМ есть что добавить и предложить в этом направлении работы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Fixxxer®

Утилита хороша, слов нет. Минус один: абсолютная невозможность создавать журнал работы.

Что хочу я как хелпер:

1. Просканировать систему.

2а. Если что-то найдёт - делаем карантин MBR и фиксим.

2б. Если чисто - кланяемся.

Как это реализуется в работе. По п.2 всё ясно:

Сохраните текст ниже как cleanup.bat в ту же папку, где находится скачанная Вами утилита (в Блокноте вставьте текст, затем Файл - Сохранить как - Выберите 'Тип файла: все файлы' и 'Имя файла: cleanup.bat'. Не забудьте сохраниться именно в ту папку, где находится утилита!).
remover dump \\.\PhysicalDrive0 mbr.binremover fix \\.\PhysicalDrive0

Запустите cleanup.bat
По окончании в папке появится файл mbr.bin. Пришлите его в карантин согласно Правил (Приложение 3).

По п.1. ничего не ясно: весь вывод в консоли, что там, как там - видит только пользователь. Что там и как там - можно понять только из слов, а если человек не знает английский? Рекомендация типа

remover.exe > log.txt

тоже не спасает: по выполнению работы утилита ждёт Any Key, если это на экране не отобразится - пользователь будет до посинения сидеть и ждать окончания работы (если по счастью на клавиатуре что-то не нажмёт).

Можно это исправить? Или ключ scan [path_to_logfile] придумать или просто Any Key в конце убрать....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
TANUKI

Хм... а как провериться на наличие этой заразы? А то смущает меня падучесть Лисы и иногда Проводник падает в 7-ке (7100)... ЕСЕТовского инспектора достаточно?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Fixxxer®

Пусть меня поправят, но кажется в Vista и тем более в Win7 Sinowal/Bootkit не распространяется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
didok

у меня Remover пишет Unknown boot code при попытке дальнейшей проверки Remover отключается как быть дальше хотел полностью вставить картинку как у вас ---не получается.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
didok

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

  • Сообщения

    • demkd
      ИИ — полезная штука, но, к сожалению, бесплатные версии, как тот же Google Gemini Flash, тупенькие на уровне 12b моделей, делают колоссальное число ошибок по мелочам. Яблочко от яблони... Мало того, "новое" у них обычно старое с отставанием на год, и это в лучшем случае. Я сейчас как раз занимаюсь новой, уже 3-й версией своего "Клавиатурного помощника". В нём будет поддержка локального ИИ, горячих ИИ-клавиш, голосовых команд, голосового ввода и вспомогательной LLM для переводов, правки текста и т.п. Именно локального ИИ без необходимости обращения в сеть и сопутствующих утечек данных И это не для старого железа — нужно как минимум много памяти и современный процессор, в идеале хотя бы RTX 5060 Ti 16 ГБ в качестве ускорителя. А результат, ну, такой себе. ИИ слишком склонен ошибаться, и доверять ему что-то серьёзное пока не стоит, даже код пишет, который как-то работает, но в нём масса мелких и незаметных ошибок и уязвимостей. 
      Текст исправлен с помощью Google Gemma 4 E4B. 
    • PR55.RP55
      Вы сказали: "Найди все новые ключи которые появились 2026 г. и ранее не использовались... Можешь ?"
      *Да, я могу помочь* составить список новых ключей реестра и путей
      автозагрузки, которые вредоносное ПО использует в текущих кампаниях
      (включая модификации 2026 года), маскируясь под легальные системные
      компоненты. ( скопирую частично) :   * *|HKLM\SOFTWARE\Classes\Protocols\Filter|* и *|\Handler|* — новые
          модификации Adware перехватывают протоколы edge:// или msproedg://
          для подмены поисковой выдачи.   * *|HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss|* —
          использование подсистемы WSL для скрытого автозапуска
          Linux-ориентированных рекламных модулей, незаметных для стандартных
          триггеров автозагрузки Windows. Современные зловреды (особенно Adware и майнеры) научились прописываться
      в тихий автозапуск без создания классических ключей |Run| или
      |Services|. Они используют встроенный механизм Windows 10/11 —
      *псевдонимы выполнения приложений*.   * *Суть*: В реестре создается связь в ветке
          |HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths| или через
          механизм |AppXPackage|. Зловред подменяет вызов легальной команды
          (например, при наборе пользователем |notepad| или |calc| в строке
          «Выполнить») и запускает свое тело.
        * *Что добавить в памятку*: Обращать внимание на появление кастомных
          записей в блоке «Псевдонимы приложений» и проверять, куда
          перенаправляются стандартные системные вызовы. 2. Подмена через каталоги |Lxss| (WSL — Windows Subsystem for Linux)
      Это одна из самых опасных современных тенденций, так как многие
      антивирусы до сих пор слабо сканируют Linux-среду внутри Windows.   * *Суть*: Майнеры и стилеры прописывают свой запуск внутри
          дистрибутива WSL (ключ реестра
          |HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss|). При старте
          Windows запускается скрытая фоновая сессия WSL, которая активирует
          ELF-бинарник (Linux-вирус). В логах автозапуска Windows это выглядит
          как легальный старт службы |wsl.exe|, но с хитрыми аргументами.
        * *Что добавить в памятку*: Формула «А+В+С»: если |wsl.exe|
          запускается автоматически с флагами |-d| (конкретный дистрибутив)
          или скрытыми bash-скриптами — это 100% повод для изоляции и проверки
          содержимого виртуального диска VHDX. 3. Продвинутый Timestomping с подделкой под апдейты ОС
      Раньше вирусописатели просто копировали даты у соседних файлов
      (|kernel32.dll| и т.д.). Теперь они действуют умнее:   * *Суть*: Дата создания файла выставляется ровно на день/час крупного
          официального обновления Windows (например, подстраиваются под график
          Patch Tuesday от Microsoft). Аналитик смотрит на лог uVS, видит дату
          (например, |14.10.2025|) и думает: «А, ну это тогда накопительный
          апдейт прилетел, файл чистый».
        * *Что добавить в памятку*: Правило проверки контрольных сумм. Не
          верить датам, даже если они идеально совпадают со временем
          системного обновления. Если у файла из папки |System32| с
          «правильной» датой обновления отсутствует валидная ЭЦП (или статус
          |Цифр. подпись: НЕТ|) — это критический триггер. 4. Атаки типа Living off the Land (LotL) через новые системные утилиты
      Вместо использования заезженных |powershell.exe| или |cmd.exe|, которые
      сейчас жестко блокируются любым EDR/антивирусом, малварь перешла на
      легальные, но редкие утилиты Windows (LOLBins).   * *Суть*: Для скачивания и запуска вредоносного кода используются
          системные компоненты:
            o |curl.exe| (теперь встроен в Windows) — для скрытой загрузки
              полезной нагрузки.
            o |tar.exe| — для распаковки зашифрованных архивов со стилерами
              прямо «на лету».
            o |winget.exe| (Windows Package Manager) — для скачивания
              вредоносных утилит из легальных репозиториев.
        * *Что добавить в памятку*: В uVS нужно тщательно анализировать
          параметры запуска командной строки в Планировщике задач (|TASKS|),
          если там фигурируют |curl|, |tar| или |bitsadmin|, качающие что-то с
          внешних IP-адресов. 6. Скрытые модификации через COM-объекты (COM Hijacking без изменения
      файлов)
      Вместо перезаписи файлов в |System32| или создания явных ключей |Run|,
      малварь перехватывает легальные системные интерфейсы через реестр.   * *Суть*: Зловред прописывает путь к своей вредоносной DLL в ветку
          *|HKCU\Software\Classes\CLSID\{GUID}\InprocServer32|*. При этом
          берется GUID легального и часто используемого компонента Windows
          (например, Проводника, контекстного меню или планировщика). Как
          только система или пользователь совершает обычное действие
          (открывает папку, кликает правой кнопкой мыши), Windows
          автоматически подгружает вредоносную DLL.
        * *Что добавить в памятку*: В uVS такие объекты часто попадают в
          категорию «Подозрительные CLSID» или скрытые расширения оболочки.
          Если в ветке |HKCU| (пользовательский уровень) переопределяется
          системный GUID, который по умолчанию должен жить только в |HKLM|
          (уровень системы) — это явный признак перехвата. 7. Спуфинг цифровой подписи через уязвимости каталогов (Catalog Signing
      Spoofing)
      Малварь научилась обходить базовую проверку подписей, из-за чего в логах
      некоторых утилит файл может ошибочно помечаться как «Подписан Microsoft».   * *Суть*: Используются уязвимости в механизме проверки файлов через
          каталоги безопасности Windows (|.cat| файлы). Вредоносный бинарник
          модифицируется таким образом, что его хэш совпадает с хэшем
          легального файла в базе данных каталогов (используются коллизии или
          специфические уязвимости парсинга).
        * *Что добавить в памятку*: Правило двойной проверки. Если файл
          находится в нетипичном месте (например,
          |C:\Users\...\Temp\svchost.exe|), но uVS или ОС рапортует, что у
          него «Валидная подпись Microsoft» — необходимо принудительно
          отправлять хэш файла на VirusTotal через встроенную функцию uVS или
          проверять подпись сторонними утилитами (например, |Sigcheck| от
          Sysinternals) с проверкой отзывов сертификатов. 8. Эксплуатация механизма «Служб доставки обновлений» браузеров
      (Edge/Chrome Maintenance)
      Рекламное ПО (Adware) и кликеры ушли от создания собственных явных служб
      и теперь паразитируют на легальных планировщиках браузеров.   * *Суть*: Вредоносный скрипт не создает новую задачу в Планировщике.
          Вместо этого он модифицирует параметры /уже существующей/ легальной
          задачи, например, |MicrosoftEdgeUpdateTaskMachineCore|. В
          оригинальную команду дописывается скрытый аргумент
          (аргумент-паразит), который раз в сутки скачивает или запускает
          рекламный модуль. Аналитик видит знакомое имя задачи Edge, видит
          легальный путь к апдейтеру и пропускает её.
        * *Что добавить в памятку*: При анализе задач Планировщика (|TASKS|) в
          uVS нужно смотреть не только на имя файла, но и *полностью
          разворачивать строку аргументов*. Любые добавленные URL-адреса,
          вызовы |cmd /c|, или сторонние пути в параметрах легальных служб
          обновления — это стопроцентный признак компрометации. 10. Фейковые системные переменные в путях автозапуска
      Обман визуального восприятия аналитика через манипуляцию переменными среды.   * *Суть*: В реестре или планировщике путь к файлу прописывается как
          |%SystemRoot%\System32\drivers\malware.sys|. Но перед этим на уровне
          пользователя (|HKCU\Environment|) создается кастомная переменная
          |%SystemRoot%|, которая указывает вовсе не на |C:\Windows|, а на
          |C:\Users\Public\Documents|. В итоге аналитик глазами видит
          «безопасный» системный путь, а система при загрузке идет в скрытую
          пользовательскую папку.
        * *Что добавить в памятку*: Всегда проверять блок «Переменные
          окружения» в начале лога uVS. Любые попытки переопределить
          стандартные переменные вроде |%SystemRoot%|, |%WinDir%| или
          |%ProgramFiles%| на уровне текущего пользователя — это критическая
          угроза.
    • PR55.RP55
      Сейчас дал ИИ задание напиши скрипт и... Вот:  ( взял Инфо. из одного из старых образов) Скрипт лечения для uVS Чтобы полностью удалить эту службу, связанные с ней файлы и очистить ссылки в реестре, выполните следующий скрипт: text ; uVS v4.15.1 [Script] ; Target OS: Windows ; Удаление вредоносной службы и основного файла апдейтера delref %Network%\C:\PROGRAM FILES (X86)\YONTOO\Y2DESKTOP.UPDATER.EXE ; Удаление исполняемого файла в AppData, вызываемого через параметры службы delref %AppData%\YONTOO\YONTOODESKTOP.EXE ; Принудительное удаление самой службы из реестра delsrv Yontoo Desktop Updater ; Очистка остаточных путей и каталогов Yontoo deldir C:\Program Files (x86)\Yontoo deldir C:\Users\cappu44ino\AppData\Roaming\Yontoo ; Перезагрузка для применения изменений restart --------- Я сильно не увлекался - так для примера.  
    • PR55.RP55
      santy Модели ИИ ( я делал запрос к google ) - есть возможность задать вопрос ( дать задание ) по заранее выбранным настройкам: настройки: yaml [SYSTEM_OVERRIDE] ---------- Код он сам себе напишет :)  Главное задать нужные вопросы и потом попросить\ сохранить настройки в виде кода ) Единственно - не все ИХ модели нормально работают. Результаты тоже нужно проверять... Например:  получить Резюме... По записи - ( как в моём примере в Новые функции ) С заранее заданными параметрами - что нам нужно.  Это и для обучения и для экономии времени и когда оператор устал, для написания отчёта - по работе на семинар, при обсуждении на форуме, анализ новых угроз или появился новый ключ автозапуска; там где есть сомнение - что это... Построить цепочку - чтобы увидеть механику процесса\заражения. Увидеть аномалии - как то, что браузер "подписан" но это ЭЦП не головного офиса - а ЭЦП - пусть и "легитимное" - но смежников.  Аномалии пути; размера; схожесть имени и т.д. Никакие настройки uVS этого не дадут.  Можно увидеть никогда ранее неиспользуемый ключ запуска ( или его нестандартное применение ).  Если железо современное - то возможно? - локальные модели ИИ. Можно попробовать например дать задание: Найди все новые ключи которые появились 2026 г. и ранее не использовались...  
    • santy
      Как гипотетические варианты действий: ---------------------- - получить детальную расшифровку выбранного антивирусного детекта по результату проверки файла на VT из экрана ИНФО. Здесь я бы обратил внимание на три основных детекта: у Kaspersky, DrWeb, ESET, возможно + Microsoft. - получить расшифровку по цифровой подписи файла, насколько известна, и надежна. -  может стоит продумать свою классификацию детектов, и потом уже на основании данной классификации находить другие примеры/способы запуска и т.п.
×