About Parts One and Two This post is a conclusion to a three-part blog analyzing "Marcher" malware that targets the Android platform. Read part one
here and part two
here. To round out the discussion, let’s cover the network and host indicators associated with this trojan.
About Part One
Last week I posted a blog analyzing "Marcher" - malware targeting the Android platform. Designed to steal mobile banking app credentials from banking customers, it is one of the most prevalent Android password stealers seen in the wild. Read part one here.
Part 1 of 3
"Marcher" is malware targeting the Android platform. It is designed to steal mobile banking app credentials from customers of many different financial institutions. Distributed through a variety of means, it is one of the most prevalent Android password stealers seen in the wild, second only to Svpeng.
BEC is an acronym for "business email compromise." BEC refers to social engineering attacks used to convince those in charge of finances at an organization to send large payments to the scammers. These attacks are carried out over email conversations initiated by the scammer who spoofs the identity of an executive at the organization.
As we discussed in a previous blog post, cybercriminals have recently spent more time zeroing in on a specific target and deploying spear phishing attacks which have resulted in a surge of high-profile security breaches and/or major fraud schemes leaving organizations with millions in financial losses. For attacks that aren’t financially-motivated, such as those often carried out by nation-state actors or hacktivists, target selection is based on operational and strategic objectives. Targeting in financially-motivated attacks is much more dynamic with multiple variables that can factor into the decision. In this post we’ll explore some of those factors and how the attacks are delivered.
Business email compromise (BEC), spear phishing, and social engineering aren’t just buzz words that have gained popularity in the security industry. These tactics have recently been employed by cybercriminals to get around the plethora of security controls deployed to protect organizations. Account takeover has evolved from using malware to compromise credentials and remotely using the victim’s computer, to using social engineering schemes over email to fool legitimate users into performing wire transfers, such as the recent BEC attack on Ubiquiti that nearly cost the organization $46.7 million.
In a recent blog post, we wrote about Vawtrak expanding targets and gaining momentum. Fast forward a few months and the threat is anything but diminishing. Sophos just released a technical report on Vawtrak which discusses the significance of the threat and its Crimeware-as-a-Service model. In December 2014, Vawtrak version 0x38 was released including significant code and configuration changes that indicate momentum and an intense focus on development of the crimeware kit. To better understand the complexity of the threat, this post is a historical review bringing you all the way up to the most recent enhancements observed in December.
It should come as no surprise that cybercriminals have yet again displayed superior moral character with a scheme exploiting websites of non-profit organizations to verify stolen card data. PhishLabs’ R.A.I.D (Research, Analysis, and Intelligence Division) has uncovered an underground service that allows cybercriminals to use an interactive chat bot to automate the verification of stolen payment card data. The bot is a script programmed to login to an online chat channel and monitor it for messages containing data such as credit card numbers, cardholder names, and expiration dates using a special input syntax. Miscreants are purposefully targeting websites of non-profits with this service to verify stolen credit card data.
Bot design and implementation
When cybercriminals join the online channel and "chats," the bot uses the data provided (cardholder name and information) to input and run transactions against the websites of charities and other non-profits in order to verify that the card data is correct and the account is active. The bot then reports the results and any transaction details back the crook.
The bot interacts as a user on an IRC (Internet Relay Chat) channel. Functions like card verification are handled through private messages between a moderator, the criminal service's customer, and the bot's own "user" ID on the same chat channel. These messages contain bot commands formatted using a specific syntax recognized by the bot. Using the private message feature allows the service's users to chat openly with each other but keep messages that contain things like valuable card data out of the hands of the other criminals on the channel.
The bot itself is a program implemented in the perl programming language. Although based on a design for IRC interactions that dates back many years, this bot uses specific modules and code customized for cybercrime purposes first seen in 2011. This particular strain of criminal tailored code is known for its use of Portuguese for comments and variable names.
The source code to those bots is available, but compared to those older bots that were coded for a single main purpose, the bot used in this case is larger and more complex, handling many different functions that cybercriminals may find useful. Indeed, in addition to automated card verification, this bot also includes modules for tasks such as:
- Checking tracking numbers on packages, for example, used by the channel members to track items purchased using stolen cards through a "reshipper" network
- Address and ZIP code verification for cardholder identity data
However, card verification seems to be the primary use, and that's the main draw for the service's customers. See Figure 1 for a snippet of code showing the card verification data.
Figure 1 - Bot source code snippet showing card data approval messages
The Dyre banking Trojan made its first debut in June 2014, targeting large financial institutions across the globe. In September, PhishLabs’ R.A.I.D (Research, Analysis, and Intelligence Division) observed a number of enhancements to the banking Trojan that further increases the danger of the threat.
Banking Trojans Expand Beyond Financial Targets
The most recent attack utilizing the Dyre Trojan targeted the cloud computing company, Salesforce.com. Historically, banking Trojans were used to steal account credentials of banking customers but now sensitive business data is being stolen from companies in the healthcare industry, retail, software industry and others. Malicious software developers are seeking access to organizational systems and operating systems to steal data that would aid in identity theft for purposes of committing fraud. Attackers remain patient and persistent; evolving the tools, harvesting the data and attacking when it is unexpected.
With the recent discovery of the Shellshock bug, many banking institutions are left wondering what the implications are to the financial industry and how to begin to secure systems. In this post, we've addressed common questions and mitigation tactics for banking entities to reduce the risk of exploitation through the Shellshock bug vulnerability.