Jump to content

URI "discarded as fake"


Recommended Posts

Not too fussed since it is mostly just "spamvertized" links but I'm seeing a lot of this lately in botnet spam, like in

http://www.spamcop.net/sc?id=z5502431053za...39fc1ea81d036ez

Finding links in message body

Parsing text part

Resolving link obfuscation

http://www.keygenerics.com

Tracking link: http://www.keygenerics.com/

No recent reports, no history available

Host www.keygenerics.com (checking ip) IP not found ; www.keygenerics.com discarded as fake.

www.keygenerics.com is not a routeable IP address

Cannot resolve http://www.keygenerics.com/

Which is utter nonsense which is to say I can't believe anyone should be having trouble resolving this or most like it at the time of parsing, not ALL the time or practically so. If SpamCop really is having difficulty (various examples seem to be in various networks) then the question needs to be asked "Why?". If it is actually that SC can't be bothered - there is an unending succession of these hostnames (ingenuity in coming up with new names verges on the breathtaking), probably just redirecting to one or more central points - then that would be quite understandable but a more forthright/truthful message from the parser would be helpful for those who might want to take reporting further using their own resources. Not as if the parser-reporting system seems to be hard-pressed lately by comparison with historical rates of processing (admitting that may not be the only consideration).

Just saying/wondering ... insights welcome, this goes way beyond the usual, occasional failures to resolve AFAICT. Maybe the domain nameservers (NS1.DRUGSTOREPHARMPHARMACY.COM, NS2.TUGH.RU in this instance at least) are blocking SC, is it as simple as that? Can SC really be that easily thwarted? A virtual selective "dark internet"? How can that be allowed? (anyone else might be "arbitrarily" excluded).

Link to comment
Share on other sites

  • 3 weeks later...

Hi Farelf.

How do you know the parser is incorrect when it says the URLs don't "resolve?"

Are you thinking that it would be illogical for the spam to include a URL that doesn't resolve? Or perhaps, you're plugging the "un-resolvable" URLs into your browser, and you're raising an active website without any problem?

You work too hard.

Thanks,

-neil-

Link to comment
Share on other sites

...

How do you know the parser is incorrect when it says the URLs don't "resolve?"...

Hi Neil,

I wouldn't touch a spamvertized site with a barge-pole, let alone visit one with my browser. I use IDServe.exe (from https://www.grc.com/id/idserve.htm) for such risky business and even that might be be pushing things in terms of what even that minimal query might reveal about "me" to "them".

Instead of that, any DNS lookup tool will resolve those domains, taking that last example (http://www.spamcop.net/sc?id=z5512860706z8...32f64e85ca2788z)

C:\Documents and Settings\Admin>nslookup www.genericswelnesspharmaceutical.com 8.8.8.8

Server: google-public-dns-a.google.com

Address: 8.8.8.8

Non-authoritative answer:

Name: www.genericswelnesspharmaceutical.com

Address: 213.229.101.252

C:\Documents and Settings\Admin>nslookup genericswelnesspharmaceutical.com 8.8.8.8

Server: google-public-dns-a.google.com

Address: 8.8.8.8

Non-authoritative answer:

Name: genericswelnesspharmaceutical.com

Address: 213.229.101.252

I use IPNetInfo a lot (http://www.nirsoft.net/utils/ipnetinfo.html), that resolves the above and does the RIPE Database lookup to find network contact details etc. (in this case SpamCop declines to use the abuse address found - "Reports disabled for abuse[at]as29550.net" - hopefully for good reason).

One could also resolve it with http://centralops.net/co/DomainDossier.aspx which can provide all sorts of lookup information, including registrar and registrant contacts (the latter being allegedly some lady operating from at a non-existent street address in a suburb not far from mine - with a South Australian telephone number, some 2,500 km away from the suburb in question. They consistently lie, do spammers). Domain Dossier can also do a service scan and that reveals no common services are supported at the IP address - it is probably just a "redirector".

Another good tool is robtex - http://dns.robtex.com/genericswelnesspharmaceutical.com.html#result - that will show the names of other domains shared by the server. In this case it is only a handful but, since they are probably all "new", robtex possibly hasn't had time to build the complete picture.

Robtex also reveals the nameservers for the domain (as does DomainDossier), they are ns1.genericswelnesspharmaceutical.com and ns2.genericswelnesspharmaceutical.com which resolve to 220.179.72.106 and 189.19.3.170 respectively and which have the server names of (well, none for the first but in CHINANET Anhui province network) and 189-19-3-170.dsl.telesp.net.br. SpamCop (supposedly) can't reach those, the rest of the world can.

[edit] To be fair, in-addr.arpa is a trifle brusque when asked for the PTR record of the primary nameserver:

C:\Documents and Settings\Admin>nslookup -type=ptr 220.179.72.106 8.8.8.8

Server: google-public-dns-a.google.com

Address: 8.8.8.8

*** google-public-dns-a.google.com can't find 106.72.179.220.in-addr.arpa.: Non-existent domain

C:\Documents and Settings\Admin>nslookup -type=ptr 189.19.3.170 8.8.8.8

Server: google-public-dns-a.google.com

Address: 8.8.8.8

Non-authoritative answer:

170.3.19.189.in-addr.arpa name = 189-19-3-170.dsl.telesp.net.br

C:\Documents and Settings\Admin>

One or both of those may be hacked. Spammers don't pay for anything they can steal and many registrars are too slack, idle and indolent to know when anything is amiss or even to react when given proof that such is the case (IMO).[/edit]

And, exercising enormous if uncharacteristic restraint, I shall refrain from replying to your "You work too hard" comment, not even to indicate the irony of it :D

Steve S

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...