Analysis of SSL/TLS Handshakes in Malware Encrypted Traffic

Masaryk University Faculty of Informatics

Analysis of SSL/TLS handshakes in malware encrypted traffic

Bachelor’s Thesis

Daniela Belajová

Brno, Fall 2018 Masaryk University Faculty of Informatics

Analysis of SSL/TLS handshakes in malware encrypted traffic

Bachelor’s Thesis

Daniela Belajová

Brno, Fall 2018 This is where a copy of the official signed thesis assignment and a copy ofthe Statement of an Author is located in the printed version of the document. Declaration

Hereby I declare that this paper is my original authorial work, which I have worked out on my own. All sources, references, and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source.

Daniela Belajová

Advisor: Mgr. Stanislav Špaček

i Acknowledgements

I would like to thank my advisor Mgr. Stanislav Špaček for all his guidance, patience, valuable advice and feedback through the whole process of writing this thesis. I would also like to thank my family for their support and encouragement.

ii Abstract

One of the current trends in cybersecurity is abusing encrypted network traffic to mask a malware activity and complicate its detection. Although encryption ensures the confidentiality of transmitted data, at the same time it prevents the use of some detection methods. In this bachelor’s thesis, I focus on the SSL/TLS protocol, which is one of the most widespread encryption protocols providing secure communication in nowadays networks. The main aim of this work is to analyze the SSL/TLS traffic generated by malware in recent malware campaigns misusing encryption to hide their activity, concentrating on protocol metadata from the initial handshake of the connection and based on the results of comparison with benign encrypted traffic, find possible distinctive characteristics that would allow malware to be identified in benign encrypted traffic.

iii Keywords

SSL/TLS protocol, SSL/TLS handshake, encrypted traffic, analysis, malware, botnet, C&C server, pcap, detection

iv Contents

1 Introduction 1

2 Encrypted network traffic 2 2.1 The present situation in encrypted network traffic ...... 2 2.2 Encryption protocols ...... 3 2.3 SSL/TLS protocol ...... 4 2.3.1 Versions ...... 4 2.3.2 Protocol features ...... 5 2.3.3 Protocol architecture ...... 5 2.3.4 The process of handshake ...... 6 2.3.5 The process of abbreviated handshake ...... 9 2.3.6 X.509 certificates ...... 10 2.3.7 Extensions ...... 11

3 Overview of recent malware campaigns 12 3.1 Recent malware campaigns ...... 12 3.1.1 Trickbot ...... 13 3.1.2 Gozi ...... 14 3.1.3 ZeusPanda ...... 15 3.1.4 IcedID ...... 16 3.1.5 Gootkit ...... 17 3.1.6 Dridex ...... 18

4 Malware handshakes analysis 20 4.1 Dataset ...... 20 4.2 Wireshark ...... 21 4.3 Results of the analysis ...... 21 4.3.1 Trickbot ...... 23 4.3.2 Gozi ...... 24 4.3.3 ZeusPanda ...... 25 4.3.4 IcedID ...... 26 4.3.5 Gootkit ...... 27 4.3.6 Dridex ...... 28 4.4 Summary and comparison ...... 29

5 Malware and benign traffic comparison 30

v 5.1 Benign malware dataset ...... 30 5.2 Discussion about comparison results ...... 31 5.2.1 Extensions ...... 31 5.2.2 Cipher suites ...... 32 5.2.3 Certificates ...... 33 5.2.4 Versions ...... 34 5.3 Summary ...... 35

6 Conclusion 36 6.1 Future work ...... 37

Bibliography 38

A The summary of malware campaigns 43

B Results of SSL/TLS handshakes analysis 44

C Pcap files with analyzed samples 46

vi List of Tables

4.1 An overview of Trickbot malware samples 23 4.2 Trickbot C&C servers certificates 24 4.3 An overview of Gozi malware sample 24 4.4 Gozi C&C servers certificates 25 4.5 An overview of ZeusPanda malware samples 25 4.6 ZeusPanda C&C servers certificates 26 4.7 An overview of IcedID malware samples 26 4.8 IcedID C&C servers certificates 27 4.9 An overview of Gootkit malware samples 27 4.10 Gootkit C&C servers certificates 28 4.11 An overview of Dridex malware samples 28 4.12 Dridex C&C servers certificates 29 5.1 The occurrence of extensions in ClientHello/ServerHello messages in the benign traffic sample 31 A.1 The summary of recent malware campaigns 43 B.1 Mapping extensions to the hex code used in Table B.2 44 B.2 Malware SSL/TLS handshakes analysis results 45

vii List of Figures

2.1 TLS protocol structure - based on Source: [9] 5 2.2 The TLS full handshake - based on Source: [8] 7 2.3 The TLS abbreviated handshake - based on Source: [8] 9 4.1 Lists of malware-supported cipher suites 22

viii 1 Introduction

Over the last few years, as the need to protect users’ privacy in the online world has grown, the encryption of data transmitted across networks has become nearly a standard situation. However, the adaptation of this technology has been followed by efforts to exploit its wide usage as a security threat and malware (malicious software) distribution tool. Considering the encrypted traffic poses a challenge for detecting anomalies and applying the conventional traffic monitoring methods, it is essential to develop new effective privacy-conscious ones. In this thesis, I focus on Secure Sockets Layer/Transport Layer Se- curity (SSL/TLS) encryption protocol which secures data transmission for most of the known application protocols in today’s networks. The aim of this work is to investigate the possibility of differen- tiating encrypted traffic generated by malware in recent malware campaigns from benign encrypted traffic based on SSL/TLS handshake parameters which are exchanged in unencrypted form while establishing a connection between the communicating parties. The thesis is divided into six chapters. Chapter 1 and Chapter 2 introduce the current issue of encrypted network traffic. Chapter 2 also constitutes the behavior process of SSL/TLS protocol and thus creates the theoretical basis for the analysis. Chapter 3 overviews the selected recent campaigns of malware families which benefit from encrypted traffic to hide their activities. The practical part of this work begins with Chapter 4, which out- lines the analysis results of collected pcap files with encrypted traffic generated by malware families described in Chapter 3. Chapter 5 dis- cusses the comparison of obtained data from malware analysis and the acquired benign traffic sample. Samples of regular and malware traffic are the output of the thesis together with the results oftheir analysis. Chapter 6 provides the summary of achieved outcomes and suggests a possible direction for further research.

1 2 Encrypted network traffic

This chapter in Section 2.1 and Section 2.2 provides an explanation of the current trend in encrypted network traffic and a basic survey ofthe encryption protocols occurring in today’s networks. The essential part of the chapter consists of a description of SSL/TLS encryption protocol in Section 2.3, where I focus on SSL/TLS subprotocols responsible for the initial handshake and parameters exchanged and established during this process.

2.1 The present situation in encrypted network traffic

Nowadays, encryption is one of the most effective and most commonly used techniques to secure stored or transmitted sensitive information. Encryption provides data confidentiality by converting any type of data to an encoded form which is readable only to an entity with an appropriate secret, a decryption key. Currently, we can label any information as sensitive whose collection and analysis can lead to tracking, profiling or other crimes against the network services user. It includes passwords, banking credentials, and email or another type of electronic communication theft. That is why in today’s Internet world, the number of websites using encryption protocols, especially the SSL/TLS protocol, to ensure the protection of their activities, is significantly rising. On the other hand, the properties of encrypted traffic have become very popular in the last years among cybercriminals who have started misusing them to hide malware activity and to prevent malware detection based on pattern matching. Companies that have been in the network security market for many years, like SonicWall, have seen a growing number of attacks hidden by the SSL/TLS protocol [1]. Zscaler announces that it has blocked an average of 800,000 SSL transactions a day in the half-year period at the turn of 2017 and 2018 that hide some form of attack [2]. So the main question is: How to differentiate between legitimate and malicious encrypted traffic? One of the possible ways can be decryption of the communication’s packets followed by packet’s content analysis and their re-encryption. However, this method is too expensive and ineffective. Therefore,

2 2. Encrypted network traffic

scientists are developing methods that do not require this approach and preserve user privacy. The majority of encryption protocols comprise of two main phases. Encrypted data transmission is preceded by an unencrypted handshake, the initial setting of parameters for further communication and possible authentication of the communicating parties [3]. Because packets are sent as a plaintext during the handshake, they are simply accessible and therefore they can be analyzed.

2.2 Encryption protocols

The main function of encryption protocols is the use of cryptographic principles and methods to ensure secure data transfer between communicating parties. In today’s networks, this feature is implemented on multiple layers. On the network layer of the ISO/OSI model operates IPSec protocol suites. IPSec was designed as an improvement of security over the internet because the IPv4 protocol does not offer sufficient security features. It is currently an optional component of IPv4 protocol and the part of IPv6 protocol. The significant feature of IPSec is that it provides security of all traffic at IP level and does not require modifi- cation of each application. IPSec can work in tunnel or transport mode and encompasses two protocols: Authentication Header (AH) for authentication and Encapsulating Security Payload (ESP) for encryption, authentication and anti-replay services [4]. The SSL/TLS encryption protocol provides secure data transfer in cooperation with Transmission Control Protocol (TCP) of the ISO/OSI transport layer. Within the application layer of the ISO/OSI model, encryption services may be implemented directly in applications. Among programs that use encryption to secure their communication belong Se- cure Shell (SSH), Skype or BitTorrent. SSH is a protocol for secure remote login and other network services over an unsecured network. SSH uses server-client model and provides data confidentiality, integrity, user and server authentication and optional compression. It was created as a replacement for the unsecure remote login protocols like Telnet. BitTorrent and Skype are both based on peer-to-peer principles.

