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

Recommended Posts

PR55.RP55

1) Возможность задать очерёдность выполнения команд скрипта.

Путём назначения последовательности.

Пример:

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

;Target OS: NTv6.1

1; zoo %SystemDrive%\USERS\DEN\DOCUMENTS\ITERRA\CVWFICN.DLL

2; czoo

5; delref %SystemDrive%\USERS\DEN\DOCUMENTS\ITERRA\CVWFICN.DLL

3; deltmp

4; delnfr

restart

т.е. Нет необходимости редактировать сам скрипт - достаточно назначить очерёдность/последовательность применения команд.

*При формировании скрипта нумерация строки задаётся автоматически.

2) Настраиваемое меню подсказок.

т.е. Оператор задаёт для себя корректирующие подсказки.

Например при удалении файла с параметрами:

\Windows\Appinit_Dlls - через delall - Выдавать сообщение: "***********************" которое сам для себя задаст оператор.

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

с редко встречающимся типом заражения.

Подсказки реформируются на базе поискового критерия.

т.е. Создали критерий поиска и в меню критерия УВЕДОМЛЕНИЕ выбрали: Уведомление активно.

При применении команды по типу: delall %SystemDrive%\USERS\DEN\DOCUMENTS\ITERRA\CVWFICN.DLL

uVS автоматически выдаст предупреждение.

3) При формировании/написании скрипта нужна возможность отменить отданную команду.

В меню uVS добавить: "Отменить последнее действие"

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

ручной корректировки уже готового скрипта.*

*Ручная корректировка может привести к нарушению логики скрипта - кода.

4) Наименование сигнатуры указывать не после, а до.

Пример:

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

;Target OS: NTv6.1

addsgn ITERRA.DLL.Vir; A7679BCC06E1397E8089A6E6EFB50280D3FFF575B47EA678F5C32E9AD328733826943D564B773CB5

9580F41A866240AD2B8C17A2D01AC4207A21F7C720F8DD8C 64

Это необходимо при работе на ряде форумов - где окно ввода данных/кода имеет ограничение по размеру.

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

Для просмотра скрипта тратится время.

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

5) Сохранять файл/список файлов с присвоенным статусом: "ПРОВЕРЕН"

Логика применения: Обрабатывается образ/система проверенным файлам задаётся статус "ПРОВЕРЕН"

После выхода из uVS результат т.е.: файл/список файлов с присвоенным статусом: "ПРОВЕРЕН"

Сохраняется.

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

Автоматически ( по настройке в settings.ini ) происходит проверка/отсев списка.

* Где файл/список имеет имя равное имени образа.

Сохранятся такие чёткие данные по файлу как имя/директория, SHA1...

Что позволяет при повторном анализе образа/системы не тратить время на повторную проверку файла.

Также данный подход/метод эффективен и при просмотре повторного < > контрольного образа данной системы.

** Также в данном файле сохраняются результаты проверки объекта на V.T.

6) К команде по типу:

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

;Target OS: NTv6.1

bl 312D99CB54686F8C06215ABC820C59C6 47104

Автоматически добавлять имя файла в отношении которого была применена команда.

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

;Target OS: NTv6.1

CVWFICN.DLL; bl 312D99CB54686F8C06215ABC820C59C6 47104

7) Возможность по выбору перенести/переместить ВСЕ объекты из выбранной категории в категорию: "Подозрительные и вирусы"

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

по типу HIPS-а

На время выполнения скрипта.

Или по команде из контекстного меню файла/объекта.

uVS автоматически определяет какой раздел/лы подлежат блокировке.

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


Ссылка на сообщение
Поделиться на другие сайты
santy
1; zoo %SystemDrive%\USERS\DEN\DOCUMENTS\ITERRA\CVWFICN.DLL

addsgn ITERRA.DLL.Vir; A7679BCC06E1397E8089A6E6EFB50280D3FFF575B47EA678F5C32E9AD328733826943D564B773CB5

9580F41A866240AD2B8C17A2D01AC4207A21F7C720F8DD8C 64

CVWFICN.DLL; bl 312D99CB54686F8C06215ABC820C59C6 47104

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

-----------

предложение:

скорректировать автоматическое действие при отдаче команды delall при установленном параметре

; Автоматически копировать в zoo файл, удаляемый с помощью команды delall (кроме сетевого режима)

