Тест антивирусов на детектирование полиморфных вирусов (результаты) - Страница 7 - Тесты и сравнения - Форумы Anti-Malware.ru Перейти к содержанию
Сергей Ильин

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

Recommended Posts

Valery Ledovskoy
Во-первых баллы взяты не с потолка - смотри методологию.

А я и не говорю, что они взяты с потолка. Я пытаюсь уточнить выбор условий.

В данном случае Вы выделение точно 100%-ного результата тоже поддерживаете, даже не смотря на мои аргументы?

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

Есть антивирусы А и Б и вирусы V1, V2, V3

При этом, допустим, получились такие результаты:

По V1:

А - 100%

Б - 99,99%

По V2:

А - 99,99%

Б - 99%

По V3:

А - 98,99%

Б - 90%

По первому вирусу могу сказать, что различие в 1 балл для антивирусов А и Б является несправедливым, т.к. не учитывается погрешность измерений, которая присуща любому подобному тесту.

По второму и третьему вирусу могу сказать, что одинаковые баллы для антивирусов А и Б не является справедливой оценкой, т.к. специфика детекта полиморфных вирусов говорит мне о том, что результат в 99% и 99,99% являются существенно разными результатами, так же, как и различие в 90% и 98,99%.

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

Причина - именно дискретность балльной системы.

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

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

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

С этим согласен. Экспоненциальная шкала оценки уровня детекта спасёт при этом и будет ли более точной, чем балльная?

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

Да, идеальной системы оценки не добиться, но её можно сделать более объективной, согласны?

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


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

Самый большой прикол в том, что:

1) Кто определил, что именно так надо разбивать на семейства? Тот кто дал сэмплы?

2) Кто сказал о том, что Starman (Allaple) вообще вирус? Ни разу не вирус, даже файлы не заражает. Это просто полиморфный дроппер. Так вот, его детект напрямую зависит от того был ли данный экземпляр дроппера у вирлаба или не был. Это связано со спецификой сигнатуры и "подпрограммы", которая ловит уже все остальное.

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

p.s. И напоследок про Авиру: а сколько сэмплов этот антивирус поймал с четким определением принадлежности к вирусу? А не Xpack/HEUR? :lol: Ведь если там был HEUR, то вы сами понимаете какое будет лечение :angry:

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


Ссылка на сообщение
Поделиться на другие сайты
Иван
С этим согласен. Экспоненциальная шкала оценки уровня детекта спасёт при этом и будет ли более точной, чем балльная?

кстати существующая балльная оценка сродни экспоненте

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


Ссылка на сообщение
Поделиться на другие сайты
Николай Головко
кстати а кто такой умный грохнул 8 постов?

Умный зачистил четыре взаимных наезда и четыре сообщения с обсуждением Витали.

У вас есть возражения?

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


Ссылка на сообщение
Поделиться на другие сайты
Иван
Умный зачистил четыре взаимных наезда и четыре сообщения с обсуждением Витали.

У вас есть возражения?

да нет наверное :rolleyes:

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
кстати существующая балльная оценка сродни экспоненте

Так я и говорил об этом:

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

Только я тут прикидывал, и экспонента получается не слишком хороша.

Есть тут один интересный вариант, сейчас обдумываю, позже напишу.

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


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

Ну вот, закончил свои неспешные рассчёты за кружечкой тыквенного сока :)

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

Делаем следующие предположения.

1. Если детект менее 80% - ставим 0 баллов - у пользователя большие проблемы.

2. Если детект 90% - ставим 16,46 баллов (почему такая "некруглая" цифра - ниже).

3. Если детект 99% - ставим 90 баллов.

4. Если детект 99,75% - ставим 100 баллов.

5. Если детект более 99,75% - ставим 100 баллов.

Задача сводится к построению кубической параболы, проходящей между точками (80;0), (90;16,46), (99;90), (99,75;100).

А эта задача легко сводится к решению системы из 4 линейных уравнений.

При этом было бы неплохо, чтобы производная этой кубической функции в точке x=80% была нулевой. Именно этим объясняется цифра в 16,46 баллов за 90% детекта, я с помощью неё добился практически нулевой производной на стыке x=80%.

В результате у меня получилась следующая функция:

y=0.009419*x^3-2.19037*x^2+169.6099*x-4373.1

