Атака шифровальщика на офис в Москве: реальный кейс восстановления

Меня зовут Семёнов Евгений Сергеевич, и я — директор компании АйТи Фреш. Моя работа — уже 15 лет заниматься IT-инфраструктурами для малого и среднего бизнеса здесь, в Москве. За все эти годы мне, к сожалению, не раз приходилось тушить настоящие «пожары» после атак шифровальщиков. Один из таких случаев, очень показательный, произошёл совсем недавно, этой зимой. Под удар попал офис торговой компании, где было 32 рабочих места. Я хочу подробно рассказать вам, как к ним проник ransomware, что мы сделали, чтобы локализовать инцидент, как удалось восстановить 1С и файловый сервер, и, конечно, какие шаги мы предприняли, чтобы подобное больше никогда не повторилось.

Звонок в субботу утром: что мы увидели

Тот субботний звонок поступил ровно в 9:42. Бухгалтер пришла в офис, чтобы сдать срочный отчёт, но так и не смогла открыть базу 1С. Что же она увидела? На рабочем столе сервера лежал текстовый файл DECRYPT_README.txt, а в нём — требование в 5 BTC за расшифровку. Все файлы, как назло, получили новое расширение .locked2026. Уже через 40 минут я был на месте — компания, к счастью, арендует офис на Преображенке, так что ехать мне было совсем недолго.

Картина была классическая для атак на малый бизнес. Зашифрованными оказались:

• Сервер 1С на Windows Server 2019 — база торговли (180 ГБ) и зарплаты (12 ГБ)
• Файловый сервер на Windows Server 2016 — общие папки бухгалтерии, отдела продаж, юристов (общий объём 1.4 ТБ)
• 14 рабочих станций из 32 — те, что были включены в пятницу вечером и подключены к сетевым папкам
• Бэкапы на NAS Synology — атакующие зашли по SMB-учётке и зашифровали последние 30 снапшотов

Но что же всё-таки уцелело? Скажу так: это было наше спасение. Осталось облако «Яндекс 360», где размещалась почта, CRM тоже была в облаке. И, что самое ключевое, удалось найти внешний USB-диск. Офис-менеджер, как по расписанию, раз в неделю, по пятницам, подключал его и копировал на него самые критичные данные. Большая удача: последняя копия оказалась от 14 февраля — это всего за 6 дней до того, как произошла атака.

Хронология атаки: как они вошли

Прежде чем бросаться что-то восстанавливать, я всегда выделяю несколько часов на форензику. Это крайне важно, ведь от того, где именно была точка входа, зависит буквально всё. Сможем ли мы дальше пользоваться текущей инфраструктурой или придётся сносить всё под ноль и переустанавливать с нуля? Журналы Windows Security на контроллере домена чётко показали нам вот что:

1. Февраль, среда, 02:14 — успешный вход через RDP с IP-адреса в Нидерландах под учёткой admin с паролем Admin2024!. До этого — 3 870 неудачных попыток за месяц с разных IP.
2. 02:18 — атакующий поднял RDP с сервера 1С на остальные серверы (та же связка admin/Admin2024! работала везде).
3. 02:25 — выгрузка ntds.dit через теневую копию, унос на внешний сервер. Это значит, что хеши паролей всех доменных пользователей теперь у атакующих.
4. 02:40 — четверг 23:50 — тишина. Видимо, изучали инфраструктуру и продавали доступ.
5. Пятница, 22:30 — заход уже под другой учёткой администратора, остановка служб 1С, удаление volume shadow copies через vssadmin delete shadows /all.
6. 22:55 — запуск шифровальщика на серверах. Файлы шифровались около 4 часов.
7. 03:10 субботы — заход на NAS Synology через SMB и шифрование снапшотов.

Знаете, главная причина всего этого инцидента оказалась до смешного банальной: порт 3389 был просто проброшен напрямую в интернет на роутере MikroTik. До нас этим офисом занималась «команда из двух человек по абонентке 18 000 руб./мес». Они открыли такой доступ, цитирую, «чтобы директор мог работать из дома». И что вы думаете? Никаких VPN, никакой MFA, никаких ограничений по IP, да и политики блокировки аккаунтов просто не существовало. А пароль Admin2024! давно уже «засветился» во всех мыслимых утечках. Мы, конечно, потом проверили через haveibeenpwned — он там числится с 2024 года. Просто безалаберность.

Первые 4 часа: изоляция и сбор доказательств

Когда случается критичный инцидент, самое главное — не наделать ещё больших ошибок. Я вот что скажу: никогда не перезагружаю заражённые серверы, пока не соберу всю форензику. Почему? Потому что это просто уничтожит важные данные в RAM и сотрёт часть журналов. Мы действовали строго по такому плану:

• 11:00 — физически отключили офисный роутер от интернет-провайдера. Если атакующие ещё внутри, они должны потерять связь.
• 11:15 — отсоединили зашифрованные рабочие станции от сети, не выключая.
• 11:30 — сделали посекторные образы дисков серверов 1С и файлового через FTK Imager на внешний SSD 4 ТБ. На случай, если что-то пойдёт не так с восстановлением — у нас будет точная копия для повторных попыток.
• 13:00 — собрали Windows Event Logs (Security, System, Application) с обоих серверов и контроллера домена в одну папку EVIDENCE_2026-02-20.
• 14:30 — позвонил клиенту и предложил план: не платить выкуп, восстанавливать из последней внешней копии + текущих данных в облаке + ручное добивание.

Бухгалтер, конечно, плакала, директор сидел молча, а я спокойно, но твёрдо всё объяснял. Подумайте сами: простой фирмы всего лишь за один день — это около 240 000 руб. упущенной выручки. Восстановление, по моим подсчётам, займёт 3–5 дней. А платить выкуп? Во-первых, это совсем не гарантия — атакующие часто просто исчезают с деньгами. Во-вторых, после оплаты вас почти наверняка взломают повторно. И в-третьих, 12 миллионов — это, на минуточку, их годовой бюджет на нормальное IT-обслуживание. В итоге они согласились на восстановление, и это было верное решение.

Восстановление сервера 1С: первый приоритет

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

Наш план был таков: сначала поднимаем чистый Windows Server 2022 на свободной виртуалке нашего гипервизора Proxmox. Потом разворачиваем туда чистую платформу 1С 8.3. Затем восстанавливаем базу из внешней резервной копии от 14 февраля. Ну а дальше — вручную догоняем и добиваем все операции за те 6 дней, что были потеряны.

1. Сб 18:00 — установили Windows Server 2022 + патчи, подключили в новый домен company.local (старый домен считаем скомпрометированным, поднимать его нельзя).
2. Сб 21:00 — установили платформу 1С 8.3.24 + сервер 1С + MS SQL Server 2022 Standard.
3. Сб 23:00 — восстановили базу торговли из .dt файла на USB-диске. Загрузка 180 ГБ заняла 6 часов.
4. Вс 06:00 — база поднялась, проверили целостность через Конфигуратор → Тестирование и исправление. Результат — OK.
5. Вс 09:00 — позвонил директору, договорились, что бухгалтерия с 11:00 садится восстанавливать операции 14–19 февраля по бумажным накладным и выпискам банка из «Сбер Бизнес».
6. Вс 11:00 — Пн 19:00 — три бухгалтера и оператор отдела продаж вручную внесли 1 247 документов реализации, 312 поступлений, 89 платёжек. Не идеально, но работа возобновилась.

База зарплаты, к счастью, восстановилась гораздо проще. Расчёт за февраль ещё не успели закрыть, так что потеря 6 дней оказалась совсем некритичной. Все нужные данные из кадровой системы и табелей, как выяснилось, лежали на бумаге у HR-отдела.

Файловый сервер: компромисс между скоростью и полнотой

1.4 ТБ файлов! Представьте себе: это договоры, фотографии товаров, маркетинговые макеты, юридические документы, накопленные за 8 лет работы. На внешнем USB-диске, конечно, была копия от 14 февраля, но, увы, не полная. Там лежали только папки бухгалтерии и юристов, а вот маркетинг и фото товара бэкапить было, как мне сказали, «дорого по диску».

Мы не стали терять времени и пошли сразу двумя параллельными путями. Первым делом, мы подняли новый файловый сервер на Windows Server 2022 и развернули на него всё, что удалось спасти с USB-диска. Это дало нам примерно 60 % данных, пусть и с давностью в 6 дней.

Второе, и это было невероятно, — мы попробовали восстановить данные из теневых копий прямо на самом NAS Synology. Атакующий, конечно, зашифровал основные данные и снапшоты, которые лежали на общем доступе. Но, как оказалось, штатная функция Synology BTRFS Snapshot Replication хранит снапшоты на совершенно отдельной квоте. И шифровальщик до неё просто не добрался! Он работал по SMB и элементарно не видел эти данные. Мы смогли вытащить снапшот от 19 февраля 23:30 — то есть всего за 30 минут до начала атаки. В нём оказалось 92 % всех файлов, причём в самом актуальном состоянии. Это была просто огромная удача и, одновременно, бесценный урок: NAS с правильно настроенными снапшотами на BTRFS — это, скажу я вам, очень серьёзный рубеж защиты!

Полностью восстановились мы к среде, всего через 4 дня после того инцидента. Потери данных оказались минимальными, по нашей оценке, это всего 0.3 % файлов — в основном, отдельные документы, созданные в пятницу 19 февраля и просто не успевшие попасть в последний снапшот.

Что заменили в инфраструктуре после восстановления

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

Бэкап-стратегия 3-2-1 на практике для офиса 30 РМ

После всего этого инцидента я ещё раз убедился: если бэкап доступен из той же сети, что и боевые серверы, то это, по сути, иллюзия бэкапа. Шифровальщик спокойно зашёл по SMB и без проблем уничтожил все снапшоты на NAS. Поэтому правило 3-2-1 для офиса, где до 50 РМ, я теперь расшифровываю вот как:

• 3 копии данных: оригинал на сервере + копия на NAS + копия в облаке Yandex Cloud Storage / Selectel S3
• 2 разных типа носителей: SSD/HDD в офисе + объектное хранилище в облаке
• 1 копия офлайн: внешний HDD на 8 ТБ, который умная розетка Sonoff включает раз в неделю на 4 часа в воскресенье. Шифровальщик физически не может зашифровать диск, который выключен.

Для базы 1С я всегда настраиваю Veeam Agent отдельно: ежедневный инкремент и еженедельный фулл. И самое главное — каждый месяц мы обязательно делаем тест восстановления на отдельном стенде. И это не просто «проверим, открывается ли файл», нет! Это полноценное поднятие базы и контрольный запрос: «сколько контрагентов?», «сколько проводок за прошлый месяц?». Если цифры сходятся — значит, бэкап рабочий. Этот тест занимает у инженера всего 2 часа в месяц, но, поверьте мне, это лучшая страховка из всех, что существуют.

Сколько стоила компании эта история и сколько стоила бы профилактика

Давайте посчитаем по факту. Прямые потери торговой компании от инцидента:

• 4 дня частичного простоя — упущенная выручка ~860 000 руб.
• Сверхурочные бухгалтерии (3 человека по 4 дня) — 95 000 руб.
• Наша работа по восстановлению (320 часов команды из 4 инженеров) — 540 000 руб.
• Закупка нового оборудования (внешний SSD, 2 диска для NAS, лицензия Kaspersky) — 78 000 руб.
• Лицензии Veeam Agent + объектное хранилище в Yandex Cloud за год — 47 000 руб.
• Репутационный ущерб у двух крупных клиентов, попросивших отчёт об инциденте, — оценить трудно

Итого только в деньгах — около 1.62 млн руб., и это без учёта репутации.

А теперь давайте подумаем: сколько бы стоила профилактика, если бы этот офис изначально обслуживали нормально? Наш тариф «Стандарт» в АйТи Фреш для офиса на 32 РМ с одним сервером 1С и файловым — это 96 000 руб./мес, или 1.15 млн в год. И в эту сумму уже входят: VPN с MFA, антивирус Kaspersky, грамотные бэкапы по схеме 3-2-1, постоянный мониторинг, плановые обновления Windows и 1С, а также обучение сотрудников. То есть, один год нормального аутсорсинга обходится значительно дешевле, чем всего один инцидент с шифровальщиком. Разница, как говорится, налицо.

Чек-лист: как понять, что ваш офис под угрозой ransomware

Если у вас офис в Москве, и хотя бы один из пунктов, что я перечислю ниже, про вас — то, друзья мои, пора действовать! Не ждите того самого субботнего звонка:

• Порт 3389 RDP проброшен в интернет (даже если «на нестандартный порт» — это не защита)
• У админов один пароль на все серверы, и пароль не менялся больше года
• Бэкапы хранятся только на том же физическом сервере или NAS, доступном по SMB всем
• Нет ни одной офлайн-копии (внешний диск, лента, выгрузка в облако)
• Антивирус «бесплатный» или установлен «когда покупали ПК»
• Никто не помнит, когда последний раз тестировали восстановление из бэкапа
• Сотрудники не отличают фишинговое письмо от настоящего
• Windows Server старше 2019 без последних обновлений
• Сетевое оборудование (роутер, NAS) с прошивкой 2-летней давности

FAQ — частые вопросы по ransomware

Стоит ли платить выкуп шифровальщику?

Нет. По данным ФБР и CISA, 20 % заплативших не получают рабочий ключ, 80 % подвергаются повторной атаке в течение года. Кроме того, финансирование преступников запрещено законодательством ряда стран. Лучше вкладывать деньги в восстановление и защиту.

Как защитить офис в Москве от ransomware?

Базовый минимум: убрать RDP из интернета и пускать админов только через VPN с MFA, использовать офлайн-копию бэкапа (3-2-1), включить EDR/антивирус с поведенческим анализом, обновлять Windows Server и 1С регулярно, обучить сотрудников распознавать фишинг.

Сколько стоит восстановление после шифровальщика?

Для офиса 25–35 рабочих мест с одним сервером 1С — от 280 000 до 850 000 руб. в зависимости от состояния бэкапов и масштаба шифрования. В нашем кейсе расходы на восстановление и hardening составили около 620 000 руб., тогда как выкуп просили 5 BTC (~12 млн руб. на тот момент).

Можно ли восстановить базу 1С после шифрования?

Только из бэкапа. Расшифровать сами файлы DT/CD без ключа атакующего практически невозможно — современные шифровальщики используют AES-256 или ChaCha20. Если бэкапа нет, остаются дорогие услуги лабораторий восстановления данных, и то с шансом 10–30 %.

Сколько занимает полное восстановление офиса после атаки?

Без подготовки — от 4 дней до двух недель. С готовым DR-планом и регулярно проверяемыми бэкапами — 4–8 часов. В нашем кейсе мы вернули критичные сервисы (1С и файловый) за 36 часов, остальное — за 4 дня.