bAutoZooOnDelAll = 1 (0 по умолчанию)

если файл не найден.

т.е. не добавлять в скрипт команду ZOO file not found

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


Ссылка на сообщение
Поделиться на другие сайты
alamor
1) Возможность задать очерёдность выполнения команд скрипта.

Путём назначения последовательности.

и каждый раз в скрипте назначать очерёдность команд ? имхо было бы лучше, если бы эта последовательность была бы заложено в uVS. У каждой команды был бы определённый приоритет и она автоматически вставлялась бы в скрипт в последовательности зависящей от приоритета, к примеру czoo после всех команд карантина, restart в самом конце, если оператору по какой-либо причине надо изменить порядок выполнения команд, то оператор меняет их последовательность вручную в скрипте.

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

+1

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


Ссылка на сообщение
Поделиться на другие сайты
PR55.RP55
alamor пишет: Цитата(PR55.RP55 @ 08.12.2012, 17:05) *

1) Возможность задать очерёдность выполнения команд скрипта.

Путём назначения последовательности.

И каждый раз в скрипте назначать очерёдность команд ?

Вы Вообще читаете написанное ?

Написано: "ВОЗМОЖНОСТЬ"

т.е. Это некая свобода действия.

Написано: "*При формировании скрипта нумерация строки задаётся автоматически."

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

И сейчас невозможно понять ( не прибегая к сравнению ) какой файл был блокирован по bl**************, а какой соответственно НЕ был.

Santy пишет: Значимые параметры команды должны быть впереди.

Можно и так: bl CVWFICN.DLL; bl 312D99CB54686F8C06215ABC820C59C6 47104

Видно какая команда применена, видно имя файла.

ПРЕДЛОЖЕНИЕ.

1) Закладка - Поиск.

uVS Фиксирует поисковые запросы.

До 10 запросов.

Возможность быстрого повторного поиска/перехода к выбранному объекту.

На постоянной основе поиск закреплён для:

.EXE

.DLL

.SYS

*Что позволяет произвести мгновенную фильтрацию списка по выбранному типу расширения.

DF4.jpg

post-8956-1355488833_thumb.jpg

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


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

Написано: "ВОЗМОЖНОСТЬ"

возможность для одного не должна создавать проблемы с читабельностью для многих;

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

Можно и так: bl CVWFICN.DLL; bl 312D99CB54686F8C06215ABC820C59C6 47104

Видно какая команда применена, видно имя файла.

вообще то в языках программирования принято в конце комментировать строки.

(обрати внимание как в разных языках добавляются комментарные строки)

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

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

И сейчас невозможно понять ( не прибегая к сравнению ) какой файл был блокирован по bl**************, а какой соответственно НЕ был.

я считаю главным, чтобы "понимал" uvS что там написано в скрипте.

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


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

Santy

Я согласен - скрипт должен быть таким, чтобы uVS правильно его читала.

Однако и про Оператора нужно помнить.

Если вариант не проходит - значит вариант не проходит.

:unsure:

H2O.jpg

2012_12_14_194540.jpg

post-8956-1355506934_thumb.jpg

post-8956-1355506983_thumb.jpg

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


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

предложение в 3.77:

добавить в "инфо" информацию по детекту сигнатурой (полное наименование сигнатуры), если есть подобный детект.

(чтобы все возможные методы детектов были отражены.)

+

при просмотре списка объектов в основном окне uVS

при наведении курсора мыши (типа обработки события on mouse) на статус текущей записи высвечивать

(или на полупрозрочном фоне, или по типу подсказок tooltiptext)

полное имя объекта;

инфо по детектированию сигнатурой, если есть;

инфо по детектированию критериями, если есть

инфо по детектированию антивирусами на VT&jotti

убирать краткое инфо, при перемещении курсора в другие поля.

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


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

1) Возможность совершать переход/просматривать Инфо. по файлу/объекту по типу.

Информация < > Информация < > Информация < > Информация < >

Так:

Выбрали файл/объект открыли контекстное меню > выбрали: ИНФОРМАЦИЯ.

Открыли ИНФОРМАЦИЯ и ....

И прямой переход от одного окна Инфо. к другому.

1.1 ) Объединение ЧАСТИ МЕНЮ в рамках одного окна.

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

* Например: " Проверка по V.T. "

2) В новых версиях созданный образ имеет приличный вес.

