Thursday, April 17, 2014

Heartbleed Check Added to ZULU

Many of you already regularly use ZULU, our free service for analyzing any URL to determine it's overall risk and we've just made it better by adding a 'heartbleed' check.  ZULU operates by applying a variety of checks to the content, URL and host for a given web page, along with doing the same for external page elements. You will now note that the Content Checks section includes a Heartbleed OpenSSL Check.
Vulnerable Result Shown for Heartbleed OpenSSL Check
For more information on why heartbleed is such a serious vulnerability, take a look at our earlier blog which details how exploitation occurs. In a nutshell, the heartbeat TLS extension allows one machine to send a small packet to another to keep a TLS connection open. That request includes a small message, which the responding machine subsequently includes in the reply. The problem occurs as the request also includes a parameter indicating the size of the message, which is not properly validated in some versions of OpenSSL. Therefore, if the size value is larger than the actual size of the message, the response will also include random data from memory to fill the void. This is a serious data leakage issue as the response could include sensitive information such as passwords, cookies and even private encryption keys. The impact of this vulnerability is also exacerbated by the fact that OpenSSL is such a popular SSL implementation, leaving many popular websites vulnerable.

Now when you run a ZULU scan, as part of the overall content checks, we also send a heartbeat request to port 443 on the server. We check to see if an SSL server is present and if it will respond to a request where the specified message size does not match the actual length of the message. If that's the case, the report will state 'Heartbleed OpenSSL Result: Vulnerable' in the report and the overall score will be adjusted accordingly.

- michael

Tuesday, April 8, 2014

Why you should care about the OpenSSL heartbleed vulnerability

Yesterday, researchers from Google and Codenomicon made quite a splash when they revealed details of a vulnerability in OpenSSL's implementation of the heartbeat extension, which they have affectionately dubbed heartbleed.  In short, heartbleed represents a classic example of a simple programming oversight - not properly validating the length of a message, which leads to a serious memory leak.

Why is this such a big deal?

Breadth and depth - Heartbleed impacts the most common implementation of SSL/TLS (OpenSSL), which is used on the majority of web servers. In fact, according to Netcraft, in April 2014, Apache and nginx, two of the most popular web servers that both include vulnerable Open SSL implementations, account for 66% of active web servers. As for depth, the impact of the vulnerability is significant and trivial to exploit. A simple request will return up to 64 KB of random data from server memory. This data could include extremely sensitive information such as private encryption keys and authentication credentials. To make matters worse, there are no logs of such requests, so a victim won't even know that they were attacked and the exploit can be sent over and over, retrieving new data every time.

How does it work?

The heartbeat extension is defined in RFC 6520 and was added to the TLS protocol to provide a simple means of keeping a TLS session alive. Think of it as a small packet that the client sends to the server to let it know that it's still around. The problem occurs, because that simple packet includes the length of the payload that it's sending, which isn't properly validated. If the actual payload is smaller that the payload length value, the server will return random data from memory to fill the void. There is already plenty of PoC exploit code for this vulnerability readily available on the web if you want to test your own servers.  Let's break down a sample heartbeat request to illustrate the vulnerability (some hexadecimal values have been converted to decimal in the description).

|18 03 02 00 0A 01 40 00 4D 49 43 48 41 45 4C|
|#1| #2  | #3  |#4| #5  |         #6         |

#1 - Type = 24
#2 - Version = 0x302
#3 - Data length = 10 (#4 + # 5 + #6)
#5 - Total payload length (16,384 bytes)
#6 - Data ('MICHAEL')

The problem?

In this example, the data length is 10 bytes, while the total length of the payload is set to 16,384 bytes. Due to improper bounds checking, the server ultimately returns both the data sent in the heartbeat request, along with whatever else happens to come after it in memory. In the screenshot below, you can clearly see the heartbeat payload ('MICHAEL') sent to a vulnerable server, is followed by random browser headers - likely from a recently requested webpage on that server.

Data leakage from a web server vulnerable to the OpenSSL 'heartbleed' attack 

The verdict

