The phone rang. Two different companies had been hacked, both in the same way. One was a very large corporation, (we’ll call it “Worldwide Company, Inc”) which had many bank accounts that held millions of dollars. The other was a small business that handled a lot of financial transactions– we’ll call them “Local LLC.” The bank shut down both companies’ online accounts after it was clear that the hackers had gained access to their internal systems. We traced the attacks back to two phishing emails. There were telltale signs of the Blackhole Exploit Kit at work.
The Backstory Video of the Phishing Attack Under the Hood – Network Traffic Analysis Man-in-the-Browser Attack on Bank of America’s Site Bells and Whistles	Curious, I extracted copies of the phishing emails and malware from each infected workstation. What did it LOOK like when these companies were infected? What were their computers actually doing under the hood? Most of all, I wanted to actually SEE the Man-In-the-Browser attack in action!
After three days and a LOT of caffeine, I finally caught it on camera. Below are videos and screenshots of the phishing attack, followed by a real Man-in-the-Browser attack on Bank of America’s web site. My favorite part is when the attacker tried to steal my debit card number, expiration date, security code, Social Security Number, date of birth, driver’s license number, and mother’s maiden name– all at the same time. Nice try, dude!! (I used a Paypal test credit card number to submit the “validation” form. The hackers actually check to make sure your credit card number is legit.) Share these videos with your friends and co-workers so they know how NOT to get pwned!

The Backstory

Case #1: Worldwide Company, Inc.

At Worldwide Company, Inc., Mrs. Miller managed a corporate bank account containing millions of dollars. One afternoon, she received a message that read, “Hi, as promised your photos.” She clicked on the link. Nothing much seemed to happen.

A few days later, Mrs. Miller logged into the company’s online banking site. Strangely, the bank’s web site popped up a message saying that she needed to verify her identity. It asked her to type in her name, which she did. Next, “the bank” asked for her phone number. Mrs. Miller entered her phone number. Then it asked her to verify her security question, and showed her the question. Mrs. Miller typed in the answer to her security question. Finally, “the bank” asked for her one-time key. Mrs. Miller typed in her RSA token number.

Unbeknownst to Mrs. Miller, her infected computer silently initiated a wire transfer from the company’s account for $49,500.

Fortunately, the corporation required a second person to approve transfers that large. After a few moments, the bank’s web site popped up with another question for Mrs. Miller– “What is the name of the second person required to approve wire transfers?” Mrs. Miller typed in the person’s name. Next, the web site asked for the email address of the second person who approved wire transfers.

Mrs. Miller hesitated, and called the bank. The bank shut down the corporation’s access to online banking while the investigation proceeded.

Case #2: Local LLC

At Local LLC, “Linda” managed all of the company’s online banking. One morning, she received an email that read, “Dear Online Account Operator, Your ACH Transactions have been temporarily disabled.” She clicked on the link. Nothing much happened, so she went about her day. Unbeknownst to Linda, her computer began communicating with a remote system on the “Clodo-Cloud” network in Russia.

A few days later, Linda logged into her corporate online banking web site. Unusually, the bank’s web site popped up with a question asking her for her “one-time password.” She typed in her password. Next, it popped up asking for her name. She typed her name in, too. Finally, it popped up asking for her phone number. She typed her phone number in as well.

Instantly, Linda got a phone call from a woman with a very heavy foreign accent, claiming to be “Emily Rice” from the local bank. She said “I need to help you with your bank account.” Linda hung up the phone, and called the bank.

Afterwards, forensic analysis revealed telltale signs of the Blackhole Exploit Kit at work in both cases. Moreover, based on interviews and malware analysis, both companies were infected with a similar “payload” that launched a sophisticated Man-in-the-Browser attack designed to steal banking credentials– and more.

Video of the Phishing Attack

First, I installed Linda’s phishing emails on a computer in LMG’s malware analysis laboratory, began sniffing traffic, and then clicked on the links and captured video. In the video below, you’ll see what Linda saw when she clicked on the link.

As you can see, Internet Explorer popped up and connected to:
hxxp://agenda.igrejaemcanoas.net/redirecting.htm

However, this server is just a middleman! Here’s a screenshot of the URLQuery report for that site, showing that Suricata /w Emerging Threats Pro identified this as a “Blackhole 2 Landing Page.”

Linda’s browser was immediately redirected to:

hxxp://lemonadiom.ru:8080/forum/links/public_version.php

It was this site that ultimately compromised her computer.

Here’s a screenshot from URLquery.net of the final landing page:

Yes, it’s blank. You can see why a normal person might think nothing much of it. That’s the point.

Many thanks to Scott Fretheim for setting up LMG’s malware analysis lab! [Note: identifying information was changed to protect the victim. For the video, I also replaced the "middleman" link in the phishing email with one that still worked. Those middlemen have a short lifespan-- usually only a few days, if that.]

Under the Hood – Network Traffic Analysis

