Clickthrough forensics

When you click on a link in your mail, where does it go? Are you sure?
HTTP Redirects
In most bulk mail sent the links in the mail aren’t the same as the page the recipients browser ends up at when they click on it. Instead, the link in the mail goes to a “click tracker” run by the ESP that records that that recipient clicked on this link in this email, then redirects the recipients web browser to the link the mail’s author wanted. That’s how you get the reports on how many unique users clicked through on a campaign.
In the pay-per-click business that’s often still not the final destination, and the users browser may get redirected through several brokers before ending up at the final destination. I walked through some of this a few years ago, including how to follow link redirection by hand.
HTTP Forensics
Evil spammers sometimes deploy countermeasures against that approach, though – having links that will only work once or twice, or redirects that must be followed within a certain time, or javascript within an intermediate page or any of a bunch of other evasions. For those you need something that behaves more like a web browser.
For serious forensics I might use something like wireshark to passively record all the traffic while I interact with a link from inside a sandboxed browser. That’s not terribly user-friendly to use or set up, though, and usually overkill. It’s simpler and usually good enough to use a proxy to record the web traffic from the browser. There are all sorts of web proxies, used for many different things. What they have in common is that you configure a web browser to talk to a proxy and it’ll send all requests to the proxy instead of to the actual website, allowing the proxy to make any changes it wants as it forwards the requests on and the results back.
For investigating what a browser is doing the most useful proxies are those aimed at either web developers debugging web apps or crackers penetration testers compromising web apps. Some examples are Fiddler (Windows), Cellist (OS X, commercial), mitmdump (OS X, linux, Windows with a little work), Charles (anything, commercial) or ZAP (anything).
I’m going to use mitmdump and Firefox. You don’t want to use your main browser for this, as the proxy will record everything you do in that browser while you have it configured – and I want to keep writing this post in Safari as I work.

Run mitmdump in a shell window, then configure Firefox to use it as a proxy (Preferences → Advanced → Network → Settings… → Manual proxy configuration) on 127.0.0.1 port 8080 for all protocols.

Visit a page and you’ll see mitmdump printing out all the URLs it’s accessing.

You’ll also see some errors, if it tries to load anything over TLS. Lets fix that before doing anything else. Visit mitm.it – not here, in the browser you’re using with the proxy – and click on the logo for your operating system. You’ll get a prompt to install a certificate – you’ll want to use it for “websites”. This certificate allows mitmdump to man-in-the-middle TLS connnections so it can record that traffic.

Finally, lets look at some spam

I’ve been getting some spam advertising T-Mobile being sent to a tagged email address that was used to register a domain that expired a decade ago and hasn’t been used since. Fairly scummy spam, but the branding and contact information looks like it’s being paid for by T-Mobile themselves.

The mail is being sent “from” info@t-mobile.emsecure.net, and all the links in the mail are in t-mobile.emsecure.net, so lets start there.

The base domain, emsecure.net, doesn’t appear in DNS at all, nor does www.emsecure.net. http://t-mobile.emsecure.net/ redirects to https://t-mobile.emsecure.net/ – which then returns a zero length file. Spammers who are trying to hide who they are.

So, we’re going to need to follow the actual links in the mail. The main clickthrough link looks like this:

https://t-mobile.emsecure.net/optiext/optiextension.dll? ID=3vu3xT_3CPZ_j6rc4uQh4sUS_7093dV7XpSiW9K 1u3OY8xvN%2BQbAkNTu%2BZfkh6hF0SSHlhh KjgLYcuXOlEg3dm1KLoTFM

I want to record the links visited, as well as displaying them, so I run “mitmdump -w tmobile.log” to record the output to a file. Then I visit that long, ugly link in Firefox.
And then I’m surprised. The link doesn’t redirect anywhere. Instead it goes to a T-Mobile branded landing page hosted on the t-mobile.emsecure.net domain. And all the links on this page go to URLs that are https://t-mobile.emsecure.net/optiext/optiexension.dll?id=string_of_gibberish too.
That’s good, though. This is exactly why using a real browser with a recording proxy is more convenient than trying to trace this by hand. I can see that there are just a few call-to-action links on this page. I pick the “Find out more” link and click on it. This time mitmdump shows me that the gibberish emsecure link redirects immediately to the advertiser:

https://business.t-mobile.com/contact-a-rep.html? cmpid=DMA_EM_UC9ETF09_SHDQJRY9M11888

So there aren’t multiple levels of resale of clicks going on in this case – T-Mobile are either paying the spammer to send the spam or buying leads directly from them. And I have all the 2.5 megabytes of traffic sent to and from my browser recorded in “tmobile.log” if I need to do further analysis, or present it as evidence, in the future – even if the site itself is removed.
Conclusion
The main conclusion is that a proxy can be a very useful tool for digging in to where a link goes, and who is responsible for it.
In this specific case it’s enough to show that T-Mobile (or perhaps an individual T-Mobile sales rep, but it seems really unlikely) are the responsible party for the spam, and they’re probably buying leads from the Belgian spammer who sent the spam. Digging a little deeper, the spammer is Selligent (who’ve just merged with StrongView, née StrongMail. You guys used to be cool.)
Whether it’s lead purchase, list purchase or epending – if you end up sending spam to an email address harvested from a domain registration at least a decade ago you’re buying terrible, terrible data. This is why you’ re hitting spamtraps, causing complaints and getting blacklisted.
 

