On the Internet however, within a matter of minutes I can create a fake virtual branch running on a server with a slight variation of a bank’s .com domain name (see steps on previous page). Upon arrival, unsuspecting users would be presented with an exact replica of your Web site and/or login screen. Why wouldn’t a user type in their username and password?

When a user attempts to log in using their valid username and password the less sophisticated thief could simply return a message such as, “Sorry, the server is down for maintenance. Please check back tomorrow. We appreciate your business.” Users might be frustrated, but they would be completely unaware that they had just handed over the keys to their accounts. Within seconds the crooks could use the lifted password/ID to enter the real bank site and drain a user’s accounts via fraudulent bill payments to P.O. boxes around the country. We don’t know that this has ever happened, but it will.

A more sophisticated thief might capture the password and login information in the background and then go ahead and log the user directly into their real bank account by passing the information to the real login script. This is extremely deceptive, as the user would experience nothing different from a typical session. The user will not realize anything is amiss until their funds are stolen later. Under this scenario, the thieves could take their time, monitoring the balances on their victim’s accounts over weeks or even months, and strike when balances reach their peak.

But still, would this strategy really work? With 50 million Web pages out there it’s hard enough to find legitimate Web sites, much less some strange imposter. Would real users be foolish enough to enter their passwords at false domain names?

To find out, we set-up a lookalike login screen for Security First Network Bank www.sfnb.com running under the lookalike www.sfnb.net domain name (screenshot right). Within 24 hours, legitimate SFNB customers attempted to login to the fake site. After they pressed “OK” we told users it was a fake. Our login screen did not actually capture anything typed in, but it could have.

We pulled the test site of the Web after a few days and buried the program in our hard drive forever. Had we been real crooks we could have run the scam for a few days easily compromising dozens of accounts or more before detection. Posting the false address in search engines and directories could have increased traffic to the fake site.

Using the same techniques, an identity thief could post credit applications on the Web using a bank’s name and trademarks, and capture social security numbers, bank account numbers, and the like.

All is Not as it Appears on the Net

This is actually a fake login screen. Notice the name, Security Fist (instead of First) and the lookalike domain name  sfnb.net  instead of  snfb.com .

The login screen above is an exact replica of the SFNB screen with a couple of important exceptions.

1. Not logged in to a secure server. Notice the broken key and the “http” instead of “https.” Though we could have run our scam on a secure server to avoid this tell-tale clue.

2. Notice the bank name is Security Fist instead of Security First. Again, real crooks wouldn’t do this.

3. The “E-mail Support” link is bogus too. Any email sent using this link would go to the crooks instead of the bank. Also realize the text displayed on the page has nothing to do with the actual underlying <mailto:> hyperlink.

Number three is significant for another reason. Even without going to the trouble of setting up a fake Web site, the owners of a lookalike Web domain could get emails destined for the bank. The fake site would also receive email exchanges from vendors, friends, relatives, and co-workers. This is why it’s important to educate employees and customer’s not to send sensitive information via unsecured email and to double check email addresses before hitting send.

The message returned to the “victims”
of our spoofing demonstration.

Register Your .net Today

Look at these domain names:

www.wellsfargo.net

www.keybank.net

www.wachovia.net 

www.sfnb.net 

These must belong to Wells Fargo, Key Bank, Wachovia and Security First, right? Actually, none are currently registered to the banks involved. They were all registered by my company, NetBranch  www.netbranch.com  this year. (By the way, we were only trying to prove a point and will gladly transfer the domain names upon request.)

Don’t make the same mistake. It will only set you back $70 to lock-in the .net version of your name.

For those of you still reading (I assume some are already emailing your Webmaster), you can take several steps to prevent this situation.

1. Register every similar name you can think of, they only cost $2.92 per month. At a minimum, lock in <yourbank.org> and <yourbank.net>. Credit unions should register <yourcu.com> if you haven’t already. Check for domain availability at  rs.internic.net/cgi-bin/whois . Do the same when new top-level domain names are introduced.

2. Don’t allow access from any server with a permutation of your domain name.

3. Check your access logs. Look for a large volume of requests to your login script from a single IP address or domain name. Also look for a high number of requests for your login graphics.

4. Restrict access to your login script. Your login script should only work when the referring IP address of the requesting server is the server that houses your official login screen.

5. Create a two-step login process for bill payment, interbank funds transfer, or any feature that could be used to move money out of the rightful account holders’ pockets. First-level passwords could be stored as cookies, or could be simple things such as the user’s last name. The secondary password would be the crucial one safeguarding monetary transactions. Any type of two-step password scheme would defeat the simple attack outlined here. Although sophisticated fraud artists could attempt to mimic your two-step process as well.

6. Use the VeriSign logo/certificate on the login page. But realize the crooks can steal this image as well.

7. Educate customer service staff and end-users.

User Advice:

•  Be cautious with your passwords
•  Verify the domain name/spelling
•  Verify site certificates
•  Use bookmarks
•  Never give account info via email

8. Search and scan the Web and newsgroups for uses of your name including misspellings and permutations. Some brokerages have full-time employees devoted to this process. They also look for compliance violations from their own brokers.

9. Hire a security consultant who looks beyond encryption and firewalls and applies common sense techniques to protect you from spoofs and other low-tech hacks.

10. Allow users to set their own security parameters on their accounts such as:

•  Allow access only from specified domains.
•  Maximum dollar amount of bill payments/day
•  No logins after midnight or weekends without special override password.

11. Send an email to users every time their account is accessed and every time a bill pay is initiated.

Alan Martin is President of NetBranch  www.netbranch.com , a consulting and design company specializing in banking and financial sites. He is also Webmaster for Online Banking Report. He can be reached at (770) 736-5956, or webmaster@onlinebankingreport.com .