Category: Palo Alto Networks

Executive Summary

Recently, WeipTech was analyzing suspicious Apple iOS tweaks reported by users and found over 225,000 valid Apple accounts with passwords stored on a server.

In cooperation with WeipTech, we have identified 32 samples of a new iOS malware family in the wild. We have analyzed the samples to determine the author’s ultimate goal and have named this malware “KeyRaider”. We believe this to be the largest known Apple account theft caused by malware.

KeyRaider targets jailbroken iOS devices and is distributed through third-party Cydia repositories in China. In total, it appears this threat may have impacted users from 18 countries including China, France, Russia, Japan, United Kingdom, United States, Canada, Germany, Australia, Israel, Italy, Spain, Singapore, and South Korea.

The malware hooks system processes through MobileSubstrate, and steals Apple account usernames, passwords and device GUID by intercepting iTunes traffic on the device.  KeyRaider steals Apple push notification service certificates and private keys, steals and shares App Store purchasing information, and disables local and remote unlocking functionalities on iPhones and iPads.

KeyRaider has successfully stolen over 225,000 valid Apple accounts and thousands of certificates, private keys, and purchasing receipts. The malware uploads stolen data to its command and control (C2) server, which itself contains vulnerabilities that expose user information.

The purpose of this attack was to make it possible for users of two iOS jailbreak tweaks to download applications from the official App Store and make in-app purchases without actually paying. Jailbreak tweaks are software packages that allow users to perform actions that aren’t typically possible on iOS.

These two tweaks will hijack app purchase requests, download stolen accounts or purchase receipts from the C2 server, then emulate the iTunes protocol to log in to Apple’s server and purchase apps or other items requested by users. The tweaks have been downloaded over 20,000 times, which suggests around 20,000 users are abusing the 225,000 stolen credentials.

Some victims have reported that their stolen Apple accounts show abnormal app purchasing history and others state that their phones have been held for ransom.

Palo Alto Networks and WeipTech have provided services to detect the KeyRaider malware and identify stolen credentials. In the remainder of this blog, we provide details about the malware and the attacks.

Finding KeyRaider

The attack was first discovered by i_82, a student from Yangzhou University and member of WeipTech. WeipTech (Weiphone Tech Team) is an amateur technical group consisting of users from Weiphone – one of the largest Apple fans websites in China. Previously, WeipTech cooperated with us to report on other iOS and OS X malware including AppBuyer andWireLurker.

Beginning in July 2015, WeipTech members began investigating reports that some users’ Apple accounts were used to make unauthorized purchases and to install iOS apps. By looking at jailbreak tweaks these users had installed, they found one tweak that collected user information and uploaded it to an unexpected website. They then found this website has a trivial SQL injection vulnerability that allows access to all of the records in the “top100” database (Figure 1).

Figure 1. WeipTech found SQL injection vulnerability in the C2 server (from WeipTech)

In this database, WeipTech found a table named “aid” that contains 225,941 total entries. Approximately 20 thousands entries include usernames, passwords and GUIDs in plaintext, while the rest of the entries are encrypted.

By reverse-engineering the jailbreak tweak, WeipTech found a piece of code that uses AES encryption with fixed key of “mischa07”. The encrypted usernames and passwords can be successfully decrypted using this static key. They then confirmed that the listed usernames were all Apple accounts and validated some of the credentials. The WeipTech researchers dumped around half of all entries in the database before a website administrator discovered them and shut down the service.

On August 25, WeipTech posted about the leak on their Weibo account, submitted avulnerability report to Wooyun (a leading vulnerability crowdsourcing website in China) and forwarded the information to CNCERT/CC.

When Palo Alto Networks researchers analyzed the tweak WeipTech mentioned in their report, we found that it did not contain malicious code to steal passwords and upload them to the C2 server. However, through other information WeipTech provided to us, we determined that there was other malware in the wild that was collecting the stolen credentials and uploading them to the same server.

We named this new iOS malware family “KeyRaider” because it raids victims’ passwords, private keys and certificates. (Just like “Lurker” and “Reaper”, Raider is also a unit in Blizzard’s real-time strategy games.)

KeyRaider Distribution

KeyRaider, as far as we know, only spreads through Weiphone’s Cydia repositories for jailbroken iOS devices. Unlike other Cydia sources such as BigBoss or ModMyi, Weiphone provides private repository functionality for each registered user so that they can directly upload their own apps and tweaks and share them with each other.

One Weiphone user, named “mischa07”, uploaded at least 15 KeyRaider samples to his personal repository so far in 2015 (Figure 2). Since his user name was also hard-coded into the malware as the encryption and decryption key (Figure 3), we strongly suspect mischa07 is KeyRaider’s original author.

Figure 2. mischa07’s personal Cydia repository

Figure 3. “mischa07″ was hardcoded in the malware as encryption key

According to Weiphone’s web page, some of the tweaks mischa07 uploaded have been downloaded tens of thousands of times (Figure 4). These apps and tweaks provide functionalities such as game cheating, system tuning and app advertisement stripping.

Note that there are two especially interesting tweaks in mischa07’s repository:

• iappstore (Figure 5): Provides service to download non-free apps from Apple’s official App Store without purchase.
• iappinbuy: Provides service to get some official App Store apps’ In-App-Purchasing items totally free.

Mischa07 even posted in Weiphone forum to promote these two tweaks but some users didn’t believe their supposedly magic functionalities. However, from Weiphone’s website, the iappinbuy still received 20,199 downloads (Figure 4), while iappstore got 62 (only counting the newest version).

Figure 4. One malicious sample was downloaded over 30,000 times

Figure 5. The iappstore tweak can directly install non-free apps from App Store

