Опубликовано · примерно 10 мин. чтения
В 00:33 на сервере с 1С и базой SQL появился файл с запиской вымогателей и первый зашифрованный файл. В 01:40 на другом сервере удалили каталог резервных копий и отменили расписание архивации, а через пятнадцать секунд принудительно очистили журнал безопасности — событие 1102. В 02:08 на административной станции запустился исполняемый файл, который антивирус классифицировал как вымогатель только в 07:40. К утру компания не работала.
Это не пересказ отраслевого отчёта. Мы обследовали эту инфраструктуру после инцидента, и всё, что ниже, взято из журналов, конфигураций шлюзов и выгрузки Active Directory. Название компании, адреса и имена узлов убраны — остались механика и цифры, потому что именно они повторяются от случая к случаю.
Порядок событий важнее, чем кажется
Шифрование началось на сервере, а не на рабочей станции. Запуск программы на административной станции в 02:08 был не началом атаки, а её продолжением: файлы на сервере к тому моменту шифровались уже полтора часа. В 02:51 зафиксирован сетевой вход с файлового сервера, опубликованного в интернет, на рабочую станцию в соседнем сегменте — единственный уцелевший след ночного перемещения по сети. В 07:41, через полчаса после срабатывания антивируса, на административной станции появилась служба-драйвер с автозапуском.
Между запуском процесса и первой реакцией защитного средства прошло около пяти с половиной часов. За это время шифрование шло на других узлах.
Почему точную точку входа установить не удалось
Скажу неприятное: конкретный входящий сеанс злоумышленника мы не назвали. Не потому, что плохо искали, а потому, что записей за ту ночь физически не осталось. Причин две.
Первая — журнал безопасности на одном из серверов очистили руками. Событие 1102 фиксирует сам факт очистки, учётную запись и идентификатор сеанса, но содержимое не возвращает.
Вторая интереснее и касается почти всех. Локальный журнал безопасности по умолчанию весит 20 МБ и ведётся с перезаписью по кругу. На сервере, опубликованном в интернет, шёл непрерывный внешний подбор паролей: 34 372 неудачных сетевых входа с 30 внешних адресов за сутки, темп около 1 450 попыток в час. Этого потока хватает, чтобы полностью обновить журнал примерно за сутки. Записи ночи инцидента вытеснил не злоумышленник — их вытеснил сам подбор, который продолжался и на момент обследования. Пока журналы лежат только локально, каждый следующий инцидент придётся разбирать так же вслепую.
Ведущая версия: удалённый рабочий стол наружу
На пограничном маршрутизаторе работала трансляция внешнего порта на порт 3389 файлового сервера — без ограничения адресов-источников. На самом сервере удалённый рабочий стол был включён без обязательной проверки подлинности на уровне сети (NLA), то есть форма входа отдавалась до аутентификации. Именно на этот узел приходился весь зафиксированный внешний подбор, и именно с него ночью пошло перемещение внутрь.
Отдельно про порт. Публикация была не на 3389, а на нестандартном пятизначном порту — ровно тот случай, когда привычная мера не работает. Сканеры перебирают весь диапазон портов, а не список типовых: на «спрятанный» порт пришло тридцать четыре тысячи попыток входа. Всего на двух периметрах этой компании оказалось 25 действующих публикаций удалённого рабочего стола. Не одна забытая — двадцать пять.
Пароли, которые невозможно не подобрать
Доменная парольная политика выглядела так: порог блокировки — 0, то есть блокировки нет вообще; минимальная длина пароля — 0 символов; требование сложности выключено. При таких настройках успешный подбор — вопрос времени и словаря, а не удачи. Чаще всего перебирали имена АДМИНИСТРАТОР (13 937 попыток), ADMINISTRATOR (4 133) и USER (2 947).
Второй правдоподобный источник учётных данных — то, о чём пишут редко. На восьми узлах нашлись следы средств обхода лицензирования и общая папка с активаторами, а на одной станции — исключение антивируса для такого софта. Активаторы распространяются вместе с программами кражи паролей и запускаются с правами администратора при отключённой защите. Доказать, что данные утекли именно так, нельзя, и в отчёте это записано как версия. Вывод для обеих версий одинаковый: пароли, действовавшие до инцидента, считать известными посторонним и менять полностью, а не выборочно.
Резервные копии, которых не было
Это самая дорогая часть истории, и картина здесь типовая.
- Контроллер домена: встроенная архивация Windows, последняя копия — за 56 суток до инцидента, целевой носитель — локальный диск D того же сервера, который она должна защищать.
- Сервер 1С: сторонняя программа копирования, служба остановлена, проверка теневых копий завершается ошибкой.
- Два терминальных сервера и второй сервер 1С: средств резервного копирования не обнаружено вообще.
- Рабочая станция с копиями телефонии: папка открыта на запись для всех, сама станция опубликована по удалённому рабочему столу.
Контрольное восстановление не проводилось ни разу, и ни одна из найденных копий не годилась для возврата актуального состояния. Это и есть разница между «бэкапы настроены» и «бэкапы есть»: первое — галочка в интерфейсе, второе — файл, который вы развернули на тестовом стенде и увидели, что база открывается.
Плоская сеть, где всё видит всё
Внутреннее сканирование показало 100 активных узлов в одном сегменте канального уровня: серверы, рабочие станции, 30 камер видеонаблюдения, 26 устройств IP-телефонии, 12 принтеров и сетевое оборудование. Такая сеть не доказывает, каким путём шёл злоумышленник, но убирает барьеры: скомпрометировали одну станцию — и с неё видны серверы, контроллер домена и управляющие интерфейсы. Заодно камера с прошивкой пятилетней давности стоит в одном сегменте с бухгалтерской базой.
Про учётную запись — важная оговорка
Все разрушительные действия выполнены под одной привилегированной доменной учётной записью: ею очищен журнал, из её профиля запускался шифровальщик, под ней же выполнен вход на соседнюю станцию. Соблазн назвать виновного огромный, и это ошибка. Совпадение имени в журнале означает использование учётных данных, но не доказывает, что за клавиатурой сидел их владелец: пароль могли похитить или подобрать, тем более что политика это допускала. Правильный вывод — считать запись скомпрометированной, сменить пароль, аннулировать сеансы и билеты, проверить права.
Так делать не надо
Переносить удалённый рабочий стол на нестандартный порт и считать вопрос закрытым. Защита — это ограничение по адресам-источникам, доступ через VPN и включённая проверка подлинности на уровне сети.
Хранить резервную копию на том же сервере, который она защищает. Шифровальщик добирается до подключённых дисков в первую очередь, а удалить каталог с копиями — первое, что делают перед запуском шифрования.
Проверять восстановление в день аварии. Копия, которую ни разу не разворачивали, — это предположение, а не копия.
Сразу после инцидента закрыть порты и вернуться к работе. Так затираются следы, а если атакующий закрепился внутри — задачей в планировщике, службой, лишней учётной записью, — закрытые порты ему не мешают.
Что проверить у себя сегодня
- Откройте список правил проброса портов на маршрутизаторе и посчитайте, сколько ведёт на удалённый рабочий стол и у скольких задано ограничение по адресам-источникам.
- Посмотрите доменную парольную политику: порог блокировки, минимальную длину, сложность. Три нуля подряд — это состояние «подбирается за ночь».
- Найдите последнюю резервную копию и ответьте на два вопроса: на каком физическом носителе она лежит и когда её последний раз разворачивали.
- Посмотрите размер журнала безопасности на сервере с публикацией наружу и самую раннюю запись в нём. Хранит меньше недели — историю инцидента вы не восстановите.
- Проверьте, включена ли на серверах проверка подлинности на уровне сети для удалённого рабочего стола.
Если по ходу списка стало понятно, что смотреть некому и некогда, это и есть повод позвать подрядчика. Порядок действий на случай, когда шифрование уже идёт, собран отдельно — на странице реагирования на инцидент.
Границы: чего мы не делаем
Мы не расшифровываем файлы: если для семейства нет готового дешифратора, восстановление возможно только из копий, и обещать другое нечестно. Не ведём переговоры с вымогателями и не делаем экспертизу для суда — это профильные компании с другой лицензией. Лабораторное исследование образца в такие работы тоже не входит: название программы в этом инциденте взято из записки вымогателей и расширения файлов, а не из анализа кода. Наша часть — остановить, восстановить работоспособность, найти вероятную точку входа и построить копирование, которое переживёт следующий раз.
Частые вопросы
Мы маленькая компания, кому мы нужны?
Логика у нападающих обратная: небольшая организация защищена хуже, взломать её дешевле, а платить за остановленный бизнес она готова так же. Подбор паролей вообще не выбирает жертву — он идёт по интернету подряд.
У нас есть антивирус, разве этого мало?
В разобранном инциденте антивирус сработал — через пять с половиной часов после запуска процесса, когда шифрование уже шло на других узлах. Защитное средство полезно, но это последняя линия, а не первая.
Сколько занимает восстановление?
Когда копии целы и физически отсоединены — два-три дня. Когда копий нет, речь идёт о неделях: заново разворачиваются серверы, переустанавливаются станции, восстанавливается домен. Часть данных не возвращается.
С чего начать, если список выше вас не порадовал
Обследование, из которого взят этот разбор, заняло пять дней и дало пятнадцать критичных пунктов — от двадцати пяти публикаций удалённого рабочего стола до нарушенной репликации Active Directory, которая не работала несколько лет и о которой никто не знал. Ни один пункт не был экзотикой: всё это встречается по отдельности почти в каждой второй инфраструктуре, а беда случается, когда они собираются вместе.
Начать стоит с того же, с чего начинали мы, — с аудита инфраструктуры. Для парка примерно до 20 компьютеров и одного сервера он бесплатный, для большего объёма считается отдельно. По итогам будет понятно, что открыто наружу, живы ли копии и сколько времени хранятся журналы. Позвонить можно по номеру +7 499 390-96-31.