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

Все началось с утреннего звонка коллеги - не может подключиться к корп сети через VPN, не проходит соединение. Ок, открываю Cisco AnyConnect, пытаюсь соединиться иии, действительно. Выдает какую-то ошибку (уже не помню какую), но при этом IP пингуется и я могу подключиться к циске через ASDM. Странно, конечно. Штош, придется ехать в серверную и смотреть на месте. Неспешно собираюсь, а в это время начинают поступать все новые звонки и сообщения. Возникает нехорошее предчувствие. Доезжаю до серверной, жму кнопочку на KVM, вижу работающий TS. Логинюсь на него и на рабочем столе вижу файл Your_files_have_been_encrypted.html

Я. Понял. Сразу. Все.

Люди по-разному реагируют на стресс и потрясение. Кто-то впадает в ступор, кто-то в панику, кто-то в истерику. Мне довелось ощутить нечто среднее. Какой-то момент я стоял и тупо смотрел на этот файл. Очевидно, что это фиаско, но я еще не думал о последствиях, способах решения, не думал вообще ни о чем осязаемом. Просто уставился на экран и хотел, чтобы все это было лишь дурным сном. Увы.

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

Достаю телефон, звоню генеральному и спокойно говорю: «Нас взломали». Все, точка невозврата. Начинается приключение.

Предыстория

Эта небольшая организация на обслуживание досталась мне в типичном для отрасли состоянии. Операционная деятельность, конечно, не ритейл, но работают они 7/0 8-20. Железо хорошее, но древнее, как и все ПО, возрастом примерно 10 лет. За это время предприятие прошло через руки нескольких сисадминов. Каждый из них достраивал свои велосипеды по мере возможностей и воображения, но фактически все держалось на базе, которую создал первый админ.

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

За полгода до инцидента была взломана наша материнская компания. Болезненный простой, только официальных убытков на ~ 300 миллионов рублей. Я сказал, что мы следующие. Накаркал.

Анализ

Первым делом выдергиваю сетевой шнурок из циски и физически гашу все сервера. Это все, что ты можешь сделать в данный момент.

Тем временем звонков становится все больше: все филиалы не работают, нет интернета и связи с серверами, у всех зашифрованы файлы на декстопах.

Чтобы понимать масштаб проблемы, необходимо описать инфраструктуру:

3 филиала, офис, ДЦ. Все работает на древних цисках ASA 5505 site to site VPN + подключение юзеров напрямую.

Серверная инфраструктура:

3 гипервизора ESXi 7.х с vCenter. Внутри крутятся: AD1,2, Exchange/Office 2016, 3CX, Veeam, NFS, SMB – все на 2012R2, достаточно свежие уже мои линуксовые сервера со всяким разным. Физические серверы тоже 2012R2 под 1С с SQL, Terminal Server, бэкап сервер TrueNAS. Везде из AV только defender.

Главные активы: шара 4ТБ, около 10 1С SQL баз объемом в 1ТБ, профили юзеров RDP еще около 5ТБ, почта Exchange примерно 500ГБ.

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

Гипервизоры работоспособны, но VM выключены, а их образы зашифрованы.

Физические сервера также в строю, но на них были остановлены все критичные службы, в том числе 1С, SQL. Базы и файлы зашифрованы.

Шары с профилями в виде SCSI и SMB зашифрованы целиком и наглухо.

TrueNAS работает, но пул уничтожен. Бэкапов больше нет. А что, кстати, с бэкапами?

Делались они по схеме 3-2-1: Veaam бэкапы фул и инкременты всего на TrueNAS, отдельно базы данных и критические данные ежедневно бэкапились на отдельный RAID. Ну и off-site backup, который цеплялся через VPN на циску и ежедневно бэкапил, опять же, через Veeam.

3 и 2 уничтожены, значит вся надежда на off-site!

Добираюсь до офсайта, обезланиваю и трясущимися руками подключаю монитор. Неужели и до него добрались, суки? Нет, живой! Смотрю бэкапы, но что я вижу?

По логам виама бэкапы делались и проходили исправно, вот только таймштамп последних успешных… январь месяц, а на календаре уже конец июня. Более того, главная база 1С датируется вообще августом прошлого года. Почти год разрыв. Это конец, катастрофа, крах. Виноват ли я в том, что просрал проверку бэкапов? Безусловно виноват и еще как. Вроде не первый год в IT, но наступил на классические грабли. В условиях ограниченных ресурсов и времени ошибки неизбежны, но это ни разу не оправдывает игнор проверки целостности резервных копий.

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

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

Исследование

Итак, масштаб разрушений ясен. Осталось понять, как с ним дальше жить.

