Новые функции в Universal Virus Sniffer (uVS) - Страница 42 - Universal Virus Sniffer (uVS) - развитие, использование и решение проблем - Форумы Anti-Malware.ru Перейти к содержанию

Recommended Posts

santy

будут белые критерии, будет больше возможностей по автоматической корректировке скрипта. + комбинированный детект сигнатур и критериев (в какой то форме) можно будет реализовать.

добавлю что есть идеи правильные и есть тупиковые.

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

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

удаление всего из текущей категории - это тупиковая идея. мало того что ситуация с удалением невоспроизводимая (нет основания для удаления файлов в самом скрипте - на основании чего это удаляется: проверка ВТ, сигнатуры, критерии, внешние проверки в КСН, herdprotectScan? хз. абстрактный оператор об этом молчит), она еще и бесперспективная в плане автоматического создания скрипта.

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


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

Команда может работать для всех: url объектов.

В том числе и в автоматическом режиме.

-------

команда: "Удалить все файлы в текущей категории"

Следует понимать, что команда может работать так: "Удалить все файлы в текущей категории ( с учётом фильтрата ) "

т.е. можно, при фильтрации удалить все ?ВИРУС?

как объект получил/получает статус ?ВИРУС? - ?

По результату проверки на V.T...

По результату работы поискового критерия...

Критерий в частности может быть основан на цифровой подписи/производителе.

----

Можно работать и без критерия.

По производителю.

Задали производителя > получили список состоящий только из одного производителя например: Ask***

И применив одну команду удалили все объекты/файлы от данного производителя.

---

А в принципе - решение за оператором, что и как ему в текущей ситуации делать - какое принять решение - какой сделать выбор.

---

И здесь нет сигнатур.

здесь нет автоспорта.

---

т.е. минимизация первичных операций.

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


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

Недавно были непонятки.

по .sys файлу: http://www.anti-malware.ru/forum/index.php...st&p=178694

Который, как оказалось не был исполняемым.

А относился к - sys файлам типа: "текстовый или содержит какие-то данные"

Если несколько человек посмотрели Инфо. ...

И с ходу этого не поняли...

Это серьёзный недостаток.

Оператор с полу-взгляда должен видеть с чем он имеет дело.

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

без: "можно догадаться"

дело серьёзное.

А в серьёзном деле такие выражения, как ДОГАДАТЬСЯ не подходя.

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


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

1)

         deltmpdelnfrczoorestart  ; Всего знаков кода: 4987; Установленный лимит знаков кода: 5000

Суть в том, что на ряде форумов есть ограничение на число символов.

Логика: Оператор пишет скрипт > Открывает окно сохранения скрипта > Видит, что скрипт нуждается в корректировке = сокращении числа строк/символов кода.

Или же строк так много, что нужно сохранять в файл.

Или видит - скрипт может быть размещён на форуме так, как есть.

Лимит знаков кода прописывается в: settings.ini

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


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

demkd,

сейчас распространена проблема Search with Bing

как правило в образах есть три файла

HKLM\System\CurrentControlSet\Services\NetHttpService\ImagePath

C:\Windows\SysWOW64\nethtsrv.exe

HKLM\System\CurrentControlSet\Services\nethfdrv\ImagePath

\??\C:\Windows\system32\drivers\nethfdrv.sys

HKLM\System\CurrentControlSet\Services\ServiceUpdater\ImagePath

C:\Windows\SysWOW64\netupdsrv.exe

--------------

скажем создал я критерий Search with Bing

и добавил в него условие

ссылка~ \Services\nethfdrv\

и хочу расширить этот критерий, добавив еще пару условий по другим файлам.

сейчас это можно сделать, редактированием в списке критериев. находим критерий Seach with Bing и добавляем вручную другие условия.

предлагаю расширить возможности редактирования критерия из окна "Инфо" следующим образом.

- добавить в контекстное меню фунцию "выбрать текущий критерий из списка"

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

---------

сейчас текущий критерий (в окне Инфо) можно выбрать из тех критериев, которые были выведены по данному объекту.

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


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

1) Предложение см. фото.

Ещё бы на выбор из меню для колонки производитель.

Для основных.

