◆IKORG
English

← Практика · 22 октября 2026

Восстановление сервера после шифровальщика: офис за выходные

Как заново подняли Windows Server, 1С и офисную сеть, закрыли внешний RDP и вернули сотрудникам доступ к работе после атаки.

12 минут чтениясервер

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

Восстановление разделили на две задачи: вернуть рабочую инфраструктуру и восстановить учёт. Первую закрыли за выходные. Основное восстановление 1С заняло примерно неделю. По оценке руководителя, удалось вернуть около 80% данных и больше — это приблизительная оценка, а не результат измерения. Часть работы с путевыми листами ещё продолжается.

Здесь рассказываем про сервер, удалённый доступ, общие папки, сканирование и печать. История восстановления учёта — в главном кейсе серии. Работу поделили так: руки — на месте, голова — удалённо. Новый сервер и диски делал на месте специалист IKORG, а ИИ-агент Claude Code вёл его по шагам через мессенджер. С сетью и MikroTik помогал отдельный специалист. 1С, учётные записи, общие папки и аудит ИИ-агент настраивал удалённо, под контролем владельца студии. Действия записывали в журнал, разрушительные операции требовали решения руководителя.

Что произошло с сервером и почему пропали резервные копии?

До атаки работал Windows Server 2019 в рабочей группе, без домена. RDP был открыт в интернет. Злоумышленник вошёл под учётной записью сотрудника, под которой работала и служба 1С. По предположению руководителя, вошли через компьютер этого сотрудника. По его же словам, в журнале безопасности было около 4 600 попыток входа по RDP примерно за два часа. Затем связь с сервером пропала, к утру данные оказались зашифрованы. Ещё атакующий сменил пароль администратора.

Файлы получили расширение .aes. Использовался вымогатель семейства Cripton7zp, бесплатного дешифратора для него не было. На двух NVMe-SSD в RAID зашифровали рабочую систему, архивы 1С и СБИС, документы, таблицы, PDF. Шифрование было выборочным: обработки 1С с расширением .epf и папки программ уцелели.

Отдельный WD Red на 2 ТБ считался резервным диском, но стоял внутри того же сервера. Копии на нём зашифровали вместе с основной системой. Получился запасной ключ, который хранили в той же запертой квартире. Пострадала и копия на компьютере сотрудника. На дисках не нашли ни одного живого файла базы .1CD или .dt, теневых копий тоже не оказалось. По словам руководителя, от баз в исходном виде остались только конфигурации.

Со слов руководителя, позднее по FTP также подобрали пароль администратора и зашифровали его файлы. Сведения об этом эпизоде — именно его сообщение. При этом уже установленное сочетание открытого внешнего RDP и личной учётной записи для службы создавало опасность.

Уцелевшие папки программ могли обнадёжить, но установленная 1С, её конфигурация и база с рабочими документами — разные вещи. Программа запускается, а учёт всё равно приходится восстанавливать.

Что делать с заражёнными дисками после шифровальщика?

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

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

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

Заражённые диски изъяли, новый сервер поставили на новый M.2-диск. Так запуск рабочей среды отделили от исследования старых носителей. Больше не требовалось решать судьбу оставшихся данных только ради места под Windows.

Как прошла установка Windows Server 2025 и 1С?

В ночь на воскресенье Windows Server 2025 поставили на новый диск — на месте, с подсказками ИИ-агента в мессенджере. Дальше удалённо подняли 1С 8.5 и MS SQL Server, разместили бухгалтерию, отраслевую базу перевозчика, ЗУП и ещё одну базу.

Параллельно возвращали доступ сотрудников, общие файлы, принтеры и приём сканов. Для офиса установка заканчивается не на экране приветствия Windows, каким бы жизнерадостным он ни был. Результат — когда можно открыть базу, получить документ, сохранить файл и распечатать его.

Вместе с системой меняли правила удалённого доступа и проверяли безопасность. Чистая Windows со старым открытым RDP оставила бы прежнюю точку входа.

