Tuesday, 25 June 2013

Carberp archive

My first impression on the archive leak was "it's full of crap, where i should start"
And i was right about this, Okay Carberp source is leaked but 2Gb... what the final size of a carberp stub 700Mb ?
This archive contain really a lot of things who have nothing to do with Carberp like Zeus source code, Trusteer reports, RootkitUnhooker, UPX, openVPN, Stoned Bootkit, KonBoot, a leaked version of Citadel (lol?) and various others... (still entertaining)
This without speaking about all files generated by the IDE, (all useless .html, .obj, .idb, pdb...)
All useless double EXE files, 7z/rar/zip archives.
Those guys need to learn to organize their shit, the source code is the same chaotic mosaic.
On This archive Carberp is not the only thing who got leaked, there is also Mystic Compressor.

One of my first love (even if it's lame, i've unpacked really a lot of stuff packed with this)
Mystic commands: pack, register, unregister, copies, run, exec, test
MD5: c391deda94d4b6132a0420e104364c98
MD5: 564ffcdee65fc85d28828aacb5bf513d
MD5: 700f76b8d1c29d32c1d107d5fffe187b
MD5: e6ff5021ab01651407d7e9d7b6586863
I've always wondered who was behind Mystic and it's the first time i see the compressor.

To give you an overview of the AVs Detection on Mystic, here is a simple Hello world in assembler:

Without mystic: https://www.virustotal.com/en/file/5b3a24f86859ebb5856a5abd7c78bb5a819de7e1c1150f51b0f2fc6ff2fb4fad/analysis/1372161832/

With Mystic: https://www.virustotal.com/en/file/e46248776110c58f77da4a654db96ca1881028a91991712f5d61bd04cba87864/analysis/1372161816/

Some links about mystic compressor:

Stating the obviously main leak, Carberp builder:
2.3.1 - 2f143aa5c616a5e0995c9d68afc03d3e TS: 2013-01-21
2.2.1 - 8e2a2c2fe8e5165904a7934567e9b8f5 TS: 2013-01-30
2.1 - e158889586ec328ce1edbfe5ace72697 TS: 2013-01-02 - bf38f21f7787c54b4adc2b7484b71768 TS: 2012-12-25 - 949fff00b88a48ac1ebe03601b908468 TS: 2012-09-08

Builder of the first Carberp leak:
d57474d7df5ae5c823390a174111de5d TS: 2012:10:01

Config Builder:
ee00c34194898d739f77d0cd861efbc7 TS: 2012-08-17
9b125eecf8ef814f109182081dd2d8f1 TS: 2011-09-13
275d1983de8a313fc22db0c2f0a8dfe7 TS: 2012-08-17 *from the first leak*

Liberty Reserve inject (will be so useful now!):

On some forums, malware services already include Carberp:

And to finish some translations done by @Malwageddon
Бут-лоадер для драйверов

Позволяет загружать специально собранные драйвера в момент старта ОС.
Драйвер загружается до инициализации ядра NT, а значит до старта PatchGuard.
Цифровая подпись драйвера не требуется.

Поддерживаются все ОС Windows, начиная с XP, и по 7 SP1, включительно.
Поддерживаются две архитектуры: x86 и AMD64 (EM64T).

Код лоадера метаморфный, состоит из некоторого кол-ва блоков, которые
перемешиваются в случайном порядке при каждой сборке проекта. Таким образом,
каждый свежесобраный лоадер бинарно отличен от предыдущего. В дальнейшем,
по желанию заказчика, можно доработать лоадер, добавив динамическое шифрование
и элементы полиморфизма.

Проект собирается с помощью MS Visual Studio 2005 и MS Windows XP DDK.
Cначала собирается под х86, затем под AMD64.

Состав проекта
  1. Генератор лоадера (\BkGen).
  2. Библиотека лоадера (\BkLib).
  3. Программа-установщик (\BkSetup).
  4. Библиотека-установщик (\SetupDll).
  5. Драйвер-инжектор (\KLoader).
  6. Утилита для прикрепления файлов(\FJ).
  7. Батники для сборки примерного установщика с примерами DLL (\BkBuild).

Генератор лоадера
  Собирается только для х86 в исполняемый файл BkGen.exe
  При запуске создает файл VBR.COM содержащий метаморфный код загрузчика.
  При каждом запуске генерирует уникальный загрузчик.

