Krebs on Security

Crimeware Helps File Fraudulent Tax Returns

April 14, 2014

Many companies believe that if they protect their intellectual property and customers’ information, they’ve done a decent job of safeguarding their crown jewels from attackers. But in an increasingly common scheme, cybercriminals are targeting the Human Resources departments at compromised organizations and rapidly filing fraudulent federal tax returns on all employees.

Last month, KrebsOnSecurity encountered a Web-based control panel that an organized criminal gang has been using to track bogus tax returns filed on behalf of employees at hacked companies whose HR departments had been relieved of W2 forms for all employees.

An obfuscated look at the he control panel for a tax fraud operation involving more than a half dozen victim organizations.

According to the control panel seen by this reporter, the scammers in charge of this scheme have hacked more than a half-dozen U.S. companies, filing fake tax returns on nearly every employee. At last count, this particular scam appears to stretch back to the beginning of this year’s tax filing season, and includes fraudulent returns filed on behalf of thousands of people — totaling more than $1 million in bogus returns.

The control panel includes a menu listing every employee’s W2 form, including all data needed to successfully file a return, such as the employee’s Social Security number, address, wages and employer identification number. Each fake return was apparently filed using the e-filing service provided by H&R Block, a major tax preparation and filing company. H&R Block did not return calls seeking comment for this story.

The “drops” page of this tax fraud operation lists the nicknames of the co-conspirators who agreed to “cash out” funds on the prepaid cards generated by the bogus returns — minus a small commission.

Fraudulent returns listed in the miscreants’ control panel that were successfully filed produced a specific five-digit tax filing Personal Identification Number (PIN) apparently generated by H&R Block’s online filing system. An examination of the panel suggests that successfully-filed returns are routed to prepaid American Express cards that are requested to be sent to addresses in the United States corresponding to specific “drops,” or co-conspirators in the scheme who have agreed to receive the prepaid cards and “cash out” the balance — minus their fee for processing the bogus returns.

Alex Holden, chief information security officer at Hold Security, said although tax fraud is nothing new, automating the exploitation of human resource systems for mass tax fraud is an innovation.

“The depth of this specific operation permits them to act as a malicious middle-man and tax preparation company to be an unwitting ‘underwriter’ of this crime,” Holden said. “And the victims maybe exploited not only for 2013 tax year but also down the road, and perhaps subject of higher scrutiny by IRS — not to mention potential financial losses. Companies should look at their human resource infrastructure to ensure that payroll, taxes, financial, medical, and other benefits are afforded the same level of protection as their other mission-critical assets.” Continue reading →

Heartbleed Bug: What Can You Do?

April 10, 2014

129 Comments

In the wake of widespread media coverage of the Internet security debacle known as the Heartbleed bug, many readers are understandably anxious to know what they can do to protect themselves. Here’s a short primer.

The Heartbleed bug concerns a security vulnerability in a component of recent versions of OpenSSL, a technology that a huge chunk of the Internet’s Web sites rely upon to secure the traffic, passwords and other sensitive information transmitted to and from users and visitors.

Around the same time that this severe flaw became public knowledge, a tool was released online that allowed anyone on the Internet to force Web site servers that were running vulnerable versions of OpenSSL to dump the most recent chunk of data processed by those servers.

That chunk of data might include usernames and passwords, re-usable browser cookies, or even the site administrator’s credentials. While the exploit only allows for small chunks of data to be dumped each time it is run, there is nothing to prevent attackers from replaying the attack over and over, all the while recording fresh data flowing through vulnerable servers. Indeed, I have seen firsthand data showing that some attackers have done just that; for example, compiling huge lists of credentials stolen from users logging in at various sites that remained vulnerable to this bug.

For this reason, I believe it is a good idea for Internet users to consider changing passwords at least at sites that they visited since this bug became public (Monday morning). But it’s important that readers first make an effort to determine that the site in question is not vulnerable to this bug before changing their passwords. Here are some resources that can tell you if a site is vulnerable: Continue reading →

