Pull to refresh

Comments 115

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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


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

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

А нельзя ли сделать защиту, которая будет считать энтропию каждого файла? И затем будет следить за активностью системы и перепроверять энтропию если какая-то софтина активно перебирает файлы, если один файл резко повысил / изменил уровень энтропии можно уже точно знать кто его трогал и по паре других файлов подтвердить, затем можно тормознуть процесс меняющий энтропию.
Это как концепт, я очень далек от этой темы.
Концепт может и интересный, но такое ПО придется многому научить. В частности отличать данные создаваемые различными алгоритмами компрессии данных от шифрованных данных, так как при общей оценке энтропии у них определенно будет сходство.
UFO just landed and posted this here
Проще наверное усвоить, что как бы не работал над защитой данных системный администратор, всегда найдется пользователь, либо неблагоприятные обстоятельства (не только вирус шифратор), которые приведут к потере данных.

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

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

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

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

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

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


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

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

Спасибо за отличную статью. Что придумал после атаки шифровальщика, к счастью без последствий: установлен дополнительный сервер на Linux, на который по крону копируются бэкапы, и который никак не виден из основной системы.

Sign up to leave a comment.

Articles