Figure 6. Author promotes his iappstore tweak

Another Weiphone user that distributed the KeyRaider malware is “氵刀八木” or “bamu”. Bamu’s personal repository is pretty popular in the community since he frequently provides useful tools. After the attack was exposed, bamu deleted almost all of malware he uploaded from the repository and denied it on the forum. However, with help from Weiphone, we checked all apps or tweaks he has ever uploaded and found at least 18 of them will install the KeyRaider malware on victims’ iOS devices. While mischa07 appears to have created the malware and developed different versions of it, bamu’s malicious apps are mostly created by repackaging existing apps or tweaks such as iFile, iCleanPro and avfun with the malware.

When KeyRaider uploads hijacked user password to its C2 server, it includes a parameter named “flag” or “from” in the HTTP URL to track the source of the infection. In mischa07’s code, the value of these parameters is always the app’s name such as “letv.”  While in bamu’s samples, the value will always be “bamu”. From leaked data, we found that over 67% of stolen accounts came from bamu.

Since bamu is only a distributor, our latter behavior analysis will mainly focus on samples directly distributed by mischa07.

Stolen User Data

KeyRaider collects three kinds of user data and uploads to its C2 server by HTTP; we identified two different C2 servers.

• top100.gotoip4[.]com
• http://www.wushidou[.]cn

During the course of our analysis, these domain names resolved to the IP address 113.10.174.167. In the “top100” database in this server there are three tables: “aid”, “cert” and “other”. KeyRaider use four PHP scripts on the server to access the database: aid.php, cert.php, other.php and data.php.

By analyzing the code and data dumped by WeipTech, we found that the “aid” table stored 225,941 stolen Apple ID’s user name, password and device GUID combinations. The “cert” table stored  5,841 entries of infected devices’ certificate and private key that are used by Apple’s push notification service (Figure 7). Finally, the “other” table stored over 3,000 entries of device’s GUID and app purchasing receipts from App Store server.

Figure 7. One entry in the leaked cert table

We sorted the email addresses from the stolen Apple IDs and found more than half of them used email service provided by Tencent. Below are top 10 most popular stolen account Email address domains. (Six of them are primarily in use by Chinese users):

• @qq.com
• @163.com
• @icloud.com
• @gmail.com
• @126.com
• @hotmail.com
• @sina.com
• @vip.qq.com
• @me.com
• @139.com

However, we also found some email addresses belong to other countries’ or regions’ domain names, including:

• tw: Taiwan
• fr: France
• ru: Russia
• jp: Japan
• uk: United Kingdom
• ca: Canada
• de: Germany
• au: Australia
• us: United States
• cz: Czech Republic
• il: Israel
• it: Italy
• nl: Netherlands
• es: Spain
• vn: Vietnam
• pl: Poland
• sg: Singapore
• kr: South Korea

Malicious Behaviors

The KeyRaider malicious code exists in Mach-O dynamic libraries that are used as plugins for the MobileSubstrate framework. Through MobileSubstrate APIs, the malware can hook arbitrary APIs in system processes or in other iOS apps.

Many previous iOS malware families also abused the MobileSubstrate. For example, the Unflod (aka SSLCreds or Unflod Baby Panda) that was found by Reddit users and was analyzed by SektionEins used it to intercept SSL encrypted traffic and steal Apple account passwords. TheAppBuyer malware discovered last year used the same technique to steal passwords and to purchase apps from App Store. KeyRaider takes this technique another step further. It implemented the following malicious behaviors:

• Stealing Apple account (user name and password) and device GUID
• Stealing certificates and private keys used by Apple Push Notification Service
• Preventing the infected device being unlocked by passcode or by iCloud service

Stealing Apple Account Data

Most KeyRaider samples hook SSLRead and SSLWrite functions in the itunesstored process (Figure 8). itunesstored is the system daemon that is responsible for communicating with the App Store using the iTunes protocol.

Figure 8. KeyRaider hooks SSLRead and SSLWrite in itunesstored

When the App Store client asks the user to input their Apple account for login, the information is sent to the App Store server via an SSL encrypted session. In the replacement function of SSLWrite, KeyRaider looks for this kind of login session, and searches for specific patterns to find the Apple account’s username, password and device’s GUID in the data being transferred (Figure 9). Next, in the replacement function for SSLRead, these credentials are encrypted using the AES algorithm with the static key “mischa07”, and then sent to the KeyRaider C2 server (Figure 10).

Figure 9. Searching for Apple account information in SSL data

Figure 10. Uploading stolen credentials to the C2 server

In addition to hooking SSLRead and SSLWrite, KeyRaider also invokes MGCopyAnswer(“UniqueDeviceID”) to read the device GUID.

Stealing Certificates and Private Keys

In some samples, KeyRaider also hooks the apsd process — the daemon process responsible for Apple Push Notification Service on iOS systems. It hooks the SecItemCopyMatching function defined in the Security framework. This API is used to search keychain items that match given search query.

After installing the hook, when the search query has a label value of “APSClientIdentity”, KeyRaider will execute the original SecItemCopyMatching, then invoke SecIdentityCopyCertificate and SecIdentityCopyPrivateKey to copy the certificate and private key from the original function’s return result (Figure 11). Together with GUID, these credentials are then sent to the C2 server (Figure 12). In the iOS keychain, the key that labeled with APSClientIdentity is used for the push notification. Through these credentials, an attacker can create a fake push notification to the system.

Figure 11. Copy push service’s certificate and private key

Figure 12. Upload certificate and key

Lock Device

When KeyRaider hooks the SecItemCopyMatching, except for intercept notification credentials, it will also compare current query’s label with a very special string “com.apple.lockdown.identity.activation”. If the label is this string, KeyRaider will set this query’s result to zero. (Figure 13)

