Целью этой статьи не является публичное осуждение кого-либо.
Предисловие
Ничего не предвещало беды, даже намека на разбор, но раз уж проект закрылся, то думаю пора, хотя бы с научной точки зрения...
Стоит упомянуть еще пару деталей:
Почему проект закрылся? - По словам селлера, кодер ушел работать в приват, оставив софт без дальнейших обновлений, поэтому проект закрылся, так как никто его больше поддерживать не сможет.
Были ли шеллы в панелях балдра? - Ссылаясь на слова кодера - нет. Дело в том, что в админке нашли дыру и по ней грузились шеллы, а потом уже выкачивались логи. Все бы ничего, если бы это происходило не сразу, как с KPOT, дыры находили и по мере поступления новых панелей заливали шеллы, но вот только не с Baldr, шеллы залили всем и сразу, на все панели, которых на трекерах и так очень много. А правда это или нет, я уже не знаю.
Причастен ли overdot? - Сложно сказать, но мое мнение: нет. Он просто селлер, от него в этой ситуации ничего не зависело. Но как селлер, он и отлетел на всех форумах.
Анализ - Введение
Сам софт состоит из 2 главных частей:
Анализ - Native
Как обычно начнем со скана в DiE:
Ничего примечательного нет, как и после просмотра в CFF. Поэтому открываем семпл в IDA:
Кликаем по __tmainCRTStartup и находим пользовательский EP:
Переключусь сразу в псевдокод:
Для начала разберемся с динамическим импортом, подгружаем нужный модуль через LoadLibraryW, дергаем из него функцию через GetProcAddess.
Теперь займемся расшифровкой .NET файла:
Расшифровка будет похоже на ту, что была в Racoon. Переносим ключ в буффер:
Копируем тот же цикл:
Далее нужно получить массив с зашифрованным бинарником, для этого делаем дабл клик по byte_40F0C8:
И ПКМ -> Array -> OK:
В меню IDA жмем Edit -> Export Data, выбираем С unsigned char array и ставим галочку у Save data to clipboard:
Далее вставляем это, желательно, в отдельный файл:
И далее дописываем цикл:
Прописываем запись бинарника на диск:
И запускаем программу:
Проверяем, что успешно расшифровали:
.NET Бинарник расшифрован, обычным статическим анализом, ничего мудреного. Толку от подобного шифрования действительно мало.
В данном случае адрес (*(*v48 + 12)) - является адресом функции GetRuntime. Где первым аргументом передается версия .NET для подгруза.
Итого по нативной обертке:
Снова начнем с DiE:
Видим целый веер протекторов, но это нам не мешает открыть файл в dnSpy:
Видим кучу треш-кода, который нельзя так просто вычистить через de4dot, но как минимум поверхностно проанализировать сможем. Софт является многопоточным, после прохождения всего того треш-кода, запускаются новые потоки:
Внутри каждой такой функции могут создаваться еще больше новых потоков. Далее анализировать смысла совсем нет, понять все очень трудно, но можно, например, как здесь увидеть название ManagementObject и понять, что это функция, которая создает запросы WMI:
Но на этом анализ .NET не заканчивается, ведь это C#, и получаем:
Но для свежести картины, загрузим семпл версии 3.0:
Домен все также в голом виде.
Заключение
Иногда хочется просто промолчать и только кинуть загадочный взгляд, а потом прошептать:
Предисловие
Ничего не предвещало беды, даже намека на разбор, но раз уж проект закрылся, то думаю пора, хотя бы с научной точки зрения...
Стоит упомянуть еще пару деталей:

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

Были ли шеллы в панелях балдра? - Ссылаясь на слова кодера - нет. Дело в том, что в админке нашли дыру и по ней грузились шеллы, а потом уже выкачивались логи. Все бы ничего, если бы это происходило не сразу, как с KPOT, дыры находили и по мере поступления новых панелей заливали шеллы, но вот только не с Baldr, шеллы залили всем и сразу, на все панели, которых на трекерах и так очень много. А правда это или нет, я уже не знаю.

Причастен ли overdot? - Сложно сказать, но мое мнение: нет. Он просто селлер, от него в этой ситуации ничего не зависело. Но как селлер, он и отлетел на всех форумах.
Анализ - Введение
Сам софт состоит из 2 главных частей:
- Обертка, написанная на C++
- Сам софт, написанный на C#

Анализ - Native
Как обычно начнем со скана в DiE:

Ничего примечательного нет, как и после просмотра в CFF. Поэтому открываем семпл в IDA:

Кликаем по __tmainCRTStartup и находим пользовательский EP:


Переключусь сразу в псевдокод:

Для начала разберемся с динамическим импортом, подгружаем нужный модуль через LoadLibraryW, дергаем из него функцию через GetProcAddess.
Почему-то кодер забыл сделать динамической и эту функцию:

Теперь займемся расшифровкой .NET файла:

Расшифровка будет похоже на ту, что была в Racoon. Переносим ключ в буффер:

Копируем тот же цикл:

Далее нужно получить массив с зашифрованным бинарником, для этого делаем дабл клик по byte_40F0C8:

И ПКМ -> Array -> OK:

В меню IDA жмем Edit -> Export Data, выбираем С unsigned char array и ставим галочку у Save data to clipboard:

Далее вставляем это, желательно, в отдельный файл:

И далее дописываем цикл:

Прописываем запись бинарника на диск:

И запускаем программу:

Проверяем, что успешно расшифровали:

.NET Бинарник расшифрован, обычным статическим анализом, ничего мудреного. Толку от подобного шифрования действительно мало.
Осталось только рассказать про CLRHosting, который использует Baldr для загрузки стиллера в память. Использует он .NET v4.030319 Runtime, который установлен далеко не у всех, как например, на многих Windows 7, поэтому на них стиллер не отработает:Вообще не обязательно тратить так много времени на распаковку, можно просто сдампить файл после запуска, но так было бы менее интересно читать эту статью

В данном случае адрес (*(*v48 + 12)) - является адресом функции GetRuntime. Где первым аргументом передается версия .NET для подгруза.
Итого по нативной обертке:
- Динамический импорт остался без использования кастомного GetProcAddress, имена всех функций и модулей не зашифрованы
- Шифрования бинарника, сделанное для галочки (в версии 3.0+ алгоритм поменялся, но распаковать также многого не стоит)
- Зависимость от .NET 4.0
Снова начнем с DiE:

Видим целый веер протекторов, но это нам не мешает открыть файл в dnSpy:

Видим кучу треш-кода, который нельзя так просто вычистить через de4dot, но как минимум поверхностно проанализировать сможем. Софт является многопоточным, после прохождения всего того треш-кода, запускаются новые потоки:

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

Но на этом анализ .NET не заканчивается, ведь это C#, и получаем:

Но для свежести картины, загрузим семпл версии 3.0:

Домен все также в голом виде.
Сбор Telegram идет по дефолтному пути:

Заключение
Иногда хочется просто промолчать и только кинуть загадочный взгляд, а потом прошептать:
