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

Recommended Posts

PR55.RP55

1. "Поиск по исключению"

т.е. При вводе в поле поиска например символа "e" ... ( или "e +..." )

В списке будут оставлены только те объекты, что Не содержат данный символ.

* Пример совместного применения: "Фильтрующий поиск + Поиск по исключению"

Имя

___________________

AXCMD.EXE

LVAGENT.EXE

BUBBLАS.SCR

WIN32K.SYS

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

В результате "Поиска по исключению"

В списке остаются:

BUBBLАS.SCR

WIN32K.SYS

_________________

2. Категория:

HOST

Контекстное меню - для IP прописанного в "Host" ;

uVS по запросу открывает в браузере или же логе, информацию по принадлежности данного IP объекта.

3. Категория:

Internet/Windows Explorer

При заполнение чека: "Скрыть известные"

Автоматически скрывать записи по типу:

HTT*://WW*.MICROSOFT.COM/ISAPI/REDIR.DLL?PRD=IE&AR=IESEARCH

HTT*://WW*.MICROSOFT.COM/ISAPI/REDIR.DLL?PRD=IE&PVER=6&AR=MSNHOME

...

т.е. Скрывать стандартные данные/настройки.

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


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

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

Реализовать возможность добавлять комментарий к строке отображения СТАТУСА объекта.

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

В качестве примера см.фото.

11.jpg

uVS_374.2.jpg

post-8956-1323788380_thumb.jpg

post-8956-1323788399_thumb.jpg

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


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

Zoo.

См.фото.

uVS___.jpg

post-8956-1323961580_thumb.jpg

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


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

Santy пишет в теме:

http://www.anti-malware.ru/forum/index.php...st&p=147132

1. сбрасываем статус проверенные у всех файлов.

2. находим данный файл в автозапуске,

3. в контекстном меню выполняем проверку хэша файла по базе проверенных.

* это тонкости понимания работы uVS

проделай все по порядку: 1,2,3

и будет результат.

uVS Общий FAQ.txt

F4 - Проверка хэшей файлов в списке по базе проверенных файлов

F6 - Проверка цифр. подписей файлов в списке.

По пунктам № 1. 2. 3.

1. Если, сбросить статус проверенные у всех файлов.

То будут сброшены значения и для файлов прошедших проверку по SHA1 - базе проверенных !

Что, иначе как Абсурдом назвать невозможно !

Зачем же тогда вообще нужна эта база ?

Получается, база есть - но её как-бы и нет совсем ?

Самый натуральный Абсурд.

Можно понять когда произойдёт сброс у файлов прошедших проверку по цифровой подписи.

Но причём же здесь база SHA1 - Зачем сбрасывать результаты её проверки !?!

Если, есть сомнение в самой базе - то её вообще в таком случае нельзя использовать...

Или, если были случайно/самостоятельно в неё добавленных нежелательные Хеши.

То, такую базу, просто следует удалить - и скачать/создать новую.

Что это значит: Это значит, что так делать нельзя !

И тонкости работы с uVS тут совершенно ни причём !

Просто нельзя, где же логика ?

Пункты № 2-3.

"

2. находим данный файл в автозапуске,

3. в контекстном меню выполняем проверку хэша файла по базе проверенных."

В Автозапуске может быть 100 файлов.

И перебирать их все ?...

Что касается контекстного меню...

Если скрупулёзно подойти к делу/задаче - то нужно эти 100 файлов проверить. ( каждый файл проверить ! )

Это 100 раз открыть контекстное меню ?

Это также Абсурд.

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

Соответственно, должно быть два пункта проверки в Меню при работе с образом:

А) Скрыть проверенные по: Циф.подписи & SHA1

В) Скрыть проверенные по: SHA1

Таким образом, мы ИЗНАЧАЛЬНО можем оставлять в списке файлы прошедшие проверку по определённому типу/критерию.

Что в спорных случаях будет способствовать решению задачи.

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

P.S. считаю, что проблемы такого рода проверок будут продолжаться/повторяться ещё неоднократно.

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

Кроме того, законы Эргономики ещё не отменили.

Что самое главное в Эргономике это: "НЕ ПРОВОЦИРОВАТЬ ВОЗНИКНОВЕНИЕ ОШИБОК и НЕШТАТНЫХ СИТУАЦИЙ".

