February 5, 2014

Last week, Target told reporters at The Wall Street Journal and Reuters that the initial intrusion into its systems was traced back to network credentials that were stolen from a third party vendor. Sources now tell KrebsOnSecurity that the vendor in question was a refrigeration, heating and air conditioning subcontractor that has worked at a number of locations at Target and other top retailers.

hvachooverSources close to the investigation said the attackers first broke into the retailer’s network on Nov. 15, 2013 using network credentials stolen from Fazio Mechanical Services, a Sharpsburg, Penn.-based provider of refrigeration and HVAC systems.

Fazio president Ross Fazio confirmed that the U.S. Secret Service visited his company’s offices in connection with the Target investigation, but said he was not present when the visit occurred. Fazio Vice President Daniel Mitsch declined to answer questions about the visit. According to the company’s homepage, Fazio Mechanical also has done refrigeration and HVAC projects for specific Trader Joe’s, Whole Foods and BJ’s Wholesale Club locations in Pennsylvania, Maryland, Ohio, Virginia and West Virginia.

Target spokeswoman Molly Snyder said the company had no additional information to share, citing a “very active and ongoing investigation.”

It’s not immediately clear why Target would have given an HVAC company external network access, or why that access would not be cordoned off from Target’s payment system network. But according to a cybersecurity expert at a large retailer who asked not to be named because he did not have permission to speak on the record, it is common for large retail operations to have a team that routinely monitors energy consumption and temperatures in stores to save on costs (particularly at night) and to alert store managers if temperatures in the stores fluctuate outside of an acceptable range that could prevent customers from shopping at the store.

“To support this solution, vendors need to be able to remote into the system in order to do maintenance (updates, patches, etc.) or to troubleshoot glitches and connectivity issues with the software,” the source said. “This feeds into the topic of cost savings, with so many solutions in a given organization. And to save on head count, it is sometimes beneficial to allow a vendor to support versus train or hire extra people.”

CASING THE JOINT

oktarget

Investigators also shared additional details about the timeline of the breach and how the attackers moved stolen data off of Target’s network.

Sources said that between Nov. 15 and Nov. 28 (Thanksgiving and the day before Black Friday), the attackers succeeded in uploading their card-stealing malicious software to a small number of cash registers within Target stores.

Those same sources said the attackers used this time to test that their point-of-sale malware was working as designed.

By the end of the month — just two days later — the intruders had pushed their malware to a majority of Target’s point-of-sale devices, and were actively collecting card records from live customer transactions, investigators told this reporter. Target has said that the breach exposed approximately 40 million debit and credit card accounts between Nov. 27 and Dec. 15, 2013.

DATA DROPS

While some reports on the Target breach said the stolen card data was offloaded via FTP communications to a location in Russia, sources close to the case say much of the purloined financial information was transmitted to several “drop” locations.

These were essentially compromised computers in the United States and elsewhere that were used to house the stolen data and that could be safely accessed by the suspected perpetrators in Eastern Europe and Russia.

For example, card data stolen from Target’s network was stashed on hacked computer servers belonging to a business in Miami, while another drop server resided in Brazil.

globeauth

Investigators say the United States is currently requesting mutual legal assistance from Brazilian authorities to gain access to the Target data on the server there.

It remains unclear when the dust settles from this investigation whether Target will be liable for failing to adhere to payment card industry (PCI) security standards, violations that can come with hefty fines.

Avivah Litan, a fraud analyst with Gartner Inc., said that although the current PCI standard (PDF) does not require organizations to maintain separate networks for payment and non-payment operations (page 7), it does require merchants to incorporate two-factor authentication for remote network access originating from outside the network by personnel and all third parties — including vendor access for support or maintenance (see section 8.3).

In any case, Litan estimates that Target could be facing losses of up to $420 million as a result of this breach, including reimbursement associated with banks recovering the costs of reissuing millions of cards; fines from the card brands for PCI non-compliance; and direct Target customer service costs, including legal fees and credit monitoring for tens of millions of customers impacted by the breach.

