Forum Moderators: open

Message Too Old, No Replies

Multiple-IP hits

botnet activity?

         

dstiles

11:58 pm on Nov 30, 2009 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



Following up on an odd 404 querystring I discovered the following weird behaviour.

The first line in the log showed a valid page request from 94.76.69.n. The page, pagename.asp, included a bot trap in the header.

The next log line, which triggered the 404, showed:
/pagename.asp/x/trapname.asp from IP 94.76.69.n

where x is a target trap folder and trapname a trap page in that folder linked from the original page's header, as noted. It obviously picked up both the pagename and the page's bot-trap URL and combined them. This in itself is odd and triggered an IP ban. This and all subsequent hits on the site from that IP and others returned 403.

The weird bit is that the resulting 404 occurred three times, once from the original IP, once from 123.125.156.nnn and once from 120.28.64.nn, all within about 3 seconds (all trapped by IP due to previous or newly trapped bad behaviour). The 404 querystring was exactly the same in each case.

Subsequent hits were all grouped in threes. The above IPs were involved seemingly at random together with a few others, mostly from APNIC ranges but an Amazon AWS (174.129.216.nnn) IP as well (all Amazon AWS IPs are permanently blocked here). Total IPs involved: 21

At no time was there a referer so I have no idea where the hits originated. They did not hit all pages but they did hit all of the forms. My guess is that they came in on the back of previous (undetected, which would be unusual) scans or from an SE of some kind. The original (random?) page was followed by the home page then by another (different) trap URL. (I often see scans from banned IPs that continue seemingly at random despite 403s.)

The whole session logged the same session cookie, which in my experience is unusual for bots, especially across varying IPs (I assume the IPs were part of a botnet). The session cookie helped trap accesses by the other IPs involved.

User-Agent in all cases:
Opera/9.70 (Linux i686 ; U; zh-cn) Presto/2.2.0

No headers set except HTTP_ACCEPT (but to what is not logged).
Note gap in "Linux i686 ;"

Presto seems to be an Opera engine. My linux version of Opera is 9.80 with Presto 2.2 (can't get it to update to 10.10) but it includes X11 in the UA (this doubtless changes according to linux flavour so probably no indication of trappability).

Total pages hit: 20 (approx half of site's pages; most use querystrings but none were included in the hits).

enigma1

10:36 am on Dec 1, 2009 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Do you have some sort of custom HTML tag in the <head> section of the page? I am not sure what you mean there, how it is linked from the header, via the <link> tag? Or is it another header emitted with the 404 that has a link?

Anyways when I check my serverlogs for the IP range 123.125.156.n you mentioned, I saw something perhaps close to what you saw. A bunch of requests within a couple of minutes with exactly the same invalid query coming from various ips including the 123.125.156.n range.

The referrers in my case were showing the query. All queries identical around 10 IPs were involved (compromised routers and servers). The query itself indicates an RFI but the content seems to pull part of the URL from a redirect I emit in case of invalid headers. The UA in all cases read:

"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; Maxthon; .NET CLR 1.1.4322)"

Here are the details:

174.142.104.n - - [22/Nov/2009:12:15:10 -0500] "GET /sorry/?continue=http://........
174.142.104.n - - [22/Nov/2009:12:15:12 -0500] "GET /sorry/?continue=http://........
174.142.104.n - - [22/Nov/2009:12:15:16 -0500] "GET /sorry/?continue=http://........
64.27.19.n - - [22/Nov/2009:12:15:20 -0500] "GET /sorry/?continue=http://........
174.142.104.n - - [22/Nov/2009:12:15:21 -0500] "GET /sorry/?continue=http://........
200.177.228.n - - [22/Nov/2009:12:15:22 -0500] "GET /sorry/?continue=http://........
123.125.156.n - - [22/Nov/2009:12:15:24 -0500] "GET /sorry/?continue=http//........
64.27.19.n - - [22/Nov/2009:12:15:34 -0500] "GET /sorry/?continue=http://........
78.47.189.n - - [22/Nov/2009:12:15:35 -0500] "GET /sorry/?continue=http://........
64.27.19.n - - [22/Nov/2009:12:15:40 -0500] "GET /sorry/?continue=http://..........
200.27.164.n - - [22/Nov/2009:12:15:54 -0500] "GET /sorry/?continue=http://.........
200.238.83.n - - [22/Nov/2009:12:15:56 -0500] "GET /sorry/?continue=http://..........
123.125.156.n - - [22/Nov/2009:12:15:57 -0500] "GET /sorry/?continue=http://..........
41.215.34.n - - [22/Nov/2009:12:16:09 -0500] "GET /sorry/?continue=http://..........
174.142.104.n - - [22/Nov/2009:12:16:10 -0500] "GET /sorry/?continue=http://..........
41.215.34.n - - [22/Nov/2009:12:16:25 -0500] "GET /sorry/?continue=http://..........
174.142.104.n - - [22/Nov/2009:12:16:36 -0500] "GET / HTTP/1.1" 301 5 ..............
150.70.84.n - - [22/Nov/2009:12:17:37 -0500] "GET /sorry/?continue=http://............

If you notice the 174.142.104.nnn range bounced back after the first redirect and got another from the domain root this time but again the referrer was the same.

dstiles

11:30 pm on Dec 1, 2009 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



The header has a link that traps quite a few baddies. How it's implemented I won't say. :)

Your log looks as if the pages were always the same: is that correct? Mine were ALWAYS three hits on one page then move to the next page for three more. There was never a referer.

enigma1

3:06 pm on Dec 2, 2009 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member



Yes, the query is identical. But the pattern repeated on several occasions with different IPs. Seems the bots get confused from the redirects or something because they try to include a url with regular content not some malicious script in the particular situation.

Now without the redirects it would been a different store I believe I would see one of the regular RFIs.