Adobe, Microsoft Push Critical Fixes

April 8, 2014

22 Comments

Adobe and Microsoft each issued updates to fix critical security vulnerabilities in their software today. Adobe patched its Flash Player software and Adobe AIR. Microsoft issued four updates to address at least 11 unique security flaws, including its final batch of fixes for Office 2003 and for systems powered by Windows XP.

Two of the four patches that Microsoft issued come with Redmond’s “critical” rating (its most severe), meaning attackers or malware can exploit the flaws to break into vulnerable systems without any help from users. One of the critical patches is a cumulative update for Internet Explorer (MS14-018); the other addresses serious issues with Microsoft Word and Office Web apps (MS14-017), including a fix for a zero-day vulnerability that is already being actively exploited. More information on these and other patches are available here.

As expected, Microsoft also used today’s patch release to pitch XP users on upgrading to a newer version of Windows, warning that attackers will begin to zero in on XP users even more now that Microsoft will no longer be issuing security updates for the 13-year-old operating system. From Microsoft’s Technet blog: Continue reading →

‘Heartbleed’ Bug Exposes Passwords, Web Site Encryption Keys

April 8, 2014

171 Comments

Researchers have uncovered an extremely critical vulnerability in recent versions of OpenSSL, a technology that allows millions of Web sites to encrypt communications with visitors. Complicating matters further is the release of a simple exploit that can be used to steal usernames and passwords from vulnerable sites, as well as private keys that sites use to encrypt and decrypt sensitive data.

Credit: Heartbleed.com

From Heartbleed.com:

“The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop communications, steal data directly from the services and users and to impersonate services and users.”

An advisory from Carnegie Mellon University’s CERT notes that the vulnerability is present in sites powered by OpenSSL versions 1.0.1 through 1.0.1f. According to Netcraft, a company that monitors the technology used by various Web sites, more than a half million sites are currently vulnerable. As of this morning, that included Yahoo.com, and — ironically — the Web site of openssl.org. This list at Github appears to be a relatively recent test for the presence of this vulnerability in the top 1,000 sites as indexed by Web-ranking firm Alexa.

An easy-to-use exploit that is being widely traded online allows an attacker to retrieve private memory of an application that uses the vulnerable OpenSSL “libssl” library in chunks of 64kb at a time. As CERT notes, an attacker can repeatedly leverage the vulnerability to retrieve as many 64k chunks of memory as are necessary to retrieve the intended secrets.

Jamie Blasco, director of AlienVault Labs, said this bug has “epic repercussions” because not only does it expose passwords and cryptographic keys, but in order to ensure that attackers won’t be able to use any data that does get compromised by this flaw, affected providers have to replace the private keys and certificates after patching the vulnerable OpenSSL service for each of the services that are using the OpenSSL library [full disclosure: AlienVault is an advertiser on this blog].

It is likely that a great many Internet users will be asked to change their passwords this week (I hope). Meantime, companies and organizations running vulnerable versions should upgrade to the latest iteration of OpenSSL – OpenSSL 1.0.1g — as quickly as possible.

Update, 2:26 p.m.: It appears that this Github page allows visitors to test whether a site is vulnerable to this bug (hat tip to Sandro Süffert). For more on what you can do you to protect yourself from this vulnerability, see this post.

Fact-Checking Experian’s Talking Points

April 5, 2014

39 Comments

In the wake of long-overdue media attention to revelations that a business unit of credit bureau Experian sold consumer personal data directly to an online service that catered to identity thieves, Experian is rightfully trying to explain its side of the story by releasing a series of talking points. This blog post is an attempt to add more context and fact-checking to those talking points.

Experian has posted several articles on its Web properties that lament the existence of “inaccurate information about Experian circulating in news outlets and other Web sites.”

