Uncovering a code injection attempt via user-agent

After a long time, I took some time to analyze results of monitoring I put in place for my website. The data is collected from an apache module to track user agent string that were scanning for "Wordpress" looking URL's in my webserver..   I just pulled some recent ones to see if code injection is still being attempted! Let's see

The very first hit is an interesting code injection technique. If you had any type of  cgi scripts or PHP scripts that got this user-agent, and the scripts did not normalize this user-agent field while either parsing, logging or passing this data to another program, you have a little malware ready to explode.

So what can these type of malware do and why do the hackers adopt this type of technique?  I am going to let you answer that question as you watch me tease this apart.

Step 1: Malicious script is somehow executed on your host.

The malicious scripts first of all wants to send back a nice "SUCCESS" to the hacker and then proceed to the next steps.  If another instance of "ss" malware is running - please kill it and lets clean up all the temporary directory /var/tmp, tmp, etc. Oh don't forget the memory temp like /dev/shm. Lets try to download using wget or curl or lwp-donwload at least one of these is likely to be installed and be in the default path of all Linux system, a "tar ball" of malware from our friends sites.  The malware now has a few components when you untar it, you see (ah! hidden directory ".a44s").  Lets where what all this malware now contains.

The files in here are basically shell scripts and a binary that is designed to become your background daemon to steal credentials and pass it on to hackers to maintain access. The first script that will execute is shell script "ss" (top left) which basically executes the "r" malicious code (does not anything if you are running a mac!),
what you see in the right hand side starts executing, basically more things to download from xaa to xln using a sequence loop and falling back between wget, curl and lwp-download.  The left side file of "pass.text" basically is used as the configuration file with default password for open shared, devices (embedded devices) and network devices (cisco, etc).  The code shown below basically efficiently runs 1000 threads of the executable "b" that will run to gather all possible data and send it back via ftp to the hacker.

This part of code is all about "maintaining access" if you know the SANS generalized attacker's methodology.

Conclusion
There is a lot more I can write to tell you about the malicious code and the approach of the hacker.  I think the story line here is plenty representative of current days malware targeting your websites, hosted sites with some clever techniques.  There are a few general observations I want to leave you with

• Code inject still a good attack vector to protect against your publicly available content.
  (shell script, javascript, iFrame or SQL can be bundled into this high level category. )
• If you use web application firewall or web acceleration, use this to neutralize and remove abnormal characters in fields like user-agent and in certain cases to query string and post variables. 
• If you don't use one, you can temporarily use some configuration on apache/nginx/IIS to block this.
• If infection is successful, today's malware has multiple components, phases, downloading more components as it establishes its presence or its ground.  This makes clean up very difficult.
• Lateral movement of hackers to gain access to other resources internally causes more havoc and trouble for cleanup.  Leaving default password to what you think is isolated from the internet is risky.

More thoughts?