TryHackMe — Red Teaming — Chapter 1: Red Team Fundamentals — Subchapter 2: Red Team Engagements

Task 1. Введение

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

Участие Red Team бывает разных видов, включая:

1. Имитации мероприятия ввиде обсуждения за столом.

2. Имитация противника.

3. Физическая оценка.

Цели обучения:

1. Понять компоненты и функции участия Red Team.

2. Узнайте, как правильно планировать Red Team мероприятие, исходя из потребностей, имеющихся ресурсов и TTPs.

3. Понимать, как составлять документацию по заданию в соответствии с целями клиента.

Task 2. Определение масштаба мероприятия и целей

Договор между сторонами при промедении Red Teaming мероприятия может быть очень сложным и бюрократическим. Ключом к успешному взаимодействию является четкое определение задач или целей клиента. Цели клиента должны обсуждаться непостредственно между клиентом и командой специалистов, чтобы создать взаимопонимание между обеими сторонами относительно целей и деталей предстоящего мероприятия. Установленные цели являются основой для остальной документации и планирования официального договора.

Без четких и конкретных целей и ожиданий вы готовитесь к очень неструктурированной и незапланированной кампании. Цели задают тон всей остальной работе.

При оценке целей клиента и планировании деталей задания вам часто придется решать, насколько сфокусированными будут действия Red Team.

Задания можно разделить на общие внутренние/сетевые тестирования на проникновение или целенаправленную эмуляцию противника. Целенаправленная имитация противника определяет конкретную APT или группу для имитации атак в рамках мероприятия. Обычно это определяется на основе групп, которые нацелены на конкретные отрасли компании, например, финансовые учреждения и APT38. Внутреннее или сетевое тестирование на проникновение будет иметь схожую структуру, но часто будет менее целенаправленным и будет использовать более стандартные TTP.

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

Цели клиента также повлияют на общие правила проведения и объем задания.

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

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

1. Никакой утечки данных.

2. Производственные серверы запрещены.

3. 10.0.3.8/18 — вне зоны действия.

4. 10.0.0.8/20 находится в зоне действия.

5. Простои системы не допускаются ни при каких обстоятельствах.

6. Исчезновение PII (Personally Identifiable Inforemation — личная и конфиденциальная информация сотрудников комании) запрещено.

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

Task 3. RoE (Rules of Engagement)/Правила проведения Red Teaming мероприятия

Правила проведения Red Team мероприятия (RoE) — это юридически обязывающее изложение целей и объема работ клиента с дальнейшей детализацией ожиданий обеих сторон. Это первый официальный документ в процессе планирования взаимодействия, который требует надлежащего согласования между клиентом и Red Team. Этот документ часто выступает в качестве общего договора между двумя сторонами; также можно использовать внешний договор или другие NDA (соглашение о неразглашении).

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

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

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

Task 4. Планирование кампании

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

Каждая внутренняя Red Team будет иметь свою методологию и документацию для планирования кампании. Мы покажем один подробных планов, который позволяет обеспечить точную коммуникацию и подробную документацию. Сводка кампании, которую мы будем использовать, состоит из четырех различных планов, отличающихся глубиной и охватом, адаптированных из документов Red Team мероприятия. Каждый план можно найти в таблице ниже с кратким объяснением.

Task 5. Документация описывающая заключение договора между клиентом и Red Team

Документирование Red Team мероприятия является продолжением планирования кампании, когда идеи и мысли о планировании кампании официально документируются. В этом контексте термин «документ» может быть обманчивым, так как некоторые планы не требуют надлежащего документирования и могут быть простыми, как электронное письмо.

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

План договора:

План действий:

План мероприятия:

План по устранению последствий (необязательно):

Task 6. Концепция действий

Концепция операции (CONOPS) — это часть плана мероприятия, в которой подробно описывается высокоуровневый обзор хода операции; мы можем сравнить ее с отчетом о тестировании на проникновение. Этот документ будет служить в качестве справочной информации для бизнеса/клиента, а также для красной ячейки, от которой можно отталкиваться и расширять дальнейшие планы кампании.

Документ CONOPS должен быть написан с точки зрения полутехнического документа, предполагая, что целевая аудитория/читатель обладает нулевыми или минимальными техническими знаниями. Хотя CONOPS должен быть написан на высоком уровне, вы не должны опускать такие детали, как общий инструментарий, цели мероприятия и т.д. Как и в случае с большинством документов Red Team. Не существует установленного стандарта документа CONOPS. Ниже приведен перечень критических компонентов, которые должны быть включены в CONOPS.

1. Имя клиента

2. Поставщик услуг

3. Сроки

4. Общие цели/фазы

5. Другие цели обучения (эксфильтрация)

6. Высокоуровневые инструменты/техники, которые планируется использовать

7. Группа угроз для имитации (если есть)

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

Task 7. План использования ресурсов

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

В отличие от CONOPS, план ресурсов не должен быть написан в виде документа, вместо этого он должен быть написан в виде маркированных списков подразделов. Как и в большинстве документов Red Team, не существует документов или стандартного набора шаблонов плана использования ресурсов. Ниже приведены примеры подразделов плана использования ресурсов.

1. Заголовок

   • Персонал

   • Даты

   • Клиеты

2. Даты проведения мероприятия

   • Даты проведения разведки

   • Даты первоначального компрментации

   • Даты постэксплуатации и сохранения в системе

   • Другие даты

3. Необходимые знания (по выбору)

   • Разведка

   • Начальная компрометация

   • Пост-эксплуатация

4. Требования к ресурсам

   • Персонал

   • Аппаратное обеспечение

   • Облако

   • Разное

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

Task 8. План операций

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

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

1. Заголовок

   • Персонал

   • Даты

   • Клиент

2. Условия остановки/приостановки мероприятия (могут быть помещены в ROE в зависимости от глубины)

3. Требуемый/назначенный персонал

4. Конкретные TTP и планируемые атаки

5. План связи Red Team

6. Правила проведения мероприятия (необязательно)

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

1. vectr.io

2. Электронная почта

3. Slack

Task 8. План мероприятия

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

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

1. Цели

2. Операторы

3. Эксплойты/атаки

4. Цели (пользователи/машины/объекты)

5. Варианты выполнения плана

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