Гружусь с PE на TS и первым делом смотрю Event Viewer. В 22.30 вижу логин с сервисного акка админа AD, который использовался для различных нужд, в том числе для авторизации по VPN через AD. Компрометация пароля? Сомнительно. Скорее поверю в фишинговое письмо или брутфорс хэша пароля из конфига дырявой циски, да это и не важно. Векторов атаки масса и мне в принципе не интересно как. Судя по датам изменения файлов, атака началась около 22:30 и была завершена уже в районе 23:00.Важно, что человеческое присутствие не прослеживается, скорее всего отработал скрипт и достаточно грязно. Налицо автоматический проход без вдумчивого анализа инфраструктуры и ценности данных.

Параллельно у провайдера заказываю детализацию трафика за несколько месяцев для изучения на предмет аплоада больших объемов данных. Все в пределах нормы, аномалий и всплесков не обнаружено. Судя по скриптовому характеру взлома, угрозы слива похожи на блеф. Если рыбачишь сетью, то заморачиваться с каждой сорной, но жирной рыбешкой просто невыгодно.

На TS запускаю скан MalwareBytes и вот оно:

C:\Windows\svchost.exe

Babuk ransomware (я всю историю называл его бабадуком по ассоциации с дебильным фильмом ужасов). Шифрует все стойким алгоритмом ChaCha20. Через сервис https://id-ransomware.malwarehunterteam.com после загрузки зашифрованного файла и письма диагноз MB подтверждается. В открытом доступе ключей не обнаружено, расшифровка невозможна. Но так как атака была проведена, скорее всего, без участия живой силы, то теплится надежда вытащить хоть какие-то данные.

Бэкап

TrueNAS – не самый плохой вариант для бэкапов. ZFS славится своей надежностью и отказоустойчивостью, но, как показывает практика, в случае уничтожения данных, восстановление – задача крайне нетривиальная.

Напомню, что на TrueNAS был развален пул из 8 дисков RAID6. Был уничтожен его конфиг, как и снапшоты. Каким-то образом также сломана SMB шара. У меня возникли подозрения, что за эту ниточку можно попытаться потянуть. В теории, преступники могли просто грохнуть пул и не заморачиваться с шифрованием самой жирной части моей инфраструктуры. Осталось «всего-то» вытянуть данные с ZFS.

Для того, чтобы собрать пул обратно необходим его кэш, который хранится по пути /etc/zfs/zpool.cache. Он не был зашифрован, но переписан и забит нулями. Стало ясно, что необходимо попытаться восстановить его во что бы то ни стало.

После нескольких часов чтения я понял, что на рынке существует совсем немного решений для работы с ZFS. Помимо кондовых zdb и zfs-dumpster фактически есть только три серьезных коммерческих утилиты: UFS Explorer, reclaime, Klennet. Их я и начал испытывать по порядку.

Первым пошел в атаку UFS Explorer. По нулям. Вторым стартанул recalime и, о чудо, он смог обнаружить zpool.cache! Подцепляю его, собираю пул и он заводится.

С мольбами к богам через shell пробираюсь на пул в репу, ввожу ls и… вижу только шару с профилями в виде .vstore, больше ничего. Но что обнадеживало, репо имел корректную структуру и ничего не было зашифровано! То ли не отработал скрипт, то ли он и не должен был сработать, да мне это, опять же, было не важно. Я видел примерно половину своих данных по объему и ценности. Проблема заключалась в другом.

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

Veeam в зависимости от типа делает бэкапы в своих проприетарных форматах. Это может быть vbm, vbk, vib или vstore в случае с smb. Первые три замечательно импортируются через Backup & Replication console, а вот четвертый не будет работать без конфига сервера VB&R, а именно – файла .bco. Интернеты и мануалы, к сожалению, не смогли ничему этому факту противопоставить, поэтому ничего не оставалось, как пытаться дальше ковырять ZFS.

К сожалению, на данном этапе пути возможности recalime исчерпались и тогда наступило время прибегнуть к последнему ПО из списка.

На просторах интернета крайне позитивно отзывается о софте Klennet ZFS Recovery. Там, где остальные коммерческие продукты показывают лапки, Klennet умудряется совершить невозможное, по крайней мере так говорили немногочисленные, но с виду вполне компетентные отзывы.

Итак, чтение документации, запуск скана и томительное сорокачасовое ожидание, но есть результат. В отличие от конкурентов найден 1.6млн файлов. Сначала я сам ничего не понял, как так, но специфика такова, что у любого специализированного ПО есть приколюхи. Klennet не исключение.