“It’s no surprise that cybercrime and data breaches are hot topics for media and bloggers these days,” wrote Gerry Tschopp, senior vice president of public affairs at Experian. “Unfortunately, because of all the attention paid to these topics, we’ve seen some inaccurate information about Experian circulating in news outlets and other Web sites. I want to take a moment to clarify the facts and events.”

I’ve read this clarification closely, and it seems that Experian’s latest talking points deserve some clarification and fact-checking of their own. Below are Experian’s assertions of the facts (in bold), followed by some supplemental information glossed over by said statements of fact.

-No Experian database was accessed. The data in question have at all relevant times been owned and maintained, not by Experian, but by a company called US Info Search.

As all of my stories on this incident have explicitly stated, the government has said the data was not obtained directly from Experian, but rather via Columbus, Ohio-based US Info Search. US Info Search had a contractual agreement with a California company named Court Ventures, whereby customers of Court Ventures had access to the US Info Search data as well as Court Ventures’ data, and vice versa. Experian came into the picture in March 2012, when it purchased Court Ventures (along with all of its customers — including the proprietor of the identity theft service).

For its part, US Info Search says Experian’s explanation of the events is based on false statements and misrepresentations, and that the proprietor of the ID theft service paid Experian for his access using large cash payments sent to Experian via wire from Singapore.

“Experian provided access to records via a gateway that used multiple data sources and the suspect never had access to our service,” US Info Search CEO Marc Martin said in a written statement. “We, like many others, provide data to Experian, who in turn sold data to customers they approved and monitored. Our agreement with Court Ventures and subsequently Experian was to provide information that was being used for identity verification and fraud prevention.

-Further, Experian’s only involvement was that it purchased the assets of a company, Court Ventures, that provided access to US Info Search’s data to Court Ventures’ customers. Under that contract, customers of Court Ventures, including the criminal in this case, could access US Info Search’s data. This was not an Experian database, and specifically, this was not a credit database.

Experian has a duty to conduct “due diligence” on companies it wishes to acquire, because it knows that in purchasing a company it will acquire all of the company’s assets — including whatever debts, liabilities or poor decisions the previous owners may have incurred that end up creating problems down the road. Experian wants to blame everyone else, but by its own admission, Experian didn’t conduct proper due diligence on Court Ventures before acquiring the company. Addressing a U.S. Senate committee last December, Experian’s senior vice president of government policy, Tony Hadley, allowed that “during the due diligence process, we didn’t have total access to all the information we needed in order to completely vet that, and by the time we learned of the malfeasance nine months had expired, and the Secret Service came to us and told us of the incident. We were a victim, and scammed by this person.”

Also, if it wasn’t clear by now, Experian’s PR mantra on this crisis has been that “no Experian database was accessed,” in this fraud. But this mantra draws attention away from the real victim: Consumers whose information was sold by Experian’s company directly to an identity theft service. A critical question to ask to this line of thinking is: Why does it matter whose database it is, if it contains personal info and Experian profited from its sale? Continue reading →

U.S. States Investigating Breach at Experian

April 3, 2014

59 Comments

An exclusive KrebsOnSecurity investigation detailing how a unit of credit bureau Experian ended up selling consumer records to an identity theft service in the cybercrime underground has prompted a multi-state investigation by several attorneys general, according to wire reports.

Ngo’s Identity theft service, superget.info

Reuters moved a story this afternoon quoting Illinois Attorney General Lisa Madigan saying that “it’s part of a multistate investigation,” and that Connecticut Attorney General George Jepsen said that Connecticut is looking into the matter as well.

News of the breach first came to light on this blog in October 2013, when KrebsOnSecurity published an exclusive story detailing how a Vietnamese man running an online identity theft service bought personal and financial records on Americans directly from a company owned by Experian, one of the three major U.S. credit bureaus.