This is a serious threat. Use freely available tools such as this handy web app to quickly check your servers to determine if you're vulnerable. If you are, either upgrade OpenSSL to 1.0.1g or recompile your existing OpenSSL version with -DOPENSSL_NO_HEARTBEATS compile time option.

- michael

Friday, April 4, 2014

Corporate users dive into March Madness

Here in the ThreatlabZ, we track stats and trends for all Zscaler customers. While our primary focus is on malicious traffic, it's intriguing to also track surges of traffic caused by non-security events.  We weren't surprised to see the NCAA basketball March Madness games cause peak traffic in both the Streaming Media and Sports categories.  There are clearly no shortage of users that participate in bracket-ology.

The graphic below shows the spike in Sports and Streaming data, which shows an interesting bandwidth trend when viewed as a percentage of total traffic seen on that particular day.  To benchmark normal traffic, I also calculated Pre-Madness traffic shown as March 17th. The first two full days of the tournament occurred on Thursday March 20th and Friday March 21st. I omitted the weekend games as Zscaler receives corporate traffic so a drop in overall traffic on the weekend is already predictable.

The typical amount of Sports Streaming data doubles during the first Round.

On Thursday and Friday (March 20th and 21st), the initial two full days of the tournament, Sports and Streaming traffic nearly doubled, primarily due to March Madness. The third round (March 27th and 28th) wasn't quite as popular. Perhaps our customers has already had their brackets busted at that point! The surge in traffic during the opening round is an impressive stat when you consider that Zscaler receives traffic from enterprises all over the world and March Madness is a US based event. A single sporting event, in one country can actually be popular enough that it can cause a significant spike in traffic for a given category on a global scale

User's have more than one way to watch these games.  The use of mobile devices like the iPad, iPhone and Android devices are responsible for a significant portion of this traffic spike as well.  Below is the Sports and Streaming traffic seen from mobile devices during this time-frame.

User's preferred to watch the games on their iPad devices.

While companies may not want to block access to such content, they may also not be aware of the percentage of bandwidth that can be consumed during a major sporting event. It's always worthwhile to keep track of such spikes and ensure that QoS controls are in place to ensure that such traffic is at least throttled to ensure that it doesn't negatively impact business critical activities.

Tuesday, March 25, 2014

Walkthrough of a Recent Zbot Infection and associated CnC Server

During routine ThreatLabZ log analysis, we encountered the following malicious Zbot executable connecting back to it's CnC and exfiltrating data via POST requests.
  • MD5: 0b43d6a65f67ef48f4da3a1cc09335a1
  • Size: 442368 bytes
  • Detected as PWS:Win32/Zbot by Microsoft (VT 43/49)


What separated this discovery from your average CnC server? The attackers were kind enough to leave the CnC server largely exposed (directory browsing enabled, many files not password protected) to provide a rare behind the scenes look at a live botnet operation. Let's walk through what we observed.  

The above mentioned Zbot variant was responsible for dropping the following malicious files:
  • 6ca1690720b3726bc76ef0e7310c9ee7 - Win32/Stoberox.B (VT 26 / 50)
  • d2c6a0e888d66882d7dc29667c4c9ec0 - TrojanDownloader:Win32/Cutwail (VT 38/50)
We also noted that it started a server listening on ports 1548 and 3492 and sends some data via POST requests to hxxp://
(see malwr sandbox report).

Domains contacted:
  • [ IP:]
  • [IP:]
  • [IP:]
IPs contacted:

Malicious IP Virus total links

While looking at the POST data submitted to hxxp://, we explored this site and found that it is currently hosting two malicious files and a password protected admin console.

Below are the files which are hosted on hxxp://, which can be observed thanks to the fact that the attackers left directory browsing enabled:

[   ] 03-Mar-2014 09:49 12M  
[DIR] admin/ 21-Aug-2013 23:44  
[   ]  all.exe 21-Mar-2014 17:36 457K
[   ]  rok.exe 21-Mar-2014 06:23 75K

all.exe attempted to communicate to the followings DGA generated Domains:

Admin Console

Although we weren't able to access the live admin console as it was password protected, we were able to replicate the setup from the exposed source files (hxxp:// it would appear as shown below:

Another directory with browsing enabled exists at hxxp:// Here the data from infected machines connecting back to the CnC server can be observed:

Before being transmitted from a victim machine, the data is encrypted using RC4 encryption, base64 encoded and then sent via the POST method to the CnC.

Here is the code for first decoding the data using base64 decoding and then RC4 decryption:

After decoding and decrypting, a record is created in the aforementioned directory hxxp://

The following a sample of the information stored from an infected victim:

What does this data represent?

This particular record includes the following:
  • Bits: 0 means OS is 32 BIT 
  • Country: SOUTH KOREA
We are continuing to track these malicious Domains and IP addresses and advise you to block them too.

- rubin

Friday, March 21, 2014

Scams Taking Advantage of Malaysia Airlines 370 Disappearance

I spent some time today looking for sites that are taking advantage of the disappearance of Malaysia Airlines flight 370 (MH370) to profit from the tragedy. Unsurprisingly, it was all too easy to find examples of this as it is almost a given that scammers will attempt to profit from any breaking news story, especially those where the public is desperate for the latest tidbit of news - regardless of where it may be coming from.

Advertising Scam

The first example is an advertising scam. The scam begins with the infection of a legitimate site, in this case debiworley[dot]com, a personal website for a photographer. A subdomain has been added to the site, which hosts different scams, all leveraging the same approach. In the case of the MH370 scam, an alleged video has been posted to alert[dot]debiworley[dot]com/news/?mh370. At that page you'll see the image shown below, which purports to show a Malaysian Airlines plane crashed in the jungle:

The page includes the fake video and also includes comments formatted to appear as though they're from Facebook. Despite the look of the page, everything is simply an image. Clicking anywhere on the video doesn't actually play the video, but instead prompts the user to share the video on Facebook by presenting the following popup, before it can be played.

If the user chooses to share the video, it does not ever play, but instead simply shares the scam with their Facebook friends. What the victim is promoting is a quickly hacked together site hosted at vinreox[dot]com, a simple website that acts as a front end for various YouTube videos and the owner profits from advertisements on the site.

Note: The owner of the infected website has been informed of the infection.

Pay-Per-Click Scam

This time around, the scam appears to be hosted at a site controlled by the attacker. There are various URLs on the domain that ultimately link to the same content, but one in particular (rentadp[dot]com/malaysia/) appears to be piggybacking on the MH370 disappearance. When visiting that URL, the victim is redirected to a completely fake Facebook page.

Once again, most of the page is nothing more than an image and the only links either refresh the page or prompt the user to share the scam on their real Facebook profile before they can view the video. It would appear that the scammers were a bit lazy this time as despite the URL referencing 'Malaysia', they've clearly used a picture of US Airways Flight 1549, which crash landed on the Hudson river in 2009.

Should users choose to share the scam, they won't ever see the video, but instead will be redirected to a pay-per-click scam which requires yet another task, this time around the victim must fill out one of three surveys before they can proceed. This is where the the scammers make money. They're paid a few cents for every survey completed.

Unfortunate that anyone would seek to profit from a tragedy, but unfortunately, this has now become the norm.

- Michael

Wednesday, March 12, 2014

LightsOut EK Targets Energy Sector

Late last year, the story broke that threat actors were targeting the energy sector with Remote Access Tools and Intelligence gathering malware.  It would seem that the attackers responsible for this threat are back for more.  This particular APT struck late February between 2/24-2/26.  The attack began as a compromise of a third party law firm which includes an energy law practice known as Thirty Nine Essex Street LLP (www[.]39essex[.]com).  The victim site is no longer compromised, but viewers should show restraint and better browsing practices when visiting. shown as a referral URL to suspicious site.

The compromise leads the victim to another site which provides the attacker with a specific user-agent in the URL field.  The purpose of this is to pass along diagnostics to the attacker so that the proper malicious package is sent to the victim.  This should be taken as a point of identification in administrator logs as this may indicate an attack on your network.

At the time of research, the Java Class file was returning 404.

