Microsoft to Botmasters: Abandon Your Inboxes

May 4, 2012

If the miscreants behind the ZeuS botnets that Microsoft sought to destroy with a civil lawsuit last month didn’t already know that the software giant also wished to unmask them, they almost certainly do now. Google, and perhaps other email providers, recently began notifying the alleged botmasters that Microsoft was requesting their personal details.

Page 1 of a subpoena Microsoft sent to Google.

Microsoft’s unconventional approach to pursuing dozens of ZeuS botmasters offers a rare glimpse into how email providers treat subpoenas for account information. But the case also is once again drawing fire from a number of people within the security community who question the wisdom and long-term consequences of Microsoft’s strategy for combating cybercrime without involving law enforcement officials.

Last month, Microsoft made news when it announced a civil lawsuit that it said disrupted a major cybercrime operation that used malware to steal $100 million from consumers and businesses over the past five years. That legal maneuver may have upset some cyber criminal operations, but it also angered many in the security research community who said they felt betrayed by the action. Critics accused Microsoft of exposing sensitive information that a handful of researchers had shared in confidence, and of delaying or derailing international law enforcement investigations into ZeuS Trojan activity.

Part of the controversy stems from the bargain that Microsoft struck with a federal judge in the case. The court granted Microsoft the authority to quietly seize dozens of domain names and Internet servers that miscreants used to control the botnets. In exchange, Microsoft agreed to make every effort to identify the “John Does” that had used those resources, and to give them an opportunity to contest the seizure. The security community was initially upset by Microsoft’s first stab at that effort, in which it published the nicknames, email addresses and other identifying information on the individuals thought to be responsible for renting those servers and domains.

And then the other shoe dropped: Over the past few days, Google began alerting the registrants of more than three dozen Gmail accounts that were the subject of Microsoft’s subpoenas for email records. The email addresses were already named in Microsoft’s initial complaint posted at zeuslegalnotice.com, which listed nicknames and other information tied to 39 separate “John Does” that Microsoft is seeking to identify. But when Microsoft subpoenaed the email account information on those John Does, Google followed its privacy policy, which is to alert each of the account holders that it was prepared to turn over their personal information unless they formally objected to the action by a certain date.

According to sources who received the notices but asked not to be named, the Google alerts read:

“Hello,

Google has received a subpoena for information related to your Google
account in a case entitled Microsoft Corp., FS-ISAC, Inc. and NACHA v.
John Does 1-39 et al., US District Court, Northern District of California,
1:12-cv-01335 (SJ-RLM) (Internal Ref. No. 224623).

To comply with the law, unless you provide us with a copy of a motion
to quash the subpoena (or other formal objection filed in court) via
email at google-legal-support@google.com by 5pm Pacific Time on May
22, 2012, Google may provide responsive documents on this date.

For more information about the subpoena, you may wish to contact the
party seeking this information at:

Jacob M. Heath
Orrick, Herrington, & Sutcliffe, LLP
Jacob M. Heath, 1000 Marsh Road
Menlo Park, CA 94025

Google is not in a position to provide you with legal advice.

If you have other questions regarding the subpoena, we encourage you
to contact your attorney.

Thank you.”

Unlike most of its competitors in the Webmail industry, Google is exceptionally vocal about its policy for responding to subpoenas. This has earned it top marks from privacy groups like the Electronic Frontier Foundation (EFF), which recently ranked ISPs and social media firms on the transparency of their policies about responding to requests for information filed by the government or from law enforcement.

Continue reading

OpenX Promises Fix for Rogue Ads Bug

May 2, 2012

Hackers are actively exploiting a dangerous security vulnerability in OpenX — an online ad-serving solution for Web sites — to run booby-trapped ads that serve malware and browser exploits across countless Web sites that depend on the solution.

Security experts have been warning for months about mysterious attacks on OpenX installations in which the site owners discovered new rogue administrator accounts. That access allows miscreants to load tainted ads on sites that rely on the software. The bad ads usually try to foist malware on visitors, or frighten them into paying for bogus security software.

OpenX is only now just starting to acknowledge the attacks, as more users are coming forward with unanswered questions about the mysteriously added administrator accounts.

Continue reading

