PROJET AUTOBLOG


Krebs on Security

Site original : Krebs on Security

⇐ retour index

Adobe, Microsoft Push Critical Security Fixes

mardi 12 mai 2015 à 23:33

Microsoft today issued 13 patch bundles to fix roughly four dozen security vulnerabilities in Windows and associated software. Separately, Adobe pushed updates to fix a slew of critical flaws in its Flash Player and Adobe Air software, as well as patches to fix holes in Adobe Reader and Acrobat.

brokenwindowsThree of the Microsoft patches earned the company’s most dire “critical” rating, meaning they fix flaws that can be exploited to break into vulnerable systems with little or no interaction on the part of the user. The critical patches plug at least 30 separate flaws. The majority of those are included in a cumulative update for Internet Explorer. Other critical fixes address problems with the Windows OS, .NET, Microsoft Office, and Silverlight, among other components.

According to security vendor Shavlik, the issues address in MS15-044 deserve special priority in patching, in part because it impacts so many different Microsoft programs but also because the vulnerabilities fixed in the patch can be exploited merely by viewing specially crafted content in a Web page or a document. More information on and links to today’s individual updates can be found here.

Adobe’s fix for Flash Player and AIR fix at least 18 security holes in the programs. Updates are available for Windows, OS X and Linux versions of the software. Mac and Windows users, the latest, patched version is v. 17.0.0.188. 

If you’re unsure whether your browser has Flash installed or what version it may be running, browse to this link. Adobe Flash Player installed with Google Chrome, as well as Internet Explorer on Windows 8.x, should automatically update to the latest version. To force the installation of an available update, click the triple bar icon to the right of the address bar, select “About Google” Chrome, click the apply update button and restart the browser.

brokenflash-a

The most recent versions of Flash should be available from the Flash home page, but beware potentially unwanted add-ons, like McAfee Security Scan. To avoid this, uncheck the pre-checked box before downloading, or grab your OS-specific Flash download from here. Windows users who browse the Web with anything other than Internet Explorer may need to apply this patch twice, once with IE and again using the alternative browser (Firefox, Opera, e.g.).

If you run Adobe Reader, Acrobat or AIR, you’ll need to update those programs as well. Adobe said it is not aware of any active exploits or attacks against any of the vulnerabilities it patched with today’s releases.

Who’s Scanning Your Network? (A: Everyone)

lundi 11 mai 2015 à 05:36

Not long ago I heard from a reader who wanted advice on how to stop someone from scanning his home network, or at least recommendations about to whom he should report the person doing the scanning. I couldn’t believe that people actually still cared about scanning, and I told him as much: These days there are countless entities — some benign and research-oriented, and some less benign — that are continuously mapping and cataloging virtually every device that’s put online.

GF5One of the more benign is scans.io, a data repository of research findings collected through continuous scans of the public Internet. The project, hosted by the ZMap Team at the University of Michigan, includes huge, regularly updated results grouped around scanning for Internet hosts running some of the most commonly used “ports” or network entryways, such as Port 443 (think Web sites protected by the lock icon denoting SSL/TLS Web site encryption); Port 21, or file transfer protocol (FTP); and Port 25, or simple mail transfer protocol (SMTP), used by many businesses to send email.

When I was first getting my feet wet on the security beat roughly 15 years ago, the practice of scanning networks you didn’t own looking for the virtual equivalent of open doors and windows was still fairly frowned upon — if not grounds to get one into legal trouble. These days, complaining about being scanned is about as useful as griping that the top of your home is viewable via Google Earth. Trying to put devices on the Internet and then hoping that someone or something won’t find them is one of the most futile exercises in security-by-obscurity.

To get a gut check on this, I spoke at length last week with University of Michigan researcher Zakir Durumeric (ZD) and Michael D. Bailey at the University of Illinois at Urbana-Champaign (MB) about their ongoing and very public project to scan all the Internet-facing things. I was curious to get their perspective on how public perception of widespread Internet scanning has changed over the years, and how targeted scanning can actually lead to beneficial results for Internet users as a whole.