3 2. Encrypted network traffic

BitTorrent allows sharing large amounts of data over the internet and Skype provides services for chat, video or voice calls and files sharing. Both protocols use obfuscation algorithms that make it difficult to detect their operations [3].

2.3 SSL/TLS protocol

Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are encryption protocols that provide data security for a client and a server communicating over unsecure network. Thanks to the collaboration with TCP, the SSL/TLS protocol is application protocol independent, which means that almost any application that can be run over TCP can be run over SSL/TLS without the necessity to significantly modify the application. Using existing known protocols like HTTP in combination with SSL/TLS protocol is referred to as HTTPS.

2.3.1 Versions SSL has gone through several revisions and is still developing and repairing its vulnerabilities. SSL 3.0 and its lower versions are officially declared deprecated [5] and they should not be used anymore. TLS is very similar to SSL 3.0 but because of some minor changes made to enhance security, they are backward incompatible. Nevertheless, creating the secure communication channel between two communicating parties to transfer data is the approach shared by all versions of SSL and TLS. There are currently four versions of TLS 1.0, 1.1, 1.2 and TLS 1.3. However, Internet Engineering Task Force (IETF), a standard organi- zation, is preparing deprecation of versions 1.0, 1.1 and recommends disabling them [6]. Many websites have already discontinued supporting these versions in 2018. In August 2018, IETF published RFC 8446 for TLS 1.3 [7], which brought improvement to the currently most widely used TLS 1.2. By the time the new standard will be fully adopted, TLS 1.2 is still considered safe enough. In this thesis, the description of the SSL/TLS protocol is, in the main, based on RFC 5246 for TLS 1.2 [8] and in the rest of the work, an abbreviation TLS indicates the version 1.2 unless otherwise specified.

4 2. Encrypted network traffic

2.3.2 Protocol features The SSL/TLS protocol ensures:

∙ Data confidentiality (privacy) - ensured by encryption of transmitted data using symmetric cryptography. The encryption key is generated uniquely for each connection during initial handshake.

∙ Authentication of communicating entities - realized by asymmetric cryptography and a public key certificate. Authentication may be required from both sides, but typically server authentication only occurs. Since authentication is optional, both parties may remain anonymous and may not authenticate each other. However, this option is not recommended.

∙ Data integrity - provided by a message integrity checks included in messages using a Message Authentication Code (MAC), a function of the secret key and the message. It means that without notice, no attacker can replay messages or change their order. The TLS versions use the HMAC algorithm which is based on a hash function.

Figure 2.1: TLS protocol structure - based on Source: [9]

2.3.3 Protocol architecture The TLS protocol consists of two layers: the TLS Record Protocol and the TLS Handshake Protocol, as is illustrated in Figure 2.1. The main purpose of the Record Protocol is to transmit messages of various higher-layer protocols (the Handshake Protocol, the Alert Protocol, the Change Cipher Spec Protocol, and the Application Data Protocol). Note that the TLS does not specify what application protocol it is due to its already mentioned application protocol independence. It fragments, compresses (optional), applies a MAC, encrypts and

5 2. Encrypted network traffic

transmits messages in this order. The protocol uses parameters and algorithms negotiated with the Handshake Protocol. Three TLS subprotocols are responsible for the handshake phase: The Handshake Protocol, The Change Cipher Spec Protocol and the Alert Protocol. The Change Cipher Spec Protocol consists of a single message sent by both client and server during a handshake after parameters agreement has been done. It notifies the recipient that subsequent records will be protected under the newly negotiated parameters. The Alert Protocol reports errors that occurred during a handshake. Alert messages are of two types: warning, which can be ignored, and fatal, which immediately terminates the connection. The Handshake Protocol is responsible for authentication and negotiation of session’s parameters, which are: ∙ Session identifier - an arbitrary byte sequence chosen by the server to identify a session state. ∙ Peer certificate - X509v3 certificate. ∙ Compression method - the algorithm used to compress data. ∙ Cipher suite - represents a bundle of cryptographic algorithms like the key exchange algorithm, the encryption algorithm, MAC algorithm and pseudorandom function (PRF) used for key generation. ∙ Master secret - 48-byte secret shared between client and server. Master secret is obtained during handshake and used to generate all cryptographic keys (encryption and MAC keys). ∙ Is resumable - a flag indicating whether the session can be used to initiate new connections.

2.3.4 The process of handshake The TLS handshake can be divided into four phases as shown in Figure 2.2. Handshake messages order presented in Figure 2.2 must be preserved otherwise a fatal error occurs. During the first phase, hello messages are exchanged by which client and server make an agreement on the parameters of the session. When the client first tries to connect to a server, a ClientHello message is sent. This message consists of the client’s preferred version of the TLS protocol by which he wants to communicate; a random number used

6 2. Encrypted network traffic

Figure 2.2: The TLS full handshake - based on Source: [8]

during the keys generation; a sessionID which has zero value, if the client wants to create a new session and the server will generate a new sessionID; the lists of compression methods and the cipher suites supported by the client in order of client’s preferences and in the end, extensions that allow the client to require extended functionality. Server’s response is a ServerHello message. In this message, the server specifies the parameters which it chose (version, extensions, cipher suite and compression algorithm) from what was offered to it within the ClientHello. The TLS protocol version on which the client and the server agree should be the highest possible that they both support. The ServerHello also contains a random number that is used to generate keys. During the second and third phases, the client and server are authenticated, and the cryptographic keys are being generated. Right after the ServerHello, the server sends Certificate, ServerKeyExchange,

7 2. Encrypted network traffic

CertificateRequest and ServerHelloDone messages when besides the last one, all the messages are optional and whether or not they are sent depends on the selected cipher suite. The Certificate message contains the entity’s certificate or a certificates chain. A ServerKeyExchange message is sent only for some types of key exchange algorithms like Anonymous (DH_anon) or Ephemeral (DHE) Diffie-Hellman, when additional information for keys generation is needed. If the selected cipher suite requires client’s authentication, the server sends a CertificateRequest message to which the client must respond by sending the Certificate message with its certificate. The CertificateRequest contains the list of certificate types that the server can recognize and the list of certificate authorities that the server accepts. By a ServerHelloDone message the server terminates its hello part of the communication and waits for the response from the client. Now, the client verifies the validity of the server’s certificate. If the server has requested client’s authentication, the client sends a Cer- tificate message. Based on the type of the client’s certificate, a Certifi- cateVerify message may also be required for certificates with signing ability to prove the client’s ownership of a private client key corre- sponding to the public key specified in its certificate. Otherwise, the only mandatory message that the client is expected to send is the ClientKeyExchange. This message contains the information needed to generate the master secret. The exact content of ServerKeyExchange and ClientKeyExchange messages is based on the choice of the cipher suite, because the process may vary slightly de- pending on key exchange algorithm but at the end of the third handshake phase, both sides have all the necessary information for the calculation of all cryptographic keys. The role of the fourth and the last phase is to verify that both the client and the server have the same security parameters and the session was not compromised by the attacker. Firstly, ChangeCipherSpec messages are exchanged, which do not exactly belong to the Handshake protocol as is mentioned in Section 2.3.3. Their only function is to confirm that all the following transmitted data will be protected by newly established parameters.

8 2. Encrypted network traffic

A Finished message is always sent immediately after the Change- CipherSpec. It is the first message protected by negotiated parameters and contains a hash of all handshake messages except the Finished. When both the client and the server verify that the handshake has been executed correctly, the encrypted transmission of the application data begins.

2.3.5 The process of abbreviated handshake

Figure 2.3: The TLS abbreviated handshake - based on Source: [8]

Due to the fact that the entire handshake process is relatively complex and time-consuming, TLS allows two session resumption options: via a sessionID or a SessionTicket. In the first case, both sides store the state of the session andthe whole process is shortened, as shown in Figure 2.3. The ClientHello message contains the non-zero value of the sessionID which identifies the session to be resumed. Cipher suite and the compression algorithm are set to values of the session to be resumed. If the server cannot identify the session based on the sessionID, the full handshake will be performed instead. If the server can identify the session in the ClientHello, it restores the connection and sends the ServerHello message with the same SessionID. Subsequently, both parties directly send the ChangeCipherSpec and the Finished messages. In the second case, the status of the entire session is cached by the client. The TLS server encapsulates the session state into a Ses- sionTicket and forwards it to the client in a NewSessionTicket message

9 2. Encrypted network traffic

during handshake before its ChangeCipherSpec message and after it verified the client’s Finished message. If the client supports this mechanism, include the SessionTicket TLS extension in the ClientHello message. There are several variants of how the handshake of the session resumption can be accomplished. More detailed description in RFC 5077 [10].

2.3.6 X.509 certificates The X.509 certificate uses asymmetric cryptography and a digital signature mechanism to confirm the ownership of the public key. The certificate is an electronic document that contains the user’s public key and this document is signed by the private key of a trusted certification authority (CA), which had verified user’s identity and by its signature confirm an association between the user and his public key. The format of X.509 certificate contains fields [11]: ∙ Version - defines version of the certificate format. ∙ Serial Number - a positive integer assigned by the CA to each certificate. ∙ Signature Algorithm ID - contains identifier of the signature algorithm used by CA for signing. ∙ Issuer Name - must be distinguished name of the certificate issuer. ∙ Period of Validity - the period during which CA maintains information about the certificate that is defined by two dates: the beginning of certificate validity (notBefore) and the end of certificate validity (notAfter). ∙ Subject name - a name of the entity associated with the public key. ∙ Subject’s Public Key Information - contains the public key and the used public key algorithm. ∙ Issuer Unique Identifier - mandatory for versions 2 or 3. Defines issuer unique identifier. ∙ Subject Unique Identifier - mandatory for versions 2 or 3. De- fines a subject unique identifier. ∙ Extensions - defined only for the version 3. They enable to specify more information about the certificate subject (Subject Key

10 2. Encrypted network traffic

Identifier, Subject Alternative Name) or issuer (Authority Key Identifier, Issuer Alternative Name). ∙ Certificate Signature - contains hash code of certificates’ fields encrypted by CA’s private key.