Вероятно, со временем будет происходить дальнейшее увеличение веса.

Соответственно предлагаю провести оптимизацию данных образа.

Сейчас данные сохраняются так, как есть.

Пример:

C:\Program Files\7-Zip

C:\Program Files\K-Lite Codec Pack

Предлагаю ввести КРАТКОЕ обозначение каталогов.

Пример:

C:\&P&\7-Zip

C:\&P&\K-Lite Codec Pack

ЭТО ТОЛЬКО ДЛЯ ОПТИМИЗАЦИИ ХРАНЕНИЯ ДАННЫХ ! !

ДАННЫЕ БУДУТ ОТОБРАЖАТЬСЯ ДЛЯ ОПЕРАТОРА СТАНДАРТНО - т.е: \Program Files\

Или, необходимо использовать математические модели.

Аналог того, как данные сжимают/оптимизируют архиваторы.

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

3) Оптимизация обработки файлов MSI при создании базы проверенных файлов SHA1.

Можно значительно сократить время проверки/обработки путём исключения ранее обработанных

MSI пакетов.

т.е. В меню uVS появляется команда: "Добавить все исполняемые файлы каталога в список + msi"

Логика такая: Можно по базе проверенных выяснить обрабатывался ли данный объект ранее.

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

Если SHA1 msi файла есть в базе...

Значит его обработка уже проводилась.

Пропускаем...

И переходим к тому/тем объектам которых нет в базе.

* Добавили в список, отфильтровали по F4 - далее, работаем с оставшимися объектами списка/каталога.

Можно привести пример насколько часто такие объекты часто встречаются:

PhysX_9.10.0514_SystemSoftware.msi

SMathStudioDesktop.0_75.Setup.msi

Eav_nt32_RUS.4.2.71.3.msi

sw_lic_full_installer.msi

PredatorPackage.msi

HiJackThis.msi

calibre-0.8.52.msi

7z464-x64.msi

DB9_Spec_ru.msi

NETCFSetupv35.msi

Между тем, на данный момент uVS их НЕ обрабатывает.

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

И НЕ логично для вышеописанного примера.

Применение данной методики обработки/предварительного отсева позволит значительно сократить

время проверки группы файлов и тем самым позволит ускорить пополнение базы SHA1 проверенных.

т.е.Необходима возможность сохранять SHA1 msi в базе проверенных.

+ Опционально возможность добавления их в список.

4) Примечание.

Применение технологии CUDA.

Когда это эффективно/практично ?

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

Пакетов драйверов; Антивируса; Офиса и т.д.

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

5) В окно Информация добавить запись:

" Файл создан в течении 10 дней "

Что позволит, при формировании сложного/составного критерия применить эту информацию в качестве добавочного критерия.

Что эффективно при поиске угроз не применяющих маскировку до дате/Времени создания.

6) ПРЕДЛОЖЕНИЕ.

ПРЕДЛАГАЮ ПЕРЕЧИТАТЬ ВСЕ ПРЕДЛОЖЕНИЯ

+

ЗАМЕЧАНИЯ ПО ОШИБКАМ ПРОГРАММЫ.

ЗА ВСЁ ВРЕМЯ ПРОШЕДШЕЕ ПОСЛЕ ВЫХОДА uVS 376 версии.

Как правило при первом/однократном прочтении информация НЕ воспринимается.

7) Седьмое предложение:

ХОРОШО ВСТРЕТИТЬ НОВЫЙ ГОД,

С НАСТУПАЮЩИМ !

И ВСЕГО САМОГО ЛУЧШЕГО !

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


Ссылка на сообщение
Поделиться на другие сайты
demkd
добавить в "инфо" информацию по детекту сигнатурой (полное наименование сигнатуры), если есть подобный детект.

(чтобы все возможные методы детектов были отражены.)

А оно и сейчас есть.

при наведении курсора мыши...

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

Файл создан в течении 10 дней "

вверху фильтр по дате, его достаточно.

Оптимизация обработки файлов MSI при создании базы проверенных файлов SHA1.

не видел я чтоб msi попадали в список, соотв. не понятен смысл

с наступающим! :)

в шапку добавил нек. предложения.

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


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

Ещё раз.

Добавление в список MSI необходимо при формировании/составлении базы SHA1 проверенных файлов.

Только для этого ! !

