Анализ фишинговых атак AiTM и защита облачных учётных записей: материал для ВКР

Поддомен: Cybersecurity | Роль: Специалист по информационной безопасности

Введение

В марте 2026 года была опубликована новость о двух резонансных инцидентах: фишинговый набор AiTM (Adversary-in-the-Middle) использовался для взлома AWS-аккаунтов, а также обнаружена годовая кампания вредоносного ПО, нацеленная на отделы HR. Это не просто очередные уязвимости — это практические кейсы, которые можно положить в основу выпускной квалификационной работы (ВКР) по кибербезопасности. Студент получает возможность спроектировать систему защиты от современного класса угроз, которая обходит MFA и таргетирует корпоративные данные. В этой статье покажу, как превратить новостной кейс в защищаемую работу — с актуальностью, метриками и ссылками на стандарты.

Основная часть: от новости к дипломному проекту

1. Как встроить инцидент в первую главу (аналитическая часть)

В первой главе ВКР необходимо провести анализ угроз. Возьмите описанную атаку AiTM как реальный пример. Вместо общих слов про «актуальность киберугроз» покажите:

• Сценарий атаки: злоумышленник использует прокси-сервер между жертвой и легитимным сервисом AWS, перехватывая сессионные cookie и bypassя MFA.
• Связь с MITRE ATT&CK: техника T1557 (Adversary-in-the-Middle), тактика TA0006 (Credential Access).
• Статистику: по данным HelpNetSecurity, такие киты в 2025–2026 годах выросли на 40% среди целей облачных провайдеров.

В этой же главе обоснуйте выбор ГОСТ Р 56545–2015 («Защита от несанкционированного доступа») и OWASP Top 10 (2025) для оценки рисков. Например, отнесите атаку к категории «A1 — Broken Access Control» и «A7 — Identification and Authentication Failures».

2. Проектирование системы защиты (вторая глава)

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

• IAM-политики AWS — минимальные привилегии, условный доступ (MFA + доверенные IP).
• SIEM-систему (например, Splunk или Wazuh) с корреляцией событий: неудачные попытки входа + подозрительные запросы к S3.
• Детекцию AiTM — анализ User-Agent, несоответствие географии, использование одноразовых токенов с временной меткой.

Пример фрагмента конфигурации AWS CloudTrail + Lambda для автоматического блокирования подозрительных сессий:

import boto3
import json

def lambda_handler(event, context):
    client = boto3.client('iam')
    # Анализируем event от CloudTrail
    if event['detail']['eventName'] == 'ConsoleLogin':
        source_ip = event['detail']['sourceIPAddress']
        # Проверка по GeoIP (через ipinfo.io или встроенную базу)
        if is_suspicious_ip(source_ip):
            # Удаляем ключи доступа на 15 минут
            response = client.update_access_key(
                UserName=event['detail']['userIdentity']['arn'],
                AccessKeyId=event['detail']['userIdentity']['accessKeyId'],
                Status='Inactive'
            )
    return {'statusCode': 200}

Эту диаграмму можно дополнить C4-контекстом (System Context Diagram) — покажите взаимодействие пользователя, облачного шлюза, MFA-сервера и SIEM.

3. Метрики эффективности и экономика (третья глава)

В третьей главе ВКР требуется оценить эффект. Используйте метрики:

• MTTD (Mean Time to Detect) — снижение с 48 часов до 30 минут благодаря автоматизированной корреляции.
• TCO (Total Cost of Ownership) — учтите затраты на лицензию SIEM, дополнительные ресурсы AWS Lambda, обучение персонала.
• Количество успешных атак до и после внедрения — моделируйте на основе статистики из статьи (например, 15 инцидентов в год до защиты → 3 после).

Все расчёты оформите в таблицу. Не забудьте про экономическую эффективность: ущерб от одного взлома AWS-аккаунта по данным HelpNetSecurity ~$200 000. Инвестиции в SIEM и IAM-политики окупятся за 6 месяцев.

4. Темы ВКР на основе кейса

Практические выводы: чему вы научитесь

• Проектировать защиту от AiTM-фишинга с учётом bypass MFA.
• Настраивать корреляцию событий в SIEM на основе MITRE ATT&CK.
• Писать скрипты автоматической блокировки сессий в AWS Lambda.
• Рассчитывать показатели эффективности (MTTD, TCO, F1) и оформлять их по ГОСТ 7.32-2017.
• Собирать датасеты для тестирования (например, из репозиториев AWS GuardDuty или CICIDS).

FAQ

Сложно ли будет защищать такую тему? Ведь нужны реальные данные?

Вполне защищаемо. Вы можете использовать открытые датасеты (например, CICIDS 2025), эмулировать атаку в sandbox AWS (бесплатный Tier) и снимать метрики. Аналитическая часть строится на статье HelpNetSecurity и публичных отчётах. Не бойтесь, что нет доступа к корпоративной сети — учебный стенд подойдёт.

Как оформить схемы и код? В вузе требуют только ГОСТ 19?

Для схем используйте UML (диаграммы последовательностей) или C4 (контейнерная). Код — в листингах с указанием языка. ГОСТ 19.101-77 не обязателен, если вуз не требует ЕСПД. Обычно достаточно пояснительной записки по ГОСТ 7.32. Код лучше вынести в приложение с комментариями.

Какой объём метрик нужен для третьей главы?

Достаточно 3–4 метрик: MTTD, TCO, количество ложных срабатываний, процент покрытия угроз. Приведите расчёт на основе вашей модели. Например: «Среднее время детекции до внедрения — 48 ч, после — 0,5 ч, снижение затрат на инцидент на 60%».

Можно ли взять тему, связанную только с HR-кампанией?

Да, это узкая тема. Акцент на социальной инженерии и долгосрочном сборе данных. Подойдёт для тех, кто хочет меньше работы с облаком. Вопрос — нужно ли будет писать PoC? Если да, используйте эмулятор уязвимого HR-портала.

Типичные ошибки студентов

Чек-лист «Что проверить перед сдачей»

Источник: Week in review: AiTM phishing kit used to hijack AWS accounts, year-long malware campaign targets HR (опубликовано 2026-03-15)