Watching a phishing attack live Yesterday a phishing mail for a community bank in a US east coast state (throughout this blog post I have obscured many details including names, domains and IP addresses) slipped through GMail's spam/phish filter and then right through POPFile. Only Thunderbird bothered to warn me that it might be a scam.



The message itself was sent from an ADSL connected machine in China.



Of course, since I don't have an account with this bank it was an obvious phish, but I was curious about it so I followed the link in the message.



The link appeared to go to https://*****bank.com/Common/SignOn/Start.asp but actually went to http://***.***.164.158:82/*****bank.com/Common/SignOn/Start.html. Clearly a phish running on a compromised host.



A reverse DNS lookup on the IP address of the host revealed that the phish was being handled by a web server installed in a school in a small central Californian town. The machine appeared to be running IIS, but the phishing server identified itself (on port 82) as Apache/2.0.55 (Win32) Server.



The Start.html page was identical to the actual sign on page used by the bank. In fact taking a screen shot of the real page and doing a screen shot of the phishing page revealed that they were identical. Even the MD5 checksum of the images was the same. Naturally, not everything was the same in the HTML.



Although almost all the HTML was identical (with the phishing site even pulling its images off the real bank's site), the name of the script that handled validation of the user name and password had been changed from SignOn.asp (the actual bank uses ASP) to verify.php (the phisher used PHP).



The only significant diff between the phisher site and the real site is:



272c272

< <form action="verify.php" method="post" id="form1" name="form1">

---

> <form action="SignOn.asp" method="post" id="form1" name="form1">



Once a username and password was entered the phishee was taken to a page asking for name, email address, credit card number, CVV2 number and PIN (with the PIN asked for a second time for validation). After that the user was thanked for verifying their details.



The user name, password, credit card number, CVV2 number and PINs were saved to a file called red.txt in the same directory as the HTML and PHP files used to make the phishing site. How do I know that? Simple, by popping up one level in the phishing URL to http://***.***.164.158:82/*****bank.com/Common/SignOn/ I was able to get a directory listing. In the directory there were three HTML files, two PHP scripts and red.txt. Clicking on that file gave me access to the phished details as they came in.



I quickly informed the bank and US CERT of the phishing site. I tried to figure out how to contact the school, but it was 0500 in California.



Here's a sample entry from the actual log file.



###################################

Tue Sep 19, 2006 5:33 am

Username: youare

Password: stuipd

***.***.118.70

###################################

Tue Sep 19, 2006 5:34 am

cc: 4111111111111111

expm: 10

expy: 2006

cvv: 321

pin: 1122

pin2: 1122

***.***.118.70

###################################



The time is local to California and you can see the details that the person entered. Here clearly a vigilante has decided to mess with the phisher by entering bogus details. In fact, the last time I was able to access the site (before it was pulled down) there were 33 entries in the log file. Of these 32 contained nothing, or offensive user names and passwords.



But one seemed to contain legitimate information.



The log file had a first entry at 0454 California time from a machine owned by MessageLabs (I assume that they are doing some automated testing of phishing sites), the last entry was as 1226 California time.



The one legitimate entry contained a valid Visa card number (valid in the sense that the number validated against the standard Luhn check digit algorithm). Also the user name and password looked legitimate and a quick Google search revealed that the username was also used as part of the email address of a small business in the same town as one of this small bank's branches. It looked very likely that this entry was legitimate and the person had given away their real card number and PIN.



US CERT quickly responded with an auto-response assigning me an incident number and I received an email from the bank's IT Ops Manager Jack. Jack told me that he was already aware of the site and that this was the third time this little bank had been phished from machines in California and Germany. I gave Jack the name of the school in California, and he said he'd get in contact with them (he'd already called the FBI). I also told Jack about the one card number that looked totally legitimate; he told me he was in charge of all card operations at the bank and had the power to deal with it.



Some hours after that the site went offline. Yesterday a phishing mail for a community bank in a US east coast state (throughout this blog post I have obscured many details including names, domains and IP addresses) slipped through GMail's spam/phish filter and then right through POPFile. Only Thunderbird bothered to warn me that it might be a scam.The message itself was sent from an ADSL connected machine in China.Of course, since I don't have an account with this bank it was an obvious phish, but I was curious about it so I followed the link in the message.The link appeared to go tobut actually went to. Clearly a phish running on a compromised host.A reverse DNS lookup on the IP address of the host revealed that the phish was being handled by a web server installed in a school in a small central Californian town. The machine appeared to be running IIS, but the phishing server identified itself (on port 82) asThe Start.html page was identical to the actual sign on page used by the bank. In fact taking a screen shot of the real page and doing a screen shot of the phishing page revealed that they were identical. Even the MD5 checksum of the images was the same. Naturally, not everything was the same in the HTML.Although almost all the HTML was identical (with the phishing site even pulling its images off the real bank's site), the name of the script that handled validation of the user name and password had been changed from(the actual bank uses ASP) to(the phisher used PHP).The only significant diff between the phisher site and the real site is:Once a username and password was entered the phishee was taken to a page asking for name, email address, credit card number, CVV2 number and PIN (with the PIN asked for a second time for validation). After that the user was thanked for verifying their details.The user name, password, credit card number, CVV2 number and PINs were saved to a file calledin the same directory as the HTML and PHP files used to make the phishing site. How do I know that? Simple, by popping up one level in the phishing URL toI was able to get a directory listing. In the directory there were three HTML files, two PHP scripts and red.txt. Clicking on that file gave me access to the phished details as they came in.I quickly informed the bank and US CERT of the phishing site. I tried to figure out how to contact the school, but it was 0500 in California.Here's a sample entry from the actual log file.The time is local to California and you can see the details that the person entered. Here clearly a vigilante has decided to mess with the phisher by entering bogus details. In fact, the last time I was able to access the site (before it was pulled down) there were 33 entries in the log file. Of these 32 contained nothing, or offensive user names and passwords.But one seemed to contain legitimate information.The log file had a first entry at 0454 California time from a machine owned by MessageLabs (I assume that they are doing some automated testing of phishing sites), the last entry was as 1226 California time.The one legitimate entry contained a valid Visa card number (valid in the sense that the number validated against the standard Luhn check digit algorithm). Also the user name and password looked legitimate and a quick Google search revealed that the username was also used as part of the email address of a small business in the same town as one of this small bank's branches. It looked very likely that this entry was legitimate and the person had given away their real card number and PIN.US CERT quickly responded with an auto-response assigning me an incident number and I received an email from the bank's IT Ops Manager Jack. Jack told me that he was already aware of the site and that this was the third time this little bank had been phished from machines in California and Germany. I gave Jack the name of the school in California, and he said he'd get in contact with them (he'd already called the FBI). I also told Jack about the one card number that looked totally legitimate; he told me he was in charge of all card operations at the bank and had the power to deal with it.Some hours after that the site went offline. Labels: anti-spam Available Now The Geek Atlas

With this unique traveler's guide, you'll learn about 128 destinations around the world where discoveries in science, mathematics, or technology occurred or is happening now. Travel to Munich to see the world's largest science museum, watch Foucault's pendulum swinging in Paris, ponder a descendant of Newton's apple tree at Trinity College, Cambridge, and more. Each site in The Geek Atlas focuses on discoveries or inventions, and includes information about the people and the science behind them. With this unique traveler's guide, you'll learn about 128 destinations around the world where discoveries in science, mathematics, or technology occurred or is happening now. Travel to Munich to see the world's largest science museum, watch Foucault's pendulum swinging in Paris, ponder a descendant of Newton's apple tree at Trinity College, Cambridge, and more. Each site in The Geek Atlas focuses on discoveries or inventions, and includes information about the people and the science behind them. GNU Make Unleashed

230 pages of GNU Make from basics to advanced. Covering topics not covered in other GNU Make books such as: eliminating recursive make, doing arithmetic, Makefile debugging techniques and more.



Everything you wanted to know about making real Makefiles. Search Enter your search terms Web www.jgc.org Submit search form Previous Posts Image spam filtering BOF at Virus Bulletin 2006 Mo...

A C implementation of my simple GPS code

Apologia: Sophos and SoftScan

Did SoftScan, Sophos and Panda rip off my blog? (U...

Slashdot effect = 3.5 * Digg effect

Optimal SMS keyboard layouts

Subliminal advertising in spam?

The hell of Dell France

Unbanned from Digg

Badges of Honor 230 pages of GNU Make from basics to advanced. Covering topics not covered in other GNU Make books such as: eliminating recursive make, doing arithmetic, Makefile debugging techniques and more.Everything you wanted to know about makingMakefiles. Subscribe to

Posts [Atom]