TLS’s Certificate message contains X.509 certificate or a certificates chain. In the chain the first mentioned certificate always belongs to the entity which sent the message and each subsequent certificate verifies the authenticity of the predefined certificate. The last onein the chain is the self-signed root certificate that identifies the trusted root CA. Sometimes it may be omitted from the chain [9]. More detailed information on the X.509 Public Key Infrastructure Certificate can be found in the RFC 5280 [12].

2.3.7 Extensions TLS extensions allow extending protocol capabilities without the necessity to significantly modify the protocol. The basic set of extensions is defined in RFC 6066 [13]. The signature_algorithms extension indicates to the server which signature/hash algorithm pairs may be used in digital signatures. By the status_request extension, the client may ask the server for the server’s certificate status information. The supported_groups extension indicates the list of supported elliptic curves associated with Diffie–Hellman algorithm. Another extension is SessionTicket TLS, which is used in session resumption with the SessionTicket as I already mentioned in Section 2.3.5. The client can tell a server the name of the server it is contacting by server_name extension. This information may be required to main- tain a secure connection when multiple servers are managed on one IP address. TLS provides many other extensions that are managed by Internet Assigned Numbers Authority (IANA).

11 3 Overview of recent malware campaigns

Using SSL/TLS protocol by malware’s authors to hide malicious activity has had a growing tendency in recent years with rapid escalation and significant expansiveness. This chapter provides an overview of only a very small percentage of selected malware families and their the most current campaigns falling under this trend.

3.1 Recent malware campaigns

The key part of this thesis covers the analysis of the SSL/TLS encrypted communication between malware (eventually a bot) and its command and control (C&C) server, which occurs after the delivery and installation of malware on the victim’s system. A bot is a malware-infected computer that receives and executes commands from one or multiple C&C servers. Grouping bots create a botnet, a network of infected systems under the management of C&C servers. Nowadays these serve as a powerful tool for cybercriminals, al- lowing them to engage in large-scale attacks, mostly denial-of-service (DDoS) attacks, on global companies. For the analysis I opted for six different malware families and this chapter provides a fundamental overview of their characteristics, behavior, and the most essential and recent campaigns. All of them have influenced events in the world of computer security in thelast two years. For all selected malware families, malware type is Trojan horse denoted as financial or banking. It means that their main goal isto get as much of victim’s financial information as possible including account numbers and passwords, credit card numbers and online banking data. Further, all are targeting machines with operating system Windows. This concentration on Windows-based systems was not predetermined but it developed during the research. This is probably due to the fact that much of malware exploits the vulnerabilities of Windows OS. In all cases, the infection vector, the way of malware distribution, includes phishing or malspam (malicious spam) even though malware collaboration has recently grown, and some have begun to provide

12 3. Overview of recent malware campaigns

distribution services for others. In some cases, exploit kit, which is a toolkit used to automatically and silently exploit vulnerabilities on victims’ machines, was used for distribution. Table A.1 in Appendix A summarizes campaigns of selected malware families from this chapter. It’s a question of how many equally operating malware kinds we do not know yet and how many will be disclosed over the next few years. Due to the benefits of encrypted traffic it is assumed thatthe number of malware attacks using the SSL/TLS protocol will increase each year.

3.1.1 Trickbot The banking trojan Trickbot appeared for the first time in the fall of 2016 and since then it has been constantly evolving and expanding into Canada, the UK, Australia, Germany, Asia, Nordic countries and the US. Trickbot, unlike other trojans that attack the banks of the big countries of Europe, also focuses on the smaller, economically weaker ones, like Bulgaria, Lithuania, Latvia, Slovenia and Slovakia, which can be regarded as a less likely target for the attack [14]. Trickbot is considered to be the successor of Dyreza/Dyre malware and its main goal is to steal information about the user - data from browsers, systems and network data, email communications, and especially passwords, bank or other financial details. It is a modular malware which means that it is composed of several modules, each with a distinct function. Attackers can change the modules in the desired way, and they can adapt the attack according to the current needs. Individual modules may even be downloaded and replaced after infecting the computer. The documented modules of Trickbot currently include the following data stealers: InjectDll as a core stealing module, OutlookDll for Microsoft Outlook credentials stealing or ModuleDll/ImportDll for browser data such as cookies, browsing history, plugins stealing. Reconnaissance modules are Systeminfo, Mailsearcher, NetworkDll which gather information about the system. WormDll and ShareDll add to a malware the ability of self-distribution [15]. From the very beginning, the most common infection vector of Trickbot was the malspam campaign with attached Word, Excel or PDF

13 3. Overview of recent malware campaigns

documents with embedded malicious macros which utilize Windows PowerShell to download a malware from a remote C&C server and run it on the computer. In this case, the macro is understood as a sequence of commands that can be later recalled by a mouse action or a single command. Starting in 2018, Trickbot has been working with Emotet malware, which acts as its distribution tool. The user will download a version of Emotet, another financial trojan that, when launched, downloads and runs Trickbot. This collaboration created a dual-threat for the Internet world [14]. However, Trickbot still continues to spread through its campaigns. The latest version of Trickbot came up in August 2018 with new tricks like process hollowing (a code injection technique), disabling security tools of an infected machine (like Windows Defender) and anti-analysis techniques, for example, forcing malware to sleep for a various amount of time or useless system functions calls. However, in this case, macros downloading Trickbot execute only if the user zooms in/out the document [16].

3.1.2 Gozi

Gozi was first discovered in December 2007 as running in wild forat least one month. The significant part of the code was similar tothe Ursnif and Snifula, outstanding trojans of that time. Today Gozi is also known under these names. After initial malware research, it was found that its motherboard server was located in Russia, physically probably in the Petersburg area. Gozi’s main activity includes stealing account numbers and passwords from clients of global banks or financial service companies, the top US retailers and the leading online retailers. The stolen data contained medical information as well. Since the beginning of its existence, Gozi has been distributed through phishing campaigns with embedded links to malicious websites that require confidential information from the user. Credentials have been stolen using methods such as keylogging or hijacking [17]. Gozi has been on the market for more than a decade and is one of the longest running banking trojans of today. Its code was leaked

14 3. Overview of recent malware campaigns

in 2010 which resulted in the creation of its variants: Vawtrak/Nev- erquest and Gozi ISFB (labeled also as Gozi version 2). Gozi IFSB is still active separately in North America and Europe, but since the third quarter of 2017 mostly in Japan. At present, there are other active variants that have evolved from Gozi ISFB such as Dreambot or GozNym. The latest variant is Gozi version 3, active since mid-2017 [18] and based on the leaked Gozi ISFB source code but with modifications in the field of attack tactics. The malware’s operators added redirection attacks, the tactic also used by malware such as Dridex, Gootkit and Trickbot. Gozi version 3 is the first variant of Gozi which uses redirection attacks. In this case, the victim is redirected to a fake web site on the attacker-controlled server and thanks to web injection techniques the user’s credentials can be stolen. Malware maintains connection with the legitimate website of the bank to ensure the authenticity of the information displayed to the user. This campaign targets business and banking customers in Australia [19].

3.1.3 ZeusPanda

ZeusPanda is a spin-off of Zeus malware [20]. It was firstly discovered in 2016 by Fox IT and presently it belongs to the most active descendants of Zeus, spreading through phishing emails and targets Windows operating systems. Around March 2016, ZeusPanda’s infection vectors included emails with a malicious Microsoft Word attachment and 3 different versions of exploit kits (Angler Exploit Kit, Nuclear Exploit Kit, and Neutrino Exploit Kit). The main goal of the campaign were the clients of Aus- tralian and UK banks. These emails were also sent to individuals working at mass media or manufacturing corporations [21]. ZeusPanda is primarily focused on financial organizations, but with every new campaign it expands its target areas. F5 Labs analyzed the latest ZeusPanda activity between February and May 2018 [22] and found that in addition to financial services, attacks were directed mainly at cryptocurrency and last but not least at social media (Face- book, Instagram, Twitter), adult sites and various popular applications (Skype or Youtube).

15 3. Overview of recent malware campaigns

Campaigns were targeting financial services in Canada, the US, Italy, Latin America (Argentina, Columbia, and Ecuador) and in Japan it was mostly credit card providers. There were different C&C servers for each campaign connected to a known threat actor network hosted in Russia and once in China. In all cases, HTTPS were used to hide malware communication from tra- ditional intrusion inspection controls and the same attack techniques to collect payment information or other forms of personal information: web injection, logging of keyboard input and screen shots of user activity. Since the summer of 2017, it has been possible to see this growing trend in the case of ZeusPanda banker in the expansion of the attacked areas. However, this is the first occurrence focusing on cryptocurrency. The last activity of ZeusPanda was in October 2018, when several attacks on organizations in the US, Canada, and Japan happened. In this case, ZeusPanda was distributed by another banking trojan Emotet, which has become a distribution tool for different trojans in recent months [23].

