Website redirectors

[Tim P]

This phishing link was in one of my spams:

http://www.google.com/url?q=http://www.goo...SLR4KqaQhIp9e9y

which redirects to:

http://mofklqbc4f.da.ru/3fi96g6di13232di79SLR4KqaQhIp9e9y

But I'd really like to know how to get this without resorting to following a browser link

and looking at the resulting packet data log.

SC did not determine this link. It wouldn't go beyond Google.

[Wazoo]

I'd rather try to deal with the link as seen in the actual spam .. Tracking URL please ... But, yes, the SpamCop parser doesn't chase down re-directions. For decoding fun, try http://www.gooby.ca/dec.htm for a look at the various methods out there to obfuscate things, noting that some of your sample is also based on Google's internal handling.

[eaolson]

I'd rather try to deal with the link as seen in the actual spam .. Tracking URL please ...  But, yes, the SpamCop parser doesn't chase down re-directions. 

19153[/snapback]

Actually, it does. If you put just the obfuscated URL into the spam submittal box and process it, it will strip out most URL redirects, and deobfuscate the URL. It won't find 302 redirects, but that doesn't seem to apply to the OP's problem.

[Wazoo]

I left lots of stuff out of the previous response, again rather wishing to see the link in context. In the specific case offered, there are several issues involved, to include that some obfuscarion works on "this" browser, but not "that" browser ... not known if there was any java scri_pt going on that may have impacted the link offered up, etc. etc. ....

Agreed that in this case, there is an attempt to decode the URL using the single-line parse, but noting that the single-line is a different bit of code that that used while parsing a whole spam, so there are differences in actions and results at times. In this case, here's the attempted de-obfuscation from the single-line parser;

Parsing input: http://www.google.com/url?q=http://www.goo...SLR4KqaQhIp9e9y

Percent unescape: http://www.google.com/url?q=http://www.goo...gle.com/url?q=H %54%%374%%350%%33a%2f /mofklqbc4f%%32e %%344%%361 %%32E%%352 U /%%333fi96g6di13232di79SLR4KqaQhIp9e9y

host 66.102.7.99 (getting name) no name

Google redirection = http://www.google.com/url?q=http://www.google.com/url?q=H T%74%50%3a/ /mofklqbc4f%2e %44%61 %2E%52 U /%33fi96g6di13232di79SLR4KqaQhIp9e9y

Percent unescape: http://www.google.com/url?q=http://www.google.com/url?q=H TtP:/ /mofklqbc4f. Da .R U /3fi96g6di13232di79SLR4KqaQhIp9e9y

host 66.102.7.99 (getting name) no name

Google redirection = http://www.google.com/url?q=H TtP:/ /mofklqbc4f. Da .R U /3fi96g6di13232di79SLR4KqaQhIp9e9y

host 66.102.7.99 (getting name) no name

Google redirection = H TtP:/ /mofklqbc4f. Da .R U /3fi96g6di13232di79SLR4KqaQhIp9e9y

Unescaped: http://www.google.com/url?q=http://www.goo...gle.com/url?q=h %54%%374%%350%%33a%2f /mofklqbc4f%%32e %%344%%361 %%32e%%352 u /%%333fi96g6di13232di79slr4kqaqhip9e9y

Unescaped: http://www.google.com/url?q=http://www.goo...gle.com/url?q=h T%74%50%3a/ /mofklqbc4f%2e %44%61 %2e%52 u /%33fi96g6di13232di79slr4kqaqhip9e9y

Unescaped: http://www.google.com/url?q=http://www.goo...gle.com/url?q=h TtP:/ /mofklqbc4f. Da .R u /3fi96g6di13232di79slr4kqaqhip9e9y

host 66.102.7.99 (getting name) no name

Obfuscated hostname

68 a0 74 74 70 3a 2f a0 2f 6d 6f 66 6b 6c 71 h ttp:/ /mofklq

62 63 34 66 2e a0 64 61 a0 2e 72 a0 75 a0 2f bc4f. da .r u /

33 66 69 39 36 67 36 64 69 31 33 32 33 32 64 3fi96g6di13232d

69 37 39 73 6c 72 34 6b 71 61 71 68 69 70 39 i79slr4kqaqhip9

65 39 79 e9y

Cannot resolve H TtP:/ /mofklqbc4f. Da .R U /3fi96g6di13232di79SLR4KqaQhIp9e9y

No valid email addresses found, sorry!

Chasing that down, one finds;

10/23/04 15:57:06 Slow traceroute mofklqbc4f.da.ru

Trace mofklqbc4f.da.ru (213.59.0.84) ...

158.43.188.217 RTT: 130ms TTL: 96 (ge1-0.gw1.lnd8.gbb.uk.uu.net ok)

146.188.66.50 RTT: 178ms TTL: 96 (rtcomm-gw.customer.ALTER.NET ok)

217.106.7.232 RTT: 176ms TTL: 96 (msk-dsr7-ge0-1-0-0.rt-comm.ru bogus rDNS: host not found [authoritative])

213.59.0.84 RTT: 179ms TTL: 50 (mofklqbc4f.da.ru ok)

10/23/04 15:39:57 Browsing http://mofklqbc4f.da.ru/3fi96g6di13232di79SLR4KqaQhIp9e9y

Fetching http://mofklqbc4f.da.ru/3fi96g6di13232di79SLR4KqaQhIp9e9y ...

GET /3fi96g6di13232di79SLR4KqaQhIp9e9y HTTP/1.1

Host: mofklqbc4f.da.ru

HTTP/1.1 302 Found

Date: Sat, 23 Oct 2004 16:42:49 GMT

Server: Apache/1.3.9 (Unix) da.ru/1.2/DeathMatch

