T.Hunter

❓Что логировать, чтобы расследование состоялось

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

Минимум, без которого расследование не строится:
🔹 Запуск процессов. Что, кем и с какими аргументами (Windows Event 4688 или Sysmon). По нему видно цепочку
🔹 PowerShell. Script Block Logging (4104). Любимый инструмент атакующего, без логов невидим
🔹 Входы и аутентификация (4624 / 4625). Видно подбор паролей и вход с чужой учетки
🔹 DNS-запросы. Часто единственный след связи с управляющим сервером

Три вещи, без которых логи бесполезны:
🔸 Единое время. Без синхронизации (NTP) события не сложить в линию
🔸 Срок хранения. Атакующего замечают через месяцы, а логи за неделю затерты
🔸 Централизация. Логи на взломанной машине сотрет сам атакующий

🎯 Threat hunting по MITRE ATT&CK: с чего начать

Threat hunting это проактивный поиск злоумышленника, который уже внутри, но тревогу не поднял. Не ждем алерт, а сами проверяем гипотезы. MITRE ATT&CK здесь каркас: база знаний о тактиках и техниках реальных атак

С чего начать:

1. Проверьте, что видите. Поиск без данных невозможен. Сопоставьте техники ATT&CK с тем, что реально пишется в логи (процессы, PowerShell, сеть, DNS)
2. Не хватайтесь за всю матрицу. Возьмите актуальное: с чего чаще начинают атаки на вашу отрасль, что видно в отчетах и в БДУ ФСТЭК
3. Начните с частого. Техники почти из каждой атаки: T1059 (запуск команд и скриптов), T1003 (кража учетных данных), T1053 (планировщик задач)
4. Гипотеза → запрос → вывод. «Если закрепляются через автозагрузку, увижу в логах так-то». Нашли, не нашли, увидели слепую зону, в любом случае результат

Это не про инструмент, а про вопрос, который вы задаете своим данным

🔐 Фишинг-устойчивая аутентификация

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

Где это не усиливает защиту:
🔹 Код из SMS пользователь вводит сам. На поддельной странице его перехватывает прокси и подставляет на настоящий сайт
🔹 Push с одной кнопкой «Подтвердить». Человека заваливают запросами или шлют их в момент фишинга, и он жмет «да» на автомате

Как лучше:
🔹 Push с вводом числа с экрана входа (number matching) вместо простой кнопки. Убирает случайные подтверждения, но от перехвата через прокси не спасает, так что это мера переходная

Что реально устойчиво к фишингу:
✅ FIDO2 / passkey и аппаратные ключи (например, YubiKey). Подпись привязана к адресу сайта и на поддельном домене не сработает

SMS лучше, чем ничего. Но для админов, VPN и критичных систем ставьте надежный фактор