Если файл/лы будет попадать в список - ПО ЗАПРОСУ оператора.

т.е.: "Добавить в список все файлы каталога + msi "

С возможностью сохранить в базе проверенных SHA1 данного файла.

То, в дальнейшем при составлении базы появляется возможность узнать > обрабатывался ли файл раньше.

Соответственно, если обрабатывался - он пропускается/игнорируется оператором.

Что экономит время.

Интерес в плане составления базы представляет начинка файла которого ещё нет в базе...

Смотрим фото пример.

2012_12_26_152656.jpg

2012_12_26_154346.jpg

post-8956-1356515588_thumb.jpg

post-8956-1356515603_thumb.jpg

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


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

сейчас так

?ВИРУС? ВИРУС ПОДОЗРИТЕЛЬНЫЙ в автозапуске

предлагается так

?ВИРУС? ВИРУС (SpyEye.1224(64)) ПОДОЗРИТЕЛЬНЫЙ в автозапуске

т.е. имени сигнатуры нет в инфо.

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

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

тут подсказка должна всплыть при фокусировке курсора на поле "статус".

Но не настаиваю.

Ибо лень разработчика имеет более высокий приоритет, чем лень пользователя. :)

С Наступающим!

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


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

santy

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

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


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

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

(с критериями все ок!)

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

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

Полное имя C:\SYSTEMHOST\24FC2AE32BE.EXE

Имя файла 24FC2AE32BE.EXE

Тек. статус ?ВИРУС? ВИРУС ПОДОЗРИТЕЛЬНЫЙ в автозапуске

Удовлетворяет критериям

SPYEYE (ПОЛНОЕ ИМЯ ~ SYSTEMHOST)(1)

Сохраненная информация на момент создания образа

Статус в автозапуске

Размер 335872 байт

Создан 04.08.2004 в 02:56:38

Изменен 09.12.2010 в 18:15:09

Тип файла 32-х битный ИСПОЛНЯЕМЫЙ

Цифр. подпись Отсутствует либо ее не удалось проверить

Доп. информация на момент обновления списка

SHA1 71E5FCC37D409CD0D1AC0CAF57156BAFE3BB49E0

MD5 19BA33348A23362FA5D668D6A8AB7530

Ссылки на объект

Ссылка HKEY_USERS\S-1-5-21-1787129984-3472257021-3128328180-1129\Software\Microsoft\Windows\CurrentVersion\Run\YI9B2F0F3EXHXU1I

YI9B2F0F3EXHXU1I C:\systemhost\24FC2AE32BE.exe

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


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

1) Меню команда/закладка.

т.е. при необходимости отдать команду: Открываем заранее созданный/подготовленный список.

Выбираем команду.

Команда применяется = добавляется в скрипт.

2) Возможность переключится в 2-х оконный режим.

см.фото.

3) Добавить команду меню: "Удалить все задачи"

4) Запрос/поиск по базе проверенных SHA1

т.е. при помощи сторонней программы получили MD5 | SHA1 подозрительного объекта.

Появилась возможность проверить файл.

Проверить без обращения к V.T. и т.д.

51_cr.jpg

post-8956-1357217047_thumb.jpg

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


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

Здравствуйте demkd! Возник одна идея по поводу uVS:

- С повышением тем по поводу баннеров в браузерах, мы часто начали принимать код для сброса DNS-кэша и в скрипте приходится писать это вручную (EXEC cmd /c"ipconfig /flushdns"). И что бы улучить нашу работу, автоматизировать этот код в uVS. Например так:

0e0cdb1514ba.jpg

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


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

Аркалык

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

PR55.RP55

исправил, выложил в ветке тестирования.

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


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

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

+

имеет смысл в дальнейшем ее (flushdns) автоматически добавлять в скрипт, если были отданы команды по очистке левого DNS (setdns)

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


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

1) Пример

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

;Target OS: NTv5.1

; С:\ВАСЯ\ВАСЯ.EXE

zoo D:\ВАСЯ\ВАСЯ.EXE

; zoo D:\ВАСЯ\ВАСЯ.EXE

Есть мнение, что комментирование операции для ZOO лишнее.

2) settings.ini

По завершению работы с Образом...

По настройке settings.ini

Файл Образа автоматически перемещать в указанный каталог...

3)

PR55.RP55 пишет:

Меню команда/закладка.

