Target Hackers Broke in Via HVAC Company?

February 06, 2014, Adam Shnider, VP, West Region, Professional Services

When I first heard about the account used to gain access to the Target environment, my first reaction was to laugh at the ridiculousness of the HVAC vendor having an impact on the CDE like it seems to (or is rumored) to have had in the recent breach.  Then I started thinking with the PCI controls, including 8.5.6, requirements for revoking vendor access, how could an HVAC vendor account be the culprit for such a broad attack and how could this affect our customers.

Because I have no direct information about the attack vector and breach, the following is just a hypothetical, yet, real risk that organizations could be facing today.

What can someone do with a seemingly unrelated account

First, I was putting together a scenario of why the HVAC vendor would have access to the CDE and it occurred to me, "What if the HVAC vendor didn't have access to the CDE?" This led me to start thinking about "How could this account be used?"

How can this account be used?

For starters, let's make the assumption that this system is a Windows systems that is Domain connected to the Target corporate domain and Target uses the same domain or a trust with the domain for the CDE (this is not unheard of).  The attacker then uses the account to access the known systems (billing systems, HVAC or other possible authorized systems.)  Well, now we are getting somewhere.  There is a treasure trove of data on any given system that once I get access I can use against my target.  Let's count the ways:

  • Dump the SAM (security database) to get all usernames and crack the passwords that are cached
    • That is right, every Windows systems keeps a local cache of everyone that has logged into the system and can be downloaded once I have any credentials to the system.  Sure the passwords are encrypted but no account lockouts are going to stop my brute force attack of the passwords offline.  And maybe, just maybe, there is a Domain Admin or other individual with escalated privileges that has logged in the last 90 days and password is still valid.
  • Get the local Administrator account and password
    • And would it be too crazy to think that this password is different on every system on the corporate network.  Oh man, if I had a penny for every time I have heard on a corporate network that they use a standard password for all local Administrator accounts I would be a rich man.  Or at least a simple nomenclature that is easy to guess based on serial number or system name.
  • Get other juicy information from the local system that may lead to information that could help attack other systems and domain controllers

Privilege Escalation:

Now that I have an account what can I do with it, just about anything I want and will largely go undetected because…..it will look and feel like authorized access.  Here are some fun things that can be done with an admin account once obtained:

  • Local Administrator accounts (especially if they are same or a simple nomenclature) can be used to log into other corporate assets (workstations, servers, etc) to dump more SAM files and see what accounts are there and keep digging until you get the juiciest of accounts, a Domain or Enterprise Admin account.
  • Local Administrator account can be used to install local domain management tools to then open the Domain Users and Workstations and review what usernames you may want to target that have the privileges you want.
  • Domain Admin accounts can be used to…….well, do just about anything you want, like access a distribution server or Gold image and make changes and it will look like it was all done by authorized users.

Conclusion

A seemingly unrelated account can be used to escalate privileges and create chaos and havoc on any environment in which the same or trusted domains are used between a corporate network and sensitive network.

How can we prevent this?

Unplug everything and revert back to stone and chisel or the barter system.  Although that is an option, not very practical in this day in age and neither is Bitcoin as that has its own issues.  The answer is vigilance, threat modelling and risk management.  Here are a few things that might help prevent this type of issue.

  • Domain and sensitive system isolation.  Setting up separate domains and networks for the PCI environment.  PCI has been pushing in this directly and you can see why.  Who would have thought my refrigeration vendor that keeps my store comfortable or my Coke's cold was a risk to PCI?
  • Segmentation with additional credentials to access the CDE systems.  How about some bastion hosts (jump boxes) with two-factor authentication between general corporate networks and sensitive networks?  Let's make sure we put all the right systems behind this jump box, log servers, anti-virus servers, deployment servers, patching servers, etc.  This may reduce the risks of pivoting between segmented environments even if the base Domain credentials are compromised.
Adam Shnider

Author

Adam Shnider — VP, West Region, Professional Services

Recent Posts

Post Topics

Archives

Tags