A New Hampshire-based IT consultancy lost nearly $100,000 this month after thieves broke into the company’s bank accounts with the help of 10 co-conspirators across the United States.
On Feb. 10, Hudson, N.H. based Cynxsure LLC received a voicemail message from its bank, Swift Financial, a Wilmington, Del. institution that focuses on offering financial services to small businesses. The message said to contact the bank to discuss an automated clearing house (ACH) payment batch that had been posted to Cynxsure’s account.
The next day, Cynxsure’s owner Keith Wolters returned the call and learned from Swift that someone had put through an unauthorized batch of ACH transfers totaling $96,419.30. The batch payment effectively added 10 new individuals to the company’s payroll, sending each slightly less than $10,000. None of the individuals had any prior business or association with Cynxsure.
Wolters said the bank told him it would try to reverse the transfers, and in the meantime it issued the company a provisional credit, replacing all of the stolen funds. But when he went to draw on that amount, Wolters found he was not able to withdraw money from the account. The next day, Wolters said, the bank reported that it had been unable to reverse the transactions. Shortly thereafter, he said, Swift withdrew the provisional credit.
Cynxsure’s attorney is now drawing up papers to sue the bank.
“We have done our best to make sure we’ve done everything we possibly can to protect our side of the equation,” Wolters said. “We’ve put a lot of time and effort into making sure something like this couldn’t have come from our side. We’re not going to be one of those companies that goes quietly into the night after something like this.”
James Reilly, operations leader at Swift Financial, declined to comment on the incident, saying only that “it is against our corporate policy to discuss this matter further due to customer privacy and possible litigation.”
Wolters said his is the only computer used to access the company’s accounts online. Since the incident, he has conducted numerous scans with a variety of anti-virus and anti-malware products – which he said turned up no sign of malicious software. Wolters is holding out hope that perhaps the incident is related to a story that he said a Swift Financial executive told him about an incident last summer in which a Swift employee was caught gathering customer online banking credentials without authorization, but that story could not be independently confirmed.
Swift, like all commercial banking institutions serving businesses in the United States, is required under federal guidelines to secure customer transactions using some form of “multi-factor authentication,” or something else in addition to just a user name and password.
Swift and many other commercial banks have chosen to adopt a technology that requires business customers to “register” the computer they use to do online banking, by answering a set of “secret questions.” Customers are generally prompted to answer these questions if they try to access their accounts from a new computer or if the customer tries to log in to his or her account using an Internet address that the bank has never seen associated with that account before.
Wolters said the bank told him that whoever initiated the bogus transaction did so from another Internet address in New Hampshire, and successfully answered two of his secret questions.
The Cynxsure manager said he thought a fingerprint scanner attached to the Windows laptop he uses to access his bank account online would help thwart any attacks from password-stealing malware. The scanner stores passwords as encrypted image files; when his bank or any other site asks for a password, Wolters doesn’t enter the password in the site. Instead, he merely presses his thumb onto the scanner, which in turn decrypts the stored password for that site and pastes the information in the password field of the site he’s visiting.
Unfortunately, these scanners aren’t designed to defeat attacks from malware such as the ZeuS Trojan, which is often mislabeled as an invader that records computer keyboard keystrokes. It can do that, but its most useful feature is one that intercepts all data the user enters into user name and password fields. This feature, called a “form grabber,” effectively snatches the credentials before the browser can encrypt the information and send it over the https:// connection.
The fingerprint reader, when presented with the proper finger or thumbprint, will decrypt the appropriate stored credentials for the site currently active in the user’s browser, and paste that information into the relevant forms on the site. If a Trojan like ZeuS were present on the machine, it would be just as able to rip out that information after the unsuspecting victim hits the “submit” button in their browser.
True, it is still not clear yet whether the attackers in this case used ZeuS, or any other malware for that matter. Still, similarities between this attack and others strongly suggest the work of an organized crime gang operating out of Eastern Europe that typically steals banking credentials using the ZeuS Trojan, and funnels the stolen funds in the same way as Cynxsure was hit.
Last week, I wrote about criminals using ZeuS to siphon roughly $150,000 from a Michigan insurance company. The attackers in that case sent the money to 15 people across the United States that had no prior business with the company, and the hackers defeated the bank’s battery of secret questions in that attack as well.
Alas, Cynxsure may still get some money back, albeit a paltry 1 percent of what was taken. One of the individuals who received a $9,500 transfer from Cynxsure’s account, 26-year-old Merit Moll, from Collowhee, N.C., said he got the payment after signing up for a work-at-home job offered to him by a company calling itself the Element Group. The company’s Web site, formerly at element-groupinc.ws, is no longer online. But Moll said he was told to create an account at the site and check his Web-based e-mail at the site once a day for messages that a new task was ready. On Feb. 9, Moll got his first (and last) task, and was asked to wire the money in $3,000 chunks to three different individuals in Ukraine.
When confronted by his bank that the money he’d received and forwarded on had been stolen, Moll said he told his bank to take the $750 commission he’d received for his work, as well, as the rest of the money in his account (around $250), and make sure it was given back to Cynxsure.
“That was every last penny I had,” Moll said. “I told them, ‘Please take it, I wish I could do more. This is me sending what money back that I can, saying, I am really sorry. They really fooled me.’”
Cynxsure’s Wolters said he hasn’t seen a dime of the money yet.
A screen shot of Merit Moll's account at Element Group
Okay, I have been watching these type posts for some time. This one seems different in they had done what you suggested, dedicated a computer, updated AV, etc. and still got hit.
So exactly what category of apps do you need on your machine to stop these virus, trojans, botnets, password stealers and other malware? Anti-virus, a spyware, etc.
Also, is there an independent source to advise us which ones actually works?
qfxsoftware.com claims “KeyScrambler encrypts your keystrokes in the kernel, giving keyloggers only “scrambled,” meaningless keys to record… Defeats old and new, known and unknown, keyloggers…. Works even on security compromised computers.” I’d like to know if it really defeats all keyloggers as it seems to claim or is it just hype.
“KeyScrambler” would not guard against the type of malware in this article which collects information from the browser at point of submission rather than just keystrokes.
Try a dedicated computer running Linux instead of Windows. Using a Live CD can be even more secure since nothing is stored on the hard disk.
Distributions such as Ubuntu offer a Live CD with a browser that is fully capable of performing online banking tasks.
For people requiring access to other documents and programs while doing online banking, running a Linux distro inside a virtual machine, even on a compromised Windows system, can be an option.
To my knowledge ZeuS does not sniff network traffic or compromise VMs. VirtualBox is free for both home and business use.
There are many issues with running a VM for protection. In short, its much more complicated than booting to Linux and not nearly as safe.
Short answer: Don’t use Windows computers for online banking.
Consider using a Mac or Linux. If you are a Windows user, you might consider booting your Windows computer from a Linux Live CD for your online banking sessions.
Here is another article by Brian Krebs you may find worthwhile:
http://voices.washingtonpost.com/securityfix/2009/10/avoid_windows_malware_bank_on.html
Another Brian Krebs article with more details on banking with Live CDs
http://voices.washingtonpost.com/securityfix/2009/10/e-banking_on_a_locked_down_non.html
The best solution to this type of problem is booting a computer using Linux, running off either a CD, USB flash drive or SD memory card. I first wrote about this back in August shortly after Brian started the series on bank frauds. Brian too, came to the same conclusion.
http://www.esecurityplanet.com/features/article.php/3834031/Consider-Linux-for-Secure-Online-Banking.htm
Any Windows based solution is sub-optimal and in-defensible.
To be safe while running Linux on a computer with an internal hard drive (which is not at all necessary) you can dismount the internal hard drive keeping Linux completely away from it. Or, get a cheap, used PC and throw away the internal hard drive.
@Michael Horowitz I don’t know very much. Suppose the bank requires the customer to “register” the computer before initiating a transaction. Will that requirement cause a hassle for the Linux solution you suggest?
Does registration require the computer to store a cookie, or something like that? Is storage of a cookie possible if you are booting off of the dedicated Linux CD you suggest? –Ben
@Ben
There is *always* a trade-off between security and convenience. Upping security means decreased convenience. If you read enough stories about banking fraud, you can decide for yourself how much inconvenience you are willing to tolerate for added security.
Yes, a Linux user may have to register the computer each time, but it depends. If you run Linux from a USB flash drive or SD memory card you probably will be able to save data locally and avoid this. I can’t know how every bank handles registration. However, running off a CD means you can’t store any data, running of a flash drive/SD card means you can. That’s the rule, but there are exceptions. For example, some Linux Live CDs will store data on the hard drive. And, some memory cards offer hardware write protection.
To me these are small issues. The big issue is to use Linux instead of Windows.
Wow. They’re even modding down Mike Horowitz. Or anyone reiterating Brian’s original suggestions. On closer inspection I think the live CD is the ultimate tactic: it’s cheap – as in zero cost with Ubuntu; it doesn’t require purchasing any additional hardware or any additional anything; it’s write-protected. That about sums it up. Are you still having an issue with this suggestion? Put it this way: if everybody and their cousin started using a Linux live CD tomorrow for banking – and I mean literally everybody – what do you think would happen?
1. Zeus wouldn’t run. That’s for sure.
2. The hackers may regroup and find another way to attack – and that’s a real long shot – but that will at least take time. And at the rate money is leaking out today, even that kind of respite will translate into major savings.
What’s really important is that all boxes are cleaned and no one but no one inputs anything sensitive on any other box. Ever. Because those boxes, if they’re Windows, are going to get hacked one way or another.
Trusteer’s research shows that the odds of even finding Zeus – much less removing it – with today’s AV are less than one in four.
So you can’t use any other boxes ever for sensitive stuff. Stick with the live CD and things are going to get better.
Rick’s absolutely right. There is NO 100% solution to this problem which will be both convenient and safe, but you can almost reach this by booting to a liveCD. Ubuntu’s is very easy to use, and includes a browser which is very good (Firefox).
I do not recommend booting from a USB or other writeable media, even if not doing so requires answering your security questions every time. If you can write to it, so can fraudsters.
If you are a small business owner, do not mess around with this simply because you don’t want to spend an extra 5 minutes to do this business. That 5 minutes can save you your business.
They didn’t do everything Brian advises. They didn’t take real ultimate precautions. Brian suggests using a non-Windows machine. Such as a Mac or a Linux live CD. Which makes sense as the #1 criminal right now is ZeuS and ZeuS only attacks Windows.
Then there’s the matter of the dude claiming he’s had his machine scanned and it’s clean. Iceman had an expression he used with Pete Mitchell. The bank won’t settle for that – he’ll have to provide 3rd party forensic results. And I think we’ll find his box wasn’t at all as clean as he believed it to be.
We’re all expecting this to be Zeus and to behave like the Zeus infections we’ve seen stealing information from noncommercial users. But for a target potentially yielding as much money as this, it’s entirely possible they’ve crafted a trojan that uninstalls itself after the deed is done. They don’t anticipate there being any chance they can continue to collect data from that computer once there’s been such a high-profile theft, so why make it easy for law enforcement and the AV software companies to find and analyze their malware?
A two factor authentication that is more ‘robust’ might be helpful. For example, requiring smart-card authentication to get to the web site, or a bank issued variable-pin code generation mechanism such as an RSA token that changes every XX seconds or (as my bank offers) requiring a PIN that is sent to a registered cell phone via SMS.
A smart-card provides a private key (that needs a pin to be accessed). The bank has the matching public key. This, in-turn, is used to create the SSL session. even if there is a form grabber in play, in order to create a bogus session, the attacker would have to have compromised and/or duplicated the smart card. This would require a physical device to generate the required ssl session. No device=>no https session=>no transaction.
A variable PIN synchronized to the bank would require either physical possession of the token generator (keyfob, etc) or the registered device (i.e. cell phone) that receives the pin issued by the bank. Either way, a physical device would need to be present (ok… so someone could clone the phone, if they had the number that was registered with the bank to recieve the PIN code.)
my bank offers both PIN distribution to a cell phone via SMS (free) or an RSA key-fob (I believe the key fob is actually issued as a credit card looking device) that is available for a small fee (under $20).
One could always use some sort of social engineering to get the bank to issue a pin or pin-device to an unauthorized user, but then this would not be the same type of attack because the illegitimate transaction would be generated by an authorized user (albeit improperly authorized). Thats the beauty and bane of social engineering. No amount of technology can defeat or prevent a duped human from using authorized systems and processes to provide access to an unauthorized entity.
All of these still have an easy path for the bad guys on a compromised computer. The SSL session which requires a private key is still subject to ‘live hijacking’ where the bad guys alter the contents of a live session to make fake transfers / payments after the victim has initiated the SSL session.
The cell phone SMS could have been the most promising because it is a completely separate channel out of the control of the compromised computer. Alas, in real life, the cell phone is tied to an Email account or cell phone company login which was likely compromised along with the computer. The bad guys then have some sort of control over the cell phone as well to defeat SMS based PIN security.
Combine them.
Rather then tie your transaction authentications to a cellphone you own and thus might get compromised, tie it to a wireless device that the bank issues.
I don’t know what the costs would be like, but I’m thinking a deal like OnStar or Kindles use where they buy bandwidth in bulk.
Initiate the transactions on your PC. Even if the session is hijacked, the device pops up with each transaction for you to authorize which will show the fraudulent entries.
Yes, it won’t work everywhere…some folks will need a landline modem version, and some folks will just be SOL. But between wireless and wireline systems 99% of organizations which have these large balance bank accounts could be protected.
“One could always use some sort of social engineering to get the bank to issue a pin or pin-device to an unauthorized user…”
Valid point. Unfortunately, the presence of an authentication method such as a token or even a less secure one such as “challenge questions” in a security compromise leads many to say that the authentication method has been defeated.
Authentication tools merely verify that the password was generated from an authorized source. I’m not sure if it is the bank’s job to make sure that the authorized user won’t give them away and get tricked by a maintenance screen…
Ultimately, this would not protect you from Zeus. The fraudsters would just wait for you to enter your credentials, and then hijack your session in real time using a man-in-the-browser attack. They then return a fake error message to you asking you to try again. By that time, the fraudster is in your account.
If he keeps the browser from timing out, he could even lurk in your online banking to allow you time to log out, and then he could send his nefarious transactions.
There is absolutely no substitute for properly protecting the end user.
Unfortunately, most banks do not do enough to help the end users protect themselves. Educate, educate, educate.
I don’t have anything on Chernobrov, but this may be Kaleeva:
About Me
n.kaleeva does not have (a) anything about yourself.
http://n.kaleeva @ bk.ru
Personal information
n.kaleeva
Beginner
31 years
Female
Ukraine, Kiev
Date of Birth: March-12-1978
Interests
No data
Statistics
Registration: 06.11.2008
Profile Views: 54 *
Last Seen: 11.01.2009, 16:31:56
Local Time: 05/02/2010, 21:50:30
2 posts (0 per day)
Contact
AIM: No Information
Yahoo No Information
ICQ No Information
MSN: No Information
Contact Send Message
Contact Private
* Profile views updated each hour
n.kaleeva
Community
*
About Me
Topics
Messages
Comments
Friends
Contents
This user has not written anything about themselves and not use the signature on the forum.
Views
n.kaleeva has no visitors to display.
Comments
Other users have left no comments for n.kaleeva.
Friends
There are no friends.
Partners
ßíäåêñ öèòèðîâàíèÿ Rambler’s Top100
Time is now: 05/02/2010, 21:50:30
Forum IP.Board 2.3.6 © 2010 IPS, Inc.
Licensed to: JSC “TV VID”
My bank requires a username/password, then a PIN. The PIN screen displays an image of 10 letters, each corresponding to a digit. The letters change each time, and only the bank knows the association between the images and the real numeric PIN. So the first time I log in, I might see
A-B-C-D-E-F-G-H-I-J
1-2-3-4-5-6-7-8-9-0
If my real PIN is “1234” I would type “ABCD.” But the next time, I might see
Z-Y-X-W-V-U-T-S-R-Q
1-2-3-4-5-6-7-8-9-0
Since my real PIN is “1234,” I type “ZYXW” this time.
What does everyone think of the security of this approach?
Here’s a screen shot: http://www.flickr.com/photos/a102001/4381358891/.
Some malware includes screen captures at key moments – the attackers would still end up with the actual PIN. And the live session can still be manipulated by the attacker in the background to perform unauthorized transfers or payments.
There are very few authentication security methods that are not susceptible to man-in-the-middle attacks. I don’t like to spend a lot of time pitching technological solutions, because I sort of feel like my stories are the biggest commercials for those technologies already anyway. But if I were to focus on one type of technology as holding the most promise to defeat these attacks, I would say anything that focuses on authenticating the transaction, rather than the user.
Part of the problem here is the banks want to push the fraud detection onto the customer, with tokens, and secret questions and all kinds of other things. But these can always be stolen, intercepted, phished, whatever.
A component of any real solution has to incorporate some evaluation of the transaction information : the part where money is made to move. In that instance, the bank can do like the credit card companies have long done: Ask, hey what does this customer’s normal banking activity look like? Ok, let’s build an algorithmic way of measuring that. Then, when presented with a given set of transactions, ask, does this set of transactions match the type of activity we normally see from this customer (i.e., do they normally wire money to 10 different individuals they’ve never wired money to before, in 10 different cities??). If the answer is no, proceed to step 2, call customer, or whatever.
I realize that commercial banks are very sensitive to doing anything that might interfere with their customers’ normal business operations, but most banks do not even offer such a service, nor do they adequately inform businesses about the risks of banking online.
Transaction monitoring would be an excellent thing for banks to bring in. Banks have this habit of trusting the customer once they’ve authenticated. They continue to push tools to customers to make it easier to “trust” them, ie key fobs, and other out of band authentication. While malware like zeus regularly takes advantage of this practice, then abuses the trust and power available in online banking environments.
What they really need to do is build a banking environment that doesn’t trust customers and their actions while banking online. Just like in a physical bank, you don’t trust a customer isn’t going to rob you until they walk out the door, transaction complete. Transaction monitoring for online banking seems to be a low impact way to do that, without impairing customer perception.
I agree. When I travel and buy gas a hundred miles from home and a half hour later, my wife buys something at the hometown KMart, My card company wants to know what is going on. It can be frustrating some times, but I finally learned that if I call the Card company before leaving town to let them know where to expect charges, we are ok. I think banks SHOULD be doing this as well. There is no reason they cannot. Just remember to provide them with a number where they can reach you when they need to. (my card company has 4 numbers where they can reach me).
Oh, and when you get that statement at the end of each month, verify it against the receipts (in this day and age, if you don’t save your receipts, you are asking for trouble) NOT against what you download from the bank or Card company. That will always match but the receipts may not. That’s how you find your mistakes, their mistakes or fraud if it occurs.
I’ve been doing this forever and haven’t lost so much as a penny yet.
It’s absolutely true that we are seeing many traditional 2-factor authentication solutions such as OTP tokens falling short. In my practical experience there are a few effective solutions out there right now:
1. Out of band OTP code delivery along with confirmation of transaction details (ie. an SMS or voice message that says “you’re wiring $15K from account X to account Y, your passcode is 302831”). Delivery of an OTP alone is insufficient. Yes, you have to be careful about how users are allowed to reset the out of band destination address.
2. Fraud detection engines on the target website (e.g. corporate banking) that monitor user behavior and look for patterns of unusual activity. Looking at the specific transaction data (from acct/to acct/amount) is not enough — you need to look at more context from the overall session, e.g. speed of user’s movement through the site, and at patterns of activity across the user base.
3. One time password tokens that don’t just display a passcode — they also make the user enter transaction details then generate a signature code. While effective from a security perspective, these do have usability challenges re: understanding the UI and dealing with tiny keyboards.
4. Arguably, malware detection software or other software which aims to strengthen your browser is interesting, but it is definitely an arms race when you are attempting to run security software on the same machine as the malware.
[Disclosure: I work for a vendor that offers solutions in spaces 1 through 3 above — but these solution areas are generic and multiple fine vendors do exist.]
Who says that banks aren’t monitoring transactions already? Larger banks have transaction risk monitoring going on in the background. I would note that almost all of these fraud examples you find are with firms banking with smaller banks that cannot invest in that level of secuirty like larger banks can. I think you should start tracking stats of the size of the bank (assessts for simplicity) who’s client you’ve heard of being defrauded. I think you’ll find incidents skewed towards smaller banks because they don’t have transaction monitoring in place.
I have to agree that I really only hear about smaller banks being the victim of these types of losses. I think you are right it would be extremely interesting to see who is really the victim of these types of fraud, large vs small banks. However I don’t know that simply because we only hear about the small banks that means that the big banks have this all under control. We usually hear about these incidents regarding lawsuits or upset customers, big banks have a lot more resources to keep people quiet and even just compensate customer losses to maintain PR and face. I’m not saying that is the case, but on the other hand without hard research I’m not drawing any conclusions.
If there are major/minor banks using transaction monitoring, I would love to hear about it and even discuss to learn lessons from them. I think there is huge value to all banks in having a successful model to follow to help prevent this fraud. Right now I think risk based transaction monitoring is still a developing technology, when a mature solution is needed right this instant.
PS – If your using transaction monitoring as a financial institution, I would love to have someone change my mind about the state of things.
Man in the browser… (aka dll injection)I find it hard to believe that there was zero malware on the computer that is allegedly the only one that accesses that account. Most of the bank related malware have been doing this for a long time and hook the same DLL’s that control these functions in the browser.
Whoever the person that reported that there is no malware on that supposed computer did not do a thorough search for malware. Thorough – meaning searches for malware that has no signatures (yet.)
The problem being like so many people are saying is the access point where the data is sent before it is encrypted and sent.. (the form field) You can have all the factors you want but if the information is not protected in the browser before it is submitted you are SOL. Use a dedicated *nix box 🙂 Ubuntu is kid friendly enough these days for people to use.
Wolters story isn’t adding up yet or he is accessing the bank account from more than one computer that has differing levels of ‘security.’
I agree with Ben,
I understand what the IT company is saying, but this fits the “mold” to the “T” of malware.
I hope this does not start any flames
I called my banks after reading a few of your articles and interestingly enough they are not prepared for nonce based authentication. If you have a following from the banking community it may be nice if you run an article on how to prevent this type of attack. I get the laws protect the individual more than the business, but this has to increase the cost of doing business etc…
I would gladly spend $15 – $20 for an RSA SecurID.
I may have to create a knowledge base article to put all this information in one place and to link to in every article like this.
In practically every story I write about this fraud, I get comments from people suggesting RSA tokens are the answer: Let me state plainly that they are not, and that I have seen example after example of these guys intercepting that information as well and defeating it.
Any solution that does not assume the customer’s machine *is already compromised by malware* stands zero chance of beating the bad guys at their own game.
Please see the following story, which points to two other articles that outline a few specific steps that business owners can take to insulate themselves from this type of fraud. Those steps mainly involve using something other than windows for online banking, and/or using a dedicated system.
http://voices.washingtonpost.com/securityfix/2009/10/e-banking_on_a_locked_down_pc.html
I am certainly one that says that when USED CORRECTLY, there are security tokens (I’m not naming brands) that have not been defeated, and wouldn’t with any cases I’ve heard of.
They can be used set to be used to login and perform the transaction, only once, and can authenticate both the user and the bank website.
When the maintenance screen comes up and someone in the Ukraine is operating with your passcode, the token hasn’t been defeated — the code has been stolen by keylogging software. No one says they can’t be stolen. But the user is clued in to the theft when the screen doesn’t come up and verify the second token number with a matching code. If the user doesn’t get the second code, obeys the maintenance screen instructions and doesn’t call the bank, it’s social engineering, not the token’s failure.
In your example the session should still be able to be hijacked.
I have no solution for the issue at hand but behavior based analysis should also be behavioral based analysis of actions on the banks end.
“Any solution that does not assume the customer’s machine *is already compromised by malware* stands zero chance of beating the bad guys at their own game. ”
Well said Brian! This one sentence says it all and must be the baseline of any online banking solution.
That’s very true. That’s the essence of security everywhere. But the cause of the woes here is Zeus. And Zeus only attacks Windows machines. All these trojans attack only Windows machines.
And here we have Brian himself saying ‘DUH – then don’t use a Windows machine’ and even he’s been modded down.
A Linux live CD. Shuttleworth ought to start sending them to everyone. Anyone doing online business should have one and have practised with it. Gee what a different world it would be. Perhaps just for a moment but still and all. Think about it. At least it’s time to regroup. Anything is better than the status quo.
There has to be some way corporations can be mobilised to start practising secure computing with as little as a Linux live CD, to start thinking with their other extremity instead.
I think any campaign that gets the word out ‘do your banking with a live CD’ is going to help – and hopefully help a lot. The status quo is untenable.
Do we want to see an improvement in Internet security or do some people just want to go on talking about it?
There is nothing wrong with better security systems from the other end. People can go on discussing further measures. You need good authentication no matter what. But start at the root cause of what’s ailing business online first.
Unfortunately, the live CD’s are only really helpful when the only people using them are ones who already are pretty good at protecting themselves. Once naive users start looking for sites to get a download to create a boot disc, they’ll be getting duped by the same kind of people distributing rogue AV programs. And if they start popping any CD that shows up in the mail into their computers as if they were AOL installs, I’m sure we’ll see them being used as vectors for malware, too.
It seems to me that one of the ways to fight this kind of fraud rests in the hands of our government:
First, would be to consider anyone who participates in these crimes, but especially the person who actually moves the money (the mule), as part and parcel of the crime and therefore a co-conspirator. If someone else on the inside is participating, same thing–they become a co-conspirator. (Brian seems to have no trouble finding and interviewing these people, so one must ask, why should law enforcement have any difficulty finding them?) Then throw the book at these folks. We need to remember that ignorance of the law is not an excuse, and if you make the punishment monetary (perhaps returning the money to the cheated business) plus some jail time, this would convince people to stop doing this stuff.
and
2. Give business the same kind of protection that is currently granted to non-business banking clients. I’ve never quite understood why there should be any difference other than the banking lobby convincing the all-to-easily-convinced in Congress that it’s not the bank’s fault, when it most certainly is.
@Henry S. Winokur >>Give business the same kind of protection that is currently granted to non-business banking clients. I’ve never quite understood why there should be any difference<<
It's a long and complicated legal story. These commercial banking transactions are governed largely by Uniform Commercial Code Article 4A, which was drafted in the 1980s by well-meaning people who knew technology would change, but they weren't sure how it would change. The drafters wanted to provide flexibility so that banks and their business customers could innovate as the years pass. In so doing, they treated each party as a grown-up with real responsibility and risk.
It is not clear that the banks in cases like this (I'm not passing judgment on any particular case) will win under UCC 4A. A key issue is whether the bank used a "commercially reasonable" security procedure — a flexible idea intended to fit the situation. It is very possible that a court would find that as of 2010 (thanks in part to Brian’s reporting over the past 6 months) that a commercially-reasonable security procedure must include something like transaction-specific evaluation/authentication. –Ben
if I have read Brian’s work correctly, ANY multi-factor authentication system is vulnerable to the crime rings using the Zeus trojan.
It simply doesn’t matter if the second factor is algorithm generated, e.g. RSA key fob or out of band like SMS transmitted code to the cell phone.
The inherent flaw is that the submission of all credentials is done through the same channel – the browser connection.
As Brian detailed in one post – a real-time automated man-in-the-middle attack provides a dummy bank page to the users or replace HTML code to show that the system is down for maintenance – please return in 15 minutes. Meanwhile the attacking system is submitting all the credential before they can expire
Brian has suggested two ways to avoid this pain – bank on a MAC or from a clean Linux install, e.g. from a LiveCD.
Some have posters suggested that banks should require entering the authentication code for EVERY TRANSACTION, not just logon.
I have spent a lot of time evaluating vendor solutions and was very disappointed with the emergence of the Zeus attack because I had focused on several out-of-band second factor authentication methods including Verisign’s VIP program which likely would have seemed more impressive to clients than the various South African SMS solutions which may have been preferable because they do not require joining the VIP consortium.
My interest is for a client portal allowing with the ability to view and upload/download private documents. I am not looking to authenticate transactions.
Does anyone know of any vendor offering the user a way to SUBMIT the authentication code out-of-band and integrate it back to the portal?
Maybe SMS….please text your account name and pin to 55555 where the back end picks off the account name to and then uses the PIN to authenticate the activity occurring on the website, e.g. Krebs1234 is distinguishable from Ohio1234.
I know the SMS example is weak, I just can’t think of a simple, secure way to submit an authentication code away from the browser.
I would be happy to walk you through our out of band product. I don’t know if it does exactly what you’re looking for but you can complete transactions out of band without entering anything else back into the browser. I can be contacted via http://www.breakpointllc.com.
The key is to at least confirm the transaction details with the user through the second channel, instead of just providing an OTP through the second channel. So you SMS them the details (“ACH $12,357 from acct 130283 to 40280. Confirmation code 128301”) then have them enter the confirmation code. Now they at least have the opportunity to review the details. Completing the transaction out of band is even better.
That’s if you want to involve the user… As I mentioned above another effective approach is for the bank to use a transaction fraud monitoring engine.
All these alternative solutions share the same premise: people asking/looking for online business security solutions so they don’t get their transactions hacked, even when they know their own computers to be infected.
That’s really sound reasoning. A practical solution desperately searching for a theoretical opiate.
“a real-time automated man-in-the-middle attack provides a dummy bank page to the users or replace HTML code to show that the system is down for maintenance – please return in 15 minutes. Meanwhile the attacking system is submitting all the credential before they can expire”
And I would suggest that a valid argument could be made that this is not in fact a failure of a security token, but social engineering.
Gee, I wonder how a Zeus trojan could have been installed on Wolters’ computer.
I have the feeling that it may be because domains used for the well known IRS exploit, which installs this trojan, are allowed to remain active for 12 days in a row.
Some registrars will ‘recall’ the domain very soon after it is reported as fraudulent.
Some registrars monitor the use of their domains and don’t even have to wait for it to be reported to them before they ‘recall’ fraudulent domains. The same exploit was tried with two other registrars but the domains were taken down very quickly.
Some registrars are so good at verifying registrant information that the domains never get registered in the first place. A resistrar told me last week that a domain applicant asked him to please pass his credit card through as the domain was needed right away. The registrar checked with his financial unit and informed the applicant
that his credit card was on a blocked list, at which point the applicant hung up the phone.
The Computer Emergency Response Team for the registrar which has allowed the domain used for this exploit to remain active for 12 days will take down all reported fraudulent domains on weekday mornings.But new domains, and sometimes even the same domains, will be registered the same day. And if the domains are registered on a friday you can expect them to remain active the entire weekend no matter how many reports are received, no matter how obvious the fraud.
If we required registrars to consider domains known to be used for installing the zeus trojan an emergency and their emergency response team to respond 24/7 we could probably avoid the majority of these reported infections.
The registrar which has allowed these domains to be active was also reported on by the UAB in their blog: http://garwarner.blogspot.com/2010/02/phishers-target-bloggercom-accounts.html.
Although garwarner is reporting on a different exploit starting on the 21st of february, the same registrar and many of the same domains were used for the IRS exploit and many other exploits after being reported to the registrar on the 18th of february.
Of course we don’t want to name the registrar as this might appear ‘gratuitous’ to some sensitive readers even though naming the bank 8 times doesn’t elicit the same reaction. The UAB blog does show the country code ‘kr’ of the registrar and notes that their domains “have been favored lately by the Avalanche/Zeus group”.
The IRS exploit was also detailed last year on the UAB blog several times:
http://garwarner.blogspot.com/2009/11/zeus-zbot-malware-moves-back-to-irs.html
http://garwarner.blogspot.com/2009/09/irs-version-of-zeus-bot-continues.html
http://garwarner.blogspot.com/2009/10/weekend-of-old-news.html
It should be noted that several of the registrars for the country codes listed in the above reports have really cleaned up their act. Two of them were used in the recent IRS exploit and taken down very quickly.
The key, as Brian mentioned in a comment, is that banks have to start assuming that customers have malware. The entire small business and government banking community isn’t switching to a Mac or a Linux O/S any time soon.
Additional layers will help. As Brian mentions, authenticating the transaction, and not just an identity, out of band could help.
However, the business banking/cash management applications already have several tools that can be used to prevent many of these attacks. The key will be getting banks and customers to agree to use these extra tools. In general their use will make online banking less convenient. It will still beat going to the branch, if one is even available, to do your banking.
In this case it sounds like there is only one registered user for the entire company. That makes some of the options hard or impossible to use.
The other interesting piece is the timing. This was an ACH event and not a wire event. ACH transactions often have a day delay. That delay is fading. Several banks have already banded together to create same-day ACH clearing. The Federal Reserve is more widely implementing same-day ACH clearing this year. The business and banking community have desired same-day ACH for a long time but it will benefit the bad guys too.
I hope these guys make a couple of phone calls and get someone involved who is experienced with investigating these types of attacks. The mention of running multiple AV products as their incident response made me cringe.
Brian, i also agree that I am not sure there is a tech solution in regards to auth methods here. You hit it on the nose.
I think as banks begin to push back on where the liability lies for the fraud and customers begin to pursue legal action, then we may (may) see some real change (i hope).
T
Great discussion today on bank fraud, Brian. Could I change the focus for a moment to ask a few questions about an unexpected trojan on my computer?
I’m careful about where I download programs from, and frequently scan them at Jotti, but this one seems to have slipped through, unless MSE is showing a false positive. Because I got the BSOD a couple of days ago after the most recent MSFT patches, I ran Microsoft Security Essentials on the whole computer and it came up with “TrojanClicker:Win32/Yabector.gen” located inside a utility’s installer file which I’ve had in my external drive’s downloaded file storage area for over a year. The program associated with that utility installation file is Unlocker, which continues to run on my computer. Perhaps I should mention it’s title bar calls itself LockHunter rather than Unlocker. MSE didn’t flag it or any other program or file as problematic.
The MSE warning was this:
unlocker1.8.7.exe->(nsis-6-eBay_shortcuts_1016.exe)->(nsis-1-eBayShortcuts.exe)
Questions: while MSE removed that infection identified within the program installer for Unlocker/LockHunter, as well as the original installer file itself, am I really safe? Wouldn’t the Win32/Yabector.gen have been unleashed something to parts unkown in my computer at the time I installed Unlocker a year ago? If so, how do I identify and get rid of it’s tentacles? Should I remove the program file Unlocker/LockHunter too? Could my data be compromised? I’ve done the Drop My Rights thing.
Thanks for your continuing columns helping us to stay (or get) safe! –BB
http://lmgtfy.com/?q=TrojanClicker%3AWin32%2FYabector.gen
Bill,
You can upload the suspect file to http://www.virustotal.com to get an idea of how a number of AV programs view the file.
The Generic virus defs are prone to false positives
Either it is an inside job by someone at Swift Financial or Mr. Wolters’ computer is infected.
He said that he scanned his system for malware. But was that done when the OS wasn’t loaded? Because a rootkit can hide itself when the OS is running.
On a preventative measure, was he running as a full administrator on his system? If so, game over! That’s breaking a cardinal rule of a defense in depth strategy, especially for a system used for sensitive tasks such as this. Running as a n0n-admin would’ve prevented a rootkit from infecting the system.
Reminds me of the top two laws of “10 Immutable Laws of Computer Security”,
http://technet.microsoft.com/en-us/library/cc722487.aspx
Law #1: If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore
Law #2: If a bad guy can alter the operating system on your computer, it’s not your computer anymore
I agree that something sounds fishy and hope that you would be right on the first point, but also believe that I’ve read that the Zeus trojan is effective even if someone is running as a limited user in Windows. That’s certainly been a hot button for Brian over the years.
I think it’s why he’s only recommended two secure ways to do corporate banking and neither involve Windows.
Two words: dual controls. Two more: implemented properly.
I agree that dual controls with proper authentication would make it a lot harder to do much with a hijacked session.
In my opinion, banks are reluctant to require dual control because many clients (for many reasons) want to allow one employee to initiate and approve transactions.
Again — it’s a balance between better security and trying to retain clients.
Hey! Brian!
You’ve been quoted on
“The Register”, U.K.’s acerbic and witty website-commentator on all things Internet.
….”The reports are only the latest to chronicle the growing use of skimmers to scam holders of payment cards and the banks who issue them. In December, police reported that at least two dozen victims were compromised by skimmers places at an AM/PM gas station in Rocklin, California.
A recent item on KrebsonSecurity features a bevy of photos that show just how well the devices blend in with their surroundings, making it hard for even savvy consumers to detect them.”…
Congratulations on your fine new website.
It could be a missed detail, but I am surprised that once alerted, to a possible breach the computer in question wasn’t isolated and inspected asap by a forensics pro.
Wolters may have inadvertantly destroyed the eveidence that would help his case, or at least made any future inspection of the computer subject to doubt
The obvious red flag is recently transferred funds being wired to a country with lax law enforcement by someone who has not previously wired anything anywhere. Unfortunately, it’s not obvious to the victim’s bank, due to the intermediate step involving the money mules.
Perhaps U.S. banks need to isolate countries where this fraud is rampant. For instance, the first time a depositor wants to wire money to an at-risk country like Romania, especially if the funds have been deposited in his account within the previous 14 days, he must appear in person at the bank. He would be required to read and sign off on each section of a document that explains what a money mule is and holds him responsible if he participates in such a scheme. It’s a small inconvenience for someone with family in Romania, but it would force the scammers to start wiring the money to countries where there is more risk of being arrested. If any bank fails to screen its wire transfers that way, then the banks that cooperate with the system would insert a delay before transferring any funds to them from their own clients’ accounts.
If you think of it, it’s rather strange you can wire thousands of dollars of someone else’s money halfway around the world far more easily than you can take a pair of shoes on an airplane.
I posted earlier a well-meaning compliment to Brian Krebs concerning his being quoted on the U.K.’s “Register” blog on security issues. Shows that he’s being widely read.
Lo, some jerk has clicked on the “dislike” button for that well-meant post.
What’s a guy to do here?
It is a mystery. Let us know when you find out the answer to that one Charlie.
So if the ACH added 10 “new employees” for payment…how was their payroll changed to account for these 10 new employees?
I don’t think the hack required 10 other “co-co-conspirators” – but even if it did, those would be easy to find in the blackmarket.
Sound very a lot like other payroll hacks..
http://voices.washingtonpost.com/securityfix/2009/10/paychoice_suffers_another_data.html
The banking industry must slow down certain higher risk transactions. Back in the day banks used to withdraw the funds to a clearing account then send funds the next day or even two days later. Banks receiving funds might hold them for one day. All this led to tighter regulations by the Fed to make funds available as soon as possible. Commercial banks didn’t necessarily want Reg CC, it was imposed. Float can help identify fraudulent transactions. (Yes commercial banks will make some money on this.) But customers have to be vigilant too. This customer called back the next day? Sorry Charlie, that money is gone! Holding that transaction one day internally might have saved the day.
For customers that are demanding faster settlement of transactions, then enforce, extensive security such as Out of Band Authentication. Only make available. Just open thoughts.
Brian,
Interesting article… it really generated a lot of good comments.
If they don’t do core level of Integration between their software and the Biometric Technology then this sort of issues may come often. Beside this, Core level of Integration will allow to keep the user detail in the database, not the user name and password only.
The writing seems to me that the fingerprint was just assigned for some previously used User Name and Password to access in their account. If this is so, then there is no chance to secure the system by that. Banks or Insurance companies should deploy the latest Biometric Authentication like Finger Vein or Palm vein to authenticate their employees and members.
Really sad one….But true. We have to keep a very significant lesson from this. We should be well prepared to prevent any type Technological fraud at this era, we cant afford to take any risk of security whether it is related to any sensitive issue. So I do believe the Accounting-Transaction system of every bank should be integrated to the latest biometrics technology , from there every user can be identified very easily. Not only that but also no body can have any transaction of the system before the enrollment to the system database. I really find no other alternatives of preventing these.
what a nightmare! So sad.. something still left to learn! ha…