Towards data resilience: the analytical case of crypto ransomware data recovery techniques

Published Online January 2018 in MECS

In light of this, in this paper, we endeavor to evaluate ransomware attack recovery techniques from an attack structure point of view. We contend that ransomware strains with the same attack structure can be addressed with a similar recovery technique provided such a one exists. We experiment and analyze a myriad of samples and suggest a mitigation approach depending on the observed attack structure.

The rest of the paper is outlined as follows: Related works are discussed in Section II. Section III discusses the common attack structures and related concepts while the experimental setup and methodology are brought forth in Section IV. Results and the analyses thereof are presented in Section V while recommendations and best practices are brought forth in Section VI and we draw the conclusion in Section VII.

• II.    Related Works

Ahmadian et al. [23] present an approach for detecting and preventing highly survivable ransomware based on a principal feature discovered in the taxonomy. The focus of their work is to provide data resilience via monitoring and preventing the encryption of the victim's data. Based on dynamic malware analysis, the prevention methodology is successful when the ransomware tries to contact the C2 to download the encryption key. Though the findings are interesting, it clear that this prevention mechanism only works for ransomware that do not have embedded encryption keys. The work does not detail how the ransomware deletes the target files after encryption. This is important because even if ransomware manages to encrypt a victim's data, it's still possible to recover the data without paying the ransom depending on the deletion techniques employed.

Scaife et al. [24] present CryptoDrop, a dynamic analysis based early-warning detection system that informs a victim upon discovery of suspicious file activity. The system stops a process tampering with large amounts of the user’s data. Their tests provide interesting results of a median loss of only 10 files from 5,100 files. However, the whole concept is based on the premise that multiple file access is an indicator of compromise. Further, there is no provision as to what type of deletion methodology is implemented by the observed samples because even the 10 lost files could be recovered depending on the deletion methodology.

Kirda [25] approaches ransomware attacks from a qualitative point of view and argues that the majority of ransomware isn't as complex as portrayed. He argues that behavioral characteristic which are common in all ransomware can be used to detect it. The author addresses some of the deletion techniques and some of the strong encryptions used. The author contends that even access to CryptoAPI functions which is used by most crypto ransomware can be monitored. However, there is no formulation of the attack model and ransomware is broadly addressed to refer to both crypto and non-crytpo ransomware. Further deletion of the shadow volume copy and privilege escalation are not put into consideration which in essence are part of the methodologies which ransomware uses to make data recovery almost impossible.

Mercaldo et al. [26] present a static analysis method to automatically inspect ransomware sample based on Android. The dissection is executed with the goal of testing whether the malicious behavior represent a class of ransomware functionalities. Though the work is largely based on ransomware for Android systems, the deletion mechanism is not clear. Further, it's not evident how the ransomware seeks to prevent data recovery.

Cabaj and Mazurczyk [27] propose the use of SDN to mitigate ransomware attacks. The approach is based on dynamic analysis of CryptoWall whereupon two realtime mitigation approaches are proposed. The proposed SDN-based applications rely on updated databases of proxy servers of ransomwares. The work does not detail how ransomware achieves data recovery prevention. Moreover, like the other previous work, this approach only addresses those families of ransomware that need to contact the C2 server to effectuate the encryption.

• III.    Attack Structures and Related Concepts

Crypto ransomware attack methodologies come in two flavors; those employing symmetric key cryptosystems and those employing hybrid crypto systems. The former uses standard and custom symmetric key encryption algorithms for encrypting the target payload whereas the latter combines both symmetric and asymmetric key encryption algorithms to achieve the same. However, attack structures utilizing only symmetric key and custom made algorithms have been found to be weak and easily crackable to recover the data [9]. Attackers have thus shifted towards using the hybrid approach where standard symmetric algorithms, e.g. DES, AES, 3DES etc are used to encrypt the target data and the asymmetric encryption, e.g. RSA, ECC is used to encrypt the symmetric key. It’s quite obvious that symmetric algorithms are faster than their asymmetric counterparts hence their use for encrypting the payload [10]. The majority of ransomware samples are known to use the CryptoAPI from operating system’s Cryptographic Service Provider (CSP) to access cryptographic services for use in the ransomware payload. In light of the aforementioned, the attacker thus seeks to secure the private key from the asymmetric key pair. This leaves the attacker with two options:

• (1)    whether to locally generate the asymmetric key pair on the victim after infection,

• (2)    or whether to contact the Command & Control (C2) servers to download the asymmetric key pair [11].

Local Key Generation

This is the most practical and efficient method of handling the asymmetric key pair. It does not need third party communications and takes off overhead from the C2 severs. It is faster to implement as it uses the target operating system’s CryptoAPI. The drawback however is that since the seed to the asymmetric key pair generation is gotten from the local machine, it is possible, via memory analysis of persistent memory to retrieve these parameters and rebuild the key via reverse engineering. This was the major implementation weakness of WannaCry ransomware that made it possible to retrieve the RSA primes used in asymmetric key generation [12].

C2 Server Key Download

This is the ideal approach as it is practically infeasible to derive the matching private key of a public key download from the C2 servers. This was the approach implemented in Cryptowall-4 [13]. Nonetheless, this approach encounters the challenge of beaconing back to the C2 servers after a successful infection. This is only possible on the pretext that the victim has an active and steady Internet connection which can never be guaranteed. Furthermore, it requires a secure communication channel between the C2 servers and the ransomware agent.

Since the spectrum of infection vectors is so wide (from both online and offline attack vectors), it is impossible to guarantee absolute Internet connection on the victims end. This has led to attackers generating asymmetric key pairs locally on the victim as evidenced in many ransomware samples. Once the infection occurs and the subsequent encryption, ransomware seeks to incapacitate data resilience and make recovery efforts futile by deleting the original copies of the files. This is mainly done in any one of the following: (i) deleting the original file after encryption thus leaving only the resultant cipher-text (ii) overwriting the original file with random data to make restoration impossible (iii) deleting volume shadow copy snapshots in the system via vssadmin.exe. This scenario subdivides four attack instances on data resilience as elaborated in figure 1 below.

Fig.1. Data recovery attack structures

A ransomware attack on data recovery can implement any of the four attack instances depicted in figure 1. Attack methodologies employing instances 1 and 3 can easily be countered by recovery application such as

Photorec or Recuva [14] which seek to recover lost directory structures and the lost meta-data of the deleted files. In such scenarios, there’s no need to retrieve the encryption key since the deleted files can be recovered. Notwithstanding the aforementioned, most attackers employ attack structures that utilize instances 2 and 4 where recovery of deleted files using the aforesaid software resources does not apply. In such instances, recovery of the original data can only be done through decryption using the applicable encryption keys. It’s important to note that attack instances 2 and 4 are independent and so are 1 and 3.

The attack model

Using the attack structures in figure 1, we now endeavor to characterize the attack model which describes data deletion and the recovery prevention thereof as used in this paper. We fuse an attack graph and a finite state machine to express the deletion attack of target data on a victim’s system as shown in figure 2 below. The resultant attack graph is a Directed Acyclic Graph (DAG) defined as:

G_t^ = ^_ЬЕ_Ц) (1)