Figure 13. Set lockdown activation result always to zero

At the time of this publication, there isn’t any public documentation of the com.apple.lockdown.identity.activation query on the Internet. We believe that this query is used to unlock devices. By setting this query’s result to zero, KeyRaider may prevent users from unlocking their own devices either by locally inputting correct unlock passcode or by remotely unlocking the devices via iCloud.

Note that in all samples we’ve found thus far, this piece of code is standalone and not invoked by any other code; it has only been implemented there and exported as a function. However, we have evidence that real attacks using this functionality have occurred.

Free Apps For Everyone!

Some samples of KeyRaider implemented code to download purchase receipts and Apple accounts from the C2 server. However, only in the iappstore and iappinbuy jailbreak tweaks were these actually used.

According to an author’s description, iappstore can be used to download any app from App Store totally free. Let’s take a look at how they make that possible.

The app hooks the SSLWrite API twice. The first hook is used for password stealing just like others. The second hook tries to determine whether current HTTP request is equal to “POST /WebObjects/MZBuy.woa/wa/buyProduct”. This is used to determine if the session is making a purchase using the iTunes protocol (Figure 14).

Figure 14. Hooking app purchase session

If the request is making the purchase, the next time SSLWrite is invoked, the hooking code will try to match keywords such as “salableAdamId”, “appExtVrsId”, “vid”, “price”, “guid”, “installedSoftwareRating” and “pricingParameters” in the data being sent to get payment information about current app.  If the app is not free, a function named fire() is then invoked.

The fire function then invokes the readAid() function. readAid() reads a local file located at /var/mobile/Documents/iappstore_aid.log. This file contains an Apple account’s username, password, device GUID, related iTunes session’s token, cookie, phone number and carrier, operating system information and iTunes CDN server number. The function then parses this data and creates an Account object.

If the file doesn’t exist, it will invoke readAidUrl() function which will download new account information from KeyRaider’s C2 server and create an Account object (Figure 15). Figure 16 shows an account downloaded from the server.

Figure 15. Downloads Apple account from C2 server

Figure 16. Stolen Apple account was downloaded from C2 server

After creating the Account object, fire() will generate a plist format string that contains the account information, and invoke login(), then invoke sendBuy().

The login() function will construct an HTTP connection to the follwing URL with the plist string and a AppStore client like user agent value.

• p*-buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/authenticate

This causes the current iTunes session to be logged in with the remote Apple account. (Figure 17)

Figure 17. Emulating login protocol

After the login request, login() will parse the returned result for the cookie, token and other information and will save this data together with an account password to the local iappstore_aid.log file, to be used for the next purchase. If the login failed due to a password error, it will invoke readAidUrl() again to get a different Apple account from the C2 server.

The sendBuy() function works similarly to the login() function but requests another URL for app purchasing verification:

• p*-buy.itunes.apple.com/WebObjects/MZBuy.woa/wa/buyProduct

Through this procedure, the iappstore tweak can successfully purchase any app using another person’s stolen Apple account.

Note that, besides of these operations, in two standalone functions verifySF() and verifySF2() implementation in this sample, KeyRaider also tries to get or use information about Apple account’s password recovery questions and answers. This functionality hasn’t been finished in the samples we analyzed.

The functionality of iappinpay is similar to iappstore. The only difference is that the purchase interface has changed as well as some of the parameters used (Figure 18). Since the C2 server database also stored some previous In-App-Purchase receipts, it seems that author also planned to implement functionality to reuse these receipts, possibly to send them to Apple to prove that that they have previously purchased an item.

Figure 18. In-App-Purchase verification request

Phones Held for Ransom

In addition to stealing Apple accounts to buy apps, KeyRaider also has built-in functionality to hold iOS devices for ransom.

Some previous iPhone ransomware attacks are based on remotely controlling the iOS device through the iCloud service.  Some of these attacks can be avoided by resetting the account password to regain control of iCloud. KeyRaider is different. It can locally disable any kind of unlocking operations, whether the correct passcode or password has been entered. Also, it can send a notification message demanding a ransom directly using the stolen certificate and private key, without going through Apple’s push server. Because of this functionality, some of previously used “rescue” methods are no longer effective.

We know that KeyRaider has been used to hold a phone for ransom, as one victim reported that his phone was locked while prompted message in screen is “Please contact by QQ or phone to unlock it.” (Figure 19)

Figure 19. Ransom message on locked iPhone

Other Potential Risks

At Palo Alto Networks Ignite 2015 conference back in April we introduced the underground economy and supply chain involved with iOS hacking. KeyRaider plays a very important role in this chain.

With a victim’s Apple account and password, attackers can launch all kinds of additional attacks. For example, they can control the device through iCloud and compromise the victim’s private data contained in their iMessage logs, contacts, photos, emails, documents and location. In 2014, for example, many celebrities’ iCloud accounts were hacked and photos leaked, which raised awareness of the threat from stolen Apple account credentials.

Additionally, there are many other ways to profit from these stolen accounts.

App Promotion

Some developers will pay money for their apps to occupy a better position in App Store rankings, and installation count is one of the most important factors in creating these rankings. Using the stolen data, attackers can easily install “promoted” iOS apps from App Store to increase their installation count. In fact, many of KeyRaider’s victims reported that their Apple accounts had an abnormal app downloading history, which led to the discovery of this attack.

Cash Back

Attackers can purchase non-free iOS apps from App Store using stolen accounts. The fee will be paid by victims, but money will go to Apple and then partly to developers. Then developers share this income with attackers, as was the case with the AppBuyer malware.

Spam