И удобство...

В общем, я свою позицию выразил.

А так, уже, как угодно !

Просто считаю данное положение дел в корне - неверным.

Ну... Вот снова лишнее написал.

Я это всё к тому, что должно быть 1- но действие по выбору - а не последовательность действий.

Последовательность в которой далеко не всегда есть необходимость.

т.е. Если целая группа/последовательность команд может быть заменена 1-й командой.

То так и должно быть !

А всё дополнительные команды - Вот они уже должны быть по желанию и прочее...

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


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

http://www.anti-malware.ru/forum/index.php...st&p=147132

uVS Общий FAQ.txt

F4 - Проверка хэшей файлов в списке по базе проверенных файлов

F6 - Проверка цифр. подписей файлов в списке.

По пунктам № 1. 2. 3.

1. Если, сбросить статус проверенные у всех файлов.

То будут сброшены значения и для файлов прошедших проверку по SHA1 - базе проверенных !

Что, иначе как Абсурдом назвать невозможно !

Зачем же тогда вообще нужна эта база ?

Получается, база есть - но её как-бы и нет совсем ?

Самый натуральный Абсурд.

RP55, автор конечно выскажет более корректное мнение, но я скажу так:

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

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

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

прошел проверку по SHA1. но база по SHA1 общая: авторская+ пользовательская. Мало ли что может добавить в свой SHA "черт" на противоположном конце.

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

----------

соответственно сбрасываем статус проверенные, чего там напроверял "черт" на противоположном конце, и проверяем по SHA1 весь автозапуск на своей стороне. За свой sha1 ты отвечаешь лично. Никто никого не заставляет делать сбросы на каждой проверке образа, но если есть сомнения как в случае с smaxxi, то следует ДЕЛАТЬ ЭТО.

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


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

Моя Позиция:

1. Последовательность из 3-х команд.

F4 + Сброс статуса проверенных у... и снова F4 ?

Это уже и есть Абсурд - Достаточно 1- й Команды.

"Показать/Скрыть все прошедшие проверку по SHA1"

Или : "Показать/Скрыть все прошедшие проверку по SHA1 + Циф. подпись

+ Добавить криптоновою команду.

Удалить данные добавленные пользователем - левые сигнатуры.

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

Проще нужно быть ;)

В Общем непонятно, что мы вообще обсуждаем.

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


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

1. uVS не должен сохранять данные SHA1 добавленные пользователем.

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

----------

и я создаю дополнительный файл SHA1 чтобы дополнить в список те чистые файлы с которыми работаю постоянно. (в сеть не выкладываю)

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


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

Кое что подправил в предыдущих своих сообщениях.

Идея в том, что при работе/проверке по базаМ SHA1 в списке должно быть чётко видно по какой из баз файл прошёл проверку.

И число разовых рабочих команд вполне можно сократить до 1-й.

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


Ссылка на сообщение
Поделиться на другие сайты
santy
Идея в том, что при работе/проверке по базаМ SHA1 в списке должно быть чётко видно по какой из баз файл прошёл проверку.

на стороне юзера с заражением вообще нет базы SHA1, поскольку в архивах, на которые мы даем ссылке нет базы MAIN, поэтому с большой вероятностью - сбросить статус "проверенные" у всех файлов - это отмена проверенных по ЭЦП или самолично установленных статусов "проверенные".

---------

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

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


Ссылка на сообщение
Поделиться на другие сайты
PR55.RP55
Цитата(PR55.RP55 @ 16.12.2011, 19:03) *

Идея в том, что при работе/проверке по базаМ SHA1 в списке должно быть чётко видно по какой из баз файл прошёл проверку.

на стороне юзера с заражением вообще нет базы SHA1, поскольку в архивах, на которые мы даем ссылке нет базы MAIN, поэтому с большой вероятностью - сбросить статус "проверенные" у всех файлов - это отмена проверенных по ЭЦП или самолично установленных статусов "проверенные".

Значит скорректирую позицию: Если Образ Создан - то ! Должна быть чёткая градация где/что добавлено на стороне - того кто создал

образ.

И, при проверке эти данные АВТОМАТИЧЕСКИ не должны учитываться

Либо же В ОБРАЗЕ чётко должен быть ВЫДЕЛЕН тот файл -

