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

Расследование подозрительных учетных данных AWS с использованием CloudTrail и GuardDuty

6 мин чтенияОпубликовано: 5 августа 2026 г.

Профессиональная визуальная иллюстрация по расследованию учетных данных AWS в области Cloud Security и IR

Быстрый ответ

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

Расследование в облаке требует сопоставления идентификационных данных, Control Plane, ресурсов, ключей, сессий и служб безопасности. Поскольку активность распределена между службами и регионами, временная шкала и понимание разрешений имеют решающее значение. Эта статья посвящена расследованию учетных данных AWS и предназначена для аналитиков облаков и SOC. Цель состоит в том, чтобы предоставить методологию, которую можно применять на практике, на профессиональных собеседованиях и в рабочей среде, не ограничиваясь словарным определением.

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

Практический сценарий в статье: расследование имитированных вызовов API из необычного местоположения. Все примеры представляют собой лабораторные данные или описание процессов. При работе с Penetration Testing, Web или Cloud, необходимо работать только с явным разрешением, определенной областью действия и возможностью остановить тестирование.

Источники телеметрии

На этом этапе определяется, какие доказательства необходимы для ответа на вопрос расследования. Для расследования учетных данных AWS базовыми точками являются Principal и session, API action, Resource и region, Source IP и user agent. Для каждого источника документируются владельцы, диапазон хранения, часовой пояс, задержка получения и поля, которые могут отсутствовать.

Качество сбора не измеряется тем, что лог 'приходит'. Необходимо проверить Completeness, Latency, Parsing, Duplicate events и синхронизацию времени. Тест Canary или известное лабораторное событие позволяет убедиться, что действие появилось в источнике, прошло через Pipeline и может быть найдено в правильных полях.

Principal и Access key

Тема 'Principal и Access key' является центральной частью работы по расследованию учетных данных AWS. Рекомендуется разбить ее на три вопроса: что является входными данными, какое решение необходимо принять и какое доказательство достаточно для его обоснования. Эти вопросы предотвращают автоматическое использование инструмента без понимания цели.

На практике запишите CloudTrail, GuardDuty, IAM principal, access key, AssumeRole, сравните с ожидаемым поведением и определите как минимум один Pivot. Результат должен быть проверяемым другим аналитиком, включая ограничения и дальнейшие шаги.

CloudTrail timeline

Временная шкала является основой расследования учетных данных AWS. Нормализуйте время до UTC или явно укажите часовой пояс, сохраните как Event time, так и Ingestion time, и соедините события по стабильным идентификаторам. Строка должна включать время, источник, сущность, действие, результат и достоверность.

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

GuardDuty и Scoping

Тема 'GuardDuty и Scoping' является центральной частью работы по расследованию учетных данных AWS. Рекомендуется разбить ее на три вопроса: что является входными данными, какое решение необходимо принять и какое доказательство достаточно для его обоснования. Эти вопросы предотвращают автоматическое использование инструмента без понимания цели.

Containment, Rotation и Lessons learned

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

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

Уникальные точки проверки

В этой теме рекомендуется заранее составить целенаправленную карту доказательств. Основные точки проверки: CloudTrail, GuardDuty, IAM principal, access key, AssumeRole, region, S3/Lambda/EC2. Список не является автоматическим контрольным списком; каждый элемент выбран потому, что он может связать сущность, действие и время или объяснить легитимное поведение.

CloudTrail: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.
GuardDuty: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.
IAM principal: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.
access key: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.
AssumeRole: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.
region: Определите ожидаемое значение, что будет считаться аномальным и какой дополнительный источник подтвердит находку.

Если одна из точек недоступна, необходимо задокументировать пробел и выбрать альтернативу. Например, если Process identifier нестабилен, можно использовать время, Host, User и Parent; если Payload зашифрован, используются Metadata, объем, частота и TLS/DNS context.

Практический сценарий

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

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

Шаг	Что выполняется	Результат
Подготовка	Определите Scope, время и цель. Запишите, какие поля или доказательства из CloudTrail, GuardDuty, IAM principal ожидаются.	Краткий план проверки
Создание данных	Выполните безопасное и имитированное действие, связанное с расследованием учетных данных AWS, без реальной информации или влияния на производственную систему.	Контролируемое событие/запрос/поток
Сбор	Соберите исходное доказательство и контекст из дополнительного источника. Убедитесь в правильности Time zone, идентификаторов и полноты.	Два связанных доказательства
Анализ	Напишите, что доказывает каждое доказательство, что не доказывает, и каково возможное легитимное объяснение.	Промежуточный вывод
Завершение	Выберите закрытие, эскалацию, Finding или Tuning; добавьте рекомендацию и Retest.	Задокументированный результат

Практический контрольный список

Проверьте и задокументируйте: Principal и session.
Проверьте и задокументируйте: API action.
Проверьте и задокументируйте: Resource и region.
Проверьте и задокументируйте: Source IP и user agent.
Проверьте и задокументируйте: Audit event ID.
Проверьте и задокументируйте: GuardDuty/Defender/SCC finding.
Укажите Time zone, версию инструмента и время сбора.
Сохраните необработанные данные до фильтрации или изменения.
Напишите, что доказывает находка и что еще неизвестно.
Определите владельца и дальнейшие действия с указанием срока.

Распространенные ошибки

Сосредоточиться только на одной области.
Сменить ключ до сохранения временной шкалы.
Не проверять AssumeRole или Token.
Игнорировать Control Plane.
Не сопоставлять эффективные разрешения.
Делать вывод, что географическое местоположение доказывает атаку.

Резюме и CTA

Расследование подозрительных учетных данных AWS с использованием CloudTrail и GuardDuty — это тема, которая связывает технические знания с дисциплиной работы. Начните с вопроса, собирайте только релевантные доказательства, сохраняйте контекст и время, и выбирайте действия, которые можно обосновать и перепроверить.

В рамках курса Cybersecurity & AI от HPI эти принципы отрабатываются с использованием систем, логов и лабораторий. Естественным продолжением является переход к связанным статьям, выполнение лабораторного задания и сохранение результата как части профессионального портфолио.

Вопросы и ответы

Доказывает ли расследование учетных данных AWS само по себе атаку или уязвимость?

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

Что делать, если часть данных отсутствует?

Задокументируйте отсутствие, проверьте альтернативный источник и снизьте уровень уверенности. Не следует заполнять поля предположениями или представлять Unknown как нормальное состояние.

Как долго нужно хранить доказательства?

Время зависит от политики, регулирования, стоимости и типа инцидента. Важно заранее определить Retention, Legal hold и возможность экспорта доказательств в проверяемом формате.

Как практиковаться, не подвергая риску реальную систему?

Используйте виртуальные машины, имитированные данные, CTF или выделенную лабораторию. При авторизованных проверках определите Scope, Stop conditions и резервное копирование перед началом работы.