Advertisement

Global Payments Breach Window Expands

May 1, 2012

A hacker break-in at credit and debit card processor Global Payments Inc. dates back to at least early June 2011, Visa and MasterCard warned in updated alerts sent to card-issuing banks in the past week. The disclosures offer the first additional details about the length of the breach since Global Payments acknowledged the incident on March 30, 2012.

Visa and MasterCard send periodic alerts to card-issuing banks about cards that may need to be re-issued following a security breach at a processor or merchant. Indeed, it was two such alerts — issued within a day of each other in the final week of March — which prompted my reporting that ultimately exposed the incident. Since those initial alerts, Visa and MasterCard have issued at least seven updates, warning of additional compromised cards and pushing the window of vulnerability at Global Payments back further each time.

Initially, MasterCard and Visa warned that hackers may have had access to card numbers handled by the processor between Jan. 21, 2012 and Feb. 25, 2012. Subsequent alerts sent to banks have pushed that exposure window back to January, December, and then August. In an alert sent in the last few days, the card associations warned issuers of even more compromised cards, saying the breach extended back at least eight months, to June 2011.

Security experts say it is common for the tally of compromised cards to increase as forensic investigators gain a better grasp on the extent of a security breach. But so far, Global Payments has offered few details about the incident beyond repeating that less than 1.5 million card numbers may have been stolen from its systems.

Continue reading

Service Automates Boobytrapping of Hacked Sites

May 1, 2012

Hardly a week goes by without news of some widespread compromise in which thousands of Web sites that share a common vulnerability are hacked and seeded with malware. Media coverage of these mass hacks usually centers on the security flaw that allowed the intrusions, but one aspect of these crimes that’s seldom examined is the method by which attackers automate the booby-trapping and maintenance of their hijacked sites.

Google-translated version of iFrameservice's homepage

Regular readers of this blog may be unsurprised to learn that this is another aspect of the cybercriminal economy that can be outsourced to third-party services. Often known as “iFramers,” such services can simplify the task of managing large numbers of hacked sites that are used to drive traffic to sites that serve up malware and browser exploits.

At the very least, a decent iFramer service will allow customers to verify large lists of file transfer protocol (FTP) credentials used to administer hacked Web sites, scrubbing those lists of invalid credential pairs. The service will then upload the customer’s malware and malicious scripts to the hacked site, and check each link to ensure the trap is properly set.

A huge percentage of malware in the wild today has the built-in ability to steal FTP credentials from infected PCs. This is possible because people who administer Web sites often use FTP software to upload files and images, and allow those programs to store their FTP passwords. Thus, many modern malware variants will simply search for popular FTP programs on the victim’s system and extract any stored credentials.

Continue reading

Correction to Java Update Story

April 27, 2012

An earlier version of this blog post incorrectly stated that Oracle had shipped security updates for its Java software. Oracle did push out an update for Java earlier this month — Java 6 Update 32 — but the new version was a maintenance update that did not include security fixes. My apologies for any confusion this may have caused.

Skimtacular: All-in-One ATM Skimmer

April 25, 2012

I spent the past week vacationing (mostly) in Southern California, traveling from Los Angeles to Santa Barbara and on to the wine country in Santa Ynez. Along the way, I received some information from a law enforcement source in the area about a recent ATM skimmer attack that showcased a well-designed and stealthy all-in-one skimmer.

The skimmer pictured below is the backside of a card acceptance slot overlay. It was recovered by a customer at a bank in the San Fernando Valley who called the cops upon her discovery. Police in the region still have no leads on who might have placed the device. The numeral “5” engraved in the upper right portion of this skimmer suggests that it was one in a series of fraud devices produced by this skimmer maker.

Backside of an all-in-one ATM skimmer found this year at a bank in the San Fernando Valley area of California.

Continue reading

Help Kickstart a Film on Cybercrime

April 23, 2012

A deep sense of doubt and dread began to sink in halfway through our journey down a long, lonely desert highway from just outside Austin to coastal Texas. We were racing against the clock (we’d just scarfed down our third meal in a row at a roadside Subway shop), yet my minivan companions — a filmmaker from California and a husband-and-wife camera crew — seemed pleased with the footage we’d collected so far. I was far less sanguine about our prospects, and was almost certain that our carefully-laid plans to ambush a money mule on camera were about to unravel.