Библиотека лоадера
  Собирается под х86 и под AMD64 в статическую библиотеку (.lib).
  Содержит функции, необходимые для установки и инициализации лоадера.
  Импортируется установщиком и драйвером. Подробнее см. файл bklib.h.

  При сборке ищется файл лоадера VBR.COM и интегрируется в ресурсы.
  Собирается только под x86 в исполняемый файл BkSetup.exe.

  Собирается под х86 и х64 в динамическую библиотеку SetupDll.dll
  Библиотека экспортирует одну функцию: ULONG BkInstall(VOID),
  при вызове которой, производится установка загрузчика в системе.
  В случае ошибки, функция возвращает код ошибки Win32.

  Собирается под х86 и AMD64 как драйвер NT (kloader.sys).
  Инжектит прикрёпленные DLL в указаннае процессы. Список DLL и процессов
  задается файлом конфигурации для утилиты FJ. При загрузке сканирует папку
  \SystemRoot\RepSrc. Ищет в папке \SystemRoot и во всех подпапках файлы с
  такими же именами как те, которые найдены в \SystemRoot\RepSrc и заменяет их.

Утилита для прикрепления файлов
  Собирается только под х86 в исполняемый файл FJ.EXE.
  Используется для присоединения инжектируемых DLL к файлу драйвера и для
  присоединения файла драйвера к инсталлеру. Подробнее см. \FJ\ReadMe.txt.

Батники для сборки примерного установщика
  BkBuild.bat - собирает инсталлер с прикреплёнными к нему драйверами kloader.sys
                для х86 и amd64, соответственно. К каждому драйверу прикрепляются
                DLL для инжекта.
  BkSetup.cfg - конфигурационный файл для сборки инсталлера.
  kldr32.cfg  - конфигурационный файл для прикрепления DLL к 32х-битному драйверу.
  kldr64.cfg  - конфигурационный файл для прикрепления DLL к 64х-битному драйверу.
  demo32.dll  - 32х-битная демо-библиотека.
  demo64.dll  - 64х-битная демо-библиотека.

Порядок сборки
  1. При помощи Visual Studio 2005 собрать весь проект. Сначала собрать под i386,
     затем, под amd64.
  2. Открыть консоль (CMD.EXE), зайти в папку \BkBuild и запустить из консоли
  3. Забрать готовый установщик из папки \BkBuild\Release.
Bootloader for the drivers

Allows loading specially crafted drivers during Operating System start-up.
The driver is loaded before NT kernel initialization and before PatchGuard starts,
so it can patch any kernel code.
The driver is given control before any other drivers are loaded (including all
boot-load drivers), so it can monitor and interact with their loading process.
Digital signature for the driver is not required.

Supports all Windows OS, from XP to Windows 8 inclusive.
Supports 2 CPU architectures: x86 and AMD64 (EM64T).
Boot-loader is working under any NTFS types.

Assembled project has three major components:
- Initial Program Load (IPL);
- specially crafted driver that is loaded prior NT kernel;
- installation program (or installation library(DLL));

IPL code is metamorphic and consist of a number of blocks. During each project
compilation blocks are mixed in a random order.
IPL code is encrypted and dynamically decrypted only during execution.
Each newly compiled IPL code is different from the previous ones.
The driver is also encrypted when written to the disk and decrypted by IPL during
the start-up.

There is a size limit for the driver: due to the way IPL operates - the driver can't
be bigger than 100KB.

The project is compiled with MS Visual Studio 2005 and MS Windows 7 WDK.

Additional components

The driver may include the following additional components:

- Virtual File System Manager. Creates encrypted(RC6) virtual file system (VFS) in
unformatted disk area.
  Enables User-mode interface for working with the files stored in VFS.

- filters disk access. Blocks 'external' access to the sectors where IPL and VFS is
located. Hides VFS

- DLL injector. Allows process loading(injection) of DLLs stored on VFS or attached
to the file driver. Includes interface to manage injects in the user-mode.

- Driver loader. Enables interface for loading unsigned drivers.

- TCP/IP stack (including: ARP, ICMP, DNS). Allows BSD-socket network access for
drivers and user-mode applications.

Project components
  1. IPL generator(\BkGen).
  2. Loader library(\BkLib).
  3. Installation program(\BkSetup).
  4. Installation library(SetupDll).
  5. Injection driver(\KLoader).
  6. VFS library(\FsLib).
  7. Unsigned drivers loader library(\DrvLdr).
  8. Loader and VFS protection filter library(\BkFilter).
  9. File attachment utility(\FJ).
  10. VFS manager tool/interface(\VFS).
  11. Batch files for assembling a loader sample with sample DLLs (\BkBuild).