Valid Apple account usernames can also be sold standalone for use by spammers. Previous SMS based spam may cost money to send and is easily to be blocked by carriers. However, iMessage-based spam only needs Internet access and the recipient’s Apple ID. This kind of spam has become very popular in the last two years.

Ransom

Holding the victims’ Apple accounts, their devices or the information contained in their iCloud storage for ransom can also generate revenue for the attacker.

Device Unlocking

These stolen accounts can also be sold in another market. Apple adopted a security mechanism to prevent lost or stolen devices being wiped and re-sold that requires you to verify the Apple ID before wiping. Hence there is now a market for individuals looking for certain devices’ Apple account information.

Other Future Attacks

Combined with personal data in iCloud, stolen accounts can also be used in social engineering, fraud and targeted attacks.

Protection and Prevention

It’s important to remember that KeyRaider only impacts jailbroken iOS devices. Users of non-jailbroken iPhones or iPads will not be affected by this attack.

WeipTech has provided a query service in their website http://www.weiptech.org/ for potential victims to query whether their Apple accounts was stolen. Palo Alto Networks provided the stolen account information to Apple in August 26^.. Worth noting is that WeipTech was only able to recover around half of stolen accounts before the attacker fixed the vulnerability. Users who have ever installed apps or tweaks from untrusted Cydia sources could also be affected.

Palo Alto Networks has released DNS signatures to cover KeyRaider’s C2 traffic to prevent the malware from relaying credentials in protected networks.

Users can use the following method to determine by themselves whether their iOS devices was infected:

1. Install openssh server through Cydia
2. Connect to the device through SSH
3. Go to /Library/MobileSubstrate/DynamicLibraries/, and grep for these strings to all files under this directory:

• wushidou
• gotoip4
• bamu
• getHanzi

If any dylib file contains any one of these strings, we urge users to delete it and delete the plist file with the same filename, then reboot the device.

We also suggest all affected users change their Apple account password after removing the malware, and enable two-factor verifications for Apple IDs.

Our primary suggestion for those who want to prevent KeyRaider and similar malware is to never jailbreak your iPhone or iPad if you can avoid it. At this point in time, there aren’t any Cydia repositories that perform strict security checks on apps or tweaks uploaded to them. Use all Cydia repositories at your own risk.

Acknowledgements

Special thanks to i_82 from Yangzhou University and WeipTech for sharing data, report and all kinds of useful information with us.

Thanks CDSQ from WeipTech and thanks Weiphone for providing potential samples to us. Thanks Xsser and Fenggou from Wooyun in information sharing.

Thanks Sereyvathana Ty, Zhaoyan Xu and Rongbo Shao from Palo Alto Networks for their effort on detecting the threat. Thanks Ryan Olson from Palo Alto Networks for reviewing and revising this report.

Claud Xiao

[Palo Alto Networks Blog]

One of the cool things I like about my job is hearing about what our customers do as a business and how they are using our products to improve their security posture. Unfortunately, due to the nature of corporate network security, these stories rarely get told publically, and even when they are, it’s rare we get to hear from the actual end user. That’s why I am excited about several of the sessions happening next week at VMworld that involve Palo Alto Networks and our partners and customers. I want to draw your attention to two in particular.

In the first session, Novamedia, the Dutch Postcode Lottery, will talk about how they are securing financial transactions measured in the millions of Euros using our VM-Series and VMware NSX. Now the cool thing here is what Novamedia does for a business, which is to generate and distribute funds to charities around the world.

From their CEO, Boudewijn Poelmann, “The opportunities for development are distributed unevenly throughout the world. Many people are threatened by hunger and disease and nature and the environment are hit hard by human activity. Fortunately, there are many non-profit organizations and people throughout the world who work to change this. They are worthy of our support and in need of funding and publicity for their work. It was from this perspective that the Nationale Postcode Loterij was launched in 1989.” (You can read more about Novamedia’s mission here.)