К понедельнику сотрудники работали на новой инфраструктуре, а восстановление документов продолжалось. Это разные рубежи: сервер уже доступен, но в базе ещё есть пропуски за потерянный период. Выходные ушли на возвращение офиса к работе, а не на полное восстановление всех данных.

Как защитить RDP-соединение после взлома?

Сначала убрали прямой доступ из интернета: на MikroTik выключили проброс порта RDP. На сервере брандмауэр разрешал подключения к порту 3389 только из локальной сети и пулов VPN.

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

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

Смена пароля — лишь часть работы. Нужно проверить, кто может добраться до службы, каким учётным записям разрешён вход и какие временные доступы остались. Здесь внешнюю доступность ограничили и на маршрутизаторе, и на сервере, а административный канал отделили от подключений сотрудников.

Как устроили VPN на MikroTik для сотрудников?

Раньше использовался PPTP. После атаки начали переход на L2TP/IPsec и подготовили сотрудникам готовые файлы настройки подключения. На момент описания кейса переход продолжался.

Настройки VPN на MikroTik должны работать вместе с правилами Windows Server. Сообщение об успешном подключении — промежуточный результат. Следом проверяют, доступен ли сотруднику нужный ресурс и закрыт ли доступ для посторонних подключений.

В связке L2TP/IPsec трафик защищает IPsec. Поэтому настройка L2TP/IPsec Server на MikroTik охватывает туннель, его защиту, учётные записи и разрешённые подключения. Назначение связки описано в документации MikroTik.

Готовые файлы избавляют сотрудников от ручной настройки подключения. Права на папки и удалённый рабочий стол задаются отдельно: вход в офисную сеть не должен открывать все данные компании.

Как восстановили общие папки и сканирование в сетевую папку HP?

Для бухгалтерии и логистов создали общие папки для сканов, права назначили по группам. Сканируют в них два МФУ HP — один у бухгалтерии, другой у логистов. Так доступ привязан к рабочим задачам: состав группы меняется, правила для папки остаются понятными.

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

Сканирование в сетевую папку HP проверяют по всей цепочке: документ прошёл через МФУ, файл появился в нужном месте, сотрудник его открыл. Проверка сетевого соединения охватывает лишь часть пути. Устройству нужны права на запись, человеку — на чтение.

Общие файлы вернули из облачной копии на Яндекс.Диске. Объём составлял около 129 ГБ: полная копия и три добавочных. Документы удалось вернуть благодаря источнику вне сервера, когда внутренний резервный диск уже был зашифрован.

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

Как подключили сетевые принтеры после переустановки сервера?

В офисе пять сетевых устройств: МФУ HP у бухгалтерии и логистов и принтеры Kyocera в двух других отделах. Печатают по IPP. Адреса устройств ещё предстоит закрепить на маршрутизаторе — задача стоит в списке. А на сервере отключили перенаправление принтеров клиентов в RDP-сессиях: у 25 сеансов были свои принтеры, и список печати на сервере разрастался без всякой пользы.

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

Печать и сканирование проверяют отдельно, даже на одном МФУ. Напечатанный документ подтверждает работу печати; отправка скана в общую папку требует собственной проверки.

При восстановлении офиса эти задачи легко отложить до лучших времён — сначала ведь 1С. Но без печати и сканирования сотрудники теряют время на обычных документах. Проверка повседневных операций входит в возвращение сервера к работе.

Что проверили аудитом и как настроили бэкапы?

После установки проверили учётные записи, RDP, брандмауэр, исключения Defender, политику паролей, автозапуск и следы AnyDesk. Это перечень проверок, а не найденных нарушений: аудит нужен, чтобы разобраться в настройках и оставшихся способах доступа.

Временной административной учётной записи подрядчика заранее назначили срок, и в этот срок её отключили по плану: сменили пароль, убрали из администраторов и из RDP. Входов под ней не было. Срок лучше назначать сразу: после срочных работ человеческая память обычно уже занята следующими срочными работами.