‘Money mule’ Geridana heading home.

The scheme was hatched by Berkeley writer/director Charles Koppelman, who’d emailed me in mid-2011 about the possibility of catching some money mules on camera for a documentary he’s working on called Zero Day. Koppelman said the money shot would be a mule coming out of a bank with a wad of cash in hand, but that he’d settle for an old-fashioned sit-down interview.

At the time, I was working with a source who was injected into the communications networks of several money mule recruitment gangs. These miscreants specialize in hiring willing and unwitting “mules” through work-at-home job scams. The mules then are asked to process bank transfers that help organized cyber thieves launder money stolen from small businesses victimized by cybercrime. The networks my source was monitoring indicated the gang was grooming between 75 and 100 mules across the country on any given day, and that they were sending fraudulent transfers to mules almost daily.

I told Charles that for such a plan to work, we’d need to focus on areas that typically held the most number of mules per capita, and that meant somewhere in Florida or Texas. When my source indexed the mules and sorted them by hometown, we discovered that there were five mules being groomed for payments within about 200 miles of Austin, Texas. If we rented a car and checked in with my source on a regular basis, we might be able to secure the footage he was after, I suggested.

But I cautioned Koppelman that I gave our plan about a 20 percent chance of working. I predicted that most of the mules would quit, screw up the transfer task, or be used and discarded by the time we flew down there and actually hit the road. Indeed, when we reached our fleabag motel just south of Austin on Aug. 3, 2011, my prognostication had almost come true entirely: We were down to one last money mule: Geridana, a young, unemployed single mother of two from Webster, a small town of about 9,000 residents in southeastern Texas.

On the morning of Aug. 4, we piled into the minivan again and raced down to Webster. We didn’t attempt to make contact with her until we were parked outside of her apartment complex, which was next door to a bail bonds shop. Turns out that Geridana was a bit of an oddity: The $9,000+ the thieves had just sent her was actually the fourth such transfer that Geridana had processed in as many weeks. The most pathetic aspect of the whole scheme? She never got paid her promised monthly salary or per-task commissions.

I’ll stop the story here, because I don’t want to spoil the movie. That is, if it ever attracts enough funding to be finished. The film is co-financed by BBC Storyville, but Koppelman and his son Walker just launched a Kickstarter campaign to raise $20,000 to ensure  continued filming of the project. A short introduction to their effort (including a scene starring Yours Truly) is available in the teaser video clip below. The filmmakers are also working with New York Times reporter John Markoff, Reuters reporter Joe Menn, and author Misha Glenny.

Microsoft Responds to Critics Over Botnet Bruhaha

April 16, 2012

Microsoft’s most recent anti-botnet campaign — a legal sneak attack against dozens of ZeuS botnets — seems to have ruffled the feathers of many in security community. The chief criticism is that the Microsoft operation exposed sensitive information that a handful of researchers had shared in confidence, and that countless law enforcement investigations may have been delayed or derailed as a result. In this post, I interview a key Microsoft attorney about these allegations.

Since Microsoft announced Operation B71, I’ve heard from several researchers who said they were furious at the company for publishing data on a group of hackers thought to be behind a majority of the ZeuS botnet activity — specifically those targeting small to mid-sized organizations that are getting robbed via cyber heists. The researchers told me privately that they believed Microsoft had overstepped its bounds with this action, using privileged information without permission from the source(s) of that data (many exclusive industry discussion lists dedicated to tracking cybercriminal activity have strict rules about sourcing and using information shared by other members).

At the time, nobody I’d heard from with complaints about the action wanted to speak on the record. Then, late last week, Fox IT, a Dutch security firm, published a lengthy blog post blasting Microsoft’s actions as “irresponsible,” and accusing the company of putting its desire for a public relations campaign ahead of its relationship with the security industry.

“This irresponsible action by Microsoft has led to hampering and even compromising a number of large international investigations in the US, Europe and Asia that we knew of and also helped with,” wrote Michael Sandee, Principal Security Expert at Fox IT. “It has also damaged and will continue to damage international relationships between public parties and also private parties. It also sets back cooperation between public and private parties, so called public private partnerships, as sharing will stop or will be definitely less valuable than it used to be for all parties involved.”