To attend the Novamedia session, look for the session titled How Novamedia protects their software Defined Datacenter with Palo Alto Networks (#SEC5452) on Tuesday from 3:30-4:30.

In the second session, Novamedia will compete with Telstra, Tribune Media and California Department of Water Resources for the title of Best Software Defined Data Center (SDDC) Project. In this case, the cool factor lies not only in the customer use cases but also the fact that the winner will be one of our customers. How can I say that with such confidence? All four of the Best SDDC competitors use our products to protect their network in one way or another. TheBest SDDC Project session happens on Monday from 4:30-5:30 (#SDDC6254-S).

Roughly two years ago when we first released virtualized version of our next-generation firewall, Lee Klarich, our SVP of Product Management, made the statement that our customers were embracing virtualization at a rapid pace and the VM-Series was going to help them solve their cloud security challenges. Next week, at VMworld you can hear how this is happening first hand. And that is wicked cool.

Matt Keil

[Palo Alto Networks Blog]

Unit 42 for the past three months has been tracking a banking Trojan targeting victims in Brazil and the United States. Escelar originally surfaced in January of this year, and has since had roughly 100,000 instances of attempted infections.

Attackers deliver the Trojan using generic Portuguese language phishing emails and are currently targeting seven Brazilian banks. Once delivered, Escelar has multiple installation stages where malware is downloaded using direct connections to multiple Microsoft SQL servers. These SQL servers are also used for command and control (C2) functionality.

The most recently discovered Microsoft SQL server being used as Escalar infrastructure contained records of 1660 infections that all connected in a two-day time frame.

The malware is able to control banking transactions conducted using Internet Explorer, and harvest email credentials, which are in turn used to spread the malware further.

Figure 1. AutoFocus map of victims receiving Escalar Trojan

Infection

Escelar is distributed almost exclusively through phishing emails. A large number of emails were originally seen in the January 2015 period, and more e-mails have continued coming since then at a somewhat slower rate.

Figure 2. Graph of sessions carrying Escalar each week in 2015

These emails are often labeled using the current date, and contain a generic message to entice the victim into running the attachment.

Figure 3. Example email containing Escelar

The following top file names have been observed in attempted infections against Palo Alto Networks customers. Many of them include resume/curriculum vitae themes using female names.

Name	Count
Curriclo_2015.exe	10227
Curriculum_Vitae_Bruna.exe	9110
Curriculum_Fernanda _Paiva.exe	6310
Curriculum_Izadora.exe	4242
Curriclo_Ana_Caroline2015.exe	2435
Seg-via-Boleto.exe	1880
Imprimir_2015.exe	1556
Curriculum_Laura.exe	1547
Curriculu_VItae-2015.exe	1453
Currculo_2015.exe	1428

Escalar Execution – Stage 1

After the victim unzips and executes the attached file, an executable written in .NET will be run. These executables are often obfuscated to thwart reverse engineers and any security controls that may be in place on the victim’s machine.

Important string names within Escelar samples are obfuscated using various cryptographic libraries. We have identified samples using both RijndaelEnhance and TripleDES.

Figure 4. Cryptographic function contained in Escelar

Figure 5. Encrypted string and decrypted version stored as a comment

This executable has limited functionality, and is only responsible for downloading an additional executable and establishing persistence via the Run registry key.

It begins by generating a random path of 8 alphabetic characters in the %APPDATA% directory. An executable name of 15 random alphabetic characters will hold to a soon-to-be-downloaded file. Escelar then makes a direct connection to a remote Microsoft SQL server and downloads a raw binary file to this local location.

Figure 6. Microsoft SQL connection

Figure 7. Acquiring raw binary image from Microsoft SQL server

Figure 8. Raw binary image

After this file successfully downloads, the following registry key is written to ensure persistence across reboots.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run [Computer Name] : [Path to Executable]

Finally, the downloaded malware is executed via a call to Interaction.Shell().

Escelar Execution – Stage 2

The second stage of the Escelar malware family shares many characteristics with the first stage. Both samples make use of direct Microsoft SQL connections, as well as encryption of important strings within the binary. They’re also both written in .NET and are often obfuscated.

This sample is once again another downloader, grabbing a raw binary image from a remote Microsoft SQL server and storing it to the following path:

%TEMP%\\JO[Computer Name][Computer Virtual Memory].exe

Figure 9. Stored image in Microsoft SQL server

Finally, the malware is executed via a call to Interaction.Shell().

Escelar Execution – Stage 3

The third stage of the malware contains the banking Trojan itself. Once again this binary is written in .NET and makes direct connections to Microsoft SQL servers. It begins by droppingJCS.Components.NeroBar.dll in the Startup folder. This DLL is used to generate progress bars and is used when the attacker chooses to generate a ‘blocker’ on the victim’s banking webpage, which we discuss later in this section.

The malware proceeds to identify the following DLLs, which are used by various Brazilian banks to prevent malicious activity. The identifier is stored in the Microsoft SQL database in order to alert the attacker as to what plugins are installed.

File	Identifier
%ProgramFiles%\\GbPlugin\\gbieh.dll	B.B
%ProgramFiles%\\GbPlugin\\gbiehcef.dll	C.E.F
%ProgramFiles%\\GbPlugin\\gbiehuni.dll	I.T.A
%ProgramFiles%\\GbPlugin\\gbiehabn.dll	S.A.N.T.A
%ProgramFiles%\\GbPlugin\\gbiehscd.dll	S.I.C.R.E.D
%ProgramFiles%\\Scpad\\scpLIB.dll	B.R.A.D.A

The IdPC identifier in the following image is made up of the following data.

• Computer Name
• Processor ID
• HD Serial
• Physical Memory
• Virtual Memory

Figure 10. Victim infections of Escelar listed in the Database

The malware monitors the victim’s browser activity. In the event they user attempts to navigate to one of the following Brazilian banking websites, the malware takes action.

• https://internetbanking.caixa.gov.br/SIIBC/index.processa
• http://www.bradesco.com.br/
• http://www.bb.com.br/
• https://www.itau.com.br/
• https://www.santander.com.br
• https://www.sicredi.com.br
• http://www.hsbc.com.br/1/2/br/para-sua-empresa

Should the victim try to open any of these banking websites in a browser other than Internet Explorer, the malware will generate a false error, close the current browser, and re-open the link in Internet Explorer.

Figure 11. False error displayed to the victim when viewing a targeted page in Google Chrome

The attacker has the ability to send a number of different commands in the ‘fun’ column of the Microsoft SQL server.

Figure 12. Commands being sent to victims

Escalar can accept the commands show below (with their translations).

Command	Translation
xclick	click
xclick2	click 2
xtexto	text
xtextopost	text post
xtexto2	text 2
xtextopost2	text post 2
xtexto3	text 3
xtextopost3	text post 3
xmultiplotexto	multiple text
xBloq	locked
xdesbloq	unlocked
xAss1	unknown
xAss2	unknown
xreiniciar	reset
xapagartexto	delete text
xsetacima	up arrow
xsetabaixo	down arrow
xtab	tab
xtab2	tab 2
xcenter	center
xcenter2	center 2
xfecharie	ie close
xsenhacert	cert password
xtoken	token
xcelular	cell

These commands allow the attacker to manipulate a victim’s banking web session and perform fraudulent transactions among other functions.

The following screenshot shows an image that is used by the malware in order to trick victims into entering the unique authentication code sent by banks to the victim’s cellular telephone. This data is uploaded to the attackers in order to conduct fraudulent transactions.

Figure 13. Escelar tricking a victim into entering the authentication code sent to their cell phone

The following screenshot shows examples of an attacker blocking a victim’s banking web session in Internet Explorer.

Figure 14. Blocking of victim’s banking web session

These pages are specific to the bank the victim is using, as we can see in the following second example.

Figure 15. Blocking of victim’s banking web session

E-mail Harvesting and Spreading

Escelar includes a component that is responsible for harvesting credentials from the following web services.

• Gmail
• Hotmail
• Webmail (any website containing the string “webmail” in the URL)

These credentials are stored in a remote Microsoft SQL server. The harvested email credentials are then used by the attackers to send additional e-mails containing Escelar. The total sum of emails in the database displayed below indicated that 3,057 emails had been sent from these addresses. The SQL server keeps track of the number of emails sent by each email address.

Figure 16. Table containing email addresses and tallies of spam emails sent

By harvesting email credentials from Escelar victims, the malware authors are able to further propagate Escelar in the event a portion of the email senders are blocked.

Conclusion

The Escelar threat has been active for approximately seven months, targeting primarily Brazil- and US-based users. We have collected over 600 variants of to date, with roughly 100,000 attempted infections. The malware provides the attacker with multiple capabilities, including the ability to harvest email credentials and manipulate banking transaction sessions. Additionally, due to the way the malware is architected, it can easily update itself, along with the infrastructure supporting it.

Users located in Brazil and the United States that use Brazilian banking services should be aware of this threat and take necessary precautions against it, such as ensuring that suspicious emails are not opened.

Palo Alto Networks customers who are using the WildFire service are protected against this threat. Users who are using Traps with WildFire integration are protected as well. Organizations should monitor their networks for unexpected outbound Microsoft SQL traffic (App-ID mssql) that may indicate an Escalar infection.

For a list of SHA256 hashes of identified instances of Escelar and identified Microsoft SQL server domains being used by Escelar, please refer to this link.

Josh Grunzweig

[Palo Alto Networks Blog]

Unit 42 researchers have observed a new Remote Access Tool (RAT) constructed by an unknown actor of Italian origin. This RAT, referred to as uWarrior because of embedded PDB strings, has been previously described by an independent researcher who noted a potentially unknown exploit being used against Microsoft Office.

Initial research into the exploit by Unit 42 indicates that this actor has opted to include multiple exploits. One is CVE-2012-1856, reinvigorated with a novel ROP chain to bypass ASLR and deliver the uWarrior payload. The other appears to be CVE-2015-1770. The malware itself is a fully featured RAT, which uses a compressed, (optionally) encrypted, raw TCP socket and binary message protocol for command and control communications.

During the course of our research, it became evident that this actor had not built uWarrior from scratch, but rather opted to borrow components from several off-the-shelf tools. Linkages between older RATs are explored later in this blog.

RTF Exploitation and ASLR Bypass

The weaponized RTF document used by this actor contains multiple OLE objects. In this instance, we see two different exploits, as well as two methods of bypassing ASLR exploit mitigations. The first method was published in 2014 by Parvez Anwar. The method he describes involves creating an embedded OLE object which contains a ProgID for “otkloadr.WRAssembly.1”. This causes MSVCR71.DLL to be loaded, a library which is not compiled with /DYNAMICBASE.

When using OLE to perform exploitation, ActiveX objects can be used to cite specific CLSID values. This is useful to an attacker as many of these CLSID values map to DLLs on the system. Attackers can deliberately use this to load any DLL they desire into the affected application so long as it maps to a valid CLSID.

This method was actually described at Black Hat USA 2015 in the talk: “Attacking Interoperability: An OLE Edition” by researchers Haifei Li and Bing Sun of Intel Security.

As a result of this method, it is possible for the attacker to force the loading of less secure libraries which were not compiled with the /DYNAMICBASE compiler flag (enables ASLR at compile time), or other libraries which further enable the corruption and manipulation of memory.

From the RTF document, we can use oletools to extract each OLE object. Thus far, we have encountered two weaponized RTF documents.

Interestingly, both documents contained identical OLE objects:

7ff9ff29b79d0eb38813bfa0b0bb1c5b116d1f9e5468ae52674bb443468658d9	object_00000020.bin
7f29f2dc8b60c0e5a22575d9c76fd9c3d39604d1acf5cb4d938a63095c61a72e	object_000000E6.bin
fe80d59686806afe3dc48f73d54b577558a7c871da17d08d937c5d7b3564e07b	object_000187A1.bin
70ea7ef3bf9966c3297a4e78024e3083013558670d051c2ca3095e2588a576d8	object_0002802C.bin

Closer examination of each of the OLE objects reveals that two of them have compressed zip files embedded in them at an offset of 1577 bytes:

Once carved and unzipped, we can see a small directory structure. Within the word/activex directory, we can see ActiveX binaries, as well as XML documents associated with them. The XML files themselves are mostly identical; duplicates of only two particularly unique ones. The contents of these two files are as follows:

From this we can see that ActiveX objects are calling specific CLSIDs. From this, two relatively known exploits can likely be identified, based on both payloads, and the CLSIDs used.

CLSID	Target Component	Patch	Associated Vulnerability
1EFB6596-857C-11D1-B16A-00C0F0283628	MSCOMCTL TabStrip control	MS12-060	CVE-2012-1856
CDDBCC7C-BE18-4A58-9CBF-D62A012272CE	OSF.DLL (memory corruption in ActiveX use cases)	MS15-059	CVE-2015-1770

As a result of MSVCR71 being loaded via Parvez Anwar’s method, it would appear that exploitation of CVE-2012-1856 could be re-invigorated by the use of ROP gadgets (now with non-randomized gadget addresses) located within its address space, making a VirtualProtect() call and stage 2 shellcode trivial. At this time it is unclear whether the original patch was designed to correct memory mismanagement of the affected TabStrip control, or if the components to load it were simply changed to operate with ASLR enabled to limit the vectors of introducing arbitrary code. At any rate, the ActiveX binary from OLE object 0x000000E6 has the following approximate structure:

Figure 1: We can see the end of the RET heap spray leading into a ROP chain and stage 1 shellcode

Keeping in mind that (of course) the addresses are backwards due to little endian byte ordering, we can observe the following ROP chain after the ret gadget 0x7c342404, and prior to actual shellcode:

In the OLE object 0x0002802C, there are more XML files containing the CVE-2012-1856 CLSID, however 2 files (activeX39.xml and activeX40.xml), contain the CLSID for CVE-2015-1770, which does in fact, cause OSF.DLL to load. Examining the ActiveX binary reveals a not-too-dissimilar structure to the first one:

Figure 2: We can observe the end of the 0xCC heap spray, the 0x08 and 0x41 memory markers as well as stage 1 code here.

Stage 2 shellcode in both cases is decoded and inserted from memory (rather than statically included in a file) and triggers a download of the uWarrior RAT itself. When executing this payload on systems with 64-bit version of Office, things may not quite go as the author intended. For example, on 64-bit systems, msvcr71.dll is part of the SysWOW64 libraries and not available in the Office15 native add-ons folder. Instead, MSVCR100.dll is loaded for those calls and the 64-bit edition of otkloadr.WRAssembly.1 is loaded as well. Furthermore this breaks many of the hard-coded addresses and ROP gadgets, landing at the following error:

The address 0x7c38bd50 is a reference back into the aforementioned, msvcr71 library which is not in memory.

It is important to note that analysis of the exploitation itself is on-going and many researchers around the industry have suggested differing vulnerabilities as a root cause; however, conclusive evidence is lacking and the combination of methods and affected code is both new and complex.

uWarrior Malware Analysis

After successful exploitation, a payload is saved to the system at “%AppData%\Roaming\TEST\WindowsUpdate.exe” and executed. The WindowsUpdate.exe application contains several artifacts that suggest that the malware author calls this Trojan uWarrior, one of which is the following debugging symbol path found in the sample:

D:\1-Visual Basic Proggetti\UtilityWarrior\UtilityWarrior\obj\Debug\UtilityWarrior.pdb

uWarrior begins by copying itself to a second location, which in this case was “%AppData%\Local\svchost.exe” and saves the path to this copied executable within the following file:

%AppData%\Roaming\warriors.dat

During execution, uWarrior logs its activities to a file located at “%AppData%\Local\Temp\bootloader.dec”, however, our team is aware of other uWarrior samples saving their logs to “C:\bootloader.dec” instead. We found that uWarrior has a configuration that follows the structure:

The settings structure found in this sample of uWarrior has the domain “login.collegefan.org” set as the C2 host, and 2020 for the communications port. When communicating with the C2 server, the uWarrior Trojan uses AES to encrypt the data sent to the C2, using the key and initialization vector (IV) seen in Figure 3.

uWarrior will receive commands from the C2 using this communication channel and will process the commands using a command handler.

Figure 3 AES Encryption Key and IV used by uWarrior

The C2 will send numerical values that the uWarrior Trojan will parse to determine which command to carry out. Fortunately, the author of uWarrior included an enumeration (a data type in programming that maps a constant value to a defined name), which applies a human-readable string to each command’s numerical value. This enumeration makes analyzing the commands available within the malware much easier. The functionality within many of the commands are handled by a helper DLL that the uWarrior will extract from its resource section named Windows_Update.UtilityWarrior.dll and load.

Unit 42 analyzed the command handler to determine uWarrior’s capabilities and found the following commands available:

EnumValue	Command	Description
10	Handshake	Instructs the Trojan to use a new key and initialization vector (IV) to encrypt network communications. The Trojan will then creates a thread that it will use in an attempt to establish communications using the new key.
14	ShutdownClient	Exits the current instance of the Trojan.
15	RestartClient	Restarts the Trojan and exits the current instance of the Trojan.
16	UninstallClient	Creates a batch script with a temporary filename that deletes the Trojan and then the batch script. The script contains the following::Repeat:DEL \”<executable path>\”if exists \”<executable path>\” goto RepeatDEL \”<batch script path>\””One interesting thing to note is that there is a flag called “BlueScreenOnTermination”, which if set in the configuration will set the Trojan’s process to be system critical by calling the SetProcessIsCritical function. After the batch script deletes the files, the Trojan exits itself and causes a Windows error due to the fact the process was system critical.
17	RestartPC	Restarts the system using the command line “shutdown.exe -r -f”.
18	ClosePC	Shuts down the system using the command line “shutdown.exe -p -f”.
19	GetSoftware	Handled by the helper DLL, which opens a specified registry key in the HKLM hive and enumerates its sub keys looking for “DisplayName” and gathers all software packages that do not have “Hotfix”, “Security Update” or “Update for” within their “DisplayName”. It responds to the C2 with a list of software packages delimited by the string “|A|”.
21	unistallSoftware	Handled by the helper DLL, which enumerates the “Software\Microsoft\Windows\CurrentVersion\Uninstall” registry key looking for the software package provided with the command and will uninstall it. It responds to the C2 with “Unistall is running” if successful or the exception if it fails.
22	GetDriver	Handled by the helper DLL, which enumerates the mounted storage devices, their total size and the available space left on them. The command concatenates this information into the following structure and sends it to the C2: “<drive number>|H|<drive’s total size>/<drive’s available space>|Q|”. For systems with multiple mounted storage volumes, the command will concatenate the additional data following the same structure above.
23	GetFiles	Handled by the helper DLL, which lists the contents of a directory of a provided path. Each folder in the directory are added to a string, which is sent to the C2 in the a format of “<folder name>|G|Floader|G||G|<provided path>|H|”. Each file in the directory are added to a string that is sent to the C2 in the format of “<filename>|G|<file extension>|G|<file size>|G|<provided path>|H|”.
24	SearchFolder	Searches the filesystem for a specified folder. If it finds the folder, the Trojan will enumerate its contents using the same code as the “GetFiles” command.
25	RunFile	Starts a process using a specified file. Does not respond to the C2 with any messages.
26	DeleteFile	Deletes a specified file. If the command has “E” switch provided, it will delete a specified directory and all of its contents.
27	RenameFile	Renames a specified file. If the command has “A” switch provided, it will rename a specified directory.
28	DownloadTCP	Reads a specified file and sends it to the C2 server.
29	UploadTCP	Writes data provided by the C2 to a specified file.
30	DownloadURL	Downloads a file from a specified URL. The C2 will provide the URL to download from in the format “<domain or IP>|A|<filename>|A|<file extension>|A|<path/URL>”.
31	RefreshLog	Sends the contents of the log file at “C:\bootloader.dec” to the C2 server.
32	ClearLog	Deletes the log file at “C:\bootloader.dec” from the system.
36	MonitorCounts	Uses the GetSystemMetrics API function to determine how many monitors are connected to the system.
37	PcBounds	Sends the height and width of a specified monitor to the C2.
38	ShortLinkFolder	Lists the contents of a special folder based on a value between 1 and 4: 1) Lists Desktop 2) Lists %TEMP% folder 3) Lists Cookies Folder 4) Lists My Documents folder