который "ПРОВЕРИЛ :)" пользователь или тот файл который прошёл проверку по "SHA1 - базе" случайно или намеренно созданной им.

или загруженной из какого либо источника.

Не складывать всех кошек в одно лукошко.

К чему эти странные телодвижения ?

Если это "Мусор" то и статус у него, как у мусора.

А работа с удалёнными системами - Это уже отдельная тема - и там должны быть свои ДОПУСТИМЫЕ параметры работы.

*Ведь возмущение народных масс имеет под собой основание :)

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


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

В uVS есть строка: Скрыть ненайденные и с заполненным производителем.

Непонятно как эти объекты между собой могут быть связанны чтобы их ставит фактически в один ряд !

Не найденные ( это то, что реально отсутствуют или не невозможно найти по той или иной причине. ! )

А какое к этому имеет отношение параметр с заполненным производителем - при том - для РЕАЛЬНО существующего/найденного объекта ?

Как это может взаимодействовать ?

* Должно быть два пункта меню: 1) Скрыть не найденные 2) С заполненным производителем...

Два совершенно отдельных и независимых пункта - так, как по логике вещей оно и есть на самом деле !

Например скрыли не найденные - ( убрав на время! из поля зрения всякий мусор ) после чего поработали/разобрались с реальными объектами...

Например внесли в скрипт сигнатуры и пр...

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

А так, как оно сейчас это...

Или я опять чего то не понимаю ?

И все эти файлы: Одни, те которые ЕСТЬ и другие коих НЕТ, суть одно и тоже ?

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

Да !

Сразу хочу извиниться перед Дмитрием.

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

Однако, я счёл единственно верным выразить данную точку зрения.

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


Ссылка на сообщение
Поделиться на другие сайты
santy
В uVS есть строка: Скрыть ненайденные и с заполненным производителем.

RP55, впору открыть новый топик, типа майн кампф или философия детектирования, откуда уже можно было бы формулировать четкие предложения к новым версиям. :)

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

предложения по uVS в 2012 г.

1. по проблеме заражения MBRlock:

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

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

по возможности поиск или подбор пароля для снятия блока

2. по критериям: составные критерии для отбора необходимых записей в образе + селектирование отобранных записей.

3. по сигнатурам: дополнительно экспорт сигнатур из списка в файл (контекстное меню в списке сигнатур)

4. по анализу инфо: использовать для поиска инфо о файлах/процессах дополнительно ресурс runscanner.net

(runscanner - родственная uVS программа и сервис информации по файлам, хотя отстает несколько в развитии.)

5. по созданию образа загрузочного диска: добавить в настройки выбор_установку фонового рисунка для Live.CD.

6. по режиму автоскрипта.

добавить скриптовую команду CLRSGN - очистка начального списка сигнатур.

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

(если используется uVS той же версии неоднократно)

7. по автоархивированию.

изменить порядок формирования имени архива.

имя архива с ZOO должно включать текст "ZOO": либо вначале, ZOO_дата-время.7z, либо в конце дата-время_ZOO.7z]

(трудности поиска архива возникают у некоторых юзеров).

8. добавить технологию select (выделения с помощью клавиш + или -) записей, и в контекстное меню операции над выделенными записями.

