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.

Many mass compromises are accomplished in an automated fashion: vulnerabilities are enumerated, and after one is found, exploits are automatically deployed. The takeover process usually involves downloading a remote administration tool for the compromised website. One common tool deployed by attackers once they compromise a website is a WebShell.

The above diagram shows an attack where the attacker finds a vulnerability in a hosted web application and manages to upload a malicious application backdoor in one of the server supported languages.  This gives him control over the entire web server. 

What is a WebShell?

A WebShell is a script/code (written in scripting languages such as PHP, Perl, or Python) that runs on the system and can remotely administer a machine. Although WebShells are used as a Remote Administration Tool for many legitimate reasons, they can still be abused by malware authors to compromise websites.  Once the attacker gets a web server to execute the script, he gains shell-level access to the host operating system running with the same privileges as the web server. To avoid detection by firewalls or antivirus technologies, the attacker usually employs evasion techniques such as code obfuscation and encryption. To thwart this aspect of the WebShell's propagation, a full content inspection approach can reveal, and intercept, a wide variety of common obfuscation techniques and even decrypt the script to expose its real intent. Let's look at an example.

In the following example, we see a custom WebShell called "oRb". The actual WebShell body is obfuscated to avoid detection, using a preg_replace function with the "e" modifier.  Hex encoding has been used to conceal eval(gzinflate(base64_decode( . 

The URL that serves the WebShell further tries to confuse or mislead security tools by declaring in the header that the content type is an image file, as you can see below:

With its real-time scanning capability, Websense ACE™ (our Advanced Classification Engine) detects the obfuscation methods and techniques discussed above.

Let's now look at a second example to see the type of functionality that WebShells encompass. In this case we see a non-obfuscated version of "RC Shell v2.0",  which is similar to our previous example in that it also tries to hide as an image:

A working WebShell

Once the WebShell script is run, it provides a web interface for remote operations on the server, including, but not limited to:

• Server Information
• File manager (access to file system)
• Access to execute commands
• SQL manager
• PHP code execution
• Bruteforce FTP, MySQL, PgSQL
• Search files, search text in files
• Malicious content upload
• Mass code injection 

This animated image shows how it would look when run (click the image to open; the animation loops):

Websense ThreatSeeker Intelligence Cloud processes approximately up to 5 billion web requests per day, and out of those requests, just yesterday we found 1400 unique examples of threats using WebShells in different countries. Here is an example of how one obfuscated WebShell is spread around the globe.

How does Websense protect against WebShells?

The animated graphic above shows how powerful the access can be for an attacker.

ACE will block access to this malicious WebShell script/page if your end users locate such a script.  In addition to preventing access to the malicious WebShell script/page, we monitor outbound content to prevent sensitive data from leaving an organization via shell commands even if the abused channel is SSL-encrypted - which is a common advanced malware technique.  With the help of web telemetry we can generalize to the tune of 85,000,000+ compromised websites and thus learn from them, including what we have discussed here about WebShells.  Have a read of our Threat Report to find out more.

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).

The attack seems to be very similar to the spear-phishing attacks we reported on with the "Rotary Domains" (Part 1 & 2) that served CVE-2012-4792 - that's the same zero-day that was found on cfr.org. The attack on IDC uses a Flash file to conduct a "heap spray" attack. The Flash file appears to have the misspelled string "heapspary".  According to Symantec, this string may be evidence that the "Elderwoord" group is behind this attack, because there's a similarity to the cfr.org attack, which held the same string "heapspary" in a Flash file as well. We're not completely convinced by this theory; this may indeed suggest a connection to the "Elderwoord" project, but may instead suggest the use of the same toolkit by different perpetrators. 

One of the most interesting techniques employed by this attack, which we described in detail in our previous "Rotary Domains" posts, is that the dropped malware is actually embedded as a XORed list of bytes on the page and assigned to a Javascript variable with a marker at the start of the stream.  After exploitation is successful, then on the client side the shellcode initiates a thorough search for a certain marker in memory called "KKONG".  When this marker is found, then the stream is extracted and de-XORed to form the actual malware binary, which is then run. This is an interesting technique that is also good for Sandbox evasion and reminds us of the "Drive by cache" techniques also found to be popular with spear-phishing attacks in the last two years. The difference in this method is that it's sort of a "Drive by marked memory object".

Websense Security Labs™ has contacted the IDC to report the compromise; as of this writing we had not heard back yet from the IDC.

The Israeli website for the “International Institute for Counter-Terrorism” and its mission statement is shown here:

Technical details

As described, the attacks on both websites are identical. The exploit chain starting point is in an HTML file on a dedicated directory.  We're not certain if this specific path was sent in spear-phishing emails, or if the main page of each of the websites referred to this path. If you have any more details on this, please do let us know.

Here are the exploit chains for ict.org.il and herzliyaconference.org:

hxxp://www.ict.org.il/js/1.html -> Flash file loader (AceInsight report)

hxxp://www.ict.org.il/js/logo4969.swf -> Flash heap-spray + exploit.html loader

hxxp://www.ict.org.il/js/exploit.html -> Dropped file cache + Exploit Loader

hxxp://www.ict.org.il/js/Protect.html -> Exploit CVE-2012-4969

hxxp://www.herzliyaconference. org/_modules/80.html -> Flash file loader (AceInsight report)

hxxp://herzliyaconference .org/_modules/logo4969.swf -> Flash heap-spray + exploit.html loader

hxxp://herzliyaconference. org/_modules/exploit.html -> Dropped file cache + Exploit Loader

hxxp://herzliyaconference. org/_modules/Protect.html -> Exploit CVE-2012-4969

Let's have a look at the specific exploit chain on ict.org.il.   The file 1.html is used just as a loader for the malicious file logo4969.swf.  Besides the loading of the malicious file, there are no malicious indicators on the page, but just the HTML Flash container/loader:

The loaded Flash file initiates a heap-spray attack, but it also acts as the caller to the Exploit Loader page exploit.html - it loads it through some Actionscript commands embedded in the Flash file, to evaluate some Javascript code to be executed on the page and load exploit.html, as seen in the next picture snippet from the file: 

exploit.html holds some Javascript code and an especially long variable. This variable starts with a marker "KKONG" that is later searched for by the shellcode that resides inside the loaded Flash file on the client side. The file is obfuscated with a simple XOR 0xBF. The page also loads the actual exploit page by calling an iframe to Protect.html:

Protect.html holds the exploit code to CVE-2012-4969. The exploit code is obfuscated with a simple obfuscation technique: 

After the exploit is triggered by Protect.html, the code will jump to the sprayed shellcode on the heap.  In return, the shellcode will scan the memory for the marker mentioned earlier: "KKONG". After the marker is found, the shellcode strips the stream following the marker and gets it de-XORed with the value 0XBF to form a valid executable file.  That file is then written to the Windows local machine's temporary folder and executed to infect the machine with a persistent backdoor.

The executed file dw20.exe (MD5:d2354e9ce69985c1f55dbad2837099b8) acts as a dropper and has the same name as the file dropped with Rotary domains attack. The threat stays persistent on the system by dropping another file to the Windows directory called startup.dll (MD5: 4e1e2b9cd6b5bca2b1b935ddc97f2d7a) that registers as an auto-started service called WindowsUpdata. Check out this complete report from ThreatScope™. The backdoor service is actually installed under a registry key called "RAT", which is not very discreet, to say the least, and the backdoor connects to a C2 that is recognized by our service as suspicious hxxp://interfacet.oicp.net:88. It appears that oicp.net is a web host that is located in China. Custom hosts on the site have been found to be involved in targeted attacks in the past (1 2); however, the specific host actually points to an IP address of 65.19.141.203 located in Fremont, California, United States. Looking closer at this IP address, we could see that it hosts a lot of mayhem, as well as many other hosts that are associated that use host names on *.oicp.net that we have already classified in a security category:

One of the most interesting parts is that the IP address to which the C2 points is hosted on an IP address range that belong to Hurricane Electric, a US-based internet service provider that got some headlines lately for being the first Internet Backbone to Connect to 2,000 IPv6 Networks. An Interesting article from 'The Droid Tech Guy' illustrates how, although web traffic in China is very restrictive and censored, its architecture is actually one of the most advanced.  According to the article, one of its advances is that it employs a security feature known as Source Address Validation Architecture (SAVA). To quote from the article: "This feature puts security checkpoints throughout the system and then builds up a database very systematically. This database will contain trusted computers and their IP addresses. This system will then authenticate who is sending what. This way, the possibility of sending malicious data becomes a lot more difficult, nearly impossible, like many say." 

This is a good point that makes us ponder - could it be that threats that originate from China are actually safer, from the attacker's perspective, if hosted outside of China? That may well be the case. 

In summary, we had a look at high profile government related website that got compromised in a 'waterhole' attack and employed some interesting technique. It looks as if targeted attacks have now been surfacing regularly and more frequently, with more attacks that are now exposed almost on a weekly basis. Those kinds of rapid discoveries may cause the players behind state-sponsored attacks or other miscreant groups to increase their level of sophistication. However, we believe that the sophistication of such attacks directly depends on the protection level employed by the target. If defense levels are mediocre or "just enough," then attackers will probably do just that much to get past them. The tough questions one should ask one's self in today's threat landscape is "what am I doing to not be the next victim?" and, even more importantly, "what am I going to do when I do become one?".  We believe that post-infection mitigation plans should be given the same emphasis as prevention and putting adequate protection in place.

Websense Protection

Websense customers are protected from this and other threats by Websense ACE (Advanced Classification Engine).  ACE protected against this threat in real-time and against the different stages of the attack progression, also known as the "kill chain". You can find in the next link more information about the 7 stages of advanced threats. Here is a recap how ACE protected against the different stages:

Lure stage: protection confirmed, the lure is the first stage of the attack and in this case it was those URLs that loaded a malicious flash file:

hxxp://www.ict.org.il/js/1.html -> Flash file loader (AceInsight report)

hxxp://www.herzliyaconference.org/_modules/80.html -> Flash file loader (AceInsight report)

Dropper stage: not applicable, the dropper is the stage where a file passes through the gateway and inspected in real-time, however, this is not applicable for this attack as the file was hidden and obfuscated in memory and reconstructed on the client side - this is a typical sandbox evasion technique. 

Calling home stage: protection confirmed, the calling home stage is the destination that the malware connects to after getting successfully installed on the victim's machine. In this attack the malware initiated connection to a destination that is already known to us hxxp://interfacet.oicp.net:88 (AceInsight report).

For participation in data analysis, special thanks to: Gianluca Giuliani

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 for web-based attacks.

This discovery ties in to Websense Security Labs predictions that Cybercriminals will become more 'virtually aware' and find modern bypass methods to avoid security detection - see our Websense 2013  Security Predictions.

Author: Darrel Rendell 

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.

Websense customers are protected from these and other threats by  Websense ACE (Advanced Classification Engine).

At Websense Security Labs™ we are used to seeing this kind of injection, based on malicious Java applets trying to exploit  Java vulnerabilities, and we have blogged about them several times. In this case, however, investigating the malicious JAR file brought up some interesting details. The malicious code has been injected in the bottom of the page, as shown better here:

At this time the website hxxp://libertyresarve.info seems to be active,  however in the latest days we seen that sometimes was turned off although was still possible retrieve the content through the Google cache. We can also be sure that it has been used for typosquatting activities against the real Libertyreserve (the virtual currency organization) website as shown below:

The message in red which has appeared on that Web page is a clear attempt to convince users to load the malicious Java applet in some way. Below is the real content of Libertyreserve.com:

 At first glance, the JAR file seems to be written not to exploit Java vulnerabilities, but just to load a binary file hosted at "hxxp://www.libertyresarve.info":

Basically the Java code is just another Java loader which requires user interaction to successfully load the binary file "123.exe". One interesting point in the screenshot above is that we can also see in the MANIFEST-INF that the Java applet has been signed with a certificate. Trying to evaluate the certificate validity with the tool "jarsigner" (included in the Java SDK) shows that the certificate expired on 5 October 2011, but the applet was signed on 7 July 2011:

Due to the expiration of the certificate, it is possible to get the reasons why this JAR file has been considered as suspicious from the details of the usual Java warning message: 

By clicking on the details offered by the Java plugin alert, it is possible, as shown, to retrieve the issues related to this untrusted Java applet. This is a mitigation for the success of the attack, but is also true that due to the kind of users on this website, maybe that they are inclined to accept this malicious JAR due to a potentially  false sense of security and trustability.  Another interesting viewpoint has been found in the associated binary file.  The detection of this file still seems low, as reported here:

https://www.virustotal.com/file/66fdad1bc63eca7d8124d16c83322a6ca3b45546a70ddb0a9e122be6e9aaebfb/analysis/1353429475/

However, we tried submitting the executable file "123.exe"  to Websense ThreatScope™ with the following result:

From the full analysis reported here, it has been detected that the C&C called by the malware  is "hxxp://firestormm6t.no-ip.info" and seems to be associated with the IP address 46.166.129.110:

The file "123.exe" seems to be a ".NET" file probably written using C#. From deep analysis of the network traffic, it is possible to retrieve the exchanged packets between an infected system and the C2 (reported above) . It is easy to see that at least for the network activity detected, all the information is encoded using a plain BASE64 encoding. For example, the following screenshot reports the first request from the infected system to the C&C:

The screenshot above shows the exchange of data between the infected system (in blue) and the C&C (in red). In this case, decoding one of the BASE64 strings enables us to understand that all the BASE64 strings above are the strings reported in the open windows on the desktop of the infected systems. So for example:

Once decoded it became:

That is the caption of the Wireshark windows we used to get the traffic. We also detected other functions, such as the screenshots of the desktop taken by the malware. Below, it is possible to recognize the JPEG marker ("JFIF") and the keyword  "CAP" which is without doubt the short form for "CAPTURE:"

The binary file, as mentioned above, seems to be written using the .NET Framework using Visual Basic .NET . By opening  the the .NET disassembler "ILSpy" (an open source .NET disassembler powerful and robust enough to obtain not only the .net opcode but also the high-level language behind the .NET applications), it has been possible to detect the main functions with the list of the commands used to exchange information and data between the C&C and the impacted systems.  For example, the function "Init" is the first function called to collect the basic information from the systems on which the executable file is run:

The char "l" and the char "v" are the command init sent by the malware at the first execution, as discovered by the captured network traffic. It is also possible to detect other commands such as the check of the Service Pack (command "SP"):

Or for example the function which is able to detect the keys pressed by the user after pressing Enter (command "[ENTER]"):

There are also other features such as the detection of the CPU architecture (32 or 64 bit), functions to locate files by dates, and more. At first glance this malware seems very well written, and it uses an interesting obfuscation mechanism to retrieve and store the data required.

Thanks to the Websense® ThreatSeeker® 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).

Although it was tempting to conclude that "inte1sat.com" is just a "typo squatting domain", we proceeded to Google "www.inte1sat.com" with the following interesting result:

At first glance, as shown above, it appears that the domain is specified in documents stored on the USA Federal Communications Commission (FCC) website. The FCC mandate states: "The Federal Communications Commission regulates interstate and international communications by radio, television, wire, satellite and cable in all 50 states, the District of Columbia and U.S. territories."

At this point we looked at the publicly accessible PDF files that came up in the Google search. When we looked for instances of "inte1sat.com" in the files, we didn't find any. The only explanation we could think of, which is highly speculative, is that there might be a misidentification of the character "l"  by the OCR algorithm of the Google PDF caching mechanism when the PDFs files are scanned or faxed as shown below:

Although we couldn't yet connect any dots, the collection of weird indications kept us going. We decided to return to the content of the original domain.

The content clearly shows that it is using Metasploit to retrieve a JAR file that uses the well-known CVE-2012-4681 that hijacks the JAVA Security Manager by generating exceptions. Evidence of this is shown below:

Here is the code used to generate the exceptions:

When the exploit is successfully executed, it loads and runs the EXE binary file "IrFKDDEW.exe" embedded in the JAR file. The MD5 of this file, as reported here, indicates that it leads to a backdoor. We submitted the binary file to Websense ThreatScope™ and it detected malicious threats as reported here. Analyzing just the network traffic generated by the malware, we discovered the following behavior:

Each HTTP request was directed to the following domain:

By retrieving and examining the HTTP stats from Wireshark, we discovered that the requested URLs are unique, except one that is called twice. Also, the pattern of requested URLs looks something like a pseudo random generation algorithm:

The URLs are "called" on a regular time interval. C&C (command and control) is "net.chiquita-brands.com" hosted at IP address 14.36.201.151. Robtex provides this information about that IP address:

Looking at our ThreatSeeker Network database, we see that this host has been known since July 9, 2012. We also note that it appears to be largely unknown to the greater security community, according to Virustotal.

Next we used Robtex to examine the WHOIS record for chiquita-brands.com:

Using the registration information, we found a paper authored by Command Five that indicates that the contact has been registering domains involved in APT and corporate cyber espionage attacks. The entire document is available here: http://www.commandfive.com/papers/C5_APT_SKHack.pdf

We cannot confirm that there is a problem in the Google OCR PDF caching mechanism that results in instances of "inte1sat.com" showing up in search results, particularly those of papers hosted by the FCC. We can conjecture that if there is a flaw, it is being exploited via a typo squatting technique to deliver an exploit.  

Continuing our search, we discovered additional strong evidence. Going back to the beginning of the analysis, it turns out that the IP address 174.139.91.163, where "inte1sat.com"  is hosted, also hosts many other domains. Four especially attracted our interest. Specifically:

- hxxp://net.peasoul.com has been used in Chinese hacking activities and in targeted attacks as reported in this Pastebin link:  hxxp://pastebin.com/yKSQd5Z5

- hxxp://www.attwirelessnetwork.com is another obvious typo squatting domain  for the original hosted at www.wireless.att.com (AT&T Wireless website )

- hxxp://www.rad-waste.org is a clear typo squatting domain for the original web site: hxxp://www.radwaste.org, a Web site for radioactive waste management professionals

Each of the typo squatting hosts are active at this time and contain the following content:

Using Robtex to retrieve the WHOIS information, we discovered that three of the domains are registered to the name "Xiaohua Dai":

Registrar for hxxp://rad-waste.org

Registrar for hxxp://attwirelessnetwork.com

Registrar for hxxp://inte1sat.com

Only one is registered to another name (Jiaxin Technology - Yong Liu): 

Registrar for hxxp://peasoul.com

There are also several other domains detected on IP address 174.139.91.163, including ssl.mailyuidyahooapis.com and bloomberg-global.com. These may also be used for typo squatting attacks, but at this time those sites are not active.

Websense customers are protected from these and other threats by Websense ACE (Advanced Classification Engine).  

The Websense® ThreatSeeker® Network has detected that two Nepalese government websites, the National Information Technology Center (NITC) and the Office of the Prime Minister and Council Minister (nitc.gov.np and opmcm.gov.np respectively), have been compromised and injected with malicious code that tries to exploit the Java vulnerability CVE-2012-0507. The aim of this injection is to install, through successfully exploiting that Java weakness, a backdoor that is also dubbed "Zegost" on the systems of visitors to these websites.

This vulnerability (CVE-2012-0507) was also used in the Amnesty International UK website compromise and in the INSS website compromise that we reported a few months back. It's interesting to note that all those compromises had injected code that was taken from the Metasploit framework, served in clear form, and not obfuscated. Although the use of code from the Metasploit framework doesn't necessarily indicate a link between all the compromises, we found further common characteristics between the compromises of the Amnesty UK website and the Nepalese government website by analyzing the backdoor C&C points when we noticed that they connected to the same domain in China. 

The backdoor variant in this attack is known to have been used in other targeted attacks that were aimed at Uyghurs, Tibetans, and others in that area.

Websense customers are protected from these threats by ACE, our Advanced Classification Engine.

Technical Analysis

According to Cyberwarnews, in early 2012, the websites of Nepalese institutions, such as the police, suffered two other types of attacks mainly in the form of defacements and data leakage. But it's not just Nepal that has been affected. This region has recently seen a sequence of targeted attacks and APTs.

Below is the content of the Nepalese National Information Technology Center (NITC) Web page along with the injected code marked in red: 

The main page was injected with a Java JAR file loader which once rendered by the Web browser is executed and attempts to exploit the CVE-2012-0507 vulnerability. The name used for the Java class name ("msf.x.Exploit.class") and the content of the file confirmed that the code was taken from the Metasploit framework. If the exploit code in the JAR file has been successfully executed, the exploit shellcode downloads and runs the executable file named "tools.exe" on the impacted system (MD5: 3c7b7124f84cc4d29aa067eca6110e2f).

The ThreatSeeker Network was able to connect that same executable file dropped from nitc.gov.np (National Information Technology Center) to another Nepalese government website, opmcm.gov.np (Office of the Prime Minister and Council Minister website), as shown below:

The red, boxed URL is the website of the Office of the Prime Minister and Council Minister. We found out that this particular website was compromised this year, at least from May 9-15, to serve this same backdoor executable (MD5: 3c7b7124f84cc4d29aa067eca6110e2f):

The content that was injected between these dates at the website of the Office of the Prime Minister and Council Minister was identical to the code injected at the National Information Technology Center website, confirming that the same attack vector was used for both:

We detected that the dropped backdoor "tools.exe" (MD5: 3c7b7124f84cc4d29aa067eca6110e2f) is a variant "AD" of the backdoor Zegost. This backdoor toolkit or remote administration tool (RAT) has also been involved in other targeted attacks in Asia, according to an analysis by AlienVault in their research blog.

Thanks to the Websense ThreatScope® sandbox service, the C&C address was detected at "who.xhhow4.com," as shown in the picture below (for the complete sandbox report, click here). 

The domain "hhow4.com" was also used as a C&C point for the dropped backdoor served at the compromised Amnesty  UK website, where that variant specifically connected to the address at "shell.xhhow4.com" (for the complete sandbox report, click here).

Both C&Cs are hosted at IP address 184.22.171.216:

The domain "xhhow4.com" is hosted in China by a Web hosting company known as Hichina Zhicheng Technology Co., Ltd. The next image shows a Robtex DNS names graph analysis for that domain:

Once the backdoor is installed on the impacted system, it initiates connections from local TCP port 1320. The destination address is to the C&C  at "who.xhhow4.com" and uses remote TCP port 53  (usually the port reserved for the DNS Zone transfer). However, it's important to note that the traffic wasn't DNS traffic but the proprietary protocol used by the backdoor for remote communications. Below is the first connection sequence between the backdoor and the C&C:

By decoding the TCP stream, it is possible to recognize that custom encryption was used to exchange information with the C&C. The network traffic starts also with a keyword, "URATU," as shown below: 

Once executed, the binary creates a Mutex named "microsoft.com" reported below:

The backdoor also uses common features like other common backdoors, such as keylogging, and supports the ability to accept and run commands remotely. As in other cases, we can see that this backdoor isn't highly complex at all, but it's certainly no less effective than other complex malware once executed on the target systems. Another interesting aspect of this backdoor file is that it's signed with what appears to be an invalid\fake certificate issued to 360.cn (a Chinese ISP) by VeriSign, as shown in the properties box:

The certificate contains the following details:

Having malicious code signed with certificates is a trend that we’ve seen in other targeted attacks that can reduce the effectiveness of human and automatic countermeasures. 

In this blog, we covered the compromise of Nepalese government websites in what appears to be a chain of targeted attacks. We managed to connect those attacks to a previously reported attack that took place in a different country: the compromise of the Amnesty International UK website. This shows that cyber warfare is trending and kicking and that there's certainly an effort by international players to stay dominant and persistent in that realm.

Security Researchers: Gianluca Giuliani, Elad Sharf.

The Websense® ThreatSeeker® Network discovered on June 27, 2012, that one of the most popular travel websites in India, cleartrip.com, was compromised and served malicious code. The website was informed of this breach and no longer serves malicious code.

In this blog, we'd like to share our insights about this attack and focus on the tactics that we observed being used. We managed to spot this attack iteration before it became fully active, before malicious files were uploaded to the exploit kits that cleartrip.com was redirected to, and before all the malicious redirection nodes that cleartrip.com led to were active. 

The tactics that the cyber criminals used show what goes into making a legitimate website's infection less obvious and more difficult for security products to detect. These tactics included the following:  

• Targeting a website's local ad system and masquerading as legitimate ads 
• Manually intervening on a compromised website and preparing multiple domains to ensure redundancy  
• Obfuscating available malicious toolkit redirectors to circumvent detection
• Using advanced traffic direction system components and masquerading as a legitimate website to remain covert 
• Using exploit kits that serve Java-based exploits only

The next image summarizes the infection redirection chain leading to the exploit website as it started from cleartrip: 

In this section, we'll take a closer look at the tactics we listed above: 

Tactic 1: Targeting the local ad system and masquerading as part of the legitimate ad chain

The attackers seemed to focus on cleartrip.com's local ad system. Having that specific component compromised allowed them to serve malicious code through ads maintained by the website itself. The ad system on cleartrip is a third-party component plugin developed by Openx. Targeting third-party plugins is a very common tactic used to compromise legitimate websites. In this instance, it looks like the attackers gained control of the website's ad system since malicious code was restricted and served from that area only. Other cases of abuse of Openx components through exploitation and serving malicious content are documented throughout the Web. 

"Malvertizing" is another form of loading malicious code with advertisements. This is when third-party advertisers have their ads or their infrastructure compromised and then having their ads injected and loaded with malicious code. However, in the cleartrip attack, the local ads were served by cleartrip.com itself and not by a third party. By gaining unauthorized access to the Openx advertising component on the website, the attackers succeeded in sabotaging and injecting ads with malicious code. Malicious code loaded by ads is harder to detect because loaded ads usually reside at deeper path levels of the website and the malicious code blends well with the rest of the ad content. In contrast, most compromises we see in the labs tend to have injected code on the main page of a website or through pages that are loaded by the main page of a website.  

When we checked the IP address of the website of one of the malicious redirectors in this attack, euro-cool.in, we saw that it was hosted on IP address 85.17.122.245. A host report on that IP revealed more websites that have the same purpose and that are part of the attackers' malicious infrastructure (image 2). Some of the websites' names contain "openx," which leads us to surmise that the individual or group behind this attack is purposefully targeting websites that have the Openx plugin.

It's evident that the attackers were trying to blend in with legitimate ad traffic and appear to be a legitimate part of the ad chain. If you look at the detailed redirection flow in the set of images below and specifically at steps number 3 and 4, you'll clearly see keywords like "advertisement" and URL patterns that are used by legitimate ad providers, such as this on the malicious redirection stage: /banners.cgi?advert_id=1&banner_id=1&chid=341aa8fca26bcff7830499c1c5f8e359 

Tactic 1 summary: By targeting a local website's ad serving component and injecting code into legitimate ads served locally by a website, attackers can more easily evade detection and remain undiscovered.

Image 1: The Openx advertising plugin login page 

Image 2: Websites hosted on  85.17.122.245 (euro-cool.in)

Image 3: Detailed redirection flow of the attack

Tactic 2: Manually intervening on a compromised website and preparing multiple malicious domains to ensure redundancy  

The redirection chain we illustrated above led to an active exploit website, however the malware binaries that were downloaded after the successful exploitation were just stubs and didn't do anything malicious at all. It appears that the attackers didn't get a chance to upload their desired malicious files to the exploit website. In addition, the redirection chain illustrated above didn't use the illustrated websites exclusively. For example, in other locations on cleartrip.com, infected ads led to the malicious redirector euro-mary.in, which had the same purpose of euro-cool.in and was served in the same structure as euro-cool.in. But euro-mary.in was a "dead" redirect and didn't redirect to an exploit website.

hxxp://euro-mary.in/banners.cgi?advert_id=1&banner_id=1&chid=341aa8fca26bcff7830499c1c5f8e359

Admin Name:Roman Inozemtsev
Admin Organization:N/A
Admin Street1:R-N TBILISSKIY, UL. TRUDOVAYa D.18
Admin Street2:
Admin Street3:
Admin City:Tbilisskaya
Admin State/Province:Tbilisskiy r-n
Admin Postal Code:352361
Admin Country:RU
Admin Phone:+7.9060585279
Admin Phone Ext.:
Admin FAX:
Admin FAX Ext.:
Admin Email: rework11@mail.ru

From the tactics that we have observed so far, we believe that the attackers were intervening and setting up an infrastructure necessary for exploitation manually, and that it's being done with redundancy in mind. The attacker, in this case, was a bit careless and had one of the malicious redirectors, euro-cool.in, on its way to carrying out the exploitation. However, as we mentioned, although the exploits were active, the downloaded malware was a stub and not malicious. The image below reveals how the malware stubs were downloaded to the Windows temporary files folder after the exploit succeeded (image 4). 

Tactic 2 summary:  Manually intervening on a compromised website and preparing multiple domains to ensure redundancy are ways to prolong the duration of an attack by serving several exploitation chains.

Image 4: Dropped stub files by the exploit kit

Tactic 3: Obfuscating available malicious tool-kit redirectors to circumvent detection

The code that the attackers injected into legitimate ads on cleartrip.com was obfuscated (marked as 1 and marked in red on the exploitation chain image). Once the code was de-obfuscated, it unveiled a known redirector tool-kit code that is used and available in the underground for the same purposes of acting as a redirection point to exploit websites. The de-obfuscated code shows "decision-making" code, which means it includes code that detects the browser's version of the browsing user. In this case, if the user's browser is Internet Explorer or Firefox, only then will the user be sent to the next level of the exploitation chain. The code also assigns a cookie to the user's browser, so it can be identified at the next redirection levels. 

Obfuscating code is a very common tactic to hide injected malicious code on legitimate websites. It can effectively hinder efforts to detect malicious code since it applies the same concept as compressing and encrypting code for malicious files with packers and crypters in order to evade known malicious code detection. Scanning the obfuscated code of the redirector toolkit yields a lower number of results from antivirus vendors than scanning the clear text code of the redirector toolkit.

Tactic 3 summary: Another way to avoid detection is obfuscating available malicious tool-kit redirectors, such as by using reliable underground tool-kits that are reliable and proven to work while hiding their activity with layers of obfuscation.

Tactic 4: Using advanced Traffic Direction System (TDS) components and masquerading as legitimate websites to remain covert

The redirector on stage 2 of the attack (euro-cool.in and euro-mary.in) does not redirect directly to the exploit website, but to a Traffic Direction System on sciencedailyreview.com (marked as 3 in the exploitation chain). This system picks and chooses whether to exploit the computer. The purpose of a TDS is to scrutinize all the possible details that can be derived from the visiting user's IP address and the visiting user's browser. For example, this method is a handy way to avoid known IP ranges of security companies and IP ranges that reside in certain geographic locations that might not be of interest for the attacker to infect.

In this case, the TDS system resides on sciencedailyreview.com. This website mimics and contains some code from the legitimate website, www.sciencedaily.com, a website about science. The malicious TDS in our case has two faces: if the visiting browser fulfills certain conditions, then it will be redirected to the exploit website, but if it doesn't, then it will be redirected to a false and copied representation of a legitimate website with content taken from the legitimate website www.sciencedaily.com. This fake, malicious website is even indexed through Google and serves legitimate content if visited through Google searches and has more than 34,000 cached pages by Google (see Image 5). 

The malicious side of sciencedailyreview.com redirects to the exploit website, but first, it checks exactly what Java version is installed on the user's machine (marked as 3 in the exploitation chain). The Java version information is essential because then a decision can be made about whether the user's installed Java version is vulnerable and based on that decision, redirects to the exploit website and serves the right Java exploit to the user's machine.

 sciencedailyreview.com was registered on 2012-05-03, and its registration details are anonymous.

Tactic 4 summary:  Using advanced Traffic Direction System (TDS) components and masquerading as legitimate websites to remain covert help evade detection and prolong the lifespan of malicious websites.

Image 5: sciencedailyreview.com masquerades as a legitimate website and is cached by Google search engine

Tactic 5: Using exploit kits that serve Java-based exploits only

The exploit website (marked as 5 in the exploitation chain) serves Java-based exploits only. Java has been one of the most popular exploited components on user machines in the past year. In general, exploit kits target several components by holding several exploits for local installed components like the local browser, Adobe Acrobat Reader, Adobe Flash Player, Java, and more. Using several exploits can prove "noisy" and can result in detection of the exploit site. Tactically targeting one component for exploitation is more effective than targeting a few components since doing so is a more focused, and hence "quieter" approach that reduces the chances of the kit being discovered. Java is a good choice since usually exploits for that platform are reliable and can serve several platforms (e.g., the Java framework is also installed on Mac computers). In addition, Java is an interpreted programming language, which means, with relatively little effort, attackers can use it to obfuscate malicious code with cheap obfuscator kits that can be bought in the Black Hat underground market. 

In our case, the exploit kit on the exploit server appeared to be the "Neosploit" exploit pack, and the exploit that was served targeted the Java vulnerability described in CVE-2012-0507. This infamous exploit was used in the Flashback mass attacks and also used in the compromise of Amnesty International UK and the compromise of the Institute for National Security Studies (Israel).

Tactic 5 summary: Using exploit kits that serve Java-based exploits is an effective way to evade detection

Image 6: Neosploit exploit kit - this version serves only Java based exploits

In this blog, we took a look at several tactics that cyber criminals employ when they compromise a legitimate website for malicious purposes. Please let us know if you have any additional insights regarding this specific incident and also, please drop us a line if you'd like to share some insights about similar compromises that you have encountered.

Between May 8 and 9, 2012, the Websense® ThreatSeeker® Network detected that the Amnesty International United Kingdom website was compromised. The website was apparently injected with malicious code for these 2 days. During that time, website users risked having sensitive data stolen and perhaps infecting other users in their network. However, the website owners rectified this issue after we advised them about the injection. In early 2009, we discovered this same site was compromised, and in 2010, we reported another injection of an Amnesty International website, this time the Hong Kong site.

In the most recent case, we noticed that the exploit vector used was the same Java exploit (detailed in CVE-2012-0507) that has been used worldwide, and which has become somewhat infamous as the cause of the recent massive Mac OS X infection with Flashback. 

Websense customers are protected from these threats by ACE, our Advanced Classification Engine.

The following is a screen shot of the detected code injection:

a

                                                                  (click on the picture to enlarge)

In the screen shot, we can see the similarities between this injection and the INSS injection we reported last week. This clearly shows the use of the Metasploit framework and the precise name of the Java class used. In addition, the associated JAR file is a well-known vector exploit for the CVE-2012-0507, as shown below:

                                                                 (click on the picture to enlarge)

Once the exploit is successful, a file download is initiated for an executable from this URL: "hxxxp://www.48groupclub.org/images/uploads/image/sethc.exe" - MD5 : 3EC4DE9EF2E158473208842F4631236A

Further analysis shows that when the "sethc.exe" file is executed on the compromised system, it creates a new binary file in the Windows system directory: C:\Program Files\...... 

The ruse appears credible because the executable file has been signed by a "valid" certificate authority (CA), as shown below:

Through further research we learn that this certificate has been in use for a while and does not appear to have been revoked at the time of this latest exploit activity.

Analyzing this low AV detected binary file, we recognize that this is a variant of the well-known Remote Administration Tool Gh0st RAT, which is used mainly in targeted attacks to gain complete control of infected systems. With this control, the remote administrator has access to a user's files, email, passwords, and other sensitive personal information. Following is the initial network capture with Wireshark between a compromised system and the remote administration center, which reveals the header information of the traffic (pay particular attention to the starting keyword "gh0st"), confirming the use of Gh0st RAT:

                                                     (clieck on the picture to enlarge)

The Remote Administration Center commands to the compromised system originate from this address: shell.xhhow4.com. At the time of this writing, the address is still active.

[Update]

Websense® ThreatSeeker® Network detected that the Amnesty International Hong Kong sister website was also compromised to serve Gh0st RAT over the weekend, and the malicious codes are still live and active. Below are some of the pages infected redirecting to the exploits. Websense Security Labs will continue to monitor and update any new changes to this attack.

The Websense® ThreatSeeker® Network has detected that the Institute for National Security Studies (INSS) website in Israel was injected with malicious code. INSS is described in its website as an independent academic institute that studies key issues relating to Israel's national security and Middle East affairs.

While we can't determine that the infection of this website with exploit code is part of a targeted attack, one could deduce that visitors to this type of site are likely to have an interest in national security or are occupied in this field. The website appears to be injected with malicious code for over a week now. (Websense' ACE provided protection against the type of injected malicious code since early 2009)