3.1.4 IcedID IcedID is a banking trojan discovered in September 2017 by researchers at IBM’s X-Force Research team. Around November 2017, its campaign was targeting financial institutes, e-commerce sites, webmails and mobile service providers in the US. IcedID has the capability to spread over a network to other end- points, monitor a browser’s activity by setting up a local proxy, web injection techniques and redirection attack techniques (redirect traffic to keep live connection with a bank providing bank’s correct SSL/TLS certificate). Like anti-sandboxes measure, malware required a system reboot. IcedID was using Emotet as a distribution tool in the campaign in November 2017 but also in the course of 2018. Typically, Emotet spreads through spam emails that are designed to look like messages from banks that contain malicious .zip files [24]. Around June 2018, cooperation between IcedID and Trickbot was observed, where they acted as a downloader for each other. In this campaign IcedID version was upgraded, which has now very similar

16 3. Overview of recent malware campaigns

methods to Trickbot. One major update to older versions is related to malware modules downloading on the victim’s system. Only the core module controlling malware’s execution is initially presented in the victim system. The other modules, which were previously present with core modules in the initial phase, are now downloaded additionally from the C&C servers likewise Trickbot. This update has reduced the original size of the malware file and allowed greater flexibility in assembling the attack according to the current needs [25].

3.1.5 Gootkit

Gootkit is an advanced modular multi-functional Windows banking trojan, so its main purpose is to steal victim’s banking data usually via web injection techniques into HTTPS traffic. Compared to other malicious programs, Gootkit did not have a lot of recognition features and had limited propagation. It could have caused scientists not to become aware of it until mid-2014, even when it could have been active in co-operation with other types of malware before. In 2016, Gootkit appeared as a standalone program in multiple campaigns. The Securelist in September 2016 [26] captured its upgraded version. As well as its earlier occurrences, it was written in NodeJS (JavaScript runtime environment). In this case, the system was infected via a chain of downloaders. This campaign was targeted at users of Europe in Germany, France, Italy, the Netherlands and Poland. The key property presented in the new version of Gootkit samples that distinguished it from foregoing always checked global environment variable crackme. When the value of the variable was not equal to a concrete fixed value, the bot started to inspect a system for a virtual environment characteristic. Goootkit’s infection vector at that time included mostly spam messages with malicious attachments and websites containing exploit kits. In 2016, Gootkit also spread through the EITest campaign, which got its name from Malwarebytes Labs [27]. Since October 2016, the campaign has also distributed many of the worst information stealers in addition to Gootkit. EITest for malware distribution utilized Rig

17 3. Overview of recent malware campaigns

EK, one of the most important exploit kits that had several versions: Rig standard, Rig-E (Empire Pack) and Rig-V ("VIP" versions). In the course of 2017, Gootkit samples changed their basic structure. Meanwhile, Gootkit consisted of Loader and Main modules. The new version has added Browser injection module responsible for network interception and access to the browser [28]. Last big campaign spread Gootkit via spam emails from compromised MailChimp around March 2018. The campaign probably began in November 2017 in Australia, continued in Italy, the UK and the US. Without the necessity to gain access to the botnet by taking advantage of weak passwords or tricking users, the attackers used effective way to distribute emails via MailChimp like trusted email provider. The majority of the emails contained embedded links to malicious Word document or .zip files with .js (JavaScript) files downloading the malware. Emails looked like invoices sent on behalf of an individuals or organizations [29].

3.1.6 Dridex Dridex is a banking trojan that was first observed in July 2014. It is sup- posed to be a successor of GameOver Zeus, peer-to-peer (P2P) variant of Zeus malware [20]. Dridex also profits from a P2P architecture to protect its C&C servers. It is modular malware and consists of two modules: an initial dropper module that downloads the main module. Dridex was most active in the first year after being discovered. At the beginning of 2017 after a half-year break, Dridex returned with a small phishing campaign targeting UK financial institutes with a new User Account Control (UAC) bypass method. The most conventional appearance of the phishing campaigns distributing Dridex are emails with a Word document attachment with macros downloading and executing malware [30]. In September 2017, another variant of Dridex emerged and it mis- used fake accounting invoices to steal user’s personal information. The latest phishing campaign in January 2018 used emails with links to FTP compromised sites for downloading malicious Word or Excel documents instead of HTTP. The main victims were users in France, the UK and Australia. It is assumed that this campaign has its origins in the Necurs botnet, one of the largest botnet of the world,

18 3. Overview of recent malware campaigns which delivers some of the worst banking trojans and ransomware threats [31]. Taking advantage of FTP websites, Necurs botnet connection and concurrently the usage of hundred times smaller amount of emails that is typical for campaigns spreading by Necurs botnet - these are the main features of this Dridex campaign that differentiate it from the previous ones [32].

19 4 Malware handshakes analysis

Chapter 4 explains the analysis process of SSL/TLS handshakes generated by different chosen malware, which are presented in Chapter 3. Section 4.1 describes the properties of the dataset and conditions imposed on malware samples. Section 4.2 is devoted to Wireshark, the tool used to filter and inspect malware samples during the analysis. The results of the analysis are presented in Section 4.3; Section 4.4 summarizes and compares the data obtained for all samples.

4.1 Dataset

I obtained all used samples with malware traffic from publicly available databases in the form of pcap files [33, 34]. In the course of their collecting, I encountered two circumstances that influenced the choice and number of samples:

1. malware versions,

2. proof of the connection between traffic and malware.

Malware versioning is a rather difficult task. There is no unified and global versioning or naming system for malware. In some cases, malware versions are maintained internally by individual security companies. In other cases, there can be information about a version directly in code. However, this only applies to a small percentage of the total number of malware types. In practice, anyone can change the public code and drop it, essentially releasing the next version in the world. This is why I decided to classify each malware sample by the date of its capture and the infection vector of the malware campaign, not based on the version number. I filtered individual samples to meet one condition and thatthe communication in them had to be interconnected with malware on the basis of some evidence. For this purpose, I chose a certificate that the server submits for its authentication. Through the sslbl.abuse.ch page [35], which provides a list of SSL/TLS certificates associated with malware or botnet activities identified through SHA1 fingerprints, I

20 4. Malware handshakes analysis

have verified the connection between the contacted server and malware activity. This reduced and affected the number of samples for each malware. The collected pcap files with malware samples are the part of Appendix C.

4.2 Wireshark

For the analysis of pcap files I used the Wireshark, a packet analyzer, which allows simple browsing of SSL/TLS handshake parameters. It also provides a number of filters to simplify data processing, such as ssl to filter the SSL/TLS encrypted communication. Implicitly Wireshark with ssl command filters communication through port 443 (HTTPS). In some malware samples used during the analysis, the client commu- nicated with the server via non-standard ports (447 or 4143). In order to see the contents of the SSL/TLS packets in this case, it is necessary to add these ports to the box SSL/TLS Ports in Edit -> Preferences -> Protocols -> HTTP. To filter pcap from background traffic Iused tcp.analysis.flags and ssl.ignored_unknown_record filters; ssl.handshake.type filter allows to se- lect individual handshake messages according to their numeric des- ignation (ClientHello (1), ServerHello (2), Certificate (11), ServerKey- Exchange(12), ClientKeyExchange (16)). Wireshark also has an Export Packet Bytes function that allows saving the certificate as a stand-alone .der file to be able to generate from it its SHA1 fingerprint.

4.3 Results of the analysis

As the basis for the analysis, I took a work by Anderson and McGrew [36], in which they presented differences between malware and benign traffic based on the unencrypted SSL/TLS handshakes metadata. According to their example, I focused specifically on the values of the parameters in ClientHello, ServerHello and Certificate messages of handshakes generated by chosen malware. In the end, I did not include ClientKeyExchange and ServerKeyEx- change in the result. If they are present during the handshake, their content differs according to the selected cipher suite and for the samples processed in this work, these messages did not contain particular

21 4. Malware handshakes analysis information to allow the following identification of malware in the general traffic.

Figure 4.1: Lists of malware-supported cipher suites

In the following part of the chapter, there are included two tables for each malware. The first table provides an overview of samples for each chosen malware with their infection vectors and the IP addresses of the servers with the port through which the client contacted the server during the handshakes.

22 4. Malware handshakes analysis

The second one contains parameters of certificates used by individual servers for their authentication in handshakes. All certificates used by the servers were self-signed, which means that the Issuer Common Name and Subject Common Name were equal. Therefore, this column is unified in the tables. In all examined samples, malware always supported one or more lists of cipher suites shown in Figure 4.1.

4.3.1 Trickbot

Table 4.1: An overview of Trickbot malware samples

Date of capture Infection vector Server(s)

2018-09-19 malspam; attachment: Excel document 94.232.20.113 (port 443)

Trickbot distributed by Emotet; Emotet distributed over malspam; 85.9.212.117 (port 443) 2018-07-31 email text: a link to download Word document with malicious 158.58.131.54 (port 443) macros

Trickbot distributed by Emotet; Emotet distributed over malspam; 104.193.252.163 (port 443) 2018-06-14 attachment: Word document/email text: a link to Word document 109.86.227.152 (port 443) with malicious macros

malspam; attachment: PDF document with embedded Excel doc- 195.69.196.77 (port 447) 2017-06-14 ument containing malicious macro 186.103.161.204 (port 443)

malspam; email subject: Invoice; attachment: double-zipped .wsf 89.231.13.27 (port 443) 2017-06-12 (windows script) file 85.228.193.94(port 447)

