Самозащита АВ полная туфта - Тесты и сравнения - Форумы Anti-Malware.ru Перейти к содержанию
Мутный

Самозащита АВ полная туфта

Recommended Posts

Мутный

Всем привет, интересно мнение экспертов ! :)

 

Итак на одном ресурсе был произведён тест на самозащиту, саму ссылку скину чуть ниже, сейчас-же суть теста и немного результатов (Сводная таблица) !

 

Итак:

 

Чуть менее двух лет назад на форуме Касперского пользователь сообщал от том, что сервис KIS 2014 легко останавливается утилитой Process Hacker, невзирая на самозащиту. От администрации он получил ответ, что проблема вскоре будет устранена. И это притом, что задолго до этого у себя на сайте Касперский рапортовал об успешном противодействии KIS 2012 этой утилите:

 

ph-kis.jpg

 

Давайте посмотрим, как сейчас обстоят дела с самозащитой у Касперского, а заодно и у других популярных антивирусов.
Будем использовать Process Hacker v 2.36 – бесплатный и абсолютно легальный менеджер задач и ресурсов, работающий с ядром ОС через Native API (API ядра).

Условия тестирования
  • для KIS использовалась ОС Windows 10, для остальных — Windows 7 Максимальная SP1 x64
  • использовались стандартные варианты установки и настройки, за исключением Касперского и DrWeb — в них дополнительно были установлены пароли на доступ к управлению
  • текущий пользователь состоял в группе Администраторы, Process Hacker запускался через пункт Запуск от имени администратора
Методика тестирования
  • был создан текстовый файл с содержимым «X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*», переименован в исполняемый eicar.com и запакован в архив с паролем
  • файл распаковывался и запускался, мы убеждались в работоспособности антивируса — файл либо удалялся, либо блокировался
  • производились попытки остановить процесс службы защиты в реальном времени антивируса — Terminate (в некоторых случаях — Terminate Tree, ниже указывается отдельно), а также приостановить его работу — Suspend с последующим возобновлением — Resume
  • файл снова распаковывался, и либо запускался, либо продолжал блокироваться антивирусом

Манипулировать процессами можно как в ручном режиме, так и из командной строки. Например:
ProcessHacker.exe -c -ctype process -cobject dwengine.exe -caction terminate
ProcessHacker.exe -c -ctype process -cobject dwengine.exe -caction suspend

 

Тестируемые антивирусы
  1. Avast! Free Antivirus 10.4.2233
  2. Avira Antivirus 15.0.13.210
  3. Dr.Web Security Space 11.0
  4. ESET NOD32 Antivirus 9.318.24
  5. Kaspersky Endpoint Security 10 SP1 10.2.2.10535
  6. Kaspersky Internet Security 16.0.0.614
  7. McAfee Internet Security (McAfee SecurityCenter 14.0.1029, Защита от вирусов и шпионских программ McAfee 18.0.204)
  8. Norton Internet Security 22.5.4.24
  9. 360 Total Security 8.0.0.1046

Более подробно можно почитать здесь:http://ajc.su/antivirusy/testirovanie-samozashhity-antivirusov-2015/

 

А теперь сводная таблица:

 

result.jpg

 

Очень огорчили Др. Веб и Каспер, причём каспера так вообще можно вырубить... :(

 

Порадовали Аваст, Эзет и старый "Друг" Нортон, хотел сообщить об этом клубу весёлых и находчивых, клубу симантек, но думаю они итак всё знает ибо по другому и быть не может, гы-гы ! :)

 

Меня-же разочаровал Доктор ибо ИМХО там самая паранаидальная самозащита, т.е. капча и т.д., я даже не поверил, проверил, к сожаления да всё-так и есть :(

 

Вот ролик:

 

 

 

  • Upvote 2

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


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

В этом тесте http://ajc.su/antivirusy/testirovanie-samozashhity-antivirusov-2015/ какая программа была установлена первой - антивирусная или Process Hacker 2.36 ?

 

Я установил Avast! Free Antivirus, потом установил Process Hacker 2.36, попробовал завершить процесс Avastsvc.exe и AvastUI - не получилось. Затем я удалил обе программы, установил сначала Process Hacker 2.36 , потом установил Avast! Free Antivirus - и смог завершить эти процессы.

 

С Kaspersky Internet Security 16.0.0.614 было точно также. Если установить касперского, а потом установить Process Hacker 2.36, то не получится завершить процесс avp.exe и avpui.exe .

Отредактировал Runt

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


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

А зачем утанавливать ? Есть-же потабл версия !

 

Незнаю как там, я когда доктора тестил, потабл версией, разумеется запускал уже на установленного доктора, так правильней, "Это имитирует поведение вируса" ! :)

 

