Принципы работы механизмов АВПО и детектирование malware в системе
Антивирусное программное обеспечение (АВПО) — одна из первых линий защиты конечных устройств и серверных систем. Современные механизмы обнаружения угроз давно вышли за рамки классического сигнатурного анализа. АВПО сочетает в себе несколько подходов: поведенческий анализ процессов, эвристику, машинное обучение, репутационные проверки файлов и облачные механизмы анализа. Это позволяет выявлять не только известные вредоносные программы, но и новые, ранее не встречавшиеся образцы, включая угрозы класса zero-day
За каждым срабатыванием антивируса скрывается многоступенчатая система анализа и принятия решений. Для аналитика SOC важно не только обнаружить саму угрозу, но и разобраться в механике ее выявления: какой именно модуль сработал, по каким признакам объект классифицирован как вредоносный, насколько полученный результат можно считать достоверным. Эта информация позволяет корректно интерпретировать события кибербезопасности, выстраивать цепочки корреляции и отличать реальные инциденты от ложных срабатываний.
Вредоносное программное обеспечение: понятие, классификация и векторы распространения
Термин «ВПО», пожалуй, один из самых распространенных в кибербезопасности. Так как это центральная тема статьи, рассмотрим его подробнее.
Вредоносное программное обеспечение (ВПО) — это программный код, реализованный в различных формах и выполняющий действия в системе без ведома или воли пользователя, из‑за чего нарушается ожидаемая модель работы устройства, приложений или сетевого взаимодействия.
ВПО в системе может:
- снижать производительность вычислительных ресурсов;
- передавать злоумышленнику контроль над ОС и ее компонентами;
- красть конфиденциальную информацию, включая учетные данные и платежные реквизиты;
- отключать или обходить механизмы антивирусной защиты;
- шифровать, удалять, модифицировать или скрывать данные;
- отображать навязчивую рекламу;
- загружать и устанавливать дополнительное опасное ПО.
Вредоносные программы различаются по принципу работы, способам распространения и выполняемым действиям. В таблице ниже рассмотрим наиболее популярные типы ВПО и рассмотрим подробно по одному примеру:
| Тип вредоносной программы | Описание | Пример |
|---|---|---|
| Черви (worms) |
Распространяются по компьютерным сетям, используя уязвимость ОС. Представляют собой отдельный файл, который самовоспроизводится для заражения других компьютеров, но не может заражать файлы в системе. Черви часто выполняют фрагменты кода, созданного для повреждения системы, например:
|
SQL Slammer атаковал серверы Microsoft SQL Server через известную уязвимость в протоколе UDP (порт 1434). Зараженный сервер немедленно сканировал случайные IP‑адреса и отправлял вредоносные пакеты, заражая следующие машины. За первые 10 минут было заражено более 75 000 серверов. Другие примеры: WannaCry, Petya |
| Вирусы (virus) |
Программный код, который распространяется через зараженные файлы, съемные носители, задействует активность пользователя, к примеру открытие документа, подключение USB‑устройств, запуск зараженного ПО. Задача вируса — нанести вред ОС. Пока пользователь не взаимодействует с зараженной программой или файлом, вирус безвреден для системы: не размножается и не распространяется самостоятельно. Активируется только после запуска зараженного ПО, затем удаляет данные, портит файлы, замедляет систему |
CIH — файловый вирус, поражавший исполняемые файлы ( Другой пример: ILOVEYOU |
| Шпионские программы (spyware) |
Скрываются на устройстве пользователя, отслеживают его активность, крадут конфиденциальную информацию с помощью создания скриншотов, прочтения буфера обмена, считывания вводимых данных на клавиатуре. Клавиатурный шпион (кейлоггер) — один из представителей такого ВПО. Он записывает каждое нажатие клавиши. Злоумышленники могут использовать кейлоггер для кражи конфиденциальной информации, например учетных данных пользователей или данных платежных карт |
CoolWebSearch — угонщик браузера (browser hijacker), который захватывал контроль над браузером и перенаправлял пользователя на сайты, приносившие доход их создателям. Использовал уязвимости в Microsoft Internet Explorer. CoolWebSearch было заражено более 8% всех компьютеров в мире. Другие примеры: VkurSe, Micro Keylogger |
| Троянские программы (trojans) |
Маскируются под легитимное ПО, но при запуске выполняют необходимые злоумышленникам действия. Троянская программа контролирует устройство, загружает дополнительное ПО, собирает персональные данные. К троянам относятся бэкдоры и RAT (троян удаленного доступа). Первые предоставляют злоумышленникам множество функций: от установки и запуска другого ПО до отслеживания действий пользователя. Вторые — позволяют злоумышленнику управлять компьютером удаленно |
Trickbot — банковский троян, который похищал конфиденциальную информацию (учетные данные для входа, финансовые сведения). Распространялся посредством фишинговых рассылок с вложением или ссылкой, после открытия которых внедрялся в систему, собирал данные с зараженного устройства, перехватывал сетевой трафик, а также мог загружать дополнительные вредоносные компоненты. C момента обнаружения заразил более 1 миллиона устройств по всему миру. Другой пример: Qakbot |
| Программы-вымогатели (ransomware) |
Блокируют доступ пользователей к системе или данным, также могут шифровать критически важные данные или всю систему с целью получения выкупа за восстановление. Чаще всего распространяются через фишинговые письма с ссылками или вложениями, зараженные документы, поддельные обновления ПО или через уязвимости в сетевых сервисах. Используют активность пользователя, например переход по ссылке, открытие вложения из письма, запуск подозрительного или неизвестного файла |
Petya — пример ВПО, совмещающего свойства червя и вымогателя. Программа распространялась самостоятельно по сети, а после заражения блокировала доступ к данным. На компьютер жертвы ВПО попадало через фишинговые письма с вложениями, а затем пыталось поразить часть жесткого диска (MFT, MBR) с данными, необходимыми для загрузки компьютера и доступа к файлам. Затем выводилось сообщение о блокировке компьютера и информацией, как получить цифровой ключ для дешифровки данных. В версии 2017 года (NotPetya) этот ключ был фиктивным, так как ВПО на самом деле безвозвратно уничтожало файлы. За первые несколько часов ВПО заразило более 300 тысяч компьютеров в 65 странах. Другие примеры: Locky, Bad Rabbit, Phobos |
| Потенциально нежелательные программы (ПНП) (adware) |
Чаще всего это дополнение легитимного ПО, которое можно отключить при установке. Не имеют отношения к загружаемой программе, предлагают рекламу. Также могут быть потенциально опасными приложениями, которые мешают нормальному функционированию ПК. Пример ПНП — рекламные программы, которые демонстрируют нежелательную или вредоносную рекламу на мониторе устройства, перенаправляют на рекламные сайты, подменяют домашние страницы браузера, а также собирают данные пользователей, например, для перепродажи |
Fireball — рекламный инструмент и browser hijacker. Распространялся через бесплатные и пиратские приложения (игры, программы), которые пользователи намеренно загружали и устанавливали. Fireball перенаправлял трафик для накрутки показов рекламы, а также крал поисковые запросы для маркетинговых агентств. Заразил около 250 миллионов компьютеров по всему миру. Другие примеры: Mindspark, Appearch |
| Логические бомбы (logic bomb) |
Выполняют вредоносную нагрузку при определенных условиях. Например, в заданную дату и время, определенный по счету вход пользователя в систему, нажатие конкретной комбинации клавиш, запуск иного ПО на устройстве жертвы. Чаще всего распространяются через внедрение в легитимное ПО на этапе разработки, через обновления, зараженные файлы или уже присутствующие в системе вирусы и черви, которые доставляют и активируют бомбу. Задача этого ВПО — нанести максимальный урон в нужный злоумышленнику момент. До этого оно никак себя не проявляет: не размножается, не удаляет данные, не модифицирует файлы, не расходует ресурсы системы |
|
| Руткиты (rootkit) |
Предоставляют административный доступ к системе, а также скрывают присутствие вредоносного кода и его действий от пользователя и АВПО. Распространяются через эксплуатацию уязвимостей ОС, драйверов, BIOS/UEFI, фишинговые вложения, а также через установку в ядро ОС, загрузку в виде драйвера или модуля. Задача руткита — обеспечить долговременный скрытый контроль над зараженной системой для последующих атак, например кражи данных, шпионажа, установки дополнительного ВПО |
Moriya — руткит, который работает на уровне ядра Windows и создает скрытые бэкдоры на серверах жертв. Распространяется через компрометацию уязвимых веб‑серверов. Moriya внедряет неподписанный драйвер в память ядра, обходя механизмы проверки цифровых подписей с помощью уязвимости в драйвере VirtualBox. Затем руткит перехватывает весь входящий сетевой трафик на уровне ядра с помощью Windows Filtering Platform и отфильтровывает специально помеченные пакеты с командами злоумышленников, скрывая эти пакеты от системы и антивирусов. Другой пример: Remsec |
| Майнеры (cryptominer) |
Позволяют майнить криптовалюту за счет вычислительных ресурсов хоста (процессора и видеокарты), на котором запущено ВПО. Распространяется через фишинговые письма, зараженные веб‑сайты, поддельные установщики популярных программ, взломанные версии софта. Задача майнера — получить криптовалюту (например, Monero, Bitcoin) за счет чужих вычислительных мощностей без ведома владельца устройства. При длительной работе майнер приводит к повышенному износу оборудования, перегреву, увеличению энергопотребления и заметному снижению производительности устройства |
LolMiner — майнер для GPU (видеокарт), поддерживающий множество алгоритмов и криптовалют. Основан на OpenCL и первоначально ориентировался на майнинг с помощью видеокарт AMD. Позже в него добавили CUDA‑бэкенд, что обеспечило майнинг на NVIDIA, а с помощью смешанных конфигураций — на AMD и NVIDIA. При запуске LolMiner подключается к указанному майнинг‑пулу по протоколу Stratum, авторизуется с помощью кошелька пользователя и начинает вычислять хеши и отправлять результаты в майнинг‑пул как подтверждение выполненной работы. Другие примеры: GMiner, NBMiner, XMRig |
Аналитику SOC необходимо разбираться в типах ВПО, чтобы приоритизировать реагирование. Например, обнаружение шифровальщика требует немедленной изоляции хоста, тогда как ПНП можно разбирать в плановом режиме. Также тип ВПО подсказывает, где искать следы активности: руткит будет скрывать процессы, троян, скорее всего, установит соединение с C2, майнеры будут использовать вычислительные ресурсы хоста, нагружая систему.
Способы внедрить вредоносное ПО на устройство жертвы
Выделяют несколько способов распространения вредоносного ПО:
- Фишинговые письма. Могут содержать:
- Ссылки на веб‑ресурсы, предназначенные для кражи учетных данных или загрузки вредоносного ПО.
- Вложения (документы Word, Excel, PDF, архивы), при открытии которых может выполняться вредоносный код, например, через макросы.
- Нелицензионное ПО. Установочные файлы, активаторы, генераторы ключей, взломанные версии программ и игр нередко содержат встроенные вредоносные компоненты.
- Скомпрометированные веб‑сайты. Злоумышленники используют уязвимости в веб‑приложениях и внедряют вредоносные фрагменты кода. Чаще всего скрытый iframe, перенаправляющий пользователя на сервер управления и контроля (C2), с которого загружается вредоносное ПО.
- Всплывающая реклама и установщики программ. Могут содержать дополнительное нежелательное ПО или вредоносные компоненты.
- Компрометация цепочек поставок (supply chain attacks). ВПО внедряется не напрямую на устройство пользователя, а через доверенное программное обеспечение, обновления или сторонние компоненты, которые используются для разработки и доставки ПО. Злоумышленники могут модифицировать исходный код, установочные пакеты или механизмы обновления. В результате вредоносный компонент распространяется вместе с легитимным продуктом и запускается в доверенной среде.
- Заражение через съемные носители. При подключении носителя к системе может автоматически выполниться вредоносный код или запуститься зараженный файл. Актуальность метода существенно снизилась за последнее десятилетие, но он все еще встречается.
В реальных атаках несколько методов часто комбинируются, поскольку многоступенчатые цепочки затрудняют обнаружение, позволяют обходить различные уровни защиты и повышают эффективность доставки вредоносного кода. К примеру, фишинговая рассылка ведет на скомпрометированный сайт с плавающим фреймом для переадресации на сервер управления и контроля, с которого и выполняется загрузка ВПО.
Антивирусное программное обеспечение
Для программных средств, предназначенных для обнаружения и нейтрализации вредоносного кода, IT‑специалисты используют два термина: средство антивирусной защиты (САВЗ) и антивирусное программное обеспечение (АВПО). Понятия отличаются контекстом и сферой употребления.
САВЗ — термин, который используется в нормативной и регуляторной документации РФ: в ГОСТах, документах ФСТЭК России, а также в технических заданиях на закупку средств защиты информации в государственных и муниципальных организациях. В этом контексте термин подчеркивает соответствие программного продукта установленным требованиям в области защиты информации.
АВПО — более общее и практическое обозначение, которое используется в среде IT‑специалистов, клиентов, а также в образовательных и прикладных материалах. Термин описывает функциональное назначение продукта, не привязывая его к конкретным нормативным требованиям или классам сертификации.
В статье будем использовать термин АВПО как более универсальный и понятный.
Антивирусное программное обеспечение — это ПО, предназначенное для обнаружения, блокировки и удаления вредоносного кода на различных этапах его выполнения в системе.
Обнаружив вредоносный объект, АВПО может:
- Попытаться «вылечить» файл, удалив вредоносный код, но сохранив функциональность файла.
- Поместить файл в карантин для изоляции от остальной системы, ограничить возможность его запуска и взаимодействия с другими компонентами ОС.
- Блокировать выполнение процесса или прервать его работу при выявлении вредоносного поведения в реальном времени.
- Удалить файл, если лечение и изоляция невозможны.
В случае ложного срабатывания администратор может восстановить объект из карантина или добавить его в список исключений политики безопасности.
Типы АВПО по архитектуре и способу управления
По этим параметрам АВПО делят на два основных типа:
- Автономные решения. Устанавливаются на отдельные рабочие станции или ограниченное количество устройств и функционируют без централизованного управления. Обновление баз и настройка таких решений происходит локально на каждом хосте.
- Централизованные решения. Основаны на архитектуре «сервер управления ↔ агенты», применяются в средних и крупных корпоративных инфраструктурах. Обеспечивают централизованное управление политиками безопасности, распространение обновлений, сбор телеметрии и управление реагированием на инциденты.
Сравним детальнее эти подходы.
| Характеристика | Автономное решение | Централизованное решение |
|---|---|---|
| Принцип работы |
Устанавливается отдельно на каждое устройство (компьютер, ноутбук, сервер), функционирует полностью самостоятельно |
Включает в себя сервер управления и агенты. Сервер управления хранит политики, дистрибутивы обновлений и собирает статистику со всех конечных устройств. Агенты — легковесные модули на конечных устройствах, получающие настройки и выполняющие задачи от сервера управления, а также передающие ему телеметрию |
| Управление политиками |
Настраивается вручную локально на каждом конечном устройстве |
Групповые политики применяются массово, удаленно. Задаются на сервере и автоматически передаются агентам |
| Мониторинг и безопасность |
Администратор не видит, выключен ли антивирус на ПК пользователя, присутствует ли вредоносный файл. Компрометация одной системы не ведет к заражению всей инфраструктуры |
Единая консоль управления показывает статус антивируса для всей сети, количество угроз, а также ведет историю событий. Компрометация сервера или одного агента может распространиться на всю инфраструктуру. Чтобы этого избежать, необходимо своевременно изолировать зараженный узел и отозвать доверенные сертификаты и ключи шифрования |
| Обновления |
Прямое из интернета (с сайта поставщика) или вручную (дистрибутивы скачиваются с сайта вендора и переносятся по USB) |
Сервер управления скачивает обновления один раз и раздает их агентам внутри сети |
| Контроль пользователя |
Пользователь с правами администратора может отключить защиту или изменить настройки |
Настройки блокируются или переопределяются сервером. Пользователь не может самостоятельно внести изменения |
| Реагирование |
Администратор узнает о ВПО, только когда пользователь проинформирует об этом, или самостоятельно при физическом взаимодействии |
Сервер управления отправляет уведомления администратору при обнаружении подозрительной активности (найдено ВПО, отключена защита или давно не обновлялись базы) |
| Ресурсы и производительность |
Каждая система работает независимо, использует собственные ресурсы процессора и памяти для сканирования, обновления вирусных баз и принятия решений о блокировке угроз |
Основная нагрузка по анализу лежит на сервере, агенты отправляют только метрики |
| Хранение логов |
Локально на каждом устройстве (в файлах или системном журнале). При переполнении диска старые записи циклически затираются. Для анализа событий с ПК администратору необходим физический доступ к устройству, что замедляет расследование инцидентов. Компрометация устройства ведет к безвозвратной потере истории событий с этого узла |
Все агенты передают логи на сервер управления, который выступает единым хранилищем истории обнаружений, изменений политик, запусков сканирований и действий пользователя. Для управления объемом хранимых данных администратор настраивает параметры ротации, например срока хранения журналов (по умолчанию 90 дней), максимального размера файла (например, 300 МБ). Удаленный доступ к логам любого ПК происходит из консоли управления, без физического подключения к устройству. Компрометация отдельного агента не влечет потери его логов. Требуется надежная защита самого сервера — настройка резервного копирования и контроля доступа |
В корпоративной среде автономное АВПО постепенно уступает место централизованным решениям. Такая архитектура позволяет внедрять единую политику безопасности, обеспечивать централизованный мониторинг и аудит событий, а также эффективно управлять инфраструктурой, в которой количество защищаемых устройств исчисляется десятками, сотнями и тысячами.
Типы АВПО по механизму защиты
По этому параметру антивирусные решения классифицируются так:
- Антивирусные сканеры. Запускаются как автоматически по расписанию, так и по запросу пользователя или администратора. Проверяют оперативную память, файловую систему и загрузочные секторы. Обнаружив ВПО, могут вылечить, переместить в карантин или удалить файл.
- Резидентные мониторы (on‑access scanner). Работают непрерывно в фоновом режиме, перехватывая обращения к файлам и процессам в реальном времени. При обнаружении подозрительного объекта блокируют к нему доступ и уведомляют пользователя.
- Сигнатурные сканеры (on‑demand scanner). Запускаются по расписанию или по требованию пользователя/администратора. Сканируют оперативную память, загрузочные секторы дисков и запускаемых файлов, чтобы выявить новые или уже известные образцы ВПО. Обнаружив вредоносный файл, пытаются его вылечить.
- Ревизоры (integrity checkers/monitors). Функционируют на основе подсчета контрольных сумм файлов и программ в системе. Работа состоит из двух этапов. Первый — формирование базы эталонных значений контрольных сумм (предполагается, что в это время система не заражена). Второй — периодическое сравнение актуальных характеристик файлов и ПО в системе с эталонными значениями из базы данных. Выявив любое несоответствие, антивирусное ПО информирует пользователя.
- Поведенческие анализаторы (behavior blockers). Работают непрерывно в фоновом режиме, наблюдая за действиями программ. Главная особенность — выявляют и предотвращают распространение вредоносных файлов на ранних стадиях заражения. Обнаружив подозрительные манипуляции в файловой системе, блокируют эти действия.
Методы обнаружения вредоносного программного обеспечения
Современные средства антивирусной защиты объединяют несколько методов обнаружения ВПО. Комплексный подход повышает эффективность и снижает вероятность ложных срабатываний. Существует пять методов обнаружения:
- сигнатурный анализ,
- эвристический анализ,
- поведенческий анализ,
- машинное обучение,
- облачные технологии.
Рассмотрим особенности каждого.
| Метод обнаружения ВПО | Принцип работы | Обнаруживаемые угрозы | Слабые места | Вероятность ложных срабатываний |
|---|---|---|---|---|
| Сигнатурный анализ |
Сравнение хешей файлов, уникальной последовательности байтов или фрагмента программного кода с базой известных угроз |
Известные и задокументированные образцы ВПО |
Не обнаруживает новые и модифицированные угрозы. Требует постоянного обновления баз данных |
Низкая: срабатывает только при точном совпадении с сигнатурой |
| Эвристический анализ |
Обнаружение особенностей кода и поведения программ, характерных для ВПО |
Новые и ранее неизвестные угрозы, модифицированные версии известного ВПО |
Не знает точно, является ли файл вредоносным. Оценивает только степень подозрительности |
Высокая: легитимные программы с нестандартным поведением часто попадают под подозрение |
| Поведенческий анализ |
Мониторинг действий программы в реальном времени |
ВПО, которое обходит сигнатурный анализ, шифровальщики, руткиты |
Высокая нагрузка на вычислительные ресурсы системы. Современные ВПО научились обнаруживать мониторинг и изменять свое поведение в системе |
Средняя: зависит от настройки правил мониторинга |
| Машинное обучение |
Классификация файлов по набору признаков на основе обученной модели |
Новые и модифицированные угрозы, аномальное поведение |
Требует хранения большого объема данных для обучения. Модель может ошибаться в нетипичных файлах |
Средняя: зависит от качества обучающей выборки |
| Облачный анализ |
Проверка файла на удаленных серверах с актуальными базами |
Новые угрозы, быстро распространяющееся ВПО |
Требует постоянного и стабильного интернет‑соединения. Риск передачи конфиденциальных данных на внешний сервер |
Низкая: базы обновляются в реальном времени |
Понимание сильных и слабых сторон каждого метода помогает аналитику правильно интерпретировать срабатывания. Например, высокий процент ложных срабатываний у эвристического анализа означает, что событие требует дополнительной проверки, а не немедленной реакции.
Принципы работы механизмов антивирусного программного обеспечения
Чтобы обеспечить эффективную защиту, АВПО должно видеть все события в ОС: доступ к файлам, запуск процессов, изменения в реестре и сетевом трафике. ОС препятствует прямому наблюдению за этими процессами, поэтому требуется внедрять компоненты защиты на уровне ядра. Именно так и работает АВПО: устанавливает несколько компонентов, которые перехватывают активность на разных уровнях системы. Разберем эти компоненты.
Драйвер‑фильтр файловой системы
Это основной механизм, с помощью которого АВПО перехватывает обращения к файлам (открытие, создание, запись, переименование). В Windows каждое обращение к файлу происходит через драйверы файловой системы. АВПО встраивает между приложением и файловой системой свой драйвер‑фильтр. В результате любая попытка программы обратиться к файлу сначала перехватывается АВПО, и только после проверки запрос идет дальше.
Драйвер‑фильтр перехватывает запрос еще до того, как файл будет фактически открыт. То есть вредоносный код не успевает выполниться, потому что АВПО получает управление раньше и блокирует угрозу на этапе попытки доступа. Также АВПО способно проверять файлы не только при открытии, но и в момент записи на диск. Например, если браузер попытается скачать файл, драйвер‑фильтр перехватит операцию записи и проанализирует содержимое до того, как файл фактически окажется на диске.
Понимание, как работает этот механизм, важно для аналитика. Если в логах антивирусного ПО есть событие о блокировке файла, значит, файл был обнаружен и остановлен до запуска. Если же файл был скачан, но записей о срабатывании защиты нет, скорее всего, он был признан легитимным, а вредоносная активность проявилась уже после его выполнения. В таких случаях анализ не должен ограничиваться событиями проверки файлов — необходимо также изучать поведенческие события.
Перехват сетевого трафика
Некоторые виды ВПО действуют не через файлы: они загружают вредоносный код напрямую в оперативную память, передают его по сети, полностью минуя файловую систему. Для противодействия таким атакам предусмотрен отдельный механизм — сетевой драйвер.
Для фильтрации сетевого трафика в Windows существуют специальные механизмы: NDIS‑драйверы (Network Driver Interface Specification) и платформа WFP (Windows Filtering Platform). АВПО регистрирует в сетевом стеке собственные компоненты, получая возможность анализировать входящий и исходящий трафик, а именно:
- загружаемые файлы (проверяет еще в процессе загрузки, до записи на диск);
- URL‑адреса (сверяет их с актуальными базами вредоносных доменов и IP‑адресов);
- содержимое HTTP‑трафика (ищет паттерны вредоносного кода в потоке данных).
Есть важное ограничение: HTTPS‑трафик зашифрован, он остается непрозрачным для АВПО. Антивирус видит только сам факт соединения и адрес назначения, но не содержимое. А значит, вредоносный код, передаваемый по зашифрованному каналу, останется незамеченным. В корпоративной среде эту слепую зону закрывают с помощью SSL‑инспекции на уровне прокси‑сервера, но это функция дополнительных средств, а не самого АВПО.
Рассмотрим на примере. Если вредоносное ПО установит связь с C2‑сервером по HTTPS, сетевой модуль АВПО зафиксирует факт соединения с подозрительным адресом, но не содержимое обмена. Следовательно, сетевых событий от АВПО недостаточно для полного анализа, их необходимо дополнять данными с межсетевого экрана и прокси‑сервера.
Мониторинг реестра
Одно из главных мест, где ВПО оставляет свои следы и закрепляется в системе, — это реестр Windows. Именно здесь программы регистрируют автозагрузку, изменяют настройки безопасности, создают новые службы и выполняют другие системные действия.
Windows позволяет контролировать реестр через механизм Registry Callbacks. В нем можно зарегистрировать функцию, которая будет вызываться при любой операции с реестром. АВПО использует этот механизм, чтобы отслеживать подозрительные изменения в реальном времени.
Операции с реестром, которые вызывают подозрения:
- Запись в ветки автозагрузки:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run,HKLM\Software\Microsoft\Windows\CurrentVersion\Run. - Изменение параметров UAC и политик безопасности.
- Создание новых служб через
HKLM\SYSTEM\CurrentControlSet\Services. - Изменение настроек браузеров (признак рекламного ПО).
Важно понимать: легитимные программы также активно работают с реестром, поэтому операция с ним не характеризует процесс как вредоносный. Необходимо разбираться в контексте изменения. Если запись в автозагрузку делает установщик легитимной программы, это нормально. Но если такая же запись выполняется процессом, который только что скачал файл из интернета, это сигнал для расследования.
Перехват вызовов API (hooking)
В отличие от файловых, реестровых и сетевых фильтров, которые работают на уровне ядра или драйверов, перехват вызовов действует еще глубже — внутри пользовательских процессов.
АВПО внедряет свой код в запущенные процессы и перехватывает вызовы системных функций до того, как они уйдут в ядро. Например, при вызове функции CreateFile АВПО перехватывает управление, проверяет параметры и только затем решает, пропустить вызов или заблокировать. Часть вредоносного ПО работает напрямую через системные вызовы, минуя стандартные API Windows, чтобы скрыться от файловых и сетевых фильтров. Перехват вызовов API позволяет обнаружить такую активность на ранней стадии.
Создатели ВПО знают про hooking и активно пытаются его обойти. Одна из популярных техник — прямые системные вызовы (direct syscalls), при которых вредоносный код обращается к ядру в обход перехваченных API‑функций.
Если АВПО фиксирует подозрительный вызов системной функции внутри легитимного процесса (например, powershell.exe вызывает функции, характерные для инъекции кода), это серьезный индикатор, который требует проверки.
АВПО использует четыре основных механизма перехвата: файловый драйвер, сетевой драйвер, мониторинг реестра и перехват API‑процессов. Каждый закрывает свой вектор угроз: файлы, трафик, механизмы закрепления в системе и активность внутри процессов.
Понимание этих механизмов позволяет аналитику разобраться, почему система АВПО пропустила атаку. В случае обхода файлового перехвата фокус внимания смещается на сетевые события. При отсутствии подозрительной сетевой активности анализируется реестр и поведенческие события процессов. Каждый из четырех уровней перехвата оставляет диагностические следы. Задача аналитика — собрать воедино эти данные и восстановить полную картину инцидента.
Устройство базы сигнатур и ее обновление
Чтобы понять, почему сигнатурный анализ эффективно обнаруживает известные угрозы, но плохо справляется с неизвестными, необходимо разобраться в его основе — базе сигнатур. Ее устройство и механизм работы определяют сильные стороны и ограничения этого метода.
Сигнатура — это уникальный цифровой отпечаток вредоносного файла или участка кода, позволяющий антивирусному ПО однозначно распознать угрозу. Сигнатура должна точно соответствовать конкретному ВПО и не встречаться ни в одном легитимном файле. Слишком общая сигнатура вызовет ложные срабатывания на легитимные программы, а слишком специфичная — пропустит модифицированную версию того же ВПО.
Выделяют два типа сигнатур: хеш‑сигнатуры и байтовые.
Хеш-сигнатуры
Это уникальный цифровой отпечаток файла, который вычисляется на основе его содержимого по алгоритмам MD5, SHA‑1 или SHA‑256. На выходе алгоритм хеширования выдает строку фиксированной длины.
Пример хешей файла AnyDesk.exe:
MD5: 620002ffe2ae46e5b8efa2201264e5dc SHA-1: bf5c046ee614fced58aedd76ba996b0e8cef7180 SHA-256: 72564813f3275f6384df47aa9c3216aec170eae50776e9e155ba3253a6c4b430
АВПО вычисляет хеш проверяемого файла и сравнивает его с базой известных. В случае совпадения файл определяется как вредоносный.
Самое важное свойство криптографических хеш‑функций — чувствительность к минимальным изменениям. Достаточно изменить или добавить один байт (например, переименовать переменную, добавить пустую строку или изменить один символ в слове) — хеш изменится полностью и совпадения с базой не будет.
Хеш‑сигнатура подходит для точной идентификации известного вредоносного файла, но бесполезна против любой его модификации.
Байтовая сигнатура
Это уникальная последовательность байтов внутри вредоносного файла. Аналитик исследует образец ВПО, находит в нем короткую уникальную последовательность байтов, которая с высокой вероятностью не встречается в легитимных файлах.
Пример байтовой сигнатуры, которая не встречается в легитимных файлах: \xEB\x2A\xFF\x8B\xC0\xCC.
Байтовая сигнатура устойчива к простым модификациям в файле (добавление байта в конец файла, изменение комментариев в коде). Даже после таких изменений антивирус распознает зараженный файл по уникальному маркеру в коде. Если злоумышленнику неизвестно, какая именно байтовая последовательность используется в сигнатуре, она может сохраниться без изменений даже после модификации вредоносного кода.
Чтобы обойти байтовую сигнатуру, атакующий должен изменить именно тот фрагмент кода, который антивирус использует в качестве маркера. Для этого используется несколько техник:
- Шифрование тела вредоносного кода. В таком случае конкретных байтов сигнатуры в коде не будет.
- Сжатие или упаковка файла. Байтовая сигнатура исходного кода отсутствует в сжатом файле.
- Обфускация кода. Изменения в коде происходят так, чтобы сохранить функциональность, но изменить структуру. Инструкции заменяются эквивалентными, меняется порядок операций, добавляется мусорный код (бессмысленные циклы, шифрование строковых констант).
На практике антивирусное ПО использует хеш‑сигнатуру для быстрой проверки, а байтовую сигнатуру для более гибкого анализа.
Формирование базы вендора
База данных антивирусного поставщика формируется за счет сбора и анализа вредоносного ПО, а также распространения информации о нем. Это не статичный, единожды сформированный файл, а динамическая, постоянно обновляющаяся система. Фундамент базы данных — большое количество потенциально вредоносных файлов, которые вендор получает из нескольких источников:
- Информация от пользователя. Если антивирусное ПО обнаружит подозрительный файл, который не удается однозначно классифицировать, оно предложит пользователю отправить информацию на анализ вендору.
- Honeypot‑системы. Вендоры разворачивают уязвимые машины в сети в качестве приманки для атакующих. Любой файл, который был загружен на сервер‑приманку, автоматически отправляется на анализ.
- Обмен данными между вендорами. Поставщики АВПО обмениваются на специализированных платформах индикаторами компрометации (например, VirusTotal, MISP, OpenTIP). Образец, загруженный на такую платформу, становится доступен всем участникам обмена.
Полученный вредоносный файл или подозрительный образец вендор отправляет в автоматизированный многоступенчатый конвейер анализа. Подробнее о методах анализа ВПО поговорим в следующей статье.
Обновление базы данных на конечном устройстве
Сигнатура загружается в облачную систему поставщика (которая проверяет файлы по актуальным базам в режиме реального времени), чтобы защитить пользователей до выхода обновления баз. После выхода обновленная база данных распространяется на конечные устройства в несколько этапов:
- Распространение обновлений с сервера поставщика. Публикация обновленной базы на серверах вендора. Файлы содержат только инкрементальные изменения (новые или измененные сигнатуры, удаленные устаревшие записи) и занимают несколько мегабайт. Это позволяет быстро загрузить их без лишнего расхода трафика.
- Проверка обновления на устройстве. Агент АВПО проверяет наличие обновлений по расписанию несколько раз в день или поддерживает фоновое соединение с сервером управления.
- Загрузка и проверка целостности. АВПО загружает обновления по защищенному каналу, затем проверяет целостность: сверяет электронную подпись поставщика и контрольную сумму скачанного файла, чтобы исключить подмену.
- Применение обновления на устройстве. Драйвер АВПО подгружает обновленную базу в память и начинает использовать новые сигнатуры при следующей проверке.
- Обработка ошибок. Если во время обновления произошел сбой, антивирус оставит текущую базу без изменений и повторит попытку позже.
Проверка по сигнатурам остается фундаментальным методом обнаружения известных угроз. Но его эффективность напрямую зависит от двух факторов: качества сигнатур и актуальности базы на конечном устройстве. Если сигнатурный анализ не сработал, это не значит, что файл безопасный. Если он вызывает подозрение по другим признакам, необходимо провести дополнительный анализ.
Механизм работы АВПО: путь от перехвата до вердикта
Когда АВПО перехватывает файл или процесс, внутри системы запускается многоступенчатая цепочка анализа. Понимание этой последовательности критически важно для аналитика: оно позволяет правильно интерпретировать вердикты антивируса и верно расставлять приоритеты при реагировании на инциденты.
Порядок работы модулей антивирусного ПО
АВПО не запускает все механизмы одновременно, так как это потребляло бы слишком много ресурсов. Модули активируются последовательно: от самого быстрого к самому глубокому анализу. Такой подход позволяет сохранять баланс между скоростью работы и глубиной обнаружения угроз.
Рассмотрим подробнее, какую роль играет каждый модуль в обнаружении угроз:
- Сигнатурный модуль. Самый быстрый метод проверки, поскольку сводится к вычислению хеша файла и его сравнению с базой известных вредоносных образцов. Если обнаруживается совпадение, файл блокируется и анализ другими модулями не выполняется.
- Эвристический модуль. Анализирует структуру файла, его код, выявляя признаки, характерные для вредоносного ПО: подозрительные последовательности команд, обращения к API, механизмы автозагрузки, создание запланированных задач и другие аномалии. По результатам проверки выносится оценка с определенным уровнем уверенности
. Каждый подозрительный признак добавляет определенное значение к общей оценке. Сумма всех этих значений формирует вероятность того, что файл вредоносный. Если эта вероятность превышает уровень уверенности, файл классифицируется как вредоносный и получает вердикт с префиксом HEUR. Это сигнализирует не о точном сигнатурном совпадении, а о вероятностной оценке, вынесенной на основе эвристических признаков. - Поведенческий модуль и облачные технологии. Если после двух фильтров файлы все еще вызывают сомнения, подключаются наиболее ресурсозатратные механизмы. Они завершающее звено углубленного анализа файла, когда быстрые и менее ресурсоемкие не дали однозначный ответ.
Формирование вердикта
Вердикт — это комбинированная оценка файла всеми модулями, которые его проверяли. Логика решения выглядит таким образом:
- Высокая уверенность во вредоносности → немедленная блокировка. Означает, что сигнатурный метод или эвристический анализ показал результат с высоким процентом уверенности. Файл сразу блокируется без дополнительных проверок. Это наиболее однозначный сценарий из всех возможных: решение принимается автоматически и не требует вмешательства аналитика.
- Средняя уверенность → карантин. Если эвристический анализ показывает средний процент уверенности во вредоносности, файл не блокируется, но и не пропускается в рабочую среду. Его помещают в карантин — изолированную зону, где он не может навредить системе, но остается доступным для анализа. Специалист анализирует его в песочнице и решает, что делать дальше: удалить, восстановить или отправить на углубленное изучение поставщику АВПО.
- Низкая уверенность → лог без блокировки. Если файл вызывает слабые подозрения, которых недостаточно для блокировки или карантина, АВПО фиксирует событие в детализированном логе (с указанием времени, имени файла, источника, степени уверенности) и пропускает файл. Такие события важно не игнорировать. По отдельности они могут выглядеть не подозрительными, но в совокупности способны указать на широкую картину атаки.
- Нет подозрений → пропуск. Файл прошел все этапы проверки без срабатывания модулей, признан безопасным, поэтому событие в логах не генерируется. Экономия на логировании позволяет не перегружать систему отчетами о заведомо легитимной активности и сосредоточить внимание на подозрительных объектах.
Вердикт проверяемого файла — это не просто бинарное решение (вредоносен/безопасен), а гибкий, зависимый от контекста результат слаженной работы всех модулей антивируса. Каждый из них вносит вклад в общую оценку, а финальное действие зависит от настроенных порогов уверенности. Для поддержки эффективности рекомендуется регулярно пересматривать эвристические правила и калибровать пороги срабатывания. Это позволяет найти баланс между надежностью защиты, производительностью системы и управляемостью количеством ложных срабатываний.
Причины различий в вердиктах разных вендоров
Разница в вердиктах антивирусных вендоров обусловлена не техническими просчетами или субъективным мнением разработчика, а отсутствием единого универсального стандарта обнаружения вредоносного ПО. Каждый вендор использует уникальную комбинацию сигнатурных баз, эвристических алгоритмов, порогов срабатывания и белых списков, что приводит к асинхронности детектирования. Следовательно, единичный негативный вердикт от одного вендора не является абсолютным доказательством вредоносности файла, как и отсутствие детектов не гарантирует безопасность.
Вот основные факторы, создающие разницу в вердиктах:
- Разные базы сигнатур. Каждая компания независимо наполняет свою базу. Например, при таргетированной атаке образец ВПО может быть отправлен на анализ только одному поставщику. Тогда лишь его продукт будет детектировать угрозу, тогда как остальные вендоры о ней не узнают вовсе.
- Разные эвристические алгоритмы. У каждого поставщика собственные алгоритмы эвристического анализа файла, поэтому компании по‑разному оценивают его подозрительное поведение. Один вендор считает определенную последовательность команд, выполненных файлом, потенциально опасной, другой — штатной работой.
- Разная скорость обновления баз. Между появлением нового ВПО и выходом сигнатуры проходит некоторое время. В первые часы после появления нового ВПО результат анализа файла на VirusTotal может быть неравномерным: несколько вендоров его уже детектируют, остальные еще нет.
- Разные пороги срабатывания. Более «агрессивные» поставщики АВПО блокируют файл при 50—60%‑й вероятности угрозы. Это дает высокую защиту и большое количество ложных срабатываний. Другие вендоры жертвуют скоростью реакции и считают файл вредоносным только при 85—90%‑й уверенности в этом, что уменьшает количество ложных срабатываний.
- Использование белых списков. Крупные поставщики АВПО ведут большие базы доверенных файлов. Например, если файл подписан валидным сертификатом от DigiCert, но выполняет подозрительные действия, то один антивирус доверится подписи, а другой — определит как угрозу.
Анализ выставленного вердикта
Рассмотрим на примере вердикта: HEUR:HackTool.Win32.KMSAuto.gen.
HEUR — говорит о том, вердикт вынесен эвристическим модулем обнаружения ВПО, а не сигнатурным. Значит, точной сигнатуры этого файла в базе нет. АВПО проанализировало поведение или структуру кода, нашло подозрительные признаки и сделало вывод о вредоносности.
HackTool — демонстрирует класс угрозы. Мы понимаем, что это не вирус или троян, а инструмент, который может использоваться как системными администраторами (например, для диагностики или восстановления лицензий), так и злоумышленниками (например, для обхода механизмов безопасности).
Win32 — указывает на архитектуру и среду выполнения. Файл предназначен для 32‑битной среды Windows.
KMSAuto — идентифицирует семейство анализирующего файла. В нашем случае это семейство инструментов активации незарегистрированного ПО продукции Microsoft.
.gen — суффикс, означающий generic, то есть обобщенный вердикт. Файл не совпал с известной версией KMS. Но по своей структуре и поведению он достаточно похож на семейство KMSAuto, чтобы получить соответствующую метку с помощью эвристического метода анализа.
Итоговое описание HEUR:HackTool.Win32.KMSAuto.gen: эвристический модуль обнаружил потенциальный инструмент для нелегитимной активации (HackTool) семейства KMSAuto, предназначенный для 32‑битной системы Windows. Вердикт вынесен по обобщенным признакам (generic) эвристическим методом анализа.
Обнаружив файл с таким вердиктом, аналитик не должен полагаться только на название угрозы. Необходимо проанализировать сам объект:
- Оценить контекст с точки зрения безопасности. Наличие файла на рабочей станции сотрудника нарушает политику лицензирования организации. Сам по себе KMSAuto не вредоносное ПО, но часто распространяется в связке с майнерами, бэкдорами и другими опасными компонентами.
- Выяснить происхождение файла. Путь к файлу дает важную информацию о поведении пользователя и возможном источнике угрозы. Например, расположение в папке
Downloadsуказывает на добровольное скачивание, а вTempилиAppData\Local\Temp— на возможное скрытое выполнение. - Проверить, запускался ли файл до того, как его удалил антивирус. Если запускался, необходимо выяснить, остались ли в системе (автозагрузке, планировщике задач, созданных и измененных файлах, исходящих сетевых соединениях) следы активности. Если запуска не было, нужно убедиться, что файл удален. В любом случае необходимо оповестить заказчика.
Информация в исходном логе события антивирусного ПО
Сырой лог АВПО — это необработанный массив событий, которые зафиксировало средство защиты. В нем записана вся информация по срабатыванию:
- время;
- категория угрозы;
- хеш файла;
- расположение файла;
- хост, где файл был обнаружен, и др.
Рассмотрим сырой лог АВПО Kaspersky на срабатывание активатора KMS:
Oct 28 08:48:01 192.192.192.192 ksc[-]: |type=ksc| |IntrusionTransport=None| |VirusName=HEUR:HackTool.Win32.KMSAuto.gen| |RawParameter8=62| |DetectionEngine=None| |VirusSha256=4140061E52A95ECD9E6C9F55E8A18F7FB1F0605FB26E1D8236EAF0DFDA04E866| |HostDNS=workstation-1| |IntrusionSourceIPv4=None| |ApplicationFileName=None| |EventId=GNRL_EV_OBJECT_DELETED| |HostName=workstation-1| |HostGroupName=Карантин| |EventRegistrationTimeUTC=2025-10-28T08:47:31.720Z| |IntrusionName=None| |VirusObject=D:\KMSAuto--RSLOAD.NET--2plus\KMSAuto++.exe| |VirusTypeId=62| |EventDescription=Описание результата: Удалено Тип: Приложение, которое может нанести вред Название: HEUR:HackTool.Win32.KMSAuto.gen Пользователь: workstation-1\userADM (Активный пользователь) Объект: D:\KMSAuto--RSLOAD.NET--2plus\KMSAuto++.exe SHA256: 4140061E52A95ECD9E6C9F55E8A18F7FB1F0605FB26E1D8236EAF0DFDA04E866 MD5: D02F15EB9D0C8CDB597D5B892A8ABA86| |@timestamp=2025-10-28T08:48:01.320117Z| |HostOSName=Microsoft Windows 10| |TaskType=None| |VirusAccount=workstation-1\userADM| |KSCVersion=13| |EventRiseTimeUTC=2025-10-28T08:16:29.167Z| |ViewVersion=19| |EventIdName=Объект удален| |HostIPv4=10.10.10.10| |DeviceName=None| |ApplicationMd5=None| |RawParameter3=None| |ApplicationPath=None| |RawParameter2=D:\KMSAuto--RSLOAD.NET--2plus\KMSAuto++.exe| |RawParameter9={"engine":10,"method":0,"blacklist":false,"cloud_sb":false,"md5":"D02F15EB9D0C8CDB597D5B892A8ABA86"}| |ApplicationAccount=None| |RawParameter4=None| |IntrusionTargetPort=None| |nId=515545349| |HostOSVersion=2009| |EventSourceName=Поиск вредоносного ПО| |RawParameter6=None| |RawParameter1=4140061E52A95ECD9E6C9F55E8A18F7FB1F0605FB26E1D8236EAF0DFDA04E866| |@version=1| |IntrusionTargetIPv4=None| |host=192.192.192.192| |RawParameter7=workstation-1\userADM| |RawParameter5=HEUR:HackTool.Win32.KMSAuto.gen| |VirusFoundTimeUTC=None| |EventSeverity=2| |TIME=0.0001964569091796875| |EOS|
Чтобы определить, является ли файл вредоносным, аналитику достаточно ограниченного набора данных (см. таблицу ниже). Полные журналы событий содержат большое количество служебной информации, которая не используется при анализе. На практике специалисты SOC работают не со всем событием целиком, а с его структурированными полями: именем файла, хешем, расположением, действием АВПО и его вердиктом.
Каждое из этих полей имеет практическое значение. Например, хеш позволяет проверить вредоносность файла по внешним источникам, путь помогает оценить типичность его расположения в системе, а вердикт и действие средства защиты — дать первичную оценку риска.
Эти поля позволяют идентифицировать и классифицировать объект. На их основе аналитик формирует индикаторы компрометации (IoC), которые затем используются для мониторинга, анализа и реагирования на инциденты. Таким образом, исходный лог преобразуется в готовые к использованию данные, которые ускоряют анализ и снижают количество ложных срабатываний.
В таблице ниже собрали информацию, на которую следует обратить внимание при ручном парсинге срабатываний АВПО на вредоносный файл.
| Данные из события | Описание | Данные из события |
|---|---|---|
|type=ksc| |
Источник события |
|
|VirusName=HEUR:HackTool.Win32.KMSAuto.gen| |
Вердикт АВПО |
HEUR говорит о том, что это срабатывание обнаружено эвристическим методом |
|
Вердикт АВПО |
Класс |
|
|
Вердикт АВПО |
|
|
|
Вердикт АВПО |
|
|
|
|
||
|VirusSha256=4140061E52A95ECD9E6C9F55E8A18F7FB1F0605FB26E1D8236EAF0DFDA04E866| |
Хеш SHA‑256 обнаруженного файла |
|
|EventId=GNRL_EV_OBJECT_DELETED| |
ID обнаружения |
Объект удален |
|HostName= workstation-1| |
Хост, на котором обнаружен объект |
|
|VirusObject=D:\KMSAuto--RSLOAD.NET--2plus\KMSAuto++.exe| |
Расположение объекта |
Путь: |
|EventRiseTimeUTC=2025-10-28T08:16:29.167Z| |
Начало активности. Время, когда событие зафиксировано на источнике |
28 октября 2025 года, 08:16:29 UTC |
|EventDescription=Описание результата: Удалено Тип: Приложение, которое может нанести вред Название: HEUR:HackTool.Win32.KMSAuto.gen Пользователь: workstation-1\userADM (Активный пользователь) Объект: D:\KMSAuto--RSLOAD.NET--2plus\KMSAuto++.exe SHA256: 4140061E52A95ECD9E6C9F55E8A18F7FB1F0605FB26E1D8236EAF0DFDA04E866 MD5: D02F15EB9D0C8CDB597D5B892A8ABA86| |
Описание сгенерированного события |
Описание результата: удалено |
|
Описание сгенерированного события |
Тип: приложение, которое может нанести вред |
|
|
Описание сгенерированного события |
Название угрозы: |
|
|
Описание сгенерированного события |
Пользователь: |
|
|
Описание сгенерированного события |
Расположение объекта: |
|
|
Описание сгенерированного события |
|
|
|
Описание сгенерированного события |
|
|
|@timestamp=2025-10-28T08:48:01.320117Z| |
Время срабатывания корреляционного правила |
28 октября 2025 года, 08:48:01 UTC |
|HostOSName=Microsoft Windows 10| |
Операционная система, установленная на хосте |
Microsoft Windows 10 |
|VirusAccount=workstation-1\userADM| |
Активный пользователь на хосте |
|
|EventIdName=Объект удален| |
Действие АВПО над объектом |
Объект удален |
|HostIPv4=10.10.10.10| |
IP-адрес хоста, на котором обнаружен объект |
|
|HostOSVersion=2009| |
Версия операционной системы, установленной на хосте |
2009 |
|EventSourceName=Поиск вредоносного ПО| |
Задача, в рамках которой было выполнено сканирование |
Поиск вредоносного ПО |
После маппинга сырого события с АВПО выпишем поля, которые важны при анализе и классификации ВПО:
- вердикт АВПО;
- хеш SHA‑256 обнаруженного файла;
- расположение объекта;
- действие АВПО над ним;
- задача, в рамках которой происходило сканирование.
В следующей части статьи проанализируем ВПО на основе этих полей.
Для аналитика SOC умение читать исходный лог события АВПО напрямую влияет на скорость и качество расследования. В интерфейсе SIEM‑системы или консоли антивируса часто отображается только краткая информация, например «обнаружено ВПО». Однако сырое событие содержит критически важные детали: название угрозы, путь к файлу, MD5‑хеш, действие средства защиты, процесс‑инициатор и сведения о пользователе. Понимание структуры таких событий помогает аналитику отличить поверхностное уведомление от оперативно значимой детали, правильно выбрать приоритет и направление расследования.
Немного практики
Для анализа IoC используют общедоступные инструменты такие, как VirusTotal, ThreatFox IoC Database, MalwareBazaar Database. Они позволяют искать по следующим параметрам:
- хеш‑сумме (как SHA‑256, так и MD5);
- URL;
- IP‑адресу;
- домену.
Для разбора примера мы используем платформу VirusTotal, так как это наиболее востребованный сервис для проверки подозрительных объектов. Ресурс использует множество антивирусных движков, сканеров и сервисов репутации, чтобы определить принадлежность объекта к ВПО. По результатам сканирования VirusTotal выводит список вендоров и вердиктов, которые посчитали, что объект является вредоносным.
Перед началом анализа необходимо повторно просканировать объект, чтобы исключить устаревшие данные вендоров, так как базы данных антивирусных движков постоянно обновляются.
Результат сканирования в онлайн‑сервисе VirusTotal отображается на следующих вкладках:
| Вкладка | Содержимое |
|---|---|
| Detection |
Информация после сканирования. Например, количество вендоров АВПО, которые классифицировали файл как вредоносный, вердикт, выставленный различными вендорами, определение семейства и категории, к которому относится ВПО |
| Details |
Дополнительная информация о сканируемом объекте. Например, при анализе хеша файла выводится информация об основных свойствах файла (различные алгоритмы расчета хеша, тип и размер файла), информация о подписи файла «Метаданные VirusTotal»: дата и время первой и последней отправки, время создания, последний анализ, наименования загруженных файлов |
| Relations |
Сведения о доменах, IP-адресах, с которыми файл взаимодействовал, а также о связанных файлах и файлах, которые были удалены во время анализа исходного объекта |
| Behavior |
Данные о динамическом анализе проверяемого файла в песочницах (например, CAPE Sandbox, Zenbox). Также отображает:
Кроме того, в этой вкладке содержится список использовавшихся тактик, техник и процедур по MITRE ATT&CK. Для обогащения IoC рекомендуется обращать внимание на разделы Network Communication (DNS Resolutions, IP Traffic, Memory Pattern Domains, Memory Pattern Urls), Processes created |
| Community |
Комментарии, которые оставляют участники VirusTotal о различных IoC. Изредка — ссылки на публичные песочницы |
Если возникают сомнения в достоверности вердикта VirusTotal (например, если 1–2 вендора АВПО признали объект вредоносным, а остальные — чистым), используйте таблицу для оценки достоверности.
| Объект | Достоверность признаков | Признаки |
|---|---|---|
| Хеш файла |
Высокая |
|
| Хеш файла |
Средняя |
|
| Хеш файла |
Низкая |
|
Пример 1
Во время поиска вредоносного ПО антивирус обнаружил на хосте workstation‑2 потенциально вредоносный объект со следующим хешем SHA‑256: ad9e4ddce68a34f0ba3010e66286bc3aa056043c7dca7a22c3222a279614025a
Антивирус вынес вердикт — HEUR:Trojan.Multi.NanoDump.gen.
Посмотреть, как выглядит результат анализа, можно на платформе VirusTotal или на скринах ниже:
Внесем информацию с каждой вкладки в таблицу:
| Параметр | Вкладка VirusTotal | Значение |
|---|---|---|
| Количество вендоров, которые посчитали файл вредоносным |
Detection |
55 из 71 |
| Хеш SHA‑256 обнаруженного файла |
Detection, Details |
|
| Хеш MD5 обнаруженного файла |
Details |
|
| Вердикт вендоров АВПО |
Detection |
|
| Тип файла |
Details |
Win32 EXE |
| Размер файла |
Details |
126.50 KB (129536 байт) |
| Время создания файла |
Details |
2024-09-17 22:55:33 UTC |
| Наименования загруженных файлов |
Details |
|
| Подпись файла |
Details |
Отсутствует |
| Взаимодействие файла с доменами |
Relations |
|
| Взаимодействие файла с IP‑адресами |
Relations |
|
| Файлы, которые создает файл при выполнении в изолированной среде |
Relations |
|
| Результат анализа песочниц |
Behavior |
Песочница Yomi Hunter детектировала файл как вредоносный |
| Открытие файлов в системе |
Behavior |
|
| Взаимодействие с ключами реестра |
Behavior |
|
| Созданные процессы |
Behavior |
|
| Ссылка на отчеты публичных песочниц |
Community |
Описание вердикта HEUR:Trojan.Multi.NanoDump.gen:
HEUR— результат эвристического анализа. Означает, что антивирусное ПО проанализировало поведение или структуру кода, нашло совокупность подозрительных признаков, сделало вывод о вредоносности объекта.Trojan— принадлежность к вредоносной программе, которая может несанкционированно уничтожать, блокировать, модифицировать или копировать информацию, нарушая работу компьютеров или компьютерных сетей.Multi— способность ПО работать более чем на одной аппаратной платформе или ОС.NanoDump— использование утилиты NanoDump.gen— обобщенный вердикт. Файл не совпал с конкретной известной версией, но по своей структуре и поведению похож на утилиту NanoDump.
Утилита NanoDump — специализированный инструмент в области кибербезопасности, который используется для снятия дампа памяти процесса LSASS и последующего извлечения хранящихся в ней секретов пользователей. Утилита позволяет злоумышленнику получить доступ к другим учетным данным пользователей для дальнейшего горизонтального или вертикального перемещения в домене AD.
Результат: файл классифицируется как вредоносный. Аналитику SOC необходимо уведомить заказчика об активности утилиты NanoDump на хосте workstation‑2.
Пример 2
Хостовый антивирус с помощью модуля поведенческого анализа обнаружил на хосте workstation‑3 потенциально вредоносный объект со следующим хешем SHA‑256: b45981580702029cfeeffc8ca69e2a4d1e9c68914009e94c31ffec9cbc544aa5
Антивирус вынес вердикт — PDM:Trojan.Win32.Generic. Действие: объект удален.
Посмотреть, как выглядит результат анализа, можно на платформе VirusTotal или на скриншотах ниже:
Внесем информацию с каждой вкладки в таблицу:
| Параметр | Вкладка VirusTotal | Значение |
|---|---|---|
| Количество вендоров, которые посчитали файл вредоносным |
Detection |
0 из 71 |
| Хеш SHA‑256 обнаруженного файла |
Detection, Details |
|
| Хеш MD5 обнаруженного файла |
Details |
|
| Вердикт вендоров АВПО |
Detection |
|
| Тип файла |
Details |
Win32 EXE |
| Размер файла |
Details |
145.98 KB (149479 байт) |
| Время создания файла |
Details |
2022-11-15 17:18:52 UTC |
| Наименования загруженных файлов |
Details |
|
| Подпись файла |
Details |
Отсутствует |
| Взаимодействие файла с доменами |
Relations |
|
| Взаимодействие файла с IP‑адресами |
Relations |
|
| Файлы, которые создает файл при выполнении в изолированной среде |
Relations |
|
| Результат анализа песочниц |
Behavior |
Все песочницы не классифицировали файл как вредоносный |
| Открытие файлов в системе |
Behavior |
|
| Взаимодействие с ключами реестра |
Behavior |
|
| Созданные процессы |
Behavior |
|
| Ссылка на отчеты публичных песочниц |
Community |
Отсутствуют |
Описание вердикта PDM:Trojan.Win32.Generic:
PDM— вердикт модуля, который обнаружил необычную активность процесса в момент его выполнения.Trojan— принадлежность к вредоносной программе, которая может несанкционированно уничтожать, блокировать, модифицировать или копировать информацию, нарушая работу компьютеров или компьютерных сетей.Win32— указание на архитектуру и среду выполнения. Файл предназначен для 32‑битной среды Windows.Generic— обобщенный вердикт, который указывает на признаки вредоносной активности, характерные для целого класса угроз, но не позволяет однозначно отнести объект к конкретной известной угрозе.
Ls.exe — портированная версия Unix‑команды ls для Windows. Команда используется для просмотра списка файлов и папок в командной строке.
По результату анализа файл классифицируется как не вредоносный, но антивирус выявил необычную работу этого процесса и завершил его выполнение. Разберемся, почему сработало АВПО. Для этого проанализируем окрестность, где было замечено чтение файлов от процесса ls.exe.
Зафиксированы обращения к файлам:
c:\users\appdata\local\microsoft\credentials\dfbe70a7e5c:\users\appdata\local\microsoft\edge\user data\local statec:\users\appdata\local\microsoft\edge\user data\default\bookmarksc:\users\appdata\local\microsoft\edge\user data\default\historyc:\users\appdata\local\microsoft\edge\user data\default\login data
Антивирус посчитал чтение критических файлов от процесса ls.exe подозрительным, остановил и завершил процесс.
В этом случае аналитику необходимо уведомить заказчика о срабатывании АВПО. Например, так: «На хосте workstation‑3 зафиксирована аномальная активность процесса ls.exe, который читал конфиденциальную информацию (учетные данные Windows и браузера Edge). Сам файл не вредоносный, но его поведение указывает на возможную компрометацию хоста».
Несмотря на появление новых технологий, антивирусное ПО остается базовым средством защиты большинства конечных устройств, а его события — одним из основных источников данных для SOC. Поэтому прежде чем переходить к более сложным методам защиты, важно понимать, как работает антивирус и какие механизмы лежат в основе его решений.
Зная, как антивирус обнаруживает файлы и процессы, аналитик может понять, почему угроза была пропущена и где искать следы дальнейшей активности. Понимая разницу между сигнатурным и эвристическим вердиктом, специалист корректно оценивает достоверность срабатывания и не зацикливается на ложноположительных. Разбираясь в том, как устроена база сигнатур и почему вердикты у разных вендоров отличаются, аналитик не будет воспринимать отсутствие детекта как подтверждение безопасности файла. Такие компетенции отличают специалиста, который умеет работать с событиями АВПО, от того, кто только читает название угрозы.
Практическая ценность анализа событий антивирусного ПО выражается в конкретных показателях: сокращении времени на обнаружение инцидентов, более точной приоритизации событий, уменьшении количества ложных срабатываний и, как следствие, повышении эффективности работы всего центра мониторинга.
В следующей статье цикла — «Основы анализа вредоносного ПО: статический и динамический подход» — разберем, как самостоятельно исследовать подозрительный файл в случаях, когда антивирус обнаружил угрозу или, наоборот, не зафиксировал ее. Также рассмотрим основные этапы статического и динамического анализа, их преимущества и ограничения.