Computer crooks stole more than $200,000 from an auto body shop in Ohio last month in a brazen online robbery. The attack is yet another example of how thieves are using malicious software to bypass bank security technologies that are often touted as strong deterrents to this type of fraud.
The latest victim is Clarke Collision Center, an auto body shop in Hudson, Ohio. According to Craig Kintz, owner of Kintz Tech, a local security consulting company that responded to the incident, on Feb. 23 an employee of the victim firm noticed something strange when she went to log in to the company’s online bank accounts: The site said the bank’s system was down for maintenance.
Clark Collision’s bank, Cincinnati-based Fifth Third Bank, requires business customers to enter their user name and password, and a one-time passcode generated by a battery-operated key fob that is synched up to the bank’s back end servers. This approach — what banking regulators call “multi-factor authentication” — involves asking the user to provide something they know (a user name and password) in addition to something they have (a code generated by a security token).
But Kintz said that when the body shop employee visited the bank’s site and entered her user name, password and the output from the security token, she was directed to a page that said the bank’s site was temporarily unavailable. The page she was sent to even included a 1-800 number supposedly for the bank’s customer service line.
Kintz said the woman called that number, but quickly found that it was not in service. When the employee looked up the real customer service number for the bank and called to complain about the suspicious activity, she learned that there had just been a large number of wires and money transfers out of the company’s accounts to individuals in the United States and overseas, Kintz said.
“She reported it to the bank at 9 o’clock that morning,” Kintz told Krebs on Security. “By 11:30 a.m. the bank had frozen all of the company’s accounts, but by that time those accounts had all been emptied.”
Kintz said Fifth Third was able to reverse or stop payment on all of the fraudulent bank-to-bank transfers that were sent to money mules involved in the scam — willing or unwitting people in the U.S. hired by the perpetrators — but that Fifth Third was unable to reverse the wire transfers that constituted the bulk of the fraudulent transactions. Still, he said, Fifth Third ultimately made Clarke Collision whole, crediting the company’s account the remaining missing money.
Whoever hit Clarke Collision Center’s bank account was busy that day: Kintz said a bank manager told his client that four other Fifth Third business customers had been similarly attacked that very same day.
I sought comment from Fifth Third, but the bank declined to discuss any specific customer cases. Whitney Ellis, the bank’s assistant public relations manager, sent me the following statement via e-mail:
In regard to the commercial malware issue, Fifth Third Bank, as well as many other banks, has been alerted of a new wave of cyber attacks aimed toward businesses and corporations to get financial information. The Bank is determined to help its commercial clients ease this threat via aggressive customer education and additional tools to aid in the prevention of possible attacks.
For those that have been affected, we are working with the customer and proper authorities to try and rectify the situation. We have been, and will continue to be in contact with our clients in aggressive customer education and sharing best practices to help prevent these type of cyber crimes.
‘four other Fifth Third business customers had been similarly attacked that very same day’
That’s creepy. But it’s also sophisticated. Welcome to the majors, dudes. The game’s ‘hardball’. ;/
I am curious about how the attackers got the user to the fake website in the first place – was DNS cache poisoning involved?
John — In every case I have investigated, the crooks had installed malicious software — usually the ZeuS Trojan — on the victim’s PC. This allows the criminals to control what the victim sees in his or her browser.
ZeuS will re-write the bank’s HTML on the fly, and inject HTML elements into the bank’s page. Mind you, they are not altering the bank’s real site — just what the victim/customer sees.
As I have noted in many previous stories, no authentication system works if it does not start with the basic assumption that the customer’s system is *already compromised*.
As such, the main way for banks to detect this type of fraud is by profiling what’s “normal” for their customers’ activity, and alerting when something that drastically deviates from that activity surfaces.
This is the old “know your customer” approach that most banks have either ignored or outsourced.
Exactly Brian, knowing your customer. And you don’t have to be a small bank to know your customer. My bank is as large as 53 and it will question something as small as $10 if it deviates from the norm. At least 53 “made Clarke Collision whole”. That’s obviously more than many banks would do.
Thanks for keeping everyone aware of these incidents.
I have a Fifth Third account, and they have caught “out of profile” (and fraudulent) transactions before. I wonder if there’s a bug/gap in their profiling?
Yours is personal and theirs was business perhaps?
Other posters to these reports have banks that also require the token to authenticate transactions — not just the initial login and then complete freedom to do anything at all. Do any U.S. banks offer this?
Even my webmail requires me to login again to do certain things. If whitelisting and trend monitoring are too hard, what makes this option a no-go?
Once the trojan has control of the browser they can easily control what the user see’s and does as the generic digits the token provide give no clue as to what exactly the user is authenticating. For example if the bank requires an extra token authentication after the login it is easy for the trojan to bump the user to a “session expired.. please login” message to get the user to enter in a new valid token code the trojan can then use in the background to validate an outgoing transfer. Many trojans also record the original balance amount and display this amount in the future so the user never even knows they have been robbed until a paper statement turns up.
From what I understand, if the bank required an authentication for each transaction, it would at least limit these. The attackers make multiple transactions under the $10,000 reporting limit, sending them to multiple money mules. If the user has entered only one transaction and is asked to authenticate additional ones, he/she will likely get suspicious no matter what the browser says.
Backend fraud detection (i.e. transaction whitelisting, trend monitoring, etc.) isn’t really that hard.
As pointed out, authentication tokens (MFA – Multi-Factor Authentication) don’t work against today’s real-time online banking threats. However, they did generally address the prevalent threats 5+ years ago, which were non-real-time threats like session replay and username/password stealing. MFA is just not the solution to today’s online banking problems.
With MFA solutions, banks and financial institutions can more easily pass on the costs of this “added security”. MFA is something tangible the customer can “see and touch”, is relatively easy to market the perceived benefits, and can provide reasonable margins for the banks and financial institutions.
The problem with backend fraud detection services is not that they are hard, but that they can be difficult for banks to pass the additional costs for these services on to customers. Since the services are mostly intangible (“invisible”) to the customer, it is harder to market the real benefits of these services to customers. Also, most online banking customers already expect their bank to be doing all these backend fraud detection activities (e.g. like they get with credit cards) as part of their online banking operations, so customers will wonder why they need to pay additional fees for the protections they thought they were already getting from their bank.
The problem is, today, a lot of banks (esp. smaller banks) don’t include backend fraud detection services as part of their online banking solutions. These are services which should have been in place from the beginning, so it now becomes an additional cost that needs to be factored in.
The banks didn’t have any trouble figuring out how to add fraud detection to credit card accounts (it wasn’t built in from the beginning there, either). The difference? They had liability for the fraudulent card activity, and have nothing to lose if their commercial customers are wiped out due to online banking/wire transfer fraud. Until the banks are required by law to protect the assets of their commercial customers, they simply will not care about fixing this problem. (They generally do offer fraud guarantees to their consumer online banking customers, presumably because the amounts involved are small enough that they can cover the loses without having to actually fix the underlying vulnerabilities.)
Brian,
At RSA 2010 an old-timer mentioned that it is really easy to hack your typical home or small- and medium-sized enterprise router remotely to set its DNS server IP address to whatever you want. I don’t know if the router is addressable from the general Internet or whether one must run something in the user’s browser to turn around and address the device. But note that this is an attack upstream of the PC and downstream of the ISP that no trace of its presence needs to be left anywhere where a malware scanner would find it.
While I appreciate that all the losses you know about involve permanently compromised PCs, the fact that there are attacks at least *possible* upstream (known, unknown, and “unknown unknown”) just reinforces you point that the financial services institutions need to follow the “X-Files principle” (TRUST NO ONE. (But the Truth Is Out There.)
Brian: Reading the article, it sounds like the person at the company did the obvious right things: followed up quickly, was suspicious, etc. So what is missing in the article is what should have been done differently: how could a company detect that this scam was in progress (especially if the ZeuS was present)? That’s the lesson that needs to come out of this: how do we educate to make people more alert.
At least we know one bank that does not leave the small business customer holding the (empty) bag. I’m just curious why it took 2-1/2 hours to freeze the company’s accounts after notification from the company employee about the fraudulent activity.
Fifth Third hasn’t left their customer holding the bag – this time, so far. They could still reverse course ass has happened with other banks in other cases.
With five known victims in one day (and who knows how many more to come!) it seems likely that Fifth Third might not be able to continue to make good to every customer that gets hit by this.
We’ll see.
as long as the bank didn’t use the term “provisional credit” this means they can take your money back as they did with our loss, the “provisional credit” makes you feel good for a couple of days then they pull the rug out from under you again.
@BK
“… that most banks have either ignored or outsourced.”
With the result that their customers are up a s**t creek without an “or” fighting robbery with both “and” tied behind their back.
I, too, wonder why, after being notified of a potentially very serious problem at 9 AM wire transfers continued to be sent from that business account for another 2.5 hours. What’s up?
This MITB attack would not have been possible if the bank was using passwindow authentication in their bank cards instead of the generic user authentication given by the key fobs. The employee would have known as soon as she superimposed her card someone was trying to authenticate an outgoing transaction from their account. The trojan would be unable to authenticate the transaction without gaining the authentication code from the user’s manual superimposition.
The only alternative protection I can think of is the bank requiring transaction signing by a more complex transaction signing token with built in keypad and a series of back and forth cryptographic checksums between the user, device and terminal which include transaction information such as the account destination number however it isnt a very elegant solution often requiring over 40+ digits by the user regardless of the transaction amount.
The solution to this problem is transaction authentication not user authentication.
As soon as the passwindow authn is entered, the bad guy controlling Zeus would just redirect user to ‘website’ out of service msg.’ and carry on their business. How does this help?
The user wont enter the authentication code for a transaction which is clearly designed for an unknown destination account. Unlike the electronic tokens it is not just generating generic OTP’s which can be switched but is easily able to encode key transaction information such as the last three digits of a destination account number or transaction amount into the actual visual challenge itself. The actual authentication code is placed alongside this information in the animated visual loop so the user must see it as they go and be aware of what they are authenticating.
http://www.passwindow.com/security.html#man_in_the_middle
Without knowing the users physical key pattern the trojan is unable to modify the visual server challenges without destroying the visual challenge itself, leaving the user just seeing noise. Even by keylogging the users previous historical responses and analysing the associated visual challenges for them the trojan is unable to deduce enough information about the key within the many years lifetime of the users card. The information leakage is predictable and requires many thousands of interceptions by the trojan.
In short there is nothing any trojan can do against passwindow authentication, I realize it is a big call but there it is. Even a basic denial of service attack would be almost impossible considering a user could easily pull the animated challenge gif up on their phone or any device with a screen and internet if it suddenly stopped working on their PC.
Yes, the insecure user-to-bank side of the traffic confused me as well because trojans can read/steal everything the user sends to the bank but I think I’ve got it now. The key to understanding PassWindow is PW makes the bank-to-user side of the traffic absolutely secure (until the user’s PW card pattern is broken). The user-to-bank side of the traffic remains insecure but this doesn’t matter with PW because secure bank-to-user traffic allows the bank to safely send single-use passcodes to the user that are associated with transaction details. Sent-to-bank-by-user passcodes are read by but are useless to trojans for future transactions because they are single-use (but can be used to break the user’s card pattern). Here’s how PW might work. The bank sends the user a PW image containing a transaction detail and passcode. For example, PW=xx3xxR789x means the user should return passcode=3 to confirm bank Routing number ending in 789 with x=unresolved. A 2nd image PW=xxxA321x5x means the user should return passcode=5 to confirm Account number ending in 321. All is safe as long as trojans cannot decode the 3 and 5 passcodes behind the user’s back. The user should not return a passcode if its account detail is unrecognizable (possible mule account). It’ll likely not even get this far because several PW challenges may be issued just to set up a mule account. Yup, it’s a bit cumbersome but seems workable though all’s lost once the user’s card pattern is broken.
Yes you’ve got it, the concept is radically different to any other authentication system out there but once you understand it is very simple. Actually I like to think the security is in the simplicity because by eliminating electronics, standard cryptography and injecting a simple human physical/visual action, the normal cat and mouse authentication failures don’t apply. There is just no way an online attacker no matter how complex is going to hack into a plain printed key pattern and steal the key.
In the demonstration for transaction authentication I usually use Pxxxx for the password and then Axxx for the last 3 account digits and then just loop it around but there is many ways it could be done and it is entirely flexible on the amount of digits used or characters to reference, T could = total for example.
The only possible angle of online attack is statistical analysis by the trojan of the screen challenge and the associated keylogged user response. Every time a user authenticates it does actually lose a tiny bit of predictable probabalistic information about the key so we’ve done lots of research on this sole attack. The results are great with it being very easy to put the necessary number of interceptions by the trojan well over 10000 or even higher magnitudes by changing simple aspects of the challenge picture, so lets say a user authenticates into their account once a day the trojan would need to wait around for 28+ years worth of authentication data by the user to correctly analyse the users key. Considering most cards are replaced every few years I don’t consider this attack feasible. This interception amount isnt set in stone either there are a number of basic multipliers which don’t affect usability at all and can easily multiply this interception rate but it seems unnecessary.
From a personal (in person) attack angle I like to think the security is pretty strong too. Being kept in your wallet instead of a hardware token floating around your desk seems much more secure and user friendly. Discreet photographic attacks (as in a hidden camera around your office) are pretty remote too with a simple transparent tint effect printed around the key pattern the attacker literally needs to get the card out of your hands and into a specialized photographic setup with a backlight. This seems as unlikely as me lending my house keys to a stranger. There are a lot of cheap open methods to protect the visual key pattern from transflective laminates to electro chromatic pressure activated cells, depending on the level of paranoia.
Anyway thanks for taking the time with a new idea, I am putting all this out here as a solution to the problem and it’s great to get any feedback.
> The only alternative protection I can think of
> is the bank requiring transaction signing by a
> more complex transaction signing token with
> built in keypad and a series of back and forth
> cryptographic checksums between the user,
> device and terminal which include transaction
> information such as the account destination number
> however it isnt a very elegant solution often requiring
> over 40+ digits by the user regardless of the
> transaction amount.
When the only “solution” that you can think of involves requiring a user to enter 40 random digits to secure every payment, it’s obvious that the information security industry needs a new acronym!
How about “TOOBA” (“Totally Out-Of-Band Authentication”)? If everything that goes through Windows is insecure, then don’t use Windows. Place a phone call!
If you think about it, the only transaction that requires this level of security is the addition of a new payee, and that is pretty rare. The bad guys can’t profit from your sending some extra bucks to someone you already do business with.
Gee, whiz. The only thing that *really* has to be secured is the addition of a new payee.
I agree the weak link in the banking chain is authenticating those outgoing accounts, much easier on the user than authenticating through hoops with every single transaction and usability is a key part of any security solution.
I didnt mention out of band authentication primarily as I was only thinking of authentication solutions which seem to be complete solutions, not alternatives which shift the problem into different areas.
The 40 digit reference is with regard to hardware tokens which can docryptographic transaction signing and their user process which I have outlined more clearly below in response to Dalmatian90, sadly they are not random digits (which would be a little more user friendly) but very specific challenge-response checksums between the device and the terminal which include transaction information.
My concern with TOOBA as well as shifting to more obscure operating systems is it doesn’t provide a “secure” theory underlying it. Their phone trojans could just as easily record these conversations (which some do to an mp3 and upload out later) compared with what they are doing in the article above. A friend of mine who developed the cryptography behind a major brand of hardware token once lamented that the real security of their tokens was reduced to “knowing the user’s mother’s maiden name” because an attacker could just ring and answer this question to bypass the authentication. Constantly moving the authentication target so far has failed at stopping authentication fraud which is essentially what we are dealing with.
The most widely used out of band authentication is SMS mTAN’s, adopted as a lower entry cost solution by some banks however it comes with an entirely new set of problems in many ways worse than the old. For a start if a hacker can get their payloads such as Zeus into your computers running the most up to date trojan detectors then you can believe they can get a similar payload onto your mobile phone which doesnt have any protection. There is a slew of other problems with SMS listed here http://www.passwindow.com/security.html#sms
As Brian said you have to assume the user’s system, be that PC, Laptop or Mobile, is *already compromised*, I would personally like to add to that with *and the attacker can control every aspect of the compromised system*. From this angle it is better to work backward from what we know is secure and then consider the other two important aspects which is usability and price, neither of which can be ignored. I know the token transaction signing and the passwindow method can’t be circumvented under this situation so we at least have a starting point, if anyone else has any ideas they are welcome to throw them in.
>So what is missing in the article is what should have
>been done differently: how could a company detect
>that this scam was in progress
The company *did* detect the scam was in progress; that is why they called the bank.
Preventive measures include technical and process controls.
Technical control would be having either a dedicated PC that just does online banking (to reduce vectors for infection from general emails and web surfing), or even more reliably a boot CD so you know you’re running a known, good configuration.
Process controls are having two people required to complete transactions — i.e. the bookkeeper initiates the transfers, the owner (from a separate PC) authorizes each one.
In a case like this where the bookkeeper noticed something was up, the transfers would’ve been sitting in a queue waiting for a separate authorization.
A very sophisticated man-in-the-middle attack against two PCs could try to subvert that process control with the systems I’ve seen (such as using one-time use authorization codes) — you show both people fake “regular” transactions such as sending $1298.37 to pay your monthly Amex bill, and getting that authorized…but back at the banks end they see a transaction for $9,987 to NAPA of Kazakhstan.
When the criminals start taking the time to be that sophisticated, you’ll need transaction authentication devices that the approver would punch in the amount of the transaction in order to get a one-time, padded authentication code that validates the amount.
Then the crooks won’t be able to alter the amount or number of transactions; they could still divert it to another recipient (i.e. $1298.37 to NAPA of Kazahkstan instead of Amex) , but its a less valuable fruit and they haven’t drained the account in doing so.
As I’ve said before, these improved controls come with a cost. While they hit individual businesses hard, it is not clear to me they threaten the broader economy — yet. Maybe in the future, not right now.
We’re still in the area where it is probably cheaper and easier to insure most folks against losses then to implement better preventive controls.
An analogy is fire protection in the U.S.
Fire insurance remains the primary line of defense against loss for most people.
Some higher value properties have fire alarms and sprinkler systems as technical controls in exchange for lower premiums, and/or complying with government regulations mostly aimed at reducing public protection costs.
Public fire protection is largely oriented not towards preventing or minimizing individual losses but life safety and keeping fires from involving multiple buildings. Conflagration prevention is the bias found in the ISO Rating system that helps set insurance rates, and even the latest career fire department staffing standard — NFPA 1710 — doesn’t try to justify a four minute response time by the fire department on the basis of fire control, but instead on the basis of delivering emergency care to heart attack victims.
Sure, we could reduce fire costs and deaths dramatically if we mandated retrofitting every building in the nation with sprinklers within a decade. Be a heck of a jobs program, too. But it wouldn’t be economical.
I suspect really tight controls fit this same category right now. We could eliminate it, but right now its cheaper to insure against loss then prevent the loss.
What we need to do is pressure that the insurance burden is born by the banks in this case. Let that industry bear the cost and make the decisions when they need to invest in improved security.
“When the criminals start taking the time to be that sophisticated, …”
They are. Look at how they are defeating CAPTCHAs. This attack to defeat two-factor authentication was pretty sophisticated. Time to face the unpleasant news, the bad guys are winning the arms race.
as for the fire insurance analogy, although fire insurance is part of the equation we also have electrical codes and fire codes and lots of other preventation measures. The reason catastrophic fires killing hundreds of people are as rare as they are these days has more to do with fire prevention and less to do with insurance IMNSHO.
For example, sprinklers are required for rental housing in many jurisdictions. That’s something that would not have happened without government regulations, was argued as too costly when those regulations were being designed and yet has paid off in saving lives and property.
We need to take a similar view of this problem with online bank robbery. Small businesses, or even all businesses, should be given legal protection for funds in the custody of their bankers. The bankers have already demonstrated their diligence in careful execution of fiduciary duty in other areas, this one needs remedies too!
>however it isnt a very elegant solution often >requiring over 40+ digits by the user regardless of
>the transaction amount.
I didn’t touch in it in my last post…
You wouldn’t need the whole forty digits.
Giving people two sets of four digits with a space between is pretty easy for most people to deal with typing in accurately — say “23ex wq89”
Providing the eight digits of a salted hash is the equivalent of locking your front door. The chances of a collision where two amounts have share the same eight digits is very, very low.
For extra security, the bank can chose different offsets for each customer used to chose the characters (i.e. one customer types in the 3rd through 7th, and 20th through 24th digits of the hash, although all they know is the device magically gives them eight characters to type in).
Combine the above — a hash that consists of the dollar amount + authorizer’s ID, a unique salt for each device, and a choice of digits that change per customer you end up with very high security but still human-usable.
Providing the full 40+ digits is having steel shutters that roll down and cover your windows, and there is a layer of steel between your outside and inside walls, to discourage all but the most hard core attacks. Military planners might need that, not Joe’s Garage.
Yes I agree with your points however I was talking more about the user mechanics of authentication on all the transaction signing devices I have seen (not that I am an expert on these devices) usually go like this
step 1 – 4 digit pin into device to power it up.
step 2 – The login, Enter server generated generic 6 digit challenge into device gathered from the website.
step 3 – Complete login, Enter device generated 6 digit back into the website. (So far these generic authentication codes are entirely subvertable by the trojan)
step 4 – Prepare transaction, enter into device new 6 digit server generated transaction code.
step 5 – Enter into device 9 digits of destination account number.
step 6 – Enter into website resulting 9 digit authentication code from the device to finish transaction.
4+6+6+6+9+9 = 40 digits.
It is the same for any value of transaction with the devices.
The good point is trojans cannot easily subvert such a system where transaction information such as the destination account number is entered into the device and then the hash of that is entered back to the server. However I am not sure this is a feasible solution for the general population, perhaps with extremely high value transactions but I honestly feel after 10 actions per transaction many people will be annoyed on a day to day basis.
PassWindow simply shows the transaction authentication code to the user along with the transaction details such as the last 3 digits of the destination account, the user only needs to enter in say 4 or 6 authentication digits directly into their terminal and thats all.
Ah, gotcha.
When you said 40 digit, I was thinking typing SHA1 hashes back and forth.
Another good post Brain.
I particularly like the statement “…brazen online robbery”. It is good to see more references to what these crimes actually are – bank robbery- not some nebulous “cyber crime”.
Although, it is important to note that the crooks stole $200,000 from the _bank_, not the auto body shop. This money was in the bank’s custody which they were protecting on behalf of their customer, and as you state, the bank’s security systems failed to provide adequate protection, which resulted in the bank robbery.
Also, Brain’s statement regarding online banking is so profound, it warrants repeating:
“As I have noted in many previous stories, no authentication system works if it does not start with the basic assumption that the customer’s system is *already compromised*. ”
This should also be the _first_ requirement for any online banking application/product.
Marty — To your point about from whom the money was stolen, the body shop did not have the money for nearly two weeks. So, while you are correct, in that the bank was the one that lost money in this case, companies that go through this often are without that operating capital for the duration of the incident.
More to the point, the bank was under no legal obligation to make good, based on the protections afforded to commercial accounts by law.
The fact that they chose to do so in the interest of customer good will does not alter the fact that the money was stolen from the body shop. It’s like the insurance company paying your claim when something is stolen from you, the theft stole your property, it didn’t belong to the insurance company any more than the contents of the body shop accounts belonged to the bank.
This was a bank robbery. That the criminals used a computer to steal the money from the bank instead of walking into a branch with a gun, makes no difference. It is the bank’s job to protect their (the bank’s) money regardless.
I don’t see how the insurance example applies to bank robbery.
Banks take their customers money, store it along with all their other customer’s money, and then use all that money for other purposes. Part of this “deal” is that the bank takes on the responsibility of protecting the money provided to them by their customers (so they can give it back at some point), which is why banks have big vaults, guards with guns, cameras, sophisticated security systems, etc. In this case, the bank failed to protect the money entrusted to them by allowing an untrusted device to access their computer systems, resulting in a bank robbery.
“no authentication system works if it does not start with the basic assumption that the customer’s system is *already compromised*.”
If the customers system is already compromised, no amount of authentication is going to matter. It comes down to the first two Immutable Laws of Security:
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
The key, as has been said already, is to prevent system compromise to begin with. Whether that involves a dedicated locked down Windows system, a non-Windows OS, or a bootable Linux CD. It’s all about minimizing risk which starts with prevention. If your system is compromised in any way, it’s game over! It’s not your system anymore. It belongs to the bad guys!
There is a difference between stealing someone’s banking credentials, and being able to do something with those credentials. If you steal someone’s online banking user name and password, but are unable to move money out of their account because the banks detects that the activity does not look like the usual activity from that customer, then those credentials are no good to the bad guys.
Brian, Thanks again for great coverage.
This story prompts me to ask (from a naive point of view): for this (and any other security risks), would the product Keystroke Inteference be of any help? It claims to defeat keystroke logging by inserting random keystrokes.
Duke
Nope. ZeuS and other malware steal credentials less through keylogging, although they do have that capability. The primary way they steal credentials is through “form grabbing,” swiping out the information submitted into forms (think username and password form on a bank site) before it is submitted and sent off to the bank’s site.
I continue to be amazed that international wires are enabled for so many companies that don’t need them. Most if not all of the online banking applications can control this. The decision to allow everything or lock everything down is always a tough one but with companies under several tens of millions in revenues it is hard to believe that very many need international wire capability. Could be wrong but it seems worth asking.
If international wire capability is turned off the banks (customers) have a much better chance of getting their money back.
From the article it appears they didnt use international transfers but send the outgoing transfers to local money mules who then do the international transferring for a 10% cut thinking they are a legitimate payment collection agent. You may have seen the spam in your inbox which reads like a job advertisement.
“We of company XXXX (usually asian sounding company name) need a money collection agent to collect payments from our overseas clients.” “offer 10% of the payments as a wage”
They usually give some excuse why they cant get the money directly perhaps citing fictitious local money transfer laws. The applicant then gets large numbers of “client payments” arriving into their account which they then directly electronic telegraphic transfer out to XXXX country who has bigger problems than dealing with foreign countries electronic crime units. Sometimes they also use the 419 criminals favorite money transfer vehicle Western Union.
When I first saw this type of fraud 10 yrs ago I thought it was some kind of drug money laundering operation and I believe that it is also often modified so that the applicant is receiving lots of electronic goods packages, the result of stolen credit cards. The scam usually continues until law enforcement knocks on the door at which point the applicant points to the job application forms (which sinisterly include all their personal information usually including a copy of their passport). Interestingly whenever I read these reports I always wonder how many of the mules know exactly what is going on but conveniently play dumb once anyone comes looking, I have never heard of a mule being charged and I imagine it would be a difficult thing to prosecute.
More to the point there are multiple solutions out there to this problem which would stop this whole problem not just bandaid it. Many online security forums have a distinctly defeatist attitude at the moment which is not warranted.
I think you’re right in most cases: Mules are people who are very naive about money and fraud. They hand their own identity to thieves in a scheme where they can’t hope to hold onto the profits once they are found out. They should be suspicious about jobs that pay too much for too little work, but who hasn’t wondered what the top business executives do for their $3 million/year salaries? It’s not like the boss is doing work that is more physically demanding or more unpleasant than the work done by the lady that cleans the toilets all night. Free market principles don’t seem to apply. So the little guy tends to think that getting salaries an order of magnitude higher than anything he’s ever received is a question of getting a lucky break, not a question of needing special skills for high-paying jobs.
But there are mules that sign up just before leaving the US, such as students graduating and returning to their home countries. Sometimes they manage to get out of the US before anyone comes to claim the stolen money. Those mules may well know what they are doing, as it seems unlikely they would sign up for something that would deposit their money in a bank in the US just before they leave, given the possibility that a SNAFU would delay the deposit until they no longer have access to the bank.
If I’m correct, the ZeuS based robberies have been going on for more than a year.
(referring back to the list you posted here, http://voices.washingtonpost.com/securityfix/victfin.htm – assuming I’m correct that the ZeuS trojan was involved in these robberies too.)
Are there no anti-malware fixes that work for this trojan family? MS Malicious S/ware removal tool, McAfee, Clam A/V, any of them?
I’m not trying to ‘blame the victim’ here, just looking for preventative measures.
There is a study on Zeus and anti malware which reads badly with only 23% detection rates http://www.trusteer.com/files/Zeus_and_Antivirus.pdf , considering how flexible the creative side of malware is I doubt anti malware software will be able to permanently fingerprint the new malware coming out. There is also an excellent article over at http://www.itworld.com/security/100320/security-industry-faces-attacks-it-cannot-stop
From the recent RSA conference which outlines the losing game of software only solutions.
I think like everyone here we would like to think there is a magic bullet to the general problem but history seems to show that once systems of any kind become complex the relative security decreases as attackers have more room to manoeuvre. I like to think of mobile phones in this regard, 10 years ago there were no trojans on their simplistic blocky operating systems, now that they are more like their complex feature filled desktop counterparts there is a slew of new mobile trojans coming out specifically to steal SMS banking authentication codes. As complexity increases security goes the other way and complexity is increasing in almost every facet of technology.
It seems like a company could make a killing producing a low cost proprietary network appliance for businesses and consumers that did absolutely nothing but connect to one’s bank. Yes. I realize this could be accomplished to some extent by using a Live CD on available hardware (due to its read only characteristics). But if manufacturers can create netbooks for $200 or less, they should be able to create a stripped down e-commerce/banking unit for a comparable price. My parents owned a WebTV a decade ago that cost them around $200 that allowed them to do just a few things: surf the web, send e-mails and print – no downloads or application installs.
we just bought an Acer dual boot netbook (Andorid/Win7) for this purpose. It is only used for banking, and from the Android browser.
As the owner of a small business, I can easily transport this netbook with me from office to home and on travel if needed. When not in use it is turned off.
Seemed like cheap insurance for about $300.
The use of a Limited user Account would have prevented the theft.
Malware can not change system files when executing as a Limited User.
The use of an Administrator Account for causal computer work, guarantees that malware will gain control of the computer. One drive-by Adobe Flash exploit is all that is needed.
If your users are Administrators, then those users are certain to become victims of malware.