ИМХО, но мне кажется это не должно влиять (Очередность, что ставить !), если только у АВ в самозащите что-то в доверенное не попадает, может цифровая подпись или ещё что ?

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


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

В архиве "KIS ProcessHacker 1.zip" 2 скриншота, там видно в программе AVZ, что в одном случае Process Hacker не смог загрузить в пространство ядра модуль "kprocesshacker.sys" и не может завершить процесс "avp.exe" (когда первым был запущен KIS, который запретил это, а потом был запущен Process Hacker), а во втором случае этот модуль уже загружен, первым был запущен Process Hacker, а потом KIS, и Process Hacker может завершить процесс "avp.exe" .

 

Видимо, в том тесте в разном порядке запускали эти программы - в одних случаях сначала антивирус, а потом Process Hacker, а в других случаях сначала Process Hacker, а потом антивирус ставили.

 

В Доктор вебе если в настройках превентивной защиты запретить загрузку того модуля, то Process Hacker уже не может завершить работу антивируса. А с настройками по умолчанию, Доктор веб разрешает загрузку того модуля, так как Process Hacker - это легальная программа, а не троянская, наверно так.

 

Наверно, тот тест неправильно проведён. Антивирус может распознать программу ProcessHacker как легальную, и разрешить загрузку модуля, это предположение.

KIS ProcessHacker 1.zip

KIS ProcessHacker 1.zip

Отредактировал Runt

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


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

Упрощенно:

 

Есть два способа (условных) прибития процессов в винде:

1. С уровня пользователя

2. Из драйвера

 

Теперь о них подробнее

Первый способ:

На антималваре в тестах есть тест на самозащиту - там тестировались способы самозащиты от завершения процессов из юзермода (user mode) - многие техники там применены и можно посмотреть таблички и т.д. Суть методов: разными ухищрениями заставить процесс перестать работать. Приводит это обычно только к убийству GUI-интерфейса, что не приводит обычно к ослаблению защиты, а только может доставить некоторые неудобства пользователю.

 

Второй способ:

Загружается драйвер и из ядра каким-либо способом прибивается процесс. Тут все просто - либо антивирус дал загрузиться драйверу, либо не дал. Если дал загрузиться драйверу (поняв, что это приложение кошерно и дружелюбно или просто "зевнув"), то дальнейшее сопротивление фактически бесполезно.

 

Обсуждение такое вяло по одной простой причине - новички от этого далеки, а старперам это скучно - обмусолена тема неоднократно.

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


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

Тащем-то первое, что нужно сделать было с процессхакером - изменить md5. Например в строке This program can not be run... поменять одну букву.

Ну и да, установка антивируса на уже заражённую систему - не совсем то. Так-то антивирусы нормальные пытаются обработать эту ситуацию, но здесь автору "теста" нужно было бы определиться, что именно он пытается проверить.

 

В мусорку, в общем.

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


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

Тащем-то первое, что нужно сделать было с процессхакером - изменить md5. Например в строке This program can not be run... поменять одну букву.

 

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

 

 

А вообще конечно, если цель защитить какой-то АВ можно вспомнить про UAC и про ограничение пользователей, другое дело если использовать UAC и ограничение пользователей, то зачем тогда АВ с ихней самозащитой ! :)

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


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

то зачем тогда АВ с ихней самозащитой !

Зачем _нам_ АВ - и я согласен.

А вот матери поставил.

  • Upvote 1

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


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

Я не являюсь авероненавистником, также-как и не являюсь фаном какого-то АВ !

 

Но если честно, то большинство АВ уже перестали развиваться, однако ценообразование у них не понятно на чём основанно, не но понятно что продавать можно всё что покупают, но всё-таки за качеством своих поделок тоже не плохо-бы следить... :(

 

Этот пост меньше про каспера и больше про доктор веп ! :(:(:(

 

Я в ролики не стал делать, но видели что процесс перезапускается после его завершения, так-вот если в момент перезапуска завершить его (По быстрее сделать "Terminate" в процесс-хакере, то этот веп вообще уйдёт в небытие....) !

 

А-так конечно от каких-то угроз защитит, тут можно вечно обсуждать, на каждый аргумент можно сделать контръаргумент, но вот на сколько такие "уязвимости" могут скомпроментировать защиту, в теории-то можно сделать прогу, которая будет добовлять вирус в исключения АВ, пока он отключон, или вообще удалять его... :)

 

Единственное это всё нужно запускать с правами админа... ;)

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


Ссылка на сообщение
Поделиться на другие сайты
priv8v
 в теории-то можно сделать прогу, которая будет добовлять вирус в исключения АВ, пока он отключон, или вообще удалять его... :)

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

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


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

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

Ну а доктор что не нормальный АВ ?

 

Dwengine.exe спокойно вырубается, также как и все процессы доктора... :)

 

То-что тестил я на 7-ке x64, UAC отключон, запуск с правами админа...

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


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

Вы проверили перестают ли функционировать мной вышеперечисленные защитные функции (хоть какие-то) при прибивании процессов доктора или просто предполагаете, что завершение его процессов ведет к полному отключению его функционала?

 

Проверить достаточно просто:

0. Имеем антивирус в обычном режиме

1. Берем еикар в запароленном архиве

2. Извлекаем, вводим пароль

3. Смотрим, что происходит (удаляется или нет, дает открыть в блокноте или нет)

 

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

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


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

Вы проверили перестают ли функционировать мной вышеперечисленные защитные функции (хоть какие-то) при прибивании процессов доктора или просто предполагаете, что завершение его процессов ведет к полному отключению его функционала?

Так я вроде в ролике это продемонстрировал нет ? ;)

 

Это была демонстрация долгова перезапуска этого сервиса !

 

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

 

Другие АВ лень проверять, но думаю будет тоже самое в целом ! :(

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


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

Вы проверили перестают ли функционировать мной вышеперечисленные защитные функции (хоть какие-то) при прибивании процессов доктора или просто предполагаете, что завершение его процессов ведет к полному отключению его функционала?

Сейчас ещё раз перечитал методику теста, тоже самое:

 

Методика тестирования
  • был создан текстовый файл с содержимым «X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*», переименован в исполняемый eicar.com и запакован в архив с паролем
  • файл распаковывался и запускался, мы убеждались в работоспособности антивируса — файл либо удалялся, либо блокировался
  • производились попытки остановить процесс службы защиты в реальном времени антивируса — Terminate (в некоторых случаях — Terminate Tree, ниже указывается отдельно), а также приостановить его работу — Suspend с последующим возобновлением — Resume
  • файл снова распаковывался, и либо запускался, либо продолжал блокироваться антивирусом.

Здесь было предположение, что ProcessHacker имеет цифровую подпись, поэтому не блокируется самозащитой, для меня это показалось странным и я проверил на вебе, добавив в конец экзешника ProcessHacker произвольный байт и доктор также "Отключался" (Смотри ролик в посте #7), отмечу что тестировал последнюю версию веба, к сожалению не имею возможности потестить другие ав, т.к. у меня установлен веп...

 

Я не имею к этому тесту никакого отношения, но считаю что всё написанное имеет место на существования, либо аргументируйте иначе, так-же как я с пруфами, а как это должно в описании ав быть, мне известно, также я прикрасно знаю отличие гуи интерфейса, от от процессов которые отвечают за сканер, антируткит и т.д. ! :)

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


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

О том и толкую...

Вот о том в тесте и пишут: что у некоторых АВ прибитие процесса не влияет на сигнатурную защиту, а у каких-то влияет. Но я не нашел уточнений по поводу с уровня ядра прибивался процесс или нет. Если с уровня ядра - говорить вообще не о чем тут. Если с уровня пользователя - тут хотя бы можно кинуть в ЛК репорт чтоб они его перевели в таск с невысоким приоритетом, что де вот тут есть способ, где с юзермода можно процесс прибить и это как-то нехорошо...

 

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

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


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

Убивает Process Hacker одним из методов Касперского и какие-то другие антивирусы. Что с того? Это лишь один из методов, по нему нельзя делать выводы о качестве самозащиты. Нашли дыру - молодцы!

 

Мы в свое время делали несколько тестов на самозащиту и потом просто устали - результат один и тот же.

 

Вот они тут все http://www.anti-malware.ru/taxonomy/term/290

 

И вот развитие этого теста на более серьезном уровне https://www.anti-malware.ru/firewall_test_outbound_protection_2013(там не только самозащита)

 

Как мы видим, почти все тупо забивают на самозащиту. Лишь некоторые что-то на эту тему делают. 

 

*******

 

P.S. А почему Касперского тестировали одного на  Windows 10? Чтобы проще было снести? :)

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


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

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

