TalkTalk

badbad

[Pfui]

TalkTalk and its scanning bot have been discussed here* before, but it appears to be newly cloaking itself. (That, or I just caught on to it.) For example:

IPs:

89.242.96.191
89.242.100.205

UA:

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.30 (KHTML, like Gecko) Chrome/12.0.742.112 Safari/534.30

MORE (stupidly coded, log-spamming) UAs:

(TalkTalk Virus Alerts Scanning Engine)

(compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR ; http://www.talktalk.co.uk/products/virus-alerts/)

HuaweiSymantecSpider/[e-mail]+(compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR ; http://www.huaweisymantec.com/en/IRL/spider)

NOTES:

robots.txt? NO
Graphics? Externals? NO
403-Savvy? NO --

07/05 09:32:50/ 403
07/05 09:41:24/ 403
07/05 09:41:25/ 403
07/05 09:41:33/ 403
07/05 09:41:36/ 403
07/05 09:41:37/ 403

For more of its misbehaviors see:
Calling .js files directly [webmasterworld.com...]

FYI:

For your "centralised website blocking"**, tit-for-tat, convenience, the inetnum for the preceding "London TalkTalk Communications Limited" cloaked-UA+IP hits is --

89.241.0.0 - 89.243.255.255
(a.k.a.)
deny from 89.241.0.0/16
deny from 89.242.0.0/15

: )

*HuaweiSymantecSpider | Privacy, ethics [webmasterworld.com...]

**UK: TalkTalk To Offer Centralised Site Blocking [webmasterworld.com...]

[cyberdyne]

I am finally managing to get on top of these pests by blocking their UA('s) and IP's in .htaccess.

I also found them using the following:

62.24.181.
62.24.252.
80.40.134.

[dstiles]

They changed the UA some months ago - not that it made any difference to being blocked. :)

Huawaei is the company that processes (or processed?) the scraped page content. There is also a connection via ChinaCache USA, which is also worth blocking: that was the original test IP range.

In the opal "AV" range I block 62.24.128.0 - 62.24.255.255 and a few individual bot-like user IPs.

I block the range 80.40.134/24. It's listed as Tiscali (80.40/13), not Opal but it looks as if it has been bought out by TalkTalk. I wasn't aware it formed part of the AV scrape.

ChinaCache is at:
65.255.32.0 - 65.255.47.255
69.28.48.0 - 69.28.63.255

Opal's users in general generate a lot of trouble for web sites anyway, including virus attacks. They are not alone in this, though, nor the worst offenders.

[cyberdyne]

Having blocked all their main IP's and UA's they today visited using the following, again, mainly hitting .js files but two .html files also (no image or css).

IP/Hostnames:
radius3.bir.opaltelecom.net / radius4.bir.opaltelecom.net
UA: 
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)

[Pfui]

Am about to give 62.24.252.133 its own Killfile rule:

host-62-24-252-133.as13285.net
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)

Hits are typically faked URI=REF format, from robots.txt to .html and even a CGI script! (Latter was last straw, killfile-wise.) If this isn't a compromised TalkTalk bot machine, it's an infected user.

Scroll down to see the Comments -- StalkStalk indeed! -- ditto the UAs associated with the IP and others of its ilk: [projecthoneypot.org...]

[wilderness]

Pfui,
You may be able to use some kind of header check, similar to what was done when AVG began displaying user IP's a while back.

There's a couple of very long old threads.

[cyberdyne]

Here are the IP's I've collected recently (all confirmed as TalkTalk / tiscali / OpalTelecom) and all with the 'suspect' U-A's. If anyone else would like to add to the list or add any comments, feel free.

62.24.181.134
 62.24.181.135
 62.24.222.131
 62.24.222.132
 62.24.222.133
 62.24.222.134
 62.24.251.240
 62.24.252.133 
 62.24.252.199 
 80.40.134.103
 80.40.134.104
 80.40.134.120
 89.242.100.205
 89.242.96.191

Also, this is a very interesting read: [talktalkmembers.co.uk...]

Sorry folks but this represents a violation of section 3) of the Regulation of Investigatory Powers Act 2000 covering Lawful interception without an interception warrant.

(poor TalkTak members!)

[cyberdyne]

Well here's a strange one. Just had a genuine-looking visit from 'TalkTalk User' who searched for my UK-based site (which would not interest anyone not from the UK) using Google.turkey!

The IP hit my homepage (all associated files) then left. This was immediately followed by two hits on my robots from: 62.24.252.133

92.28.241.130
Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.0; Trident/5.0)
http://www.google.com.tr/search?sourceid=navclient&hl=tr&ie=UTF-8&rlz=1T4ADSA_trTR332TR332&q=SEARCHTERMREMOVED+uk