Behind the scenes, Linda’s computer was actually very busy. Here are a couple charts of the network traffic, based on flow record analysis. In the screenshot below, you can see the infected computer’s communications during first 90 minutes of the attack. I’ve removed the normal Windows traffic so you can clearly see abnormal activity.

The big spike at 23:29 represents the time that the malware was executed in the lab. In real life, this occurred moments after Linda clicked on the link in the phishing email. Every 20 minutes after that, the infected computer “phoned home” using an HTTP POST.

After 24 Hours

Here’s what the traffic looked like over 24 hours. The spikes are connections over TCP port 8080 to mostly foreign servers:

As you can see, the infected computer continued to “phone home” every 20 minutes on the dot.

After 48 Hours

Here’s what the traffic looked like after 48 hours. Now we’ve zoomed out, because shortly after midnight on Monday the infected computer downloaded some data from the server–likely an update. Similar activity occurred just before noon on Monday. You can still see the “phone home” traffic– those are the tiny little blips at the bottom, which are relatively small in volume compared to the larger downloads.

Of course, the end user doesn’t see any of this happening.

(By the way, I used Argus to create these graphs. If you want to know how to make these yourself, see Chapter 5 of our Network Forensics textbook. We also cover this in Day 3 of the Network Forensics class, which is running at Black Hat July 27-30.)

Man-in-the-Browser Attack on Bank of America’s Site

After 48 hours (and two all-nighters in a row) I logged onto the (now really REALLY) infected computer, complete with shiny new malware updates. I surfed to Bank of America’s web page, and found what I was looking for– a Man-In-The-Browser attack in action!

A Man-In-The Browser attack is when your browser basically gets possessed by an attacker. The attacker can capture anything you type into your browser– usernames, passwords, you name it. They can also make web sites look different from the way they really appear, adding new fields or images that don’t show up in the real web page. Man-in-the-Browser attacks can be used to steal your login credentials, credit card number, social security number, or anything else that the attacker wants.

The two videos below show a real Man-In-the-Browser attack against Bank of America’s web site. Note that this is NOT a flaw in Bank of America’s web site! This attack works because YOUR DESKTOP is infected.

Normal Bank of America Web Site

To set the stage, let’s first take a look at what Bank of America’s web site looks and acts like normally, on a system that’s NOT infected.

In the video below, I browsed to Bank of America’s web site, and tried to login with a test account “testuserboa.” Since this account doesn’t actually exist, I was redirected to a page with an error message that said “We can’t process your request. The information you entered does not match our records. Please verify your information.” This was followed by a simple form that said “Please enter your Online ID.” Pretty straightforward.

Infected PC

Now we’re going to watch the Man-In-The-Browser attack. In the video below, I surfed to Bank of America’s web site and again tried to login with a test account, “testuserboa.” Even though the username wasn’t “correct,” the attacker certainly didn’t miss an opportunity to try to steal my information. What you see here is a form inserted by the attacker into Bank of America’s error page.

As you can see, this time, we received the same error message as before, PLUS the following text:

“We do not recognize the computer you are using. Please confirm your identity from this unrecognized computer.”

After that, the malware asked for:

• Location where your accounts were opened
  • State (options included Canada, Ireland, United Kingdom, and Spain, in addition to US States)
  • City
• ATM or Debit Card Information (15 or 16 digits, no dashes or spaces)
• Expiration Date
• Security Code
• Personal Information:
  • Social Security Number
  • Date Of Birth
  • Driver’s License Number
  • Mother’s Maiden Name

What can attackers do with this information? Anything they want!

At the bottom of the form, there was a simple checkbox with the request: “Do you want us to remember this computer, so you can avoid answering your personal information next time you sign in?”

How convenient.

Here are some screenshots of the man-in-the-browser attack that might be handy for training:

Normal behavior – Bank of America’s web site from a computer that is NOT infected	The same Bank of America page viewed from an INFECTED computer. Notice the extra “questions.”	The same page viewed on an INFECTED computer, scrolled down.
The same page viewed on an INFECTED computer, with the “Remember computer” question visible.

Bells and Whistles

The malware’s inserted code includes error checking routines which check the validity of information entered into each field. For example, if you try to enter a dummy credit card number, like “1234 5678 9012 3456,” the page produces an error message and will not let you move on. In the video above, I used a Paypal test credit card number to get past the form’s field validation without actually losing my credit card number

The malware also sets a cookie as soon as you submit the form. Unless you manually remove this cookie, you’ll never see this page again. That makes it pretty hard for everyday employees to show IT staff what happened, if they get suspicious after the fact.

The End!

I hope you enjoyed these videos as much as I enjoyed making them. Visual examples like these are really great ways to teach people about phishing and raise security awareness.

We cover malware network forensics, web proxies and flow analysis during Days 3-4 of the Network Forensics class. We’ll be teaching next at Black Hat USA, July 27-30. Seats are limited, so sign up soon!