Sandee said that a large part of the information that Microsoft published about the miscreants involved was sourced from individuals and organizations without their consent, breaking various non-disclosure agreements (NDAs) and unspoken rules.

“In light of the whole Responsible Disclosure debate  [link added] from the end of Microsoft this unauthorized and uncoordinated use and publication of information protected under an NDA is obviously troublesome and shows how Microsoft only cares about protecting their own interests,” Sandee wrote.

Given the strong feelings that Microsoft’s actions have engendered in the Fox IT folks and among the larger security community, I reached out to Richard Boscovich, a former U.S. Justice Department lawyer who was one of the key architects of Microsoft’s legal initiative against ZeuS. One complaint I heard from several researchers who believed that Microsoft used and published data they uncovered was that the company kept the operation from nearly everyone. I asked Boscovich how this operation was different from previous actions against botnets such as Rustock and Waledac.

Boscovich: It’s essentially the same approach we’ve done in all the other operations. The problem that I think some people have is that due to the type of operation, we can’t have the entire community involved. That’s for several reasons. One is operational security. The bigger the number of people involved, the more likely is that is someone will make a mistake and say something that could jeopardize all of the work that everyone has done. Also, we’re making representations to a federal court that this is an ex-parte motion and very limited people know about it. If you have multiple people knowing, and the entire security community knows, let’s say we submit declarations from 30-40 people. A court may say, ‘Well there’s a lot of people here who know about this, so isn’t this information that’s already publicly available? Don’t these people know you’re looking at them already?’ We’re really asking for an extraordinary remedy: an ex-parte TRO [temporary restraining order] is a very high standard. We have to show an immediate threat and harm, ongoing, so much so that we can’t even give the other side notice that we’re going to sue them and take away their property.

The other concern is more operational. When I was in the Justice Department — I was there for just shy of 18 years — we even compartmentalized operations there. Information was shared on a need-to-know basis, to make sure the operation would be a success and that there wouldn’t be any inadvertent leaks. It wasn’t because we didn’t trust people, but because people sometimes make mistakes. So in this operation, just like the others, we engaged with industry partners, academic partners, and some of those who wished to be open, and others who preferred to do things behind the scenes.

Continue reading

Thieves Replacing Money Mules With Prepaid Cards?

April 13, 2012

Recent ebanking heists — such as a $121,000 online robbery at a New York fuel supplier last month — suggest that cyber thieves increasingly are cashing out by sending victim funds to prepaid debit card accounts. The shift appears to be an effort to route around a major bottleneck for these crimes: Their dependency on unreliable money mules.

Mules traditionally have played a key role in helping thieves cash out hacked accounts and launder money.  They are recruited through email-based work-at-home job scams, and are told they will be helping companies process payments. In a typical scheme, the mule provides her banking details to the recruiter, who eventually sends a fraudulent transfer and tells the mule to withdraw the funds in cash, keep a small percentage, and wire the remainder to co-conspirators abroad.

Some of the mule gangs I’ve identified.

But mules are hardly the most expedient method of extracting funds. To avoid arousing suspicion (and triggering anti-money laundering reporting requirements by the banks), cyber crooks usually send less than $10,000 to each mule. In other words, for every $100,000 that the thieves want to steal, they need to have  at least 10 money mules at the ready.

In reality, though, that number is quite often closer to 15 mules per $100,000. That’s because the thieves may send much lower amounts to mules that bank at institutions which have low transfer limit triggers. For instance, they almost always limit transfers to less than $5,000 when dealing with Bank of America mules, because they know transfers for more than that amount to consumer accounts will raise fraud flags at BofA.

Thus, the average mule is worth up to $10,000 to a cybercrook. Unsurprisingly, there is much competition and demand for available money mules in the cybercriminal underground. I’ve identified close to two dozen distinct money mule recruitment networks, most of which demand between 40-50 percent of the fraudulent transfer amounts for their trouble. Not only are mule expensive to acquire, they often take weeks to groom before they’re trusted with transfers.