Some of the values within the previously mentioned enumeration are not within the command handler. Unit 42 found only two of these specific values and found in the malware, specifically “Pipe” and “Status”, which were used in network communications to designate the type of response the Trojan was sending to the C2. It does not appear that uWarrior uses the “Plugin”, “ErSoftware”, “RemoteDesktop”, “UnblockEverything”, “BlockEverything” values from within the enumeration, suggesting that the malware author did not remove these values from the enumeration even though their functionality was removed from the Trojan.

No Honor Amongst Thieves

Unit 42 researchers’ examination of uWarrior has led to the discovery of suspected progenitor samples. These samples, identified as the for-sale ctOS RAT, contain similar configuration structures and share several functions with uWarrior samples. The ctOS RAT contains a significant amount of functionality compared to the uWarrior command set, suggesting that uWarrior could be a stripped down alternative.

uWarrior’s configuration contains all of the same fields as ctOS, as well as an additional field (bool_2 in GStruct2 stucture in Figure 4), used to toggle whether “warrior.dat” should be utilized to store the path on the file system to the executable. Samples of both RATs contain a GUID field (string_2 fields in Figure 4), “TEST”, which is used to define the path where the executable will be dropped.

Figure 4 Comparison of uWarrior (GStruct2) and ctOS (Struct4) Configurations

