Drive and file selection process used in a sample of ... and file selection process used in... · 5 2 Analysis of drive and file enumeration techniques The sample used in this analysis

1

Drive and file selection process used in a sample of

Teslacrypt ransomware

Adam Burt

14th April 2016

2

Abstract

Ransomware is a type of malicious software (malware) that requires the owner of

the infected system to pay a ransom to the malware operators, in order for the

system to resume its normal service. Ransomware has historically attempted to

mimic legitimate services and organisations, such as the FBI (1) in an attempt to

fool an unsuspecting user into paying money. Recent ransomware has adopted a

method of encryption to force the user into paying a ransom. In these cases, the

ransomware will encrypted user’s data and will only provide access to decryption

keys and decryption methods, after the ransom is paid. Also in these recent

examples, strong encryption methods using public / private key pairs are typically

used and decryption is not possible without obtaining the private key. The private

key will be provided, after the user has paid the ransom.

Ransomware, that utilises encryption as a method for holding data hostage, needs

to encrypt the files stored on a users’ device. Ransomware needs to identify the

data it wants to encrypt prior to encrypting it. This paper looks at a sample of the

“Teslacrypt” malware family and the methods used to identify drives, folders and

files for encryption on the Microsoft Windows Operating System. Understanding

these methods can help in identifying the infection earlier, reduce the amount of

data encrypted and potentially provide a way to mitigate this threat.

3

1 Introduction

There have been several variants of Teslacrypt since its initial discovery (2). The

earliest release targeted computer game related files (3). However many of the

earlier releases used symmetric keys or weak encryption methods that were

susceptible to reverse engineering. In either case, tools were developed to allow the

decryption of files by using artefacts left behind by the malware (2).

Teslacrypt targets particular files on an operating system. The following list of file

extensions is targeted by Teslacrypt (2):

“.7z, .rar, .m4a, .wma, .avi, .wmv, .csv, .d3dbsp, .sc2save, .sie, .sum, .ibank, .t13,

.t12, .qdf, .gdb, .tax, .pkpass, .bc6, .bc7, .bkp, .qic, .bkf, .sidn, .sidd, .mddata, .itl,

.itdb, .icxs, .hvpl, .hplg, .hkdb, .mdbackup, .syncdb, .gho, .cas, .svg, .map, .wmo,

.itm, .sb, .fos, .mcgame, .vdf, .ztmp, .sis, .sid, .ncf, .menu, .layout, .dmp, .blob,

.esm, .001, .vtf, .dazip, .fpk, .mlx, .kf, .iwd, .vpk, .tor, .psk, .rim, .w3x, .fsh, .ntl,

.arch00, .lvl, .snx, .cfr, .ff, .vpp_pc, .lrf, .m2, .mcmeta, .vfs0, .mpqge, .kdb, .db0,

.DayZProfile, .rofl, .hkx, .bar, .upk, .das, .iwi, .litemod, .asset, .forge, .ltx, .bsa,

.apk, .re4, .sav, .lbf, .slm, .bik, .epk, .rgss3a, .pak, .big, .unity3d, .wotreplay, .xxx,

.desc, .py, .m3u, .flv, .js, .css, .rb, .png, .jpeg, .txt, .p7c, .p7b, .p12, .pfx, .pem, .crt,

.cer, .der, .x3f, .srw, .pef, .ptx, .r3d, .rw2, .rwl, .raw, .raf, .orf, .nrw, .mrwref, .mef,

.erf, .kdc, .dcr, .cr2, .crw, .bay, .sr2, .srf, .arw, .3fr, .dng, .jpe, .jpg, .cdr, .indd, .ai,

.eps, .pdf, .pdd, .psd, .dbfv, .mdf, .wb2, .rtf, .wpd, .dxg, .xf, .dwg, .pst, .accdb,

.mdb, .pptm, .pptx, .ppt, .xlk, .xlsb, .xlsm, .xlsx, .xls, .wps, .docm, .docx, .doc,

.odb, .odc, .odm, .odp, .ods, .odt”

Before Teslacrypt encrypts data, it needs to identify the files and folders it has

access to. Files and folders can exists on a variety of drive types on the Windows

Operating System and also within network resources. Figure 1 lists drive types

recognised and returned by the Windows API call to ‘GetDriveType’.

4

Figure 1 Types of drives (4)

This particular sample of Teslacrypt targets both drive types and network

resources. Further enumeration of these devices needs to be carried out to identify

folders (which will require further enumeration) and files. The extension of the files

also needs to be determined prior to encryption taking place.

5

2 Analysis of drive and file enumeration techniques

The sample used in this analysis was obtained from VirusTotal (5). Figure 2 shows

the properties of the file as created by ‘CFF Explorer’ (6).

Figure 2 Output from ‘CFF Explorer’ (6) of Teslacrypt sample

The analysis is being carried using ‘IDA Free 5.0’ (7), a freeware tool provided by

‘Hex-Rays’ as a disassembler. The original file was obfuscated and, to save time,

was executed on a Windows 7 Operating System running within a virtual

environment. Shortly after execution, the virtual machine was suspended and the

suspended memory state was acquired. Analysis of the memory image was carried

out using ‘Volatility 2.5’ (8) to extract the running process from memory. It is

often the case that obfuscated PE files can be extracted in their de-obfuscated

form, whilst they are running in memory. The ‘Volatility’ plugin named

‘procdump’ was used. The resulting EXE file was then loaded into ‘IDA Free

5.0’.

Analysis begins on the file selection process shortly after a few threads (responsible

for registry changes, process monitoring and shadow copy removal) were created. A

thread responsible for searching for and encrypting files was created. Figure 3

shows the thread being created using ‘call esi’ shortly after ‘push offset loc-

414730’.

6

Figure 3 Thread creation responsible for file / folder enumeration

The call to ‘CreateThread’ (accessed in this instance by ‘call esi’) uses the

‘lpStartAddress’ of ‘0x414730’. The code contained at ‘0x414730’ relates to the

search routine. This routine makes use several Windows API functions to

determine the files it needs to encrypt.

For the enumeration of available drives, ‘GetLogicalDriveStrings’ is called. This

function “Fills a buffer with strings that specify valid drives in the system.” (9).

Figure 4 shows the call.

7

Figure 4 ‘GetLogicalDriveStrings’ call

Following this call, there is a subroutine at ‘0x42CCB0’ that enumerates network

resources. If there are no logical drive strings returned, execution transfers to this

routine to enumerate any network resources. This routine is examined later in the

paper (Network resource enumeration). Next, an instruction to copy a

pointer to the Windows function ‘GetVolumeInformation’ (10) into the ‘EBX’

register is performed. The ‘EBX’ register is used for calling this function later. The

next several instructions compare the currently selected drive letter with ‘A’ and

then ‘B’. If either matches, the next drive letter in the list is selected. Figure 5

shows this small instruction set. Historically ‘A:’ and ‘B:’ related to floppy disk

drives and are rarely used on a standard installation of Windows without being

manually mapped as drives.

Figure 5 Skipping over drive letters ‘A’ and ‘B’

8

The next step for drive enumeration is a call to the Windows function

‘GetDriveType’ (4). The ‘GetDriveType’ function determines “…whether a disk

drive is a removable, fixed, CD-ROM, RAM disk, or network drive” (4). Once this

function completes it returns the result in the ‘EAX’ register. This return value

“…specifies the type of drive…” (4). Figure 6 shows the possible values that can

be returned.

Figure 6 Possible return values from the call to ‘GetDriveType’ (4)

The next 6 instructions check the return value against the values ‘3’, ‘4’ or ‘2’. This

version of ‘Teslacrypt’ will target any of those drive types. In the case where the

return value is either ‘3’, ‘4’, or ‘2’ (which relate to a fixed drive, or a remote

network drive, or removable drive, respectively (4)) execution jumps to the location

‘0x4148A3’. If the return value does not match ‘3’, ‘4’ or ‘2’, then execution jumps

to ‘0x4148D5’ where the next drive letter is selected and this process repeated.

The ‘0x4148A3’ routine begins with setting up the stack ready for a call to ‘EBX’

that contains the pointer to the Windows API function ‘GetVolumeInformation’.

The ‘EBX’ register was populated with this function pointer, shortly after the

previous call to ‘GetLogicalDriveStrings’ (see Figure 4). The parameters being

pushed on to the stack include the root path name as ‘lpRootPathName’. Figure 7

shows the possible parameters required to call the function.

9

Figure 7 Parameters used in the ‘GetVolumeInformation’ function (10)

The parameter that specifies the ‘lpRootPathName’ is pushed onto the stack last

through the ‘push edi’ instruction. The ‘EDI’ register contains the next root drive

letter populated after the call to ‘GetLogicalDriveStrings’. Once the function

completes, the return result which ‘If all the requested information is retrieved, the

return value is nonzero’ (10) is checked. Should the function have completed

successfully and all information returned successfully, execution jumps to the

routine at ‘0x414960’. The ‘0x414960’ routine is then responsible for parsing the file

/ folder contents and is covered later in this paper. If the call to

‘GetVolumeInformation’ fails, execution effectively jumps to the routine at

‘0x4147F0’, where the next drive letter is selected from the list and this process

repeats.

The repetitive routine of:

Checking the drive letter

Executing ‘GetDriveType’

Executing ‘GetVolumeInformation’

repeats for all available drive letters returned from ‘GetLogicalDriveStrings’.

Figure 8 shows a logical execution highlight based on the analysis so far.

Figure 8 Logical flow for drive type and letter checking so far

10

For each correctly identified drive that is ‘Fixed’, ‘Remote’ or ‘Removable’, the

drive enumeration and encryption routine is called. First the drive letter is pushed

onto the stack with ‘push edi’. The routine at ‘0x414960’ is then called.

In the 0x414960 routine, the Unicode string ‘\\*.*’ is appended to the end of the

drive letter. Next, the Windows function ‘FindFirstFile’ is called to begin the

enumeration. Figure 9 shows the append of the Unicode string and call to

‘FindFirstFile’.

Figure 9 Appending Unicode string and call to ‘FindFirstFile’

The ‘FindFirstFile’ function “Searches a directory for a file or subdirectory with a

name that matches a specific name…” (11). Calls to the ‘FindNextFile’ function

“Continues a file search from a previous call to the FindFirstFile…” (12). Both

‘FindFirstFile’ and ‘FindNextFile’ obtain a ‘WIN32_FIND_DATA’ (13) data structure

of the file. The ‘WIN32_FIND_DATA’ structure contains (starts with) an attribute at

offset ‘0x00’ named ‘dwFileAttributes’. One possible value for this attribute is

‘0x10’ which identifies the file as a “…handle that identifies a directory” (14). The

current routine tries to match whether the current handle is a directory, rather

than a file, using this value. This is achieved using a ‘test’ function as shown in

Figure 10.

11

Figure 10 Identifying a folder from the file handle attributes

If the handle is identified as a folder, the handle is passed back into the same

currently running routine for further enumeration by starting ‘FindFirstFile’

again. When the handle returned by either ‘FindFirstFile’ or ‘FindNextFile’ is a

file, the encryption routine begins by passing the file handle to a routine at

‘0x414D00’. Whilst not directly in scope for this paper, it is worth noting that this

sample also avoids encrypting already encrypted files and also files dropped by

itself, that notify the user that their files have been encrypted.

12

3 Network resource enumeration

After this sample of Teslacrypt has completed encrypting local drives, identified

using the function ‘GetGetLogicalDriveStrings’, it moves on to enumerating

network resources. The routine responsible for this task is at ‘0x414620’.

This sample uses the following functions to enumerate network resources:

‘WNetOpenEnum’ (15)

‘WNetEnumResource’ (16)

‘WNetCloseEnum’ (17)

To begin, ‘WNetOpenEnum’ is called and “…starts an enumeration of network

resources or existing connections” (15). The ‘WNetOpenEnum’ function can take five

parameters. Figure 11 shows these parameter definitions.

Figure 11 ‘WNetOpenEnum’ possible parameters (15)

The call to the ‘WNetOpenEnum’ function is passed a value of ‘2’ to the ‘dwScope’

parameter. The ‘dwScope’ parameter is the “Scope of the enumeration.” (15). A

value of ‘2’ indicates that the function should attempt to “Enumerate all resources

on the network” (18). Additionally, the ‘dwType’ is set to ‘0’ to indicate that the

function should try to enumerate all resources; both disk and print (18). Figure

12 shows the call (stack) setup and the call itself.

13

Figure 12 ‘WNetOpenEnum’ call setup

Once the ‘WNetOpenEnum’ executes successfully, it provides a handle that can be

used in subsequent calls to ‘WNetEnumResource’ (16). The ‘WNetEnumResource’

function is then called and is requested to provide “as many entries as possible”

(16). This is determined through the ‘-1’ pushed as ‘lpcCount’ on to the stack in

the instruction ‘mov [ebp+cCount], 0FFFFFFFFh’) (16) seen in Figure 12. The

‘NETRESOURCE’ (19) structure produced by the ‘WNetEnumResource’ function, is

stored in a buffer of size ‘16,384’ bytes. This buffer size was defined prior to the

‘WNetOpenEnum’ call and can also be seen in Figure 12. If the call was not

successful then next network resource is targeted. The ‘lpRemoteName’ is referenced

from the ‘NETRESOURCE’ data structure by offsetting the ‘ESI’ register, containing a

pointer to the ‘NETRESOURCE’ structure, by ‘20’ bytes in the instruction ‘add esi,

20’. This can be seen in Figure 13.

Figure 13 An offset of ‘20’ bytes into ‘esi’ (‘add esi, 20’)

14

The next several instructions check the type of resource by querying properties of

the ‘NETRESOURCE’ structure. The ‘dwScope’ and ‘dwType’ are checked and then

execution continues to place the network resource in a list. Figure 14 shows the

addition of the current item to the list through a call to ‘0x425AB5’.

Figure 14 Addition of network resources to a list

The offset, set in the ‘ESI’ register by ‘20’ bytes (that can be seen in Figure 13)

moves ‘ESI’ to point to the ‘lpRemoteName’ parameter in the ‘NETRESOURCE’

structure. The list of valid network resources that is being built, contains the

‘lpRemoteName’ parameter from each network resource enumerated. This is

determined by the instruction ‘move, ecx, [esi]’ that pushes the (already offset)

‘ESI’ register contents into the ‘ECX’ register. The ‘lpRemoteName’ parameter is

either “…a pointer to a null-terminated character string…” (19) or “…points to the

network name associated with the name pointed to by the lpLocalName member..”

(19). Once all network resources and their remote names are pushed onto this list,

control returns to the previous routine at ‘0x414904’.

At this point, the network resources are accessed and encrypted in a similar way to

which the local drives were. Accept in this case, the network resource

‘lpRemoteName’ from the list of resources are pushed one by one to the call to the

enumeration and encryption routine. Figure 15 shows this final push of each

network resource ‘lpRemoteName’ and call to the enumeration and encryption

routine.

15

Figure 15 enumerating each network resource ‘lpRemoteName’

The loop between ‘0x414911’ and ‘0x414929’ is only valid whilst there are existing

‘lpRemoteName’ entries in the list previously built. The instructions between

‘0x414919’ and ‘0x414923’ perform the list entry increment and validation check if

there are any more entries in the list.

16

4 Conclusion

Teslacrypt, like other ransomware samples can be very noisy. Enumerating the vast

number of file extensions across all connected disk drives (whether fixed, remote or

removable) and also available network resources would cost the Operating System

a high number of cycles to accommodate. This activity would make the Teslacrypt

process stand out as it consumes processors and memory with its file intensive

functions. However, something that was not covered in the initial write up, was the

priority in which the enumeration and encryption routine thread was assigned.

After the thread was initially created, a call to ‘SetThreadPriority’ (20) was

called shortly afterwards. This can be seen in Figure 3. The following instructions

show the setup to the call:

mov edi, eax - Copy thread handle to edi

push 0FFFFFFF1h - Push ‘-15’ onto the stack

push edi - Push the thread handle onto the stack

call ds:SetThreatPriority - Call the function

The ‘EAX’ register contains the handle to the thread responsible for the enumeration

and encryption routine. It is first copied into the ‘EDI’ register, then the value ‘-15’

is pushed onto the stack, then ‘EDI’ is pushed onto the stack before calling the

‘SetThreatPriority’. The value of ‘-15’ for the threat priority sets “Base priority

of 1 for IDLE_PRIORITY_CLASS, BELOW_NORMAL_PRIORITY_CLASS,

NORMAL_PRIORITY_CLASS, ABOVE_NORMAL_PRIORITY_CLASS, or

HIGH_PRIORITY_CLASS processes, and a base priority of 16 for

REALTIME_PRIORITY_CLASS processes.” (20)

This essentially sets the enumeration and encryption thread with the lowest

possible priority.

“Threads are scheduled in a round-robin fashion at each priority level, and only

when there are no executable threads at a higher level does scheduling of threads at

a lower level take place.” (20)

The user should not really experience any system degradation as their other

processes and threads should take priority. This could mean that the encryption

process could take some time and that the process may not stand out as much as

normal, based on processor time or memory usage. Perhaps over time the amount

of processing time required would become apparent, but more than likely, at this

time the process could have finished encrypted all the files. This may rule out any

system resource monitoring options for detecting the ransomware.

The large number of calls to both ‘FindFirstFile’ and ‘FindNextFile’, followed

by subsequent calls to read and write the files (not covered in this paper) may

17

serve as a good indicator that ransomware is present and enumerating and

encrypting files. Endpoint detection technologies with behavioural detection may be

able to detect this. However, whether endpoint technologies are capable or not, the

behaviour detection would infer that at least one file would be encrypted prior to

detection, if not several hundred. This situation would still not help prevent the

data loss.

The last possibility for detection looks at a behaviour was not covered in any detail

in this paper. This sample of ‘Teslacrypt’ makes use of ‘VSSAdmin.exe’ (21) to

remove any volume shadow copies. Specifically ‘vssadmin.exe delete shadows’

which “Deletes shadow copies of a specified volume.” (22). Shadow copies, when

enabled, provide us with ‘previous versions’ of files and is controlled with the

‘Volume Shadow Copy Service’ (VSS).

“VSS coordinates the actions that are required to create a consistent shadow copy

(also known as a snapshot or a point-in-time copy) of the data that is to be backed

up.” (23)

It may be possible to remove, or restrict access to, the local copy of the

‘vssadmin.exe’ tool. This would leave the ability for the user to potentially

recover a previous version of all encrypted files, to a state where they were not

encrypted. The restore procedure, of course, would need to be carried out after the

infection had been eradicated. Any legitimate use of the ‘vssadmin.exe’ tool by

system administrators, locally or globally, could be preceded with the deployment

of the tool, prior to its use; followed by the removal, after it had been successfully

used.

18

5 Bibliography

1. Federal Bureau of Investigation. FBI - New Internet Scam. The Federal

Bureau of Investigation. [Online] 09 August 2012. [Cited: 14 04 2016.]

https://www.fbi.gov/news/stories/2012/august/new-internet-scam/new-

internet-scam.

2. BleepingComputer. TeslaCrypt and Alpha Crypt Ransomware

Information Guide and FAQ. BleepingComputer. [Online] 05 05 2015. [Cited:

14 04 2016.] http://www.bleepingcomputer.com/virus-removal/teslacrypt-

alphacrypt-ransomware-information#tesla.

3. Kaspersky. New TeslaCrypt Ransomware Targets Gaming Files.

Kaspersky Lab. [Online] 23 03 2015. [Cited: 14 04 2016.]

https://blog.kaspersky.com/teslacrypt-ransomware-targets-gamers/8021/.

4. Microsoft. GetDriveType function. Microsoft Developer Network.

[Online] Unknown Unknown Unknown. [Cited: 14 04 2016.]

https://msdn.microsoft.com/en-

gb/library/windows/desktop/aa364939(v=vs.85).aspx.

5. VirusTotal. Antivirus scan for

838f89a2eead1cfdf066010c6862005cd3ae15cf8dc5190848b564352c412cfa at 2016-

01-14 11:36:41 UTC - VirusTotal. VirusTotal. [Online] 14 01 2016. [Cited: 14

04 2016.]

https://www.virustotal.com/en/file/838f89a2eead1cfdf066010c6862005cd3ae15cf

8dc5190848b564352c412cfa/analysis/.

6. Pistelli, Daniel. NTCore's Homepage. NTCore. [Online] 18 11 2012.

[Cited: 14 04 2016.] http://www.ntcore.com/exsuite.php.

7. Hey-Rays. IDA. Hey-Rays. [Online] 27 05 2015. [Cited: 14 04 2016.]

https://www.hex-rays.com/products/ida/support/download_freeware.shtml.

8. Volatility Foundation. Releases. Volatility Foundation. [Online] 28 10

2015. [Cited: 14 04 2016.]

http://www.volatilityfoundation.org/#!releases/component_71401.

9. Microsoft. GetLogicalDriveStrings fuction. Microsoft Developer Network.



us/library/windows/desktop/aa364975(v=vs.85).aspx.

10. —. GetVolumeInformation function. Microsoft Developer Network.




11. —. FindFirstFile function. Microsoft Developer Network. [Online]

Unknown Unknown Unknown. [Cited: 14 04 2016.]


gb/library/windows/desktop/aa364418(v=vs.85).aspx.

12. —. FindNextFile function. Microsoft Developer Network. [Online]


19



13. —. WIN32_FIND_DATA structure. Microsoft Developer Network.




14. —. File Attribute Constants. Microsoft Developer Network. [Online]



us/library/windows/desktop/gg258117(v=vs.85).aspx.

15. WNetOpenEnum function. Microsoft Developer Network. [Online]




16. WNetEnumResource function. Microsoft Developer Network. [Online]




17. WNetCloseEnum function. Microsoft Developer Network. [Online]




18. Microsoft. winnetwk.h. Contents of the winnetwk.h header file. s.l. :

Microsoft, Unknown.

19. NETRESOURCE structure. Microsoft Developer Network. [Online]




20. Microsoft. SetThreadPriority function. Micorosoft Developer Network.



us/library/windows/desktop/ms686277(v=vs.85).aspx.

21. —. Vssadmin. Microsoft Technet. [Online] 17 04 2012. [Cited: 14 04

2016.] https://technet.microsoft.com/en-us/library/cc754968.aspx.

22. —. Vssadmin delete shadows. Microsoft Technet. [Online] 17 04 2012.

[Cited: 14 04 2016.] https://technet.microsoft.com/en-us/library/cc788026.aspx.

23. —. Volume Shadow Copy Service. Microsoft Technet. [Online] 03 09

2014. [Cited: 14 04 2016.] https://technet.microsoft.com/en-

gb/library/ee923636(v=ws.10).aspx.

Drive and file selection process used in a sample of ... and file selection process used in... · 5 2 Analysis of drive and file enumeration techniques The sample used in this analysis

Documents