But these mules also come with their own, well, baggage. I’ve interviewed now more than 200 money mules, and it’s hard to escape the conclusion that many mules simply are not the sharpest crayons in the box. They often have trouble following simple instructions, and frequently screw up important details when it comes time to cash out (there are probably good reasons that a lot of these folks are unemployed). Common goofs include transposing digits in account and routing numbers, or failing to get to the bank to withdraw the cash shortly after the fraudulent transfer, giving the victim’s bank precious time to reverse the transaction. In isolated cases, the mules simply disappear with the money and stiff the cyber thieves.

In several recent ebanking heists, however, thieves appear to have sent at least half of the transfers to prepaid cards, potentially sidestepping the expense and hassle of hiring and using money mules. For example, last month cyber crooks struck Alta East, a wholesale gasoline dealer in Middletown, N.Y. According to the firm’s comptroller Debbie Weeden, the thieves initiated 30 separate fraudulent transfers totaling more than $121,000. Half of those transfers went to prepaid cards issued by Metabank, a large prepaid card provider.

Prepaid cards are ideal because they can be purchased anonymously for small amounts ($25-$100 values) from supermarkets and other stores. A majority of these low-value cards are not reloadable, unless the cardholder goes online and provides identity information that the prepaid card issuer can tie to a legitimate credit holder. After that card is activated, it can be reloaded remotely by transferring or depositing funds into the account, and it can be used like a debit, ATM or credit card.

“The information we gather in opening it is the same information you’d be asked if you were opening a credit card account online,” said Brad Hanson, president of Metabank’s payment systems division. “We do checks against different public resources like Experian and LexisNexis to verify that all the information matches and is accurate, and that we have a reasonable belief that you are the person applying for the card.”

The trouble is, the thieves pulling these ebanking heists have access to massive amounts of stolen data that can be used to fraudulently open up prepaid cards in the names of people whose identities and computers have already been hijacked. Once those cards are approved, the crooks can simply transfer funds to them from cyberheist victims, and extract the cash at ATMs. Alternatively, wire transfer locations like Western Union even allow senders to use their debit cards to execute a “debit spend,” thereby sending money overseas directly from the card.

Continue reading

How to Find and Remove Mac Flashback Infections

April 12, 2012

A number of readers responded to the story I published last week on the Flashback Trojan, a contagion that was found to have infected more than 600,000 Mac OS X systems. Most people wanted to know how they could detect whether their systems were infected with Flashback — and if so — how to remove the malware. This post covers both of those questions.

Screen shot of Flashback detection tool from Dr.Web

Since the discovery last week of the Flashback Mac botnet, several security firms have released tools to help detect and clean up Flashback infections. Dr.Web, the Russian antivirus vendor that first sounded the alarm about the outbreak, has published a free online service that lets users tell whether their systems have been seen phoning home to Flashback’s control servers (those servers have since been hijacked by researchers). The service requires users to enter their Mac’s hardware unique user ID (HW-UUID), because this is how the miscreants who were running the botnet kept track of their infections.

F-Secure Corp., the Finnish security firm that worked with Dr.Web to more accurately gauge the true number of Flashback-infected Macs, has a Flashback Removal Tool available for download from its Web site.

Where is Apple’s response in all of this, you ask? Apple says it is developing software that will detect and remove Flashback. Inexplicably, it has not yet released this tool, nor has it added detection for it to the XProtect antivirus tool built into OS X. The company’s advisory on this threat is predictably sparse, and focuses instead on urging users to apply a recent update for Java. Flashback attacks a well-known Java flaw, but it’s worth noting that Apple released the Java patch only after Flashback had begun infecting hundreds of thousands of Macs.

Update, 8:22 p.m. ET: Apple just released a new version of Java that includes a Flashback remover. Java for OS X Lion 2012-003 delivers Java SE 6 version 1.6.0_31 and supersedes all previous versions of Java for OS X Lion. It includes no new security fixes, but it adopts a novel approach to the debate over whether to temporarily disable or remove Java: “It configures the Java web plug-in to disable the automatic execution of Java applets. Users may re-enable automatic execution of Java applets using the Java Preferences application.” If the Java web plug-in detects that no applets have been run for at least 35 days, it will again disable Java applets.

Continue reading