т.е. при необходимости отдать команду: Открываем заранее созданный/подготовленный список.

Выбираем команду.

Команда применяется = добавляется в скрипт.

Данный вариант более практичен.

Оператор самостоятельно может составить список необходимых при работе команд.

Это может быть: EXEC cmd /c"ipconfig /flushdns"

Или любая другая возможная команда: cmd...

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


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

по сути предложений 1-4 из 418.

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

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


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

По Автоскрипту.

Складывается впечатление, что идея Автоскрипта провалилась с треском.

Там, где стояли три сосны теперь шумит лес.

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

И края этому НЕвидно.

Может ещё 20 команд добавить ?

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

Вот...

Радость будет большая...

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


Ссылка на сообщение
Поделиться на другие сайты
santy
Фактически появление одной идеи по автоскрипту влечёт за собой появление целого набора команд.

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

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


Ссылка на сообщение
Поделиться на другие сайты
PR55.RP55
Santy пишет: ничего не дают в плане реализации автоматического создания скрипта.
15.12.2012, 14:20

Santy пишет:

при просмотре списка объектов в основном окне uVS

при наведении курсора мыши (типа обработки события on mouse) на статус текущей записи высвечивать

(или на полупрозрочном фоне, или по типу подсказок tooltiptext)

полное имя объекта;

инфо по детектированию сигнатурой, если есть;

инфо по детектированию критериями, если есть

инфо по детектированию антивирусами на VT&jotti

убирать краткое инфо, при перемещении курсора в другие поля.

В общем ограничиваем Юпитер ?

Про подсказки значит можно...

А, вот ПЕРЕКЛЮЧЕНИЕ в полноценный режим 2-х оконного просмотра предлагать нельзя...

И вообще.

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


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

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

1. Нужен поиск по списку программ, аналогично поиску в списке объектов, сигнатур, критериев.

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

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


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

1) По настройке в settings.ini автоматически отображать данные в соответствии с предпочтением оператора.

т.е.например по имени файла, или статусу...

Пример: Открыли образ...

Данные автоматически отображены в соответствии с...

2) По сигнатурам.

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

т.е. НЕ проверять список по всей базе сигнатур.

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

3) Браузеры.

Команда меню: " Удалить все HTTP "

* Кроме известных для /Explorer.

4) По автоскрипту.

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

Пример:

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

;Target OS: NTv6.1

czoo

restart

deltmp

delnfr

zoo %Sys32%\BTASYNCEX.AX

bl 63D0E921C242CF3A8AC969F5071E6C31 197120

delall %Sys32%\BTASYNCEX.AX

Таким образом...

5) Окно сохранения скрипта.

По настройке в settings.ini автоматически сохранять написанный скрипт в файл = каталог.

т.е. по окончанию работы с образом uVS НЕ открывает окно с предложением: СОХРАНИТЬ.

Файл скрипта автоматически сохраняется в каталог заданный по settings.ini.

Имя скрипта = имени образа.

USER-ПК_2012-10-21_21-59-40.7z = USER-ПК_2012-10-21_21-59-40.script

6) В окно/на сохранения скрипта добавить детский ползунок.

Чтобы можно было в окне увидеть > прокрутить весь текст скрипта.

Сейчас часть написанного скрипта можно посмотреть...

Зачем скрывать остальное ?

Зачем стесняться ?

7) Автоскрипт

Пример: Есть критерий на нежелательную программу.( Из списка установленных программ )

Критерий сработал.

АВТОМАТИЧЕСКИ в скрипт/е прописываются команды на удаление.

Пример:

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

;Target OS: NTv6.1

czoo

restart

exec MSIEXEC.EXE /X{1E03DB52-D5CB-4338-A338-E526DD4D4DB1}

deltmp

delnfr

* Команды скрипта: deltmp; delnfr - выполняются перед командой restart.

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


Ссылка на сообщение
Поделиться на другие сайты
santy
exec MSIEXEC.EXE /X{1E03DB52-D5CB-4338-A338-E526DD4D4DB1}

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

инициировать только перенос объекта из списка программ в список подозрительные со статусом ?ВИРУС? с контекстными функциями:

- удалить из списка программ

- деинсталлировать

- деинсталлировать с ключом /quiet

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

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

отдельной функцией (отдельным нажатием) - автоскрипт/оптимизация

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


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

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

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



Войти

  • Сообщения

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