По-сути, ZFS работает транзакциями, а пул хранит данные в так называемых object sets. Каждая транзакция записывается с помощью Transaction Group Number или TXG. Файловая система может хранить данные о сотнях тысяч файлов и их версиях, но это вовсе не гарантирует их целостность. Klennet вытаскивает все эти транзакции, а дальше начинается работа на удачу.

После того, как я убедился, что софт работает, то оплатил коммерческую версию и первым делом вытащил конфиги Veeam (.bco), импортнул их в консоль и параллельно стал сливать репозиторий файловой шары на внешний накопитель. 9ТБ данных, томительные часы ожидания и первый результат. С некоторыми оговорками мне удалось восстановить почти 100% данных: все шары и терминальные профили пользователей!  Это была первая огромная победа на пути отчаяния и разочарования.

Veeam, санкции и упрямство

Сервер 1С. Около десятка баз, но самая важная и жирная – ERP, 130 гигов священных писаний, плоть и кровь компании, храм, незаменимая и неповторимая, бла-бла-бла, но последняя доступная копия годовалой давности…

Отдельные бэкапы уже не вариант, они 100% уничтожены, но ведь есть бэкапы сервера целиком на TrueNAS, а значит будем пытаться работать с ним.

К сожалению, с Klennet крайне неудобно взаимодействовать с данными, благо есть экспорт в CSV. Стартуем notepad++ и запускаем поиск по сорокамеговому файлу на 1.6млн строк. Есть номера TGX. Долго и нудно скролим на нужные цифры, запускаем CRC check, нервно ждем и видим 99% К сожалению, нет сотых и даже десятичных чисел, но и дураку ясно, что даже 99.9999% – это не 100. Бэкап сервера весил примерно 1ТБ, из них база 130ГБ. Побито какое-то количество данных, но ведь все это еще упаковано и пожато виамом. Каков шанс, что пострадали именно критические части базы? Какова вообще вероятность работоспособности? Это все рассуждения и риторические вопросы. Будем пробовать, терять уже все равно нечего.

Врубаем экспорт в Klennet, и ждем. На выходе получаем vbk, импортируем в Veeam и запускаем Guest OS File Restore. Видим всю NTFS серверной ОС, видим свои mdf. Победа? Как бы не так.

А тем временем взламывают Аэрофлот. Я снова ощущаю смесь горечи, злорадства и надежды. Ну если их тоже, то в чем я виноват? Бывает со всеми, даже с такими крупными и обеспеченными ребятами.

При попытке экспорта моей многострадальной базы я получаю ошибку: LZ4 block decompression error. CRC и прочие служебные данные. Причем ошибка была не статична, а сыпалась на разных этапах эскпорта. В лучшем случае удалось пройти треть, около 40ГБ из 130ГБ. Очень забавные ощущения: вот вроде бы лежит твоя база, ты хочешь забрать ее в любом виде, но заботливый Veeam тебе ее не отдает, потому что она corrupted, crc error, LZ4 и вообще фу-фу. Лежит груша – нельзя скушать. Стало очевидно, что единственный вариант – заставить виам перестать играть в чистоплотность и отдать данные как есть, но как это сделать? После недолгого курения форумов выяснилось, что всего-навсего необходимо обратиться в техническую поддержку Виама, чтобы они выписали тебе индивидуальный reg и dll фикс для понижения моральных ориентиров ПО. Такая практика существует и активно применяется. Есть лишь только одна проблемка: у меня нет поддержки и живу я в стране, которая не сильно котируется в западном мире.

Штош, воины не ищут легких путей. Расчехляю свои связи, пускаю сарафанное радио и выхожу на вендора, который имеет контакт с Veeam и может выписать нам официальную лицензию. Заключаем договор и создаем тикет в техподдержку. Спустя недолгое время получаем фикс в виде модифицированных дллок и правок реестра. Отныне виам больше не капризная целомудренная девочка, но бездушный инструмент, который отдает данные, как есть без гарантий. Быстрое применение хака и база у меня на руках.

MS SQL, 1C, финал

Итак, вожделенная многострадальная база на руках. Подрубаем ее через SQL Server Management Studio и в журнал сразу начинает валиться подобное:

SQL Server detected a logical consistency-based I/O error: incorrect pageid (expected 1:10053384; actual 0:0). It occurred during a read of page (1:10053384) in database ID 5 at offset 0x0000132ce10000 in file 'z:\xxx.mdf'.  Additional messages in the SQL Server error log or operating system error log may provide more detail. This is a severe error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.

База определенно повреждена, но она хотя бы подцепилась!

Выбор невелик, снача DBCC CHECKDB WITH REPAIR_REBUILD. Ошибок стало меньше, но в целом ситуация та же.

