There are far better things than being phished, like writing about how not to get phished. Michael P. Kassner reviews a research paper that provides amazing insight into a successful phishing operation.
In the spring of 2009, I became someone's phishee. You'd think a person who writes about IT security would know better. But I didn't. Of all the emotions I felt, embarrassment was by far the worst. Especially since, only days earlier, I penned the article, "Phishing: Is that website real or not?"
While in my "poor me" funk, I happened to remember a well-worn cliché, and decided I might as well make the proverbial lemonade instead of sulking. Or better yet, ask the experts how to avoid digital con artists like the one I bumped into, and then write about it.
To that end, I'd like you to meet someone I wish I'd known back then. His name is John Brozycki. He understands phishing, every sordid detail; his credentials: a bucket full of GIAC certifications, years of experience, and a willingness to share what he knows.
Ironically, right around the time I was phished, John was writing "Inside a Phish," a paper about one particular phisher, his escapades, and eventual take-down by authorities. It is one of the best commentaries I've read on the inner workings of a successful phishing operation.
What makes this paper valuable was John's ability to piece together details of how a phishing attack was carried out using information from both the phisher and the phishee:
I had often wished I could be a "fly on the wall" and see how a phish operated, understanding that it wouldn't represent all phishers any more than watching one bank heist would represent all bank robbers. Regardless, I knew there could be a lot of information in the emails, and I found myself immediately asking if I could study the data.
It took a while, several years in fact, before John finally obtained permission to look at the case records involved in the investigation:
I was told I couldn't while it was an active investigation. After a few years, my periodic requests finally got a positive response. I learned I could come in to review the data, agreeing not to use details such as names, IP addresses, and organizations. I wanted to study the methods and workings of the phish.
John also explained why it was important to audit the involved financial institution:
As I started reviewing the information, I also began thinking about the financial institution this phish was perpetrated against. What were they doing and how were they reacting while the phish was in play? What was done effectively and what could have been done better?
Before we get to the details of John's investigation, I thought it would be best to explain the rudiments of phishing. A phish consists of two basic components: requests and responses.
Request: The intended victim receives an email (The anatomy of a scam email message) — supposedly from an organization (usually financial) that the intended victim belongs to — carrying a request composed with one thing in mind — get the victim to respond. The following slide is an example of such a request ( Both slides courtesy of Cadzow.com).
Response: The victim decides whether to click on the link in the email or not. If the victim clicks the link, the following phishing webpage opens displaying yet another request.
As you can see, the phisher is attempting to obtain sensitive financial information. And if the victim responds, the phisher wins. According to my source (unverified), this phishing campaign fooled more than a few Citibank members. Now let's see what John's investigation turned up.
As part of the agreement with law enforcement, John promised not to reveal any discernible information; so meet Bob — the nasty phisher — and GIAC Bank — the copycatted financial institution. By agreeing, John was able to look at the phishing kit and email conversations Bob had with other operatives.
For those not familiar with phishing kits, it is an archive of all the files required to make the phishing website. John mentions why dissecting a phishing kit is helpful:
When you can get it [phishing kit], it can provide a wealth of information. Opening the kit and reviewing the source code from the PHP scripts, I found the email address where the phished data was being sent.
I thought it might be interesting to look at a few of the files John found in the GIAC Bank phishing kit:
- Config.php configures the hosting URL, the phisher's blind-drop email address where account information is to be sent, and the name of the financial institution being targeted.
- Index.php creates the front page asking for logon information. After entering the appropriate information and clicking on the submit button, the data is posted to Login.php.
- Login.php sets up the web form that requests the following: card number, expiration date, cvv2 (number printed on the card's backside), and PIN.
A fake website similar enough to fool a majority of people, asking for sensitive financial account information — what's not to like? To make it even more official looking, Bob made sure the phishing website gave the impression of having the correct digital certificates.
The GIAC Bank displays a Secured by Verisign image on the bank's webpages. Bob requested the element also be on the phishing website — no small task as John explains:
GIAC Bank uses Verisign for the site's digital certificate, and runs an element on its page provided by Verisign to help assure visitors that the page they are viewing is both authentic and secure. The phish has substituted an Adobe Shockwave file with an animation that mimics the real Verisign element (Figure 11). This is a clever touch. Even nicer, this animation is made from vector graphics, not an image capture from the real logo.
While the investigation was going on, John helped law enforcement decipher the email logs, but was not privy to the actual emails for several years (remember John had to wait until the investigation ended). Just from viewing the logs, John was convinced the actual emails would provide an immense amount of operational information.
Once the authorities gave John access to the emails, he learned something interesting. Bob did very little of the actual work; he was a coordinator, running multiple phishing operations, each targeting five different financial institutions. The jobs Bob parceled out were:
- Reconnaissance of potential victims, and what financial institutions they were associated with was an important first step.
- Target address listings of victims using common financial institutions were needed.
- Mail delivery of the phishing emails to each of the potential victims.
- Compromise web-servers so phishing kits could be installed without the actual owner's knowledge.
- Phish-kit creation and modification was critical to afford the best chance of fooling victims.
- Monetization of compromised card accounts to pay Bob and all the third-party operators involved.
This should give you an idea what's required to run a successful phishing operation, and the depth phishers will go to when there's money to be made.
What Bob did wrong
According to John, Bob made several mistakes. First, he did not delete the phish kit from the compromised web servers. That allowed authorities to warn the targeted financial institutions, helping deflect a majority of the attack's effect. Bob also kept a log of the victims on the web server. The list of victims gave authorities the chance to warn many of the victims soon enough to prevent their accounts from being compromised.
A couple of things stand out in my mind. Experts comment how criminals run their operations in a business-like manner. And, that appears to be true in Bob's case. There is a point of departure though — financing; handling money appears to be a bit more creative than what I'm used to. Several times, John pointed out, if Bob needed anything — personal or for his operation — he would simply use stolen bankcards. That's one way of eliminating risk-adverse investments.
This article was a complex piece to pull together; I can imagine the effort John went through during his years of research. That's why I want to extend my heartfelt thanks to John, and SANS as well, for allowing me to use parts of John's paper in this article.
I have been steadily reporting on phishing since 2009, and many of the articles are still relevant. If you are interested, they can be found here.