[wilderness]

quite unusual!

"ends with" Trident/5.0)

[cyberdyne]

How ironic; "TalkTalk helps keep customers safe with Homesafe".
There was just an advert on TV! (UK)

[dstiles]

As I said above - block 62.24.128/17 - none of it is true broadband.

If you want more on talktalk (and other) illegal accesses see nodpi.org. Vodafone and bluecoat seem to be the most recent baddies.

cyberdyne - 92.28.241.130 is a true opal/talktalk broadband IP. It could be that someone was checking your site in google.tr for SEO reasons or the IP may have been compromised and was being used as a proxy - I get a lot of that kind of thing but seldom from google referers so I'm guessing the former. Unless, of course, the UA is really a bad one in which case the referer may be forged.

Talktalk cannot keep its users safe because it does not check the web site until AFTER the original page download, so that one looks like an ASA job to me. The system can only work for second and subsequent visits to the same page, which on most sites is pointless since it's unlikely many people will visit most sites within a reasonable cache time. Or they could be visiting my sites, which always return a 403 for those hits. Never seems to matter. :)

[cyberdyne]

92.28.241.130 is a true opal/talktalk broadband IP. ....//.... the UA is really a bad one in which case the referer may be forged.

Thanks again, my thoughts were the same.

[Pfui]

I just had two hits from:

80.40.134.120
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)

Both were URI=REF, one to/from a transient page, one to/from robots.txt = Two fakes.

Again.

Amazing how a company paid to keep computers safe routinely appears to run unsafe computers.

This Just In:

Three more fake URI=REF hits from same IP (already blocked from the get-go), to three different CGI scripts, query strings removed (akin to hitting massively huge, off-limits but to me directory listings, thus setting my hair on fire). These guys and/or their botnet are gunning for Number One on my Annihilate Parade.

[dstiles]

I think the range 80.40.134/24 is a static DSL range within the main Opal/TalkTalk/Tiscali range. I do not think it's the ISP itself. At least one IP in the range - 80.40.134.145 - contains a web site which does not look like one belonging to the ISP.

[Pfui]

Are you saying that you think it's a real person? Because Project Honey Pot for the full IP [projecthoneypot.org...] shows one UA as being what I saw, and one other:

(TalkTalk Virus Alerts Scanning Engine)

That and the fake URI=REF hits are more than enough to make who/whatever nuke-worthy in my book.

[wilderness]

more than enough to make who/whatever nuke-worthy in my book.

Any of the Class A's mentioned in this thread are IMO "nuke-worthy" ;)

[dstiles]

Pfui - 80.40.134/24 - Possibly business lines. Because it's in honeypot does not mean it's a server.

(TalkTalk Virus Alerts Scanning Engine) takes up part of the 62.24.128/17 and the other part, as far as I'm concerned, can go whistle. It's all opal/talktalk backbone stuff.

[cyberdyne]

They appear to be visiting my site from links elsewhere too, not just directly.

[img705.imageshack.us...]

[dstiles]

The range 2.96/13 is a general broadband range, so I wouldn't expect to see the talktalk virus-scanner working on that, so probably cmments as before.

Your image does not show the full UA. Is it a standard browser or the talktalk scanner one?

[cyberdyne]

Is it a standard browser or the talktalk scanner one?

Here you go:

62.24.222.132 - "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)"

host-2-97-32-161.as13285.net - "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.0; GTB7.1; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; eSobiSubscriber 2.0.4.16; .NET CLR 3.5.30729; .NET CLR 3.0.30618; .NET4.0C)"

radius3.bir.opaltelecom.net - "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2)"

[Pfui]

dstiles, methinks you're cutting this outfit too much slack based on individual/business v. server maybes. And slack-cutting in the face of repeat bad-bot evidence is unlike you:)

The same IPs/Hosts are turning up again and again for many of us, and it looks like almost, if not all, are running -- or forging -- "(TalkTalk Virus Alerts Scanning Engine)" among other of TalkTalk's wacky UAs. For example, see the ones showing cyberdyne too much lovin' :

62.24.222.132: [projecthoneypot.org...]
radius3.bir.opaltelecom.net =
62.24.222.131: [projecthoneypot.org...]

And in my case, the offenders are again either compromised -- and not so coincidentally all forging TalkTalk -- or TalkTalk's got botnet URI=REF coding going on.

I'd rather block and give a probably-not-real person a graphic with e-mail address to contact than let TalkTalk RunRun AmokAmok AgainAgainAgain. Or do most of your real people hail from these same IPs? Or -- what am I missing that makes these slackers slack-worthy?

[dstiles]

Cyberdyne - those are standard MSIE browser UAs, although I always suspect eSobi users.

