Credit card exfiltration
DNS exfiltration
This current malware uses DNS requests to exfiltrate the stolen data. Requests have the following scheme:
- Encoded_data.domain.com
In this example, the domain server of domain.com is managed by the attacker in order to get the “encoded_data”. We identified three different DNS requests:
- Id.beacon.encoded_data1.encoded_data2.domain.com
This request is the heartbeat. The ID is a random ID generated during the first execution of the malware. Encoded_data1 is the IP address of the infected machine and encoded_data2 is the host name of the machine.
- Id.alert.encoded_data3.domain.com
The ID is the same random ID as used in the example above and encoded_data3 is a process name. The attackers receive the process name each time a credit card number is found in the memory.
- Id.encoded_data4.encoded_data5.domain.com
The ID is, again, the ID described above. Encoded_data4 is the value stored right before the separator “=” within the memory and encoded_data5 is the value stored right after the separator “=”. Further explanation will be given in the article’s section Memory Carving.
In order to perform the DNS query, the malware uses the function getaddrinfo() in Ws2_32.dll or Wship6.dll (for IPv6 support for Windows 2000).
Data obfuscation
The data transmitted in the DNS request is encoded. Here is the code that performs this task:
The pseudo code:
Foreach bytes:
a = byte XOR 0xAA
b = a XOR 0x9B
value = b XOR 0xC3
The three XOR can be simply resumed to XOR 0xF2. Below, you can see an example of decoded and encoded data:
c5008015.beacon.c3cbc0dcc3c4cadcc4cbdcc4cb.a2b3a7bedfb3b0b1c3c0c1c6.domain.com
paul@gdata:~ $ ./decode.py c3cbc0dcc3c4cadcc4cbdcc4cb
192.168.69.69
paul@gdata:~ $ ./decode.py a2b3a7bedfb3b0b1c3c0c1c6
PAUL-ABC1234
Installation
The malware can be executed with the following option:
- Install: is used in order to install a service, needed to start the malware;
- Uninstall: this option uninstalls the service;
- Start: this option is used to start the malware (if the service is already installed);
- Stop: this is used to switch off the service;
- Setd: is used to set the domain used to exfiltrate the data.
An interesting notion: the domain is set during the installation of the malware (with the Setd parameter). This marks a difference between the sample analyzed by Trend Micro and this current sample, because the domain is not hardcoded in the sample. Thanks to this approach it is not possible to find the domain used in case the sample is found within a database, such as VirusTotal. To know the domain name used to exfiltrate the data, one needs to analyze an infected machine. The domain is stored in the registry:
.Default\CurrentUser\ur
The .Default registry is an uncommon registry entry. This registry is not the Default User registry but the default registry in C:\Windows\System32\config\.
Domain obfuscation
The domain used for the exfiltration is not stored in plain text within the registry. Here is a screenshot of the algorithm needed to decode the content:
Here is the pseudo code:
Foreach bytes:
a = byte >> 5
b = byte << 3
value = a OR b
Strings obfuscation
We assume that the developer tried to obfuscate several strings in the binary. However, the implementation is faulty and not efficient: each character of a string is “xored” with 0x4D two times. But if one applies xor two times with the same value, the result is the original value… Therefore, the strings are in clear in the binary:
A xor 0x4D xor 0x4d = A
Memory Carving
To get the credit card data that is stored within the memory, the malware opens the processes currently executed on the system, except for these:
smss.exe, csrss.exe, wininit.exe, services.exe, lsass.exe, svchost.exe, winlogon.exe, sched.exe, spoolsv.exe, System, conhost.exe, ctfmon.exe, wmiprvse.exe, mdm.exe, taskmgr.exe, explorer.exe, RegSrvc.exe, firefox.exe, chrome.exe
To find the credit card data stored, the attackers use an algorithm which can be refined to the following regular expression:
\d{15,19}=\d{13,}
Here is the description of the expression:
- \d{15,19}: credit card number, between 15 and 19 digits length
- = : separator
- \d{13,}: number with 13 or more digits.
An example of a credit card number is hardcoded within the malware:
4207670075018922=16031010000863456429
The credit card data hardcoded in the sample is used to identify if the malware is currently scanning itself. If the malware found this information in the memory, the carving is stopped and the next process is analyzed.
Conclusion
The analysis explains how the cybercriminals work today: we can assume that the cyber-criminals behind The Home Depot attack probably also targeted different companies with different command and control communication channels.
We think that the approach seen in this sample is really interesting and this sample is more mature. In our case, the exfiltration method is carried out really cleverly and is rather uncommon.
We strongly advise companies which use PoS systems to have a passive DNS to store and monitor DNS activities. If configured correctly, this passive DNS can send out alerts in case suspicious behavior is detected. Furthermore, these logs can and will help in case a post-attack analysis is required. Alternatively, the traffic of PoS machines could be restricted to relevant domains. Such a whitelisting approach would prevent contact to unauthorized domains. Concerning the containment, the best approach is to create an internal DNS zone that matches the domain of the attackers and which points to a server located in the company.
IOC
File
%Windows%\Genuine\tf (log file used by the malware)
File MD5
a5dc57aea5f397c2313e127a6e01aa00
Registry
.Default\CurrentUser\id (this key contains a random ID to identify the infected machine)
.Default\CurrentUser\ur (this key contains the encoded domain of the attackers)
Service
A Service called hdmsvc with the description “Windows Hardware Management Driver”
---------------------------------------
(1)
http://krebsonsecurity.com/2014/09/home-depot-56m-cards-impacted-malware-contained/
(2)