MB: Because of the historic bias against scanning and this debate between disclosure and security-by-obscurity, we’ve approached this very carefully. We certainly think that the benefits of publishing this information are huge, and that we’re just scratching the surface of what we can learn from it.

ZD: Yes, there are close to two dozen papers published now based on broad, Internet-wide scanning. People who are more focused on comprehensive scans tend to be the more serious publications that are trying to do statistical or large-scale analyses that are complete, versus just finding devices on the Internet. It’s really been in the last year that we’ve started ramping up and adding scans [to the scans.io site] more frequently.

BK: What are your short- and long-term goals with this project?

ZD: I think long-term we do want to add coverage of additional protocols. A lot of what we’re focused on is different aspects of a protocol. For example, if you’re looking at hosts running the “https://” protocol, there are many different ways you can ask questions depending on what perspective you come from. You see different attributes and behavior. So a lot of what we’ve done has revolved around https, which is of course hot right now within the research community.

MB: I’m excited to add other protocols. There are a handful of protocols that are critical to operations of the Internet, and I’m very interested in understanding the deployment of DNS, BGP, and TLS’s interception with SMTP. Right now, there’s a pretty long tail to all of these protocols, and so that’s where it starts to get interesting. We’d like to start looking at things like programmable logic controllers (PLCs) and things that are responding from industrial control systems.

ZD: One of the things we’re trying to pay more attention to is the world of embedded devices, or this ‘Internet of Things’ phenomenon. As Michael said, there are also industrial protocols, and there are different protocols that these embedded devices are supporting, and I think we’ll continue to add protocols around that class of devices as well because from a security perspective it’s incredibly interesting which devices are popping up on the Internet.

BK: What are some of the things you’ve found in your aggregate scanning results that surprised you?

ZD: I think one thing in the “https://” world that really popped out was we have this very large certificate authority ecosystem, and a lot of the attention is focused on a small number of authorities, but actually there is this very long tail — there are hundreds of certificate authorities that we don’t really think about on a daily basis, but that still have permission to sign for any Web site. That’s something we didn’t necessary expect. We knew there were a lot, but we didn’t really know what would come up until we looked at those.

There also was work we did a couple of years ago on cryptographic keys and how those are shared between devices. In one example, primes were being shared between RSA keys, and because of this we were able to factor a large number of keys, but we really wouldn’t have seen that unless we started to dig into that aspect [their research paper on this is available here].

MB: One of things we’ve been surprised about is when we measure these things at scale in a way that hasn’t been done before, often times these kinds of emergent behaviors become clear.

BK: Talk about what you hope to do with all this data.

ZD: We were involved a lot in the analysis of the Heartbleed vulnerability. And one of the surprising developments there wasn’t that there were lots of people vulnerable, but it was interesting to see who patched, how and how quickly. What we were able to find was by taking the data from these scans and actually doing vulnerability notifications to everybody, we were able to increase patching for the Heartbleed bug by 50 percent. So there was an interesting kind of surprise there, not what you learn from looking at the data, but in terms of what actions do you take from that analysis? And that’s something we’re incredibly interested in: Which is how can we spur progress within the community to improve security, whether that be through vulnerability notification, or helping with configurations.

BK: How do you know your notifications helped speed up patching?

MB: With the Heartbleed vulnerability, we took the known vulnerable population from scans, and ran an A/B test. We split the population that was vulnerable in half and notified one half of the population, while not notifying the other half, and then measured the difference in patching rates between the two populations. We did end up after a week notifying the second population…the other half.

BK: How many people did you notify after going through the data from the Heartbleed vulnerability scanning? 

ZD: We took everyone on the IPv4 address space, found those that were vulnerable, and then contacted the registered abuse contact for each block of IP space. We used data from 200,000 hosts, which corresponded to 4,600 abuse contacts, and then we split those into an A/B test. [Their research on this testing was published here].

