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

С каждым годом становится всё труднее ответить на этот вопрос. Атрибуция кибератак превратилась в гадание на кофейной гуще. Атакующие используют одни и те же open-source-инструменты, а хорошая телеметрия блокирует атаки так быстро, что после инцидента остается слишком мало данных для полноценного расследования.

Чтобы разобраться в ситуации, мы позвали Семёна Рогачёва, руководителя отдела реагирования на инциденты Бастиона. Он уже выступал с докладом на эту тему. 

Рассмотрим три реальных кейса: от простого подсчета атакующих до полной неопределенности с двумя группировками на одном сервере. Сразу предупреждаем: простых ответов не будет. 

«Мне кажется, у нас в сети кто-то лишний»

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

Телеметрия «сломана»

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

Вот только в большинстве реальных инфраструктур с телеметрией всё плохо. В настройках ОС по умолчанию этой самой телеметрии — кот наплакал, особенно если речь о Linux. Без нормального EDR-решения или других инструментов у вас остаются обрывки журналов, которые атакующий, скорее всего, почистил, и фрагментарные следы запуска процессов. Но стоит внедрить СЗИ и мониторинг — и SOC детектирует атаку на раннем этапе, блокирует ее и вышибает атакующего из инфраструктуры почти без усилий.

Казалось бы, победа? Для бизнеса — да, а вот для аналитика и расследователя — не совсем. Данные потеряны, атакующий не успел раскрыться, не применил весь арсенал и не показал свои TTPs.

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

Open Source всех уравнял

Если раньше по самописному инструменту можно было опознать конкретную APT-группировку, то сегодня этот метод почти не работает. Финансово мотивированные злоумышленники, государственные хакеры, хактивисты — одинаково активно используют Open Source.

Sliver, Mimikatz, AdRecon, gsocket, ngrok — этот «джентльменский набор» кочует из инцидента в инцидент. Будто все грабители в городе закупились одинаковыми ломами на AliExpress. Найти в логах след одного из этих инструментов — всё равно что не найти ничего. 

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

Как же различать атакующих? С огромным трудом — опираясь на едва заметные детали и постоянно сомневаясь в собственных выводах.

Три дела для цифрового Шерлока

Дело № 1

На первый взгляд, это случай из серии «Элементарно, Ватсон!». Мы не будем касаться атрибуции, а попробуем просто посчитать атакующих.

Вводные

Октябрь 2022 года. Атакующий получает доступ к инфраструктуре компании через уязвимый Exchange и загружает веб-шелл. Через какое-то время он запускает шифровальщик LockBit, но только на этом сервере. Расследования не было. Администратор просто восстановил Exchange из бэкапа и веб-шелл вместе с ним.

Развитие сюжета

Проходит год, на дворе — ноябрь 2023. Видим новый заход — судя по всему, через тот же веб-шелл образца 2022 года. Атакующий запускает стандартный набор разведки — Xen All Passwords Pro, AdRecon и ngrok, а через три дня разливает майнер на несколько серверов.

Финал

Апрель 2024. Злоумышленник аутентифицируется через ngrok из 2023 года, снова запускает AdRecon и через пять дней проводит централизованную атаку шифровальщиком LockBit.

Восстанавливаем логику событий

— Итак, детектив, что скажете?

Гипотеза № 1: один атакующий. Но зачем ему майнер, если в итоге он всё равно запустил шифровальщик? Зачем такой длинный перерыв между запусками AdRecon — неужели злоумышленник забыл, что уже проводил разведку? Мотивация совершенно непонятна.

Гипотеза № 2: несколько атакующих. Эта версия выглядит логичнее. Один — initial access broker — проломил периметр в 2022-м и продал доступ. Второй купил его в 2023-м и решил потихоньку помайнить. Третий пришел в 2024-м с серьезными намерениями и запустил LockBit. Но если у последнего был полный доступ к разведанной сети, зачем ему было ждать пять дней? Ведь этого мало для полноценной разведки инфраструктуры крупной компании.

Майнер ломает всю картину. Он не вписывается в логику одного актора. На самой простой задаче — «просто посчитать» — мы уже не можем дать однозначный ответ. А ведь еще даже не пытались назвать злодеев по именам…

Дело № 2

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

Завязка

Май 2023 года. В сети клиента инцидент — профиль идеально соответствует известной группировке DCHelp. Они используют классическую тактику — вероятно, перебор RDP — и для закрепления создают очень специфичную учетную запись OTRS с таким же специфичным, паролем, который нельзя угадать. Попытку запустить шифровальщик DiskCryptor заблокировал антивирус. Инцидент вроде бы отработан.

