CryptoLocker: первый звонок с зашифрованным файловым сервером
Разбираем вектор заражения CryptoLocker через email-вложение, восстанавливаем данные из снапшотов NAS и экстренно внедряем AppLocker на инфицированной сети.
CryptoLocker - первый массовый шифровальщик-вымогатель - появился осенью 2013 года и за несколько недель заразил сотни тысяч машин.
Звонок пришёл в середине рабочего дня. Голос у клиента был ровный, но с той специфической интонацией, когда человек уже всё понял и просто хочет, чтобы кто-то приехал. «Файловый сервер не открывается. Все файлы с расширением .encrypted».
Это был наш первый контакт с CryptoLocker. До этого момента мы читали о нём в зарубежных блогах как о чём-то далёком - ну шифровальщик, ну вымогатель, бывает. В этот день он стал очень близким.
Что увидели на месте
Картина была аккуратная и от этого неприятная. На файловом сервере - Windows Server 2008 R2, общий диск с расшаренными папками для всего офиса - порядка восьмидесяти процентов файлов переименованы, к каждому добавлено расширение .encrypted. В корневой папке каждого каталога лежал файл DECRYPT_INSTRUCTION.html с объяснением ситуации и требованием заплатить в биткоинах. Таймер. Адрес сайта в сети Tor.
Сам сервер не был заражён напрямую. Шифровальщик запустился на рабочей станции одного из менеджеров - и зашифровал всё, до чего дотянулись смонтированные сетевые диски. Менеджер имел права на запись во все расшаренные папки. Шифровальщик работал под его учётной записью и соответственно имел ровно те же права.
Вектор заражения
На рабочей станции нашли его быстро. В папке загрузок - архив с PDF-иконкой, внутри которого лежал исполняемый файл. Письмо пришло двумя часами ранее якобы от транспортной компании - «ваш заказ ожидает получения, документы во вложении». Менеджер распаковал архив, открыл то, что выглядело как PDF.
Антивирус на станции был. Базы обновлялись раз в несколько дней, не ежедневно. CryptoLocker на тот момент был достаточно свежим, чтобы пройти мимо сигнатур. Запуск произошёл из папки %APPDATA% - место, куда пользователь может писать без каких-либо прав администратора.
Дальше процесс работал тихо: соединился с командным сервером, получил публичный ключ RSA-2048, начал шифровать. Не весь диск сразу - сначала документы, таблицы, PDF, затем расшаренные папки по смонтированным дискам. Шифрование файла по файлу, без каких-либо признаков активности для пользователя. Человек работал, пил кофе, не замечал ничего около двух часов.
Восстановление
Хорошая новость: у клиента стоял NAS Synology с настроенными снапшотами. Снапшоты делались каждые четыре часа. Последний чистый снапшот был за шесть часов до заражения - это значило потерю примерно двух часов работы, не шести. Приемлемо по меркам ситуации.
Алгоритм был такой.
Первое - изоляция. Рабочую станцию менеджера немедленно отключили от сети. Проверили, не запущен ли аналогичный процесс ещё где-то - мониторинг процессов на остальных станциях через RSAT. Чисто.
Второе - остановка сервера. Общий диск размонтировали у всех пользователей, сервер файловых служб остановили. Не трогать то, что уже зашифровано - не создавать новые версии зашифрованных файлов поверх снапшотов.
Третье - восстановление из снапшота NAS. В интерфейсе Synology DSM откатили расшаренные папки на снапшот шестичасовой давности. Процедура заняла около сорока минут на объём данных примерно в полтора терабайта. Смонтировали обратно, проверили выборочно - файлы читаются, расширения нормальные.
Четвёртое - переустановка рабочей станции. Станцию менеджера не лечили - переустановили с нуля. Лечить шифровальщики с возможными руткит-компонентами мы считаем нецелесообразным: слишком мало уверенности в результате.
Потери: около двух часов работы менеджера и двух-трёх других пользователей, которые параллельно правили файлы в тот же период. Неприятно, но не катастрофа.
Что внедрили сразу
Ещё пока шло восстановление, мы договорились с клиентом о двух вещах, которые сделаем до конца дня.
AppLocker. Настроили политику AppLocker через GPO на всех рабочих станциях. Правило простое: запуск исполняемых файлов разрешён только из %ProgramFiles%, %ProgramFiles(x86)% и %Windows%. Запуск из %APPDATA%, %TEMP%, %Downloads% и любых пользовательских папок - запрещён. Именно оттуда CryptoLocker и запустился. Политика режимная, не «только аудит» - мы убедились, что у пользователей нет легитимных программ, установленных в домашние директории.
Снапшоты чаще. На NAS изменили расписание: снапшоты каждый час вместо каждых четырёх. Хранение - суточные снапшоты за неделю, еженедельные за месяц. Нагрузки почти никакой, а окно потерь резко сужается.
Антивирус обновили на ежедневный режим с принудительным обновлением при старте системы - это не панацея, но хотя бы убирает самую очевидную дыру.
Что осталось открытым
Права доступа к расшаренным папкам у этого клиента были настроены по принципу «всем всё» - исторически так сложилось. Это прямая причина масштаба урона: шифровальщик получил доступ ко всему, что видел пользователь. Разграничение прав по ролям - следующий шаг, но это отдельная работа, которую сразу не сделать без инвентаризации того, кому что реально нужно.
Фильтрация вложений на почтовом шлюзе тоже оставляла желать лучшего. Исполняемый файл в архиве прошёл - шлюз проверял только первый уровень вложений. Поставили в план перенастройку, аналогичную тому, что мы делали с антиспам-шлюзом у других клиентов.
CryptoLocker неприятен не сложностью - он технически довольно прямолинеен. Неприятен тем, что работает тихо, бьёт по расшаренным дискам и до момента обнаружения успевает сделать всё что хотел. Снапшоты спасли ситуацию. AppLocker закрыл самый очевидный вектор. Но ощущение, что мы посмотрели на что-то, что будет встречаться чаще, осталось.
- Spear phishing: когда письмо пришло от директора · 4 апреля 2013
- Облачный антиспам-шлюз: MX в облако, спам упал с 85% до 2% · 19 сентября 2013