Related Posts

Cryptography and Email

A decade or so ago it was fairly rare for cryptography and email technology to intersect – there was S/MIME (which I’ve seen described as having “more implementations than users”) and PGP, which was mostly known for adding inscrutable blocks of text to mail and for some interesting political fallout, but not much else.
pgp
That’s changing, though. Authentication and privacy have been the focus of much of the development around email for the past few years, and cryptography, specifically public-key cryptography, is the tool of choice.
DKIM uses public-key cryptography to let the author (or their ESP, or anyone else) attach their identity to the message in a way that’s almost impossible to forge. That lets the recipient make informed decisions about whether to deliver the email or not.
DKIM relies on DNS to distribute it’s public keys, so if you can interfere with DNS, you can compromise DKIM. More than that, if you can compromise DNS you can break many security processes – interfering with DNS is an early part of many attacks. DNSSEC (Domain Name System Security Extensions) lets you be more confident that the results you get back from a DNS query are valid. It’s all based on public-key cryptography. It’s taken a long time to deploy, but is gaining steam.
TLS has escaped from the web, and is used in several places in email. For end users it protects their email (and their passwords) as they send mail via their smarthost or fetch it from their IMAP server. More recently, though, it’s begun to be used “opportunistically” to protect mail as it travels between servers – more than half of the mail gmail sees is protected in transit. Again, public-key cryptography. Perhaps you don’t care about the privacy of the mail you’re sending, but the recipient ISP may. Google already give better search ranking for web pages served over TLS – I wouldn’t be surprised if they started to give preferential treatment to email delivered via TLS.
The IETF is beginning to discuss end-to-end encryption of mail, to protect mail against interception and traffic analysis. I’m not sure exactly where it’s going to end up, but I’m sure the end product will be cobbled together using, yes, public-key cryptography. There are existing approaches that work, such as S/MIME and PGP, but they’re fairly user-hostile. Attempts to package them in a more user-friendly manner have mostly failed so far, sometimes spectacularly. (Hushmail sacrificed end-to-end security for user convenience, while Lavabit had similar problems and poor legal advice).
Not directly email-related, but after the flurry of ESP client account breaches a lot of people got very interested in two-factor authentication for their users. TOTP (Time-Based One-Time Passwords) – as implemented by SecureID and Google Authenticator, amongst many others – is the most commonly used method. It’s based on public-key cryptography. (And it’s reasonably easy to integrate into services you offer).
Lots of the other internet infrastructure you’re relying on (BGP, syn cookies, VPNs, IPsec, https, anything where the manual mentions “certificate” or “key” …) rely on cryptography to work reliably. Knowing a little about how cryptography works can help you understand all of this infrastructure and avoid problems with it. If you’re already a cryptography ninja none of this will be a surprise – but if you’re not, I’m going to try and explain some of the concepts tomorrow.

Read More

TWSD: Hiding the opt-out


This is an actual opt-out link that came in a recent email. Sadly, this is a real company, listed on the NYSE sent by a major ESP.
 

Read More

TWSD: Mail known spam trap addresses

One of the things we all “know” is that if spammers get their hands on spamtrap addresses then they’ll stop sending mail to those addresses. This is true for a lot of spammers, but sadly it’s not true for all.
I don’t think it’s any secret that I consult for all types of mailers, from those who just need a little tune up to those who want me to help them avoid filters and blocking. During some of these consulting projects, I use my own spam folder as research and provide information on the spam that I am receiving from them.
A few years ago I was working with a company who hires a lot of different affiliates to send acquisition email. A few of their affiliates had really poor practices and they were trying to figure out which affiliates were the problem. I handed over a number of mails from my personal spam traps, in order to help them identify the problem affiliate.
I told them, and their affiliate, what my spamtrap addresses were. And, for many years I stopped receiving that particular spam. But, over the last few weeks I’ve seen a significant uptick in spam advertising my former client.
I’m certainly not trying to convince anyone that handing over spamtraps is a good thing. But there is at least some evidence out there that they’re not even competent enough to permanently remove traps. I really have to wonder at how sloppy some marketers are, too, that they’ll hire spammers and not at least hand over a list of addresses they know are bad addresses to mail.
I really thought spammers were smarter than that. I am, apparently, wrong.
EDIT: Of course, mailing this spamtrap gets them nothing but a little ranty blog post here. It doesn’t result in blocking, or disconnection from their ISP or their ESP or anything else. I suspect if there was actually an affect, like, say, I started forwarding this mail to Spamhaus or other filtering companies, they might stop mailing this address. Anyone want a 20 year old, slightly used spam trap?
 

Read More