Анатомия атаки: как ransomware попадает в сеть украинского бизнеса. Реальный кейс

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

Фото: Фрагмент Ransom note

Открытая дверь: RDP наружу через маршрутизатор

Когда мы проанализировали конфигурацию периметрового маршрутизатора MikroTik, находка оказалась шокирующей, хотя и предсказуемой. На устройстве было настроено 8 правил dst-nat, которые пробрасывали протокол RDP непосредственно на внутренние хосты через нестандартные порты (13389, 23389, 33389 и т. д. ). Фактически — 8 компьютеров компании были доступны из любой точки мира через удаленный рабочий стол.

Фото: 8 правил RDP dst-nat – без ограничений по IP источника

Никаких VPN. Никакой двухфакторной аутентификации. Никакого ограничения по IP-адресу источника.

При этом администраторы компании искренне считали, что «мы за NAT-ом, нас не видно». Это распространенное заблуждение: NAT — это механизм трансляции адресов, а не средство защиты. Если вы сами настроили проброс портов — вы сами открыли дверь.

Контроллер домена, которому 17 лет

Сердцем сети был контроллер домена Active Directory на базе Windows Server 2008 SP2 — операционной системы, поддержку которой Microsoft прекратила еще в 2020 году. Эта система уязвима к целому ряду критических эксплойтов: Zerologon (CVE-2020−1472), EternalBlue, PrintNightmare — каждый из которых позволяет получить полный контроль даже без пароля.

Мы провели аудит домена с помощью инструмента PingCastle. Результат — 100 баллов из 100. Это не оценка качества. Это шкала риска, где 100 — наихудший возможный результат.

Фото: Результат аудита домена с помощью PingCastle

Среди находок: 52 учетные записи с правами администратора домена (при норме 3−5), отсутствие политики смены паролей для привилегированных аккаунтов, включенный протокол SMBv1 и десятки рабочих станций на Windows 7 и даже Windows XP.

Идеальная учетная запись для злоумышленника

Для горизонтального перемещения по сети злоумышленник выбрал сервисную учетную запись системы 1С: Предприятие. Почему именно его? Потому что этот аккаунт имел права Domain Admin, по своей природе подключался ко многим машинам одновременно (что маскирует подозрительную активность) и, самое главное, за ним не стоял ни один конкретный человек, который мог бы заметить что-то необычное.

Пароль этого аккаунта никогда не менялся. У аккаунта было разрешение на интерактивный вход по RDP, хотя для работы сервиса 1С это совсем не нужно.

Почему жертва ничего не видела

Централизованный сбор журналов событий (логов) в компании не был настроен. Все логи хранились локально на каждой машине. Злоумышленнику достаточно было очистить один файл на контроллере домена — и вся история аутентификаций исчезла. Что он и сделал.

Без SIEM, без пересылки логов на защищенное хранилище, без мониторинга — компания фактически работала вслепую. Когда мы начали расследование, большинство пораженных систем уже были переустановлены IT-командой. Ключевой сервер, с которого злоумышленник координировал всю атаку, был переустановлен полностью — это самая большая потеря доказательств в этом кейсе.

Что из этого вынести

Этот инцидент не стал следствием какой-то изощренной хакерской операции. Злоумышленники не использовали zero-day уязвимостей или специализированных C2-фреймворков вроде Cobalt Strike. Они просто воспользовались тем, что им дали: открытым RDP, устаревшей ОС, сверхпривилегированным сервисным аккаунтом и отсутствием мониторинга.

Проверьте прямо сейчас: есть ли в вашей сети проброс RDP на внешний периметр? Сколько аккаунтов имеют права Domain Admin? Когда в последний раз менялись пароли сервисных учетных записей? Сохраняются ли ваши логи где-то, кроме самих серверов?

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

Следующая статья серии: «48 часов внутри сети: что делает злоумышленник перед шифрованием» — пошаговая хронология действий BlackField от первого входа до запуска шифровальщика.

Автор: команда DFIR, SHERIFF Кібербезпека