Discovering Encrypted Bot and Ransomware Payloads Through Memory Inspection Without A Priori Knowledge
Peter McLaren William J Buchanan Gordon Russell Zhiyuan Tan
cs.CR









Discovering Encrypted Bot and Ransomware Payloads Through Memory Inspection Without A Priori Knowledge
    Peter McLaren, William J Buchanan, Gordon Russell, Zhiyuan Tan
School of Computing, Edinburgh Napier University, Edinburgh, UK.

    December 30, 2023
====================================================================================================================================







Malware writers frequently try to hide the activities of their agents within tunnelled traffic. Within the Kill Chain model the infection time is often measured in seconds, and if the infection is not detected and blocked, the malware agent, such as a bot, will often then set up a secret channel to communicate with its controller. In the case of ransomware the communicated payload may include the encryption key used for the infected host to register its infection. As a malware infection can spread across a network in seconds, it is often important to detect its activities on the air, in memory and at-rest. Malware increasingly uses encrypted channels for communicating with their controllers. This paper presents a new approach to discovering the cryptographic artefacts of real malware clients that use cryptographic libraries of the Microsoft Windows operating system. This enables malware secret communications to be discovered without any prior malware knowledge.



    

    

    



network traffic; decryption; memory analysis; Transport Layer Security; bot; ransomware





§ INTRODUCTION




    

    


    


    

    

    
    

Malicious actors employ secure channels to hide communications from detection agents. These channels enable activities such as the installation of exploit kits, distribution of malware and adware, and communicating useful information to controllers. So, knowledge of channel contents is unknown while malicious use of secure channel surges - a cloud vendor blocked 1.7 billion threats using TLS in he second half of 2018 <cit.>. Malware classes that frequently uses TLS secure channel for communications are bots and ransomware.

The ransomware element of an attack can be defined as the weaponisation part, where a ransomware element can be packaged with a defined distribution and infection methods, and then targeted as required. The first phase of ransomware, such as WannaCry, was often fairly scattergun in its targets, but the usage of ransomware in targeted attacks increases. In 2019, Symantec found that enterprise-targeting ransomware showed a yearly increase of 12% and attacks on mobile devices rose by 33% <cit.>. With WannaCry we saw the weaponisation of ransomware, which used the Eternal Blue vulnerability for its infection. The NHS in the UK was but one organization of many who suffered major outages from the ransomware infection <cit.>.

Modern bot malware is generally multi-purpose. Once installed on a client, an external controller determines bot activities through issued commands. Encrypted controller-to-bot channels prevent defenders from discovering commands. Ransomware clients are generally single purpose in that users pay to recover document or device access. Crypto-ransomware, where documents on an infected client are encrypted and a payment is required, typically in Bitcoins, for the decryption key, is a common variant <cit.>. Communications between crypto-ransomware clients and controllers may include useful information such as encryption keys.
 
Current methods of dealing with malicious use of secure channels have limitations. Whereas in unencrypted channels, payload inspection provides knowledge of malware activity, with encrypted channels, detection methods rely on discovering anomalies between benign and malicious activity. These methods assist in the detection and possible prevention of possible malicious activity but cannot provide detailed knowledge of the malicious activity.


    
This paper investigates decrypting TLS communications of real-world malware. A framework uses a standard approach for decrypting TLS traffic to analyse and decrypt the secure communications. For malware, performance challenges can result from malware use of different cryptographic libraries. So, the framework is extended to accommodate the Windows cryptographic library. Experiments evaluate decrypting real bot and ransomware command and control communications using the extension. The contribution is a novel method to discovering cryptographic artefacts used by real malware. As these are discovered in single memory extracts and decrypted in less than a second, the communicated activities of unknown malware can be discovered.



The rest of the paper is structured as follows. Related research on malware command and control channels is presented in Section II. Section III discusses sourcing of real-world malware samples while Section IV evaluates and discusses the limitations of decrypting using a standard TLS decryption methodology. An new approach for decrypting traffic using Windows cryptographic libraries is presented in Section V. The results are presented and discussed in Section VI and conclusions drawn in Section VII.








§ RELATED WORK



A number of papers focus on memory inspection to discover the malware threat using calls to APIs. Gupta et al <cit.> analysed API calls within Windows and mapped a total of 534 important API calls with 26 categories (A-Z). These were then used to identify five types of malware (Worm, Trojan-Downloader, Trojan-Spy, Trojan-Dropper and Backdoor). Hampton et al <cit.> furthered this work by analysing 14 strains of ransomware on Windows platforms and created mappings of the API call frequencies.

