Sunday, December 12, 2021

SOC на удаленке

Удаленка - отличный способ оценки зрелости ваших процессов!

В период пандемии многие предприятия были вынуждены уйти на удаленную работу. Поставщики услуг мониторинга - не исключение, при этом их не остановил запрет лицензии ФСТЭК на ТЗКИ, что в очередной раз подтвердило адекватность требований реальности, и, что самое печальное, важность их исполнения. Но в этой заметке мы не будем разводить демагогию о реальных целях лицензирования, а поговорим о влиянии удаленной работы на эффективность и результативность зрелого SOC. Кому лень читать до конца, скажу сразу: влияния - нет.

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

Припомним уровни зрелости, - с уровня 2 мы имеем требование повторимости, а с уровня 3 уже говорим о стандартизуемости. Повторимость, тем более, стандартность означает, что процесс документирован и доведен до исполнителей, а они его уже далее самостоятельно исполняют и получают предсказуемый результат. Если исполнители плохо исполняют свою роль в процессе, это значит, что либо процесс плохо описан - это фиксируется качеством документации и Базы знаний, либо исполнители не наработали достаточную практику - это исправляется онбордингом и менторством. Для обеспечения качества Базы знаний необходим процесс Управления знаниями (Knowledge management), крайне важный для SOC - это и данные о собираемой телеметрии, типовых сценариях отработки инцидентов (по-хорошему это должна делать правильная IRP), данные об инфраструктуре заказчиков (при этом база прошлых инцидентов\обращений - также отличный источник, но, ввиду того, что по требованиям по защите PII эти данные нельзя хранить долго, какие-то моменты придется вытаскивать в Базу знаний обезличенными), литература для ознакомления и многое другое. Заметка не про Управление знаниями и не про Базу знаний, поэтому напоследок лишь замечу, что для нее очень важна грамотная маркировка (теги, лейблы, summary, оглавление, и т.п., что упрощает навигацию и поиск).

Онбординг и менторство также заслуживают отдельной заметки, но пару слов здесь тоже оставим. Чтобы онбординг работал хорошо, он должен быть формально описан в виде алгоритма или перечня пунктов: что надо прочитать, какие видео посмотреть, с чем надо разобраться (может, поделать какие-либо упражнения). Здесь помогут описания и разборы прошлых обезличенных инцидентов, лабораторки,  практика - лучший способ обучения. Ментор - это назначенный опытный коллега, к которому можно обратиться по любому вопросу, при этом задача ментора - отрабатывать эти эскалации (обращения от newcomer-а)  в приоритетном порядке. На первых порах - этот ментор в прямом смысле стоит за спиной, в условиях удаленной работы это сделать несложно, так как все современные системы удаленного взаимодействия позволяют показывать экран.

Итак, в зрелом SOC все процессы ясно и понятно описаны, они повторимы на практике, и с ними легко ознакомиться самостоятельно. Есть формальный процесс онбординга, который также можно пройти самостоятельно, и он позволяет максимально быстро и эффективно войти в курс дела. Кроме этого, есть выделенный ментор, который ответит на все вопросы, проконтролирует, что newcomer на практике работает с достаточным качеством.

Уровень 4 модели зрелости требует измеримости. Метрики - неотъемлемая часть любого SOC, - это самый очевидный способ ответить на простые вопросы: насколько эффективно работают аналитики, как часто они ошибаются, какова трудоемкость в зависимости от объемов (уровня SLA, характера и количества систем в мониторинге), какова пропускная способность команды и как необходимо масштабироваться с приходом новых объемов, как изменяется пропускная способность со временем ввиду автоматизации, какова эффективность и результативность детектирующей логики, какова трудоемкость обработки инцидентов в зависимости от уровня критичности и типа атаки, и многое-многое другое. Метрики позволяют постоянно контролировать уровень сервиса и объективно показывать проблемные места.

Анализ метрик - важная задача не только для констатации прошлого и оценки настоящего, но и для угадывания будущего. Анализ метрик для целей будущего и подводит нас к 5-ому уровню модели зрелости, заключающемуся в непрерывном совершенствовании. Именно метрики подсветят проблемные места: в какое время дня\недели\года особенно напряг и с чем это коррелирует, на каких алертах и какие аналитики чаще ошибаются, на каких этапах разбора инцидентов наиболее вероятны ошибки, как изменяется трудоемкость обработки алертов с приходом новых объемов (economy of scale) и т.п. Анализ проблем - источник мероприятий по совершенствованию, и это - непрерывный процесс.

