Расшифровка одного из компонентов трояна с помощью SecureString

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

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

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

 

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

Анализ строк ниже навёл на мысль, что это так называемый SecureString, предназначенный для безопасной передачи например аутентификационных данных в т.ч. в PowerShell. И в этой строке зашит код, который некогда расшифровывался и выполнялся.

PowerShell не был моей сильной стороной, поэтому я начал разбираться.

Как получается SecureString

Запустим командную строку PowerShell (либо выполним cmd и там наберём команду powershell).

После ввода команды

$Cred = Get-Credential

Получим стандартное окно аутентификации. Введём произвольные логин и пароль:

Теперь, наша переменная $Cred станет объектом, содержащим в себе данные об имени пользователя и пароле. Причём имя пользователя будет Plaintext, а вот пароль представлен SecureString:

Выполним команды: $Cred – увидим это. А затем

$Cred.Password | ConvertFrom-SecureString

Строка чем-то похожа на наш зашифрованный код в файле вредоноса. Видимо там что-то зашито этим методом. Попробуем получить из этой строки наш Plaintext пароль:

$mypwd = $Cred.Password | ConvertFrom-SecureString

echo ([Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR((ConvertTo-SecureString $mypwd))))

Более-менее разобрался. Но вот беда – этот SecureString действительно шифруется ключами, находящимися в профиле пользователя при помощи DPAPI (DataProtection API). На другом компьютере даже имея SecureString расшифровать его нельзя, т.к. отсутствуют необходимые ключи.

Казалось бы – тупик, но… у меня есть образ диска!

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

Я сконвертировал dd-образ в формат VDI командой:
VBoxManage.exe convertdd image.dd image.vdi --format VDI

Конвертирование заняло несколько часов – образ был в 500 Гб.

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

ОС загрузилась, но встал вопрос аутентификации в домене. Раздобыть учётные данные было без вариантов – все Creds-ы в организации давно изменили, истории не осталось. Но я решил покопаться в системных файлов в поисках кешированных паролей. И лучше всего для этой цели подойдут файлы pagefile.sys и hiberfil.sys, лежащие в корне диска C:. Скармливаю их программе Passware Password Recovery Kit Forensic и иду пить чай.

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

В загруженной системе я повторил необходимые действия и ДА! Тот SecureString был успешно расшифрован. В нём хранился дополнительный powershell-код загрузки других вредоносных модулей и информация о новом подконтрольном хакерам сервере, с которого грузилась зараза.

Интересно? Поделись с другом
Litl-Admin.ru

Comments:

Leave a Reply