Upload
others
View
4
Download
0
Embed Size (px)
Citation preview
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.
[Online] Unknown Unknown Unknown. [Cited: 14 04 2016.]
https://msdn.microsoft.com/en-
us/library/windows/desktop/aa364975(v=vs.85).aspx.
10. —. GetVolumeInformation function. Microsoft Developer Network.
[Online] Unknown Unknown Unknown. [Cited: 14 04 2016.]
https://msdn.microsoft.com/en-
us/library/windows/desktop/aa364993(v=vs.85).aspx.
11. —. FindFirstFile function. Microsoft Developer Network. [Online]
Unknown Unknown Unknown. [Cited: 14 04 2016.]
https://msdn.microsoft.com/en-
gb/library/windows/desktop/aa364418(v=vs.85).aspx.
12. —. FindNextFile function. Microsoft Developer Network. [Online]
Unknown Unknown Unknown. [Cited: 14 04 2016.]
19
https://msdn.microsoft.com/en-
us/library/windows/desktop/aa364428(v=vs.85).aspx.
13. —. WIN32_FIND_DATA structure. Microsoft Developer Network.
[Online] Unknown Unknown Unknown. [Cited: 14 04 2016.]
https://msdn.microsoft.com/en-
us/library/windows/desktop/aa365740(v=vs.85).aspx.
14. —. File Attribute Constants. Microsoft Developer Network. [Online]
Unknown Unknown Unknown. [Cited: 14 04 2016.]
https://msdn.microsoft.com/en-
us/library/windows/desktop/gg258117(v=vs.85).aspx.
15. WNetOpenEnum function. Microsoft Developer Network. [Online]
Unknown Unknown Unknown. [Cited: 14 04 2016.]
https://msdn.microsoft.com/en-
us/library/windows/desktop/aa385478(v=vs.85).aspx.
16. WNetEnumResource function. Microsoft Developer Network. [Online]
Unknown Unknown Unknown. [Cited: 14 04 2016.]
https://msdn.microsoft.com/en-
us/library/windows/desktop/aa385449(v=vs.85).aspx.
17. WNetCloseEnum function. Microsoft Developer Network. [Online]
Unknown Unknown Unknown. [Cited: 14 04 2016.]
https://msdn.microsoft.com/en-
us/library/windows/desktop/aa385431(v=vs.85).aspx.
18. Microsoft. winnetwk.h. Contents of the winnetwk.h header file. s.l. :
Microsoft, Unknown.
19. NETRESOURCE structure. Microsoft Developer Network. [Online]
Unknown Unknown Unknown. [Cited: 14 04 2016.]
https://msdn.microsoft.com/en-
us/library/windows/desktop/aa385353(v=vs.85).aspx.
20. Microsoft. SetThreadPriority function. Micorosoft Developer Network.
[Online] Unknown Unknown Unknown. [Cited: 13 04 2016.]
https://msdn.microsoft.com/en-
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.