Hieu Minh Ngo, a 24-year-old Vietnamese national, pleaded guilty last month to running an identity theft service out of his home in Vietnam. Ngo was arrested last year in Guam by U.S. Secret Service agents after he was lured into visiting the U.S. territory to consummate a business deal with a man he believed could deliver huge volumes of consumers’ personal and financial data for resale.

But according to prosecutors, Ngo had already struck deals with one of the world’s biggest data brokers: Experian. Court records just released last week show that Ngo tricked an Experian subsidiary into giving him direct access to personal and financial data on more than 200 million Americans.

Continue reading →

Android Botnet Targets Middle East Banks

April 2, 2014

22 Comments

I recently encountered a botnet targeting Android smartphone users who bank at financial institutions in the Middle East. The crude yet remarkably effective mobile bot that powers this whole operation comes disguised as one of several online banking apps, has infected more than 2,700 phones, and has intercepted at least 28,000 text messages.

The botnet — which I’ve affectionately dubbed “Sandroid” — comes bundled with Android apps made to look like mobile two-factor authentication modules for various banks, including Riyad Bank, SAAB (formerly the Saudi British Bank), AlAhliOnline (National Commercial Bank), Al Rajhi Bank, and Arab National Bank.

The fake Android bank apps employed by the Sandroid botnet.

It’s not clear how the apps are initially presented to victims, but if previous such scams are any indication they are likely offered after infecting the victim’s computer with a password-stealing banking Trojan. Many banks send customers text messages containing one-time codes that are used to supplement a username and password when the customer logs on to the bank’s Web site. And that precaution of course requires attackers interested in compromising those accounts to also hack the would-be victim’s phone.

Banking Trojans — particularly those targeting customers of financial institutions outside of the United States — will often throw up a browser pop-up box that mimics the bank and asks the user to download a “security application” on their mobile phones. Those apps are instead phony programs that merely intercept and then relay the victim’s incoming SMS messages to the botnet master, who can then use the code along with the victim’s banking username and password to log in as the victim.

Some of the 28,000+ text messages intercepted by the Sandroid botnet malware.

Continue reading →

Who’s Behind the ‘BLS Weblearn’ Credit Card Scam?

March 31, 2014

70 Comments

A new rash of credit and debit card scams involving bogus sub-$15 charges and attributed to a company called “BLS Weblearn” is part of a prolific international scheme designed to fleece unwary consumers. This post delves deeper into the history and identity of the credit card processing network that has been enabling this type of activity for years.

onlinelearningaccess.com, one of the fraudulent affiliate marketing schemes that powers these bogus micropayments.

At issue are a rash of phony charges levied against countless consumers for odd amounts — such as $10.37, or $12.96. When they appear on your statement, the charges generally reference a company in St. Julians, Malta such as BLS*Weblearn or PLI*Weblearn, and include a 1-888 number that may or may not work (the most common being 888-461-2032 and 888-210-6574).

I began hearing from readers about this early this month, in part because of my previous sleuthing on an eerily similar scheme that also leveraged payment systems in Malta to put through unauthorized junk charges ($9.84) for “online learning” software systems. Unfortunately, while the names of the companies and payment systems have changed, this latest scam appears to be remarkably similar in every way.

Reading up on this latest scam, it appears that the payments are being processed by a company called BlueSnap, which variously lists its offices in Massachusetts, California, Israel, Malta and London. Oddly enough, the payment network used by the $9.84 scams that surfaced last year — Credorax — also lists offices in Massachusetts, Israel, London and Malta.

And, just like with the $9.84 scam, this latest micropayment fraud scheme involves an extremely flimsy-looking affiliate income model that seems merely designed for abuse. According to information from several banks contacted for this story, early versions of this scam (in which fraudulent transactions were listed on statements as PLI*WEBLEARN) leveraged pliblue.com, formerly associated with a company called Plimus, a processor that also lists offices in California and Israel (in addition to Ukraine).

