Evolution of Banking Malwares, Part 2

December 26, 2014 by

Shaman Vilen

Web Injects

This technique is used in scenarios where critical information such as Social Security Number (SSN) or Personal Identification Number (PIN) is otherwise not easily available.

Basically, web injects is a technique of injecting unauthorized web content into incoming HTTP response data.

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

The web page content manipulation is possible through browser API hooking, just like the form-grabbing capability discussed before. The banking Trojan can inspect the content received from the server and modify it on the fly before displaying it in the browser.

This is a very powerful technique that can be used to deceive the user, as he will believe that the content he is seeing has been received directly through his bank's website.

Web injects can be used to perform the following:

• Inject HTML content such as HTML input fields in forms to request user's SSN, ATM PIN, etc.;
• Steal or rewrite active sessions cookies to manipulate the active session;
• Inject JavaScript code to perform malicious operations in web pages as they are rendered in the browser;
• And inject HTML with JavaScript code into active sessions to lunch Automated Transfer System (ATS) attacks, which will be discussed soon. This attack enables the malware to execute fraudulent transactions on the user's behalf without revealing any details to the user. For example, the malware can manipulate the account information shown to the user by rewriting the account balances on the client side in the browser.

Here is an example of different web-injects that manipulate various login pages' HTML in attempts to phish extra data from users:

As a real example, the following "webinjects.txt" data attempts to trick the user into providing their ATM PIN number:

This threat has grown considerably. Web-inject rules are now sold openly in the black-market. With this phenomenon comes a standardization of the web-inject configuration file format, and Trojans such as SpyEye and Zeus are now the de facto standard.

Initially, web-injects were embedded statically in the binary configuration file during the build time of the malware and were in an unencrypted form. Afterwards, cybercriminals start to heavily obfuscate these configuration files and host them in the command and control (C&C) server or in an external server and provide a source link to it:

This is a great advantage because the target, as well as the content to be injected into the web page, can easily be updated to apply different rules, depending on which bot is downloading them.

Finally, broadly speaking, there are two types of web-injects for sale:

• Those that have advanced capabilities such as automatic transfer or an account balance grabber;
• And those which are simpler and feature only a phishing-like pop-up that asks the user for personal data as he is logging in. In fact, some web-inject coders sell features depending on the customer's needs, such as targeting a specific financial institution.

Automatic Transfer System (ATS)

Cybercriminals have now taken things a step further with the help of ATSs (Automatic Transfer Systems). This technique is used in conjunction with web-inject files and remains almost invisible. It performs several tasks such as checking account balances and conducting wire transfers using the victims' credentials without alerting them. ATS scripts also modify account balances and hide illegitimate transactions to hide traces of their presence to victims. As long as a system remains infected with an ATS, its user will not be able to see the illegitimate transactions made from his/her accounts.

Two types of ATS exist:

As online fraud grew, banks increased their security measures. One of these techniques is to add multi-factor authentication to important transactions such as login or performing a transfer.

Some are more rudimentary and use a simple printed list of Transaction Authorization Numbers (TANs or iTANs), while others are far more sophisticated and involve the user's mobile (mTANs) or an electronic device used in combination with the user's bank card (chip-TANs).

If multi-factor authentication is implemented, the bank will ask for a specific TAN when the user makes a sensitive transaction on the bank's website. The user then has to provide it either by looking on the list that was given to him (TAN), by checking an SMS that was just sent to his phone (mTAN), or by inserting his bank card into his chip-TAN.

To bypass TANs, the cybercriminal can trick the user into installing a piece of malware on his phone that is able to intercept SMS messages. This is usually done through social engineering. Once the user logs into his bank account, he will be shown a screen to trick the user into entering the TAN. Last but not least, the usage of a mobile component by a banking Trojan is not new. Zeus-in-the-mobile, or ZitMo, and others have been around for quite some time. What is particularly interesting in this case is that several web-inject coders are actually bundling such mobile malware with their web-injects.

Finally, there are several coders in underground forums selling public or private ATS for several banks around the world. In the underground forums, a "public" web-inject is one that is sold to anyone by the vendor, while a "private" one is customized to the buyer's need and is usually not resold by the coder. In general, buyers of private web-injects will get the source code and the rights to redistribute it to others.

PoS (Point of Sales) and RAM Scrappers

Basically, the term "PoS terminal" most commonly refers to the in-store systems where customers pay merchants for goods or services. While a lot of POS transactions are carried out using cash, many of these payments are made by customers swiping their cards through a card reader.

Cybercriminals have an insatiable thirst for credit card data. :) There are multiple ways to steal this information on-line, but Point of Sales (PoS) is the most tempting target. An estimated 60% of purchases at retailers' PoS are paid for using a credit or debit card.

Given that large retailers may process thousands of transactions daily though their POS, it stands to reason that POS terminals have come into the crosshairs of cybercriminals seeking large volumes of credit card data.

Right now, there are a number of internet forums openly selling credit and debit card data in various formats. The most common is "CVV2" where the seller provides the credit card number, along with the additional CVV2 security code which is typically on the back of the card.