IPL Generator
  Assembles into an executable file BkGen.exe - works under x86 only
  Creates VBR.COM when started and includes metamorphic loader code.
  Unique loader is generated at each execution

Loader library
  Assembles into a static library(.lib) - works under x86 and AMD64
  Includes functions required for loader installation and initialization.
  Imported by the installer and the driver. See bklib.h for more details.

Installation program
  Searches loader file - VBR.COM during compilation and integrates it into resources.
  Compiles into an executable file BkSetup.exe - works under x86 only

Installation library
  Assembles into a library file SetupDll.dll - works under x86 and x64
  The library exports one function: ULONG BkInstall(BOOL bReboot).
  Calling this function performs loader installation.
  The function returns Win32 error code if any issues are encountered.

Injection driver
  Assembles into an NT driver (kloader.sys) - works under x86 and x64
  Injects attached DLLs into specified processes. The list of DLLs and processes is
specified in the configuration file for FJ utility.

VFS library
  Being linked into Injector Driver (kloader.sys) - works under x86 and x64
  Creates VFS in unformatted hard disk sectors.
  If no or insufficient unformatted disk space is found the size of the last
partition on the hard disk in decreased.
  VFS is a modified FAT16 partition. The cluster size is equal to the physical
sector size on the disk.
  VFS maximum size is ~32MB.
  Filenames are in 8.3 format. Long filenames are not supported. No catalogue support.
  VFS is fully encrypted with RC6.

Unsigned drivers loader library
  Being linked into Injector Driver (kloader.sys) - works under x86 and x64
  Allows loading and execution of unsigned NT kernel drivers.

Loader and VFS protection filter library
  Being linked into Injector Driver (kloader.sys) - works under x86 and x64
  Filters low-level disk read/write calls.
  Disables any modifications to the disk sectors where the loader is stored.
  Blocks any modifications by external applications and drivers to the disk sectors
hosting VFS.
  Returns zeros if anything 'external' attempts to read VFS - hiding it.
File attachment utility
  Assembles into an executable file FJ.EXE - works under x86 only
  Used for attaching injectable DLLs to the driver file and for attaching the driver
file to the installer.
  See \FJ\ReadMe.txt for more details.

Batch files for assembling a loader sample with sample DLLs (\BkBuild).
  BkBuild.bat - assembles the installer with attached drivers kloader.sys - for x86
and amd64 accordingly. Each driver is attached a DLL for injection.
  BkSetup.cfg - configuration file for assembling the installation program and
attaching the drivers to it.
  setupdll.cfg- configuration file for assembling the installation library and
attaching the drivers to it.
  demo32.dll  - 32bit demo library
  demo64.dll  - 64bit demo library

Assembly order
  1. Using Visual Studio 2005 compile the entire project. Compile for i386 first and
then for amd64.
  2. Open the console(CMD.EXE). Go to \BkBuild folder and start BkBuild.exe
  3. Take the compiled loader from \BkBuild\Release folder.

Установка загрузчика
1. Инсталлер анализирует жесткий диск (\??\PHYSICALDRIVEx): проверяется таблица разделов,
 рассчитываются размеры неиспользованного пространства перед первым и после последнего раздела.
2. При наличии неиспользованной области достаточного размера в неё записывается код
3. Инсталлер читает код VBR (Volume Boot Record), находящийся в первых
 15 секторах загрузочного раздела (\Device\HarddiskХ\PartitionХ).
4. Код VBR сжимается, к нему дописывается загрузчик так, чтобы при старте VBR получить
5. Новый код VBR, включающий загрузчит, запиывается на место старого кода VBR.

OC Win7 запрещает запись в сектора диска, принадлежащие тому файловой системы.
 Тем не менее, Win7 всегда имеет пустой участок размером ~1МБ перед первым
 разделом диска. Для XP и Vista, в случае отстутсвия неиспользованного пространства,
 возможна запись кода драйвера в последние сектора последнего раздела.
Чтение и запись секторов диска производится путем открытия устройства \??\PHYSICALDRIVEx, с
 использованием нативных функций NT: NtCreateFile, NtReadFile, NtWriteFile.

Таким образом, чтобы гарантировать корректную установку загрузчика и драйвера необходимо:
1. Наличие прав администратора, а для OC Vista и Win7, также,
 наличие повышенных привелегий (UAC).
2. Наличие возможности беспрепятственно открывать, производить чтение и запись устройств
 \??\PHYSICALDRIVEx и \Device\HarddiskХ\PartitionХ