The very first time I encountered Plimus was in Sept. 2011, when I profiled an individual responsible for selling access to tens of thousands of desktop computers that were hacked and seeded with the TDSS botnet. That miscreant — a fellow who used the nickname “Fizot” — had been using Plimus to accept credit card payments for awmproxy.net, an anonymization service that was sold primarily to individuals engaged in computer fraud.

Apparently, the Internet has been unkind to Plimus’s online reputation, because not long ago the company changed its name to BlueSnap. This blog has a few ideas about what motivated the name change, noting that it might have been prompted in part by a class action lawsuit (PDF) against Plimus which alleges that the company’s marketing campaigns include the “mass production of fabricated consumer reviews, testimonials and fake blogs that are all intended to deceive consumers seeking a legitimate product and induce them to pay. Yet, after consumers pay for access to any of these digital goods websites, they quickly realize that the promotional materials and representations were blatantly false.”

Continue reading →

Who Built the ID Theft Service SSNDOB.ru?

March 27, 2014

66 Comments

Previous stories on this blog have highlighted the damage wrought by an identity theft service marketed in the underground called ssndob[dot]ru, which sold Social Security numbers, credit reports, drivers licenses and other sensitive information on more than four million Americans. Today’s post looks at a real-life identity behind the man likely responsible for building this service.

The administration page of ssndob[dot]ru. Note the logged in user, ssndob@ssa.gov, is the administrator.

Last summer, ssndob[dot]ru (hereafter referred to as “SSNDOB”) was compromised by multiple attackers, its own database plundered. A copy of the SSNDOB database was exhaustively reviewed by KrebsOnSecurity.com. The database shows that the site’s 1,300 customers have spent hundreds of thousands of dollars looking up SSNs, birthdays, drivers license records, and obtaining unauthorized credit and background reports on more than four million Americans.

Private messages and postings on various crime forums show that the service offered at ssndob[dot]ru was originally registered in 2009 at a domain called ssndob-search.info. A historic records lookup purchased from domaintools.com shows that ssndob-search was first registered to an Armand Ayakimyan from Apsheronsk, Russia. This registrant used the email address lxg89@rambler.ru.

In 2013, a copy of the carding forum carder[dot]pro was leaked online. Forum records show that the lxg89@rambler.ru address was used by a member who picked the username “Zack,” and who told other members to contact him on the ICQ instant messenger account 383337. On Vkontakte.ru, a popular Russian social networking site, Mr. Zack is the name of a profile for a 24-year-old Armand Ayakimyan from Sukhumi, a city in western Georgia and the capital of Abkhazia — a disputed region on the Black Sea coast.

Mr. Zack lists his date of birth as August 27 and current town as Sochi, the site of the 2014 Winter Olympics, (although the Mr. Zack account appears to have been dormant for some time). We can see some pictures of Mr. Ayakimyan (DOB: Aug. 27, 1989) at this profile by the same name at promodj.com, a music mixing site. That profile is tied to a group profile created by an Armand Ayakimyan in Sochi.

Mr. Ayakimyan appears to have used a number of different nicknames on various forums, including “Darkill,” “Darkglow” and “Planovoi”. That’s according to the administrators of verified[dot]cm, a top Russian crime forum at which he had apparently created numerous accounts. In an amusing multi-page thread on verified, the administrators respond to multiple member complaints about Plaovoi’s behavior by “doxing” him, essentially listing all of the identifiers that point from various email addresses, ICQ numbers and aliases back to accounts tied to Armand Ayakimyan.

KrebsOnSecurity attempted to reach Ayakimyan via multiple email addresses tied to his various profiles, including Facebook. An individual responding at the main Jabber address used by the operator of SSNDOB — ssndob@swissjabber.ch — declined to comment for this story, saying only “Я против блога. Выберите другой сервис,” or, “I am against the blog. Choose another service.” This reply came immediately after the user of this profile updated his status message notifying customers that his identity theft service was just freshly stocked with a huge new update of personal data on Americans.