This data is enough to facilitate online purchases. However some sellers also offer the more lucrative "Track 2" data. This is shorthand for the data saved on a card's magnetic strip. This data is more lucrative as it allows criminals to clone cards, meaning they can be used in brick-and-mortar stores or even ATMs if the PIN is available. The value of the data is reflected in the online sale price and these prices vary widely. CVV2 data is sold for as little as $0.1 to $5 per card, while Track 2 data may cost up to $100 per card.

So how do criminals get this data? Skimming is one of the more popular methods. This involves installing additional hardware onto the PoS terminal, which is then used to read Track 2 data from cards. However as it requires physical access to the PoS, and expensive additional equipment, it's difficult for criminals to carry this out on a large scale. To address this problem, criminals have turned to software solutions in the form of POS malware. By targeting major retailers with this malware, criminals can accrue data for millions of cards in a single campaign.

For a better understanding of how PoS malware works, let's first take a look at the payment-processing ecosystem:

First, consumers swipe their cards on merchants' PoS devices to purchase goods and services. The PoS devices send the credit card data to merchants' PoS systems.

Secondly, the PoS systems contact the PSP (Payment Service Provider), who contact the designated acquirers for transaction authorization, depending on what card brand or type was used.

Then, acquirers use the card brands' networks to contact credit card issuers. Issuers return an authorization status to acquirers via card brands' networks.

Finally, the acquirers then pass on the authorization to the PSP, who forwards it to the PoS systems and devices, which complete the transaction. This communication occurs in a matter of seconds.

Note also that all organizations that handle payment card data are required to implement safeguards set down in the PCI DSS, which refers to a set of requirements designed to ensure that all companies that process, store, or transmit credit card information maintain a secure environment. Just Google this set of requirements if you'd like to know them.

Cybercriminals have found a big hole within this layered security framework—unencrypted credit card data! In fact, while card data is encrypted as it's sent for payment authorization, it's not encrypted while the payment is actually being processed, i.e. the moment when you swipe the card at the PoS to pay for your goods. Bingo!

PoS RAM scrapers generally retrieve a list of running processes and load-inspects each process's memory for card data. Then they use regular expression (regex) matches to search for and harvest Tracks 1 and 2 credit card data from the process memory space in the RAM. Some PoS RAM scrapers implement Luhn validation to check the card data harvested prior to exfiltration.

Some of the general characteristics of RAM scrappers is that they collect system information, they use hooking and code injection techniques, they are packed, and they encrypt data when sent to the C&C server. Basically, they have almost the same functionalities as a botnet. Look at this scheme that shows the evolution of PoS malware:

In a later chapter, we are going to take the most interesting RAM scrappers and reverse engineer them to see what their code looks like.

Armed with PoS malware, the next challenge for attackers is to get the malware onto the POS terminals.

First and foremost, many POS systems are running older operating systems, such as Windows XP or Windows XP Embedded. These versions are more susceptible to vulnerabilities and are therefore more open to attack.

PoS terminals are not typically connected to the Internet, but will have some connectivity to the corporate network. Attackers will therefore attempt to infiltrate the corporate network first by exploiting weaknesses in external facing systems, such as using an SQL injection on a Web server, or finding a peripheral device that still uses the default manufacturer password. Once in the network, they will use various hacking tools to gain access to the network segment hosting the PoS systems.

The good news is that retailers will learn lessons from these recent attacks and take steps to prevent the re-occurrence of this type of attack. Payment technology will also change. Many US retailers are now expediting the transition to EMV (Europay, MasterCard and Visa), or "chip and pin" payment technologies which is referred to as "chip and PIN" and is a replacement for traditional magnetic stripe-based cards.

EMV cards contain embedded microprocessors that provide strong transaction security features. EMV never transmits the credit card data in the clear, mitigating many common POS attacks.

Chip and PIN cards are much more difficult to clone, making them less attractive to attackers. And of course, new payment models may take over. Smart-phones may become the new credit cards as mobile or NFC payment technology becomes more widely adopted.

Automated Teller Machines (ATMs) Malwares

Cybercriminals have developed and implemented malware designed to withdraw cash directly from ATMs without compromising consumers' debit cards. The ATM malware allows criminals to identify the amount of money in each cash cassette and manipulate the machine to dispense it. Magic : )

But it requires physical access to the ATM, which could be done by an insider / social engineering techniques.

There are two cases that I have been able to grab from the Internet:

The first malware appeared in late 2013 in Mexico under the name of Ploutus, which let attackers force ATMs to spew cash on demand using an external keyboard. Some weeks later, a new variant which showed that the malware had evolved into a modular architecture allowed cybercriminals to simply send an SMS to the compromised ATM, then walk up and collect the dispensed cash. It may seem incredible, but this technique is being used in a number of places across the world at this time.

The second malware, called Tyupkin, has several features that help it avoid detection:

This is considered to be a higher-level attack because it attacks the bank directly, bypassing the need for capturing consumer debit card data using skimming devices. Unlike skimming attacks, which only require access to the public space around a machine, the malware attack requires access to the back end of the ATM. The investigation revealed that only ATMs with no active secure alarm were infected. Therefore, installing alarms and eliminating the use of master keys are two easy mitigating controls that can be implemented.

Conclusion

Our intro to the world of banking malware is finished. I hope you have learned something from this, and it's time for you to move into practice now; happy reversing.