Масштабная атака программы-вымогателя ESXiArgs нацелена на серверы VMware ESXi по всему миру
Администраторы, хостинг-провайдеры и Французская группа реагирования на компьютерные чрезвычайные ситуации (CERT-FR) предупреждают, что злоумышленники активно нацелены на неисправленные серверы VMware ESXi против уязвимости удаленного выполнения кода двухлетней давности для развертывания новой программы-вымогателя ESXiArgs.
Уязвимость, отслеживаемая как CVE-2021-21974, вызвана проблемой переполнения динамической памяти в службе OpenSLP, которая может быть использована злоумышленниками, не прошедшими проверку подлинности, в атаках низкой сложности.
«По данным текущих расследований, эти кампании атак, по-видимому, используют уязвимость CVE-2021-21974, исправление для которой доступно с 23 февраля 2021 года», — говорится в сообщении CERT-FR.
«В настоящее время целевыми системами будут гипервизоры ESXi версии 6.x и ранее 6.7».
Чтобы блокировать входящие атаки, администраторы должны отключить уязвимую службу протокола определения местоположения службы (SLP) на гипервизорах ESXi, которые еще не были обновлены.
CERT-FR настоятельно рекомендует установить исправление как можно скорее, но добавляет, что системы, оставшиеся без исправлений, также следует сканировать на наличие признаков компрометации.
CVE-2021-21974 влияет на следующие системы:
ESXi версии 7.x до ESXi70U1c-17325551
ESXi версии 6.7.x до ESXi670-202102401-SG
ESXi версии 6.5.x до ESXi650-202102101-SG
Французский поставщик облачных услуг OVHcloud впервые опубликовал отчет, в котором эта массовая волна атак, нацеленных на серверы VMware ESXi, была связана с операцией программы-вымогателя в Неваде.
«По мнению экспертов из экосистемы, а также властей, они могут быть связаны с программой-вымогателем из Невады и используют CVE-2021-21974 в качестве вектора компрометации. Расследование для подтверждения этих предположений все еще продолжается», — сказал директор по информационной безопасности OVHcloud Жюльен Леврард.
«Атака в первую очередь нацелена на серверы ESXi версии до 7.0 U3i, очевидно, через порт OpenSLP (427)».
Однако вскоре после того, как наша история была опубликована, компания отступила, заявив, что они объяснили это неправильной операцией программы-вымогателя.
В конце первого дня атак было зашифровано около 120 серверов ESXi.
Однако за выходные их число быстро выросло: по данным Censys, 2400 устройств VMware ESXi по всему миру в настоящее время обнаружены как скомпрометированные в ходе кампании по вымогательству.
В бюллетене, опубликованном 6 февраля, VMware подтвердила, что эта атака использует старые недостатки ESXi, а не уязвимость нулевого дня.
Компания советует администраторам установить последние обновления для серверов ESXi и отключить службу OpenSLP, которая отключена по умолчанию с 2021 года.
В целом, кампания по вымогательству не имела большого успеха, учитывая большое количество зашифрованных устройств: служба отслеживания платежей выкупа Ransomwhere сообщила только о четырех платежах выкупа на общую сумму 88 000 долларов США.
Отсутствие выкупа, вероятно, связано с руководством по восстановлению VMware ESXi, созданным исследователем безопасности Энесом Сонмезом, которое позволяет многим администраторам бесплатно перестраивать свои виртуальные машины и восстанавливать свои данные.
Новый вымогатель ESXiArgs
Однако, судя по примечаниям о выкупе, обнаруженным в этой атаке, они не связаны с программой-вымогателем Nevada, а относятся к новому семейству программ-вымогателей.
Примерно четыре часа назад жертвы этой кампании также начали сообщать об атаках на форуме BleepingComputer, прося помощи и дополнительной информации о том, как восстановить свои данные.
Программа-вымогатель шифрует файлы с расширениями .vmxf, .vmx, .vmdk, .vmsd и .nvram на скомпрометированных серверах ESXi и создает файл .args для каждого зашифрованного документа с метаданными (вероятно, необходимыми для расшифровки).
В то время как субъекты угрозы, стоящие за этой атакой, утверждают, что украли данные, одна жертва сообщила на форумах BleepingComputer, что в их инциденте этого не было.
«Наше расследование показало, что данные не были заражены. В нашем случае на атакованной машине было более 500 ГБ данных, но обычное ежедневное использование составляло всего 2 Мбит/с. Мы просмотрели статистику трафика за последние 90 дней и не обнаружили доказательств исходящих данных. перевод", - сказал админ.
Жертвы также нашли заметки о выкупе под названием «ransom.html» и «Как восстановить ваши файлы.html» в заблокированных системах. Другие сказали, что их заметки представляют собой текстовые файлы.
Майкл Гиллеспи из ID Ransomware в настоящее время отслеживает программу-вымогатель под именем «ESXiArgs», но сообщил BleepingComputer, что, пока мы не найдем образец, невозможно определить, есть ли у него какие-либо недостатки в шифровании.
BleepingComputer имеет специальную тему поддержки ESXiArgs, где люди сообщают о своем опыте с этой атакой и получают помощь в восстановлении машин.
Технические детали ESXiArgs
Прошлой ночью администратор получил копию шифровальщика ESXiArgs и связанного сценария оболочки и поделился им в теме поддержки BleepingComputer.
Анализ скрипта и шифровальщика позволил нам лучше понять, как проводились эти атаки.
При взломе сервера в папке /tmp сохраняются следующие файлы:
encrypt — исполняемый файл ELF-шифровальщика.
encrypt.sh — сценарий оболочки, который действует как логика атаки, выполняя различные задачи перед запуском шифровальщика, как описано ниже.
public.pem — открытый ключ RSA, используемый для шифрования ключа, который шифрует файл.
motd — примечание о выкупе в текстовом виде, которое будет скопировано в /etc/motd, чтобы оно отображалось при входе в систему. Исходный файл сервера будет скопирован в /etc/motd1.
index.html — примечание о выкупе в формате HTML, которое заменит домашнюю страницу VMware ESXi. Исходный файл сервера будет скопирован в index1.html в той же папке.
Майкл Гиллеспи из ID Ransomware проанализировал шифровальщик и сообщил BleepingComputer, что шифрование, к сожалению, безопасно, а это означает, что никакие криптографические ошибки не позволяют дешифровать.
«Открытый.pem, который он ожидает, является открытым ключом RSA (я предполагаю, что это RSA-2048, основанный на просмотре зашифрованных файлов, но код технически принимает любой действительный PEM)», — написал Гиллеспи в теме поддержки на форуме.
«Для файла для шифрования он генерирует 32 байта с использованием защищенного CPRNG RAND_pseudo_bytes OpenSSL, а затем этот ключ используется для шифрования файла с использованием Sosemanuk, безопасного потокового шифра. Ключ файла шифруется с помощью RSA (OpenSSL RSA_public_encrypt) и добавляется к конец файла».
«Использование алгоритма Sosemanuk довольно уникально и обычно используется только в программах-вымогателях, полученных из исходного кода Babuk (вариант ESXi). Возможно, это так, но они модифицировали его для использования RSA вместо реализации Babuk Curve25519».
Этот анализ показывает, что ESXiArgs, вероятно, основан на утечке исходного кода Babuk, который ранее использовался другими кампаниями по вымогательству ESXi, такими как CheersCrypt и шифровальщик PrideLocker группы Quantum/Dagon.
Хотя примечания о выкупе для ESXiArgs и Cheerscrypt очень похожи, метод шифрования отличается, поэтому неясно, является ли это новым вариантом или просто общей кодовой базой Babuk.
Шифровальщик выполняется файлом сценария оболочки, который запускает его с различными аргументами командной строки, включая файл с открытым ключом RSA, файл для шифрования, фрагменты данных, которые не будут зашифрованы, размер блока шифрования и файл. размер.
usage: encrypt <public_key> <file_to_encrypt> [<enc_step>] [<enc_size>] [<file_size>]
enc_step - number of MB to skip while encryption
enc_size - number of MB in encryption block
file_size - file size in bytes (for sparse files)
Этот шифратор запускается с помощью сценария оболочки encrypt.sh, который действует как логика атаки, которую мы кратко опишем ниже.
При запуске сценарий выполнит следующую команду для изменения файлов конфигурации виртуальной машины ESXi (.vmx), чтобы строки «.vmdk» и «.vswp» были изменены на «1.vmdk» и «1.vswp».
Новая версия программы-вымогателя ESXiArgs препятствует восстановлению VMware ESXi
Новые атаки программ-вымогателей ESXiArgs теперь шифруют большие объемы данных, что значительно усложняет, если не делает невозможным, восстановление зашифрованных виртуальных машин VMware ESXi.
В прошлую пятницу массированная и широко распространенная автоматизированная атака программ-вымогателей зашифровала более 3000 серверов VMware ESXi, доступных в Интернете, с помощью новой программы-вымогателя ESXiArgs.
В предварительных отчетах указывалось, что устройства были взломаны с использованием старых уязвимостей VMware SLP. Однако некоторые жертвы заявили, что SLP был отключен на их устройствах и все еще был взломан и зашифрован.
При шифровании устройства скрипт encrypt.sh ищет файлы виртуальной машины, соответствующие следующим расширениям:
Для каждого найденного файла скрипт проверяет размер файла и, если размер файла меньше 128 МБ, шифрует весь файл с шагом 1 МБ.
Однако для файлов размером более 128 МБ будет вычисляться «size_step», что заставит шифровальщик попеременно шифровать 1 МБ данных и не шифровать фрагменты (size_step в мегабайтах) данных.
Сценарий encrypt.sh использует следующую формулу (слегка измененную для удобочитаемости), чтобы определить, какой size_step следует использовать:
size_step=((($size_in_kb/1024/100)-1))
Это означает, что для файла размером 4,5 ГБ он будет генерировать size_step равным «45», заставляя шифровальщик чередовать шифрование 1 МБ файла и пропуск 45 МБ файла. Итак, как вы можете видеть, довольно много данных остается незашифрованным к моменту завершения шифрования файла.
Для еще больших файлов, таких как файл размером 450 ГБ, объем пропущенных данных резко возрастает, при этом size_step становится равным «4607», теперь чередуется шифрование 1 МБ и пропуск 4,49 ГБ данных.
Из-за этих больших фрагментов незашифрованных данных исследователи разработали метод восстановления виртуальных машин с использованием больших и в основном незашифрованных плоских файлов, в которых хранятся данные диска виртуальной машины.
Сценарий, созданный CISA, позже автоматизировал этот процесс восстановления.
Процесс шифрования изменен
К сожалению, сегодня началась вторая волна программ-вымогателей ESXiArgs, которые включают в себя модифицированную процедуру шифрования, которая шифрует гораздо больше данных в больших файлах.
BleepingComputer впервые узнал о второй волне после того, как администратор опубликовал в теме поддержки ESXiArgs сообщение о том, что их сервер был зашифрован и не может быть восстановлен с помощью методов, которые работали ранее.
Поделившись образцами с BleepingComputer, мы заметили, что шифратор не изменился, но подпрограмма size_step скрипта encrypt.sh была удалена и просто установлена в 1 в новой версии.
Это изменение проиллюстрировано ниже в сравнении исходного вычисления size_step encrypt.sh (слева) в первой волне атак с новым сценарием оболочки (справа) во второй волне.
Эксперт по программам-вымогателям Майкл Гиллеспи сообщил, что это изменение заставляет шифровальщик чередовать шифрование 1 МБ данных и пропуск 1 МБ данных.
Все файлы размером более 128 МБ теперь будут иметь 50% зашифрованных данных, что делает их, вероятно, невосстановимыми.
Это изменение также препятствует успешному восстановлению машин предыдущими инструментами восстановления, поскольку в плоских файлах будет слишком много зашифрованных данных, чтобы их можно было использовать.
Эта вторая волна атаки также внесла незначительные изменения в примечание о выкупе, больше не включая биткойн-адреса в примечание о выкупе, как показано ниже.
Удаление биткойн-адресов, вероятно, произошло из-за того, что они были собраны исследователями безопасности для отслеживания выплат выкупа.
Однако, что еще более тревожно, администратор, который поделился новыми образцами, сказал, что SLP отключен на их сервере, но все равно снова взломан. Они также проверили наличие бэкдора vmtool.py, замеченного в предыдущих атаках, и не нашли его.
С отключенным SLP становится еще более запутанным вопрос о том, как этот сервер был взломан.
BleepingComputer по-прежнему рекомендует пытаться восстановить зашифрованные серверы ESXi с помощью сценария восстановления CISA.
Однако он, скорее всего, больше не будет работать, если вы были заражены во время второй волны атак с использованием новой процедуры шифрования.
Clop Ransomware утверждает, что он атаковал 130 организаций, используя goanywhere zeryday
Кибергруппа Clop утверждает, что стоит за недавними атаками, которые использовали уязвимость в нулевом дне в инструменте Googhwhere MFT Secure File Transform, заявив, что они украли данные из более чем 130 организаций.
Недостаток безопасности, который теперь отслеживается как CVE-2023-0669, позволяет злоумышленникам получить удаленное выполнение кода на непропатченных экземплярах GoAnywhere MFT с их административной консолью, подверженной доступу в Интернете.
Clop обратился к BleepingComputer и сказал нам, что они якобы украли данные в течение десяти дней после нарушения уязвимых серверов для использования таргетинга этой ошибки.
Они также утверждали, что они могут перемещаться по боковым направлениям через сети своих жертв и развернуть полезные нагрузки вымогателей, чтобы зашифровать системы, но решили не делать этого и только украли документы, хранящиеся на скомпрометированных GoAnywhere MFT.
Группа отказалась предоставить доказательства или поделиться дополнительной информацией о своих вторжения, когда BleepingComputer спросил их, когда начались атаки, если они уже начали вымогать своих жертв, и какие выкупы они просили.
BleepingComputer не мог самостоятельно подтвердить действия Clop, и Forta не ответил на электронные письма с просьбой получить дополнительную информацию о эксплуатации CVE-2013-0669 и обвинениях группы вымогателей,
Разработчик Goanywhere MFT Fortra (ранее известный как Helpsystems) на прошлой неделе сообщил своим клиентам, что уязвимость эксплуатируется как нулевой день в дикой природе.
На следующий день компания выпустила обновления аварийной безопасности, чтобы позволить клиентам защитить свои серверы от входящих попыток атаки.
«Мы определили, что несанкционированная сторона получила доступ к системам через ранее неизвестный эксплойт и создала несанкционированные учетные записи пользователей», - сказал Fortra.
CISA также добавил уязвимость CVE-2023-0669 Goanywhere MFT в свой известный каталог эксплуатируемых уязвимостей в пятницу, приказывая федеральным агентствам исправлять свои системы в течение следующих трех недель, до 3 марта.
В то время как Shodan показывает, что более 1000 экземпляров Goanywhere, доступных из интернета, только 135 находятся на портах 8000 и 8001 (те, которые используются уязвимой консоли администратора).
Clop Ransomware требует выкуп у жертв нулевого дня GoAnywhere
Clop требует выкуп у компаний, чьи данные были украдены с помощью уязвимости нулевого дня в решении для безопасного обмена файлами Fortra GoAnywhere MFT.
В феврале разработчики решения для передачи файлов GoAnywhere MFT предупредили клиентов о том, что на открытых административных консолях используется уязвимость нулевого дня для удаленного выполнения кода.
GoAnywhere — это решение для безопасной передачи файлов через Интернет, которое позволяет компаниям безопасно передавать зашифрованные файлы своим партнерам, сохраняя при этом подробные журналы аудита того, кто получил доступ к файлам.
Хотя никаких подробностей о том, как использовалась уязвимость, не сообщалось, вскоре был выпущен экспериментальный эксплойт, а затем исправление для этой уязвимости.
На следующий день после выпуска патча GoAnywhere кибергруппа Clop заявила, что несет ответственность за атаки.
Группа заявила, что они использовали уязвимость в течение десяти дней, чтобы украсть данные у 130 компаний.
С тех пор две компании, Community Health Systems (CHS) и Hatch Bank, сообщили, что данные были украдены в ходе атак GoAnywhere MFT.
Клоп начинает вымогать деньги у клиентов GoAnywhere
Недавно Clop начал публично эксплуатировать жертв атак GoAnywhere, добавив семь новых компаний на свой сайт утечки данных.
Общеизвестно, что только одна из жертв, Hatch Bank, была взломана с помощью этой уязвимости.
Хотя неясно, сколько требуют злоумышленники, ранее в декабре 2020 года они требовали выкуп в размере 10 миллионов долларов в аналогичных атаках с использованием уязвимости нулевого дня Accellion FTA.
Во время этих атак группа вымогателей украла большие объемы данных почти у 100 компаний по всему миру, при этом злоумышленники медленно сливали данные из компаний, требуя выкупа в миллионы долларов.
В число организаций, чьи серверы Accellion были взломаны, входят, среди прочего, энергетический гигант Shell, фирма по кибербезопасности Qualys, гигант супермаркетов Kroger и несколько университетов по всему миру, таких как Стэнфордский медицинский университет, Университет Колорадо, Университет Майами, Калифорнийский университет и Университет Мэриленда. Балтимор (UMB).
Кибергруппа Medusa набирает обороты, атакуя компании по всему миру
Medusa Ransomware, начала набирать обороты в 2023 году, нацеленная на корпоративных жертв по всему миру с требованиями выкупа на миллионы долларов.
Операция «Медуза» началась в июне 2021 года, но ее активность была относительно низкой, жертв было немного. Однако в 2023 году группа активизировалась и запустила «блог Медузы», используемый для утечки данных о жертвах, отказавшихся платить выкуп.
На этой неделе Medusa привлекла внимание СМИ после того, как они взяли на себя ответственность за нападение на район государственных школ Миннеаполиса (MPS) и поделились видео с украденными данными.
Многие семейства вредоносных программ называют себя Medusa, в том числе ботнет на основе Mirai с возможностями вымогателей, вредоносное ПО Medusa для Android и широко известная операция вымогателей MedusaLocker.
Из-за часто используемого имени были некоторые запутанные отчеты об этом семействе программ-вымогателей, и многие думали, что это то же самое, что и MedusaLocker.
Однако действия программ-вымогателей Medusa и MedusaLocker совершенно разные.
Операция MedusaLocker была запущена в 2019 году как Ransomware-as-a-Service с многочисленными аффилированными лицами, запиской о выкупе, обычно называемой How_to_back_files.html, и широким спектром расширений файлов для зашифрованных файлов.
Операция MedusaLocker использует для переговоров веб-сайт Tor по адресу qd7pcafncosqfqu3ha6fcx4h6sr7tzwagzpcdcnytiw3b6varaeqv5yd.onion.
Однако операция по вымогательству Medusa началась примерно в июне 2021 года и использовала записку с требованием выкупа под названием !!!READ_ME_MEDUSA!!!.txt и статическое зашифрованное расширение файла .MEDUSA.
Операция Medusa также использует веб-сайт Tor для переговоров о выкупе, но их сайт находится по адресу medusacegu2ufmc3kx2kkqicrlcxdettsjcenhjena6uannk5f4ffuyd.onion.
Как Medusa шифрует Windows-устройства
BleepingComputer смог проанализировать шифратор Medusa только для Windows, и пока неизвестно, есть ли у них такой шифратор для Linux.
Шифровальщик Windows принимает параметры командной строки, которые позволяют злоумышленнику настроить способ шифрования файлов на устройстве, как показано ниже.
# Command Line
Option | Description
-V | Get version
-d | Do not delete self
-f | Exclude system folder
-i | In path
-k | Key file path
-n | Use network
-p | Do not preprocess (preprocess = kill services and shadow copies)
-s | Exclude system drive
-t | Note file path
-v | Show console window
-w | Initial run powershell path (powershell -executionpolicy bypass -File %s)
При обычном запуске без аргументов командной строки программа-вымогатель Medusa завершит работу более 280 служб и процессов Windows для программ, которые могут препятствовать шифрованию файлов. К ним относятся службы Windows для почтовых серверов, серверов баз данных, серверов резервного копирования и программного обеспечения для обеспечения безопасности.
Затем программа-вымогатель удалит теневые копии томов Windows, чтобы предотвратить их использование для восстановления файлов.
Эксперт по программам-вымогателям Майкл Гиллеспи также проанализировал шифровальщик и сообщил BleepingComputer, что он шифрует файлы, используя шифрование AES-256 + RSA-2048 с использованием библиотеки BCrypt.
Гиллеспи также подтвердил, что метод шифрования, используемый в Medusa, отличается от метода, используемого в MedusaLocker.
При шифровании файлов программа-вымогатель будет добавлять расширение .MEDUSA к именам зашифрованных файлов
В каждой папке программа-вымогатель создаст заметку о выкупе с именем !!!READ_ME_MEDUSA!!!.txt, содержащую информацию о том, что случилось с файлами жертвы.
Записка о выкупе также будет включать контактную информацию расширения, в том числе сайт утечки данных Tor, сайт переговоров Tor, канал Telegram, идентификатор Tox и адрес электронной почты key.medusa.serviceteam@protonmail.com.
В качестве дополнительного шага, чтобы предотвратить восстановление файлов из резервных копий, программа-вымогатель Medusa выполнит следующую команду, чтобы удалить локально сохраненные файлы, связанные с программами резервного копирования, такими как Windows Backup. Эта команда также удалит виртуальные жесткие диски (VHD), используемые виртуальными машинами.
Комментарии
Администраторы, хостинг-провайдеры и Французская группа реагирования на компьютерные чрезвычайные ситуации (CERT-FR) предупреждают, что злоумышленники активно нацелены на неисправленные серверы VMware ESXi против уязвимости удаленного выполнения кода двухлетней давности для развертывания новой программы-вымогателя ESXiArgs.
Уязвимость, отслеживаемая как CVE-2021-21974, вызвана проблемой переполнения динамической памяти в службе OpenSLP, которая может быть использована злоумышленниками, не прошедшими проверку подлинности, в атаках низкой сложности.
«По данным текущих расследований, эти кампании атак, по-видимому, используют уязвимость CVE-2021-21974, исправление для которой доступно с 23 февраля 2021 года», — говорится в сообщении CERT-FR.
«В настоящее время целевыми системами будут гипервизоры ESXi версии 6.x и ранее 6.7».
Чтобы блокировать входящие атаки, администраторы должны отключить уязвимую службу протокола определения местоположения службы (SLP) на гипервизорах ESXi, которые еще не были обновлены.
CERT-FR настоятельно рекомендует установить исправление как можно скорее, но добавляет, что системы, оставшиеся без исправлений, также следует сканировать на наличие признаков компрометации.
CVE-2021-21974 влияет на следующие системы:
ESXi версии 7.x до ESXi70U1c-17325551
ESXi версии 6.7.x до ESXi670-202102401-SG
ESXi версии 6.5.x до ESXi650-202102101-SG
Французский поставщик облачных услуг OVHcloud впервые опубликовал отчет, в котором эта массовая волна атак, нацеленных на серверы VMware ESXi, была связана с операцией программы-вымогателя в Неваде.
«По мнению экспертов из экосистемы, а также властей, они могут быть связаны с программой-вымогателем из Невады и используют CVE-2021-21974 в качестве вектора компрометации. Расследование для подтверждения этих предположений все еще продолжается», — сказал директор по информационной безопасности OVHcloud Жюльен Леврард.
«Атака в первую очередь нацелена на серверы ESXi версии до 7.0 U3i, очевидно, через порт OpenSLP (427)».
Однако вскоре после того, как наша история была опубликована, компания отступила, заявив, что они объяснили это неправильной операцией программы-вымогателя.
В конце первого дня атак было зашифровано около 120 серверов ESXi.
Однако за выходные их число быстро выросло: по данным Censys, 2400 устройств VMware ESXi по всему миру в настоящее время обнаружены как скомпрометированные в ходе кампании по вымогательству.
В бюллетене, опубликованном 6 февраля, VMware подтвердила, что эта атака использует старые недостатки ESXi, а не уязвимость нулевого дня.
Компания советует администраторам установить последние обновления для серверов ESXi и отключить службу OpenSLP, которая отключена по умолчанию с 2021 года.
В целом, кампания по вымогательству не имела большого успеха, учитывая большое количество зашифрованных устройств: служба отслеживания платежей выкупа Ransomwhere сообщила только о четырех платежах выкупа на общую сумму 88 000 долларов США.
Отсутствие выкупа, вероятно, связано с руководством по восстановлению VMware ESXi, созданным исследователем безопасности Энесом Сонмезом, которое позволяет многим администраторам бесплатно перестраивать свои виртуальные машины и восстанавливать свои данные.
Новый вымогатель ESXiArgs
Однако, судя по примечаниям о выкупе, обнаруженным в этой атаке, они не связаны с программой-вымогателем Nevada, а относятся к новому семейству программ-вымогателей.
Примерно четыре часа назад жертвы этой кампании также начали сообщать об атаках на форуме BleepingComputer, прося помощи и дополнительной информации о том, как восстановить свои данные.
Программа-вымогатель шифрует файлы с расширениями .vmxf, .vmx, .vmdk, .vmsd и .nvram на скомпрометированных серверах ESXi и создает файл .args для каждого зашифрованного документа с метаданными (вероятно, необходимыми для расшифровки).
В то время как субъекты угрозы, стоящие за этой атакой, утверждают, что украли данные, одна жертва сообщила на форумах BleepingComputer, что в их инциденте этого не было.
«Наше расследование показало, что данные не были заражены. В нашем случае на атакованной машине было более 500 ГБ данных, но обычное ежедневное использование составляло всего 2 Мбит/с. Мы просмотрели статистику трафика за последние 90 дней и не обнаружили доказательств исходящих данных. перевод", - сказал админ.
Жертвы также нашли заметки о выкупе под названием «ransom.html» и «Как восстановить ваши файлы.html» в заблокированных системах. Другие сказали, что их заметки представляют собой текстовые файлы.
Майкл Гиллеспи из ID Ransomware в настоящее время отслеживает программу-вымогатель под именем «ESXiArgs», но сообщил BleepingComputer, что, пока мы не найдем образец, невозможно определить, есть ли у него какие-либо недостатки в шифровании.
BleepingComputer имеет специальную тему поддержки ESXiArgs, где люди сообщают о своем опыте с этой атакой и получают помощь в восстановлении машин.
Технические детали ESXiArgs
Прошлой ночью администратор получил копию шифровальщика ESXiArgs и связанного сценария оболочки и поделился им в теме поддержки BleepingComputer.
Анализ скрипта и шифровальщика позволил нам лучше понять, как проводились эти атаки.
При взломе сервера в папке /tmp сохраняются следующие файлы:
encrypt — исполняемый файл ELF-шифровальщика.
encrypt.sh — сценарий оболочки, который действует как логика атаки, выполняя различные задачи перед запуском шифровальщика, как описано ниже.
public.pem — открытый ключ RSA, используемый для шифрования ключа, который шифрует файл.
motd — примечание о выкупе в текстовом виде, которое будет скопировано в /etc/motd, чтобы оно отображалось при входе в систему. Исходный файл сервера будет скопирован в /etc/motd1.
index.html — примечание о выкупе в формате HTML, которое заменит домашнюю страницу VMware ESXi. Исходный файл сервера будет скопирован в index1.html в той же папке.
«Открытый.pem, который он ожидает, является открытым ключом RSA (я предполагаю, что это RSA-2048, основанный на просмотре зашифрованных файлов, но код технически принимает любой действительный PEM)», — написал Гиллеспи в теме поддержки на форуме.
«Для файла для шифрования он генерирует 32 байта с использованием защищенного CPRNG RAND_pseudo_bytes OpenSSL, а затем этот ключ используется для шифрования файла с использованием Sosemanuk, безопасного потокового шифра. Ключ файла шифруется с помощью RSA (OpenSSL RSA_public_encrypt) и добавляется к конец файла».
«Использование алгоритма Sosemanuk довольно уникально и обычно используется только в программах-вымогателях, полученных из исходного кода Babuk (вариант ESXi). Возможно, это так, но они модифицировали его для использования RSA вместо реализации Babuk Curve25519».
Этот анализ показывает, что ESXiArgs, вероятно, основан на утечке исходного кода Babuk, который ранее использовался другими кампаниями по вымогательству ESXi, такими как CheersCrypt и шифровальщик PrideLocker группы Quantum/Dagon.
Хотя примечания о выкупе для ESXiArgs и Cheerscrypt очень похожи, метод шифрования отличается, поэтому неясно, является ли это новым вариантом или просто общей кодовой базой Babuk.
Шифровальщик выполняется файлом сценария оболочки, который запускает его с различными аргументами командной строки, включая файл с открытым ключом RSA, файл для шифрования, фрагменты данных, которые не будут зашифрованы, размер блока шифрования и файл. размер.
Этот шифратор запускается с помощью сценария оболочки encrypt.sh, который действует как логика атаки, которую мы кратко опишем ниже.
При запуске сценарий выполнит следующую команду для изменения файлов конфигурации виртуальной машины ESXi (.vmx), чтобы строки «.vmdk» и «.vswp» были изменены на «1.vmdk» и «1.vswp».
https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/
Новые атаки программ-вымогателей ESXiArgs теперь шифруют большие объемы данных, что значительно усложняет, если не делает невозможным, восстановление зашифрованных виртуальных машин VMware ESXi.
В прошлую пятницу массированная и широко распространенная автоматизированная атака программ-вымогателей зашифровала более 3000 серверов VMware ESXi, доступных в Интернете, с помощью новой программы-вымогателя ESXiArgs.
В предварительных отчетах указывалось, что устройства были взломаны с использованием старых уязвимостей VMware SLP. Однако некоторые жертвы заявили, что SLP был отключен на их устройствах и все еще был взломан и зашифрован.
При шифровании устройства скрипт encrypt.sh ищет файлы виртуальной машины, соответствующие следующим расширениям:
Для каждого найденного файла скрипт проверяет размер файла и, если размер файла меньше 128 МБ, шифрует весь файл с шагом 1 МБ.
Однако для файлов размером более 128 МБ будет вычисляться «size_step», что заставит шифровальщик попеременно шифровать 1 МБ данных и не шифровать фрагменты (size_step в мегабайтах) данных.
Сценарий encrypt.sh использует следующую формулу (слегка измененную для удобочитаемости), чтобы определить, какой size_step следует использовать:
Это означает, что для файла размером 4,5 ГБ он будет генерировать size_step равным «45», заставляя шифровальщик чередовать шифрование 1 МБ файла и пропуск 45 МБ файла. Итак, как вы можете видеть, довольно много данных остается незашифрованным к моменту завершения шифрования файла.
Для еще больших файлов, таких как файл размером 450 ГБ, объем пропущенных данных резко возрастает, при этом size_step становится равным «4607», теперь чередуется шифрование 1 МБ и пропуск 4,49 ГБ данных.
Из-за этих больших фрагментов незашифрованных данных исследователи разработали метод восстановления виртуальных машин с использованием больших и в основном незашифрованных плоских файлов, в которых хранятся данные диска виртуальной машины.
Сценарий, созданный CISA, позже автоматизировал этот процесс восстановления.
Процесс шифрования изменен
К сожалению, сегодня началась вторая волна программ-вымогателей ESXiArgs, которые включают в себя модифицированную процедуру шифрования, которая шифрует гораздо больше данных в больших файлах.
BleepingComputer впервые узнал о второй волне после того, как администратор опубликовал в теме поддержки ESXiArgs сообщение о том, что их сервер был зашифрован и не может быть восстановлен с помощью методов, которые работали ранее.
Поделившись образцами с BleepingComputer, мы заметили, что шифратор не изменился, но подпрограмма size_step скрипта encrypt.sh была удалена и просто установлена в 1 в новой версии.
Это изменение проиллюстрировано ниже в сравнении исходного вычисления size_step encrypt.sh (слева) в первой волне атак с новым сценарием оболочки (справа) во второй волне.
Эксперт по программам-вымогателям Майкл Гиллеспи сообщил, что это изменение заставляет шифровальщик чередовать шифрование 1 МБ данных и пропуск 1 МБ данных.
Все файлы размером более 128 МБ теперь будут иметь 50% зашифрованных данных, что делает их, вероятно, невосстановимыми.
Это изменение также препятствует успешному восстановлению машин предыдущими инструментами восстановления, поскольку в плоских файлах будет слишком много зашифрованных данных, чтобы их можно было использовать.
Эта вторая волна атаки также внесла незначительные изменения в примечание о выкупе, больше не включая биткойн-адреса в примечание о выкупе, как показано ниже.
Удаление биткойн-адресов, вероятно, произошло из-за того, что они были собраны исследователями безопасности для отслеживания выплат выкупа.
Однако, что еще более тревожно, администратор, который поделился новыми образцами, сказал, что SLP отключен на их сервере, но все равно снова взломан. Они также проверили наличие бэкдора vmtool.py, замеченного в предыдущих атаках, и не нашли его.
С отключенным SLP становится еще более запутанным вопрос о том, как этот сервер был взломан.
BleepingComputer по-прежнему рекомендует пытаться восстановить зашифрованные серверы ESXi с помощью сценария восстановления CISA.
Однако он, скорее всего, больше не будет работать, если вы были заражены во время второй волны атак с использованием новой процедуры шифрования.
https://www.bleepingcomputer.com/news/security/new-esxiargs-ransomware-version-prevents-vmware-esxi-recovery/
Кибергруппа Clop утверждает, что стоит за недавними атаками, которые использовали уязвимость в нулевом дне в инструменте Googhwhere MFT Secure File Transform, заявив, что они украли данные из более чем 130 организаций.
Недостаток безопасности, который теперь отслеживается как CVE-2023-0669, позволяет злоумышленникам получить удаленное выполнение кода на непропатченных экземплярах GoAnywhere MFT с их административной консолью, подверженной доступу в Интернете.
Clop обратился к BleepingComputer и сказал нам, что они якобы украли данные в течение десяти дней после нарушения уязвимых серверов для использования таргетинга этой ошибки.
Они также утверждали, что они могут перемещаться по боковым направлениям через сети своих жертв и развернуть полезные нагрузки вымогателей, чтобы зашифровать системы, но решили не делать этого и только украли документы, хранящиеся на скомпрометированных GoAnywhere MFT.
Группа отказалась предоставить доказательства или поделиться дополнительной информацией о своих вторжения, когда BleepingComputer спросил их, когда начались атаки, если они уже начали вымогать своих жертв, и какие выкупы они просили.
BleepingComputer не мог самостоятельно подтвердить действия Clop, и Forta не ответил на электронные письма с просьбой получить дополнительную информацию о эксплуатации CVE-2013-0669 и обвинениях группы вымогателей,
Разработчик Goanywhere MFT Fortra (ранее известный как Helpsystems) на прошлой неделе сообщил своим клиентам, что уязвимость эксплуатируется как нулевой день в дикой природе.
На следующий день компания выпустила обновления аварийной безопасности, чтобы позволить клиентам защитить свои серверы от входящих попыток атаки.
«Мы определили, что несанкционированная сторона получила доступ к системам через ранее неизвестный эксплойт и создала несанкционированные учетные записи пользователей», - сказал Fortra.
CISA также добавил уязвимость CVE-2023-0669 Goanywhere MFT в свой известный каталог эксплуатируемых уязвимостей в пятницу, приказывая федеральным агентствам исправлять свои системы в течение следующих трех недель, до 3 марта.
В то время как Shodan показывает, что более 1000 экземпляров Goanywhere, доступных из интернета, только 135 находятся на портах 8000 и 8001 (те, которые используются уязвимой консоли администратора).
https://www.bleepingcomputer.com/news/security/clop-ransomware-claims-it-breached-130-orgs-using-goanywhere-zero-day/
В феврале разработчики решения для передачи файлов GoAnywhere MFT предупредили клиентов о том, что на открытых административных консолях используется уязвимость нулевого дня для удаленного выполнения кода.
GoAnywhere — это решение для безопасной передачи файлов через Интернет, которое позволяет компаниям безопасно передавать зашифрованные файлы своим партнерам, сохраняя при этом подробные журналы аудита того, кто получил доступ к файлам.
Хотя никаких подробностей о том, как использовалась уязвимость, не сообщалось, вскоре был выпущен экспериментальный эксплойт, а затем исправление для этой уязвимости.
На следующий день после выпуска патча GoAnywhere кибергруппа Clop заявила, что несет ответственность за атаки.
Группа заявила, что они использовали уязвимость в течение десяти дней, чтобы украсть данные у 130 компаний.
С тех пор две компании, Community Health Systems (CHS) и Hatch Bank, сообщили, что данные были украдены в ходе атак GoAnywhere MFT.
Клоп начинает вымогать деньги у клиентов GoAnywhere
Недавно Clop начал публично эксплуатировать жертв атак GoAnywhere, добавив семь новых компаний на свой сайт утечки данных.
Общеизвестно, что только одна из жертв, Hatch Bank, была взломана с помощью этой уязвимости.
Хотя неясно, сколько требуют злоумышленники, ранее в декабре 2020 года они требовали выкуп в размере 10 миллионов долларов в аналогичных атаках с использованием уязвимости нулевого дня Accellion FTA.
Во время этих атак группа вымогателей украла большие объемы данных почти у 100 компаний по всему миру, при этом злоумышленники медленно сливали данные из компаний, требуя выкупа в миллионы долларов.
В число организаций, чьи серверы Accellion были взломаны, входят, среди прочего, энергетический гигант Shell, фирма по кибербезопасности Qualys, гигант супермаркетов Kroger и несколько университетов по всему миру, таких как Стэнфордский медицинский университет, Университет Колорадо, Университет Майами, Калифорнийский университет и Университет Мэриленда. Балтимор (UMB).
https://www.bleepingcomputer.com/news/security/clop-ransomware-gang-begins-extorting-goanywhere-zero-day-victims/
Medusa Ransomware, начала набирать обороты в 2023 году, нацеленная на корпоративных жертв по всему миру с требованиями выкупа на миллионы долларов.
Операция «Медуза» началась в июне 2021 года, но ее активность была относительно низкой, жертв было немного. Однако в 2023 году группа активизировалась и запустила «блог Медузы», используемый для утечки данных о жертвах, отказавшихся платить выкуп.
На этой неделе Medusa привлекла внимание СМИ после того, как они взяли на себя ответственность за нападение на район государственных школ Миннеаполиса (MPS) и поделились видео с украденными данными.
Из-за часто используемого имени были некоторые запутанные отчеты об этом семействе программ-вымогателей, и многие думали, что это то же самое, что и MedusaLocker.
Однако действия программ-вымогателей Medusa и MedusaLocker совершенно разные.
Операция MedusaLocker была запущена в 2019 году как Ransomware-as-a-Service с многочисленными аффилированными лицами, запиской о выкупе, обычно называемой How_to_back_files.html, и широким спектром расширений файлов для зашифрованных файлов.
Операция MedusaLocker использует для переговоров веб-сайт Tor по адресу qd7pcafncosqfqu3ha6fcx4h6sr7tzwagzpcdcnytiw3b6varaeqv5yd.onion.
Однако операция по вымогательству Medusa началась примерно в июне 2021 года и использовала записку с требованием выкупа под названием !!!READ_ME_MEDUSA!!!.txt и статическое зашифрованное расширение файла .MEDUSA.
Операция Medusa также использует веб-сайт Tor для переговоров о выкупе, но их сайт находится по адресу medusacegu2ufmc3kx2kkqicrlcxdettsjcenhjena6uannk5f4ffuyd.onion.
Как Medusa шифрует Windows-устройства
BleepingComputer смог проанализировать шифратор Medusa только для Windows, и пока неизвестно, есть ли у них такой шифратор для Linux.
Шифровальщик Windows принимает параметры командной строки, которые позволяют злоумышленнику настроить способ шифрования файлов на устройстве, как показано ниже.
При обычном запуске без аргументов командной строки программа-вымогатель Medusa завершит работу более 280 служб и процессов Windows для программ, которые могут препятствовать шифрованию файлов. К ним относятся службы Windows для почтовых серверов, серверов баз данных, серверов резервного копирования и программного обеспечения для обеспечения безопасности.
Затем программа-вымогатель удалит теневые копии томов Windows, чтобы предотвратить их использование для восстановления файлов.
Эксперт по программам-вымогателям Майкл Гиллеспи также проанализировал шифровальщик и сообщил BleepingComputer, что он шифрует файлы, используя шифрование AES-256 + RSA-2048 с использованием библиотеки BCrypt.
Гиллеспи также подтвердил, что метод шифрования, используемый в Medusa, отличается от метода, используемого в MedusaLocker.
При шифровании файлов программа-вымогатель будет добавлять расширение .MEDUSA к именам зашифрованных файлов
В каждой папке программа-вымогатель создаст заметку о выкупе с именем !!!READ_ME_MEDUSA!!!.txt, содержащую информацию о том, что случилось с файлами жертвы.
Записка о выкупе также будет включать контактную информацию расширения, в том числе сайт утечки данных Tor, сайт переговоров Tor, канал Telegram, идентификатор Tox и адрес электронной почты key.medusa.serviceteam@protonmail.com.
Сайт переговоров Tor находится по адресу http://medusacegu2ufmc3kx2kkqicrlcxdettsjcenhjena6uannk5f4ffuyd.onion.
В качестве дополнительного шага, чтобы предотвратить восстановление файлов из резервных копий, программа-вымогатель Medusa выполнит следующую команду, чтобы удалить локально сохраненные файлы, связанные с программами резервного копирования, такими как Windows Backup. Эта команда также удалит виртуальные жесткие диски (VHD), используемые виртуальными машинами.
https://www.bleepingcomputer.com/news/security/medusa-ransomware-gang-picks-up-steam-as-it-targets-companies-worldwide/