Да, немного некрасиво в таком виде, но в прикреплённой картинке можно посмотреть, как она хорошо описывает наши мысли по поводу того, какой продукт должен получать больше баллов, а какой - меньше. При этом совершенно нет скачков между продуктами с близким результатом - вот сила непрерывности!

Итого, каждый антивирус на каждом вирусе может получить от 0 до 100 очков, причём эти очки получаются довольно справедливо.

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

На этот раз результаты получились такими:

F-Secure 99,90001

Kaspersky 99,90001

Avira 99,70220

Avast 93,23864

AVG 86,82911

Eset 83,67755

DrWeb 83,52079

BitDefender 72,79886

Agnitum 72,39108

Microsoft 71,40319

Panda Security 68,50698

Trend Micro 61,62200

Symantec 59,08700

VBA 57,06177678

Sophos 52,37361

McAfee 46,91901

Видим, что все продукты преодолели порог 40% от максимального количества баллов, большинство даже 60%-ый порог преодолели. Т.е. оценка является более объективной, и на ней можно построить новую систему выдачи наград, при которой не получат бронзовую награду те антивирусы, которые детектируют полиморфы с качеством 40% :)

Вот примерно такие мысли.

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

poly.png

post-322-1204480324_thumb.png

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


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин
p.s. И напоследок про Авиру: а сколько сэмплов этот антивирус поймал с четким определением принадлежности к вирусу? А не Xpack/HEUR? laugh.gif Ведь если там был HEUR, то вы сами понимаете какое будет лечение angry.gif

Таких вердиктов было НОЛЬ. Вы просто не можете смериться с крутость этого антивируса ;)

Все вердикты были четкими.

*********************

Что касается системы оценки результатов, то функция зависимости баллов от процента детекта была экспоненциальная. Это связано с тем, что пропуск уже небольшего количества критичен - чем ближе к 100% тем быстрее падает количество баллов.

Взять просто проценты было бы в корне не верно. Зачем тогда разбивали на семейства, проводили сложную и нужную аналитическую работу? Просто ты бы свалили все в кучу и замерили бы общий детект.

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

Валерий, согласен с предложенной тобой схемой в части присоединения к максимальному баллу за 100% какой-то окрестности, скажем, 99.8-100% это бы снизило зависимость от возможных примесей "битых" самплов и повысило устойчивость результатов.

В первоначальном варианте была 5-бальная система оценки результатов, более демократичная, но я от нее отказался по причине того, что декект на уровне менее 90% не должен ИМХО как-то оцениваться, так как слишком плохой. Это все таки означает пропуск каждого 10-го образца.

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


Ссылка на сообщение
Поделиться на другие сайты
sww
Таких вердиктов было НОЛЬ. Вы просто не можете смериться с крутость этого антивируса ;)

Все вердикты были четкими.

О да, мы просто трепещим перед авирой. Что забавно, на наших сэмплах in lab такие вердикты были :rolleyes:

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


Ссылка на сообщение
Поделиться на другие сайты
Сергей Ильин
1) Кто определил, что именно так надо разбивать на семейства? Тот кто дал сэмплы?

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

2) Кто сказал о том, что Starman (Allaple) вообще вирус? Ни разу не вирус, даже файлы не заражает. Это просто полиморфный дроппер. Так вот, его детект напрямую зависит от того был ли данный экземпляр дроппера у вирлаба или не был. Это связано со спецификой сигнатуры и "подпрограммы", которая ловит уже все остальное.

В описании теста я писал "вредоносные программы (далее вирусы)", так проще для понимания читателями. Вы же не будете спорить, что Starman (Allaple) нужно было включать в тест?

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

Где такие люди? Пока у Anti-Malware.ru их нет, вот и обходимся своими силами.

Т.е. оценка является более объективной, и на ней можно построить новую систему выдачи наград, при которой не получат бронзовую награду те антивирусы, которые детектируют полиморфы с качеством 40% smile.gif

Проблема в том, что 40% и даже 60% - это очень низкий процент, который означает пропуск примерно каждого 2-го сампла. В топку такие продукты! Какие им награды ...

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


Ссылка на сообщение
Поделиться на другие сайты
Valery Ledovskoy
Валерий, согласен с предложенной тобой схемой в части присоединения к максимальному баллу за 100% какой-то окрестности, скажем, 99.8-100% это бы снизило зависимость от возможных примесей "битых" самплов и повысило устойчивость результатов.

