Websense® ThreatSeeker® Intelligence Cloud has detected that the U.S. version of the Metro International website (metro.us) has been compromised and is serving malicious code. Metro newspaper editions are distributed in high-traffic commuter zones or in public transport networks. In the U.S., Metro is published in New York, Boston, and Philadelphia, and is "written and designed for young and ambitious professionals." The U.S. website has over 1 million visitors a month. When a visitor goes to the main page, metro.us redirects to metro.us/newyork/. That page is injected with a malicious iFrame that redirects users to websites serving exploit code, which subsequently drops malicious files on the victim's computer. Websense Security Labs™ has contacted the IT team of metro.us with a notification regarding the compromise, and they are investigating the issue. Please note that in the UK there is an unrelated Metro publication ( Associated Newspapers), which is not linked to the campaign in question. metro.us main page as of 22 July 2014: SimilarWeb.com statistics for metro.us Websense customers are protected from this threat by ACE, our Advanced Classification Engine , at the following stages: Stage 2 (Lure) - ACE has detection for the compromised websites. Stage 3 (Redirect) - ACE has detection for the injected code that redirects the user to the exploit page. Stage 4 (Exploit Kit) - ACE has detection for the malicious code that attempts to execute this cyber attack. Stage 5 (Dropper Files) - ACE has detection for the binary files associated with this attack. Stage 6 (Call Home) - Communication to the associated C&C server is prevented. Analysis The injected code has been found in multiple locations within the main website. When a user browses to the main website, the injected code loads automatically, and silently redirects the user through a TDS (Traffic Distribution System or Traffic Direction System) to a website hosting the RIG Exploit Kit. The exploit kit tries to load exploit codes to exploit various vulnerabilities, in order to drop a malicious executable on the victim's computer. Here is a sample of the injected iFrame (which was found on multiple pages on metro.us): The redirection target from the iFrame (hxxp://fsbook.us/?mt) is part of the TDS. It sets a cookie (to thwart repeated analysis attempts), then redirects to hxxp://fsbook.us/link.php: hxxp://fsbook.us/link.php in turn redirects to the RIG Exploit Kit landing page: RIG Exploit Kit RIG "came on the scene" around April 2014, and was heavily used to distribute ransomware such as Cryptowall. According to Websense ThreatSeeker Intelligence Cloud telemetry, as expected for this specific campaign, most of the victims come from the U.S. and Canada, but let's take a broader look at the geographic telemetry from RIG Exploit Kit, in the last 2 months: Top 10 Countries affected by RIG Exploit Kit Country Percent of Total United States 32.36% Canada...

Websense® ThreatSeeker® Intelligence Cloud has detected that the official website of AskMen (at www.askmen.com ), a popular free online men's web portal , has been compromised and injected with malicious "drive by" code that appears to be part of a mass-injection attack. According to similarweb.com , AskMen's website has more than 10 million visitors each month. The injected code redirects a user to a website serving exploit code, which subsequently drops malicious files on the victim's computer. Websense Security Labs™ has contacted the host master of askmen.com with a notification regarding the compromise. Update : We've been working with Ziff Davis' web security team regarding the compromise, as of today (7th July 2014) we verified with our processes that the website is clean when checked at 14:00 BST and does not serve malicious code. This is not a guarantee the website will continue to be clean. We will continue to monitor the website and update the blog if needed. AskMen's main page as of 23 June 2014: SimilarWeb.com statistics for AskMen: Websense customers are protected from this threat with ACE, our Advanced Classification Engine , at the following stages: Stage 2 (Lure) - ACE has detection for the compromised websites. Stage 3 (Redirect) - ACE has detection for the injected code that redirects the user to the exploit page. Stage 4 (Exploit Kit) - ACE has detection for the malicious code that attempts to execute this cyber-attack. Stage 5 (Dropper Files) - ACE has detection for the binary files associated with this attack. Stage 6 (Call Home) - Communication to the associated C&C server is prevented. Analysis The injected code has been found in multiple locations within the main website as well as in localized versions of it, like au.askmen.com. When a user browses to the main website, the injected code loads automatically and silently redirects the user to a website serving the actual exploit code. The injected code is obfuscated and can be found at the bottom of legitimate JavaScript pages on AskMen's website. The injected code on AskMen's website: How DGA is used to redirect the user The obfuscation used here is a simple base64 encoding, which can be easily de-obfuscated to a Redirect to a website generated by its domain generation algorithm (DGA) as well as the DGA itself. De-obfuscated JavaScript code: What the above code does is basically this: It takes the current date (year, month, and day) and uses a CRC32 algorithm as a hash function to hash that data, which ends up being the domain name. This means that a new domain will be generated everyday, and as we know how the algorithm works, we can easily predict future domains. For example, the domains that will be generated in the next 7 days (from 24 to 30 June) can be seen below. Exploit page URLs from 24 to 30 June: The Redirect takes the unsuspecting user to a heavily obfuscated page serving a Java exploit (most likely CVE...

Websense Security Labs™ see a lot of new malware names on a daily basis. Some are brand new and unique, and others are spin-off variants of well known malware. Recently the name 'Zberp' appeared in the media, with reports suggesting it combines some of the most powerful features of the Zeus and Carberp malware. But how different is it from Zbot, and what advanced features does it possess? In this blog, we will detail the features of 'Zberp', explain how to protect ourselves from it, and reveal why the hype surrounding it is somewhat unfounded. In our previous blog on Zeus GameOver we saw an increase in that particular variant during April and May but as we can see in the following heatmap, the popularity of Zeus variants in general has decreased since the large spikes we saw at the end of February and throughout March. Identification - same old Zeus? Firstly, we need to check whether this is actually a known Zeus variant. Uploading a sample of Zberp to Zeus tracker suggests that it is indeed the KINS variant: KINS is also known as 'ZeusVM' in the security community and has been well documented in the past. Its features include the usage of a virtual machine code obfuscation to execute code using (and abusing) a commercial product known as ' VMProtect ', and hiding the download of its configuration file in images with a well known technique called steganography . Also seen in some KINS versions is the ability to hide its registry modifications that allow it to be launched on start-up, an interesting persistence feature that makes it a bit more challenging to detect. However, the underlying malware dubbed 'Zberp' is almost identical to Zeus and has no behavioral differences, so what is different after all? Let's have a deeper look. Dumping the configuration file from Zberp shows us that the version number is 1.0.1.0, a common KINS version. Unsurprisingly, the configuration file format itself is very much the same as many other Zeus variants: VERSION 1.0.1.0 BOT URL https://bloggershop.co.vu/idcon/driver/load.exe COMMAND AND CONTROL URL https://bloggershop.co.vu/idcon/static.php ... Evasion Techniques & Unique Features 'Zberp' has a slight change to the code that handles its hooks. Before we dive a bit deeper, what exactly is hooking doing in malware context? In short, Hooking is a technique used by malware to 'spy' on the victim's actions and subsequently steal relevant information. In simple terms, think of opening your banking website in your browser: the data that goes to and is received from the banking website can be intercepted using hooking at the application level (this means it will subvert any SSL encryption too) . Back to our analysis, a typical KINS/Zeus hook on the HttpSendRequest Windows API looks like this: Whereas a 'Zberp' hook is quite different: The 'handler' is the part of the hook that utilises and intercepts the information from the API. The...

In their rush to exploit users, hackers have littered their own creations with easily exploitable vulnerabilities. They're learning that it's not so easy to write secure code. In fact, most of us in the business of securing our applications and systems know that bulletproofing software is an extremely expensive and exhaustive undertaking. Most attackers lack the necessary resources and community peer review to harden their malware, and that provides an opportunity for the security community to advance a conversation about what we should do about it. Some food for thought: Hackers hide in the shadows and thrive in anonymity; probing their attack networks would shine a light on their own techniques and tactics Law enforcement and the security community could use the information to track down suspects and shut down attack infrastructure Malware creators who have to look to their own defenses would have to slow down the production of new attacks Is it legal? Is it ethical? Let's look at a vulnerability in the C&C of a Zeus Trojan in circulation and envision the possibilities together. The Vulnerability As we have explained in previous blogs , Zeus is a banking Trojan, which is designed to steal login credentials and other Personally Identifiable Information (PII). In this analysis, we will demonstrate that malware authors make numerous mistakes as regular software engineers and show how a particular publicly known vulnerability present in the Zeus C&C server can lead to full access to the botnet’s Command Panel or possibly full system compromise of the server. We have set up our own Zeus C&C and bot in our internal research network where we can simulate this attack and show its implications. In order to understand why the vulnerability exists in the first place, we must understand the basic workings of Zeus. Zeus bots operate in the following pattern: 1) Infect a system 2) Gather credentials and PII, and 3) Upload the stolen data in the form of reports to the C&C Server. The crucial point here is that the bot uploads some file to the remote server. What if we could leverage this mechanism to impersonate a bot and upload our own file to the server? Let’s say an executable, with which we could execute commands on the server. Unfortunately, we can’t just simply upload a file. Zeus uses RC4 algorithm to encrypt all communications between the bot and the server, so it will only accept files if they are encrypted with the same key that the server uses. Luckily for us, RC4 is a symmetric cipher, which means that both parties (in this case the bot and the C&C) use the same pre-shared key. This further implies that the key is embedded somewhere in the bot. So we need to capture a Zeus binary and find the keys in order to be able to communicate with the C&C. We can achieve this by using the Volatility memory analysis tool to dump the RC4 keystream from an infected machine’s memory. Now that we have the...

In this blog we shall reveal the uses for certificates, uncover how to combat abused certificates and dig deep into an example of how malicious software can be digitally signed to pass certification verification.

This blog describes briefly what WebShells are, and how attackers can
use WebShells to gain powerful shell level/system level access to a
server. WebShells have been used in attacks for quite a long time now,
but with changes in attack trends, cyber criminals are getting more
sophisticated with deployment techniques and methods to circumvent
detection. With the help of our Websense® ThreatSeeker® Intelligence
Cloud, we came across a few examples in which attackers have used
different techniques. These are elaborated on further in this blog.

Websense Security Labs™ and The Websense® ThreatSeeker™ Network have detected that the government-related websites ict.org.il and herzliyaconference.org have been involved in a 'waterhole' attack and are injected with malicious code that serves as an exploit for Internet Explorer vulnerability CVE-2012-4969. The first website describes itself as the “International Institute for Counter-Terrorism”. Both websites seem to be connected and governed by a leading Israeli academic institution called the IDC.

The malicious code found on the websites is identical and was identified as CVE-2012-4969 - an Internet Explorer vulnerability that was verified as a zero-day at the time and was found to be exploited in the wild on September 2012. It was found by Eric Romang from Zataz.

From our initial checks, the websites still serve the malicious code on specific paths, and have been serving the malicious code from as early as the 23rd of January 2013. At the time of this writing, the malicious code on ict.org.il appears to be fully functional, but the malicious code on herzliyaconference.org doesn't seem to be functional (the main page that initiates the exploit seems to have been removed; although subsequent pages are still available, on their own they won't serve a successful exploit).

Hot on the heels of the NBC.com hack last week, Websense® Security Labs™ researchers were alerted by SANS to another high profile website compromise on Friday: bible.org . It appears that the offending code has now been removed from the bible.org website. At first glance, this seemed to be a run-of-the-mill “compromise, redirect, exploit” chain; however, closer analysis revealed the use of an interesting Honeyclient evasion technique. Honeyclients allow the profiling of websites in a heuristic and automated way; more often, testing a website with a Honeyclient takes longer than signature-based solutions but the results are much more accurate, especially when new zero-day code or a new emerging threat needs to be flagged up and requires scrutiny. Usually, Honeyclients run on top of virtual machine sandboxes: evasion techniques allow malicious code to become more aware of its running environment and to check if it's in a virtual environment or likely to be an 'analysis' environment before actually running malicious code. This snippet of code is the entirety of the Honeyclient evasion attempt - as the method name suggests, the function ‘jsstatic’ will only be called once the eventhandler registers the movement of the user’s mouse over the document (page) – obviously, a primitive Honeyclient will have no mouse movement emulation, therefore the offending function that leads to exploit code will never be called and alerted on by the Honeyclient. Let’s take a closer look at the jsstatic function (click to enlarge): The first part of this function definition is simply a sentry variable, to stop the function being executed indefinitely with each new onmousemove event – the global variable astatf is defined as 0 in an earlier part of the script. The next part simply creates the iFrame, which is then executed as if it had just been injected into the page, as per a normal compromise. This technique is quite primitive and showcases the infancy of this type of Honeyclient evasion technique. The plethora of event handling methods available means this technique is not going to go away anytime soon, and is likely only going to get more complex and inventive. In summary: the use of such techniques ultimately aids malicious code in remaining undetected for longer periods of time and thus increases its chances of bypassing security products undetected. The technique described in this blog is simple and allows redirection to exploits only if a mouse movement is detected, an action that is often associated with an actual person interacting with a website and often not used by primitive Honeyclients. Why are the attackers using this technique instead of the normal drive-by type technique we usually see? probably because they wanted to make the attack more stealthy, as attacks like this wouldn't be picked up by automated behavioral analysis systems. That's why multiple layers of defense are needed...

The Websense® ThreatSeeker® Network has detected that a FOREX trading website was injected with a malicious Java applet, which could install malware on the affected systems of the site's users. FOREX is the foreign exchange market where international currencies are traded, and nowadays, it's used by millions of people around the world.

The targeted website is a popular FOREX website called "Trading Forex," located at hxxp://tradingforex.com. One of the questions that is raised when encountering such a compromise is whether some cybercriminal shift their focus from mainstream online money management systems of banks and stock exchanges to "easier wins" with online systems and services that are likely to be less mature from a security perspective. Another interesting fact is that the dropped backdoor at Trading Forex is written in Visual Basic.Net and requires the Microsoft's .NET framework to be successfully installed and operational on the victim's computer.

Thanks to the Websense® ThreatSeekerTM Network, Websense Security Labs recently detected an unusual domain name that we have analyzed. The domain name, "inte1sat", substitutes the number "1" for the lower case letter "l", an example of "leet" substitution that surfaced in the 1980s and is still used today. (Leet is a method of constructing words by substituting numbers for letters.)

The first step in our investigation was to look into the content of the URL: hxxp://www.inte1sat.com:

As so often happens, the content revealed what appeared to be another Java exploit attempt. We decided to set aside content analysis for the moment and investigate instead the domain name spelled in its normal alpha-English form: "Intelsat.com". Googling Intelsat.com we learned that it is a company involved in satellite technologies and satellite-enabled services (including IP trunking, telecommunications, and more).