Далее DBCC CHECKDB с аргументом REPAIR_ALLOW_DATA_LOSS. База все так же указывала на потерю консистентности.

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

Итоги и выводы

Эта история ударила по всем. Были понесены серьезные убытки, нарушены бизнес-процессы, созданы невероятные неудобства и стрессовые ситуации для, так или иначе для всех, и руководства и сотрудников. 

Было принято решение вынести наглухо всю инфраструктуру и поднять заново. Шлюзы, сервера, гипервизоры – все было отправлено в утиль и организованно с нуля.

Полный отказ от Cisco и другой проприетарщины , вместо них маршрутизаторы на opnsense.

Максимальная изоляция как изнутри, так и извне, жесткое ограничение доступа к серверам и шлюзам. Любые внешние ресурсы с минимальным необходимым функционалом и за reverse proxy.

Минимальное использование AD. Посидев и подумав, я понял, что повсеместное использование домена в моем кейсе - это не необходимость, но блажь. Управлять, безусловно, удобнее, но какой ценой?

В итоге все, что может обойтись без домена – работает без домена. Это, прежде всего, все рабочие станции, которые раскатываются из подготовленного образа. По-сути, они являются тонкими клиентами до TS. Лучше изредка подключаться через условные DameWare или RustDesktop, чем постоянно параноить, что сегодня кто-то схватил очередной вирус с 0-day уязвимостью и положит тебе всю инфру. Да, на TS это можно сделать тоже, но вероятность подобного с жесткими GP и свежим defender сильно ниже.

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

Только за этот год я успел пропатчить 2 критические уязвимости MS (RDP и офис) и по одной для Veeam и ESXi. Хоть telnetd в инфре не было и на том спасибо.

Для бэкапов была пересмотрена политика мониторинга. На стример денег не дали, поэтому в схему 3-2-1 добавился дополнительный внешний жесткий диск, подключающийся напрямую к серверу. Питание подается через умную розетку. Во время еженедельного бэкапа диск включается, после выключается. Примитивно, но от автоматических атак вполне должно помочь.

В будущем есть мысль подключения какого-нить интеллектуального решения для мониторинга именно ransomware атак.

Что касается ситуации в общем, то мне повезло. Очень повезло. Разрулил чисто на упрямстве, опыте, удаче и безысходности. Мысли посетили следующие:

• ломали меня скрипткидис, скорее всего вообще юзеры RaaS. Их погубила лень. Прояви они хоть капельку больше внимательности и усердия, буквально на йоту, я бы не выплыл. Почти наверняка они даже не знали, кого взломали, не были физически в моей инфраструктуре. Ковровая бомбардировка.

• не важно, сколько у тебя бэкапов. Важна организация хранения и регулярная проверка целостности.

• от ошибок и 0-day никто не застрахован. Взламывают и майкрософт и меня и пенсионерку тетю Валю. Понятно, что у всех разные бюджеты, ответственность, подход к ИБ, но взламывают, опять же, всех, смирись. Рядовой организации невозможно выстроить неприступный бастион. Хотя бы из-за неизбежного вездесущего человеческого фактора. В текущих реалиях гораздо важнее правильно организовать тыл. Не так важно, что тебя могут сбить с ног, гораздо важнее, как быстро ты можешь подняться и вообще можешь ли. При всех панических настроениях и вбросах аэрофлот поднялся за 1 день. Кто бы что не говорил, но они красавчики. Кто был, то понимает. А кто-то банкротится и закрывается навсегда, как та британская логистическая контора с вековой историей.

• никогда не экономьте на инфраструктуре и ИБ. Это касается и владельцев бизнеса и админов. Задача первых прежде всего понимать ценность и важность IT. Сегодня часто это вообще костяк вашего бизнеса. Задача вторых – не бояться и уметь продавливать свое мнение, правильные решения и бюджеты. Цените себя и свой труд. Ни один уважающий себя специалист не станет работать с инфраструктурой из говна и палок, но и ни один руководитель не придет к вам с инициативой потратить «лишних» денег, если только их прям некуда девать.

• не паникуйте и не опускайте руки. Никогда. Поначалу любое происшествие кажется неисправимой катастрофой, но глаза боятся, а руки делают. Как показывает практика, из любой ситуации можно если не выплыть, то хотя бы очень сильно нивелировать последствия. Это был один из самых тяжелых и напряжных периодов в моей профессиональной карьере. Нервы, постоянное стороннее давление, дух на нуле. Но по итогу все это сделало меня опытнее, увереннее и сильно-сильно осторожнее, хотя даже спустя время нет-нет, да приснится кошмар по мотивам. Типичный ПТСР.

Всем безоблачного неба и серверов, коллеги.