ок.

В первоначальном варианте была 5-бальная система оценки результатов, более демократичная, но я от нее отказался по причине того, что декект на уровне менее 90% не должен ИМХО как-то оцениваться, так как слишком плохой. Это все таки означает пропуск каждого 10-го образца.

А в принципе-то непрерывная балльная система чем не нравится? Ведь мы избавляемся от всех недостатков дискретности.

Если нужно получить 0 баллов на 90% детекта и ниже, а 100 баллов на 99,8% и выше, то можно построить и такую гладкую функцию между 90% и 99,8%.

Или Вы в принципе такой путь отвергаете?

Проблема в том, что 40% и даже 60% - это очень низкий процент, который означает пропуск примерно каждого 2-го сампла. В топку такие продукты! Какие им награды ...

Я про то говорил, что бронзовые медали давали за 40% от максимального количества баллов.

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


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

Даже один пропущенный работоспособный сампл полиморфика через NNN поколений приведет к полному заражению машины недетектящимся вариантом вируса. Так что у детекта есть только два варианта - или 100% или 0% и никакой "бронзы" за 40%

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

  • Upvote 5

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


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

Результаты теста опубликованы на английском языке

http://www.anti-malware-test.com/?q=node/47

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


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

  • Сообщения

    • PR55.RP55
      Несколько не по теме. Но для владельцев сайтов актуально... https://www.comss.ru/page.php?id=20880
    • santy
      RP55, По п.10 уже есть реализация: в 5.04 o Переменные окружения всех пользователей с некорректным содержимым теперь добавляются
         в список как подозрительные объекты со статусом "ПЕРЕМЕННАЯ".
         Удаление такого объекта приведет к удалению переменной пользователя или 
         к восстановлению значения по умолчанию если это системная переменная.   по п. 8, для задач в uVS публикуется командная строка, но то что стали модифицировать известные задачи, это да, теперь придется за всеми задачами следить по п.7 В uVS есть указание на то что известный файл размещен по нестандартному пути, по идее тоже должно попасть в подозрительные. по п.6 Ранее уже сталкивались с подобным зловредом,  здесь, https://chklst.ru/forum/discussion/76/kak-udalit-bekdor-crexv-i-vosstanovit-normalnuyu-rabotu-menyu-pusk-v-xpvistaseven  
    • demkd
      ИИ — полезная штука, но, к сожалению, бесплатные версии, как тот же Google Gemini Flash, тупенькие на уровне 12b моделей, делают колоссальное число ошибок по мелочам. Яблочко от яблони... Мало того, "новое" у них обычно старое с отставанием на год, и это в лучшем случае. Я сейчас как раз занимаюсь новой, уже 3-й версией своего "Клавиатурного помощника". В нём будет поддержка локального ИИ, горячих ИИ-клавиш, голосовых команд, голосового ввода и вспомогательной LLM для переводов, правки текста и т.п. Именно локального ИИ без необходимости обращения в сеть и сопутствующих утечек данных И это не для старого железа — нужно как минимум много памяти и современный процессор, в идеале хотя бы RTX 5060 Ti 16 ГБ в качестве ускорителя. А результат, ну, такой себе. ИИ слишком склонен ошибаться, и доверять ему что-то серьёзное пока не стоит, даже код пишет, который как-то работает, но в нём масса мелких и незаметных ошибок и уязвимостей. 
      Текст исправлен с помощью Google Gemma 4 E4B. 
    • PR55.RP55
      Вы сказали: "Найди все новые ключи которые появились 2026 г. и ранее не использовались... Можешь ?"
      *Да, я могу помочь* составить список новых ключей реестра и путей
      автозагрузки, которые вредоносное ПО использует в текущих кампаниях
      (включая модификации 2026 года), маскируясь под легальные системные
      компоненты. ( скопирую частично) :   * *|HKLM\SOFTWARE\Classes\Protocols\Filter|* и *|\Handler|* — новые
          модификации Adware перехватывают протоколы edge:// или msproedg://
          для подмены поисковой выдачи.   * *|HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss|* —
          использование подсистемы WSL для скрытого автозапуска
          Linux-ориентированных рекламных модулей, незаметных для стандартных
          триггеров автозагрузки Windows. Современные зловреды (особенно Adware и майнеры) научились прописываться
      в тихий автозапуск без создания классических ключей |Run| или
      |Services|. Они используют встроенный механизм Windows 10/11 —
      *псевдонимы выполнения приложений*.   * *Суть*: В реестре создается связь в ветке
          |HKCU\Software\Microsoft\Windows\CurrentVersion\App Paths| или через
          механизм |AppXPackage|. Зловред подменяет вызов легальной команды
          (например, при наборе пользователем |notepad| или |calc| в строке
          «Выполнить») и запускает свое тело.
        * *Что добавить в памятку*: Обращать внимание на появление кастомных
          записей в блоке «Псевдонимы приложений» и проверять, куда
          перенаправляются стандартные системные вызовы. 2. Подмена через каталоги |Lxss| (WSL — Windows Subsystem for Linux)
      Это одна из самых опасных современных тенденций, так как многие
      антивирусы до сих пор слабо сканируют Linux-среду внутри Windows.   * *Суть*: Майнеры и стилеры прописывают свой запуск внутри
          дистрибутива WSL (ключ реестра
          |HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss|). При старте
          Windows запускается скрытая фоновая сессия WSL, которая активирует
          ELF-бинарник (Linux-вирус). В логах автозапуска Windows это выглядит
          как легальный старт службы |wsl.exe|, но с хитрыми аргументами.
        * *Что добавить в памятку*: Формула «А+В+С»: если |wsl.exe|
          запускается автоматически с флагами |-d| (конкретный дистрибутив)
          или скрытыми bash-скриптами — это 100% повод для изоляции и проверки
          содержимого виртуального диска VHDX. 3. Продвинутый Timestomping с подделкой под апдейты ОС
      Раньше вирусописатели просто копировали даты у соседних файлов
      (|kernel32.dll| и т.д.). Теперь они действуют умнее:   * *Суть*: Дата создания файла выставляется ровно на день/час крупного
          официального обновления Windows (например, подстраиваются под график
          Patch Tuesday от Microsoft). Аналитик смотрит на лог uVS, видит дату
          (например, |14.10.2025|) и думает: «А, ну это тогда накопительный
          апдейт прилетел, файл чистый».
        * *Что добавить в памятку*: Правило проверки контрольных сумм. Не
          верить датам, даже если они идеально совпадают со временем
          системного обновления. Если у файла из папки |System32| с
          «правильной» датой обновления отсутствует валидная ЭЦП (или статус
          |Цифр. подпись: НЕТ|) — это критический триггер. 4. Атаки типа Living off the Land (LotL) через новые системные утилиты
      Вместо использования заезженных |powershell.exe| или |cmd.exe|, которые
      сейчас жестко блокируются любым EDR/антивирусом, малварь перешла на
      легальные, но редкие утилиты Windows (LOLBins).   * *Суть*: Для скачивания и запуска вредоносного кода используются
          системные компоненты:
            o |curl.exe| (теперь встроен в Windows) — для скрытой загрузки
              полезной нагрузки.
            o |tar.exe| — для распаковки зашифрованных архивов со стилерами
              прямо «на лету».
            o |winget.exe| (Windows Package Manager) — для скачивания
              вредоносных утилит из легальных репозиториев.
        * *Что добавить в памятку*: В uVS нужно тщательно анализировать
          параметры запуска командной строки в Планировщике задач (|TASKS|),
          если там фигурируют |curl|, |tar| или |bitsadmin|, качающие что-то с
          внешних IP-адресов. 6. Скрытые модификации через COM-объекты (COM Hijacking без изменения
      файлов)
      Вместо перезаписи файлов в |System32| или создания явных ключей |Run|,
      малварь перехватывает легальные системные интерфейсы через реестр.   * *Суть*: Зловред прописывает путь к своей вредоносной DLL в ветку
          *|HKCU\Software\Classes\CLSID\{GUID}\InprocServer32|*. При этом
          берется GUID легального и часто используемого компонента Windows
          (например, Проводника, контекстного меню или планировщика). Как
          только система или пользователь совершает обычное действие
          (открывает папку, кликает правой кнопкой мыши), Windows
          автоматически подгружает вредоносную DLL.
        * *Что добавить в памятку*: В uVS такие объекты часто попадают в
          категорию «Подозрительные CLSID» или скрытые расширения оболочки.
          Если в ветке |HKCU| (пользовательский уровень) переопределяется
          системный GUID, который по умолчанию должен жить только в |HKLM|
          (уровень системы) — это явный признак перехвата. 7. Спуфинг цифровой подписи через уязвимости каталогов (Catalog Signing
      Spoofing)
      Малварь научилась обходить базовую проверку подписей, из-за чего в логах
      некоторых утилит файл может ошибочно помечаться как «Подписан Microsoft».   * *Суть*: Используются уязвимости в механизме проверки файлов через
          каталоги безопасности Windows (|.cat| файлы). Вредоносный бинарник
          модифицируется таким образом, что его хэш совпадает с хэшем
          легального файла в базе данных каталогов (используются коллизии или
          специфические уязвимости парсинга).
        * *Что добавить в памятку*: Правило двойной проверки. Если файл
          находится в нетипичном месте (например,
          |C:\Users\...\Temp\svchost.exe|), но uVS или ОС рапортует, что у
          него «Валидная подпись Microsoft» — необходимо принудительно
          отправлять хэш файла на VirusTotal через встроенную функцию uVS или
          проверять подпись сторонними утилитами (например, |Sigcheck| от
          Sysinternals) с проверкой отзывов сертификатов. 8. Эксплуатация механизма «Служб доставки обновлений» браузеров
      (Edge/Chrome Maintenance)
      Рекламное ПО (Adware) и кликеры ушли от создания собственных явных служб
      и теперь паразитируют на легальных планировщиках браузеров.   * *Суть*: Вредоносный скрипт не создает новую задачу в Планировщике.
          Вместо этого он модифицирует параметры /уже существующей/ легальной
          задачи, например, |MicrosoftEdgeUpdateTaskMachineCore|. В
          оригинальную команду дописывается скрытый аргумент
          (аргумент-паразит), который раз в сутки скачивает или запускает
          рекламный модуль. Аналитик видит знакомое имя задачи Edge, видит
          легальный путь к апдейтеру и пропускает её.
        * *Что добавить в памятку*: При анализе задач Планировщика (|TASKS|) в
          uVS нужно смотреть не только на имя файла, но и *полностью
          разворачивать строку аргументов*. Любые добавленные URL-адреса,
          вызовы |cmd /c|, или сторонние пути в параметрах легальных служб
          обновления — это стопроцентный признак компрометации. 10. Фейковые системные переменные в путях автозапуска
      Обман визуального восприятия аналитика через манипуляцию переменными среды.   * *Суть*: В реестре или планировщике путь к файлу прописывается как
          |%SystemRoot%\System32\drivers\malware.sys|. Но перед этим на уровне
          пользователя (|HKCU\Environment|) создается кастомная переменная
          |%SystemRoot%|, которая указывает вовсе не на |C:\Windows|, а на
          |C:\Users\Public\Documents|. В итоге аналитик глазами видит
          «безопасный» системный путь, а система при загрузке идет в скрытую
          пользовательскую папку.
        * *Что добавить в памятку*: Всегда проверять блок «Переменные
          окружения» в начале лога uVS. Любые попытки переопределить
          стандартные переменные вроде |%SystemRoot%|, |%WinDir%| или
          |%ProgramFiles%| на уровне текущего пользователя — это критическая
          угроза.
    • PR55.RP55
      Сейчас дал ИИ задание напиши скрипт и... Вот:  ( взял Инфо. из одного из старых образов) Скрипт лечения для uVS Чтобы полностью удалить эту службу, связанные с ней файлы и очистить ссылки в реестре, выполните следующий скрипт: text ; uVS v4.15.1 [Script] ; Target OS: Windows ; Удаление вредоносной службы и основного файла апдейтера delref %Network%\C:\PROGRAM FILES (X86)\YONTOO\Y2DESKTOP.UPDATER.EXE ; Удаление исполняемого файла в AppData, вызываемого через параметры службы delref %AppData%\YONTOO\YONTOODESKTOP.EXE ; Принудительное удаление самой службы из реестра delsrv Yontoo Desktop Updater ; Очистка остаточных путей и каталогов Yontoo deldir C:\Program Files (x86)\Yontoo deldir C:\Users\cappu44ino\AppData\Roaming\Yontoo ; Перезагрузка для применения изменений restart --------- Я сильно не увлекался - так для примера.  
×