We know that the malware is stealing some application data, but we don't know which application it is and what data was stolen. Let's try to find this out by viewing the HTTP payload in the packet bytes (lowest pane) pane of standard Wireshark display as follows:

We can see from the preceding screenshot that the payload started with LokiBot version 18 in Decimal (12 in Hexadecimal) , and we need to divide that by 10 to get the exact version. Next, we had 27 as the identifier for data exfiltration on application credentials. Next, the first word denotes a width of zero, denoting that the payload value will be unpacked as a normal string. Next, we have a word value that denotes a length of 0a, which is 10 in decimal. We can see that we have a length of 10 bytes denoting the binary ID, which is XXXXX11111. Again, we have the next width and length, which will denote the system username; we can see we have a width of one and length of six. Since we have a width of one, we will unpack this data as hex. Therefore, at two bytes each, we have the username that is REM. Next, we have the system name, and again width is 1 and length is 1c, denoting 28. The next 28 bytes indicate that the infected system name is REMWORKSTATION. Following the same notation for the values, the next value shows the domain, which is, again REMWORKSTATION. Let's look at the next hex section as follows:

We have the next four bytes as the Screen Width and the following four as Screen Height. We have a check on local admin and built-in admin, and the preceding screenshot shows that, in the next four bytes, both are showing a one, indicating a yes. The next two bytes are set to one if the OS is 64 bit, which is not the case, so it's set to zero. The next eight bytes define the OS major and OS minor products and the os_bug patch variables, which are 6,3,1,107 respectively. This means that we can denote the OS as 6.3.1.107, which is Windows 8. Additionally, the values stored here are in the little-endian format that means last significant byte is the first. In the next section, we have the following:

We can see the next two bytes as the value denoting the first-time connection as a zero. This means that the victim has connected for the first time. Next, two bytes denote that the data stolen is compressed, while the following two bytes define whether the stolen data is encoded or not, and following up these two bytes are another two bytes defining the encoding type. The next four bytes denote the original stolen data's length, which is 8,545 bytes. A separator is in between, and we again have the width and length for the string:

As shown in the preceding screenshot, we have a 48-byte-long mutex value used by the LokiBot. Next, LokiBot uses this mutex as follows:

• Mutex: B7E1C2CC98066B250DDB2123

Based on this value, the LokiBot's files will be located in the following locations:

• Hash Database: "%APPDATA%\C98066\6B250D.hdb"
• Keylogger Database: "%APPDATA%\C98066\6B250D.kdb"
• Lock File: "%APPDATA%\C98066\6B250D.lck"
• Malware Exe: "%APPDATA%\C98066\6B250D.exe"

If we observe closely we can see that the directory name starts from 8^th character to 13^th character of the Mutex while file name starts from 13^th character to 18^th character.

Well! That was too much information traveling on the network. Let's see what's next:

Next, we have the key length, the key itself, and length of compressed data. We now know that the length of the compressed data is 2,310 bytes, which looks like this:

We can see some of the values as XML and HTML. But, we still need to decompress this data. On researching the malware executable file (Run strings command on the executable), we will discover that one of the strings in the binary executable contains LZSS, which is a popular data-compression encoding scheme. You can find more on compression and decompression at https://github.com/maxim-zhao/aplib.py/blob/master/aplib.py.

Using the library, we can copy the bytes from Wireshark capture and feed it as an input to the decompress function defined in the library. Let's decompress the data as follows:

Well! It looks like the stolen data is from FileZilla, and it looks like a config file. On repeating the analysis for other packets, such as one with the value 2B (keylogger) type, we will have similar data, and on decompression, it will look similar to the following:

Now we have the keylogger data as well. So, what do we know as of now?

We have successfully gathered the following Indicators of Compromise (IOC) details by working on the preceding sample:

• The infected system: 172.16.0.130
• The infected user: REM
• The infected system hostname: REMWORKSTATION
• Domain infected: REMWorkstation
• OS architecture: 32 Bit
• Screen resolution: 3440 x 1440
• Windows OS NT version: 6.3.1 (Windows 8)
• The command and control server: 185.141.27.187
• Malware used: LokiBot
• Malware detection: User-Agent, HTTP method (POST)
• Malware activities: Application Data Exfiltration on FileZilla, Keylogging
• Malware version: 1.8
• Malware compression: LZSS
• Malware encoding: None
• Malware files names: %APPDATA%\C98066\6B250D.*

Amazing! We have plenty of information just from analyzing the PCAP file. Let's look at some more examples in the next section.

In the preceding exercise, we worked on an unknown sample and researched on its IOCs. We were not only able to detect the basic information about the infection but were also able to decode its communication. We found the exfiltrated data sent to the attacker as well. Let’s work on some more samples such as ransomware and banking Trojans in the upcoming sections.