Все перечисленные выше процессы, характеризующие работу зрелого SOC никак не зависят от работы в офисе или удаленно. Понятие еще более размывается в случае распределенных команд, как, например, наша. Для меня, работающего из России, безразличен режим работы моих коллег из Америки: работают ли они из офиса, или из дома, - в любом случае они для меня удаленные сотрудники, наблюдать их "вживую" я не могу, но метрики и статистика их работы позволяют объективно видеть их результаты. Важно оценивать работу именно по результату, удаленка не отнимает эту возможность, и поэтому не влияет на эффективность работы или управления. Скорее даже верно обратное: если наблюдаются сложности с оценкой по результату, то проблема не в режиме работы, а в процессах, и негативное влияние удаленки здесь может быть хорошим индикатором.

Тем не менее, коммуникация - основная проблема удаленной работы. Более 70% процентов информации передается невербальными методами. Здесь, безусловно, есть потеря в передаче некоторой ментальной информации, типа, озабоченности, взволнованности, душевного состояния, а с учетом тяжелой работы аналитиков SOC и потенциальным выгоранием - это крайне важно. Но и здесь можно придумать контроль - увеличение отдельных совещаний 1-на-1 с менеджером, при включенной камере (вообще, включение камеры при синхронных коммуникациях - правило хорошего тона), где можно обсудить не только производственные вопросы, а вообще, все, что угодно, именно в рамках синхронной коммуникации. Подавляющее большинство других коммуникаций можно делать асинхронно. Асинхронная коммуникация - важный фактор эффективной удаленной работы, - это когда мы пишем сообщение и не ожидаем ответ сию же секунду, общение не производится интерактивно. Когда команда распределена географически, асинхронная коммуникация - единственно возможный способ, так как наше рабочее время попадает на период отдыха наших американских и дальневосточных коллег.  Очевидным плюсом асинхронной коммуникации является ее документированность, и, следовательно, возможность ее хранения, последующего анализа и переиспользования, например, для целей обучения. В зрелом SOC документированность коммуникаций внутренних, тем более, внешних - принципиальное требование, так как это - единственный способ сохранения контекста при пересменках аналитиков, а также, для внутренних расследований в случае эскалаций (кто что кому когда написал\посоветовал, какие действия кем были предприняты и т.п.). Именно поэтому для зрелого SOC привычна и естественна асинхронная коммуникация, и это не создает отрицательного эффекта на работу SOC.

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


Tuesday, December 1, 2020

SOC Forum 2020 Live: Роботы среди нас!

Вкалывают роботы, 

А не человек!

"До чего дошёл прогресс" Крылатов. Энтин


Сегодня на SOC forum рассказывал о машинном обучении для целей триажа алертов.

Выкладываю презентацию.

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


FP против FN

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

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

Да, это позволит нам снизить Ошибочные пропуски (False negative, FN), но увеличит количество Ложных срабатываний (False Positive, FP), которые, несомненно отразятся на нашей операционной эффективности – нам нужно много людей на первой линии, которые будут заниматься триажем алертов…. 


Типовое применение МашОбуча

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

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


Другое применение МашОбуча

Прекрасно осознавая, как выглядят современные атаки, и понимая, что платой за возможность их обнаружить будет огромное количество алертов для анализа на линии SOC (так как мы хотим их обнаруживать, не хотим качеством обнаружения сервиса оплачивать наши же ресурсные проблемы!), мы задумались как разгрузить аналитиков с помощь того же Машобуча. Как решить проблему эффективного триажа? Как из образовавшегося потока алертов отфильтровать те, что являются ложными срабатываниями, и тем самым подойти к проблеме обнаружения не стороны перечисления зла, а со стороны фильтрации легитимной активности.

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


Этапы пайплайна MDR

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

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

Далее, работают по кейсу в IRP (идут в События, смотрят что было до, что было после, подшивают релевантные события, строят Timeline инцидента). Если после расследования понятно, что это не фолса, пишут описание для Заказчика и публикуют в Портал.


Мечты..., превращенные в цели

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


Этапы пайплайна MDR + ML

Модель встраивается в пайплайн таким образом. Будучи автоматом, Автоаналитк является частью пайплайна автообработки.

Прежняя детектирующая логика решает проблему пропусков (FN), а Автоаналитик быстрого триажа (фильтрации FP).


Входные данные 

На слайде представлен пример реального алерта. Это массив JSON-объектов Событий, каждый объект имеет набор признаков со значениями. В качестве значений может быть что угодно: строка, число, дата, список.


Текущая агрегация

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


FPR и TPR