So, that’s the other thing that’s really exciting about this data. Notification is one thing, but the other is we’ve been building models that are predictive of organizational behavior. So, if you can watch, for example, how an organization runs their Web server, how they respond to certificate revocation, or how fast they patch — that actually tells you something about the security posture of the organization, and you can start to build models of risk profiles of those organizations. It moves away from this sort of patch-and-break or patch-and-pray game we’ve been playing. So, that’s the other thing we’ve been starting to see, which is the potential for being more proactive about security.

BK: How exactly do you go about the notification process? That’s a hard thing to do effectively and smoothly even if you already have a good relationship with the organization you’re notifying….

MB: I think one of the reasons why the Heartbleed notification experiment was so successful is we did notifications on the heels of a broad vulnerability disclosure. The press and the general atmosphere and culture provided the impetus for people to be excited about patching. The overwhelming response we received from notifications associated with that were very positive. A lot of people we reached out to say, ‘Hey, this is a great, please scan me again, and let me know if I’m patched.” Pretty much everyone was excited to have the help.

Another interesting challenge was that we did some filtering as well in cases where the IP address had no known patches. So, for example, where we got information from a national CERT [Computer Emergency Response Team] that this was an embedded device for which there was no patch available, we withheld that notification because we felt it would do more harm than good since there was no path forward for them. We did some aggregation as well, because it was clear there were a lot of DSL and dial-up pools affected, and we did some notifications to ISPs directly.

BK: You must get some pushback from people about being included in these scans. Do you think that idea that scanning is inherently bad or should somehow prompt some kind of reaction in and of itself, do you think that ship has sailed?

ZD: There is some small subset that does have issues. What we try to do with this is be as transparent as possible. All of our hosts we use for scanning, if look at them on WHOIS records or just visit them with a browser it will tell you right away that this machine is part of this research study, here’s the information we’re collecting and here’s how you can be excluded. A very small percentage of people who visit that page will read it and then contact us and ask to be excluded. If you send us an email [and request removal], we’ll remove you from all future scans. A lot of this comes down to education, a lot of people to whom we explain our process and motives are okay with it.

BK: Are those that object and ask to be removed more likely to be companies and governments, or individuals?

ZD: It’s a mix of all of them. I do remember offhand there were a fair number of academic institutions and government organizations, but there were a surprising number of home users. Actually, when we broke down the numbers last year (PDF), the largest category was small to mid-sized businesses. This time last year, we had excluded only 157 organizations that had asked for it.

BK: Was there any pattern to those that asked to be excluded?

ZD: I think that actually is somewhat interesting: The exclusion requests aren’t generally coming from large corporations, which likely notice our scanning but don’t have an issue with it. A lot of emails we get are from these small businesses and organizations that really don’t know how to interpret their logs, and often times just choose the most conservative route.

So we’ve been scanning for a several years now, and I think when we originally started scanning, we expected to have all the people who were watching for this to contact us all at once, and say ”Please exclude us.’ And then we sort of expected that the number of people who’d ask to be excluded would plateau, and we wouldn’t have problems again. But what we’ve seen is, almost the exact opposite. We still get [exclusion request] emails each day, but what we’re really finding is people aren’t discovering these scans proactively. Instead, they’re going through their logs while trying to troubleshoot some other issue, and they see a scan coming from us there and they don’t know who we are or why we’re contacting their servers. And so it’s not these organizations that are watching, it’s the ones who really aren’t watching who are contacting us.

BK: Do you guys go back and delete historic records associated with network owners that have asked to be excluded from scans going forward?

ZD: At this point we haven’t gone back and removed data. One reason is there are published research results that are based on those data sets, results, and so it’s very hard to change that information after the fact because if another researcher went back and tried to confirm an experiment or perform something similar, there would be no easy way of doing that.

BK: Is this what you’re thinking about for the future of your project? How to do more notification and build on the data you have for those purposes? Or are you going in a different or additional direction?

MB: When I think about the ethics of this kind of activity, I have very utilitarian view: I’m interested in doing as much good as we possibly can with the data we have. I think that lies in notifications, being proactive, helping organizations that run networks to better understand what their external posture looks like, and in building better safe defaults. But I’m most interested in a handful of core protocols that are under-serviced and not well understood. And so I think we should spend a majority of effort focusing on a small handful of those, including BGP, TLS, and DNS.