Litan notes these estimates do not take into account the amounts Target will spend in the short run implementing technology at their checkout counters to accept more secure chip-and-PIN credit and debit cards. In testimony before lawmakers on Capitol Hill yesterday, Target’s executive vice president and chief financial officer said upgrading the retailer’s systems to handle chip-and-PIN could cost $100 million.

Target may be able to cover some of those costs through a mesh network of business insurance claims. According to a Jan. 19 story at businessinsurance.com, Target has at least $100 million of cyber insurance and $65 million of directors and officers liability coverage.

Update, Feb. 6, 3:33 p.m. ET: Fazio Mechanical Services just issued an official statement through a PR company, stating that its “data connection with Target was exclusively for electronic billing, contract submission and project management.” Their entire statement is below:

Fazio Mechanical Services, Inc. places paramount importance on assuring the security of confidential customer data and information.  While we cannot comment on the on-going federal investigation into the technical causes of the breach, we want to clarify important facts relating to this matter:

–          Fazio Mechanical does not perform remote monitoring of or control of heating, cooling and refrigeration systems for Target.

–          Our data connection with Target was exclusively for electronic billing, contract submission and project management, and Target is the only customer for whom we manage these processes on a remote basis.  No other customers have been affected by the breach.

–          Our IT system and security measures are in full compliance with industry practices.

Like Target, we are a victim of a sophisticated cyber attack operation.  We are fully cooperating with the Secret Service and Target to identify the possible cause of the breach and to help create proactive initiatives that will further enhance the security of client/vendor connections making them less vulnerable to future breaches.