In addition to sharing similar configurations, it appears that the uWarrior author borrowed code from the ctOS RAT. uWarrior’s helper DLL (used to handle several of uWarriors functionality) has two functions that directly overlap with functions from ctOS source code, specifically one that gets the size of a specified file and the second that enumerates the mounted storage volumes.

Static analysis of ctOS and uWarrior samples reveals Italian language strings. These Italian strings are part of PDB paths and are prevalent throughout .net manifest data. This lends additional strength to the linkage between ctOS and uWarrior, as the former’s control panel demos are also in Italian.

Palo Alto Networks WildFire identifies the exploit files and malware used in these attacks as malicious. Palo Alto Networks AutoFocus users can view the analysis related to these files using the uWarrior tag.

Indicators

Sample Hashes

WindowsUpdate.exe,5dce01ec5e1bc1b4f5012e0b4bf16532206284fc8c64cfb8dcf907f45caf98fc

Windows_Update.UtilityWarrior.dll,f4aa83297844eb8297711e32554e41f677cce290732171583199a57fb7a0674b

ammendment.doc, a6dea088c9e2c9191e4c2fc4ece7b7b7bd3f034f444362d35c8765f6ec4bd279

WUPOS_update.doc, 57a5d0da72655df9c5ca9137df7210b86845eeabae488537c70e36587274937c