Abode

Microsoft

Майкрософт

Google

Nvidia

------

Суть идеи - быстрое переключение/выбор между объектами.

Без набора поискового запроса и без переключения раскладки клавиатуры.

111.jpg

post-8956-1403619026_thumb.jpg

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


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

RP55,

Суть идеи - быстрое переключение/выбор между объектами.

Без набора поискового запроса и без переключения раскладки клавиатуры.

быстрее будет вбить одну букву в запрос. Аналогично и по статусу.

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


Ссылка на сообщение
Поделиться на другие сайты
alamor
4) Добавить в окно сохранения скрипта кнопку: "Скрипт отредактирован - сохранить изменения. "

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

+1, полезная фича.

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


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

1) Критерии поиска.

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

Это группы:

a) ADWARE

б) VIRUS

c) Сеть

d) Информационные/уведомительные/предупреждения.

Теперь о каждой группе и о критериях поиска.

a) ADWARE - Определяются по:

Типу ( плагины ); По цифровой подписи; По известному имени файла/программы.

Надёжность этого типа критериев близка к 100%

т.е. Ложных определений по ним практически нет.

От этих объектов не зависит целостность системы.

Их случайное/преднамеренное удаление не наносит вреда системе.

б) VIRUS - Определяются по:

Многим признакам.

Это Ключи автозапуска, как постоянные так и временные: старт объекта из временного каталога; нетипичная директория объекта;

И сотни других параметров.

Создаются сложные/составные критерии.

Для определения одного вируса может быть задано несколько критериев.

Надёжность этого типа критериев: Не превышает 75 %

Вирусы маскируются и лучше перестраховаться чем пропустить угрозу.

Удаление может причинить значительный вред операционной системе.

Требуется проверка и перепроверка данных !

c) Сеть:

Работа с устойчивыми признаками.

hosts;DNS;стартовые страницы; IP; прокси ...

Надёжность этого типа критериев близка к: 98%

От этих объектов не зависит целостность системы.

Их случайное/преднамеренное удаление практически не наносит вред системе.

d) Информационные/уведомительные/предупреждения.

Например на выявление установленных антивирусных продуктов ( их потенциальных конфликтов )

Легальных программ слежения за PC; по некоторым системным обновлениям; конфликтующим программам; устаревшему софту; программам удалённого подключения

и т.д.

Надёжность критериев высокая.

От этих объектов, как правило не зависит целостность системы.

Но, клиенту может быть нанесён материальный ущерб.

----------

Как же работает uVS с этими группами...

Все найденные объекты получают статус: ?ВИРУС?

т.е. они равны.

Что есть сейчас в меню программы ?

Смотрим: Тесты > Проверить список по пользовательской базе признаков...

т.е. команда проверяет по всем _ЧЕТЫРЁМ_ типам одновременно и выдаёт один вердикт: ?ВИРУС?

Четыре типа... А вердикт один...

Что является серьёзной недоработкой - которую необходимо исправить.

Как это сделать ВАРИАНТЫ:

1) Вариант

При формировании поискового критерия Оператор задаёт имя критерия.

пример:....| СТАТУС |

ADWARE - ADWARE 1

.................ADWARE 17

.................ADWARE 20

----

VIRUS -.... VIRUS SPY

................VIRUS AutoRun

................VIRUS Sality

-----

Сеть - .... Сеть Левый IP

................Сеть Левый DNS

-----

В итоге в колонке | СТАТУС |

каждый объект получает ВЕРНЫЙ статус...

Применив фильтр/поиск - мы можем получить только объекты одного статуса.

Например: ADWARE

т.е. Получаем на 100% надёжный список из одних ADWARE.

которые можно ЕДИНОВРЕМЕННО удалить - как при помощи автоскрипта, так и применив команду:

" Удалить все файлы в текущей категории ( с учётом фильтра )

Разом можно удалить 20 или 100 файлов/объектов...

Их практически не нужно проверять...

Критерий заданы надёжные.

----

Сейчас 95% всей работы это работа по удалению рекламы.

( в темах лечения - форумах Вирусов практичеки нет )

А рекламы очень много, это десятки объектов.

И каждый нужно удалить.