(селектированные записи выделять при просмотре: или цветом (добавить в настройки цвета), или доп. знаком например * или # последнем поле таблицы.)

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

так же включить селектирование при выполнении запроса по составным критериям.

(можно в настройки вынести - селектирование при запросе.)

например:

к селектированным записям можно применить: проверку всех селектированных по хэшам на VT, Jotti,

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


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

Хотелось бы еще увидеть простой и удобный менеджер автозапуска

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


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

Есть ещё такое предложение - сохранять в образе bat/cmd/vbs - часто полезно посмотреть, что там файл вытворяет. Размер у них, как правило, небольшой, раз уж mbr/vbr сохраняем, то и эти файлы стоит.

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


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

Скоро новый год, поэтому ещё ряд социалистических предложений.

В том плане, что всё для народа, всё для победы!

ДОЛОЙ ЗЛОКОЗНЕННЫЕ ВИРУСНЫЕ НАПАДЕНИЯ !

1.В случае ошибки возможность: "Отменить крайнюю команду скрипта"

*С повторным отображением тех файлов которые были скрыты/удалены из списка при выполнении данной команды.

** Суть в том, что отменяются не все действия, а именно последняя команда.

Это, как в графическом редакторе - нарисовал на фотографии бяку...

Бяка не понравилась...

Жмём на отмену!

2. Контекстное меню файла: "Поиск по имени файла в реестре"

3.По Live CD добавить в uVS "crashreporter.exe"

т.е при невозможности/ошибке загрузки c диска формировать репортаж с типом ошибки.

Например: Ошибка HDD контроллера; недоступен драйвер...; Ошибка файловой системы...

4.Новая команда в меню:

" Удалить все не найденные - с добавлением команды удаления в скрипт"

т.е. Вместо одной команды: DELNFR

АВТОМАТИЧЕСКИ отдаётся ряд команд по типу:

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

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

delref %SystemDrive%\USERS\АР\DOWNLOADS\ANKA_SETUP.EXE

delref %Sys32%\DRIVERS\EWUSBDEV.SYS

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

т.е. уже нет необходимости отдавать отдельные команды скажем для 5 -ти файлов.

Отдаётся только одна и для всех разом...

uVS в автоматическом режиме по списку определяет не найденные объекты и даёт по ним команду на удаление.

5.Поисковые критерии.

Добавить команду: "Ограничить действие поискового критерия областью поиска"

Пример: "Ограничить действие поискового критерия областью поиска \%SystemRoot%\"

Пример:

Тип - Имя файла ( и скажем вводиться расширение sys.bat...)

6.Селектирование файлов списка по типу:

Контекстное меню файла: "Исключить файл из данной категории - Добавить файл в категорию "Подозрительные и вирусы"

т.е. Например поверяем категорию "Весь Автозапуск"

И файл. Vasia.exe вызывает у нас подозрение - и мы не углубляясь сразу в проверку - перекидываем его в категорию "подозрительные и вирусы"

И так, формируется группа файлов вызвавших подозрение.

И теперь, есть возможность не рыская по всем категориям проверить эти файлы.

* Желательно иметь примечание/метку из какой категории был экспортирован данный файл/объект.

7. Было бы полезно произвести дополнительную проверку\лечение по типу:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Security Center\UpdatesDisableNotify

и т.д. с сохранением информации в образ.

8. В плане обнаружения файловых вирусов или их последствий.

По дате изменения файлов автозапуска системы.

Сравнение дат...

И если "Все" файлы - дата, их изменения датирована одним числом...

Выдавать предупреждение.

* Сам по себе такой критерий может дать ложное предупреждение... ( и даст )

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

9. Цитата: " Операционные системы Windows XP; Vista поддерживаю хранение даты разделов реестра."

Соответственно, есть потенциальная возможность сравнить время создания тела файла и время записи информации в реестр?

И соответственно сравнение/выявление расхождения в данных.

* Насколько это всё реально ?

Или же при Мониторинге в локальной сети ?

10. Изменение данных Реестра.

т.е В контекстное меню файла добавить команду на перезапись имени файла.

Команда:

CHANGE %SystemDrive%\USERS\АР\DOWNLOADS\ANKA_SETUP.EXE

В результате в реестре будет такая запись: \ANKA_SETUP.EXE\uVS.CHANGE

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

И, если после этого отдать команду:

CHANGE %SystemDrive%\USERS\АР\DOWNLOADS\ANKA_SETUP.EXE\uVS.CHANGE

то...

uVS считывает данные, после чего сравнивает значение_ И, ЕСЛИ найдено равенство этих значений.

( Запись реестра = \ANKA_SETUP.EXE\uVS.CHANGE = команде ANKA_SETUP.EXE\uVS.CHANGE )

то, значения будут сброшены на дефолтные.

В данном случае получаем одну команду под выполнение двух действий.

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


Ссылка на сообщение
Поделиться на другие сайты
Angel-iz-Ada
4.Новая команда в меню:

" Удалить все не найденные - с добавлением команды удаления в скрипт"

т.е. Вместо одной команды: DELNFR АВТОМАТИЧЕСКИ отдаётся ряд команд по типу

:-------------------------------------------------

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

delref %SystemDrive%\USERS\АР\DOWNLOADS\ANKA_SETUP.EXE

delref %Sys32%\DRIVERS\EWUSBDEV.SYS

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

т.е. уже нет необходимости отдавать отдельные команды

скажем для 5 -ти файлов.Отдаётся только одна и для всех разом...

а разве сейчас не так?:) delnfr ведь так и поступает

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