Проходит почти год

Апрель 2024. В систему через RDP с внешнего IP входит пользователь — та самая учетка OTRS. Ключевой момент: он входит с первого раза, без перебора пароля. Но дальше начинается странное — его TTPs не имеют ничего общего с DCHelp. Злоумышленник отключает антивирус и запускает шифровальщик BlackBit.

Выясняем связь между эпизодами

Откуда у второго атакующего пароль от учетки, созданной первым?

Технический анализ здесь бессилен. Связь между этими двумя событиями, скорее всего, нужно искать не в коде или логах, а где-то на даркнет-форумах. Первый атакующий — DCHelp — оставил «ключ под ковриком», а второй — связанный с BlackBit — либо купил, либо получил доступ по знакомству. Такая сделка с дьяволом не оставляет артефактов в системе, но напрямую влияет на происходящее.

Дело № 3

А вот теперь — хардкорный уровень. Этот кейс включает все возможные проблемы: отсутствие телеметрии, парадоксы и странные связи.

Сцена

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

Персонаж А («Хирург»): его активность начинается в сентябре 2023-го и тянется до начала февраля 2024-го. Он действует аккуратно, неторопливо, почти бесшумно. Использует уникальный инструмент, похожий на известный YARAT, но под Linux. Закрепляется через gsocket, добавляет ssh-ключ для root, проводит разведку через tcpdump и тихо сканирует сеть. Его почерк — глубокая, методичная разведка с использованием WINRM.

Персонаж Б («Орда»): набегает в конце февраля 2024-го. Закрепляется тем же gsocket, но дальше стандартный набор: fscan — для сканирования, Mimikatz и XenAllPasswordsPro — для паролей, AdRecon — для разведки в домене. Его действия — классические smash and grab: быстро собрать все, что плохо лежит, разлить шифровальщик и смыться.

Собираем картину происходящего

Что же это было? Один атакующий, который полгода аккуратно всё исследовал, а потом решил сменить тактику и устроить набег? Но зачем тогда менять уникальный инструмент на общедоступный ширпотреб? 

Возможно, два разных атакующих случайно столкнулись на одной уязвимости с разницей в пару недель. Однако «Орда» по почерку очень похожа на группировку, которая взяла ответственность за итоговое шифрование. Следует ли отсюда, что у этой группировки появился новый инструмент, и нужно атрибутировать его им? Или это множественная компрометация, где одна группа просто «доела» то, что не успела другая?

Чем глубже копаем, тем меньше понимаем. Это и есть современная атрибуция в условиях недостатка телеметрии во всей красе.

Не знаешь — так и скажи

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

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

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

Примите реальность: идеальной атрибуции не существует

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

Боритесь с Confirmation Bias — это зло

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

Кластеры важнее имен

Зачем вообще нужна атрибуция? Прежде всего, для понимания, чего ожидать от атакующего дальше, и выстраивания защиты. Но если все используют одни инструменты, гонка за конкретным названием группировки теряет смысл.

Полезнее мыслить кластерами активности — «у нас в сети группа, которая использует gsocket для закрепления, AdRecon — для разведки и LockBit — в финале, так подготовимся же к защите от этих TTPs». Неважно, что это за злодеи, если все они лезут через одну дыру. Просто заделаем брешь — и дело с концом. 

Инфраструктура — ненадежная улика 

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

Сегодня IP использует одна группа, завтра его арендует другая. Даже если ваш TI-вендор привязывает хост к определенному атакующему, помните: вы не знаете, на основании каких данных сделали эту привязку. Это как опознать преступника по машине из каршеринга — завтра на ней поедет кто угодно.

Проверяйте уникальность инструментов

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

Цените контекст, а не только артефакты

Атрибуция — не просто сопоставление хешей и IP-адресов. Почему атакующий действовал так долго? Почему в первом кейсе переключился на майнер, а во втором не стал менять пароль от учетки? Ответы на эти вопросы дают больше информации, чем технические данные. Главное — постоянно перепроверять выводы.

Жизнь после атрибуции

Возможно, в будущем AI-системы научатся вычленять уникальные поведенческие паттерны из логов и находить едва уловимый почерк даже у атакующих со стандартным набором инструментов. Но пока самый мощный аналитический процессор — мозг опытного специалиста. А лучшие инструменты расследователя — критическое мышление, насмотренность и готовность вовремя остановиться и сказать: «здесь у меня нет однозначного ответа».

И это, как ни странно, самый профессиональный ответ из всех возможных.

PURP — Telegram-канал, где кибербезопасность раскрывается с обеих сторон баррикад

t.me/purp_sec — инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастиона