29 апреля в 16:26

Восстановление файлов после трояна-шифровальщика

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


рис. 1

Последующие попытки запуска рабочей среды 1С также не увенчались успехом. Бухгалтер связалась с компанией, обслуживающей вычислительную технику их организации, и запросила техническую поддержку. Специалистами обслуживающей организации выяснено, что проблемы куда более масштабные, так как кроме того что файлы базы 1С Бухгалтерии 7.7 были зашифрованы и имели расширение “BLOCKED“, зашифрованными оказались и файлы с расширениями doc, docx, xls, xlsx, zip, rar, 1cd и другие. Также обнаруживался текстовый файл на рабочем столе пользователя, в котором сообщалось, что файлы зашифрованы с использованием алгоритма RSA 2048, и что для получения дешифратора необходимо оплатить услуги вымогателя. Резервное копировании 1С баз осуществлялось ежедневно на другой жесткий диск установленный в этом же ПК в виде создания zip архива с папкой 1С баз, и копия архива помещалась на сетевой диск (NAS). Так как ограничения доступа к резервным копиям не было, то вредоносное программное обеспечение имело доступ и к ним.

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

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

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

Поэтому сразу приступаем к анализу файлов, структуры которых хорошо известны. В данном случае удобно использовать для анализа DBF файлы из базы 1С, так как структура их весьма предсказуема. Возьмем файл 1SENTRY.DBF.BLOCKED (журнал бухгалтерских проводок), размер данного файла 53 044 658 байт


рис. 2

Рассматривая шифрованный DBF файл, обращаем внимание на то, что первые 0x35 байт не зашифрованы, так как присутствует заголовок, характерный для данного типа файлов, и наблюдаем часть описания первого поля записи. Произведем расчет размера файла. Для этого возьмем: WORD по смещению 0x08, содержимое которого равно 0x04C1 (в нем указан размер заголовка DBF файла), WORD по смещению 0x0A, содержимое которого равно 0x0130 (в нем указан размер одной записи в базе), DWORD по смещению 0x04, содержимое которого равно 0x0002A995 (количество записей), и 0x01 – размер конечного маркера. Решим пример: 0x0130*0x0002A995+0x04C1+1=0x0032965B2 (53 044 658) байт. Размер файла, согласно записи файловой системы, соответствует расчетному на основании информации в заголовке DBF файла. Выполним аналогичные проверки для нескольких DBF файлов и удостоверимся, что размер файла не был изменен вредоносным ПО.

Анализ содержимого DBF показывает, что небольшие файлы начиная со смещения 0x35 зашифрованы целиком, а крупные нет.


рис. 3

Номера счетов, даты и суммы изменены, чтобы не нарушать соглашения о конфиденциальности в том числе и в зашифрованном участке.

Начиная со смещения 0x00132CB5 обнаруживаем отсутствие признаков шифрования до конца файла, выполнив проверки в иных крупных файлах подтверждаем предположение, что целиком шифруются только файлы менее 0x00132CB5 (1 256 629) байт. Многие авторы вредоносного ПО выполняют частичное шифрование файлов с целью сокращения времени искажения пользовательских данных. Руководствуются вероятно тем, чтобы их вредоносный код за минимальное время нанес максимально возможный ущерб пользователю.

Приступим к анализу алгоритма шифрования


рис. 4

На рис. 4 на месте заголовков полей DBF файла присутствуют почти одинаковые последовательности из 16 байт (смещения 0x50, 0x70, 0x90), также видим частичное повторение последовательностей из 16 байт (смещения 0x40,0x60,0x80), в которых есть отличия только в байтах, где должно прописываться имя поля и тип поля.

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

Исходя из особенностей строения заголовков DBF файлов и изменений байт в последовательностях, можно сделать предположение, что шифрование выполнено посредством XOR операции над данными с неким паттерном. Также можно сделать предположение, исходя из длины повторяющихся последовательностей, что длина паттерна 16 байт (128 бит). Заголовок базы равен 0x04C1 байт, размер описания одного поля в заголовке 0х20 (32) байт. Из этого следует, что заголовок данного DBF файла содержит (0x4C1-0x21)/0x20=0x25 (37) описаний полей. На рис. 4 подчеркнуты красным фрагменты записей двух полей начиная со смещения 0x10, которые в случае 1С как правило имеют нулевые значения, кроме самого 0x10 (так как по этому смещению указывается размер поля), на основании этого можно полагать, что уже имеем 15 из 16 байт ключа шифрования 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xXX 0xAF 0x45 0x6A 0xB7.

Для нахождения последнего байта в ключе возьмем другой фрагмент этого же DBF файла.


рис. 5

На рисунке 5 обратим внимание на нулевой столбец, точнее на его нешифрованную часть, и видим, что там преобладает значение 0x20 (код пробела согласно ASCII таблицы). Соответственно, и в шифрованной части столбца будет преобладать некое одинаковое значение. Легко заметить, что это 0xFA. Для получения оригинального значения недостающего байта ключа необходимо выполнить 0xFA xor 0x20=0xDA.

Подставив полученное значение на недостающую позицию, получим полный ключ 0x97 0x99 0xE6 0xBF 0x4B 0x6C 0x77 0x76 0x3A 0x80 0x0B 0xDA 0xAF 0x45 0x6A 0xB7.

После выполнения процедуры xor операции с полученным ключом над шифрованными участками получили оригинальное содержимое файла


рис. 6

Для окончательного контроля проведем операцию расшифровки zip архива, затем распакуем архив. Если все файлы извлеклись и не возникало ошибки CRC для какого-либо файла, то можно окончательно подтвердить корректность ключа. И финальным этапом будет распаковка остальных файлов согласно технического задания.

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

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

Следующая публикация: Восстановление данных из поврежденного RAID массива в NAS под управлением Linux
Предыдущая публикация: Восстановление базы 1С Предприятие (DBF) после форматирования
Янчарский Павел @hddmasters
карма
85,0
рейтинг 118,0
специалист по восстановлению данных
Самое читаемое Администрирование

Комментарии (114)

  • +4
    Надеюсь теперь задача резервного копирования решена немного по другому?
    • +2
      Клиенту были даны рекомендации, а прислушались к ними или нет не могу знать.
      • +1
        Если стоимость восстановления оказалась не напряжной для клиента, то скорее всего были сделаны оргвыводы с раздачей люлей всем причастным и не очень и на этом всё заглохло.
        • +3
          Не будем гадать. Все равно не узнаем, как оно на самом деле.
          • +1
            Если снова обратятся к вам-я угадал.
          • 0
            а сколько стоили ваши услуги в данном случае?
            • +2
              В договоре с клиентом прописано, что информация заказчика, включая информацию о заключенном с ним договоре, не передается третьим лицам. Конкретная стоимость услуг является элементом договора.

              Если Вы хотите обратиться за услугой, то в нашей лаборатории бесплатная диагностика, на основании которой оцениваются трудозатраты, согласно технического задания, и формируется стоимость услуги. Учитывая различную сложность задач и нюансы технических заданий стоимость может варьироваться в очень широком диапазоне.
              • 0
                Нет, мне было просто был интересен примерный масштаб сумм.
      • –14
        А клиент небось на MS Windows сидит?
        • +8

          А как ещё вирус мог зашифровать все файлы базы данных 1с в виде файлов, да ещё и 7.7 версия только на windows. А если встретите бухгалтера, который сидит на линуксе и делает бэкапы — скиньте номерочек

        • +1

          Это почему? Естественно, на Solaris.

        • 0
          не, под Mac OS
          • 0
            Давайте не будем ворошить эту рану :)
    • 0
      Для бекапов использую Syncthing, с включенной версионностью. Бекапы синхронизируются на другой комп, в случае каких-либо изменений на первом, на втором создаются копии файлов с изменениями. Физически компы никак не связаны, кром поограммы синхронизатора. Еще полезно переименовывать бекапы в dll или просто убирать расширение. А у пользователей настроил, чтобы vbs и js открывались блокнотом по умолчанию.
      • 0
        Еще была идея зашифровать раздел на диске (vracrypt, truecrypt), автомонтировать его, бекапить туда базы и размонтировать обратно. Или самое простое убирать букву диска после бекапа.
        • +2
          В определенный момент раздел будет доступен не только средству бэкапа.
          • 0
            Сделать запуск средства бекапа от администратора, а всего остального от обычного пользователя и настроить права на доступ к диску с бекапом, что бы только администратор имел права на запись.
            • 0
              Дополнительные меры защиты это конечно хорошо. Но не 100% гарантия. Организуя резервное копирование нужно учесть множество различных вероятностей наступления неблагоприятных событий и продумать эффективные меры.

              Сегодня вирус шифровальщик, завтра намеренные действия обиженного увольняющегося человека, послезавтра пожар, потоп и т.п.
            • 0
              Не надо ничего бекапить от администратора. У всех кому надо должны быть права ридонли на дестинейшен (любой), а бекапить должна отдельная учетка с правами записи в дестинейшен и правами только чтения из источника. Учетка не должна использоваться ни для чего, кроме как бекапов.
        • 0
          Не так давно перешел на одну интересную утилиту — Duplicati.
          ПО по умолчанию из коробки умеет шифровать в AES-256, имеет очень приятный и понятный Web-GUI, а так же множество различных протоколов для подключения к конечному серверу, что исключает необходимость монтирования (подключения) дисков в самой системе. Ну и конечно же — инкрементное резервное копирование на закуску.
          Очень рекомендую.
  • +2
    Интересно, почему такие товарищи не используют банальный AES-GCM или какой-нибудь chacha20/xsalsa20 (который вообще реализуется тривиально и его реализаций есть в открытом доступе)? Т. е. уникальный ключ не генерируют, возможно, чтобы не держать C&C сервера, а иметь один простой константный ключ, но почему не осилили взять разумный криптопримитив?
    • +3
      Глядя на финансовые схемы работы многих авторов вредоносного ПО и на их «творения» можно сказать, что там как и в любой сфере полно дилетантов жаждущих получить быстрые деньги. Конечно кроме дилетантов есть и настоящие профессионалы пошедшие, так сказать не той дорогой.
      Полагаю, что весь секрет именно в этом.
      • +2

        Что-то мне вспомнилось приложение под андроид, предназначенное для шифрования данных, которое просто xor'ило первые 128 байт файла ключом 0x04 (1 байт, да).

        • +2
          Где-то в 2009 году встретился шифровальщик, который xor'ил файлы целиком ключом 0x30 (1 байт). Чай не один ли автор у этого ПО?
          • 0
            Скорее банальное отсутствие фантазии.
      • +11
        В моей практике зашифровали комп. Были ценные базы. Связались с автором, купили дешифровщик. А он дешифровал с ошибками. Расшифровалось все кроме нужных баз. В итоге сам автор сидел 2 дня пытался нам базу вернуть. Ничего не вышло. Обращались к специалистам, те запросили неподьемную сумму. В итоге раскопали 3 месячный бекап на другом компе. Это насчет квалификации писателей шифровальщиков.
  • +1
    И наконец последний вопрос:
    Какова сумма оплатить услуги вымогателя и специалиста по восстановлению данных?
    Если не хотите конкретную цифру указывать, скажите во сколько раз, в два, три… пришлось бы уплатить вымогателю.
    • +3
      Мне неизвестно сколько точно денег требовал вымогатель и брался бы он за решение задачи по расшифровке или просто бы тихо перестал отвечать на письма после получения средств.
    • 0
      С нас требовали, 12 тыс. руб. за комп. :(
      А файлы я смотрел, ну похоже было тоже самое, как описано в статье, причем текстовые файлы, малого размера открывались несмотря на зашифрованность :)
    • +1
      По разному. Случаи из практики.
      Я видел алгоритмы, которые срабатывали только при наличии доступа к интернету с машины-жертвы и которые после работы отправляли наружу список зашифрованного.
      Закосил под дурачка, запусти в песочнице с кучей одт, док и т.п.
      Потом связался от лица жертвы и от лица дурачка.
      У жертвы зашифровало почтовый ящик the bat!, пару тысяч документов, две базы ms access.
      Цена вопроса 2,8 btc.
      У меня было зашифровано порядка 20 тысяч документов, но была озвучена цифра в 1 btc.
      Также встречал алгоритм, который сразу указывал в txt-файле на рабочем столе условия и сумму.
      За только один файловый вариант 1с без каких либо других документов было указано 1 btc. За 100 pdf показало 0,6. Подозреваю, что оценка работает по маскам.
      А оплатить восстановление — это как повезёт. Я видел реализацию шифрования через AES, где ключ генерировался на машине-жертве, после чего ключ шифровался rsa и оставался лежать в виде шифра на диске. А вот для получения закрытого ключа надо было связаться. В этом случае, кстати, дело происходило на отрезанной от сети машине. Затащили в виде поражённого офисного документа. Расшифровать AES — сомнительное предприятие сейчас.
      Просили фиксированно. 3 биткоина.
    • 0
      В моей практике были суммы 28, 30, 12 тыс р за расшифровку вымогателю.
  • +1
    Видела комментарий к вашей предыдущей статье, где вы спрашивали о пожеланиях тем ваших заметок, поэтому не могли бы вы написать заметку с описанием процесса восстановления данных с RAID массивов, созданных средствами Linux, при условии, что в самом Linux ничего сделать не выходит?
    • 0

      Речь про mdadm? Что именно не выходит? Диски все аппаратно целые?

  • 0
    Постараюсь рассмотреть и этот случай на примере какого-либо NAS'а. Уровень рассмотрю тот который попадется под руку. Полагаю, что Вас скорее всего может интересовать именно описание суперблоков, чтобы можно было понять конфигурацию массива и прелести и недостатки LVM?
  • 0
    Всегда печалит, когда вместо бекапов есть только прошлогодние скриншоты…

    Не забывайте делать бекапы… ну и проверять их корректность…
  • +1
    Что сказать, повезло, что оказалось все проще
  • +1
    Встречался с аналогичной ситуацией. Тоже бухгалтер, тоже шифровальщик. Но так как ума у меня гораздо меньше, то в итоге подошло более простое решение (то ли нагугленое, то ли наяндексеное, не помню уже).

    Именно — восстановление данных резервной копии, заботливо сохраненных Volume Shadow Copy Service.
    • 0
      Профессионально написанные шифровальщики не менее заботливо эти теневые копии затирают. Тоже встречал в своей практике.
  • –3
    А нельзя майкрософту взяться и накатить на все виндовые машины апдейт, заставляющий хранить предыдущие версии пользовательских файлов? Шифровальщики вымрут ибо все перестанут платить.
    • 0
      Умные шифровальщики отключают shadow copies первым делом. Так что только бэкапы и подальше.
      • –2
        Дык сделать чтоб не отключалось. И юзеру во весь экран мессендж — смотри, у тебя, похоже, шифровальщик завёлся.
        • 0
          какой-то механизм отключения будет так или иначе — например через bcdedit, а значит шифровальщику просто придется подождать пока система перезагрузится…
          • –3
            Не вижу, почему нельзя сделать надёжно, если, конечно, появится желание сделать.
            • 0
              Потому что как только сделаете ЛЮБОЕ решение — оно попадет к злоумышленнику, будет найден обход и решение перестанет работать. Серебрянная пуля врядли возможна.
              • –3
                Серебрянных пуль полно. Примеры:
                1. В 90-е была эпидемия бутовых вирусов. В BIOSах появилась настройка, спрашивающая у пользователя можно ли переписать MBR / boot sector, бутовые вирусы закончились.
                2. В современных CPU просто так данные не исполнить как код.
                3. А ещё SSL/TLS для защиты трафика.

                Теперь конкретика — если операционка, от слова совсем, не будет позволять без админских прав отключать сохранение копий перезаписываемых файлов, что может противопоставить шифровальщик?

                • 0
                  Он будет ломать файлы перед записью в теневую копию, а потом сразу восстанавливать. Через некоторое время у вас в теневой копии будут сломанные файлы. После чего он окончательно сломает файлы и сообщит вам о своём присутствии.

                  Я никакого отношения не имею ни в шифровальщикам, ни к борьбе с ними. Но за 10 секунд придумал обход вашей серебрянной пули. Конечно, можно придумать защиту и от предложенного мной метода. Но это как раз и будет та самя преславутая борьба оружия и защиты, которая никогда не кончается.
                  • 0
                    даже ломать не обязательно, просто примотать скотчем пачку LPE эксплоитов.
                    • 0
                      Актуальные LPE еще иметь надо. А судя по качеству большинства шифровальщиков у них нет ресурсов, чтобы заиметь такую штуку себе.
                      • +3
                        это в теории.
                        а на практике если там десятка, то приглашенный мальчик просто открутит автообновлялку нафиг после первого же инфаркта у буха, когда в середине заполнения месячной отчетности у нее винда уйдет в перезагрузку. если там 8 и ниже — то там скорее всего и так решето, не обновлявшееся со времен появления GWX.
                  • –4
                    Хранить все версии файла, как в гитхабе. А если вдруг стало много диска отъедаться, то сразу будет видно, что завёлся шифровальщик.
                    • 0
                      Да, да. Вот вы сейчас начали придумывать обходы для предложенного мной решения.
                      Я не буду продолжать придумывать обходы для ваших новых вариантов.
                      Вы спросили, как обойти — я ответил. Дальше сами.

                      UPD:
                      Ну и не поможет хранение всех версий. Если шифровальщик проживет достаточно долго на зараженной машине — будет достаточно создано новых файлов, которые и не представлены в бэкапе в не сломанном виде.
                      • –4
                        Потому что дальше обходов нету.
                        • +2
                          Ну ладно. Я дополнил свой коммент, с объяснвнием почему ваше решение не работает. Я так понимаю будет следующее «Дальше обходов нет»…
                          Ваши утверждения на уровне детского сада. Аргументы вы не понимаете. Извольте принять минус в карму. Удачи!
                          • –6
                            1. Новые файлы изначально создаются не сломанными, с этим, я надеюсь, Вы согласитесь. А при перезаписи эти новые файлы попадут в бекап (со ВСЕМИ версиями).
                            2. Научитесь спорить на технические темы предметно и без истерик.
                            • 0
                              Детский лепет. АРгументированно спорить не буду, вижу что это бесполезно.
                              Если что-то не понятно — перечитайте то, что я уже написал.
                              • –6
                                Спасибо, достаточно. Я уже понял, что технических аргументов у Вас не осталось.
                                • +1
                                  Ну так уж и быть. Специально для вас:
                                  «Новые файлы изначально создаются не сломанными, с этим, я надеюсь, Вы согласитесь.»
                                  Не соглашусь.
                                  Делаем примитивную dll инъекцию(даже LPE и RCE не нужны) и вот у нас уже файлы изначально пишутся в ФС сбойными. Даже если у нас ФС попробует хранить историю вообще на каждое изменение файла — это не поможет.

                                  Это, я, конечно, не для вас пишу. Вам бесполезно. Это скорее для тех, кто может подумать, что я перетсла аргументировать, потому что у меня аргументов нет. Ваши высказывания можно десятью разными способами побить, просто нет смысла это делать.
                                  • –1
                                    1. В моих рассуждениях модель нарушителя (очевидным образом) следующая:
                                    — Процесс шифровальщика имеет права пользователя, но не админстратора.
                                    — ОС не имеет уязвимостей, позволяющих шифровальщику совершить что-то, на что прав пользователя не достаточно (да, на практике можно придумать кучу атак и упомянуть сотню уязвимостей, но речь не об этом).
                                    2. Научитесь себя вести.
                                    • +2
                                      1. Невозможно предусмотреть всё. Или на выходе будет нечто неюзабельно, с чем не захотят иметь дело пользователи.
                                      2. Научитесь думать.

                                      Вобще в целом вы правы. Я веду себя неадекватнее чем вы в плане личного диалога. С другой стороны вы несете такую ересь, что очень тяжело удержаться в русле диалога. Ну прям как с свидетелями Иеговы разговаривать. Долбят одну и туже ересь с милой улыбкой, а логики никакой. Ну в духе «ОС не имеет уязвимостей». Ага. Чтобы ОС не имела уязвимостей надо сделать ОС, у которого не будет уязвимостей.
                                      • 0
                                        Ещё раз, я говорю о том, как остановить шифровальшиков, работающих только под пользовательскими привилегиями. Если появились права администратора, то всё, game over, об этом и говорить нечего. Если Вам моя «ересь» непонятна, то задавайте вопросы. Но по-моему Вам просто гораздо важнее выйти из этого спора победителем, чем мне. Поэтому давайте и будем считать Вас победителем.
                                        • 0
                                          Londoner копировать всю базу 1С (как в данном случае), особенно если она расположена на сетевом диске, просто непрактично. Регулярные бэкапы, неподконтрольные юзерам, чуть исправляют ситуацию, но свежие изменения всё равно будут потеряны.

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

                                          Иными словами, патч «за всё хорошее и против всей фигни» никак не выходит. При чудовищных накладных расходах, которые он создаёт, он даже полностью задачу не решает.
                                          • 0
                                            Да, накладные расходы могут быть высокими. Частично поможет сохранение лишь дельты, а не всего файла. Но какая есть альтернатива, если бекапы делать некому, а побороть это зло централизованно надо?
                • +1
                  1. В 90-е была эпидемия бутовых вирусов. В BIOSах появилась настройка, спрашивающая у пользователя можно ли переписать MBR / boot sector, бутовые вирусы закончились.

                  насколько мне помнится данная мера могла помочь, если работа с диском велась через INT 13h, или INT 25h/26h. Если брать команды из АТА стандарта и работать с диском подключенному к IDE контроллеру через порты 1F0h -1F7h (170h-177h), то защита со стороны BIOS ничем не поможет.

                  Исчезновение данной категории вирусов в девяностых связано больше с массовым переходом на к многозадачным ОС начиная с Windows 95 и выше (более старые версии не были настолько популярными).

                  2. В современных CPU просто так данные не исполнить как код.

                  так эта мера защите полезна разве, что при атаки на какое-то ПО. Если же пользователь сам запустит тело вредоносного ПО, то подобная защита со стороны CPU не является защитой.
                  Теперь конкретика — если операционка, от слова совсем, не будет позволять без админских прав отключать сохранение копий перезаписываемых файлов, что может противопоставить шифровальщик?

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

        Мой планшет с 32 Гб SSD в чём-то с ними согласен.

      • –1
        Обычно доков и прочих экселей у пользователя немного.
        • 0
          Но кроме этого бывает и масса иных не менее ценных файлов и объемы впечатляющие.
          • 0
            Хорошо, давайте тогда сядем на попу и не будем делать ничего.
            • 0
              Зачем в крайности бросаться? Любой организации стоит продумать систему резервного копирования, которая бы исключала катастрофичную потерю данных. Чтобы в худшем случае были минимальные потери, которые бы не приводили к остановке деятельности.
              • –1
                У любой организации не получится. 90% организаций — это комп на виндуз, директор, бухгалтер и пяток работников не очень умственного труда. Некому там думать про бэкапы. С них и будут кормиться шифровальщики. Чтоб их остановить, надо чтоб ручеёк выкупов пересох раз и навсегда, для этого одна-единственная организация, называющаяся майкрософт, должна продумать за них за всех.
  • 0
    >Оценив масштаб проблемы, специалисты обслуживающей организации выполнили копирование только шифрованных файлов на отдельный накопитель и произвели переустановку операционной системы. Также из почтового ящика бухгалтера были удалены письма, содержащие вредоносное ПО.

    Очень смахивает на заметание следов, на месте этой пострадавшей компании я бы сменил обслуживающую организацию. Делетанство полное.
    • +2
      Очень смахивает на заметание следов, на месте этой пострадавшей компании я бы сменил обслуживающую организацию. Делетанство полное.


      Информации об обслуживающей организации была подана клиентом. Я предпочел бы воздержаться от навешивания ярлыков особенно, когда нет комментариев от второй стороны (обслуживающей организации). Так как в такой ситуации поспешные выводы с высокой вероятностью могут оказаться неверными.

      Учитывая, что нет информации о том, кто именно и что удалил и сделано это было по просьбе клиента или самим клиентом.
      • 0

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


        Вот если бы вы написали, что обслуживающая организация первым делом отключила ПК от сети, нажала кнопку ресет и с live-cd сделала образ hdd для дальнейшего анализа, у меня бы не возникло подозрительных мыслей.

        • 0
          Вся вводная часть до попадания файлов к нам написано со слов клиента. К сожалению на 100% она не может быть достоверной. Так как люди склонны упускать детали, особенно в вопросах, в которых не очень хорошо разбираются.

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

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

    Мне бы было еще интересно послушать какой путь проделал автор, какие книги читал, прежде чем сия мешанина из 16ричных чисел (для меня мешанина) начала для него складываться во что-то осмысленное. Спасибо.

    • +3
      Простой пусть от детского интереса к программированию (с 10 лет в 1990 году), сначала ассемблер на КР1801ВМ-1 (БК0010-01), потом ассемблер Z-80 (ZX-Spectrum). К слову первый случай восстановления данных был в 1994 году, когда перестал читаться гибкий диск 5,25 с моими трудами, тогда была изучена файловая система, которую использует TR-DOS и написаны средства для вычитывания данных, которые за давностью лет уже канули в небытье. С 1994 года ассемблер 80286. Там параллельно прорезался интерес, к тому как работают такие устройства, как накопители на жестких магнитных дисках, а также к устройству файловых систем. В общем к 2005 году хобби переросло в профессиональную деятельность.

      Книги читались в ранние годы в духе «Как написать игру на ассемблере» издательства Питер (если мне не изменят память). Остальное постигалось посредством анализа как чужого кода, так и структур.
      • 0
        TR-DOS — вот она, ОСь без уязвимостей :)
    • 0
      Рекомендую почитать все статьи Криса Касперски (Земля ему пухом!)
      Ну и еще его книги.
      Если голова не лопнет)))
    • 0
      Обычно такое возникало после пары лет «программирования» на ZX-spectrum непосредственно в кодах Z80 на встроенном отладчике (версия пзу 1990 года, да). Тяжелые девяностые, мы развлекались как могли. Дальнейшие шашни с отладчиками под дос и шиндовс (незабвенный softice!) лишь усугубляли диагноз. Сказочная надежность флоппи дисков и norton disk editor так же вносили.
      • +1
        До сих пор вспоминается MONS4D и GENS4D. И как потом радовали TASM и STS.
  • 0
    Фантазия у кулцхакеров какая-то ограниченная. Можно было при запуске приаттаченного к письму файла хотя бы показать какой-нибудь excel-ный отчет, взятый с того же компьютера бухгалтера, через поиск в «Моих документах». И запускать «шифрование» не сразу, а по таймеру, например в пятницу 13 числа или по какому нибудь событию — например при монтировании флешнакопителя.
    • 0
      Вы же понимаете, что рассмотрен частный случай, который при грозном тексте (со слов клиента), оказался вовсе не грозным шифратором. А так хватает весьма изощренного кода с не менее изощренным функционалом, который еще отловить проблема в силу того, что жертва получает дропер, который скачивает основной вредоносный код (или целую цепочку вредоносного ПО, где у каждого элемента своя задача), который после активации в нужный момент, самоликвидируется.
  • 0

    Все гораздо проще, ребятки) если у вас поработал шифровальщик, а бэкапа нет, то просто восстанавливаемся через теневые копии. По умолчанию в Шиндовс делаются вроде раз в неделю. Встает вопрос актуальности восстанавливаемой инфы, но тут как повезет. Это лучше, чем ничего. Пару раз "спасал жЫзнь" юзверям. Кстати, он не шифрует файлы почтовых клиентов где хранятся письма pst'шники. А для кого-то это самый важный файл на компе. В общем смотрим существующие теневые копии. Подрубаем, появляется папка shadows в корне и будет вам счастье)

    • 0
      Если бы все и всегда было в «теневых копиях», вопрос в том, что необходимо вести какие-либо анализы не стоял. Возможность получения данных из теневых копий рассматривается любыми системными администраторами. В нашем случае на новом носители даны шифрованные файлы и все техническое задание — восстановить.
  • 0
    Я не совсем понял, а копия на NAS тоже оказалась повреждена?
    У меня тоже есть NAS, очень боюсь такого повреждения. Подключил как сетевой диск, но от имени пользователя, которому есть доступ только на чтение, запись только в папку для торрент-задач.
    Подключение по адресу делаю от имени другого пользователя, у которого есть доступ на запись. Credentials сохранены. Я в опасности?(
    • 0
      Да, так как NAS был в сети и был доступен вредоносному ПО.
    • +1
      Я думаю, надо наоборот делать — чтобы NAS сам лазил и забирал нужные файлы себе, ну и отчёты/алармы слал кому надо.
      • 0
        Вообще он так делает, бекапами занимается служба синолоджи от имени выделенного пользователя. Не стал упоминать это, так как это нивелируется доступом от пользователя с большими правами. По идее надо сделать пользователя, у которого были бы права на всё что обычно нужно и не было прав на бекапы и служебные папки.
  • +1
    Спасибо за статью, учту на будущее, что есть и такие простые варианты ;)
    Да, был бы RSA-2048, работали б сейчас бухгалтеры…
    • 0
      Был бы RSA пришлось бы искать тело вируса. В некоторых случаях локально сохраняется копия ключей (например за пределами последнего LBA последнего раздела). Если же ключи только у злоумышленника, тогда, либо платить ему в надежде, что он снизойдет до расшифровки (чаще откажет), либо бухгалтерам заниматься восстановлением учета.
      • +1
        В некоторых случаях локально сохраняется копия ключей (например за пределами последнего LBA последнего раздела).

        Серьезно? А тело вируса зачем?
        • +1
          Чтобы понимать, что делало вредоносное ПО и есть ли все необходимое для расшифровки на накопителе жертвы.
      • 0
        А чем бы вам помогло обладание открытым ключом RSA?
        • +2
          Тем, что некоторые вирусописатели хранят все необходимое в одном месте. То есть тело-шифратор по совместительству и дешифратор. И все необходимые ключи для расшифровки тоже могут быть сохранены локально у пользователя. Всегда стоит проводить анализ, чтобы понимать с чем имеем дело.

          • 0
            Если бы злоумышленник так сделал — сохранил бы всё в одном месте — он бы не стал тогда вообще прибегать к асимметричному шифрованию, какой в этом смысл.

            Имея на один встроенный открытый ключ асимметричного шифрования и генерируя при каждом сеансе шифрования файлов новый ключ для симметричного шифра, можно зашифровать быстро все файлы, попутно сохраняя зашифрованный ключ для симметричного шифра. После этого злоумышленник может требовать деньги в обмен на расшифровку ключей. Таким образом, современные технологии шифрования позволяют поставить шах и мат обороняющейся стороне.
        • 0
          Прекрасно понимаю, что только открытый ключ нам ничего не дает.
  • +2
    Если бы злоумышленник так сделал — сохранил бы всё в одном месте — он бы не стал тогда вообще прибегать к асимметричному шифрованию, какой в этом смысл.


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

    Это никто не оспаривает. Есть вредоносное ПО, которое писали специалисты своего дела и не допускали детских ошибок.

  • –1
    А нельзя ли сделать защиту, которая будет считать энтропию каждого файла? И затем будет следить за активностью системы и перепроверять энтропию если какая-то софтина активно перебирает файлы, если один файл резко повысил / изменил уровень энтропии можно уже точно знать кто его трогал и по паре других файлов подтвердить, затем можно тормознуть процесс меняющий энтропию.
    Это как концепт, я очень далек от этой темы.
    • +1
      Концепт может и интересный, но такое ПО придется многому научить. В частности отличать данные создаваемые различными алгоритмами компрессии данных от шифрованных данных, так как при общей оценке энтропии у них определенно будет сходство.
    • 0
      Проще обычную защиту в виде разграничения прав и SRP настроить, чем городить такую софтину, не говоря про ресурсы нужные для такой софтины.
      • 0
        Проще наверное усвоить, что как бы не работал над защитой данных системный администратор, всегда найдется пользователь, либо неблагоприятные обстоятельства (не только вирус шифратор), которые приведут к потере данных.

        По этой причине, ко всем мерам защиты добавить и выверить процедуры резервного копирования и продумать, как реализовать создании копий критически важных данных так, чтобы застраховаться от максимально возможного количества неблагоприятных явлений.
        • 0
          Так мы не про бэкапы, а про защиту от шифровальщиков, бэкапы самом сабой. Да и насколько я помню там тоже есть пару основных правил, которые спасут в большинстве случаев:
          Хранить отдельно и делать от отдельного пользователя. В самом простом случае как писал: «Сделать запуск средства бекапа от администратора, а всего остального от обычного пользователя и настроить права на доступ к диску с бекапом, что бы только администратор имел права на запись.» Но лучше создать отдельного пользователя с нужными правами, и использовать его только для бекапов.
          • 0
            Забыл. Второе правило не про пользователей в часности. А про то, что бэкапы надо делать из вне, чтобы доступ был только односторонним, и инициатором должен быть сервер, а не клиент. Написал может и сумбурно, но я думаю меня поймут.
    • 0
      Ну и к слову обход такой защиты. Открываем два процесса. Первый приступает к шифрованию, второй следит за первым. По мере остановки защитой первого процесса, второй открывает третий процесс и начинает выполнять задачи первого процесса, третий процесс получает роль второго процесса. И так в цикле.
      • 0
        Бэкап сам по себе не спасет от такой напасти, можно сделать так чтобы бэкапились уже зашифрованные файлы. Эту мысль про анализ энтропии я как раз где-то из темы бэкапа подчерпнул, кстати.
        Думаю, как и всегда, комплексный подход нужен, чтобы снизить шанс заработать для криптовымогателей.
        • 0
          Упс, ответ на меры по резервному копированию.
          • 0
            Именно. Полумерами не обойтись. Нужен комплексный подход. Рассмотрение различных потенциально возможных проблем и комплекс мероприятия по упреждению проблем или минимизации потерь.
  • 0
    Ламера пост в данном вопросе, но активно интересующегося:
    Тело шифратора пишется как правило в Temp'ах и/или в реестре? Или полный рандом, куда больше нравится автору?
    Из опыта: пару раз приносили технику с подобной дрянью на борту, не являясь специалистом в данном вопросе заканчивалось переустановкой ОС (благо из «важных» данных — сохранения игр. Частные просьбы друзей и знакомых). Снимал образ акронисом, потом один раскатил на тестовой машине без доступа к интернету, курение мануалов и нолуночный гуглеж не принес результатов. За неимением времени забросил затею, но иногда все же собираю информацию из разных источников, дабы однажды победить свой первый шифратор )
    • 0
      Тело шифратора может быть в виде отдельного файла, а также может никогда не сохраняться на накопитель и отработать находясь исключительно в памяти компьютера. На все воля автора ПО. В реестре ОС авторы вредоносного ПО обычно прописывают ключи для запуска трояна после перезагрузки ПК.
  • 0
    Спасибо за статьи! Зачитаться можно!
    Из пожеланий к новым статьям… хочется, что бы Вы рассказали не только истории восстановления и спасения утопающего, но и может попробовали например серию статей о Вашем ремесле. Не обязательно технического содержания. Еще с удовольствием почитал бы уроки по восстановлению данных в домашних условиях. Рекомендации по диагностике и правильным действиям в случае подозрения на отказ запоминающего устройства. Скажем так… как успеть принести к Вам чтобы с большей вероятностью и с меньшими трудо/деньго затратами спасти данные.
    С нетерпением жду следующих публикаций!
    • 0
      По методам диагностики устройств планируются некоторые заметки, но скорее всего они разместятся на официальном сайте, так как это достаточно частый вопрос клиентов. Да и на хабрахабр вроде нет подходящего хаба для такой тематики.

      В частности уже положено начало выкладыванию этих материалов. Например ознакомление с устройством SMART (как происходит взаимодействие с жестким диском, как интерпретируются параметры параметры утилитами, как формируется состояние SMART status и за какими атрибутами лучше вести наблюдение, чтобы своевременно успеть предпринять меры.

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

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

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

      Наглядный пример в комментариях к одной из публикаций
      • 0
        Коменты к статьям все читал:) Теперь вот поизучаю статьи с Вашего сайта.
        Про устройства файловых систем конечно можно почитать в вики, но уроки по изучению ФС, в целях дальнейшего восстановления информации, я думаю будут интересны.
        • 0
          На сайте много интересного, но вот еще бы к ним картинки… Зрительно информация лучше заходит. Особенно в FAQ не хватает картинок.
          Не придираюсь, просто пожелание :)
  • 0
    но уроки по изучению ФС, в целях дальнейшего восстановления информации, я думаю будут интересны.


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

    Учитывая малый интерес к подобным материалам не вижу смысла их плодить.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.