268 thoughts on “Target Hackers Broke in Via HVAC Company

  1. Tom Fiorillo

    Some of the HVAC monitoring software uses an older version of Java. The software does not appear to be well updated. Also, it is not uncommon for companies to just connect their HVAC equipment to the rest of their network. Best practice for any SCADA system would be to have it on a separate network, or on a dial back system. I guess the hackers had to decide whether to mess with Target’s HVAC system or steal millions of credit cards, not much of decision.

  2. JJ

    The HVAC company said that they did not manage HVAC systems for Target. They had a login for project management, contracts and related issues. http://faziomechanical.com/Target-Breach-Statement.pdf

    It does say “data connection” but does not specify what type. A much earlier post claimed it was an RDP connection without specifying where the knowledge came from. That would make a lot more sense than a dedicated private line or a site-to-site VPN for the activities Fazio mentioned.

    Way too many companies, large and small, just allow RDP directly on the Internet “because it’s encrypted by default” (at least in Server 2008 and later). If it’s a domain-joined computer, as it almost certainly would be, it now comes down to how they kept domain separated from the others and how they kept that remote connection separated (and how well it was patched and monitored). The mere fact that a computer is domain-joined reveals the name of the domain in the login dialog box.

    Best guess for a company with around 2,000 locations and 360,000+ employees is it got dumped on a network segmented from the payment network but with wide access to their internal corporate network. That would remove the PCI 2-factor requirement and allow that RDP server to access the other AD resources it needs to perform its intended functions.

    This is one of the reasons why PCI 3.0 now requires a formal pen test to prove segmentation as opposed to a cursory review of the administrative controls.

    A classic PCI whitepaper from a QSA talks about how they owned the entire internal network from the Internet via a pen test undetected and in short order but found the PCI zone bullet-proof. Nothing they did would allow them to break-in and almost everything they tried generated an alert., unlike the internal network. Separate accounts, separate AD forest, you name it, they did it right.

    Until the tester said to himself “Self, what are the chances they used the same admin login usernames and passwords in the PCI zone as they did for their internal systems?”

    Game over and without any alerting because it was a successful attempt and not a failed one.

    1. Rex

      Hi JJ,
      Could you please point me to that “A classic PCI whitepaper from a QSA” , if it is in public domain?
      thank you
      Rex

  3. JJ

    With regards to the comments about whether yet another security product could have detected the intrusion I have two observations. These are not directed at the posters so please do not take offense.

    1. If you think technology can fix security, you don’t understand technology and you don’t understand security.

    2. The root cause of a security incident is rarely about the technology and almost always about the implementation.

    If you think these two observations are directed at you and you are either a security technology salesperson or non-technical manager running a technical function, you might be correct. 🙂

    1. TheHumanDefense

      JJ,
      Your statement should be on every security teams portal across the nation. If I agreed with you anymore I might think your a brother of another mother.
      My business cards have this printed on the back: “security is not a technical solution, it’s a human resolution.” Let’s just understand Humans are in everything we do. Automation exists because humans make it so.

  4. T.B. Fitzgerald

    I am not confident in what Avivah Litan states regarding PCI applicability, though her statement may have been taken out of context. Take a look at requirement 7 and 8 of the referenced PCI document; requirement 9 is applicable in a sense albeit it is regarding physicals access. Anyone who has done PCI DSS for an ASV (Approved Scanning Vendor) has read this document at least once in its entirety and references it often during certification and scans. Moving on, these requirements in PCI DSS (and other regulatory compliances) are difficult for an ASV to audit simply because a vendors word may be the only verification that is possible. We can make speculations and do finger pointing but ultimately it is the responsibility of the vendor to monitor and audit their own network and the individuals that have access.

  5. Brent

    Hi Brian,

    I really enjoy your blog! Thank you so much for all of the hard work and investigation!

    I had an ancillary question to this Target breach that concerns me. I haven’t done enough research, but this is possibly where a number of the accounts may have been sourced.

    After visiting Target yesterday, I became concerned after they scanned the back of my drivers license (which I believe is called a pdf417 barcode to comply with the Real ID Act). They did this because I did not have a receipt for my return. I understand that they are tracking individuals for fraud purposes, but why is all of the information on the license required?

    I asked the employees about the scan and what they were doing with the information. The employees of course were clueless, as this appears to be a standard operating procedure.

    After using an Android scan app, I realized that just about all of the information on the front of the license is embedded in the code.

    Are there federal or state laws that prohibit using the information on the barcode for non-government or non-law enforcement purposes?

    Thanks!

    Brent

    1. Serena

      Brent, I did a quick Google search and came across a state ACLU web site which states that in that particular state there are only limited circumstances when a private business can scan your license. Unfortunately, verifying your identity during a return is one of those circumstances. How unfortunate! So what happens if you don’t have a driver’s license or state ID? Or what happens if you have one but tell the clerk that you don’t? We know it’s OK to not have an ID because the Democrats have declared it discriminatory to require one. (I never imagined something good would come of their ruse, but here it is.)

        1. Serena

          I am so bothered by this that I can’t clear my head! So there are laws allowing merchants to scan driver licenses but prohibiting them from selling the info. Who is policing them? Are we relying on internal whistleblowers? This might classify as “appalling”. I have not yet had my license scanned, I’ve only had to show it for visual checks. Thanks so much for the heads up, I’ll figure out how I’m going to handle the situation if it ever occurs. Maybe I’ll try “I don’t have a license” and see what the response is.

  6. JJ

    Yes, laws exist for drivers license information and they apply to companies because it is considered Personally Identifiable Information by the FTC.

    Yes, if Target collects it they have to protect it. You know, just like credit cards and contact information. 🙂

    And Target is within their rights to refuse your return request if you do not have a receipt and you do not have ID.

    BTW, many retailers subscribe to a service that alerts them to “frequent returners”. If you get tagged that way, you may find their return policy excludes returns by you. Scanning a DL eliminates data entry errors and gives a whole lot more information for the database including something about your likes and dislikes.

    It’s just like when a cashier asks for your phone number: tell them it’s unlisted. When they ask for your driver’s license, tell them you don’t carry it with you. See if they’ll accept something else or just press on. (Pro tip: Never tell them you hope to get it back from the judge soon.)

    1. Brent

      Thanks, JJ! It just doesn’t seem right that a retailer should use the information for such a purpose. I think it is justifiable to also question Target’s protection of Personally Identifiable Information. lol.

  7. JJ

    One lesson I learned way too late in life is that “Nobody messes up on purpose.” Once you adopt that philosophy you tend to take a deep breath, pause, and see things in a different light. Yes, I have known a few people who made me seriously question my philosophy. 🙂

    The people working at Target aren’t dumb or lazy and in this business all it takes is one tiny crack in your protections and someone will find it and pry you wide open, sometimes in just a few days. That crack can be a seemingly innocuous mistake by a co-worker or even you. This is no longer the realm of the lone hacker but rather worldwide, organized crime and they are much better financed and staffed than any of us could ever be.

    As far as their using that information, well, you voluntarily handed it over upon request in return for something of value to you, that refund. I do disagree with their scanning it without warning but since almost everyone would say “no”, they rely on people not protesting too loudly.

    1. Brent

      Thank you again, JJ. It was indeed my fault for handing over my license. It was a deer in the headlights moment after realizing they were scanning the license, versus manually taking information from it. Well, lesson learned.

  8. Rupert

    Great discussion. I did not see any mention of File Integrity Monitoring. PCI requires FIM to be in place and I was wondering whether this would have alerted that something was going on. Appreciate your thaoughts on this.

  9. Mike B.

    Meanwhile, back at the ranch (in the U.S.), we still carry magnetic strips on our credit cards instead of a digital chip that generates a unique code every time it’s used.

  10. JJ

    FIM will catch the dumb criminals. No good malware nowadays ever touches disk except maybe to store files in a system temp folder and nobody monitors a temp folder. If it never touches the disk, FIM is blind, deaf and dumb.

    Mike B., I’m not so sure of that. I’ve got a bud who works in security for a company that produces much of the plastic used around the world, including EMV. He’s said several times that the unique code feature is optional and many, many retailers don’t use it because it slows down transactions even more due to the back-and-forth communications needed. I don’t know enough about the technology to know if that is even possible.

    I do know that the mag stripe still exists because most ATMs won’t do EMV, even outside the USA.

    1. Rupert

      Thanks JJ. Given the increased sophistication of malware how do security practitioners defend against ram scraping attacks as it has been alleged to be the case in the Target breach. Is chip and pin implementation the solution? I believe that companies spend a lot of money to secure the perimeter of their network but ignore internal network security such as segmenting their networks i.e. a defense in depth approach. Plus running on old outdated technology make it easy targets for criminals.

      1. Paul

        Rupert asks how to defend from a RAM scraper. The answer is to encrypt at the swipe. Then you have to worry about the recent threat of hackers who substitute their device for yours, but this is easier than defending card numbers.

        Here’s the catch. You can’t really get it. We’ve begged every supplier, but you have to have a device, your POS software has to support it, and your processor has to also support it (unless you custom build a system to decrypt and reencrypt for sending to the processor.) Those three elements have to work together.

        All the processors talk about it. I haven’t found one that can actually deliver it for a moderately sized merchant. I’ve considered building a single board computer box that sits between the swipe and register computer, but get stymied because I can’t get inside the back end of the POS software.

        As far as I am concerned, the problem lies squarely with the processors. They have had end to end encryption for their standalone counter machines for many years, but they still drop the ball at the outside edge of the merchant network for POS based systems. There is no excuse for it, except that they are never the ones fined.

  11. JJ

    I’m not convinced your personal behavior matters much in whether your card gets swiped or not. I set online alerts on all bank accounts and payment cards so any transaction above $0 on the cards or bank accounts sends me a text. Chase even has special ones for gas station and online purchases. They usually arrive within a minute of my use of the card. The best defense is calling the number on the back of the card as soon as possible to kill the card.

  12. Seth

    I work for a DDC/BMS controls company that has personally put in these systems, and monitors them on a regular basis. If Target did not separate their billing and payment network from the HVAC network via VPN or a completely separate VLAN, the blame is solely on them. I have worked in casino’s, government buildings (both state and federal), and standard commercial properties, and never once have the customer put up on the same network as their financial servers. The blame lays SOLELY on Target IT department for this one. Would you ever give an outside mechanical contractor that is watching your thermostat access to your banking information? If that is the stance that Target takes on their customers security (to put it at risk and blame their shortcomings on another company), I personally would never run my card anywhere that is controlled by them. Bad network security Target! Very bad!

    1. al

      The vendor stated that they were not monitoring or controlling HVAC but instead stated that they had a login to a Target administrative system that has since been revealed as Ariba. Still, there was not sufficient separation between this system and much more sensitive systems such as the POS and the CRM system containing the customer contact information which was also stolen along with the CC numbers. That of course is Target’s responsibility and not the vendors. It could have been any number of vendors that led to the unfortunate result since many have access to the administrative system.

  13. Wayne

    Stuff like this is enough to make you want to go back to a cash only society … just disturbing!

  14. Rupert

    Would implementation of chip and pin and p2p encryption prevent such an attack? I have read that this attack would not be successful if the above was in place. Is this true? Does this mean that the data is never in the clear from start to finish of the transaction processing. Any feedback comments or information on this would be appreciated.

  15. JJ

    If Chip and PIN (EMV) is implemented properly it keeps the scraped data from being used to create duplicate physical cards. It would not prevent the data from being used for online and other card-not-present transactions. And since EMV cards need to retain a magnetic stripe for compatibility purposes, principally with ATMs, the attackers will focus on companies and channels that won’t or can’t upgrade their readers.

    Target is blowing smoke by saying this breach caused them to go to EMV cards. There is no doubt they were just going to do it anyway if just because of a late 2015 sort-of deadline. Except now they can say they are doing it to help protect their customers and it’s costing them a lot of money to protect their customers so we should be grateful.

    EMV reduces the card-present fraud for sure. And once a merchant reaches 75% of their transactions by EMV, the merchant is no longer required to have the very costly PCI audits. They still have to comply, they just don’t need a formal audit. (Cue the checkbox compliance )

    Merchants that do NOT switch to EMV will suddenly incur liability for card-present fraud, something they are currently shielded from.

    And those are the reasons Target is moving to EMV.

    1. Rupert

      Thanks for your response JJ. EMV looks like the real deal along with p2pe encryption. Given that this is a very secure method of processing payments do we really need FIM if this is in place. I guess PCI will waive this requirement as well. I do agree with you that criminals will move to targets that are easier to exploit. A cop told me once that if you have a home alarm system installed burglars may just try a home without one and skip your home.

  16. Steve

    JJ,
    Can’t you just scratch the magnetic strip on the back of your license to remove the data from it?

  17. JJ

    You could scratch the strip off as long as you don’t need it anywhere that requires it and there is no person to manually process the transaction like an ATM.

  18. JJ

    One of the big issues with PCI-DSS is that it’s a minimum baseline requirement. The card brands all have their own requirements on top of PCI that you also need to comply with as a merchant.

    So if Visa waives the requirement for an independent assessment when you hit 75% EMV transactions but MasterCard doesn’t and you accept both, guess what?

    Or if both Visa and MasterCard waive it but Discover and Amex don’t, guess what?

    I don’t see that scenario happening because the larger merchants that need an independent assessment could just drop the smaller ones and the smaller card brands know it.

  19. JJ

    @Rupert, this old joke has a lot of truth in it:

    “If you and your friend are being chased by a bear in the woods, you don’t need to out-run the bear. You just need to out-run your friend.”

    As a consumer and not a company the cop’s story is very applicable. But if you’re a company and someone is going after you specifically, you don’t have a prayer.

  20. JJ

    Sorry, @Steve, I just saw you mentioned “license” and not EMV card. I’d run a big rare earth magnet over a drivers license before I’d deface it. It’d be just your luck to get stopped and the cop uses the scraped strip as a pretext for something. That’s actually not a bad idea as long as you keep your mouth shut about doing it.

  21. Gary

    JJ, you make a good point regarding PCI baseline as I found out recently when I was reviewing a company’s compliance to PCI. I was informed that a decision was made not to implement FIM due to the cost. Instead they are implementing EMV and P2PE and stated that would remove the need for FIM. I checked the standards on the PCI council website but found no mention that a co would be exempt from requirement 11.5 if EMV and P2PE is in place. So I was thinking that they would not receive a ROC from their QSA but apparently there is a lot of leeway for QSAs to interpret the PCI requirement. I guess this will become an issue for the company if there is a breach and it is found out that the requirements were not met. Just wondering if a QSA is liable for providing a ROC when the company is not in compliance?

  22. JJ

    Disclaimer: I am not a QSA.

    Remember that a RoC is NOT a Report Of Compliance but rather a Report On Compliance. The RoC does NOT say you are compliant, it details your level of compliance.

    The RoC is submitted to the relevant card brand for their determination of whether it is acceptable. They can reject it or reject the compensating controls listed in it. They also can accept it as-is.

    If the QSA submits many defective RoCs they can be placed on “in remediation” status. They are listed in red on the PCI Council’s site until the deficiencies are corrected. No QSA wants that so they will be very careful.

    Anybody can be found liable of anything but it takes a court of law to do that. And proper corporate structure and bankruptcy usually ends that problem.

    I had heard that a proposed change to PCI 3.0 was to move approval for compensating controls from the card brands to the QSA but I don’t know that it actually happened. That would have raised the potential liability risk significantly for QSA’s and probably spelled an end to most convoluted, complicated compensating controls.

    1. Adrian Sanabria

      Disclaimer: I WAS a QSA (just a PCIP now)

      I have to correct a few items in your last statement:

      1. The ROC DOES say that you’re compliant. There’s no “level of compliance”. You are either compilant or non-compliant. PCI is all-or-nothing – you must be 100% compliant to pass.

      2. The ROC is not submitted to the card brand, but to the acquirer. The acquirer could be the merchant bank, credit card processor or both. AFAIK, the card brands only see a ROC if there is a breach and they’re trying to determine whether or not to levy fines. You are correct in that the acquirer can reject the QSA’s ROC or compensating controls. The acquirer is ultimately responsible for the merchant’s compliance, and therefore, they can reject a crappy QSA’s work. (NOTE: I don’t think I was a crappy QSA, but Bank of America kicked my ass one year – they are one of the few acquirers I encountered that actually read over ROCs before accepting them!).

      3. Going into remediation is based on the QA process implemented by the PCI council. It works like you say, but isn’t invoked by the acquirer and isn’t based on a number of ‘defective’ ROCs. In theory, a single ROC could bury you. The Council generally requests a single ROC (the QSAC gets to choose which one) every year to review from each QSAC. In practice, I doubt they decide based on a single ROC. They probably request more samples if the one you sent them was bad, and then decide.

      4. Compensating controls are just part of the ROC, and there is only one level of approval – the acquirer. It doesn’t make sense to move approval to the person that wrote the control. Moving liability to the QSAC would be very controversial if that’s what you’re implying. I did not see any changes in 3.0 suggesting such a liability change. Move the liability to QSACs, and I guarantee many would just shut down shop. Until the average QSA competancy level comes up considerably, we will probably have convoluted, complicated and unnecessary compensating controls for many years to come.

  23. JJ

    Thanks, Adrian. Yes, I wrote “card brand” when I meant acquirer. Sorry.

    What I wrote about the RoC is what our current QSA has said may times. That they submit it and it can be disapproved, so in that case it does not indicate compliance. The QSA thinks you are or they would not submit it but the acquirer decided otherwise, so you’re not compliant as based on that version of the RoC. If you’re up against your filing deadline and it’s disapproved, well, don’t wait so long next time. 🙂

    We interviewed a few companies who were put “in remediation”, as a lot of companies were, when the QA process first came out. They all indicated they had to submit a lot of RoC’s. Maybe they were just hanging themselves or something. One tried to defend themselves by saying it was just a disagreement over sample size. I asked what their sample size was versus the total population. They declined to answer. So I came to the conclusion that their sample size was zero and they got caught. They didn’t confirm or deny that assertion either. That was a short interview process with them. 🙂

    Can you speak to the number of compensating controls allowed in a RoC? I know there;’s no hard limit but we’ve heard from several QSA’s we’ve interviewed that when it gets over four or so that the RoC will usually be rejected because, as you wrote, “convoluted, unnecessary and complicated” translates to “not getting followed because it’s too difficult”.

    Again, thanks for your comments.

  24. Myra

    Hello to every one, it’s actually a nice for me to pay a visit this site, it consists of valuable Information.

Comments are closed.