ZD: In many ways, we’re just kind of at the tip of this iceberg. We’re just starting to see what types of security questions we can answer from these large-scale analyses. I think in terms of notifications, it’s very exciting that there are things beyond the analysis that we can use to actually trigger actions, but that’s something that clearly needs a lot more analysis. The challenge is learning how to do this correctly. Every time we look at another protocol, we start seeing these weird trends and behavior we never noticed before. With every protocol we look at there are these endless questions that seem to need to be answered. And at this point there are far more questions than we have hours in the day to answer.

Deconstructing the 2014 Sally Beauty Breach

vendredi 8 mai 2015 à 01:59

This week, nationwide beauty products chain Sally Beauty disclosed that, for the second time in a year, it was investigating reports that hackers had broken into its networks and stolen customer credit card data. That investigation is ongoing, but I recently had an opportunity to interview a former Sally Beauty IT technician who provided a first-hand look at how the first breach in 2014 went down.

sallybOn March 14, 2014, KrebsOnSecurity broke the news that some 260,000 credit cards stolen from Sally Beauty stores had gone up for sale on Rescator[dot]cc, the same shop that first debuted cards stolen in the Home Depot and Target breaches. The company said thieves made off with just 25,000 customer cards. But the shop selling the cards listed each by the ZIP code of the Sally Beauty store from which the card data had been stolen, exactly like this same shop did with Home Depot and Target. An exhaustive analysis of the ZIP codes represented in the cards for sale on the fraud shop indicated that the hackers had hit virtually all 2,600 Sally Beauty locations nationwide.

The company never disclosed additional details about the breach itself or how it happened. But earlier this week I spoke with Blake Curlovic, until recently an application support analyst at Sally Beauty who was among the first to respond when virtual alarm bells starting going off last year about a possible intrusion. Curlovic said that at the time, Sally Beauty was running exactly one enterprise solution for security — Tripwire (full disclosure: Tripwire is an advertiser on this blog). Tripwire’s core product monitors key operating system and application files for any changes, which then triggers alerts.

Tripwire fired a warning when the intruders planted a new file on point-of-sale systems within Sally Beauty’s vast network of cash registers. The file was a program designed to steal card numbers as they were being swiped through the registers, and the attackers had named their malware after a legitimate program running on all Sally Beauty registers. They also used a utility called Timestomp to change the date and time stamp on their malware to match the legitimate file, but that apparently didn’t fool Tripwire.

According to Curlovic, the intruders gained access through a Citrix remote access portal set up for use by employees who needed access to company systems while on the road.

“The attackers somehow had login credentials of a district manager,” Curlovic said. “This guy was not exactly security savvy. When we got his laptop back in, we saw that it had his username and password taped to the front of it.”

Once inside the Sally Beauty corporate network, the attackers scanned and mapped out the entire thing, located all shared drives and scoured those for Visual Basic (VB) scripts. Network administrators in charge of managing thousands or tens of thousands of systems often will write VB scripts to automate certain tasks across all of those systems, and very often those scripts will contain usernames and passwords that can be quite useful to attackers.

Curlovic said the intruders located a VB script on Sally Beauty’s network that contained the username and password of a network administrator at the company.

“That allowed them to basically copy files to the cash registers,” he said. “They used a simple batch file loop, put in all the [cash] register Internet addresses they found while scanning the network, looped through there and copied [the malware] to all of the point-of-sale devices — roughly 6,000 of them. They were in the network for like a week prior to that planning the attack.”

HIDING IN PLAIN SIGHT

Curlovic said the malware planted on Sally Beauty’s network was identified (by some security vendors) as a variant of FrameworkPOS, a card-stealing program that exfiltrates data from the target’s network by transmitting it as domain name system (DNS) traffic.

