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)

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.

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.

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.

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.

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.

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Õ

FAQ

> 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?

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

- 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.

- 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.

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

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.