> так же меня интерисуют где хранится будут мои дллки которые инжектятся в процесс ?

В последних секторах системного тома.

> если винду снесут,руткит + мои длл останутся?

Нет, не останутся.
Мало кто может пережить переустановку систему.
Сделать такое можно, но будет дорого и я не уверен, что это нужно.

> и буткит ты рассказывал там какойто крутой метод ?
> тобишь запись не в mbr , а чтото другое,приватное опиши плиз подробнее.

Вкратце, у нас внедрение не в MBR, а в загрузочные файлы системы.
Loader setup
1. The installer analyses the hard disk (\??\PHYSICALDRIVEx): checks partition table,
   calculates the size of unused space before the first partition and after the last one
2. If found a big enough area - the driver code is written into it.
3. The installer reads VBR (Volume Boot Record) code that is located in the first 15 sectors of the boot partition (\Device\HarddiskÕ\PartitionÕ).
4. VBR code is compressed and the loader is added to it, so that when VBR is started it gets the control.
5. The new VBR code that includes the loader overwrites the old VBR code.

Windows 7 disables writing into file system volume sectors on the hard disk, but
it always has ~1MB of unused space before the first partition.
For XP and Vista, if no unused space is found it's possible to use the last sectors of the last partition to store the driver's code.
Hard disk sectors are read and written by opening \??\PHYSICALDRIVEx device using native NT functions: NtCreateFile, NtReadFile, NtWriteFile.

The loader and the driver will be guaranteed to install successfully under the following conditions:
1. operation is performed with admin rights. Also, for Vista and Win7 elevated UAC rights are required.
2. Unrestricted access to open, read and write to the following devices
 \??\PHYSICALDRIVEx è \Device\HarddiskÕ\PartitionÕ


> where will my DLLs that are injected into processes be stored?

The last sectors of the system volume.

>if Windows is reinstalled will the rootkit and my DLLs survive?

No, will not survive.
Not many kits can survive Operating System reinstall.
I'm sure it's doable, but it'll substantially increase the cost and I’m not sure it's really required.

> and you were saying there is some really cool method for bootkit?
> like, not using MBR, but something else... could you give more details please?

Simply saying, we do not use MBR, we use OS boot files.

DLL которую нужно запустить необходимо положить в папку In под именем
in.dll. В этой dll должна быть функция start (все буквы маленькие), она
должна быть определена следующим образом:
start(char* exe, int admin)
где exe полный путь к ехе файлу через который была запущена dll
admin - 0 - админских прав нет и они не были получены, 1 - админские права уже были,
        2 - админских прав не было, но они были были насильно получены.

Для формирования ехе необходимо полностью перекомпилировать проект (ребилд), и конечный
результат будет в папке release.
сейчас в папке release лежит ехе в который вшита длл для авторана через планировщик
задач, но такой авторан срабатывает только при админских правах.
Copy the DLL you wish to execute into a folder 'In' and rename it to 'in.dll'
The DLL has to have a function called 'start'(all lowercase). The function has to be defined in the following format:
start(char* exe, int admin)
where 'exe' is the full path to the file the DLL was executed with
admin - 0 - no admin rights and it wasn't possible to obtain them
        1 - already has admin rights
        2 - no admin rights, but were successfully forced to obtain

The entire project has to be re-build in order to create the 'exe' file. The end result will be in 'release' folder.
The current 'exe' file in the 'release' folder has embedded autorun DLL that uses Task Scheduler - this autorun will work only with admin rights

Структура папки билда:

- Tools - утилиты для упаковки
  - WhiteJoeBuild.exe - для встраивания строк в dll и dll в exe
  - mystic.exe - криптор для финального файла ring3 версии
  - builder.exe - GUI к WhiteJoeBuild.exe для встраивания строк URLs в locker.dll
- SrcDir - папка для исходных файлов процесса билда.
  Должна содержать:
  - locker.dll - рабочая ДЛЛ как для BootKit, так и для Ring3 версии
  - locker.exe - ring3 версия Locker. В нее встраивается locker.dll.wjb_out и он
    умеет ее разворачивать в памяти.

- OutDir - папка для результатов. При старте билда полностью очищается.
  Сюда ложатся результаты билда:
  - bootkit-locker.dll - файл для BootKit с вшитыми строками
  - ring3-locker.exe - файл ring3 версии с вшитой bootkit-locker.dll
  - mystic-ring3-locker.exe - обработанный Mystic.exe файл ring3-locker.exe