А смысл ?

 

У каспера есть модуль по мойму называется "Контроль программ", кратко фишка в том, что он в зависимости от настроек определяет программу и запускает её с "Пониженными привелегиями", примерно тоже делает и UAC, если программе нужно запустится с повышением прав, то должен-быть запрос на это... :)

 

Так-вот, вполне вероятно, если сбить цифровую подпись процесс-хакера, то он запустится с какими-то ограниченными правами и несможет завершить процессы АВ, НО это нужно проверить, у меня к сожалению нет такой возможности сейчас, у кого стоит каспер, проверьте времени много это не займёт, но будет хоть какая-то ясность в этом вопросе...

 

НО появляется несколько уточнений (ИМХО):

 

1. Тест "Самозащиты" не должен зависить от других модулей, т.е. реакция "Контроля программ" это одно, реакция самозащиты это другое;

 

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

 

Теперь про доктора, там вообще такого модуля нет ("Контроль программ"), там есть так называемая "Превентивная защита", но она строится на превентивных блокировках, т.е. например блок файла хостс и т.д., поэтому-да тут хоть сбивай ЦП, хоть нет один фиг... :)

 

Это если только брандмауер проверять на дефолтных настройках, там это учитывается... :(

 

Мы в свое время делали несколько тестов на самозащиту и потом просто устали - результат один и тот же.

 

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

 

Вот они тут все

 

Почитаю, а Вы чем убивали процессы, сами писали, или что-то типо процесс-хакера, лучше может даже чем-то другим ещё потестить... :)

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


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

 

 

1. Тест "Самозащиты" не должен зависить от других модулей, т.е. реакция "Контроля программ" это одно, реакция самозащиты это другое;

 

Теперь про доктора, там вообще такого модуля нет ("Контроль программ"), там есть так называемая "Превентивная защита", но она строится на превентивных блокировках, т.е. например блок файла хостс и т.д., поэтому-да тут хоть сбивай ЦП, хоть нет один фиг... :)

 

 Мутный, уточните, на что должна быть реакция "Контроля программ" ? И на что должна быть реакция самозащиты ? Вы уверены, что чётко себе представляете, как это устроено и работает - самозащита, Контроль программ, Превентивная защита.

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


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

 Мутный, уточните, на что должна быть реакция "Контроля программ" ? И на что должна быть реакция самозащиты ? Вы уверены, что чётко себе представляете, как это устроено и работает - самозащита, Контроль программ, Превентивная защита.

Вы говорите о каспере, или о каком-то другом АВ ? Реакция у каждого АВ может быть разной, в зависимости ктстати и от настроек тоже...

 

Но давайте уточню на примере веба и каспера, т.к. работал с ними, с каспером правда давно уже не работал, но помню как-там и что !

 

Так вот в начале определимся с понятиями, как я понимаю что такое "Контроль программ", "Самозащита" и "Превентивная защита", с точки зрения каспера:

 

1)Контроль программ - Это модуль который отвечает за ограничение прав доступа запущенных программ, если по простому то как минимум там должно отслеживаться: Доступ к файловой системе, системному реестру и взаимодействие с другими программами.

 

В новых версиях незнаю как устроенно, но раньше там было несколько групп, из тех-что помню:

 