Other studies detect the presence of malware command and control channels. Signature-based detection systems that check for known byte sequences in packet headers or payloads may be less successful with new malware variants or encrypted traffic. So, anomaly detection methods using data mining methods <cit.> can distinguish benign from malware traffic. For example, features such as correlations between malware channel request and response times <cit.>, short packet sizes <cit.>, TLS header information <cit.>, or a combination of features <cit.> are possible differentiators. The features facilitate malware detection and prevention but the encrypted contents are hidden.

Controller emulation can discover malware client plaintext. Logging client requests may provide useful insights although cited challenges may be environment security, scalability for large botnets, and transparency, where malware detects the presence of a test environment and terminates <cit.>. Although a controlled environment is advantageous
<cit.> and can be used to detect adversaral activities <cit.> emulator drawbacks for decrypting real-world malware communications may be not knowing valid controller responses but, perhaps more importantly, the malware must be known a priori to execute in the environment.

Patil et al <cit.> define an investigation framework for analysing captured memory for the detection of malware using information from processes, running threads, opened registry keys, and user authentication details. Google, too, focus on memory inspection for the detection of malware <cit.> and use a number of virtual machines to detect anomalous behaviour.

Feichtner et al <cit.> defines a method of detecting cryptographic misuse in Apple iOS applications. Their work uses a decompilation method to analyse the code calls to the core cryptographic libraries. In their analysis they found that 82% of the applications sampled had a cryptographic flaw. For this they defined six main rules to identify a cryptographic flaw. These included: the usage of the ECB mode for encryption; the usage of a non-random IV for CBC encryption; and the usage of constant encryption keys. Most of flaws found related to the usage of a non-random Initialization Vector (IV) and the usage of constant encryption keys. They also found that 27% of the sampled apps used ECB (Electronic Code Book) for the symmetric key encryption.

A priori malware knowledge may also enable plaintext discovery. While virtual machine environments, such as DRAKVUF <cit.>, support malware dynamic analysis, such solutions succeed only where actual, or suspected, malware is obtained.  Our approach requires no prior knowledge so discovering the plaintext in the encrypted communications of unknown malware is possible.

Discovery of malware cryptographic artefacts may enable their communications to be decrypted. For example, researchers have discovered TLS encryption keys in memory <cit.>. Initialization vectors were not discovered, which for commonly-used AES-GCM encryption is necessary, so plaintext was not derived. Furthermore, whereas keys were discovered in Linux memory, malware is still predominantly Windows-focused <cit.>. 




§ SOURCING MALWARE SAMPLES

Malware communications analysis ideally executes real malware samples. Samples of recent provenance are preferable as these may reflect the approaches of modern malware authors, Maintained online databases provide guides to current usage. For SSL traffic, the SSL Blacklist website <cit.> lists bot and ransomware clients in reverse chronological order of awareness. From the list, 35 potential malware entities were identified. For each, multiple client executable samples were downloaded in compressed, password protected from the VirusShare website <cit.>. 

The compressed files are securely copied to the client. on which Windows Defender is disabled, the compressed files uncompressed and executed. As the responder acting as a malware controller was not configured to respond appropriately, only three executables successfully established a TLS connection including a data exchange with a server running the OpenSSL server application <cit.>.

The three malware executables are listed in Table <ref> followed by pertinent background.




Zbot, also known as ZeuS or Zeus, is a well-known bot malware instance. Detected in 2006 <cit.>, Zbot is primarily known for stealing banking passwords by injecting code into a user browser as illustrated in Figure <ref>. Other Zbot functionality includes extracting information such as browser history and cookies, certificates, and mail account information as well as perform actions such as manipulate local files, install ransomware, log keystrokes, take screenshots, and manage a botnet of other infected computers <cit.> <cit.>. Although Zbot previously used the HTTP protocol for communications, information and commands are now generally concealed with TLS.

 

Gozi, also known as Ursnif inter alia, is also an information-stealing bot. Detected in 2007 <cit.>, Gozi is commonly used by malicious actors for stealing and other confidential banking information <cit.> <cit.> <cit.> as shown in <ref>. Although functions include theft of cookies and email credential, and logging of keystrokes and browsing activity <cit.>, a key feature is intercepting network traffic to hijack financial transactions. For example, when a money transfer is detected, Gozi issues an encrypted message through its command and control server to prevent the correct transfer and redirect the funds to a controlled account <cit.>. 

 

TorrentLocker is an instance of crypto-ransomware. Known since 2014, sufficiently similar to CryptoLocker to also be known as Crypt0L0cker, it encrypts user documents including pictures, advises the user of its action, and demands payment using Bitcoins <cit.> as indicated in Figure <ref>. Although client-controller communications were previously encrypted using XOR, TLS is now a common communications mechanism <cit.>. Information transmitted to the controller includes the ransom page, the encryption key which is RSA-encrypted with a TorrentLocker public key, counts of encrypted files, address book contacts, email credentials, and logs <cit.>.

 


    
    


§ APPROACH

