Stolen credentials were used in the South Carolina data breach, according to a report prepared by a forensics team investigating the incident.
The IRS, which we were compliant with, does not believe that you have to encrypt Social Security numbers.
S.C. Gov. Nikki Haley
The data breach, which exposed millions of Social Security numbers, bank account information and thousands of credit and debit card numbers, began with a phishing attack on Aug. 13. At least one employee clicked on an embedded link which executed malware on the employee's machine, according to the Public Incident Response Report (.pdf), prepared by Alexandria, Va.-based Mandiant. The firm said it was unable to determine how the employee's credentials were obtained by the attacker.
Two weeks after the phishing attack, an attacker logged into the South Carolina Department of Revenue's remote access service using legitimate credentials. Using a Citrix portal, the attacker used the employee's access rights to log into more sensitive systems, exposing the sensitive data, according to the report.
South Carolina officials were tipped off to the potential of a data breach after law enforcement contacted them Oct. 10 warning that several taxpayers who used the Department of Revenue's system were victims of identity theft. Two days later Mandiant's forensics team began to investigate the scope of the breach and contain it.
For a period of two months, the attacker gained access to systems, deploying malicious software to obtain more credentials and gain access to six servers, according to the report. The attacker then installed a backdoor enabling easy access to the systems.
In all, the attacker gained access to 44 systems, installed a backdoor on one server and stole database backups and files on three systems. "The attacker performed such activities as reconnaissance and password hash dumping," according to the report, issued Tuesday.
In a news conference associated with the release of the report, South Caroina Gov. Nikki Haley blamed the IRS for the breach, but took responsibility for not going above and beyond the IRS's security compliance mandates. The Department of Revenue did not have duel verification to get into its system, making it easier for an attacker to use stolen credentials to gain access. Social Security numbers were not encrypted.
"If you combined the fact that we had 1970 equipment with the fact that we were IRS compliant was a cocktail for an attack," Haley said. "The IRS, which we were compliant with does not believe that you have to encrypt Social Security numbers. … We should have done more than we did."
Data breach stats
Verizon 2012 DBIR recommends log analysis and password management:
The 2012 DBIR highlights prevalent problems with simple, relatively inexpensive recommendations.
Verizon DBIR 2012: On Web app security, basics still lacking
Expert Michael Cobb analyzes takeaways from the Verizon DBIR 2012 report regarding Web app security and the need for more basic security measures.
Victims of the breach were all electronic filers, according to Haley. In addition to the 3.8 million people whose data were exposed, the breach included information on 1.9 million dependents. It also included data on 699,900 businesses. Information on 3.3 million bank accounts were also stolen.
The attacker showed his prowess, according to the report. In addition to the backdoor Trojan, multiple password dumping tools were used, administrative utilities were deployed, Windows batch scripts were enabled to perform scripted actions and generic utilities helped to execute commands against databases.
"The attacker used at least four valid Department of Revenue user accounts during the attack," according to the report.
According to the report the attacker created 15 encrypted archives containing 74.7 GB of data, which contained a combination of encrypted and unencrypted data.
"All instances of encrypted data within the various databases were encrypted using an industry standard two-key method that leveraged the AES 256-bit encryption standard. One key was used to encrypt the data (“encryption key”); the second key was used to protect the encryption key by encrypting it (“key encrypting key” or KEK)," according to the report. "No evidence was discovered to suggest that the attacker stole, or accessed, the key encrypting key."
Stolen credentials are at the core of most breaches, according to The 2012 Verizon Data Breach Investigation's Report. In addition to stolen credentials the report calls out remote access system weaknesses and said most firms that experience a breach learn of it from an external source. Log analysis and password management were among the Verizon DBIR's recommendations.