Ночные резервные копии SQL делает программа резервного копирования администратора 1С, и они проходят — это проверили. Из-за нехватки места на диске выбрали модель восстановления SIMPLE. У компромисса есть цена: в SIMPLE нельзя восстановить базу на произвольный момент между резервными копиями с помощью цепочки резервных копий журнала транзакций. Ограничение описано в документации Microsoft.

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

Ночные копии SQL идут. Дальше требуется контролировать место хранения, права на удаление и возможность восстановить базу. Задание в расписании подтверждает только настройку: пригодность копии и её способность пережить повторный взлом проверяют отдельно.

Почему восстановление 1С продолжалось после запуска офиса?

Сервер вернул среду для работы, а потерянные документы приходилось собирать из сохранившихся источников. Отраслевую базу подняли из старой копии примерно на конец апреля. Май–сентябрь заполняли заново.

Около 2 500 реализаций из бухгалтерии превратили в заявки, акты и счета-фактуры. Банковские поступления разбирали и связывали с заявками. Для восстановления бухгалтерии использовали книги продаж, распознанные сканы и документы электронного документооборота. В ЗУП дозаводили кадровые данные.

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

Дубли, нумерация и сопоставление оплат требовали отдельной проверки. Этому посвящена статья о документах и банковских выписках в 1С. Доступность инфраструктуры проверяют одними способами, достоверность восстановленного учёта — другими.

Ошибки, которые стоят дороже всего

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

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

Оставить RDP открытым в интернет. Здесь он стал путём входа атакующего. После восстановления выключили проброс и ограничили источники подключений в брандмауэре. Помимо смены пароля нужно пересмотреть доступность службы.

Запускать службу 1С под учётной записью живого человека. Так служебная работа оказывается связана с персональным доступом. Службам нужны отдельные учётные записи с необходимыми правами. В исходной системе этого разделения не было.

Чистить Temp учётной записи, под которой работает сервер 1С. Удаление используемых временных файлов может вызвать ошибку «Файл не обнаружен …v8_*.tmp». При такой причине помогает перезапуск rphost. Он затрагивает рабочие процессы — перед запуском нужно учесть последствия для пользователей.

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

Что делать, если вас зашифровали этой ночью?

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

Руководителю пригодятся два списка: что уже работает и что ещё не восстановлено. Так доступный рабочий стол не превратится в преждевременную отметку о завершении, а разбор последнего документа не задержит запуск офиса.

Частые вопросы

Можно ли расшифровать файлы с расширением .aes?

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

Можно ли восстановить сервер за выходные?

В этом случае к понедельнику сотрудники работали на новом сервере. Основное восстановление 1С заняло примерно неделю, часть документов восстанавливали позднее. Это срок конкретной работы; в другом случае он зависит от состояния системы и сохранившихся источников.

Помогает ли RAID от шифровальщика?

RAID не заменяет отдельную резервную копию: доступные системе файлы остаются доступны для шифрования. Здесь пострадали данные на двух NVMe-SSD в RAID. Для восстановления нужны независимые пригодные источники.

Достаточно ли установить Windows Server 2025 вместо старой системы?

Нет. После чистой установки нужно проверить доступы, службы, учётные записи, сетевые правила и резервное копирование. Здесь вместе с системой восстановили офисные функции и закрыли внешний RDP.

Можно ли поручить восстановление ИИ-агенту?

Здесь Claude Code работал под контролем владельца IKORG, с журналом действий. Разрушительные операции требовали решения руководителя, спорные данные подтверждали ответственные сотрудники. Контроль доступа и человеческая проверка оставались обязательной частью работы.

Нужно поднять сервер и офис после атаки?

IKORG помогает восстановить серверную среду, доступ сотрудников, 1С, общие папки, сканирование и печать. ИИ-агент работает под контролем владельца студии, с журналом действий и согласованием разрушительных операций.

Если сервер зашифрован или офис работает частично, напишите нам. Опишите, что перестало работать и какие копии сохранились. Разберём доступные источники и определим порядок восстановления инфраструктуры и данных.