where the nodes N = {n_t | i = 0,1,2,3, .„} , is a set of vertices 71 j e Nt traversed to reach the goal (data deletion) and the edges E^ = { eij | i,j = 0,1,2,3,...} , is a set of arcs e[,j e E_tj representing attack actions yielding the traversal. The system starts in S_o ( Secure State - SS ) represented by whereupon infection by the ransomware transitions through t_T to state S_T ( Privilege Escalation - PE) representative of the node set { n _t,ti ₂}. The edge e _o, , leading to n , represents a malware infection into a user profile with no elevated privileges to enable execution of the ransomware. The ransomware in most cases inserts itself into a legitimate process in order to attain the required privileges thus transitioning to n ₂ via the edge e ₁, ₂ . Alternatively, some infections land the ransomware into a privileged user profile and this is depicted by the attack edge e _o,₂ to node n ₂.

Secure     Privilege        File     Shadow Copy

Upon attainment of privileged mode in state S,, the ransomware proceeds to delete the original files after encryption. This is depicted by attack edge e2.3 to node n3 and e2.4 to n4. This transitions the system to state S2 (File Deletion - FD) representative of the node set (n3,n4} via transition 12. The edge eг.3 to node n3 is infeasible because we suppose that the target system implements standard Discretionary Access Control (DAC). This would require the ransomware to be added to the target file’s Access Control List (ACL) or to take the identity of the target file’s owner, hence the privilege escalation via e4,2.

The node n ₃ represents system state upon normal file deletion corresponding to attack instance 1 of the attack structure in figure 1. Conversely, n₄ represents system state upon file deletion which encompasses overwriting the original file with random data which in essence corresponds to attack instance 2 of the attack structure in figure 1. Some ransomware are known to end here as their final goal whereas other tend to further seek to incapacitate data recover by deleting shadow copies [15]. The latter is depicted by attack edges e ₃.5 and e₄.5 which necessitates transition t ₃ leading to node n₅. The resultant is state S₃ ( Shadow Copy Deletion - SCD ) representative of a state where original data has been deleted and the corresponding shadow copies. In order characterize the linkages between the nodes, we deduce the adjacency matrix Л_M of the DAG in figure 2:

	"0	1	1	0	0	0"
	0	0	1	0	0	0
^ M =	0	0	0	1	1	0	(2)
	0	0	0	0	0	1
	0	0	0	0	0	1
	. 0	0	0	0	0	0 .

It’s vivid from the adjacency matrix that node n2 is the isthmus linking the passive infection phase and the active attack process which is the actual file deletion. Thus elimination of this node ought to be prioritized in the mitigation process. Following from the Equation (2), we deduce the possible attack paths from n0 in the secure state So to n5 in the breached state S3.

?i : n o ^ n ^ n ^ n 5

P₂ : n ₀ ^ n ₂ ^ n ₄ ^ n ₅

P₃ : n o ^ ^ ^ n ^ n ^ n 5

P₄ : n o ^ n_T ^ n 2 ^ n 4 ^ n 5           (3)

Even though path P_t appears to be a subset of P₃ and path P₂ a subset of P₄, they are all independent unique paths. The similarity entails the two possible states in and S₂ represented by the node set (n_T,n₂} and (n₃,n₄} respectively. If we let the parameters p^. (p_k . a)_k to denote PE , FD and SCD respectively, where к is such that к e [-, +] , then we can express any given state as a function:

Sn(Pit, tok) where n € ( R U (0}}(4)

Since state S ₃ has only one possible state represented by , the corresponding status equation can be expressed as:

S3 (Pk-Pkto) = to(5)

If we let p _ and p₊ to represent privileged and unprivileged mode respectively, then the state equation for state S ₁ is an exclusive OR operation expressed as:

S1 (Pk. Pk. tok) = P- ® p +

In the same vein, if and represent original file deletion and original file overwriting , the state equation for state is thus expressed as:

S2 (Pfc.Pк, tok) = P_®P+

The exclusivity in Equation (6) and (7) entail that although path appears to be a subset of and path a subset of , they are independent events. Even though it is possible for ransomware to run two distinct processes; one in unprivileged and another in privileged mode, it defies attack logic and it’s only reasonable to postulate that the attacker will want to run in privileged mode or otherwise but not both modes. In the same manner, most ransomware will either delete or overwrite the original file after encryption [16]. Having described the attack model, we now endeavor to demonstrate the ransomware attacks that seek to breach data availability via deletion after encryption and prevent recovery efforts.

• IV.    Experiment Set-up and Methodology

We employ two approaches to all ransomware samples in our experiments: reverse engineering (static analysis) and behavioral analysis (dynamic analysis). These analyses are performed in a confined sandbox environment in conformity to recommended best practices [17].

Static Analysis

In static analysis, we perform an autopsy to extract malware features without running it and analyze the source code fragments for functions and directives related to data deletion and recovery prevention. In the same manner, we look at some features that counter malware analysis since it’s through such analysis that we seek to implement data recovery. Further in this analysis, we use a range of malware analysis disassembly tools not limited to Ollydebug, IDA Pro, Dependency Walker etc for dissection of the malware code internal logic. The diagram depicted in figure 3 below illustrates the stages we employ in reverse engineering.

Finger Printing

Input Malware Sample

Obfuscation Checks

Embedded

Strings Checks

Assembly Code Analysis

Fig.3. Summarized static analysis stages

Crypto Hashes

Virus Scans

Meta-Data Extraction

In stage 1, we ready our ransomware samples. We select a wide range of specimens including the latest samples at the time of writing not limited to WannaCry, Cerber, Cryptowall, Locky etc which dominate the ransomware landscape accounting for 90% of the attacks [18]. We begin the extraction of external features in stage 2 where we compute the samples’ cryptographic hashes to determine their identities. We further solidify the samples’ authenticity and extract extra features by submitting them to reputed malware databases Virustotal.com, Malwr.com and Virscan.org. This removes false negatives and detects any changes in the original source code. We counter-check for obfuscation in stage 3 to determine whether the malware author compressed, encrypted or altered the ransomware contents. Thus we check whether the sample has been packed to disguise the internal program logic. In stage 4, we check for embedded strings related to file deletion and recovery prevention and any other relevant strings. We extract the meta-data in stage 5 by parsing the executables through corresponding tools (PEView and Resource Hacker). Finally, after having extracted all these external features, we proceed to stage 6 where we disassemble and debug the code using IDA Pro and Ollydebug respectively and hunt for techniques employed to delete target data and prevent the recovery thereof as elaborated in the preceding section.

Dynamic Analysis

We perform the second class of tests where we actively interact with the malware by running it in a sandbox environment and polling the associated behavioral features. The test-bed for dynamic analysis, as shown in figure 4 below, comprises two components: the serverside and client-side component.

The server-side component is a Linux system (Ubuntu) running Cuckoo sandbox and Volatility whereas the client-side comprises virtual machines of different versions of the Windows operating system. We limit our scope to the Windows desktop edition considering its widespread use [19]. We deliver the ransomware to the victim using the Cuckoo server console and collect all the behavioral features of the ransomware from the generated report. We seek limit the network activity to “host-only” and disable DNS resolutions for those samples with killswitch domains as discovered during the static analysis stage. Since the infection vector is not relevant according to the attack model, we iteratively use the Cuckoo server console to deliver the ransomware to all the victims by specifying the IP addresses of the victim virtual machines. We collect all relevant features from both static and dynamic analysis and tabulate them in the proceeding results’ section.

• V.    Results and Analyses

In order to ensure that data recovery efforts stay futile after a ransomware attack, malware authors employ two main approaches; one directed towards a victimized user seeking data recovery and one towards a malware analyst experimenting on the ransomware in a contained environment. Attack techniques directed to a victimized user include deleting the original file after encryption, overwriting it, deletion of volume shadow copies and the use of resilient standard encryption to make decryption of the victimized files impossible. In the case of WannaCry, the procedure just before deletion of the original files is shown in the code snippet in figure 5 below.

GetWindoMsDirectory W(pathTot1oueFiles, МЙХ_РЙТН);

if ( «pathToHoueFiles == diskLabel ♦ "й" ) <

GetTempPathW(MflX_PftTH, pathToHoueFiles);

if ( wcslen(pathToHoueFiles) 66 pathToHoueFiles[ucslen(pathloHoueFiles) - 1] ( pathToHoueFiles[ ucslen ( pathToltoueFile:) - 1] • O; return pathToHoueFiles;

else < swprintf(pathToHoueFiles, L"%C:\\%s", (diskLabel * 'fl'), L"$RECVCLE");

CreateDirectoryW(pathTol1oueFile , 0);

sprintf(61pConnandLine, "attrib »h *s %C:\\%s", diskLabel ♦ "й", "$RECVCLE") CreateProcess(6IpConnandLine, 0, 0);

• Fig.5.    Procedure for handling files designated for deletion

The last part of the code creates a temporal directory “$RECYCLE” where targeted user files meeting the conditions stated in the first part of the code are moved to. The ransomware obfuscates this directory using the attribute "attrib +h +s" in order to hide it from the Windows Explorer. Upon proper synchronization in the code, the targeted files are deleted and not overwritten. However, if errors occur in the synchronization process, targeted files might not actually get deleted but will remain hidden in the “$RECYCLE” directory or might not even be moved at all. This un-thorough way of deleting files is unsecure and targeted files can be recovered using recovery software discussed in the preceding section.

However, if the targeted files reside in directories classified as “priority” , the ransomware alters the deletion methodology. This is shown in figure 6 below.

SHGetFolderPathW(0, CSIDL_DESKTOP, 0, 0, GpszPath);

ProcessDir(wannaCtx, &pszPath, 1);

LOWORD(pszPath) = 0;

SHGetFolderPathW(0, CSIDL_PERSONAL, 0, 0, bpszPath);

if ( wcslen(6pszPath) )

ProcessDir(wannaCtx, bpszPath, 1);

ProcessDriues(CSIDL_COMMON_DESKTOPDIRECTORV, callback_Proi ProcessDriuesCCSIDL^COMMON^DOCUMENTS, callback_ProcessDir

• Fig.6.    Deletion of “priority files” via overwriting

After having deleted the files as specified above, the ransomware goes further to prevent any system recovery by deleting volume shadow copies with the command:

This deletes volume shadow copies and all created system restore points and further disables any debugging of startup errors. However, this is a privileged command and for systems configured with User Account Control (UAC), the following window pops up:

Fig.7. UAC seeking volume shadow copy deletion

It’s only at this time window that the victim might have a chance to restore their data depending on their action. However, if the command is invoked in root mode or if UAC is disabled (as specified in the attack model), the victim might not encounter this pop up.

At this point, the data recovery prevention techniques by the ransomware are complete. It proceeds to make itself persistent by adding corresponding registry entries and enlisting in the startup so that the malware runs each time the system is restarted. There are other actions that the ransomware performs such as network activity, checking if the victim is already infected, trying to propagate on port 445 to exploit the SMB vulnerability [20] on unpatched systems etc.

The ransomware observed herein mostly used functions present in the operating system to effectuate the actual encryption. The most commonly observed encryption algorithms were RSA and AES. The RSA was mainly used to encrypt the symmetric AES key whereas the AES itself was used to encrypt the actual files. The diagram below in figure 8 shows one of the observed cryptographic algorithms used by some samples. We collect a couple of external features of the samples from the analysis methodology presented thus far. Some samples of the same family had different variations depending on year in which they were released in the wild. Such variations include update to loopholes and errors in the code that made data recovery possible.

aMicrosoftEnhan db 1 Microsoft Enhanced RSA and		AES Cryptographic Provider XREF: sub_k0182C*iqto
align 4	; DATA
; CHAR aCryptgenkey[] aCryptgenkey    db 'CryptGenKey',0	; DATA	XREF: sub_k01 A
; CHAR aCryptdecrypt[] aCryptdecrypt db 'CryptOecrypt',0	; DATA	XREF: sub_k01Ak5»SBto
align 10h ; CHAR aCryptencrypt[ ] aCryptencrypt db 'CryptEncrypt',0	; DATA	XREF: SUb_O01A4S»NEto
align 10h ; CHAR aCryptdestroyke[] aCryptdestroyke db ‘CryptOestroyKey‘,0	; DATA	XREF: subh01AkS*qito
; CHAR aCryptinportkey[] aCryptinportkey db 'CryptInportKey',0	; DATA	XREF: sub_k01A45«3kTo

DATA XREF: SUb_kOink5*2Cto align 10h

; CHAR aCryptacquireco[]

acryptacquireco db 'CryptAcquireContextA',0 align к dd offset a doc          : "

.doc"

Fig.8. Ransomware encryption routines

Table 1 below shows external features of 10 different samples used in the experiment. We specify the methodology used by each sample to extract the encryption key, whether to download from the C2 server after initial beaconing or use the operating system’s CryptoAPI.

Table 1. External features for various samples

Sample	Key Gen. Method	Public Key	Private Key	CSP	File Size
Sample1 (Cerber)	Local	RSA	RC4	ECP	244 KB
Sample2 (CryptoWall)	C2 Download	RSA	RSA	ECP	404 KB
Sample3 (WannaCry)	Local Generation	RSA	AES	ECP	3636 KB
Sample4 (Locky)	C2 Download	RSA	AES	ECP	116 KB
Sample5 (TeslaCrypt)	Local	ECC	AES	BCP	384 KB
Sample6 (Petya)	Local	ECC	Salsa20	-	788 KB
Sample7 (Gpcode)	C2 Download	RSA	AES	ECP	29 KB
Sample8 (CTB-Locker)	Local	ECC	AES	ECP	1173 KB
Sample9 (CryptoLocker)	C2 Download	RSA	AES	ECP	549 KB
Sample10 (NotPetya)	Local	RSA	AES	-	309 KB

We observed in the samples that the majority generated encryption keys locally. Local key generation accounted for 60% while C2 Download accounted for the remaining 40%. It was noted however that most newer versions of those that originally downloaded the encryption key were able to begin the attack process even without communicating to the C2. A shift towards ransomware attacking without contacting the C2 servers could only be explained that it’s not always that the target host will have an Internet connection or firewalls and IDS might actually restrict network access depending on the scenario.

Almost all the samples used a public key to encrypt the symmetric key that encrypted the files. Those that did not need to contact the C2 to attack came with an embedded public key of which RSA accounted for 70% while the remaining 30% was ECC. It’s observed that most recent ransomware versions are shifting towards using RSA for asymmetric key encryption. The RSA public key is usually not used to encrypt user files due to its computational intensiveness resulting in significant CPU like in the case of CryptoWall. The majority of ransomware (80%) used symmetric block ciphers for file encryption with AES accounting for 70% while the stream ciphers accounted for 20% which included RC4 and Salsa20.

Almost all the samples made use of the CryptoAPI provided Microsoft Cryptographic Services. The Enhanced Cryptographic Provider (ECP) library accounted for 70% due to its provision of stronger security via longer keys and additional algorithms while the Base Cryptographic (BCP) was observed in one sample. The average file size of the ransomware payload was about 750 KB. Such a small size of less than a Megabyte is easily downloadable and unnoticeable. The ransomware once run tries to hide by assuming the identity of a trusted process or injects itself into one.

We further tabulate behavioral characteristics of the samples that seek to make data recovery impossible and present them in Table 2 below with other related characteristics of the samples.

Sandbox Evasion

It was observed that a number of the sample employed some techniques to conceal their operations and thus make data recovery even harder. The ransomware checks against a number of conditions and would not run if a condition is satisfied. Others actually would go ahead to crash the debugger once detected. The diagram in figure 9 below shows sandbox evasion against Virtual Box. The malware checks if the VBoxService.exe is running and if it detects such a process, it will switch into sleep mode and there will be no further analysis. This will inhibit efforts to find out how the malware operates and that subsequently thwart any sought data recovery attempts whatsoever in this respect.

call    subji88828

leave retn sub_«i08B09 endp

• Fig.9.    Sandbox evasion against virtual box

leave retn sub_4№B1l> endp

• Fig.10.    Sandbox evasion against Wireshark

  

  Fig.11. Sandbox evasion against kill switch

  
  

Table 2. Behavioral features and Characteristics

Sample	Delete Orig. File	Overwrite Orig. File	Delete Shadow Copy	C2 Beaconing	Sandbox Evasion	Persistent Presence	First Appeared
Sample1 (Cerber)	✓	✓	✓	-	✓	✓	2016
Sample2 (CryptoWall)	-	✓	✓	✓	✓	✓	2014
Sample3 (WannaCry)	✓	✓	✓	-	✓	✓	2017
Sample4 (Locky)	-	✓	✓	✓	✓	✓	2016
Sample5 (T eslaCrypt)	-	✓	✓	-	✓	✓	2015
Sample6 (Petya)	-	✓	✓	-	✓	✓	2016
Sample7 (Gpcode)	✓	✓	-	✓	-	-	2004
Sample8 (CTB-Locker)	✓	✓	-	-	✓	✓	2014
Sample9 (CryptoLocker)	✓	✓	-	✓	✓	✓	2013
Sample10 (NotPetya)	✓	✓	✓	-	✓	✓	2017

; httribvlrs: bp tiaard Prone nub ЙМВ6 0 proc nrjr war 128- dword ptr  128h war 12*- dward ptr  izxn war IBC- dword ptr  tOCh puah    rbp | now     rbp, rap tub     »*P . 178h        ; IpClonsHanr lea     rax. [rbp«war_1SCJ now     dword ptr [гак], SPNCbCNfh now     award ptr [гак»)], NZAZNbb now     [eip«l7Kh«var 1?*|, В now     (rap*128h«vor 128), rax call    FindVimlovd sub     rap, s           ; hObJect tint    rax. rax

Jz      abort locrrt NW8A8

Fig.12. Sandbox evasion against Ollydebug

Explicit PID: 3472

C06B8289E0F6F53C8084A962D23F927...........................................................................................................................

Exponent 010001

Searching for primes numbers in memory..........

Primel

F6F35985D35ElD232AAAECC3712E56D8EClE8B180FEFAAE6E27D9EBlB31D24A97B5669A6C7Bt

BCC77D1FF30102F91DD6...............................................................................................................................................

Prime2

BE3BD0E14336D6EAADA58195471132DC8377ADF925A16D9BD7BC009694E7A68B6A3A3B0A0CF^

7C5 0D5D 3 F E C41A3 213 В F F A3 65В................................................................................................................................

File c:\Documents and Settings\All Users\Application Data\Microsoft\User

File c:\Documents and Settings\All Users\Application Data\Microsoft\User

Fig.13. Target file decryption using primes left in the ransomware allocated memory

In the same manner, some malware look for other virtualizations services such as VMware and Qemu. Some malware implement sandbox evasion against efforts to sniff commutations to C2 servers as show in figure 10 above. Since Wireshark is one of the most used packet sniffers, the malware checks to see if such a process is running and if so detected, it won’t run. However, this check is done on the guest running the sandbox, so a solution would be to run the packet sniffer from another host but in the same subnet. The WannaCry sample we ran checks against a kill-switch to check if it was running in a sandbox environment. However, a newer version of the ransomware does not include the kill switch domain.

Figure 11 above shows a check against such a kill switch. The ransomware checks to see if the fake nonexistent domain is reachable. Such a domain would only be reachable in a sandbox environment where automatic valid DNS responses are present.

Kill switch domains were eliminated in new WannaCry strains because security researchers registered some of these fake domains consequently leading to the ransomware not running when it beacons to such domains.

The sandbox evasion techniques discussed thus far are directed towards dynamic analysis. Newer ransomware strains, however, employ sandbox evasion techniques against static analysis as. These target analysis and debugging tools as shown in figure 12 above.

In the above code, the targeted analysis tool is even encoded. The arguments 594C4CFh and 474244h when converted to ASCII read “YLLO” and “GBD” respectively which is equivalent to Ollydebug when read in reverse. Basically the malware checks for an Ollydbg window via the call FindWindowA and prevents any further analysis if the condition is met.

We observe in Table 2 that almost all the samples employed some form of either dynamic or static analysis sandbox evasion, with the majority against dynamic analysis. Earlier versions of Gpcode showed fewer signs of sandbox evasion if any at all, apparently due to the fact that it represents one of the earliest forms and not a new form of ransomware. It’s only in later versions that it started to include complicated techniques such as RSA and AES encryption. It can be observed form Table 2 that as ransomware matures, so do the techniques employed to make data recovery impossible. This is evidenced throughout the timeline where earlier versions did not give priority to shadow copy deletion and use of unsecure deletion techniques. Furthermore, recent versions likewise do not need to contact the C2 server to effectuate an attack. They come with embedded public keys, mostly RSA, with which they encrypt the public key of the subpair of the locally generated RSA keys after it encrypts the AES key which actually encrypted the original user data.

However, the tendency to generate an RSA key pair on the targeted host has brought the possibility of fetching off from running memory the seeds used in such key generations. The figure above in figure 13 shows the successful decryption of WannaCry victim files using

Wanakiwi [21] after having fetched from memory the primes used in RSA sub-key pair generation.

It’s worth noting however that the above method of data recovery only works if the memory allocated to the ransomware process is not flushed or overwritten. That is to say that the victim shouldn’t restart his machine among other things, which is quite the contrary in the event of an unexpected attack.

• VI.    Recommendations and Best Practices

Ransomware seems not to be leaving us anytime soon. If anything, with the advent of Ransomware as a Service (RaaS) [22], its activities are only expected to be on the rise and users should brace themselves against such attacks. Ransomware is best prevented than cured. That is to imply that security measures against ransomware ought to be proactive and not reactive. A reactive approach will always force the victim to seek recovery efforts which are not 100% percent guaranteed. Mitigating ransomware requires a different approach as opposed to that when dealing with conventional malwares because subtle errors can lead to indefinite loss of data. Offline backup is strongly recommended because new malware strains such as WannaCry and NotPetya introduce worm capabilities enabling them to traverse a compromised network and attack any online backup on the network. Users should always keep their systems updated and have their security vulnerabilities patched because new malware versions capitalize on such loopholes. Considering the diversity of attack and infection vectors, backups alone aren’t enough. Network and local security should be implemented which should not allow unsanctioned privilege escalation since it’s noticed that deletion of volume shadow copies requires privileged access. In the same manner, since ransomware on average seeks to delete volume shadow copies, offline backup of volume shadow copies is highly recommended since it’s possible to restore a system from offline backed up volume shadow copies. Last but not the least, user training and awareness should always be factored in when implementing a security plan. It’s the benign actions of users that lead to ransomware attacks because on average, ransomware requires some form of user action. This could be as simple as opening an attachment, visiting a webpage harboring an exploit kit, running a macro in an office application or simply opening up a PDF document.

• VII.    Conclusion

The approach used to evaluate data deletion attacks by ransomware, as presented in this paper, shows that data recovery after a ransomware attack is possible depending on the attack structure. Ideal attack structures have shown that public keys ought to be generated on the C2 server and later propagated to the ransomware upon successful beaconing after an attack. This, coupled with secure data deletion techniques would make data recovery almost impossible. However, we observed that this is not the attack structure implemented by the majority of ransomware families, especially the recent ones, owing to the complexity of interlinked factors. The other attack structures are prone to full data recovery the degree of which is dictated by the data deletion methodology implemented by the ransomware. Though almost all ransomware variants seem to seek to delete volume shadow copies, offline backup of shadow copies before ransomware attacks and their subsequent restoration would restore data to the same level of the backup. Though almost all ransomware employs some form of sandbox evasion techniques directed against dynamic and static analysis, it is still possible to restore ransomed data especially in with the current methodology of generating public key pairs using the victimized host. From our study, we are led to conclude that no matter how devastating a ransomware attack might appear, the key to data recovery options lies in the underlying attack structure and the implemented data deletion methodology.