In all samples, there were several handshakes occuring between the client and the server. In sample 2017-06-12, the communication was done over two ports, 443 and 447. In both cases, the client offered TLS 1.2 version, List 1 of cipher suites and extensions: extended_master_secret, SessionTicket TLS, ec_point_formats, renegotiation_info, supported_groups (x25519 (0x001d), secp256r1 (0x0017), secp384r1 (0x0018)), status_request and signature_algorithms:

SHA1 DSA (0x0202) ecdsa_sha1 (0x0203) rsa_pkcs1_sha256 (0x0401) rsa_pkcs1_sha384 (0x0501) rsa_pkcs1_sha1 (0x0201) rsa_pkcs1_sha512 (0x0601) ecdsa_secp256r1_sha256 (0x0403) ecdsa_secp384r1_sha384 (0x0503) ecdsa_secp521r1_sha512 (0x0603)

In the first ten from 28 offered cipher suites, there were noneof those from other samples.

23 4. Malware handshakes analysis

The server 89.231.13.27 communicating over port 443 chose 0xc014 cipher suite and TLS version 1.0. The server 85.228.193.94 communicating over port 447 chose 0xc030 and TLS version 1.2. Extensions were the same in both cases: renegotiation_info, ec_point_formats and SessionTicket TLS, which was used to resume the session with Ses- sionTicket. The ClientHello and the ServerHello messages had the same content in samples 2017-06-14, 2018-09-19, 2018-07-31, 2018-06-14 in all handshakes. The client always offered TLS version 1.0; extensions: sup- ported_groups (secp256r1 (0x0017), secp384r1 (0x0018)), renegotiation_info, ec_point_formats; and List 2 of cipher suites. The server selected TLS version 1.0, cipher suite 0xc014, and extensions: renegotiation_info, ec_point_formats.

Table 4.2: Trickbot C&C servers certificates

Server Validity Issuer/Subject SHA-1 IP address (from/to) Common Name

89.231.13.27 17-06-07 rvgvtfdf 3AE6F60DA16B99C5807FE93E4729AD7C2F4FFAB3 186.103.161.204 18-06-07

85.228.193.94 17-05-02 sd-97597.dedibox.fr CF31D2F8E419D76517B0BC6C3EAD1F246B950A42 195.69.196.77 27-04-30 85.9.212.117 C=AU, ST=Some-State, 158.58.131.54 18-01-11 O=Internet Widgits E9FBF9CE3A3EEA7BA2BDADBAB163CFF2148DC9E7 19-01-11 109.86.227.152 Pty Ltd 94.232.20.113

16-12-06 John/emailAddress= 34F06057EEA1BA0ECD0734FB7890E5B54B3F89DC 104.193.252.163 44-04-22 John_Alaskagmail.com

4.3.2 Gozi

Table 4.3: An overview of Gozi malware sample

Date of capture Infection vector Server(s)

malspam; email subject: Invoice; attachment: Word document 2018-01-03 203.24.188.166 (port 443) with malicious macro

In the case of Gozi, I found only one sample meeting the specified conditions containing Gozi version 3. Several full handshakes took place between the client and the server. The ClientHello included TLS

24 4. Malware handshakes analysis

1.0 version, extensions: renegotiation_info, supported_groups (secp256r1 (0x0017), secp384r1 (0x0018)), ec_point_formats; and List 2 of cipher suites. The server chose TLS version 1.0, renegotiation_info extension and cipher suite 0x002f.

Table 4.4: Gozi C&C servers certificates

Server Validity Issuer/Subject SHA-1 IP address (from/to) Common Name

C=AU, ST=Some-State, 17-09-25 O=Internet Widgits 647C00A1F727BB2F1C97553D4F4BA4B51842EC74 203.24.188.166 18-09-25 Pty Ltd

4.3.3 ZeusPanda

Table 4.5: An overview of ZeusPanda malware samples

Date of capture Infection vector Server(s)

ZeusPanda distributed by Emotet; Emotet distributed over 2018-08-13 malspam; attachment: Word document/email text: a link down- 178.132.7.104 (port 443) loading Word document

ZeuSPanda distributed by Emotet; Emotet distributed over 2018-07-09 malspam; email text: a link to Word document with malicious 110.10.176.124 (port 443) macro

In both samples the client offered communication over TLS 1.2, List 3 of cipher suite and the same extensions: ec_point_formats, renegotia- tion_info, server_name, supported_groups (secp256r1 (0x0017), secp384r1 (0x0018)), signature_algorithms:

rsa_pkcs1_sha256 (0x0401) rsa_pkcs1_sha384 (0x0501) rsa_pkcs1_sha1 (0x0201) ecdsa_secp256r1_sha256 (0x0403) ecdsa_secp384r1_sha384 (0x0503) ecdsa_sha1 (0x0203) SHA1 DSA (0x0202)

Both servers established a connection through TLS version 1.2, chose renegotiation_info extention and the cipher suites 0x003c.

25 4. Malware handshakes analysis

Table 4.6: ZeusPanda C&C servers certificates

Server Validity Issuer/Subject SHA-1 IP address (from/to) Common Name

domain.com/O=My 18-07-06 Company Name 50EF774F2D86659B55E2411F3790199CE3FA3C5E 110.10.176.124 19-07-06 LTD./C=US

domain.com/O=My 18-08-13 Company Name 561A72267ADE93D27C59BAC17E08EA411321548B 178.132.7.104 19-08-13 LTD./C=US

4.3.4 IcedID

Table 4.7: An overview of IcedID malware samples

Date of capture Infection vector Server(s)

IcedID distributed by Emotet; Emotet distributed over malspam; 2018-09-06 5.135.252.103 (port 443) attachment: PDF/Word document

IcedID distributed by Emotet, Emotet distributed by malspam; at- 2018-09-04 tachment: PDF document with a link for the Emotet Word docu- 93.189.41.44 (port 443) ment with malicious macro

IcedID distributed by Emotet; Emotet distributed over malspam; 2018-06-26 5.187.0.158 (port 443) email text: a link to Word document with malicious macro

In the case of IcedID, the communication took place in a specific order always with two different servers hosted on one IP address. After the initial short time, when several handshakes had been done with the first server, followed by an x-minute pause, every x-minute the handshake with a second server on the same IP address was initialized. In the sample 2018-06-26, there were a 10-minutes pause and intervals. The client negotiated connection with TLS 1.2, List 3 of cipher suites extensions: renegotiation_info, server_name (urnachay.com, percal- abia.com), supported_groups (secp256r1 (0x0017), secp384r1 (0x0018)), ec_point_formats, and signature_algorithms:

rsa_pkcs1_sha256 (0x0401) rsa_pkcs1_sha384 (0x0501) rsa_pkcs1_sha1 (0x0201) ecdsa_secp256r1_sha256 (0x0403) ecdsa_secp384r1_sha384 (0x0503) ecdsa_sha1 (0x0203) SHA1 DSA (0x0202)

The server established connection with TLS 1.2, 0x003c cipher suite and renegotiation_info extension.

26 4. Malware handshakes analysis

In the samples 2018-09-04 and 2018-09-06, after the 5-minute pause, two handshakes with the second server were performed and at 5-minute intervals the connection was re-initialized. The client established a connection with the parameters: TLS version 1.0, List 2 of cipher suites and extensions: renegotiation_info, supported_groups (secp256r1 (0x0017), secp384r1 (0x0018)), ec_point_formats and server_name, where in 2018-09-04, the first server was whoulatech.com and second tybal- ties.website, fillizee.com and efiging.com in 2018-09-06. In both cases, servers opted for TLS 1.0, 0x002f cipher suite and renegotiation_info extension.

Table 4.8: IcedID C&C servers certificates

Server Validity Issuer/Subject SHA-1 IP address (from/to) Common Name

93.189.41.44 18-05-23 default.com/emailAddress 816C8EEDC2632DE8A88B777E28F91A4F3F7E8936 5.187.0.158 19-05-23 [email protected]

18-02-21 foror2 77F0B3EF2A939F801DC7E761E072E71B3413B1C1 5.135.252.103 19-02-21

4.3.5 Gootkit

Table 4.9: An overview of Gootkit malware samples

Date of capture Infection vector Server(s)

2016-12-06 Rig-E Exploit Kit (EK) via EITEST campaign 5.39.48.106 (port 443)

2016-10-21 Rig Exploit Kit (EK) via the EITEST campaign 199.180.115.105 (port 443)

2016-10-03 Rig Exploit Kit (EK) via the EITEST campaign 116.127.248.229 (port 443)

In all samples, a single handshake took place between the client and the server. Moreover, the ClientHello and the ServerHello messages include the same parameters. In the ClientHello is offered TLS 1.0 version, List 4 of cipher suites and extensions: SessionTicket TLS, next_protocol_negotiation, ec_point_formats and supported_groups:

sect571r1 (0x000e) secp256r1 (0x0017) secp192r1 (0x0013) sect571k1 (0x000d) sect239k1 (0x0008) sect163k1 (0x0001) secp521r1 (0x0019) sect233k1 (0x0006) sect163r1 (0x0002) sect409k1 (0x000b) sect233r1 (0x0007) sect163r2 (0x0003) sect409r1 (0x000c) secp224k1 (0x0014) secp160k1 (0x000f) secp384r1 (0x0018) secp224r1 (0x0015) secp160r1 (0x0010) sect283k1 (0x0009) sect193r1 (0x0004) secp160r2 (0x0011) sect283r1 (0x000a) sect193r2 (0x0005) secp256k1 (0x0016) secp192k1 (0x0012)

27 4. Malware handshakes analysis