----

Вариант №2

Разбить команду: " Проверить список по пользовательской базе признаков. "

На под. команды:

" Найти все ADWARE "

" Найти все VIRUS "

" Найти все уведомления "

...

варианта и здесь два.

1) Имя задаёт оператор.

2) ИЛИ Разделение файла snms - на 4 самостоятельных блока/файла.

------

Что ещё + даёт этот подход ?

Со временем критерии становиться всё больше и больше.

Время проверки увеличивается - ( особенно при работе с системой, а не с образом автозапуска.)

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

Быстрее найти нужное.

+

Можно свести ложные определения к нулю _0_

что позволит быстрее обработать данные/образ не отвлекаясь на мусор/рекламу.

Пример: В списке "Подозрит. и Вирусы" 54 файла/объекта

Из них 41 - ADWARE.

После их автоматического удаления в списке останется небольшая группа объектов.

Её можно изучить/проверить и принять решение...

+

Нет нагрузке на V.T. - при проверке всего списка - так, как список отфильтрован.

+

Можно работать без V.T. - ОПРЕДЕЛЕНИЕ основано на надёжных критериях.

+

Быстрота обработки данных.

Результат уже разбит по категориям.

Большая часть данных подлежащих анализу проходит автоматическую обработку.

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


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

1) Оператор-cache|SHA1

Оператор работает с образом, проверяет файлы.

Отдаёт команду: "файл проверен"; Все файлы каталога пров." ; "Все файлы в текущей категории пров. "

П Р О В Е Р Е Н Ы !

Оператор работает дальше > открывает новый образ автозапуса > применяет команду:

" Проверить по базе предыдущих проверок Оператор-cache|SHA1 "

Вопрос - какой смысл по 100 раз проверять одни и те же файлы ?

Да...

Образы разные...

Но файлы одинаковы по SHA1

Со временем накопиться большая база проверки - сотни тысяч файлов.

Получиться огромная экономия по времени.

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

Какие есть + моменты ?

а) Это независимая база. *

Она является дополнением к базам: SHA1|MAIN ;SHA1|Оператор + vtcache + ( Оператор-cache|SHA1 )

* Можно отметить уровень надёжности баз.

SHA1|MAIN - от разработчика - и по сути самая надёжная.

SHA1|Оператор - на втором месте база файлов сформированная самим оператором или группой операторов.

vtcache - надёжно но... проверку может пройти и вирус - нужно время чтобы убедиться в надёжности файла.

Оператор-cache|SHA1 - Прежде всего основывается на мнении оператора - на его знаниях/опыте/практике.

Здесь оператор может отталкиваться в том числе и от результата проверки на V.T.

б) База формируется автоматически - параллельно работе.

Оператор проверяет > программа индексируется результат: _ ЭТИ _ файлы проверены __

в) Экономия по времени проверки.

На саму проверку.

На пополнении базы проверенных - Оператор-cache|SHA1

---------

2) Реализовать доп команды:

Удалить файл из базы: vtcache

Удалить файл из базы: Оператор-cache|SHA1

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


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

Demkd

Всё таки...

Не прося много...

Хотелось бы.

Узнать мнение по выше изложенным предложениям.

---

А то получается, что: "Тихо сам с собою я веду беседу"

Так и чердачёк фруттис может отъехать... в Пермь.

:mellow:

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


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

PR55.RP55

потом, после релиза очердной версии почитаю, пока времени нет.

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


Ссылка на сообщение
Поделиться на другие сайты
PR55.RP55
Demkd пишет:

потом, после релиза очердной версии почитаю, пока времени нет.

Буду ждать - как новую версию, так и оценки предложений.

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


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

RP55,

1) Критерии поиска.

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

Это группы:

a) ADWARE

б) VIRUS

c) Сеть

d) Информационные/уведомительные/предупреждения.

все это можно делать в рамках назначенных действий для критериев.

при расширении структуры списка snms.

а) установка статуса объекта при детектировании

б) назначенные действия при детектировании (для автоматического добавления команды в скрипт)

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

- со списков файлов и объектов

-со списком записей из hosts

- со списком записей из установленных программ.

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


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

santy