One of the interesting facts about this infection is that it uses the same Java exploit vector (CVE-2012-0507) that managed to infect around 600,000 Mac users in a massive scatter attack dubbed Flashback a few weeks ago.

It's also worth noting that in the last few months, Israeli websites have been under continuous cyber-based threats and attacks. We don't think that this latest infection is part of an organized mass infection campaign but is probably just part of that trend. We continue to look for additional websites leading to the exploit website.

We have contacted the Webmaster of the website and notified them on the issue and the location of the injected code on the website, so far, we haven't heard back from them.

Websense customers are protected proactively from these threats by ACE, our Advanced Classification Engine.

Here's how this exploit works: if users visit the home page of the INSS website, the injected malicious Javascript code loads a Java exploiter. The injected code shown below consists of a "document.write" function call that uses decimal-encoded string characters to hide the exploit URL. Once decoded, the destination page may be retrieved. This means that users are silently redirected to the exploit page while their browser loads the website's home page:

The obfuscated injected content on the INSS home page looks like this:

Here's the decoded content:

And the content of the out.htm web page:

By merely looking at the code snippet above, we can see that the applet class's name suggests its intentions: "msf.x.Exploit.class." After further investigation, we detected that "test.jar" holds the exploit of the well-known Java vulnerability CVE-2012-0507. The inner workings of the "test.jar" file reveal that it contains a rather large compressed text file called "abc.txt" that is filled with a huge number of "a" characters. Once decompressed, the file size is about 104 MB. We think that this is a technique that attempts to evade automated malware analysis technologies, since some of those systems typically avoid downloading the contents of big files, because malware tends to be small in size.