The analysis framework executes in a virtualized environment, A hypervisor supports a virtual machine monitor executing on a privileged virtual machine, a suspect client virtual machine executing malware samples, and virtual machines providing server functionality for client communications. The framework extracts read/write client virtual machine memory, analyses memory extracts to discover small sets of candidate cryptographic artefacts, and decrypts  encrypted network traffic until a decrypt is validated. The framework accommodates SSH and TLS protocols and encryption algorithms such as AES and ChaCha20.

A standard TLS extension searches memory extracts for key blocks that a pseudo-random number generator (PRNG) create after the handshake. For AES-GCM, the agreed encryption algorithm for each malware sample, key blocks contain client and server encryption keys, and client and server implicit initialization vector (IV) segments. MemDecrypt memory analysis searches for key blocks following the process illustrated in <ref> where the explicit IV segment in an Application Data network packet enables searches for candidate implicit IVs, which enable candidate key block discovery. Candidate implicit IVs are memory extract segments co-located with explicit IV segment values. Candidate key blocks are memory extract segments co-located with candidate implicit IV segments and where the key block client key and server key exceed a threshold. 

 



 §.§ Test Environment

The Xen Project 4.4.1 hypervisor runs on a Core 2 Duo Dell personal computer with 40 GB of disk storage and 3 GB of RAM,  It supports a privileged hypervisor console running Debian release 3.16.0-4-amd64 version and the MemDecrypt framework. and three unprivileged virtual machines. Experiments execute on a Windows client and a Linux server virtual machine. The client runs the Windows 10 (10.0.16299) operating system with 2 GB of memory and 40 GB of disk, and the  server runs an Ubuntu 14.04 build (“Trusty”) with 512 MB of allocated memory and 4 GB of disk storage. 

The environment is configured for malware containment. The malware client is prevented from communicating with external servers to prevent possible corruption of other environments. So, an additional Linux machine running Ubuntu 14.04 build (“Trusty”) with 512 MB of allocated memory and 4 GB of disk storage is established as a DNS server using the ‘dnsmasq’ package. Responses to benign DNS requests, such as *.microsoft.com, return the DNS server IP address and to other requests the IP address of the target TLS server. For the first experiment, debug mode was enabled to log keys, IVs and plaintext. The OpenSSL server command used was:


openssl s_server -accept 443 -debug -cert crt.pem -key key.pem -WWW



 §.§ Results

With Zbot, the application of the standard TLS extension to memory extraction and analysis, the decrypt analysis component  was projected to require approximately 34 hours to identify correct artefacts. By excluding artefacts less than 1000 bytes apart in memory extracts, this reduced to 15 minutes so the combined analysis duration was 38 minutes. Although quicker than brute-force, cryptanalytic, and side-channel approaches, the duration may be insufficient for practical application in live scenarios. Furthermore, the duration is substantially longer than earlier experiments with, for example, the OpenSSL library, warranting further analysis. 

Two factors cause this increase. One is the 8-byte explicit IV segment obtained from an Application Data Message. For Zbot, the first explicit IV segment is '0x0000000000000001' as illustrated in the highlighted section of the Wireshark packet capture in Figure <ref>. This byte sequence occurs more frequently than randomly generated explicit IVs in memory extracts. So, when the explicit IV is used to discover possible four-byte implicit IV segments, 578,629 possible instances were found. Entropy measure thresholds reduced the candidate key block size to  23,361. By contrast, an experiment with an OpenSSL client application yielded three candidate implicit IVs and 79 candidate keys. 

 

The other factor is masquerading. To evade detection, malware applications may camouflage their activities and one such mechanism is masquerading as a benign application so the malware may also be known as a ‘trojan’. In the Windows environment, examples of benign applications used for masquerading includes the Edge browser and Windows Explorer. However, when Zbot masquerades as the Windows Explorer, for example, the data collection component extracts 265 read/write memory files totalling 73.2 MB for each separate extraction. The combination of these two factors leads to large sets of candidate keys and IVs. 



§ WINDOWS LIBRARY EXTENSION

Memory extract features suggest a more efficient alternative. Using the session key and IV from OpenSSL server logs, a search of malware client application memory yielded interesting facts: the key occurs frequently in different extract files, memory extract files sizes containing the key are within specific ranges, and two unusual ASCII strings are present near encryption key locations in the memory extract files.

The repeated occurrence of the key in memory extracts may result from data protection or an absence of data cleansing. After a TLS handshake when client and server keys have been generated by a pseudo-random generator, the keys may be copied to record data structures for simplified access by the encryption process. The malware may copy the keys repeatedly to ensure access. Alternatively, the malware writer may copy keys on different occasions but fail to cleanse the source or copy. In any case, this feature is not used in the extension.