Это всё хорошо.

но...

Сейчас бы хоть сделать: Сопоставление ОТОБРАЖЕНИЯ - ИМЯ критерия и колонки | Статус | -

Пример:

Имя Adware11 | Ст. Adware11 |

---

А потом уже переходить к автоматизации процесса.

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


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

а что мешает тебе называть т.о. критерии? называй как тебе удобно. а статус, если будет принята(реализована) идея, можно будет устанавливать назначенной командой SETSTAT(?ВИРУС-АДВАРЕ?)

поскольку уже запланировано добавление функционала

10. доработка критериев: белые, назначение действия [v?.??]

то от него и надо отталкиваться.

а привязка статуса к названию критерия - это не есть хорошо.

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


Ссылка на сообщение
Поделиться на другие сайты
PR55.RP55
Santy пишет:

Статус, если будет принята идея, можно будет устанавливать назначенной командой SETSTAT(?ВИРУС-АДВАРЕ?)

Зачем _устанавливать статус_ ЕСЛИ статус задан/УСТАНОВЛЕН ?

Задан в имени !!

Это группы:

a) ADWARE

б) VIRUS

c) Сеть

d) Информационные/уведомительные/предупреждения. ( Инфо. )

*Если нужны ещё группы - то Оператор их создаст - по своему усмотрению.

Это и есть статус...

И если мы говорим об автоматизации.

Под каждый тип можно задать перечень отдаваемых команд.

--------------------

На примере сигнатур.

Сейчас по факту каждая сигнатура - это критерий.

Каждой сигнатуре - задано собственное имя.

СОБСТВЕННОЕ Имя отображается в колонке | статус |

Представим, что этого нет...

А есть одно общее определение для всех сигнатур...

Пример:

;uVS v3.82.8 [http://dsrt.dyndns.org]

;Target OS: NTv6.1

zoo %SystemDrive%\USERS\USER\APPDATA\LOCAL\YANDEX\UPDATER\PRAETORIAN.EXE

bl 2BF4BEF954542E8E402F7A2CA6436B04 798024

addsgn 1AE49A9A5583358CF42B254E3143FE547601B9FA0A3A13F1C03FA1374DD6714C239CC0339D559D49

2B0BC197CD4B457110236311A9255077E4B5AC2F9F5FA577 8 &

? ВИРУС ?

zoo %Sys32%\BTASYNCEX.AX

bl 63D0E921C242CF3A8AC969F5071E6C31 197120

addsgn 729053925465C9E30AD4AED1DAC82240250742F66900E02F060E3A575D46E1DCA91185DF39129C92

5E870F81C5F8B5EBA6AD05CA54DAB02C2CACD1284C18A19D 15 ? ВИРУС ?

zoo %SystemRoot%\APPPATCH\LFWYID.EXE

bl 2FEB5C4997A39899B85D5395271FB1A1 301056

addsgn 35E901E5156ABF760BD451BC69425205CDAD090976928202A9C39B3DB6E45D4C231EF6B4A0159DF2

7C1EBE9F0D95A2C6F61CC177A8B1F02C1E9A1E559E292240 8 ? ВИРУС ?

zoo %SystemDrive%\PROGRAM FILES\PRMT8\BACKUP\PROMTUSERS.EXE

bl 4D4BFA868A4314F16A64221FFF8B4DA9 53248

addsgn 1AD0729A55837A8FF42B254E3143FE84C9A2FFF68959AF79C4C34CB1FCD7304CAA026B567F551454

8F81C59FCF23E9FB3CDF614FC9DBF12C4BFBB1E7C6472215 8 ? ВИРУС ?

Сразу виден уровень марзама ээ... т.е. маразма !

-----

Так и для ПОИСКОВЫХ КРИТЕРИЕВ.

Недопустимо всё сваливать в одну кучу под наименованием ? ВИРУС ?

И радоваться - " вот какое холодное молоко даёт наша коровка "

Хорошо - что даёт.

Плохо, что ТОЛЬКО холодное.

Оно должно быть всяким: И холодным и тёплым и горячим - всё по мере необходимости.

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


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

RP55, я понимаю, тебе хочется писать и писать без остановки,

но даже если будет группировка критериев, то она никоим образом не относится к статусу объекта. по мне так достаточно одного активного статуса ?ВИРУС? (то что подлежит проверке, удалению, исправлению), остальное можно регулировать назначенными действиями.

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

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

--------

группировка она и сейчас есть. в зависимости от списка, с которым работает uVS

либо это список объектов и файлов, либо это список hosts, либо это список программ.

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


Ссылка на сообщение
Поделиться на другие сайты
PR55.RP55
Santy пишет:

даже если будет группировка критериев, то она никоим образом не относится к статусу объекта. по мне так достаточно одного активного статуса ?ВИРУС? остальное можно регулировать назначенными действиями.

Это как - почему не относиться ?

http://www.grandars.ru/student/statistika/...kih-dannyh.html

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

Это сомнительно.

Например сетевая активность - в этой группе могут быть совершенно разные объекты...

Чаще всего простые итоговые сводки не удовлетворяют исследователя, так как они дают слишком общие представления об изучаемом явлении.

Поэтому статистический материал подвергается группировке.

И далее...

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


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

потому что группировка данных - это одно, а статус объекта это другое. Если объект имеет статус :ПОДОЗРИТЕЛЬНЫЙ, значит выходит и часть критериев должна иметь группу - ПОДОЗРИТЕЛЬНЫЕ?

Группировка должна быть свободной и расширяемой. какой-то привязки к группе сейчас не видится, или видится в связи с разными списками. Например - одна группа (и только она) обрабатывает список hosts; другая группа (и только она) обрабатывает список установленных программ.

объекты в том числе и адварные могут быть из разных категорий. sys, exe и проч. Я например часто удаляю объекты sys через виртуализацию. объекты exe либо через chklst&delvir либо через del или delall.

корме того в качестве объектов (через критерии) можно будет добавить и каталоги и удалять их автоматически через deldirex

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


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

*

На herdprotect.com уже 11 000 000 файлов.

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


Ссылка на сообщение
Поделиться на другие сайты
PR55.RP55
Уважаемый Vvvyg ;) пишет:

И одна хотелка: было бы здорово, если бы все ссылки на страницы типа hxxp://www.sweet-page.com/.... и далее 100500 символов, и такое в нескольких вариантах - удалялись бы одной командой.

И соответственно предложение от RP55

1) Твик - удалить все: http://****

uVS будет содержать список основных ссылок не подлежащих удалению

типа: HTTP://GO.MICROSOFT.COM/FWLINK/?LINKID=

-------

P.S.

Что мешает это сделать ?

Бывает, что за раз необходимо удалить 8 и более ссылок.

Кому нравиться сидеть и тыркать 8 раз на удаление ?

Кому нравиться скрипт который не умещается в окно ?

И что в этом плохого ?

Удалиться пара стартовых страниц Aser или ещё чего... ( ценного )

Польза от твика очевидна.

Да и очистка url виде твика будет к месту.

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


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

Тема: Runddl32 загружает процессор на 50 %

http://pchelpforum.ru/f26/t139397/

Часто _у игрунов_ встречается такая проблема.

Предлагаю сделать твик по устранению проблемы.

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


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

PR55.RP55

пока не понятно что там твикать и из-за чего проблема, кому-то помогает замена rundll на правильную версию, кому-то правка ключей.

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


Ссылка на сообщение
Поделиться на другие сайты
PR55.RP55
Demkd пишет:

пока не понятно что там твикать и из-за чего проблема, кому-то помогает замена rundll на правильную версию, кому-то правка ключей.

Замена rundll к твикам не относиться - значит остаётся правка ключей.

Нет идеального оружия...

Но эффективность в 50% будет хорошим достижением.

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

Это актуально - жалобы на повышенную нагрузку встречаются часто.

Как пример правка/твик 12 для: " Сброс значений ключей Winlogon в начальное состояние. "

Так и для rundll +

твик: Убрать все накрученные хвосты.

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


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

Пожалуйста, войдите, чтобы комментировать

Вы сможете оставить комментарий после входа в



Войти

  • Сообщения

    • 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
    • santy
      RP55, есть у тебя ТГ?
×