The server always established connection with TLS 1.0 version, 0xc014 cipher suite and extensions: renegotiation_info, ec_point_formats, SessionTicket TLS, next_protocol_negotiation.

Table 4.10: Gootkit C&C servers certificates

Server Validity Issuer/Subject SHA-1 IP address (from/to) Common Name

5.39.48.106 C=GB, ST=Berkshire, 11-11-07 L=Newbury, AC5C1F1AA5753DF82A1D587D3CD8415069613B61 199.180.115.105 12-11-06 116.127.248.229 O=My Company Ltd

4.3.6 Dridex

Table 4.11: An overview of Dridex malware samples

Date of capture Infection vector Server(s)

malspam; email text: a link downloading Word document with 91.92.136.107 (port 443) 2017-12-04 an embedded object to retrieve Dridex installer 107.170.65.224 (port 4143)

malspam; email subject: Confirmation letter; attachment: zipped 2017-03-30 8.8.247.36 (port 443) .exe file

In both samples, the client was trying to initilize connection with each server requiring TLS 1.2 version. Its ClientHello message contains the same parameters in all these handshakes: List 3 of cipher suites and extensions: renegotiation_info, supported_groups (secp256r1 (0x0017), secp384r1 (0x0018)), ec_point_formats, signature_algorithms:

rsa_pkcs1_sha256 (0x0401) rsa_pkcs1_sha384 (0x0501) rsa_pkcs1_sha1 (0x0201) ecdsa_secp256r1_sha256 (0x0403) ecdsa_secp384r1_sha384 (0x0503) ecdsa_sha1 (0x0203) SHA1 DSA (0x0202) In the sample 2017-12-04 the client initialized connection with the server 107.170.65.224 supporting TLS 1.0, List 2 of cipher suites and extensions: renegotiation_info, supported_groups (secp256r1 (0x0017), secp384r1 (0x0018)), ec_point_formats. The server 8.8.247.36 and 107.170.65.224 established connection with TLS 1.0, 0x002f suite and renegotiation_info extension. The server 91.92.136.107 in sample 2017-12-04 chose the same extension but TLS 1.2 version and 0x003c cipher suite. 28 4. Malware handshakes analysis

Table 4.12: Dridex C&C servers certificates

Server Validity Issuer/Subject SHA-1 IP address (from/to) Common Name

17-03-30 EFED79AF32BFCB562D939563A5DF85EDFE418B5C 8.8.247.36 17-09-28 Raanu9nedbl.talk

17-12-01 6EDD06F71BB868A3E721F6603905C145AB97790C 107.170.65.224 18-06-01 2Squraofatt.pub

17-12-01 8305CB9F39638DAD87BBC1BFB84F8DE1630E2B32 91.92.136.107 18-06-01 ngrdbrepstst.si

4.4 Summary and comparison

The prevalence of malware communication during which TLS version 1.2 was negotiated or established was approximately as common as version 1.0. No other version occurred. The most commonly supported extensions by malware were supported_groups, ec_point_formats, signature_algorithms and renegotia- tion_info. Diversity of malware-supported extensions and their parameters was not large. All malware samples in this work used only 4 different lists of cipher suites in specific order, shown in Figure 4.1, of which List 4was used only by Gootkit. Gootkit was more distinct from the remaining malware by the parameters used. For example, it supported a much larger number of options for the supported_groups extension. Concerning certificates used by C&C servers for their authentication, the results of this analysis showed that most C&C servers had certificates valid for 365 days. However, the work of Anderson and McGrew showed that this is not entirely typical for malware certificates. All used certificates were self-signed and chain certificates had a length of just 1. The SSL/TLS handshake parameters for all malware variants are summarized in Table B.2 in Appendix B.

29 5 Malware and benign traffic comparison

The main objective of this thesis is to explore the encrypted traffic of recent malware campaigns in order to find possible characteristics that would allow it to distinguish it from benign encrypted traffic. Chapter 5 yields the results of SSL/TLS handshake parameters comparison between regular traffic and malware samples analyzed in Chapter 4. The handshake parameters of individual malware families are summarized in Table B.2 in Appendix B. Finally, the chapter summarizes the possibilities of using examined handshake parameters as malware identifiers.

5.1 Benign malware dataset

A representative sample of regular encrypted traffic that I compared with collected samples of recent malware campaigns analyzed in Chap- ter 4 was obtained from Google searches and browsing currently the most popular sites using HTTPS protocol. HTTPS is still the most commonly used protocol in the web environment that secures communication with SSL/TLS protocol. Based on the Google transparency report [37] of the most visited websites supporting HTTPS as the default settings, I have selected the following sites to create a regular traffic sample: wikipedia.org facebook.com instagram.com yahoo.com twitter.com vk.com amazon.com reddit.com netflix.com ebay.com paypal.com

The size of the sample was sustained in dimensions still suitable for viewing only through Wireshark. The pcap file with a benign traffic sample is a part of Appendix C.

30 5. Malware and benign traffic comparison 5.2 Discussion about comparison results

5.2.1 Extensions

Table 5.1: The occurrence of extensions in ClientHello/ServerHello messages in the benign traffic sample

ClientHello ServerHello Extension (% of total) (% of total)

renegotiation_info (0xff01) 100 (16,29)* 100

ec_point_formats (0x000b) 100 92,26

server_name (0x0000) 100 65,15

supported_groups (0x000a) 100 0

signature_algorithms (0x000d) 100 0

SessionTicket TLS (0x0023) 99,87 73,56

status_request (0x0005) 99,74 51,27

application_layer_protocol_negotiation (0x0010) 97,35 74,23

heartbeat (0x000f) 83,59 17,89

extended_master_secret (0x0017) 16,41 2,94

signed_certificate_timestamp (0x0012) 12,50 0,67

channel_id (0x7550) 11,49 0,67

padding (0x0015) 3,16 0

token_binding (0x0018) 0,88 0

next_protocol_negotiation (0x3374) 0 0

Table 5.1 shows the occurrence of individual extensions within the analyzed benign traffic sample, expressed in a percentage and rounded. *In the case of renegotiation_info extension, with regard to the im- plementation of older versions of the SSL/TLS protocol, two mecha- nisms for signaling renegotiation support were defined: the renegotia- tion_info extension and a special Signaling Cipher Suite Value (SCSV) TLS_EMPTY_RENEGOTIATION_INFO_SCSV, which is not a true cipher suite and cannot be negotiated, but it has the same semantics as the empty renegotiation_info extension. ClientHello messages should not include both variants simultaneously [38]. Table 5.1 shows for renegotiation_info the percentage occurrence of the ClientHello messages in which client supports renegotiation

31 5. Malware and benign traffic comparison

and in parenthesis the percentage occurrence of messages with the renegotiation_info extension. Based on Table B.2 in Appendix B and Table 5.1, it is clear that in both malware and benign traffic generally clients support the same extensions: supported_groups, ec_point_formats, signature_algorithms and renegotiation_info. The status_request and server_name extensions were also very fre- quent in regular encrypted traffic, and on the other hand, malware only supported them rarely. Server_name was in all ZeusPanda and IcedID samples, but nowhere else and status_request was advertised only by Trickbot, only in one sample. Extensions that malware did not support at all but were quite common in the case of regular traffic include heartbeat, channel_id, signed_certificate_timestamp, application_layer_protocol_negotiation. On the other hand, the next_protocol_negotiation extension did not occur in the analyzed sample of benign traffic once, but was advertised by Gootkit. In the case of malicious traffic, except for Gootkit and Trickbot, each C&C server selected only the renegotiation_info extension, unlike standard traffic, where the diversity of extensions supported bythe server was larger. On the basis of the data obtained, it is obvious that diversity and number of SSL/TLS extensions supported either by the client or the server were in the analyzed regular traffic sample much larger than in malicious traffic samples and the occurrence of some extensions is characteristic in the case of benign traffic.

5.2.2 Cipher suites

The most frequently offered cipher suites in analyzed sample of benign traffic:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c) TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d) TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)

32 5. Malware and benign traffic comparison

In all malware samples appeared only 4 different lists of cipher suites offered by malware (List 1-4), which are shown in Figure 4.1. The most common cipher suites were 0x000a, 0xc013, 0xc014, 0x002f and 0x0035 that are referred to as weak but relatively common even in regular traffic. The non-secure or weak cipher suites include especially those using the encryption with Cipher Block Chaining (CBC) mode, which is vulnerable with lower than TLS 1.2 version, MD5 or SHA-1 MAC algorithm and RC4 encryption algorithm. In the samples of all malware kinds, one or both of 0x0005 and 0x0004 cipher suites, which are obsolete, were offered. Typically, cipher suites with RC4 or MD5 algorithms also appeared unlike the regular traffic sample, where cipher suites with these algorithms could notbe seen. This did not apply only to List 1 used by Trickbot, which does not act suspiciously unlike the remaining lists offered by malware and it contains the same cipher suites as were mostly offered by clients in the analyzed sample of regular traffic. Gootkit as the only one included cipher suites with the Camellia symmetric block cipher used as the encryption algorithm. The C&C servers usually chose weak 0xc014 and 0x002f cipher suites. The suites 0xc030 and 0x003c, considered to be secure enough, was established during ZeusPanda, Dridex, Trickbot and IcedID handshakes. In Table B.2, it can be seen that the server choice differed within samples of the same malware and depended primarily on communicating servers. In collected dataset, the most frequently selected cipher suites by server in benign traffic were 0xc030, 0xc02f, 0xc02b, 0xc02c and 0x009d. All of them are secure and recommended. From the compared results, malware usually focuses on weaker cipher suites, which are minimized for benign traffic and so C&C servers usually choose those cipher suites that cannot be uniquely identified as secure.