Location: http://yahoo-com-------i.nm.ru/

<HTML><BODY><A HREF="http://yahoo-com-------i.nm.ru/">http://yahoo-com-------i.nm.ru/</A></center></BODY></HTML>

which then gets;

10/23/04 15:55:08 Slow traceroute yahoo-com-------i.nm.ru

Trace yahoo-com-------i.nm.ru (212.48.140.151) ...

194.186.157.237 RTT: 182ms TTL: 96 (cat02.Moscow.gldn.net fraudulent rDNS)

194.186.0.130 RTT: 177ms TTL: 96 (ORC-gw.Moscow.gldn.net ok)

212.48.140.151 RTT: 179ms TTL: 41 (flock0vhs.newmail.ru ok)

10/23/04 15:42:09 Fetching http://yahoo-com-------i.nm.ru/

Fetching http://yahoo-com-------i.nm.ru/ ...

GET / HTTP/1.1

Host: yahoo-com-------i.nm.ru

<META HTTP-EQUIV="Refresh" CONTENT="0; URL=http://help.yahoo.com/help/edit/context/context-02.html">

<scri_pt language=java scri_pt>

// ensure top window

if (window != top)

{

top.location = window.location;

}

</scri_pt>

<title></title></HEAD>

<BODY bgColor=#ffffff onload="window.open('welcome3.html', 'yaheit', 'top=305,left=250,width=270,height=190,toolbar=no,location=no,scrollbars=no,resizable=no')">

</BODY>

Which I'm not going to go any further on, not enough time now for tracking down the DNS issues involved .... http://www.ripn.net:8080/nic/whois/whois.cgi shows "No entries found for the selected source(s)" for a query on both yahoo-com-------i.nm.ru and mofklqbc4f.Da.RU

[Tim P]

I'd rather try to deal with the link as seen in the actual spam .. Tracking URL please ...  But, yes, the SpamCop parser doesn't chase down re-directions.  For decoding fun, try http://www.gooby.ca/dec.htm for a look at the various methods out there to obfuscate things, noting that some of your sample is also based on Google's internal handling.

19153[/snapback]

sorry about that.. I have a specimen that just came in. This report was generated from an altered phishing spam I had manually parsed. I altered it to munge some identifying info in the header. The SC parser wasn't catching it and inserting the 'x'.

http://www.spamcop.net/sc?id=z685201981z1c...b1755d0fd41018z

I had resorted to the "click here" link to see the url.

Not advisable for any phishing or spam link...however, the outbounds were diverted to my localhost..

eDexter proves very handy for just this purpose.

-N "rogue- nets-in-Asia and Europe" and " -U *.* "rules do the trick nicely.

I dont know of a simpler and safer way decode obfuscated url/phish/spamsite- "click here"- links.

But...I'm no expert on these matters and someone may point out that there is still some risk in using this method.

[Tim P]

I'd rather try to deal with the link as seen in the actual spam .. Tracking URL please ...  But, yes, the SpamCop parser doesn't chase down re-directions.  For decoding fun, try http://www.gooby.ca/dec.htm for a look at the various methods out there to obfuscate things, noting that some of your sample is also based on Google's internal handling.

19153[/snapback]

Thanks, this is helpful

[ankman]

I'd rather try to deal with the link as seen in the actual spam .. Tracking URL please ... But, yes, the SpamCop parser doesn't chase down re-directions. For decoding fun, try http://www.gooby.ca/dec.htm for a look at the various methods out there to obfuscate things, noting that some of your sample is also based on Google's internal handling.

This post is quite old (10 years), but due to the recent Google redirectors I would like to pick it up again, because I couldn't find a (satisfying) answer.

Why doesn't Spamcop when parsing URLs in spam follow them and pull out URLs following.

A spam today had the URL goo.gl/GqxowX and I parsed it manually (wget) and get

Resolving goo.gl (goo.gl)... 173.194.43.104, 173.194.43.102, 173.194.43.99, ...

Connecting to goo.gl (goo.gl)|173.194.43.104|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://armadaglobalinc.com/fl/?coment/piso...itamadeira.html [following]

--2014-03-09 11:28:08-- http://armadaglobalinc.com/fl/?coment/piso...itamadeira.html

Resolving armadaglobalinc.com (armadaglobalinc.com)... 173.201.97.1

Connecting to armadaglobalinc.com (armadaglobalinc.com)|173.201.97.1|:80... connected.

HTTP request sent, awaiting response... 301 Moved Permanently

Location: http://thegenericsrx.eu/?fl/ [following]

--2014-03-09 11:28:20-- http://thegenericsrx.eu/?fl/

Resolving thegenericsrx.eu (thegenericsrx.eu)... 178.19.107.91

We have 2 targets. The latter is the spammer itself or a spammer friendly ISP though. armadaglobalinc.com (173.201.97.1) is Godaddy.

Often those URLs are compromised sites under control of "good" ISP or web site hosters. Umm, not sure if they quality as "good", but I often see Bluehost, Godaddy and such. Because of Spamcop not following redirects (forwarders) I tend to manually report them.

Sholdn't be hard to implement? Or does it cause a too high load on Spamcop's systems if it would do it?

Wouold IMO be nice to have this feature.

[turetzsr]

Hi, ankman,

...In brief, I believe the answer to your question is that link parsing is a relatively "expensive" part of the spam parsing process and handling spamvertized links is merely "gravy" from the perspective of the SpamCop parser's main goal, which is to identify the spam source. See the SpamCop FAQ (links to which appear towards the top of each SpamCop Forum page) labeled "SpamCop reporting of spamvertized sites - some philosophy." Also my reply in SpamCop Forum Topic "IP not found" may be of interest to you as an alternative.