It has become common for users to use Google to find information that they do not know. In a quick Google search you can find practically anything you need to know. Links returned by a Google search, however, are not guaranteed to be safe. In this situation, the threat actors decided to take advantage of this behavior by using Search Engine Optimization (SEO) to make their malicious links more prevalent in the search results, enabling them to target users with the Zeus Panda banking Trojan. By poisoning the search results for specific banking related keywords, the attackers were able to effectively target specific users in a novel fashion.
By targeting primarily financial-related keyword searches and ensuring that their malicious results are displayed, the attacker can attempt to maximize the conversion rate of their infections as they can be confident that infected users will be regularly using various financial platforms and thus will enable the attacker to quickly obtain credentials, banking and credit card information, etc. The overall configuration and operation of the infrastructure used to distribute this malware was interesting as it did not rely on distribution methods that Talos regularly sees being used for the distribution of malware. This is another example of how attackers regularly refine and change their techniques and illustrates why ongoing consumption of threat intelligence is essential for ensuring that organizations remain protected against new threats over time.
INITIAL ATTACK VECTOR
The initial vector used to initiate this infection process does not appear to be email based. In this particular campaign, the attacker(s) targeted specific sets of search keywords that are likely to be queried by potential targets using search engines such as Google. By leveraging compromised web servers, the attacker was able to ensure that their malicious results would be ranked highly within search engines, thus increasing the likelihood that they would be clicked on by potential victims.
In one example, the attacker appeared to target the keyword search containing the following search query:
In most instances, the attacker was able to get their poisoned results displayed several times on Page 1 of the Search Engine Results Page (SERP) for the keyword search being targeted, in this case “al rajhi bank working hours in ramadan”. A sample of the malicious results returned by Google is included in the image below.
By leveraging compromised business websites that have received ratings and reviews, the attacker could make the results seem more legitimate to victims, as can be seen by the star/rating displayed alongside the results in the SERP.
The attacker targeted numerous keyword groups, with most being tailored towards banking or financial-related information that potential victims might search for. Additionally, certain geographic regions appear to be directly targetedy, with many of the keyword groups being specific to financial institutions in India as well as the Middle East. Some examples of keyword searches being targeted by this campaign were:
“nordea sweden bank account number”
“al rajhi bank working hours during ramadan”
“how many digits in karur vysya bank account number”
“free online books for bank clerk exam”
“how to cancel a cheque commonwealth bank”
“salary slip format in excel with formula free download”
“bank of baroda account balance check”
“bank guarantee format mt760”
“free online books for bank clerk exam”
“sbi bank recurring deposit form”
“axis bank mobile banking download link”
Additionally, in all of the cases Talos analyzed, the titles of the pages that functioned as the entry point into this malware distribution system had various phrases appended to them. Using the “intitle:” search parameter, we were able to positively identify hundreds of malicious pages being used to perform the initial redirection that led victims to the malicious payload. Some examples of these phrases are included below:
“found download to on a forum”
“found global warez on a forum”
“can you download free on the site”
“found download on on site”
“can download on a forum”
“found global downloads on forum”
“info site download to on forum”
“your query download on site”
“found download free on a forum”
“can all downloads on site”
“you can open downloads on”
In cases where victims attempt to browse to the pages hosted on these compromised servers, they would initiate a multi-stage malware infection process, as detailed in the following section.
Ironically we have observed the same redirection system and associated infrastructure used to direct victims to tech support and fake AV scams that display images informing victims that their systems are infected with Zeus and instructing them to contact the listed telephone number.
INFECTION PROCESS
When the malicious web pages are accessed by victims, the compromised sites use Javascript to redirect clients to Javascript hosted on an intermediary site.
This results in the client retrieving and executing Javascript located at the address specified by the document.write() method. The subsequent page includes similar functionality, this time resulting in an HTTP GET request to another page.
The intermediary server will then respond with a HTTP 302 which redirects clients to another compromised site which is actually being used to host a malicious Word document. As a result, the client will follow this redirection and download the malicious document. This is a technique commonly referred to as “302 cushioning” and is commonly employed by exploit kits.
Following the redirect results in the download of a malicious Microsoft Word document.
Following the download of the malicious Word document, the victim is prompted by their browser to Open or Save the file. When opened, the document displays the following message, prompting the victim to “Enable Editing” and click “Enable Content”.
Following these instructions will result in the execution of malicious macros that have been embedded in the Word document. It is these macros that are responsible for downloading and executing a PE32 executable, thus infecting the system. The macro code itself is obfuscated, and quite basic. It simply downloads the malicious executable, saves it into the %TEMP% directory on the system using the filename such as “obodok.exe”.
In this case, the malicious executable was being hosted at the following URL:
hXXp://settleware[.]com/blog/wp-content/themes/inove/templates/html/krang.wwt
The macros use the following Powershell command to initiate this process:
A review of DNS related information associated with the domain hosting the malicious executable shows that there were two significant spikes in the amount of DNS requests attempting to resolve the domain, occurring between 06/07/2017 and 06/08/2017.
Settleware Secure Services, Inc. is a document e-Signing service that allows documents to be signed electronically. It is used across a number of different processes, including Real Estate escrow e-Signing, and also offers eNotary services.
MALWARE OPERATIONS
The malicious payload associated with the campaign appears to be a new version of Zeus Panda, a banking trojan designed to stealing banking and other sensitive credentials for exfiltration by attackers. The payload that Talos analyzed was a multi-stage payload, with the initial stage featuring several anti-analysis techniques designed to make analysis more difficult and prolonged execution to avoid detection. It also featured several evasion techniques designed to ensure that the malware would not execute properly in automated analysis environments, or sandboxes. The overall operation of the Zeus Panda banking trojan has been well documented, however Talos wanted to provide additional information about the first stage packer used by the malware.
The malware will first query the system’s keyboard mapping to determine the language used on the system. It will terminate execution if it detects the any of the following keyboard mappings:
- LANG_RUSSIAN
- LANG_BELARUSIAN
- LANG_KAZAK
- LANG_UKRAINIAN
The malware also performs checks to determine whether it is running within the following hypervisor or sandbox environments:
- VMware
- VirtualPC
- VirtualBox
- Parallels
- Sandboxie
- Wine
- SoftIce
It also checks for the existence of various tools and utilities that malware analysts often run when analyzing malicious software. A full list of the different environment checks performed by the malware is below:
If any of the environmental checks are met, the malware then removes itself by first writing a batch file to the %TEMP% directory and executing it using the Windows Command Processor. The malware uses RDTSC to calculate the time-based filename used to store the batch file. This batch file is responsible for deleting the original sample executable. Once the original executable has been deleted, the batch file itself is also removed from %TEMP%.
In an attempt to hinder analysis, the initial stage of the malicious payload features hundreds of valid API calls that are invoked with invalid parameters. It also leverages Structured Exception Handling (SEH) to patch its own code. It queries and stores the current cursor position several times to detect activity and identify if it is being executed in a sandbox or automated analysis environment. An example of the use of valid API calls with invalid parameters is below, where the call to obtain the cursor location is valid, while the call to ScreentoClient contains invalid parameters.
Below is an example of a bogus call designed to lure an analyst and increase the time and effort required to analyze the malware. Often we see invalid opcodes used to lure the disassembler, but in this case, the result is that it is in front of hundred of structures too, making it more difficult to recognize good variables.
The below screenshot shows a list of auto populated and useless structures by IDA. These measures are all designed to impede the analysis process and make it more expensive to identify what the malware is actually designed to do from a code execution flow perspective.
Periodically, we can find a valid and useful instruction. Below the EAX register is stored in a variable to be reused later in order to allocate a heap memory chunk to initiate its own unpacked code.
The malware also uses others techniques to make analysis significantly more difficult, like creating hundreds of case comparisons, which makes tracing code much harder.
Below an example of several if conditional statements in pseudo code demonstrating this process and how it can result in impeding the ability to efficiently trace the code.
In order to decrypt the malware code it’s installs an exception handler, which is responsible for decrypting some memory bytes to continue it’s execution.
Below you can see the SEH has just been initialized:
In the same routine, it performs the decryption routine for the following code. We also observed that the high number of exception calls were causing some sandboxes to crash as a way to prevent automated analysis.
Once the data is decrypted and stored into the buffer that was previously allocated, it continues execution back in winmain using a known mechanism, the callback routine feature of EnumDisplayMonitor, by setting up the value of the callback routine towards the patched memory.
During this execution, the malware will then continue to patch itself and continue execution.
The strings are encrypted using an XOR value, however each string uses a separate XOR value preventing an easy detection mechanism. Below is some IDA Python code which can be used to decrypt strings.
def decrypt(data, length, key):
c = 0
o = ''
while c < length:
o += chr((c ^ ord(data) ^ ~key) & 0xff)
c +=1
return o
def get_data(index):
base_encrypt = 0x1251A560
key = Word(base_encrypt+8*index)
length=Word(base_encrypt+2+8*index)
data=GetManyBytes(Dword(base_encrypt+4+8*index), length)
return key, length, data
def find_entry_index(addr):
addr = idc.PrevHead(addr)
if GetMnem(addr) == "mov" and "ecx" in GetOpnd(addr, 0):
return GetOperandValue(addr, 1)
return None
for addr in XrefsTo(0x1250EBD2, flags=0):
entry = find_entry_index(addr.frm)
try:
key, length, data = get_data(entry)
dec = decrypt(data, length, key)
print "Ref Addr: 0x%x | Decrypted: %s" % (addr.frm, dec)
MakeComm(addr.frm, ' decrypt_string return :'+dec)
MakeComm(ref, dec)
except:
pass
This code should comment IDA strings decrypted and referenced where 0x1250EBD2 corresponds to the decryption routine and 0x1251A560 corresponds to the table of strings encrypted
Comments are inserted into the disassembly making it much easier to understand the different features within the malware.
For API calls, there are also well known hash API calls which use the following algorithm. Again this is code which can be used within IDA in order to comment API calls.
def build_xor_api_name_table():
global table_xor_api
if not table_xor_api:
table_xor_api = []
entries = 0
while entries < 256:
copy_index = entries
bits = 8
while bits:
if copy_index & 1:
copy_index = (copy_index >> 1) ^ 0xEDB88320
else:
copy_index >>= 1
bits -= 1
table_xor_api.append(copy_index)
entries += 1
return table_xor_api
def compute_hash(inString):
global table_xor_api
if not table_xor_api:
build_xor_api_name_table()
if inString is None:
return 0
ecx = 0xFFFFFFFF
for i in inString:
eax = ord(i)
eax = eax ^ ecx
ecx = ecx >> 8
eax = eax & 0xff
ecx = ecx ^ table_xor_api[eax]
ecx = ~ecx & 0xFFFFFFFF
return ecx
The malware uses a generic function which takes the following arguments:
- the DWORD which corresponds to the module.
- An index entry corresponding to the table of encrypted string for modules (if not loaded).
- The hash of the API itself.
- The index where to store the api call address.
Below is example pseudo code showing how the API call is performed just to perform a process lookup into memory using the snapshot list.
Once the malware begins its full execution, it copies an executable to the following folder location:
C:\Users\<Username>\AppData\Roaming\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys\
It maintains persistence by creating the following registry entry:
HKEY_USERS\<SID>\Software\Microsoft\Windows\CurrentVersion\Run\extensions.exe
It sets the data value for this registry entry to the path/filename that was created by the malware. An example of the data value is below:
"C:\Users\<Username>\AppData\Roaming\Macromedia\Flash Player\macromedia.com\support\flashplayer\sys\extensions.exe"s\\0
In this particular case, the file that was dropped into the infected user’s profile was named “extensions.exe” however Talos has observed several different file names being used when the executable is created.
Additional information about the operation of the Zeus Panda banking trojan once it has been unpacked has been published here.
CONCLUSION
Attackers are constantly trying to find new ways to entice users to run malware that can be used to infect the victim’s computer with various payloads. Spam, malvertising, and watering hole attacks are commonly used to target users. Talos uncovered an entire framework that is using “SERP poisoning” to target unsuspecting users and distribute the Zeus Panda banking trojan. In this case, the attackers are taking specific keyword searches and ensuring that their malicious results are displayed high in the results returned by search engines
Source:https://blog.talosintelligence.com/2017/11/zeus-panda-campaign.html
Working as a cyber security solutions architect, Alisa focuses on application and network security. Before joining us she held a cyber security researcher positions within a variety of cyber security start-ups. She also experience in different industry domains like finance, healthcare and consumer products.