5.2.3 Certificates

The certificates used by the C&C servers during malicious activity were always self-signed and the certificates chain length was 1.

33 5. Malware and benign traffic comparison

As a result of determined conditions on the analyzed malware dataset all certificates can be denoted as blacklisted. In the case of a regular traffic sample the certificates chain length was at least 2 and the self-signed root certificate was signed by trusted certificate authorities like DigiCert, Let’s Encrypt, GlobalSign, Thawte, RapidSSL or GeoTrust. The validity of C&C servers’ certificates was 365 days in all samples of IcedID, PandaZeus, Gozi and Gootkit. However, Gootkit’s C&C servers authenticated themselves in 2016 by certificates that expired in 2012. For Dridex in all samples the certificates were valid for 182 days. In Trickbot’s samples, the validity of certificates was mostly 365 days or more than 10 years. In 2018 the Certification Authority Browser (CA/B) Forum, un- incorporated association of separate organizations with the aim of improving the use of certificates in the Internet community, decided in Ballot 193 [39] that for each SSL/TLS certificate issued from March 1, 2018, its validity must not exceed 825 days. The examined regular traffic sample, like in the malicious activity, very often featured 365-day certificates, but that was the only exact value of certificate validity that was repeated. Certificates issued after March 1, 2018 were valid in the range from 70 to 456 days and those issued before in the range from 321 to 1144 days. The certificate is a relatively complex document. In this work,I focused only on its basic features, but they differ visibly between malware and benign traffic. Due to the more complex structure ofthe certificate, it might be useful to examine it more closely for whichwas not enough space in this thesis.

5.2.4 Versions

As shown in Table B.2 in Appendix B, malware families analyzed in this thesis are still using the older version of TLS, specifically version 1.0. The gradual migration to the most widely used and recommended version of TLS 1.2 is also obvious. In the examined sample of benign traffic all communications between a client and a server were established via the TLS 1.2 version.

34 5. Malware and benign traffic comparison

However, according to SSL Labs statistics [40], support for TLS version 1.0 in the web environment is around 70% up to November 3, 2018, which is not negligible amount. Therefore, at present, the SSL/TLS protocol version cannot be considered as a significant feature to distinguish malware from regular traffic, even though the occurrence of communications established by TLS version 1.0 should be suspicious. For several months, efforts have been made to deprecate versions 1.0 and 1.1, so in the future, communications via these versions could be more clearly linked to malicious activity, but it is a question of how malware authors will adapt to this situation. In the samples already investigated in this thesis there is seen upgrading of malware and its adaptation to current changes in network security.

5.3 Summary

Based on the results of the malware and benign encrypted traffic analysis and the comparisons of SSL/TLS handshake parameters, it can be concluded that there are visible differences between the values of offered cipher suites and supported extensions, which malware kinds exploit in their activities and which appear in the regular SSL/TLS encrypted operations. It can also be argued that the certificate itself used by the server for its authentication after a deeper examination can play an important role in identifying individual malware families in benign encrypted traffic. Basic features of the certificate such as the certificates chain structure and the validity of certificates are significantly different between malware and regular traffic. However, at present the protocol version cannot be considered as a distinguishing characteristic of malware, due to the support for individual TLS versions in current networks, even older ones and it’s a question of how the situation will develop in the future.

35 6 Conclusion

The aim of this thesis was to inspect the SSL/TLS handshake parameters used in the collected samples of malware encrypted traffic and compare them with parameters common in the benign encrypted network traffic with intend to find any specific features that would allow malware detection. In order to meet the goal, it was necessary to study the current situation around the SSL/TLS protocol, its functions, and its role in today’s networks. The whole work is dedicated to six selected malware families abusing the SSL/TLS protocol: Gozi, Trickbot, ZeusPanda, Dridex, IcedID, and Gootkit. The thesis provides the overview of their recent campaigns and pcap files with captured traffic of their activity are the output ofthis thesis. During the SSL/TLS handshake parameters analysis, I paid atten- tion to the protocol version, cipher suites, advertised extensions, and SSL/TLS certificates, mainly to its validity and trustworthiness. Of the mentioned malware families, the most specific parameter values appeared in the Gootkit samples. The comparison results between the collected samples of malware and benign traffic showed that the most promising protocol parameters for malware distinguishing are cipher suites and extensions. Both show quite different values in case of malware and regular traffic. Likewise, the examined basic properties of SSL/TLS certificates suggest that certificates with which the C&C servers normally dis- pose of are fairly specific and their occurrence may indicate malicious activity. On the other hand, on the basis of processed data, it is not possible to designate the protocol version as a characteristic feature due to the current SSL/TLS protocol support on the networks and the gradual adaptation of malware. This thesis and its results confirm that the use of some non-encrypted metadata of SSL/TLS protocol is one of the perspective approaches to malware detection in encrypted network communications.

36 6. Conclusion 6.1 Future work

From the view of the work’s perspective outcomes, it is advisable to consider further research into the detection of malware in general traffic using SSL/TLS handshake parameters. In this thesis I worked with already captured malware communication in the form of pcap files and linked individual samples toa specific malware kind by the SSL/TLS blacklisted certificates used by C&C servers during authentication process. One of the possible further steps may be to extend the analyzed dataset by samples captured in own controlled virtual environment and to link malware, for example, through its source code or behavior in the test environment. Another direction of the future research may be to explore the SSL/TLS certificate properties used during authentication in more detail.

37 Bibliography

[1] DANG, K. Encrypted Cyber Attacks: Real Data Unveils Hidden Danger within SSL, TLS Traffic [online]. 2018 [visited on 2018- 10-07]. Available from: https://blog.sonicwall.com/2018/ 03/encrypted-cyber-attacks-real-data-unveils-hidden- danger-within-ssl-tls-traffic/. [2] DESAI, D. February 2018 Zscaler SSL Threat Report [online]. 2018 [visited on 2018-10-07]. Available from: https : / / www . zscaler.com/blogs/research/february-2018-zscaler-ssl- threat-report. [3] VELAN, P. et al. A Survey of Methods for Encrypted Traffic Classification and Analysis. In: International Journal of Network Management. John Wiley & Sons, Ltd., 2015, vol. 25, pp. 355–374. No. 5. ISSN 1055-7148. [4] FRANKEL, S.; KRISHNAN, S. IP Security (IPsec) and Inter- net Key Exchange (IKE) Document Roadmap. Request for Com- ments: 6071 [online]. 2011 [visited on 2018-10-07]. Available from: https://tools.ietf.org/html/rfc6071. [5] BARNES, R. et al. Deprecating Secure Sockets Layer Version 3.0. Request for Comments: 7568 [online]. 2015 [visited on 2018-10-17]. Available from: https://tools.ietf.org/html/rfc7568. [6] MORIARTY, K.; FARRELL, S. Deprecating TLSv1.0 and TLSv1.1: draft-moriarty-tls-oldversions-diediedie-00 [online]. 2018 [visited on 2018-10-17]. Available from: https://tools.ietf.org/ id/draft-moriarty-tls-oldversions-diediedie-00.html. [7] RESCORLA, E. The Transport Layer Security (TLS) Protocol Version 1.3. Request for Comments: 8446 [online]. 2018 [visited on 2018-10-17]. Available from: https://tools.ietf.org/html/ rfc8446. [8] DIERKS, T.; RESCORLA, E. The Transport Layer Security (TLS) Protocol Version 1.2. Request for Comments: 5246 [online]. 2008 [visited on 2018-10-17]. Available from: https://tools.ietf. org/html/rfc5246.

38 BIBLIOGRAPHY

[9] RESCORLA, E. SSL and TLS: Designing and Building Secure Systems. In: 1st ed. Addison-Wesley, 2001, p. 63. ISBN 0-201- 61598-3. [10] SALOWEY, J. et al. Transport Layer Security (TLS) Session Re- sumption without Server-Side State. Request for Comments: 5077 [online]. 2008 [visited on 2018-10-17]. Available from: https: //tools.ietf.org/html/rfc5077. [11] STALLINGS, W. Cryptography and Network Security: Princi- ples & Practice. In: 6th ed. Pearson Education, 2014, pp. 455–463. ISBN 0-273-79335-7. [12] COOPER, D. et al. Internet X.509 Public Key Infrastructure Cer- tificate and Certificate Revocation List (CRL) Profile. Request for Comments: 5280 [online]. 2008 [visited on 2018-10-17]. Available from: https://tools.ietf.org/html/rfc5280. [13] EASTLAKE, D. Transport Layer Security (TLS) Extensions: Ex- tension Definitions. Request for Comments: 6066 [online]. 2011 [visited on 2018-10-17]. Available from: https://tools.ietf. org/html/rfc6066. [14] KESSEM, L. TrickBot Takes to Latin America, Continues to Expand Its Global Reach [online]. 2017 [visited on 2018-10- 18]. Available from: https : / / securityintelligence . com / trickbot-takes-to-latin-america-continues-to-expand- its-global-reach/. [15] TrickBot Banking Trojan Takes Center Stage in 2018 [online]. 2018 [visited on 2018-10-18]. Available from: https://blog. barkly.com/trickbot-trojan-2018-campaigns. [16] GAVRIEL, H. Latest Trickbot Variant has New Tricks Up Its Sleeve [online]. 2018 [visited on 2018-10-18]. Available from: https : / / www . cyberbit . com / blog / endpoint - security / latest-trickbot-variant-has-new-tricks-up-its-sleeve/. [17] JACKSON, D. Gozi Trojan [online]. 2007 [visited on 2018-11-08]. Available from: https://www.secureworks.com/research/ gozi.