Ссылка на сообщение
Поделиться на другие сайты
PR55.RP55
а разве сейчас не так?smile.gif delnfr ведь так и поступает

Эх !

РЕАЛЬНЫЕ КОМАНДЫ - ДЛЯ РЕАЛЬНО АКТИВНЫХ! НО НЕ НАЙДЕННЫХ ФАЙЛОВ !

т.е. эти команды идут в скрипт !

В том плане, что сейчас uVS файл не видит - НО потом при выполнении скрипта файл может быть найден !

( например при изменении режима запуска start.F или изменении активности самого вируса)*

Соответственно он будет удалён только по реально отданной команде на удаление.

Файл - то появился! и потому команда DELNFR уже отдыхает !

А - как, что хотели то и удалили !

И сразу ГРУППУ файлов.

Может 5 - 7.

А не тыкаться по каждому.

* = Команда DELNFR = Ссылка на файл. ( по такому типу. )

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


Ссылка на сообщение
Поделиться на другие сайты
santy
6.Селектирование файлов списка по типу:

Контекстное меню файла: "Исключить файл из данной категории - Добавить файл в категорию "Подозрительные и вирусы"

т.е. Например поверяем категорию "Весь Автозапуск"

И файл. Vasia.exe вызывает у нас подозрение - и мы не углубляясь сразу в проверку - перекидываем его в категорию "подозрительные и вирусы"

И так, формируется группа файлов вызвавших подозрение.

И теперь, есть возможность не рыская по всем категориям проверить эти файлы.

* Желательно иметь примечание/метку из какой категории был экспортирован данный файл/объект.

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

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


Ссылка на сообщение
Поделиться на другие сайты
omnilynx13
Хотелось бы еще увидеть простой и удобный менеджер автозапуска

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

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


Ссылка на сообщение
Поделиться на другие сайты
santy
Имхо, лишнее. такого рода программ до и больше. uVS и так позволяет работать с автозапуском делать почти что угодно.

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

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


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

в ссе использовали autoruns от Марка Р., хотя сам по себе autoruns отличная программа

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


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

Да причем тут Autoruns? Подобного софта полно. Я ведь про функционал программы говорю - чтобы скриптом можно было на компьютере человека поубирать лишний софт из автозапуска, а то приходится юзать HiJackThis

  • Downvote 5

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


Ссылка на сообщение
Поделиться на другие сайты
omnilynx13
скриптом можно было на компьютере человека поубирать лишний софт из автозапуска

А что тебе uVS не позволяет делать? :huh: или что? Честно говоря в моей практике (небольшой) HiJackThis, фактические полностью вытеснился uVS.

p.s. это всё оффтоп. Предлагаю создать кому уж очень хочется топик для сравнения uVS с... :HiJackThis, Autoruns, Process Explorer и прочими интересными программами и утилитами.

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


Ссылка на сообщение
Поделиться на другие сайты
PR55.RP55
А что uVS не позволяет делать?

Ангела так и не поняли...

Впрочем видимо, как и многое из того что я раннее предлагал.

Просто доказывать нет желания.

Кому надо тот разберётся.

uVS не позволяет это сделать по одной простой причине: Речь не идёт о удалении как таковом - речь идёт о исключении из Автозагрузки

Я о той фигне которая появляется при команде msconfig - вкладка Автозагрузка.

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

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

И нет желания "удалить все ссылки" на PuntoSwitcher - потому как это программе не понравиться...

Стоит себе программа - и Ярлычок такой - махонький, но симпатичный на рабочем столе есть - и когда надо - раз!

И программку запустили...

А uVS - ей может при нынешнем раскладе только голову как павлину свернуть...

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


Ссылка на сообщение
Поделиться на другие сайты
Angel-iz-Ada
А uVS - ей может при нынешнем раскладе только голову как павлину свернуть...

вот вот. хоть кто-то меня понимает :)

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


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

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

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



Войти

  • Сообщения

    • 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
×