There are several other locations which show similar activity that are also related to this threat.  Malicious redirects come from IP address 174[.]129[.]210[.]212 should also be taken as suspicious as well as some sites hosted on this domain (aptguide[.]3dtour[.]com).

The URLquery and VirusTotal entries for this IP corroborates the notion that this location played a part in using LightsOut Exploit Kit.  

LightsOut performs several diagnostic checks on the victim's machine to make sure that it can be exploited.  This includes checking the browser and plugin versions.

The deobfuscated Javascript sheds some light on the iframe injection.

More JS Deobfuscation

Checking to see what version of Adobe is installed.

Checking to see if you are IE7.

Checking to see if Java is enabled in the browser.

Ultimately, a payload is delivered from the LightsOut Exploit kit, which attempts to drop a malicious JAR file exploiting CVE-2013-2465. At the time of research, the binary file was no longer available, which suggests that the attack window has now closed for this particular watering hole.  However, other security sources tell us that the site used in the attack is also a known HAVEX RAT CnC.

The recent activity of this threat originating from a site in the energy sector should serve as a warning to those in the targeted industry.  Prior research from other sources tells us that the threat actors involved are highly motivated and agile.  Their motive is to gather intelligence for further attacks, so be on your guard and monitor transaction logs for suspicious activity!

Friday, February 21, 2014

Probing into the Flash Zero Day Exploit (CVE-2014-0502)

Yesterday, a targeted campaign leveraging a Flash zero day exploit hit the news. Adobe has now released a security bulletin regarding this vulnerability. Based on the attack vector mentioned in prior research, we have concluded that recently observed .SWF exploitation is related to the recent zero-day threat flagged as CVE-2014-0502. Upon successful infection, the exploited victim is served a RAT (Remote Access Trojan). 

While we were doing our daily review of logs, we found a significant number of transactions related to this campaign. We specifically started looking for those compromised servers which have been mentioned in prior research.  We began investigating all suspicious transactions which used a known compromised site as a referral location. 

After some brief inspection of this location, we found not only the malicious .SWF, but also all other connected malicious files detailed in the analysis below. We will cover the dropped Flash file that exploits the vulnerability using an image that contained embedded shell code. This shellcode is then used to download the malware.

The Flash file was found to be encrypted using the DoSWF flash encryptor.

Upon throwing the Flash file into an ActionScript viewer, we immediately see the script shown below. The script tries to make a URL Request to a GIF Image file, which contains the embedded shellcode for an ROP exploit.

The script checks for the presence of a cookie labeled 'XPT2013111'. If this cookie is not already present, it sets the same.

The script then checks the operating system version and in the case of Windows XP, further checks the OS language. Details of the OS language and version are then used to determine the base address for the exploit. In case of Windows 7, the script further probes for unpatched and outdated versions of Java (Web Start 1.6 and 1.7) or Microsoft Office (Sharepoint OpenDocuments 3 or 4).

Here we can see on XP, based on the version and language, the base address for the exploit is determined by the script. Then the ROP sled is built to carry out the exploit.

The GIF image used for embedding the shellcode is shown below, which of course seems innocuous to the victim.


When opened in a hex editor, the magic bytes for a GIF image file can be seen.

However, upon careful examination, we further see extra bytes appearing toward the end of the image as shown below.

Using a shellcode emulator like libemu, we can see that this extra data represents the shellcode to be executed.

Here we see that the shellcode makes a call to the LoadLibraryA function and then to VirtualProtect to allocate memory in which to place the shellcode. It then checks for the /temp folder path and makes calls to InternetOpenUrlA to download the malware from a remote location http://[x.x.x.x]/common/update.exe and drops it into the /temp folder.

A sandbox analysis of the final dropped file can be seen here.

Browser plugins continue to be the Achilles heel of enterprise security. While enterprises struggle to ensure that browser plugins are up to date on all end user systems to prevent browser exploit kits from targeting known vulnerabilities, here we see yet another demonstration where even that is not enough. Attackers continue to identify and exploit 0day vulnerabilities in popular web browser plugins such as Adobe Flash, which unfortunately has a long history of dealing with such threats.