У каждого классифицируемого нами алерта есть истинные классы True и False, и есть классы, предсказанные Моделью, тоже True и False. В таблице приведены все пересечения истинной и предсказанной Моделью разметки.

FPR показывает какой % из истинно ложных алертов Модель классифицировала как True инциденты. Идеальная ситуация, чтобы ложных срабатываний не было и FPR=0%.

TPR показывает какой % реальных инцидентов был распознан корректно. Идеальная ситуация, когда TPR = 100%.


ROC-кривая

Рассмотрим как меняются предсказания Модели в зависимости от Порога. На схеме "горбиками" показаны распределения истинных классов True и False, а жирный красный пунктир – наш порог принятия решения Моделью: все что справа от порога модель предсказывает как True, все что слева – False. На горбиках в зависимости от порога я отобразил уже знакомые нам множества ошибок - FP, FN и верных предсказаний - TP, TN. Горизонтально перемещая порог влево и вправо, мы можем получать разные метрики TPR и FPR. 

Положения нашего Порога и получившиеся TPR и FPR удобно смотреть на ROC-кривой. ROC-кривая также характеризует качество модели – чем больше площадь под ней, тем модель работает лучше.


Схема потока алертов

Мы считаем, что все, что можно алгоритмизировать, должно быть автоматизировано! Поэтому у нас нет понятия "Первой линии SOC, отрабатывающей плейбук".

Весь поток алертов летит в Автоаналитика и чуть более трети он классифицирует как ложное срабатывание, а то, что превышает Порог и заданную Долю фильтрации – отправляет уже на разбор Человеку. 

Маленькие ручейки в виде 3% и 5% - это потоки перепроверки, необходимых для постоянного контроля качества аналитиков.


Послесловие

Этот слайд очень важен, но все что нужно я на нем написал текстом, поэтому пояснений, думаю, не требуется.


Важной ссылкой о теме является доклад Даниила Удимова по этой же теме на профильной конференции.


Благодарности

Автоаналитик был придуман в 2017, а с 2018 уже использовался в сервисе. С тех пор он значительно изменился, и процесс его совершенствования не стоит на месте. Он - продукт труда целой команды выдающихся экспертов, которым спешу выразить безмерную благодарность, и надежду на долгое плодотворное сотрудничество как в данной, так и во многих других областях применения машинного обучения в нашем нелегком Security Operations. Ребята, спасибо Вам!












Saturday, October 10, 2020

Elastic Endpoint + SIEM - простая инфраструктура для Threat Hunting-а

В статье расскажу как быстро развернуть инфраструктуру для Threat hunting-а, бесплатно.
А здесь уже рассказано, как этим можно пользоваться.



2. Обязательно Security и SSL (уже в бесплатной версии): 

3. Обязательно Security и SSL в Kibana (раз, два)