Having said that, 62.24.222.132 is in the scanner range and I have 62.24.128/17 blocked.

2.97.32.161 is in the middle of a large broadband block. The specific IP may be legitimate or it may be an infected machine (eg part of a botnet) but given that a botnet probably would not include eSobi in its UA I would say legit user.

radius3.bir.opaltelecom.net is again in the 62.24.128/17 block so bad.

My GUESS, if those three UAs were roughly within the same short period, would be a hit from the virus scanner (or other tool) followed by a legit user access followed by another scanner-like access.

One observation: it's interesting to see UAs coming from 64.24.128/17 that do not include "anti-virus scanner" tags. I don't think many IPs in that range are actual scanners though - just a handful - and the others could be something else (eg proxies). Whatever, it gets blocked here.

Pfui - not really. :)

The servers/scanners I block are as stated above. The 2.96/13 block is broadband - it's far too big anyway to be anything else but I know some of my customers are using IPs in that range.

Opal/talktalk are a source of bot-like activity, I agree, but it's partly because their users are rubbish at virus protection. And, I'll grant you, a few chancers trying it on with scrapers.

I have blocked 163 opal/talktalk IPs in the past few months, mostly in the 78.144/13 and 92.0/11 ranges: given the size of these ranges 163 does not seem to high. I think opal/talktalk show up so often simply because they own a large number of broadband IPs.

To reiterate: block 62.24.128/17 but give 2.96/13 access unless you do not want any UK traffic, like wilderness. :)

[cyberdyne]

I might add that those hits shown by the image I posted were the only hits in that time frame, ie: no image or css files were called, just my index file, favicon, robots and contact form page.

[grandma genie]

Another oddity with TalkTalk. I found this IP visiting my site today: 2.97.173.nn and 62.24.252.nnn. They were both from TalkTalk. The user agent was: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.112 Safari/535.1 and Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; InfoPath.2). So, I blocked their IP ranges. And immediately after blocking them a flurry of visitors with these IPs showed up: 66.220.153.nnn, 69.171.229.nnn, 69.63.181.nnn and these all had the same user agent: facebookexternalhit/1.0 (+http://www.facebook.com/externalhit_uatext.php). All these visitors were looking at the same file on my site. What do you make of that?
--grandma_genie

[dstiles]

2.97.173.nn is a standard DSL broadband line. I would not block this UNLESS you find bot-like activity on it.

62.24.252.nn is part of talktalk's infrastructure - ie their "bot" and housekeeping IPs. I block all of these ranges.

The first UA is google Chrome, the second one an MSIE-8 "browser". Depending on several other fields, plus the fact it came from the "bot" range, it could be almost anything.

Finding the MSIE-8 browser UA in your logs would be very common, although the number and names of the NET CLR fields often varies - it's a stupid kludge my MS but valid for all that.

66.220.153.nn and several 69.63.181.nn IPs are facebook's bot - valid, I would say, especially if someone has posted your URL on facebook.

The only one I would be interested in blocking there is the talktalk "bot" range. I would consider all others to be valid, given reasonable other evidence in headers.

[cyberdyne]

I've noticed that this same 'bot' now appears to be using Google Translate services in order to access - and scan - files unavailable directly to it/them due to .htaccess blocks.
I get a seemingly genuine hit from a TalkTalk user, immediately followed by attempted hits from the blocked IP(s) on my .js files only (oh, and robots.txt, which it always ignores), then a few seconds later hits on the very same files from Google Translate IP's.

[cyberdyne]

Had a visit today from another IP using the notorious 'HuaweiSymantecSpider'. Glad it was already blocked due to TalkTalk's antics.

web13.alexiadns.com
208.87.35.103
Nassau in Bahamas
Secure Hosting
alexiadns.com: The Leading Alexia DNS Site on the Net

U-A:
HuaweiSymantecSpider/[e-mail]+(compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR ; [huaweisymantec.com...]

[lucy24]

I've noticed that this same 'bot' now appears to be using Google Translate services in order to access - and scan - files unavailable directly to it/them due to .htaccess blocks.

Hm, interesting scheme. "We can't scan it ourselves so we'll let Google scan it for us." :)

You could do it yourself if you were more concerned about viruses than privacy. Never go to a site directly; have google translate it from English into English.

[keyplyr]

A wise webmaster learned to block translate & transcoder early in the game :)

[lucy24]

I wouldn't lose much by blocking transcoder. Could never figure out what the ### it's supposed to do anyway. Globally blocking translate would be a disservice to human users.* Mainly for one specific e-book-- but that's got to be 90% of my Translate visits, so not much point to blocking the rest.

:: wandering off to see if the Transcoder ever leads to anything useful ::


* It exists online in the original Spanish, but the illustrations were done by someone else and aren't nearly as pretty.