File system indicators

%AppData%\Local\Temp\bootloader.dec

%AppData%\Roaming\warriors.dat

Network indicators

login.collegefan.org

login.loginto.me

63.142.245.12

23.249.225.140

Brandon Levene, Robert Falcone, Tomer Bar and Tom Keigher

[Palo Alto Networks Blog]

This week’s Sales Kick Off was historic for Palo Alto Networks in many ways, not only as a celebration of our fiscal 2015 but also because we invited our top partners from around the world to join the extended Palo Alto Networks field team and discuss the opportunities ahead, side by side. CRN Associate Editor Sarah Kuranda was also with us in Las Vegas, and met with many of our partners and executives, including President and CEO Mark McLaughlin.

As Mark told CRN, “We’re investing very heavily in the partner community. We have thought for a long time that our partners and us were a team, and we really want to continue to act that way and take it to the next level. We are extraordinarily transparent; we’re giving them the same training, they’re in all the meetings we’re having with our new salespeople and our new SEs. … We are 100 percent partner-focused.”

Read more about what is driving growth in the security market, our focus on partners and the key differentiators of our security platform in CRN’s Q&A with Mark. Also be sure to check out what some of our partners have to say about their own growth and partnership with us here.

Cristina Salmastlian

[Palo Alto Networks Blog]