The conclusion that Ayakimyan is/was involved with the operation of SSNDOB is supported with evidence gathered from Symantec, which published a blog post last week linking the young man to the identity theft service. According to Big Yellow, Ayakimyan is but one of several men allegedly responsible for creating and stocking the ID theft bazaar, a group Symantec calls the “Cyclosa gang.” From their report:

Continue reading →

ZIP Codes Show Extent of Sally Beauty Breach

March 25, 2014

78 Comments

Earlier this month, beauty products chain Sally Beauty acknowledged that a hacker break-in compromised fewer than 25,000 customer credit and debit cards. My previous reporting indicated that the true size of the breach was at least ten times larger. The analysis published in this post suggests that the Sally Beauty breach may have impacted virtually all 2,600+ Sally Beauty locations nationwide.

Sally Beauty cards sold under the “Desert Strike” base on Rescator’s site.

Sally Beauty has declined to speculate on how many stores or total cards may have been exposed by the breach, saying in a statement last week that so far its analysis indicates fewer than 25,000 cards were compromised. But that number seems very conservative when viewed through the prism of data from the cybercriminal shop primarily responsible for selling cards stolen from Sally Beauty customers. Indeed, it suggests that the perpetrators managed to hoover up cards used at nearly all Sally Beauty stores.

The research technique used to arrive at this conclusion was the same method that allowed this reporter and others to conclude that the Target hackers had succeeded at installing card-stealing malware on cash registers at nearly all 1,800 Target locations in the United States.

The first indications of a breach at Target came when millions of cards recently used at the big box retailer started showing up for sale on a crime shop called Rescator[dot]so. This site introduced an innovation that to my knowledge hadn’t been seen before across dozens of similar crime shops in the underground: It indexed stolen cards primarily by the city, state and ZIP code of the Target stores from which each card had been stolen.

This feature was partly what allowed Rescator to sell his cards at much higher prices than other fraud shops, because the ZIP code feature allowed crooks to buy cards from the store that were stolen from Target stores near them (this feature also strongly suggested that Rescator had specific and exclusive knowledge about the breach, a conclusion that has been supported by previous investigations on this blog into the malware used at Target and the Internet history of Rescator himself).

To put the ZIP code innovation in context, the Target break-in came to light just a week before Christmas, and many banks were at least initially reluctant to reissue cards thought to be compromised in the breach because they feared a backlash from consumers who were busy doing last minute Christmas shopping and traveling for the holidays. Rather, many banks in the interim chose to put in place “geo blocks” that would automatically flag for fraud any in-store transactions that were outside the customer’s normal geographic purchasing area. The beauty of Rescator’s ZIP code indexing was that customers could buy only cards that were used at Target stores near them, thereby making it far more likely that Rescator’s customers could make purchases with the stolen cards without setting off geo-blocking limits set by the banks.

To test this theory, researchers compiled a list of the known ZIP codes of Target stores, and then scraped Rescator’s site for a list of the ZIP codes represented in the cards for sale. Although there are more than 43,000 ZIP codes in the United States, slightly fewer than 1,800 unique ZIPs were referenced in the Target cards for sale on Rescator’s shop — roughly equal to the number of Target locations across America.

Sally Beauty declined to provide a list of its various store ZIP codes, but with the assistance of several researchers — none of whom wished to be thanked or cited in this story — I was able to conduct the same analysis with the new batch of cards on Rescator’s site that initially tipped me off to the Sally Beauty breach. The result? There are nearly the exact same number of U.S. ZIP codes represented in the batch of cards for sale on Rescator’s shop as there are unique U.S. ZIP codes of Sally Beauty stores (~2,600).

More importantly, there was a 99.99 percent overlap in the ZIP codes. That strongly suggests that virtually all Sally Beauty stores were compromised by this breach.

Continue reading →

Last »