Data Exfiltration Techniques

Transcription

1 Data Exfiltration Techniques Introduction In this article we will see how malware encode or encrypt data that s exfiltrated to the Command and Control Server from infected machines. This is often done using a custom encoding or encryption algorithm. It is becoming increasingly common these days to see malware using this technique to prevent Security Analysts from understanding the type of data that is being exchanged between the malware and its Server. Similarly, these algorithms can also be used for randomizing the artifact details such as names of the files or registry keys created on the infected machine. In all such cases, Behavioral Analysis of the malware is not sufficient. Only after analyzing the code used by the malware can these algorithms be understood. Randomization Most malware create certain disk artifacts once they execute. If these disk artifacts have names that remain the same upon multiple executions of the malware, then it becomes easy to discover the presence of the malware on other machines using the indicators gathered during Behavioral Analysis. To prevent this, malwares can use custom algorithms that are used to generate random names for the disk artifacts they create. Similarly, most malware will gather some data from the infected machine and send it to the attacker s controlled server. If this communication channel is not encrypted or it sends the data in plain text, then it becomes trivial to understand the intention of the malware and its nature. There are certain Win32 APIs which are often used to generate a random value which in turn is used in a custom obfuscation or encryption algorithm to randomize the disk artifact names or encrypt the communication channel. Two of these Win32 APIs which are quite commonly used are: GetTickCount() and QueryPerformanceCounter(). In this article, we are going to look into a Custom Encryption and Encoding algorithm that uses QueryPerformanceCounter to generate a 16 byte Random Seed. For the purpose of completeness, we will look at how the data is gathered from the machine and what type of data it is, followed by the details of the Encryption and Encoding algorithms. Collection of Data Once the malware has successfully executed on the machine, it proceeds to gather various details specific to the machine like the MAC Address, Username, Hostname, IP Address, Timestamp and destination domain name. Below is a high level overview of how these details are gathered and in what format are they captured. Data is collected by calling Win32 APIs like GetAdaptersAddresses, GetUserNameA, GetCurrentProcessID, gethostname, gethostbyname and GetLocalTime. The data is gathered using the return values of the above functions and stored at 0041C1D0 as shown below:

2 Here mark:xxsy is a marker for the data collected. Then it calls the main Encryption Routine at to encrypt this data: Stack arguments: 0041C1D0 Pointer to the Data Collected from the machine 0041C360 Encrypted Data will be stored here Random Seed Generation Once the data has been collected from the system, it starts the encryption routine. The first step in the encryption routine is to generate the random seed which will be used in the algorithm. To generate the random seed, the QueryPerformanceCounter API is used as shown below: The function prototype of QueryPerformanceCounter() is: BOOL WINAPI QueryPerformanceCounter( _Out_ LARGE_INTEGER *lpperformancecount ); It accepts one argument, which is a pointer to the Performance Counter. Once the API has executed, it will return the Performance Counter value at this memory address. The return value has a size of 2 DWORDs. In our case, the algorithm uses only the first DWORD. Stack arguments just before the call to QueryPerformanceCounter: So, the return value will be stored at the address, 0012FD78: Below is an explanation of the code used to generate the 16 byte Random Seed:

3 LEA EAX,DWORD PTR SS:[EBP-1C] PUSH EAX ; pointer to Performance 1 2 Counter CALL DWORD PTR DS:[<&KERNEL32.QueryPerf>; QueryPerformanceCounter 3 PUSH DWORD PTR SS:[EBP-1C] ; Arg1 (1st DWORD of Performance Counter) CALL sysmgr.00404e15 POP ECX CALL sysmgr.00404e27 ; Subroutine to modify the first 8 9 DWORD MOV BYTE PTR DS:[EDI+ESI],AL ; Form the Random Seed byte 10by byte 11 TEST AL,AL 12JNZ SHORT sysmgr b7 13MOV BYTE PTR DS:[EDI+ESI],1 14INC EDI CMP EDI,10 ; Total Length of the seed is 0x10 bytes JL SHORT sysmgr After it retrieves the value of the Performance Counter, the first DWORD is passed to the subroutine at address 00404E27: This subroutine will modify the value of the DWORD and finally store the lower byte of the high order word in AL. This value will then be written to the new memory location. In each loop, one byte of random seed is generated. Since the total length of the seed is 16 bytes, there will be 16 invocations of QueryPerformanceCounter and it will write a new byte each time to the memory address where the random seed is stored. The random seed will be stored at the memory address [EDI+ESI], which is 00922D00 in our case. Before the random seed generation: It contains 0xBAADF00D because it is a new chunk of memory allocated by RtlAllocateHeap. After the first execution of the loop, the byte 0 27 is written to this location: After the above loop completes and the complete 16 byte random seed is generated and stored at 00922D00, it will copy the random seed to a new location. Below is an explanation of the code: 1PUSH 10 2LEA EAX,DWORD PTR DS:[EBX+1] 3PUSH ESI 4PUSH EAX 5MOV BYTE PTR DS:[EBX],1 ; EBX is 00B30018 where the random seed is 6copied to.

4 CALL sysmgr.00403ed0 EBX points to the location where the value of random seed will be copied to. This memory address is 00B30018 in our case. The first byte of this is fixed and it is The subroutine at 00403ED0 is used to write the random seed to the new memory location. MOV AL,BYTE PTR DS:[ESI] ; ESI points to the original location of 1 random seed. 2 MOV BYTE PTR DS:[EDI],AL ; EDI points to the new location of 3 random seed. 4 MOV AL,BYTE PTR DS:[ESI+1] 5 MOV BYTE PTR DS:[EDI+1],AL 6 MOV AL,BYTE PTR DS:[ESI+2] 7 SHR ECX,2 8 MOV BYTE PTR DS:[EDI+2],AL 9 ADD ESI,3 10ADD EDI,3 11 CMP ECX,8 JB SHORT sysmgr.00403f54 It copies the random seed this way: 1. It first copies 3 bytes of the random seed to the new location, byte by byte. 2. It then copies 3 DWORDs of the random seed to the new location, DWORD by DWORD as shown below. 1. It then writes 1 byte to the new location. After the above subroutine has executed, the new random seed is stored as shown below. Encryption Key Formation Once the random seed is generated and copied to 00B30018, it calls a subroutine at to form the Encryption Key. The stack arguments: 0012ED30 Location of the new encryption key 00922D00 Original location of the random seed 00B30019 New location of the random seed After we step into the subroutine at : 1MOV ECX,sysmgr.00416CA0 ; 00416CA0 is the location of the private 2key 3PUSH 12 ; The total size of the key is 0x12 DWORDs 4XOR EDX,EDX 5SUB ECX,EAX // subtract 12ED30 from 416CA0

5 POP EDI ; EDI will be used as the outer loop counter The malware has the private key used for the encryption stored at the address, 00416CA0. The size of this key is 0 12 DWORDs or 72 bytes. This key along with the random seed will be used to form a new key located at 0012ED byte key located at 00416CA0: Here is the loop used to generate the new key: Here is the explanation of the code: XOR ESI,ESI MOV DWORD PTR SS:[EBP-8],4 ; Initialize the inner loop counter to 4 1 MOV EBX,DWORD PTR SS:[EBP+C] ; EBX points to the original 2 location of random seed 3 MOVZX EBX,BYTE PTR DS:[EDX+EBX] ; Read one byte at a time from the 4 random seed 5 SHL ESI,8 6 OR ESI,EBX ; ESI will stored one DWORD from the random seed 7 INC EDX 8 CMP EDX,10 ; Check if all the bytes from the random seed have 9 been read 10JL SHORT sysmgr c7 11 XOR EDX,EDX ; If all the bytes from the random seed are read then 12reset EDX 13DEC DWORD PTR SS:[EBP-8] 14JNZ SHORT sysmgr b3 15MOV EBX,DWORD PTR DS:[ECX+EAX] 16XOR EBX,ESI ; XOR the DWORD from random seed with the private key 17MOV DWORD PTR DS:[EAX],EBX ; new Encryption key will be stored at ED30 ADD EAX,4 DEC EDI ; There are a total of 12 DWORDs in the key JNZ SHORT sysmgr aa Here is an explanation of the encryption routine: 1. It reads one DWORD (byte by byte) from the random seed. 2. It XORs the DWORD read from the random seed with the DWORD read from private key. 3. It stores the result into the location of the new encryption key. 4. It reads the bytes from the random seed in a cyclic order. Since the length of the random seed is 0 10 bytes or 4 DWORDs and the length of the private key is 0 48 bytes or 0 12 DWORDs, it reads the bytes from the random seed from start once it has finished reading all the bytes. Before the key formation routine has completed executing, at address 0012ED30:

6 Once the above loop has executed, the new encryption key is stored at 0012ED30 as shown below: Key Modification Routine Once the new encrypted key is formed and stored at 0012ED30, in the next loop this key is modified. It reads 2 DWORDs at a time and modifies them using a subroutine at Below is an explanation of the code: MOV ECX,DWORD PTR SS:[EBP+8] ; ECX points to the key LEA EAX,DWORD PTR SS:[EBP-4] ; This will hold the final modified value of the first DWORD PUSH EAX ; EAX points to 0012ED00 LEA EBX,DWORD PTR SS:[EBP-8] ; This will hold the final modified value of the second DWORD CALL sysmgr MOV EAX,DWORD PTR SS:[EBP+8] ; EAX points again to the start of the Key, 0012ED30 POP ECX ; 0012ED00 MOV ECX,DWORD PTR SS:[EBP-4] ; Final DWORD from previous iteration is stored in ECX MOV DWORD PTR DS:[EAX+ESI*4],ECX ; Modify the first DWORD of the key MOV ECX,DWORD PTR SS:[EBP-8] ; 13MOV DWORD PTR DS:[EAX+ESI*4+4],ECX ; Modify the second DWORD of 14 the key 15 INC ESI INC ESI ; Increment ESI two times since we are modifying two DWORDs at a time CMP ESI,12 ; The total length of the key is 0x12 DWORDs JL SHORT sysmgr e1 Before the execution of the above loop, the key at 0012ED30 is: Once the above subroutine has executed, the key is modified as shown below: Encryption of Data Once the encryption key has been formed, the data that was gathered previously from the machine

7 will be encrypted using it. In the Data Encryption Subroutine, we read two DWORDs at a time from the data and use the encryption key to modify them. Once this is done, each of these 2 DWORDs are written to the new memory location. The subroutine at is used to encrypt two DWORDs at a time. It passes 2 parameters: 12FD8C One of the 2 encrypted DWORDs will be stored here. 41C1D0 Points to the data to be encrypted It reads two DWORDs at a time from the data to be encrypted and stores them at addresses 12FD88 and 12FD8C as shown below: Once the subroutine at has executed, these two DWORDs will be encrypted as shown below: Now these two DWORDs will be written to the new memory location. Below is an explanation of the encryption subroutine:

8 The MOV subroutine EAX,DWORD at 00403ED0 PTR SS:[EBP+8] will be used to write ; the EAX DWORD holds to the memory data location. to be encrypted MOV ECX,DWORD PTR DS:[EAX+EDI*8] ; First DWORD from the data to be encrypted is stored in ECX As 1 MOV can be EAX,DWORD seen above, the PTR DWORDs DS:[EAX+EDI*8+4] at 12FD88 and 12FD8C ; Second are swapped DWORD and from written the to data the new to memory 2 be encrypted location, 00B is stored in EAX 3Also, MOV it is DWORD important PTR to SS:[EBP-C],EAX note that during Random ; Seed Store Generation, second the DWORD 16 byte at random 0012FD88 seed was 4written LEA to EAX,DWORD the memory PTR address, SS:[EBP-8] 00B MOV DWORD PTR SS:[EBP-8],ECX ; Store the first DWORD at 0012FD8C So, the encrypted data is stored after the random seed. 6 PUSH EAX 7The LEA loop EBX,DWORD above continues PTR to SS:[EBP-C] execute for the entire length of the data. 8After LEA the ECX,DWORD loop has executed PTR completely, SS:[EBP-1064] the encrypted ; Points data is stored the as shown 0x48 below: byte key 9 CALL sysmgr ; Modify the first and second DWORDs stored 10at 0012FD88 and 0012FD8C 11 PUSH 4 12 Obfuscation LEA EAX,DWORD of Encrypted PTR Data SS:[EBP-8] 13PUSH EAX 14 Once the data is encrypted and stored at 00B30029, in the next subroutine at E8 it is LEA EAX,DWORD PTR DS:[ESI-4] 15 obfuscated. PUSH EAX 16CALL sysmgr.00403ed0 ; Store the second DWORD at new memory 17address 18PUSH 4 19 The 2 parameters passed to the obfuscation routine are: MOV EAX,EBX 20PUSH EAX 21PUSH ESI 22 00B30018 CALL sysmgr.00403ed0 Pointer to the random ; seed Store and encrypted the first data DWORD at the new memory 23address C360 ADD ESP,1C The final obfuscated data will be stored here 25 If we INC step EDI into ; the Increment subroutine at E8, EDI to read we can the see the next obfuscation DWORDs algorithm from here: the data to 26be encrypted ADD ESI,8 CMP EDI,DWORD PTR SS:[EBP+10] ; Total of 13 iterations are The required inner loop will to run read 3 times all and data write 3 bytes to the new memory location. The outer loop will use JL the SHORT 3rd byte sysmgr fa from the previous sequence of bytes and modify it and write to the new memory location. Outer loop will run 0 39 times; it will write 4 bytes to the new memory location each time. Below is an explanation of the code:

9 MOV EDI,EDX MOV DWORD PTR SS:[EBP-8],2 ; Initialize local variable (this will 1 be incremented in steps of 2) 2 MOV BYTE PTR SS:[EBP-1],0 ; Initialize local variable 3 MOV EAX,ESI 4 MOV DWORD PTR SS:[EBP-C],6 ; Initialize local variable (this will 5 be decremented in steps of 2) 6 SUB EDI,ESI 7 MOV DWORD PTR SS:[EBP-10],3 ; Inner loop counter 8 MOV BL,BYTE PTR DS:[EAX] ; Read a byte from the encrypted data 9 MOV CL,BYTE PTR SS:[EBP-8] 10ADD DWORD PTR SS:[EBP-8],2 ; Increment local variable by 2 11 SHR BL,CL ; modify BL 12MOV ECX,DWORD PTR SS:[EBP-C] 13 SUB DWORD PTR SS:[EBP-C],2 ; Decrement local variable by 2 14 OR BL,BYTE PTR SS:[EBP-1] ; Modify BL 15 MOV BYTE PTR DS:[EDI+EAX],BL ; Write BL to new location MOV BL,BYTE PTR DS:[EAX] 18 SHL BL,CL 19 SHR BL,2 20 INC EAX 21 DEC DWORD PTR SS:[EBP-10] ; Decrement inner loop counter 22MOV BYTE PTR SS:[EBP-1],BL ; This value will be used in OR 23operation in next iteration 24JNZ SHORT sysmgr b 25MOV AL,BYTE PTR DS:[ESI+2] 26AND AL,3F 27MOV BYTE PTR DS:[EDX+3],AL 28ADD ESI,3 29ADD EDX,4 DEC DWORD PTR SS:[EBP-14] ; Decrement outer loop counter JNZ SHORT sysmgr c As can be seen above, it modifies the bytes of Encrypted Data and the Random Seed. It also adds an extra byte after every 3 bytes which is a modification of the third byte in the previous byte sequence. Before the obfuscation of encrypted data: After the obfuscation of encrypted data: So, the new size of the obfuscated data is greater than the encrypted data. Encoding the Obfuscated Data Once the data is encrypted and stored at 0041C360, in the next subroutine the malware will encode this data as shown below:

10 Below is an explanation of the code: MOV ESI,EAX SHL ESI,2 ; ESI will be the total length of the encrypted data above (0xE4 bytes) 1 XOR EDX,EDX 2 TEST ESI,ESI 3 JLE SHORT sysmgr b5 4 MOV EAX,DWORD PTR SS:[EBP+C] ; EAX points to encrypted data 5 LEA ECX,DWORD PTR DS:[EDX+EAX] ; EDX is the counter used as an 6 offset into the encrypted data 7 MOV AL,BYTE PTR DS:[ECX] ; Read a byte from the encrypted data 8 CMP AL,19 ; If less than 19 then add 41 to it 9 JA SHORT sysmgr ADD AL,41 11 JMP SHORT sysmgr c 12CMP AL,1A ; If it is greater than 19 then it checks if it is 13lesser than 1A 14JB SHORT sysmgr CMP AL,33 16JA SHORT sysmgr ADD AL,47 ; Add 47 if it is greater than 1A but less than JMP SHORT sysmgr c 19 CMP AL,34 20 JB SHORT sysmgr a0 21 CMP AL,3D JA SHORT sysmgr a0 SUB AL,4 ; If greater than 34 but less than 3D then subtract MOV BYTE PTR DS:[ECX],AL ; Write the modified byte into encrypted 27 data 28JMP SHORT sysmgr b0 29CMP AL,3E 30JNZ SHORT sysmgr a9 31MOV BYTE PTR DS:[ECX],2B 32JMP SHORT sysmgr b0 33CMP AL,3F 34JNZ SHORT sysmgr b0 35MOV BYTE PTR DS:[ECX],2F INC EDX CMP EDX,ESI JL SHORT sysmgr This encoding algorithm will check the value of each byte read from the encrypted data and modify it based on various comparisons. The resulting encrypted data will consist of readable ASCII characters as shown below: Random Seed Transfer Once the encrypted data is received by the Server, it will use the Decryption algorithm to retrieve the data. However in order to decrypt, the Server requires the random seed which was generated at

11 the client side and used to form the encrypted data. All other elements used to perform the encryption such as the private key are already available to the Server. If we look at the encrypted data stored at 0041C360 as shown above, the first byte is always fixed as The next 16 bytes are the obfuscated version of the random seed. In the random seed generation section, we can see that the 16 byte random seed is written to the memory address 00B After it is used to form the encryption key and encrypt the data, in the obfuscation stage, the random seed itself is also obfuscated. So, the random seed is present in the Header of the Encrypted Data sent to the Server. In this way, the Server now has all the elements required to decrypt and retrieve the data. Sending the Encrypted Data Now that the data is encrypted and stored at 00413C60, it is ready to be transferred to the Server. In our case, the malware makes use of HTTP Protocol to send this data to the Server. It first forms the HTTP Header field, Set-Cookie: as shown below: Stack arguments: The subroutine at 00404A40 takes 2 arguments. 00B30018 Pointer to the Set-Cookie: Header 0041C360 Pointer to the encrypted data After this subroutine has executed: Once this is done, it will add this field to the HTTP Request Headers: Stack arguments: 00CC000C Handle returned by HTTPOpenRequestA 00B30018 Pointer to the Set-Cookie field that needs to be added to the HTTP Request Headers Then it creates a Thread in the Suspended State: Stack arguments:

12 It resumes the Thread by calling WaitForSingleObject: 0x1C8 is the handle of the Thread created above. Once WaitForSingleObject has executed, we break at the Thread Function at C. This Thread Function will be used to send the HTTP Request to the Server: Once HTTPSendRequestA has executed, it will send the HTTP request to the Server along with the encrypted data sent in the Set-Cookie header field. Conclusion In this way, we can see how malware protect the data exchanged between them and their servers from behavioral analysis. These methods can also be used to randomize the artifact details to prevent the discovery of malware on other machines.