4. Сертификаты для SSL Elastic и Kibana – использовал OpenSSL. Лучше не самоподписанный.
4.1. Делаем УЦ на OpenSSL (статей полно в Интернет, например, эта)
4.2. От этого УЦ создаем сертификты для  kibana и elastic (использовал один сертификат для обоих). Важно: Сертификат должен содержать SAN, содержащие IP
Для SAN нужен конфиг запроса, мой пример (важное выделил):
[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn
[ dn ]
C=RU
L=Moscow
O=Kaspersky Test
OU=SOC Test
CN=kibana
[ req_ext ]
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = kibana
DNS.2 = elastic
IP.1 = 192.168.56.1
IP.2 = 192.168.220.1
Создаем запрос с созданным конфигом: openssl req -new -key kibana.key -out kibana.req -config req.conf 
Создаем сертификат подписанный ключом УЦ, с тем же конфигом: openssl x509 -req -in kibana.req -CA rootCA.crt -CAkey rootCA.key -CAcreateserial -out kibana.crt -days 5000 -extensions 'req_ext' -extfile req.conf
Полезные коммандочки:
    • Посмотреть запрос: openssl req -text -noout -verify -in kibana.req
    • Аналогично, посмотреть сертификат: openssl x509 -in kibana.crt -text -noout
5. Чтобы данные лились, в конфиге elasticsearch обязательно должен быть включен ingest node (node.ingest: true):


7. Агент – Windows, поэтому создал политику для него (“Windows”), "Default config" была.
8. Подправим URL-ы в конфигурации Ingest manager-а (IP-адреса, и https)


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

9. Для энроллмента агента надо создать Enrollment token

10. Энтроллим агента, удобнее использовать Fleet

Агента надо просто скачать, положить в новую папку и в ней выполнить команды, которые написаны в интерфейсе Kibana при энроллменте

Если выскакивает ошибка, надо потрастить использованный rootCA, помогает.

У агента есть несложное CLI, полный перечень команд здесь.

После энроллмента агент появляется во Fleet


В операционной системе появится два сервиса: агент и Endpoint Security

11. Можно посмотреть логи агента:

12. Детали конфигурации

13. Агенту можно назначить другу политику ли отключить от управления
14. В моем случае «Windows» - название политики для агента, посмотрим внутрь
Elastic Endpoint Security – политика EDR
System-1 – политика сервера, как обычной системы (метрики железа, дефолтные логи)

15. Посмотрим политику EDR

16. Также Elastic поставляет бесплатно «ханты», их можно включать и отключать

17. Можно и свои создавать

По хантам поставляется простенькая, но неплохая документация, некоторые сопоставлены с MITRE ATT&CK, ссылки ведут на сайт MITRE.

18. Данные от сенсоров можно обрабатывать перед индексированием
Конфигурирование можно выполняться из интерфейса Kibana, удобно.


19. Может потребоваться отредактировать продвинутые настройки

20. Конфигурация алертинга и EDR

21. Чтобы в Kibana увидеть данные сенсоров, надо завести новую роль (я дал полные права, но в реальной жизни надо следовать принципу минимума привилегий):


И своего пользователя включить в эту роль. Пользователь Elastic не имеет прав на данные, хоть и суперадмин
22. Для сбора Windows-логов поставил Winlogbeat

23. Установленного агента просто отключить (unenroll)
После Unenrollment-а пропадает сервис Elastic Endpoint


24. Когда события польются на Dashboard будет наглядно видно какой телеметрии сколько








Тестируем Elastic Endpoint Agent с Elasitc SIEM

Стандартом де-факто для самодельного MDR долгое время был sysmon и даже MITRE публикует детекты для него. Есть куча в прошлом SOC-ов, продвинувшихся в сторону MDR, как раз добавив события от sysmon. 

Но, с появлением EPP от Elastic ситуация может поменяться! Сегодня рассмотрим его поподробнее, используемая инсталляция описана здесь.

Для экспериментов я подготовил несложную Windows10-машинку, навеянную одним из последних своих упражнений на HTB, со следующим сценарием:

  • Первоначальный пробив - уязвимое Web-приложение
  • Повышение - ошибка в конфигурации сервисов Windows (специально подстроенная, в Windows по умолчанию все ОК)

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

Глазами Красного

1. Посканировали, нашли Web, зашли, увидели это


2. Несложное исследование помогло понять что это за приложение.

3. Под это приложение есть готовый эксплоит, 
копируем его локально

4. В самом последнем Kali не поддерживается perl2, поэтому надо творчески поправить, но, в целом, шелл забрасывается и работает

5. Будем делать шелл с помощью nc, он есть в Kali, скопируем его локально и поднимем Web-сервер

6. Скопируем на подломанную машинку nc с помощью certutil и проверим, что все получилось

7. Получим реверсивный шелл на подломанную машинку

8. Загрузим accesschk 


9. Посмотрим есть ли сервисы с уязвимой конфигурацией и найдем его


10. Заменим бинарник сервиса на nc


11. Поменяем учетную запись запуска сервиса на system (нам надо повыситься до system-а)


12. Перезапустим сервис и получим шелл от system


На этом Красный достиг своей цели, перейдем к работе Синего.


Глазами Синего. Web-shell

1. Непосредственно из первого же дашборада SIEM видно события по категориям


2. Предположим, что что-то у нас нехорошо на Endpoint

View hosts приведет на соответствующую вкладку

3. На вкладке можно анализировать события


4. Но лучше начать с алертов. Elastic считает nc чуть ли не ВПО, вероятно, в этом есть смысл. Из алерта сразу видно, что nc  подозрительно запускается из директории htdocs


5. Тут же, нажатием на кружок, можно посмотреть цепочку запуска, она достаточно длинная и очень подозрительная: httpd -> cmd -> nc -> cmd -> whoami




6. Тут же из графа можно увидеть, что nc имеет одно сетевое событие - TCP-соединение на 192.168.56.105:9001, вероятно, это и есть атакующий

7. Добавляем nc в Timeline и это покажет связанные события (фактически, можно относиться к timeline как к быстрому фильтру, который с тем же успехом можно было бы писать в поисковой строке Kibana)


Таймлайн можно сворачивать (она сохраняется автоматически) и открывать в любое время

Из таймлайна можно создавать кейс
8. Связанный с nc IoC (это как раз pivoting) IP атакующего, добавим через OR на таймлайн и найдем связанные события

Находим новую информацию здесь: HTTP-запрос от certutil (на картинке ниже добавил колонку process.name)

9. Снова посмотрим цепочку и непосредственно из нее обнаружим, что certutil выполнял файловые операции - он создал nc в C:\xampp\htdocs\upload\


10. Здесь же, из цепочки, видно, что certutil загружал файл nc с 192.168.56.105:8080

Это можно также удобно видеть из событий на таймлайне (кому как удобнее)

Что у нас есть на сейчас:
  • certutil загрузил nc с 192.168.56.105:8080
  • nc запустил реверсивный шелл на 192.168.56.105:9001 

Последовательность событий на таймлайне

Надо понять почему наш Апачи (httpd) решил запустить certutil (это наглядно видно на цепочке)


И почему httpd запустил nc

Что также можно удобно посмотреть на таймлайне

11. Предположим, что 192.168.56.105 - атакующий, посмотрим, что он делал с httpd. Известно, что httpd - сервер Апачи, посмотрим его HTTP-события

Обратим внимание на подозрительное
http.request.body.content: "GET /upload/kamehameha.php?telepathy=echo+%25CD%25 HTTP/1.1
Host: 192.168.220.99
User-Agent: python-requests/2.23.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Cookie: sec_session_id=aojo31cnoo6j0gufvv7idk99pv

"

В 23:45:27.468 заметен подозрительный POST, посмотрим ближе и увидим, что он сделан от Python

http.request.body.content: "POST /upload.php?id=kamehameha HTTP/1.1
Host: 192.168.220.99
User-Agent: python-requests/2.23.0
Accept-Encoding: gzip, deflate
Accept: */*
Connection: keep-alive
Cookie: sec_session_id=aojo31cnoo6j0gufvv7idk99pv
Content-Length: 325
Content-Type: multipart/form-data; boundary=abfd0f202812e7186c51e3207977ffad

"

Если посмотреть что делал этот конкретный процесс httpd, то тоже ничего хорошего: запускал whoami, certutil, и т.п. , что едва ли можно считать штатной работой сервера Апачи

А еще этот httpd выполнял файловые операции

13. Предположим, что httpd записал Web-шелл, и чтобы это проверить посмотрим все файлы, записанные httpd

httpd создал странный файл Kamehameha.php в 23:45:27.468 непосредственно в момент подозрительного POST-запроса, следовательно, логично предположить, что файл был создан этим POST,  тем более его вид выше подтверждает эту гипотезу.

14. После подозрительного POST, наблюдаются запросы странного Kamehameha.php с весьма красноречивыми URL

15. С этого момента уже очевидно, что нам залили Web-shell, поэтому сделаем кейс, прямо из таймлайна, удобно



Глазами Синего. Повышение

1. На первом шаге мы расследовали реверсивный шелл на 192.168.56.105:9001


Последний cmd в этой цепочке


2. Посмотрим на этот cmd (pid 9840) более внимательно
3. Обращаем внимание на ac и обнаруживаем, что он создан certutil-ом

4. Характер команд п.2 демонстрирует повышение привилегий через ошибку конфигурации сервиса SSDPSRV,  поэтому поищем подозрительные команды, запущенные как сервис (с родителем services) и легко их находим

5. На цепочке также можно заметить и сетевые соединения на 192.168.56.105:9002

6. Недвусмысленное whoami от System

Для интересных событий можно создавать заметки

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



Глазами Синего. Автоматизируем Threat hunting

Очень хорошо, что мы умеем делать гипотезы и искать им подтверждение в данных. Но важная особенность Threat hunting-а - все, что однажды найдено вручную, впредь надо искать быстрее и проще. 
Elastic SIEM, как и любой SIEM позволяет сделать правила, по которым будут создаваться алерты.
Посмотрим, как это работает.

1. Первый хант, котрый мы сделаем - whoami от system. Для начала отладим соответсвующий поисковый запрос: process.command_line:*whoami* AND user.name:"SYSTEM"


2. В приложении SIEM создадим правило

3. Заполнив все поля (можно и не все), сохраним правило. Его можно посмотреть

4. Проведем атаку, убедимся, что наше правило работает, соответствующие алерты появляются



Для проведенной атаки можно придумать еще множество других правил, предлагаю читателю это сделать самостоятельно

  • запуск nc как сервиса
  • изменение binpath у сервиса с помощь sc
  • создание .php файла httpd
  • использование certutil для загрузки файлов по http
  • создание файлов certutil-ом
  • запуск cmd из httpd
  • ... и многое другое...

Вместо заключения

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