RunBuild.bat - файл запуска процесса билда.

Описание работы с системой билда:
- запустить RunBuild.bat

- он в свою очередь запускает Tools\builder.exe,в которой надо:
  - ввести список URL через пробел
  - ввести суффикс, который будет добавляться к каждой URL
  - нажать "готово" для вшивания
  - нажать "Cancel" для завершения работы
- процесс билда после этого должен продолжится.
- после битлда закрыть CMD окно можно нажатием на Enter.

Результирующие файлы будут в OutDir
Builder folder structure:

- Tools - packaging utilities
  - WhiteJoeBuild.exe - used for inserting strings into DLLs and DLLs into EXEs
  - mystic.exe - cryptor for the final file 'ring3' version 
  - builder.exe - WhiteJoeBuild.exe GUI for inserting URL strings into locker.dll
- SrcDir - source files folder for builder process.
  Has to contain:
  - locker.dll - working DLL for the BootKit and for Ring3 version
  - locker.exe - ring3 version of the Locker. locker.dll.wjb_out goes into it - extracts the Locker into the memory.

- OutDir - Results folder. Content of the folder is cleared at each start of the build process.
  Build results are stored here:
  - bootkit-locker.dll - BootKit file with embedded strings
  - ring3-locker.exe - ring3 version file with embedded bootkit-locker.dll
  - mystic-ring3-locker.exe - processed by Mystic.exe 'ring3-locker.exe' file
RunBuild.bat - batch file to start the build process.

How to make a new build:
- run RunBuild.bat

- the batch file will execute Tools\builder.exe and you'll be prompted to supply the following data:
  - enter the list of URL separated by 'spaces'
  - enter URL suffix that will be added to each URL
  - click "ãîòîâî" button to complete embedding
  - click "Cancel" to finish the process
- the build process will continue after this.
- once the build is finished press 'Enter' to close the CMD console.

All the built files can be found in OutDir folder


формирование ехе:
builder.exe my.dll output.exe
где - my.dll - твоя длл, output.exe - конечный файл

schtasks.dll - установка авторана через планировщик задач

твоя dll должна иметь функцию

int start(char* exe, int admin)

exe - мой ехе для установки в автозапуске
admin - 0 - прав админских нет, 1 - ехе был запущен при админских правах,
        2 - ехе силой получил админские права
функция start должна возвращать 1 - авторан прошел успешно, 0 - авторан сделать не удалось
моя прога в дебаг запишет результат
creating ехе:
builder.exe my.dll output.exe
where - my.dll - your DLL, output.exe - result file

schtasks.dll - sets autorun through Task Scheduler

your DLL has to have the following function

int start(char* exe, int admin)

exe - my 'ехе' to be setup to autorun
admin - 0 - no admin rights, 1 - 'åõå' was started with admin rights,
        2 - ехе successfully forced to obtain the admin rights
the function has to return 1 - autorun completed successfully, 0 - autorun failed
my program will save the results into debug log

I've not really looked at the Carberp source without ending with a headache.
It's more fun to watch the 'information wars' about Carberp code on twitter :)
HS: Peter Kleissner got the idea to group the more interesting content: http://blog.virustracker.info/?p=276

Brace yourself, Carberp C&Cs start already to appear.


  1. This comment has been removed by the author.

  2. My god lots of c&c we going to find now. Even after patch and updates released by av company its still dangerous.

  3. Thanks for the informative post!

  4. i bet the guy who leaked it is kicking himself now.

    1. Indeed , first zeus now this what next ? Facebook source code ?

  5. juste par curiosité quel est le nom du forum fr avec le screen de Dahou ?

  6. this is old strategy. CnC is never used in serious botnet. All new used TOR network & + Skype for communication with temp CnC auto hosted at some of bot zomies. Temp CnC upload to free ftp a list ot controled zomies, statistics and search data and read from another free hosted file (in rar+pass) a list ot blacklisted hosts, control command and data. Every bot and communication is encrypted with different key stored in DB inside temp CnC and every bot/CnC have ability to destroy itself if suspect monitor/honey spot activity. Every Bot master use some of own bots as reverse proxy / VPN relay and in advance use facked WiFi as minimum security. Don't think you can catch this so easy as old warriors with listed domain based CnC. Today domain is changed with zombie based temp CnC + exchange of ftp/www based online/offline update CnC formula generated files.

    1. well actually i don't get link from public source i get cnc gates simply by setting yara rules on some honeypots