39 BIBLIOGRAPHY

[18] KESSEM, L. Ursnif v3 Emerges, Targets Australian Bank Cus- tomers With Redirection Attacks [online]. 2017 [visited on 2018- 11-08]. Available from: https://securityintelligence.com/ ursnif-v3-emerges-targets-australian-bank-customers- with-redirection-attacks/. [19] REAVES, J. Gozi V3 Technical Update [online]. 2018 [visited on 2018-11-08]. Available from: https://www.fidelissecurity. com/threatgeek/gozi-v3-technical-update. [20] FALLIERE, N.; CHIEN, E. Zeus: King of the Bots [online]. 2009 [visited on 2018-11-11]. Available from: http://www.symantec. com/content/en/us/enterprise/media/security_response/ whitepapers/zeus_king_of_bots.pdf. [21] Panda Banker: New Banking Trojan Hits the Market [online]. 2016 [visited on 2018-11-10]. Available from: https : / / www . proofpoint.com/us/threat- insight/post/panda- banker- new-banking-trojan-hits-the-market. [22] VOOLF, D. Panda Malware Broadens Targets to Cryptocurrency Exchanges and Social Media [online]. 2018 [visited on 2018-11- 10]. Available from: https://www.f5.com/labs/articles/ threat- intelligence/panda- malware- broadens- targets- to-cryptocurrency-exchanges-and-social-media. [23] OSBORNE, Ch. Panda Banker Trojan becomes part of Emotet threat distribution platform [online]. 2018 [visited on 2018-11- 10]. Available from: https://www.zdnet.com/article/panda- trojan- becomes - part- of - emotet- threat - distribution- platform/. [24] SPRING, T. New IcedID Trojan Targets US Banks [online]. 2018 [visited on 2018-11-10]. Available from: https://threatpost. com/new-icedid-trojan-targets-us-banks/128851/. [25] BACURIO JR., F. IcedID & Trickbot: A Give-and-Take Relation- ship [online]. 2018 [visited on 2018-11-10]. Available from: https: / / www . fortinet . com / blog / threat - research / icedid --- trickbot--a-give-and-take-relationship.html.

40 BIBLIOGRAPHY

[26] SHULMIN, A.; YUNAKOVSKY,S. Inside the Gootkit C&C server [online]. 2016 [visited on 2018-11-10]. Available from: https: //securelist.com/inside-the-gootkit-cc-server/76433/. [27] DUNCAN, B. Campaign Evolution: EITest from October through December 2016 [online]. 2017 [visited on 2018-11-10]. Avail- able from: https://researchcenter.paloaltonetworks.com/ 2017 / 01 / unit42 - campaign - evolution - eitest - october - december-2016/. [28] OSTROVSKY, G.; KESSEM, L. GootKit Developers Dress It Up With Web Traffic Proxy [online]. 2017 [visited on 2018-11-10]. Available from: https://securityintelligence.com/gootkit- developers-dress-it-up-with-web-traffic-proxy/. [29] CROWE, J. Alert: Malware Being Spread via MailChimp [online]. 2018 [visited on 2018-11-10]. Available from: https://blog. barkly.com/mailchimp-malware-campaigns-2018. [30] KREMEZ, V. Dridex Banking Trojan Returns, Leverages New UAC Bypass Method [online]. 2017 [visited on 2018-11-11]. Avail- able from: https://www.flashpoint-intel.com/blog/cybercrime/ blog-dridex-banking-trojan-returns/. [31] KESSEM, L. The Necurs Botnet: A Pandora’s Box of Malicious Spam [online]. 2017 [visited on 2018-11-11]. Available from: https://securityintelligence.com/the- necurs- botnet- a-pandoras-box-of-malicious-spam/. [32] KANARACUS, Ch. New Dridex Variant Emerges With An FTP Twist [online]. 2018 [visited on 2018-11-11]. Available from: https://threatpost.com/new- dridex- variant- emerges- with-an-ftp-twist/129546/. [33] Malware-Traffic-Analysis.net [online] [visited on 2018-10-26]. Avail- able from: https://www.malware-traffic-analysis.net. [34] BroadAnalysis: Threat Intelligence and Malware Research [online] [visited on 2018-10-26]. Available from: https://broadanalysis. com. [35] SSL Blacklist [online] [visited on 2018-10-26]. Available from: https://sslbl.abuse.ch.

41 BIBLIOGRAPHY

[36] ANDERSON, B.; MCGREW, D. Identifying Encrypted Malware Traffic with Contextual Flow Data. In: Proceedings of the 2016 ACM Workshop on Artificial Intelligence and Security. ACM, 2016, pp. 35–46. AISec ’16. ISBN 978-1-4503-4573-6. [37] Google Transparency Report [online] [visited on 2018-11-23]. Avail- able from: https://transparencyreport.google.com/https/ top-sites. [38] RESCORLA, E. et al. Transport Layer Security (TLS) Renegoti- ation Indication Extension. Request for Comments: 5746 [online]. 2010 [visited on 2018-11-27]. Available from: https://tools. ietf.org/html/rfc5746. [39] CA/Browser Forum - CAB Forum. Ballot 193: 825-day Certificate Lifetimes [online] [visited on 2018-11-25]. Available from: https: //cabforum.org/2017/03/17/ballot-193-825-day-certificate- lifetimes/. [40] Qualys SSL Labs: SSL Pulse [online] [visited on 2018-11-23]. Avail- able from: https://www.ssllabs.com/ssl-pulse/.

42 A The summary of malware campaigns

The Table A.1 provides a summary of recent campaigns for selected malware families using SSL/TLS encrypted traffic to hide their activity. All malware families are Windows-based banking Trojan horses. The data are current to October 2018. Trickbot malspam exploit kits Infection vector phishing drop by Emotet/ drop by Emotet drop by Emotet self-distribution self-distribution phishing, malspam phishing, malspam phishing, malspam the US countries the US, Australia Slovakia, Slovenia The most affected Latvia, Canada Bulgaria, Lithuania Australia, Germany, the Nordic countries the UK, the US, Asia the Netherlands, the US Australia, Italy, Poland the US, Italy, Argentina the UK, France, Australia Australia, Japan, the UK Germany, France, the UK Columbia, Equador, Canada - - Zeus Zeus Dyre Snifula Ursnif Related families malware Dyreza/ 2018 2018 2017 2018 2018 2018 Last June activity March August January October November 2016 2007 2016 2017 2014 2014 Discovery Table A.1: The summary of recent malware campaigns Gozi IcedID Dridex Gootkit Trickbot ZeusPanda

43 B Results of SSL/TLS handshakes analysis

Table B.2 provides an overview of parameters exchanged during SSL/TLS handshakes between malware and C&C servers. Extensions are represented in a hexadecimal code in Table B.2 and their mapping to a text form is presented in B.1.

Table B.1: Mapping extensions to the hex code used in Table B.2

hec code extensions 0x0000 server_name 0x0005 status_request 0x000a supported_groups 0x000b ec_point_formats 0x000d signature_algorithms 0x0017 extended_master_secret 0x0023 SessionTicket TLS 0x3374 next_protocol_negotiation 0xff01 renegotiation_info

44 B. Results of SSL/TLS handshakes analysis 0xff01 0x000a 0x000b 2017-03-30 TLS 1.2 List 3 0x000d TLS 1.0 0x002f 0xff01 0xff01 0x000a 0x000b TLS 1.2 List 3 0x000d TLS 1.2 0x003c 91.92.136.107 Dridex | 2017-12-04 0xff01 0x000a 0x000b 107.170.65.224 TLS 1.0 List 2 TLS 1.0 0x002f 0xff01 0x0000 0x000a 2018-09-04 2018-09-06 TLS 1.0 List 2 0x000b TLS 1.0 0x002f 0xff01 IcedID 0xff01 0x0000 0x000a 0x000b 2018-06-26 TLS 1.2 List 3 0x000d TLS 1.2 0x003c 0xff01 TLS 1.2 0xc030 85.228.193.94 | List 1 0xff01 0xff01 0x000a 0x0005 0x0017 0x0023 0x000b 0x000b 0x000d TLS 1.2 0x0023 2017-06-12 89.231.13.27 Trickbot TLS 1.0 0xc014 0xff01 0x000a 2018-09-19 2018-07-31 2018-06-14 2017-06-14 TLS 1.0 List 2 0x000b TLS 1.0 0xc014 0xff01 0x000b 0xff01 0x000a Gozi TLS 1.0 List 2 0x000b TLS 1.0 0x002f 0xff01 Table B.2: Malware SSL/TLS handshakes analysis results 0xff01 0x000a 0x0023 0x3374 0x0023 0x3374 Gootkit TLS 1.0 List 4 0x000b TLS 1.0 0xc014 0x000b 0xff01 0x0000 0x000a 0x000b Zeus Panda TLS 1.2 List 3 0x000d TLS 1.2 0x003c 0xff01 version version Client List of cipher suites Extensions Server Cipher suite Extensions TLS TLS

45 C Pcap files with analyzed samples

The pcap files with the captured benign traffic sample and collected samples of different malware kinds used in the analysis are available in the archive of this thesis in Masaryk University’s information system. All communication is filtered for encrypted SSL/TLS traffic with minimal background traffic. Individual malware samples are labeled with the date of capture and malware’s name:

∙ Trickbot,

∙ Gozi,

∙ ZeusPanda,

∙ IcedID,

∙ Gootkit,

∙ Dridex.