Sizes of memory extract files containing encryption keys ranged between 2 MB and 4 MB. Consistent with prior SSH and TLS investigations, the size probably originates from an application memory allocation request (‘malloc’) for a data structure to hold the encryption, or decryption fields such as keys, encrypt/decrypt flags, key length, mode, etc. As illustrated in Figure <ref> which maps the number of segments above a 4.5 threshold (Y-axis) against the extracted size (X-axis), the distribution of high-entropy counts in malware application memory suggests that prioritizing regions for analysis may speed up the IV and key discovery process.

  



The presence of specific ASCII strings in memory extracts containing keys is more significant. The strings are ‘3LLS’ and ‘KSSM’, or in big-endian format" 'SSL3’ and ‘MSSK’. Researchers identified ‘MSSK’ in the Windows security policy application, Local Security Authority Subsystem Service (LSASS) as a possible acronym for ‘Microsoft Symmetric Key’ or ‘Microsoft Symmetric Key’ <cit.>. ‘SSL3’ may refer to the deprecated forerunner of TLS, SSLv3. Kambic identified probable fields in the undocumented LSASS data structure including: encryption data structure sizes; TLS version; and the encryption key. The field identified by Kambic as the probable IV field is inconsistent with MemDecrypt memory extracts. The implicit IV is located approximately 20 bytes after the ‘3LLS’ string, and the key approximately 30 bytes after the ‘KSSM’ string. Although random occurrences are possible, the strings provide good indicators for identifying candidate memory extracts containing cryptographic artefacts when Microsoft security libraries are used.

A MemDecrypt extension to decrypt TLS communications from executables that use Microsoft security libraries accommodates these features. Microsoft encryption libraries are assumed When TLS Application Data messages contain explicit IV values of ‘x0000000000000001’, Additional techniques such as the identification of executable linked libraries might validate this assumption. Extract file sizes are banded to prioritise medium-sized files. The extract files are searched for the ASCII strings and fields in near locations in the same extracts and of sufficient entropy to be candidate keys and IVs are identified. The Microsoft memory analysis algorithm is shown in Algorithm <ref>. The banding is wider, and the maximum allowable distances in memory between '3LLS' and a candidate IV, and 'KSSM' and a candidate key exceed the empirically observed values to allow for potential data structure changes, as may result from operating system upgrades. The entropy thresholds for 'IVsize' and 'keysize' are set to 1.5 and 4.5 respectively based on previous experiments with PRNG functions. If the Microsoft library extension fails to find cryptographic artefacts, the TLS extension provides a fall-back.

 




§ WINDOWS LIBRARY EXTENSION EVALUATION
  
Experiments were executed to evaluate the Windows library extension. Each malware sample was executed on a Windows 10 client, memory extracted and Ubuntu OpenSSL server logs collected. Analysis decrypts were validated by evaluating compliance with HTTP 1.1 and comparison with server logs. An example of Zbot decrypted analysis output is illustrated in Figure <ref> and verification provided by the OpenSSL server log shown in Figure <ref>. Each Zbot, Gozi, and TorrentLocker samples decrypted with 100% success. Decrypt output examples for all malware samples are shown in Table <ref>. Host names and GET image names vary for different test runs, and furthermore, Gozi decrypts produce POST as well as GET requests.

  

  




Analysis component durations for each malware sample confirm the extension’s performance. As illustrated in Table <ref> the maximum combined duration for memory analysis and decrypt analysis is below 1 second, a direct consequence of reduced candidate cryptographic artefact set sizes. With the Microsoft library extension, the set sizes range between three and six, and IV set sizes between 79 and 483.




 §.§ Analysis

The small experimental set size might inhibit complete confidence in the extension's capacity to decrypt encrypted malware command and control traffic. When malware writers have developed custom security routines, analysts have broken them easily broken so known cryptographic libraries are more commonly used. Microsoft library presents a good opportunity for malware writers being pre-loaded with a Windows operating system. Use of libraries such as OpenSSL would require additional download increasing the risk of detection. It is concluded that payloads of secure TLS communications between malware clients executing on Windows clients and their controllers can be rapidly discovered.

Decrypting a single request is not conclusive. This outcome is determined by testbed configuration as the server responds with OK to any TLS requests, In the absence of a reasonable response, the client may terminate or cease further communications with the controller. Also, decryption may not necessarily provide useable information, particularly where the plaintext includes a secondary encryption layer as with TorrentLocker. However, having discovered the key and IV, a complete session is decryptable.





§ CONCLUSIONS

Rapid decryption of live TLS malware traffic offers exciting prospects. For instance, by permitting the client to communicate with its controller in a managed environment, knowledge such as client-controller interaction details may contribute to enhanced malware defences. Furthermore, decrypting unmanaged communications between malware and controller may provide ransomware keys or stolen banking details. Future work will explore these opportunities as well as expanding the range of tested malware clients.


IEEEtran