DNS is the fundamental Internet technology that translates human-friendly domain names like example.com to numeric Internet addresses that are easier for computers to understand. All networks rely on DNS to help direct users as they surf online, but few organizations actually keep detailed logs or records of the DNS traffic traversing their networks — making it an ideal way to siphon data from a hacked network.

According to a writeup of FrameworkPOS by G Data, a security firm based in Germany, the card-stealing malware allows the attackers to dynamically configure the domain name to which the DNS traffic carrying the stolen card data will reach out. On top of that, the malware obfuscates the card data with a simple cipher so that it won’t be immediately obvious as card data to anyone who happens to be examining the DNS traffic.

But Curlovic said despite its clever data-stealing methods, other parts of the malware were clumsily written. In fact, he said, one component of the malware actually broke the Net Logon service on infected point-of-sale systems, limiting the ability of the Sally Beauty cash registers to communicate with the rest of the company’s internal network. Net Logon is a Microsoft Windows component that verifies network log on requests.

“I don’t know technically what went wrong with their software, but Net Logon wouldn’t start anymore after it was installed,” Curlovic said. “We couldn’t log in remotely with domain credentials and registers couldn’t communicate out through DNS effectively after that. It was pretty huge indicator that something was seriously wrong at that point.”

As for Sally Beauty’s standing claim that only 25,000 customer cards were taken, Curlovic said he’d be surprised if it was limited to the 260,000 originally reported by this blog.

“From what I saw in the information that the Secret Service had, 260,000 was probably on the low end,” he said. “For the period of time the software was out on the registers and running, it should have been closer to around a million, based on the number of credit transactions Sally Beauty had daily. But since the malware really wasn’t working very well, it was only capturing a portion of the cards that went through because of the formatting issue that broke the Net Logon service.

ANTI-AMERICAN MESSAGES

Curlovic said the malware used in the 2014 Sally Beauty breach communicated the stolen card data to several domains that were hosted in Ukraine, and that those domains mostly carried names that seemed to be crafted as verbal jabs at the United States.

One of the images linked to in the guts of malware used in the Home Depot breach.

One of the images linked to in the guts of malware used in the Home Depot breach.

Curlovic said he can’t recall exactly what the domains were, since he no longer has access to his notes at work, but that one of the domains was something close to “vx.anti-usa-proxy-war[dot]com.” Curlovic said he no longer has access to his notes because he was terminated from Sally Beauty about three weeks ago for reasons his former employer declined to share. He said he found out through a person at the local Denton, Texas unemployment office that someone in the company had accused him of accessing another employee’s computer without authorization. “That’s a pretty strange accusation to make, since the network administrator guys there all have access to everyone’s system on the network.”

In any case, the anti-US domains referenced by the card-stealing malware reinforce a suspicion long held by this author and other researchers: That the Sally Beauty breach was carried out by the same Russian and Ukrainian organized crime gang that stole more than 100 million credit and debit cards from both Home Depot and Target.

As I noted in a Sept. 7, 2014 story, the malware used in the Home Depot breach included several interesting text strings that chastised the United States for its role in foreign conflicts, particularly in Libya and Ukraine.

“Three of the links point to news, editorial articles and cartoons that accuse the United States of fomenting war and unrest in the name of Democracy in Ukraine, Syria, Egypt and Libya. One of the images shows four Molotov cocktails with the flags of those four nations on the bottles, next to a box of matches festooned with the American flag and match ready to strike. Another link leads to an image of the current armed conflict in Ukraine between Ukrainian forces and pro-Russian separatists.”

“This is interesting given what we know about Rescator, the individual principally responsible for running the store that is selling all of these stolen credit and debit cards. In the wake of the Target breach, I traced a long list of clues from Rescator’s various online identities back to a young programmer in Odessa, Ukraine. In his many personas, Rescator identified himself as a member of the Lampeduza cybercrime forum, and indeed this site is where he alerts customers about new batches of stolen cards.”

