Going Behind the Scenes of Cybercrime Group FIN6’s Attack On Retail and Hospitality

A step that an adversary takes during the post exploitation phase of an attack is to establish a command line interface (CLI) with a computer inside the victim’s network. One recent incident demonstrates the entire intrusion set operated by FIN6[1], a financially motivated threat actor group. This incident shows the phishing email used to gain initial access to the various attack chain components including a reverse shell DLL to provide a command line interface to the adversary.[2] The use of the More_eggs[3] Javascript backdoor in this intrusion set links this incident to FIN6.[4] Companies in the retail and hospitality sectors have been targeted by this group with a specific interest in attacking point of sale (PoS) systems.[5]  What follows is a focused examination of the reverse shell DLL[6] used by FIN6 in this particular incident. Incident responders or threat hunters can take the insights learned here and apply them to similar threats to speed up their investigations.

Identifying the Sample Using Static and Dynamic Analysis

Starting with static analysis of the DLL, one export is found: DllRegisterServer. This is important later on during dynamic analysis in a debugger and in an automated malware analysis environment. This export is how the DLL must be executed when analyzing it via rundll32.exe. This export can be found using the Titanium Platform as seen in Figure 1.

Figure 1: DllRegisterServer Export

Next, looking at the assembly code of the DLL in a disassembler, the procedure immediately after the entry point is a form of execution dispatcher. This particular procedure matches a publicly available YARA rule, “PureBasicDLLNeilHodgson”.[7] The instructions matched by this rule are are highlighted in Figure 2.

Figure 2: Instructions Immediately After Entry Point

The byte string shown here hones in on the first instructions in this procedure:

83 7C 24 08 01 75 ?? 8B 44 24 04 A3 ?? ?? ?? 10 E8

This rule is effective, but does not cover the entire procedure. Depending on inclusion or exclusion of certain PureBasic options in the source code itself, this procedure can change. Therefore, to write a rule which is resilient to any of this type of change, a reference set of benign DLLs compiled using PureBasic must be used. Starting with the source code for a sample DLL which has no user code, a set of “hello world” DLLs were compiled using PureBasic versions 4.10 to 5.71. By analyzing the reference DLLs created by this process, an improved YARA rule for detecting PureBasic DLLs was developed. This new YARA signature is provided at the end of the blog.

The next step is to execute the DLL in an analysis environment and observe the execution in a debugger. By placing a breakpoint on the DllRegisterServer export location in Figure 3, the malicious code in the DLL may be examined.

Figure 3: DllRegisterServer Export Location

The IP address and port used to communicate with the command and control infrastructure are both obfuscated in an identical manner as shown in Figures 4 and 5. This obfuscation is a type of defensive evasion meant to prevent these indicators from being extracted during static analysis.[8] This same obfuscation technique is seen throughout the sample to hide various strings that are important for the malware’s execution.

Figure 4: C2 IP Address 185.204.2[.]182

Figure 5: C2 Port 443

During dynamic analysis, the sample connects out to this IP address over HTTPS. It presents a cmd.exe shell for the adversary to use in the directory that the DLL is located. This allows the adversary to run arbitrary commands on the victim’s computer. This SSL traffic can be decrypted and observed as seen in Figure 6 showing the command prompt.

Figure 6: Decrypted Command Shell C2 Traffic

Finding Related Malware Using the Titanium Platform

This particular sample is cryptographically signed using a software signing certificate. The organization name for this certificate is “D Bacte Ltd”. The details of the software signing certificate can be seen in Figure 7.

Figure 7: Software Signing Certificate

By using the search feature in the Titanium Platform, two additional related malicious DLLs are found that have the same serial number. [10] [11] Both of them are related to the FIN6 DLL and were signed using the same certificate.[12] The specific search index used to find them is the “cert-serial” query keyword. Details from these two files is shown in Figure 8.

Figure 8: Files Related via Signing Certificate

