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
      возможность есть, гляну, размер переменных окружения действительно 32767 максимум, но конкретно path больше 4095 это уже может стать проблемой.
    • Ego Dekker
      ESET Online Scanner 4.0.1  (Windows 10/11, 64-разрядная)
                                                                                  ●
              Руководство пользователя ESET Online Scanner 4  (PDF-файл)
    • Ego Dekker
      ESET Cyber Security был обновлён до версии 9.0.6700.
    • AM_Bot
      Теория звучит убедительно, но работает ли она на практике? Мы внимательно изучили Phishman 2.35 и решили не останавливаться на описании её возможностей. Вместо этого протестировали платформу на собственных сотрудниках и удивились, к каким результатам это привело.      1. Введение2. Методология тестирования Phishman 2.353. Первичное тестирование3.1. Подготовка шаблонов фишинговых сообщений, инфраструктуры рассылки3.2. Тестирование доставки и отражения результатов в статистике3.3. Результаты атак4. Обучение4.1. Формирование учебной группы4.2. Составление образовательной программы по повышению киберкультуры4.3. Процесс обучения и его результаты5. Повторное тестирование5.1. Результаты атак6. Подведение итогов6.1. Сложности, с которыми мы столкнулись7. Впечатления от проекта команды «АМ Медиа»7.1. Реакция сотрудников7.2. Реакция организаторов7.3. Сотрудничество с вендором8. ВыводыВведениеPhishman 2.35 — это система повышения осведомлённости пользователей в сфере ИБ. Она помогает развивать киберкультуру и формировать у сотрудников устойчивые навыки безопасной работы с информацией, цифровыми сервисами и корпоративными ресурсами. В процессе обучения сотрудники учатся распознавать актуальные сценарии атак, закрепляют правильные модели поведения и в результате реже становятся причиной инцидентов, связанных с человеческим фактором.В первой части обзора Phishman 2.35 мы рассмотрели платформу с точки зрения её возможностей. Теперь пришло время проверить, как всё это работает на практике. За время проекта мы не только оценили эффективность различных сценариев, но и столкнулись с рядом особенностей, которые невозможно увидеть в документации. Одни из них влияли на ход тестирования, другие оказались скорее организационными нюансами, о которых стоит знать заранее.Методология тестирования Phishman 2.35В процессе работы с киберкультурой «АМ Медиа» мы будем использовать следующие метрики:Обученность. Отражает уровень знаний сотрудников в области ИБ. Показатель растёт, когда сотрудники осваивают темы: реагирование на инциденты, защита от социальной инженерии и другие критически важные компетенции.Иммунность. Показывает, как сотрудники применяют знания на практике. Она повышается, когда демонстрируется способность распознавать угрозы и правильно на них реагировать в реальных сценариях.Киберосознанность — итоговая метрика. Объединяет знания и практические навыки, показывая, насколько сотрудники в целом устойчивы к киберугрозам и действуют корректно при их возникновении.Прежде чем оценивать эффективность работы системы, необходимо определить отправную точку. Первичное тестирование определит, на какие сценарии реагирует каждый сотрудник, где чаще всего допускаются ошибки и какие темы требуют дополнительного развития. На основе этих данных формируется индивидуальная программа обучения: сотрудники проходят персонализированные курсы, выполняют практические задания и тесты, которые помогают устранить выявленные пробелы и закрепить необходимые навыки. В процессе обучения повышается уровень обученности, а закрепление знаний через практику влияет на показатель иммунности. После завершения обучения мы проведём повторное тестирование, которое покажет, какие изменения произошли по всем ключевым метрикам.Заключительный этап — сравнение результатов первичного и повторного тестирования. Здесь станет понятно, насколько вырос уровень киберкультуры сотрудников: изменилось ли их отношение к вопросам ИБ, стали ли они увереннее распознавать угрозы и чаще принимать безопасные решения в ситуациях, где раньше могли допустить ошибку.В качестве основного канала для рассылки фишинга выбрали электронную почту. Причина очевидна: именно она остаётся основным способом первичного контакта злоумышленников с сотрудниками и доставки фишинговых сценариев. По имеющимся оценкам, более 90 % успешных кибератак начинаются с электронного письма, поэтому исключать этот канал из подобных проверок было бы некорректно.Первичное тестированиеРеальные фишинговые атаки почти никогда не строятся по универсальному шаблону: злоумышленники адаптируют содержание писем под роль человека в компании, его рабочие процессы и типовые задачи. Поэтому при выборе целевой аудитории мы разделили сотрудников по функциям и уровню доступа к корпоративным данным, а сам проект разбили на 3 последовательные волны с разным уровнем сложности.Подготовка шаблонов фишинговых сообщений, инфраструктуры рассылкиПосле определения целевой аудитории был проведён анализ структуры подразделений и рабочих процессов сотрудников. На этом этапе изучались:должностные обязанности;распределение зон ответственности;характер внутреннего взаимодействия между отделами;используемые адреса электронной почты;формат повседневной служебной переписки.Это позволило понять, какие сценарии коммуникации являются для сотрудников привычными и не вызывают подозрений.На основе собранных данных были подготовлены сценарии фишинговых сообщений. При разработке содержимого учитывались тематика рабочих задач, стиль корпоративного общения, оформление внутренних уведомлений и типовые причины отправки писем внутри организации. Основная задача заключалась в том, чтобы письмо воспринималось как стандартное рабочее сообщение, соответствующее реальным бизнес-процессам заказчика.Волна 1. Первая волна была построена как массовый фишинг. Сценарий — сверка графика отпусков. Для атаки создавали и настраивали пользовательский шаблон. Тип атаки — обычный, время начала рассылки — сразу, при запуске атаки.На этом этапе проверялась базовая реакция сотрудников на привычные рабочие триггеры и способность распознавать типовые признаки фишинга без привязки к конкретному подразделению. Рисунок 1. Шаблон для первой волны Рисунок 2. Вид фишингового письма из первой волны в почте Волна 2. Для каждого отдела были подготовлены письма, основанные на реальных рабочих процессах, характерных запросах и ситуациях, с которыми сотрудники регулярно сталкиваются в своей деятельности. Для атаки создали и настроили пользовательский шаблон, где-то добавили немного визуального оформления. Время начала рассылки — по запланированному времени. Рисунок 3. Пример шаблона из второй волны для отдела «Продажи» Рисунок 4. Вид фишингового письма из второй волны для отдела «Продажи» Волна 3. Здесь моделировались уже более сложные сценарии целевого фишинга (spear phishing). В письмах использовались специальные формулировки, элементы корпоративного брендирования. На этом этапе проверялась не только внимательность сотрудников, но и способность замечать менее очевидные признаки атаки в условиях, максимально приближённых к реальной целевой компрометации.За основу брали системный брендированный шаблон «Яндекс ID», добавили фишинговую форму и скорректировали немного её содержание. Тип атаки — обычный, время начала рассылки — по запланированному времени. Рисунок 5. Пример шаблона из третьей волны Рисунок 6. Вид фишингового письма из третьей волны При переходе по ссылке открывалась фишинговая страница. Рисунок 7. Фишинговая страница Тестирование доставки и отражения результатов в статистикеДалее была подготовлена инфраструктура рассылки. После её настройки проводилось тестирование доставки сообщений. Проверялась доставка писем во входящие сообщения почтовых клиентов, анализировалась реакция антиспам-механизмов в почте, а также контролировалась корректность работы механизмов отслеживания действий пользователей. Рисунок 8. Результаты тестирования доставки и отображения сообщений в почте Тестирование прошло успешно.После завершения проверки была сформирована последовательность отправки сообщений по заранее определённым волнам. Такой подход позволил распределить нагрузку, контролировать ход тестирования и отслеживать реакцию сотрудников на различных этапах проведения проверки. Рисунок 9. Активные мероприятия Результаты атакБыли получены следующие результаты:Иммунность — 81 %. Хороший иммунитет, большинство реагирует правильно. Охват аудитории (повторно попались на фишинг) — 71 %.Уровень риска — 8, средний. Устойчивость формируется, но есть ещё риски. Рисунок 10. Общая информация после проведения первичного тестирования Самый низкий уровень иммунности — около 50 %, после первых двух волн атак. Рисунок 11. График иммунности во время первичного тестирования Далее — сформировали в системе отчёт по скомпрометированности сотрудников, на основании которого выполнили самостоятельный анализ результатов по отделам без учёта результатов тестирования шаблонов атак. Рисунок 12. Отчёт по скомпрометированности всех сотрудников в Phishman 2.35 Таблица 1. Результаты первичного тестирования по отделамОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДокументооборот04,76 %4,76 %Продажи04,76 %9,52 %Продюсеры 0023,8 %Редакция0019,04 %Руководитель000 ОбучениеПервичное тестирование завершено, поэтому следующим этапом стало определение группы риска и формирование программы обучения.Формирование учебной группыНа этапе отбора рассматривались два варианта формирования учебной группы. Первый предполагал использование показателя иммунности сотрудников. Второй вариант заключался в создании правила, автоматически формирующего список сотрудников, которые были скомпрометированы в ходе проведённых проверок. Этот подход позволял сразу получить выборку пользователей, продемонстрировавших наибольшую подверженность атакам, без ожидания обновления показателей.Был выбран второй вариант. На основании созданного правила была сформирована группа для обучения: в неё вошли люди, которые были скомпрометированы в ходе первичного тестирования. Рисунок 13. Создание правила для выявления группы риска Рисунок 14. Отчёт по отработанному правилу для выявления группы риска Отдельно была сформирована группа сотрудников, успешно распознавших фишинговую атаку, для участия в обучении, направленном на поддержание киберкультуры.Составление образовательной программы по повышению киберкультурыПопавшиеся сотрудники были включены в отдельную учебную группу, для которой сформировали персональную образовательную траекторию. В неё вошли 3 микрокурса по фишингу и 1 курс по информационной безопасности. Содержание траектории было направлено на повышение устойчивости к методам социальной инженерии и снижение вероятности компрометации учётных данных. Рисунок 15. Заполнение параметров обучения сотрудников Рисунок 16. Составление учебной программы Отдельно была запущена программа обучения для сотрудников, которые не попали в выборку по результатам правила.Процесс обучения и его результатыПервый отчёт мы сформировали через 2 дня после запуска обучения, что позволило получить предварительную оценку вовлечённости сотрудников. Анализ данных показал, что наибольшую активность на начальном этапе продемонстрировали сотрудники, которые попались на фишинг. Рисунок 17. Промежуточный анализ обучения Через неделю после запуска обучения провели повторный анализ прогресса, включая оценку прохождения курсов и выявление участников, не приступивших к обучению. Рисунок 18. Отчёт по динамике обучения в Phishman 2.35 Анализ показал, что часть сотрудников не завершила обучение в установленный срок. Для обеспечения максимального охвата было принято решение о продлении сроков прохождения курсов. Рисунок 19. Продление и корректировка процесса обучения В результате фактическая продолжительность обучения составила 2 недели, что превысило первоначально установленный срок в одну неделю. Но и этого времени не хватило нашим сотрудникам. Чтобы узнать, кто оказался более ответственным, воспользовались возможностями правил. Рисунок 20. Пример настройки правила по выявлению сотрудников, прошедших обучение В результате была получена информация о сотрудниках, полностью и частично прошедших обучение. Рисунок 21. Отчёт по сработанному правилу по выявлению сотрудников, прошедших обучение Рисунок 22. Отчёт по сработанному правилу по выявлению сотрудников, частично прошедших обучение Результаты обучения:полностью прошли обучение — 52 %;частично — 22 %;не прошли обучение — 26 %.Мы проанализировали список сотрудников, не приступивших к обучению, и выяснили, что это те, кто не попался на фишинг во время первичного тестирования.Среди сотрудников, которые попались на фишинг, 80 % прошли обучение, остальные — прошли его частично. Рисунок 23. Результаты обучения сотрудников «АМ Медиа» Вместе с тем за этот период были зафиксированы положительные изменения в ключевых показателях: уровень обученности достиг 9 319 баллов, а показатель киберосознанности — 7 561 баллов. Несмотря на положительную динамику, полученные значения оставались гораздо ниже целевых ориентиров, что свидетельствует о необходимости дальнейшей работы по повышению вовлечённости сотрудников и развитию киберкультуры.Повторное тестированиеПовторное тестирование проводилось по тем же этапам, что и первичное: подготовка шаблонов, тестирование и проведение атак. Как и на первом этапе, основной задачей было сделать письмо максимально похожим на стандартную рабочую переписку, соответствующую реальным бизнес-процессам нашей компании.Подготовительный этап повторного тестирования потребовал дополнительных временных затрат, связанных с регистрацией новых доменов и расширением сценариев атак с учётом результатов первичного тестирования.Волна 1. Сценарии формировались не только для отдельных подразделений, но и адресно для конкретных сотрудников, что позволило повысить реалистичность и точность имитации фишинговых атак. Запустили несколько атак, для каждой из них были разработаны индивидуальные шаблоны электронных писем и соответствующие фишинговые формы. Тип атаки — обычный, время начала рассылки — по запланированному времени. Рисунок 24. Пример фишингового письма для первой волны Рисунок 25. Пример фишинговой формы для письма из первой волны Волна 2. Вторая волна представляла собой массовую фишинговую кампанию. Для неё был создан и настроен пользовательский шаблон, основанный на триггерах срочности и страхе финансовых потерь. Тип атаки — обычный, время начала рассылки — сразу, при запуске атаки. Рисунок 26. Пример фишингового письма для второй волны Тестирование доставки писем и корректности отражения результатов в статистике прошло успешно.Результаты атакВ повторном тестировании приняли участие уже 23 человека. Увеличение числа участников на 2 человека связано с подключением новых сотрудников к нашему эксперименту. Резких скачков иммунности здесь не наблюдалось. Рисунок 27. График иммунности во время повторного тестирования Для дополнительной оценки мы и здесь также выполнили самостоятельный анализ результатов по отделам без учёта результатов тестирования шаблонов атак. Таблица 2. Результаты повторного тестирования по отделамОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДокументооборот000Продажи008,7 %Продюсеры 008,7 %Редакция8,7 %08,7 %Руководитель000 Мы также посмотрели, как себя показали сотрудники, которые не прошли обучение, в повторном фишинговом тесте. По данным отчёта, в первой волне повторного тестирования на фишинг попались 40% из всех, кто не обучался. Рисунок 28. Поиск информации о сотруднике в отчёте по атакам Подведение итогов После завершения всех этапов эксперимента мы получили следующие показатели:Иммунность — 76 %. Хороший иммунитет, большинство реагирует правильно. Охват аудитории (повторно попались на фишинг) — 91,3 %.Уровень риска — 7, средний. Рисунок 29. Информационная панель Phishman 2.35 после завершения эксперимента После обучения и повторного тестирования добавились другие показатели:Обученность — 11 / 100. Знания отсутствуют, обучение следует начать с базового уровня.Киберосознанность — 10 / 100. Низкий уровень, сотрудники не знают, как действовать в случае угроз.Часть результатов сравнили и представили их в таблице ниже. Таблица 3. Сравнение показателей киберкультуры до и после обученияПоказательДо обученияПосле обученияОбученность09319Иммунность81 %76 %Киберосознанность 07561Охват аудитории (повторно попались на фишинг)71 %91,3 %Уровень риска87 Также проанализировали действия сотрудников после обучения и сравнили их с результатами первичного тестирования. Таблица 4. Сравнение действий сотрудников до обучения и послеОтделЗаполнили формуОткрыли вложенияОткрыли ссылкуДо обученияПосле обученияДо обученияПосле обученияДо обученияПосле обученияДокументооборот004,76 %04,76 %0Продажи004,76 %09,52 %8,7 %Продюсеры 000023,8 %8,7 %Редакция08,7 %0019,04 %8,7 %Руководитель000000 Рисунок 30. Процент попавшихся на фишинг до обучения и после по отделам Если во время первичного тестирования попалось 22 % участников, то после обучения этот показатель уменьшился и стал 12 %. Рисунок 31. Общий процент попавшихся на фишинг до обучения и после Результаты повторного тестирования показали, что, несмотря на заметное снижение количества взаимодействий с фишинговыми письмами, часть сотрудников по-прежнему выполняет действия, свидетельствующие о подверженности атакам. Это ожидаемый результат, поскольку киберкультуру невозможно сформировать за столь короткое время. Речь идёт о длительном процессе, который требует регулярной работы как со стороны специалистов по информационной безопасности, так и со стороны самих сотрудников.Наш эксперимент позволил проверить знания сотрудников, провести обучение и затем оценить, насколько полученные знания закрепились на практике. Однако с точки зрения развития киберкультуры — это лишь один из этапов работы, а не её завершение.Сложности, с которыми мы столкнулисьОсобенность нашего эксперимента — организация предварительного тестирования. Перед запуском каждой атаки мы проверяли её работу на собственном аккаунте, чтобы убедиться в корректной отработке сценария на стороне пользователя. Такие проверки попадали в общую статистику системы и оказывали влияние на итоговые показатели. Возможность исключить подобные события из расчётов отсутствует. Согласно комментариям вендора, для этих целей следует использовать отдельный тестовый стенд. Поэтому мы вели дополнительно самостоятельный анализ результатов эксперимента.Отдельные сложности возникли на этапе обучения сотрудников. Завершить обучение в установленные сроки не удалось из-за человеческого фактора. Не все участники смогли своевременно пройти назначенные материалы, что потребовало увеличения периода обучения и дополнительного контроля за его прохождением.Впечатления от проекта команды «АМ Медиа»Проведение тестирования не вызвало негативной реакции со стороны сотрудников. Хотя фишинговые сообщения активно обсуждались внутри коллектива, жалоб руководству или недовольства вида «зачем вообще было устраивать такую проверку» не возникло. Основной интерес был сосредоточен вокруг самих писем и попыток понять, что именно происходит.Реакция сотрудниковОдним из самых любопытных наблюдений стала реакция сотрудников после первой волны первичного тестирования. Полученные фишинговые сообщения быстро стали предметом обсуждения: сотрудники пересылали их друг другу, задавали вопросы коллегам и пытались разобраться, что происходит.Некоторые пошли ещё дальше и вступали в переписку с отправителем, воспринимая фишинговые письма как реальные рабочие сообщения. Это наглядно показало не только убедительность используемых сценариев, но и то, что практическое столкновение с угрозой вовлекает сотрудников в тему ИБ гораздо сильнее, чем абстрактные примеры из учебных материалов. Во время повторного тестирования такой реакции уже не возникло.Реакция организаторовЕсли для большинства сотрудников тестирование выглядело как неожиданно появившиеся письма в почте, то для команды, которой было поручено тестирование Phishman 2.35 этот проект сопровождался совсем другими эмоциями. Подготовка сценариев, запуск атак и ожидание результатов вызывали ощутимое волнение. Оказалось, что смотреть на ситуацию глазами злоумышленника не так просто, как может показаться со стороны. Приходилось постоянно задавать себе вопросы: какой сценарий покажется правдоподобным, что привлечёт внимание сотрудника, а что, наоборот, вызовет подозрения.Самыми напряжёнными были дни первой волны тестирования. На этом этапе ещё не было понимания, как сотрудники отреагируют на рассылки, насколько убедительными окажутся сценарии и не вызовет ли проверка негативной реакции внутри коллектива. С каждой новой зафиксированной активностью интерес смешивался с тревогой, а результаты ожидались едва ли не с большим нетерпением, чем сам запуск кампании.После завершения эксперимента стало легче: всё задуманное удалось реализовать, результаты были получены и проанализированы. Тем не менее полностью избавиться от мыслей о проделанной работе не получилось. Время от времени возвращаешься к отдельным этапам и задаёшься вопросом: а стоило ли сделать именно так? Может быть, какой-то сценарий можно было построить иначе, а какие-то решения принять по-другому?Наверное, это естественная часть любого практического проекта. Когда работа заканчивается, появляется возможность посмотреть на неё со стороны и критически оценить собственные решения. Именно в такие моменты часто приходят идеи, которые помогают сделать следующие проекты лучше.Сотрудничество с вендоромВ ходе подготовки и проведения эксперимента иногда возникали вопросы, связанные с настройкой платформы, особенностями реализации отдельных сценариев и интерпретацией результатов. Для их решения использовались как переписка, так и рабочие созвоны. Запросы обрабатывались оперативно, что позволяло своевременно получать необходимую информацию и не допускать задержек в выполнении работ. Поддержка была доступна не только в рабочее время, но и в выходные дни.ВыводыПовторное тестирование показало, что тщательно подготовленные и персонализированные фишинговые атаки значительно эффективнее. При наличии качественной разведки злоумышленники способны подобрать убедительный сценарий практически для любого сотрудника. А если специалист может ошибиться, то сотруднику, который не занимается вопросами ИБ каждый день, сделать это ещё проще.Работа в сфере информационной безопасности или информационных технологий сама по себе не защищает человека от фишинга, социальной инженерии и других современных атак. Мы убедились в этом на собственном опыте: даже профильные знания не гарантируют, что человек не попадется на хорошо продуманную атаку. Злоумышленники постоянно меняют сценарии, поэтому знания, полученные однажды, быстро устаревают.При помощи эксперимента мы не только проверили, насколько сотрудники готовы распознавать атаки, но и поняли, как с помощью Phishman 2.35 можно сделать работу по развитию киберкультуры системной. Вместо отдельных курсов появился понятный цикл: смоделировать атаку, оценить реакцию, провести обучение и проверить, изменилось ли поведение участников. При необходимости — повторить или скорректировать процесс при помощи рекомендаций платформы. Результаты фиксируются автоматически, поэтому можно видеть, какие темы требуют больше внимания, и развивать киберкультуру на основе реальных данных, а не предположений.Читать далее
    • PR55.RP55
×