“As I discovered in my profile of Rescator, he and his crew seemed somewhat taken with the late despotic Libyan leader Muammar Gaddafi, although they prefer the phonetic spelling of his name. The Web site kaddafi[dot]hk was among four main carding shops run by Rescator’s crew (it has since been retired and merged with Rescator[dot]cc). The domain kaddafi[dot]me was set up to serve as an instant message Jabber server for cybercrooks, advertising its lack of logging and record keeping as a reason crooks should trust kaddafi[dot]me to handle their private online communications.”

“When I reached out to Rescator last December to obtain comment about my findings on his apparent role in the Target break-in, I received an instant message reply from the Jabber address “kaddafi@kaddafi[dot]me” (in that conversation, the person chatting with me from that address offered to pay me $10,000 if I did not run that story; I declined). But I also discovered that the kaddafi[dot]me domain was a blog of sorts that hosted some harsh and frankly chilling anti-American propaganda.”

Curlovic said the incident response team cleaning up the 2014 breach at Sally Beauty found another curious clue in the malware that attackers planted on the point-of-sale devices. They discovered that the intruders had created two versions of the card-stealing malware — one designed for use on 32-bit Windows systems and another created for use on 64-bit versions of Windows. The authors of the malware had taken the time to add an icon to the 32-bit version of the program that could be seen if anyone opened the directory where the malware was placed: The icon was little more than a black background with “Res” written in white lettering.

This kind of signing also was seen in the malware used in the Target intrusion, which contained the following text string: ““z:\Projects\Rescator\uploader\Debug\scheck.pdb”.

PayIvy Sells Your Online Accounts Via PayPal

mercredi 6 mai 2015 à 06:57

Normally, if one wishes to buy stolen account credentials for paid online services like Netflix, Hulu, XBox Live or Spotify, the buyer needs to visit a cybercrime forum or drop into a dark Web marketplace that only accepts Bitcoin as payment. Increasingly, however, these accounts are showing up for sale at Payivy[dot]com, an open Web marketplace that happily accepts PayPal in exchange for a variety of stolen accounts.

A PayIvy seller advertising Netflix accounts for a dollar apiece.

A PayIvy seller advertising Netflix accounts for a dollar apiece. Unlike most sites selling hacked accounts, this one takes PayPal.

Marketed and sold by a Hackforums user named “Sh1eld” as a supposed method of selling ebooks and collecting payments for affiliate marketers, PayIvy has instead become a major conduit for hawking stolen accounts and credentials for a range of top Web services.

There is no central index of items for sale via PayIvy per se, but this catalog of cached sales threads offers a fairly representative glimpse: License keys for Adobe and Microsoft software products, user account credentials in bulk for services like Hulu, Netflix, Spotify, DirecTV and HBO Go, as well as a raft of gaming accounts at Origin, Steam, PlayStation and XBox Live. Other indexes at archive.is and PayIvy’s page at Reddit reveal similar results.

It’s not clear how or why PayPal isn’t shutting down most of these merchants, but some of the sellers clearly are testing things to see how far they can push it: In just five minutes of searching online, I found several PayIvy sellers who were accepting PayPal payments via PayIvy for…wait for it…hijacked PayPal accounts! The fact that PayIvy takes PayPal as payment means that buyers can purchase hacked accounts with [stolen] credit cards — or, worse yet, stolen PayPal accounts.

Jack Christin, Jr., associate general counsel at PayPal, said while the site itself is not in violation of its Acceptable Use Policies (AUP), there have been cases where PayPal has identified accounts selling goods that violate its policy and in those cases, the company has exited those merchants from its system. 

“PayPal proactively monitors sellers with PayPal accounts who use the Paylvy platform to ensure the products they are selling are in compliance with our AUP, and we take appropriate action when violations are discovered,” Christin said.

The proprietor of PayIvy (quite possibly this guy, according to many of his fellow Hackforums users) makes money off of the service by selling “premium” accounts, which apparently offer repeat sellers a way to better track and manage their sales. Appropriately enough, among his ebook offerings via PayIvy is a tutorial on how to avoid getting one’s account banned or limited by PayPal. PayIvy did not respond to requests for comment.

Sh1eld makes clear how he feels about his users selling hacked accounts to pay services via his site in this thread, where he posts about takedown requests from a company representing Netflix.