From analyzing the contents of the Jar file, it was evident that it was generated by the Metasploit toolkit, which, as we mentioned, holds the vulnerability CVE-2012-0507:

The binary associated with the exploit, "svchost.exe" (MD5: 52aa791a524b61b129344f10b4712f52), is automatically installed on the victim's computer if followed by a successful Java exploiting attempt. "svchost.exe" is a variant of Poison Ivy, a remote administration tool (RAT) that can be used, as its name suggests, to control a computer remotely. The tool is robust and mature and may be used for legitimate purposes, but is also widely used for malicious purposes. Once Poison Ivy installs on the system it connects to a Dynamic DNS command and control address at: ids.ns01.us

The recent advent of flashback malware that includes exploit code for CVE-2012-0507 has been creating waves and quickly adopted by various other attackers as Websense® Security Labs™ has shown. This blog post detail some of the aspects of CVE-2012-0507 and how this exploit has been used in the wild.

The Java code first starts with the excerpt below:

The string "sobj" contains a stream of characters that trigger the vulnerability and force Java to render something which it usually wouldn't be allowed to. The string "8BCA ..." is obfuscated with an XOR key of 0x27 shown below:

After this string is de-obfuscated, it looks something like the image below:

We compared the exploit code used in the flashback campaign (above) with another instance in the wild that surfaced recently. Apparently, the attacker is using the exploit code provided by the metasploit framework.

The only difference between the flashback exploit code and the one used by metasploit is the bytecode array, where one is a signed byte array while the other is unsigned, as revealed below:

In our flashback sample, the string that triggers the vulnerability is "XOR-ed" with 0x27, while the string seen in the metasploit sample uses a signed byte array.

Lastly, the payload used by the flashback malware is a dropped Mach-O binary executable, while the metasploit exploit opens a listening TCP port shell pipe depending on what operating system the victim is on (This highlights the beauty of a design flaw as opposed to a vulnerability that corrupts memory). The code excerpt is shown below:

 Websense security solutions protect users from these kinds of exploits.