In addition to these two files related via signing certificate, one additional file is found to be related via the ReversingLabs Hash Algorithm (RHA). This algorithm finds files with similar functionality and features, often leveraged by threat hunters to pivot during their analysis.[13] This additional file can be seen in Figure 9.[14]

Figure 9: Malware Related via RHA

In addition to these three related malware files, a cluster of five more files can be found by focusing on the specific bytes of the obfuscation algorithm used throughout the sample. These additional files are quite interesting in that there is no other clear relationship between them and the main sample in question. According to information about the More_eggs javascript backdoor found on the open source, it is being peddled as malware-as-a-service (MaaS) in the underground.[15] The source code for the obfuscator found in this reverse shell DLL is probably being reused by the MaaS provider in other malware files. A full set of identifying hashes of these additional files all related by code reuse is provided at the end of the blog. A YARA rule for detecting this obfuscation technique is provided at the end of the blog.

Conclusion

As we have seen, there are multiple methods one can use in the Titanium Platform to discover related malware files starting with a single malicious DLL. In addition to focusing on code reuse across malware families, checking for abused certificates used to sign other files can reveal additional campaigns from the same adversary. Finally, using multiple static features in the files, the ReversingLabs Hash Algorithm can reveal even more files that may not have any other obvious linkages to the sample in question.

IOCs

Samples

Known FIN6

Related via Certificate

Related via RHA

Related via Code Reuse

IP Address

YARA Rule

rule PureBasicDLL
{
meta:
author = "Malware Utkonos"
date = "2019-11-02"
strings:
$op1 = { 83 7C ( 24 | 25 ) ?? 0? 75 }
condition:
pe.DLL and all of them and
$op1[1] at pe.entry_point and
for 4 i in (1..#op1) : ( @op1[i] >= pe.entry_point and @op1[i] <= pe.entry_point + 100 )
}

rule ObfuscatorDLL
{
meta:
author = "Malware Utkonos"
date = "2019-10-05"
exemplar = "78a87d540c1758c6b4dcabb7b825ea3a186ef61e7439045ece3ce3205c7e85a2"
strings:
$op1 = /(\x8d\x15.{4}\x8d\x0d.{4}\xe8.{4}){3}/
condition:
pe.DLL and all of them and
uint32(@op1 + 13) - uint32(@op1 + 30) == uint32(@op1 + 30) - uint32(@op1 + 47)
}

[1] https://malpedia.caad.fkie.fraunhofer.de/actor/fin6

[2] https://securityintelligence.com/posts/more_eggs-anyone-threat-actor-itg08-strikes-again/

[3] https://malpedia.caad.fkie.fraunhofer.de/details/js.more_eggs

[4] https://usa.visa.com/dam/VCOM/global/support-legal/documents/fin6-cybercrime-group-expands-threat-To-ecommerce-merchants.pdf

[5] https://attack.mitre.org/groups/G0037/

[6] 78a87d540c1758c6b4dcabb7b825ea3a186ef61e7439045ece3ce3205c7e85a2

[7] https://github.com/Yara-Rules/rules/blob/master/Packers/packer.yar

[8] https://attack.mitre.org/techniques/T1140/

[9] https://attack.mitre.org/techniques/T1116/

[10] 511ad7705b216e7e472e496beba53856c97520eac12c83fa0d391594327e80f7

[11] d39f8aa90d54fd010484d7bb54c18549c3f03b02385020a35589dbe49e979bab

[12] 1d8a233cedec0e13df1bda8248dc79a5

[13] https://www.reversinglabs.com/technology/reversinglabs-hash-algorithm

[14] db93d7f80dddb450e0efeabb302d4e6d48a53457309a6369760007911b8f4af8

[15] https://medium.com/@quoscient/golden-chickens-uncovering-a-malware-as-a-service-maas-provider-and-two-new-threat-actors-using-61cf0cb87648