“We are not under any obligation to follow any site’s TOS [terms of service],” he wrote. “However, we will take actions regarding copyrighted content, malicious files, or child pornography.”

I wonder how this individual would feel about people selling stolen PayIvy premium accounts?

If you’re curious about the underground’s interest in and valuation of your online accounts, take a look at my primers on this subject, including The Value of a Hacked Email Account and the Value of a Hacked PC. Want pointers on how to avoid becoming the next victim? Check out my Tools for a Safer PC tutorial.

Update, 10:33 a.m. ET: PayIvy just sent the following message to all of its sellers: “Starting May 15th, PayIvy will be banning all netflix accounts. If you are still selling these accounts, we advice you to stop as your paypal account will be limited as part of PayPal AUP. You have 9 days to delete your Netflix products before we do a search and remove them ourselves.”

Sally Beauty Card Breach, Part Deux?

lundi 4 mai 2015 à 16:18

For the second time in a year, nationwide beauty products chain Sally Beauty Holdings Inc. says it is investigating reports of unusual credit and debit card activity at some of its U.S. stores.

Last week, KrebsOnSecurity began hearing from multiple financial institutions about a pattern of fraudulent charges on cards that were all recentlysally used at Sally Beauty locations in various states. Reached for comment on Sunday about the fraud pattern suggesting yet another card breach at the beauty products chain, Sally Beauty issued the following statement this morning:

“Sally Beauty Holdings, Inc. is currently investigating reports of unusual activity involving payment cards used at some of our U.S. Sally Beauty stores. Since learning of these reports, we have been working with law enforcement and our credit card processor and have launched a comprehensive investigation with the help of a leading third-party forensics expert to aggressively gather facts while working to ensure our customers are protected. Until this investigation is completed, it is difficult to determine with certainty the scope or nature of any potential incident, but we will continue to work vigilantly to address any potential issues that may affect our customers.”

Their statement continues: “Consistent with our ‘Love it or Return It’ policy, customer security and confidence remains our number one priority. As a result, we encourage any customer who is concerned about the security of their payment cards to call our Customer Service Hotline at 1-866-234-9442, so that we can assist them in addressing any potential concerns. Sally Beauty will, as appropriate, provide updates as we learn more from our investigation.”

In addition, the company also sent out an urgent alert today to its employees, asking associates to direct any customers with credit card issues to the Sally Beauty Web site or to call customer service. “We hadn’t gotten an email like that since last year when we had our breach,” the Sally Beauty employee said on condition of anonymity.

On March 5, 2014, this publication first reported that a batch of more than 282,000 cards that went up for sale on Rescator[dotc]cc — the same site that was first to sell cards stolen in the Home Depot and Target breaches — all traced back to customers who’d shopped at Sally Beauty locations nationwide. Asked about that pattern at the time, a company spokesperson said Sally Beauty had recently detected an intrusion into its network, but that neither its information technology experts nor an outside forensics firm could find evidence that customer card data had been stolen from the company’s systems.

But on March 17, 2014, Sally Beauty officially confirmed a breach of its network, but said its investigation determined that fewer than 25,000 card accounts were removed from its network. Nevertheless, a subsequent, exhaustive analysis of the Sally Beauty store ZIP codes listed in the cards for sale on Rescator’s site indicated that the 2014 breach impacted virtually all 2,600+ Sally Beauty locations nationwide.

Sally Beauty is not alone in dealing with separate card compromise incidents in a short period of time. Last month, hotel franchise management firm White Lodging disclosed that for the second time in a year, hackers had broken into point-of-sale systems at food and beverage outlets inside of many of its franchise locations.

It is possible that Sally Beauty locations are feeling the brunt of a large number of compromises at point-of-sale vendors, such as the recently announced breach among Harbortouch POS customers. However, at least two banks contacted by this author say the cards they were alerted to by Visa and MasterCard that correspond to the Harbortouch incident have very little overlap with the customer cards that were hit with fraudulent charges in the wake of their use at Sally Beauty locations recently.