- Доверенная группа, туда помещаются системные программы с цифровой подписью, а также другие по мнению ЛК доверенные программы, в этой группе максимальные права доступа к системе;

 

- Далее идут промежуточные группы и "Недоверенная группа" где будут уже ограничения на какие-то действия программ, как пример программа "X", которая попала по какой-то причине в зависимости от настроек в группу "Недоверенная группа", несможет удалить системную папку, несможет войти в сеть и т.д.

 

Как я уже сказал примерно также действует UAC, только там не несколько групп, а запуск приложения с ограниченными полномочиями, по сути UAC это "Урезанный" контроль программ... ;)

 

2)Самозащита - Это защита АВ от завершения процессов, защита реестра и файлов от изменения...

 

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

 

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

 

Как-то так если в кратце !

 

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

 

И ещё раз повторюсь, на разных компах может-быть разная конфигурация АВ, где-то может-быть включён "Контроль программ", где-то нет, так-же как и UAC может и не быть включон на каких-то системах... :(

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


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

Почитаю, а Вы чем убивали процессы, сами писали, или что-то типо процесс-хакера, лучше может даже чем-то другим ещё потестить...

 

У нас свой набор утилит для такого теста.

 

P.S. А почему Касперского тестировали одного на  Windows 10? Чтобы проще было снести?

 

Почему условия то разные для некоторых антивирусов?

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


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

Почему условия то разные для некоторых антивирусов?

Я к этому тесту отношения не имею, поэтому если вопрос ко мне, то не могу знать ! :)

 

Выложил просто как инфа к обсуждению...

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


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

Мы тут думаем самозащиту потестировать в рамках теста на проактивную защиту, аналоге такого вот теста https://www.anti-malware.ru/firewall_test_outbound_protection_2013 

 

Актуальная тема, стоит делать?

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


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

Только сейчас прочитал пост !

Там ссылка битая, но зашёл:https://www.anti-malware.ru/firewall_test_outbound_protection_2013

Было-бы интересно, только прикольно будет если распишите какие-бывают атаки, т.е. технически, в той статье типы атак:

Внешние атаки на защищённую фаерволом систему:

  • инициированные хакерами;
  • инициированные вредоносным кодом.

Неавторизованные исходящие сетевые соединения:

  • инициированные недоверенными приложениями (вредоносный код);
  • инициированные приложениями, сетевая активность которых явным образом запрещена правилами.

Тест проводился по следующим направлениям:

  • Проверка защиты процессов от завершения.
  • Защита от стандартных внутренних атак.
  • Тестирование защиты от нестандартных утечек.
  • Тестирование защиты от нестандартных техник проникновения в режим ядра.

Вот и интересно было-бы узнать как проводились такие атаки, пусть даже и в теории без выкладывания кода и т.д. !

А-то ИМХО неочень интересно, потом идут цифры проценты и т.д., а если-бы было описание, во первых в информационном плане интересно какие вообще бывают атаки, а во вторых было-бы видно опасность пропуска этих атак, т.е. некоторые атаки могут-быть незначительными, а некоторые опасными и т.д.

Работа такая очень ресурсоёмкая, но если есть спецы и сделаете, то прикольно будет !

Всех с праздниками кстати ! :)

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


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин
В 05.01.2016 at 6:09 PM, Мутный сказал:

Было-бы интересно, только прикольно будет если распишите какие-бывают атаки, т.е. технически, в той статье типы атак:

Так все же расписано здесь https://www.anti-malware.ru/node/12180

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


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

На мой взгляд то, что Process Hacker выгружает антивирусы - явление нормальное, потому что Process Hacker - легитимная программа (по мнению некоторых вендоров -  потенциально опасная), а не троянская, и  команду на выгрузку антивируса даёт сам пользователь ( выбрав процесс в списке и нажимая "Terminate"), то есть это действие (завершение процесса, отвечающего за работу антивируса) санкционировано самим пользователем.

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


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

  • Сообщения

    • Ego Dekker
      ESET Online Scanner был обновлён до версии 4.0.1. Приложение теперь работает только в 64-разрядной ОС.
    • 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
    • santy
      RP55, есть у тебя ТГ?
×