Heartland Hackers Caught; Answers and Questions

By Rich

UPDATE: follow up article with what may be the details of the attacks, based on the FBI/Secret Service advisory that went out earlier this year.

The indictment today of Albert Gonzales and two co-conspirators for hacking Hannaford, 7-Eleven, and Heartland Payment Systems is absolutely fascinating on multiple levels. Most importantly from a security perspective, it finally reveals details of the attacks. While we don’t learn the specific platforms and commands, the indictment provides far greater insights than speculation by people like me. In the “drama” category, we learn that the main perpetrator is the same person who hacked TJX (and multiple other retailers), and was the Secret Service informant who helped bring down the Shadowcrew.

Rather than rehashing the many articles popping up, let’s focus on the security implications and lessons hidden in the news reports and the indictment itself. Let’s start with a short list of the security issues and lessons learned, then dig into more detail on the case and perpetuators themselves:

To summarize the security issues:

  • The attacks on Hannaford, Heartland, 7-Eleven, and the other 2 retailers used SQL injection as the primary vector.
  • In at least some cases, it was not SQL injection of the transaction network, but another system used to get to the transaction network.
  • In at least some cases custom malware was installed, which indicates either command execution via the SQL injection, or XSS via SQL injection to attack internal workstations. We do not yet know the details.
  • The custom malware did not trigger antivirus, deleted log files, sniffed the internal network for card numbers, scanned the internal network for stored data, and exfiltrated the data. The indictment doesn’t reveal the degree of automation, or if it was more manually controlled (shell).

The security lessons include:

  • Defend against SQL injection – it’s clearly one of the top vectors for attacks. Parameterized queries, WAFs, and so on.
  • Lock databases to prevent command execution via SQL. Don’t use a privileged account for the RDBMS, and do not enable the command execution features. Then, lock down the server to prevent unneeded network services and software installation (don’t allow outbound curl, for example).
  • Since the bad guys are scanning for unprotected data, you might as well do it yourself. Use DLP to find card data internally. While I don’t normally recommend DLP for internal network traffic, if you deal with card numbers you should considering using it to scan traffic in and out of your transaction network.
  • AV won’t help much with the custom malware. Focus on egress filtering and lockdown of systems in the transaction network (mostly the database and application servers).
  • Don’t assume attackers will only target transaction applications/databases with SQL injection. They will exploit any weak point they can find, then use it to weasel over to the transaction side.
  • These attacks appear to be preventable using common security controls. It’s possible some advanced techniques were used, but I doubt it.

Now let’s talk about more details:

  • This indictment covers breaches of Heartland, Hannaford, 7-Eleven, and two “major retailers” breached in 2007 and early 2008. Those retailers have not been revealed, and we do not know if they are in violation of any breach notification laws.
  • This is the same Albert Gonzales who was indicted last year for breaches of TJ Maxx, Barnes & Noble, BJ’s Wholesale Club, Boston Market, DSW, Forever 21, Office Max, and Sports Authority.
  • A co-coconspirator referred to in the indictment as “P.T.” was not indicted. While it’s pure conjecture, I won’t be surprised if this is an informant who help break the case.
  • Gonzales and friends would identify potential targets, then use a combination of online and physical surveillance to identify weaknesses. Physical visits would reveal the payment system being used (via the point of sale terminals), and other relevant information. When performing online reconnaissance, they would also attempt to determine the payment processor/processing system.
  • In the TJX attacks it appears that wireless attacks were the primary vector (which correlates with the physical visits). In this series, it was SQL injection.
  • Multiple systems and servers scattered globally were used in the attack. It is quite possible that these were the part of the web-based exploitation service described in this article by Brian Krebs back in April.
  • The primary vector was SQL injection. We do not know the sophistication of the attack, since SQL injection can be simple or complex, depending on the database and security controls involved.
  • It’s hard to tell from the indictment, but it appears that in some cases SQL injection alone may have been used, while in others it was a way of inserting malware.
  • It is very possible that SQL injection on a less-secured area of the network was used to install malware, which was then used to attack other internal services and transition to the transaction network. Based on information in various other interviews and stories, I suspect this was the case for Heartland, if not other targets. This is conjecture, so please don’t hold me to it.
  • More pure conjecture here, but I wonder if any of the attacks used SQL injection to XSS internal users and download malware into the target organization?
  • Custom malware was left on target networks, and tested ensure it would evade common AV engines.
  • SQL injection to allow command execution shouldn’t be possible on a properly configured financial transaction system. Most RDBMS systems support some level of command execution, but usually not by default (for current versions of SQL Server and Oracle after 8 – not sure about other platforms). Thus either a legacy RDBMS was used, or a current database platform that was improperly configured. This would either be due to gross error, or special requirements that should have only been allowed with additional security controls, such as strict limits on the RDBMS user account, server lockdown (everything from application whitelisting, to HIPS, to external monitoring/filtering).
  • In one case the indictment refers to a SQL injection string used to redirect content to an external server, which seems to indicate that malware wasn’t necessarily always used.
  • The malware attempted to hide itself. While details aren’t available, the indictment indicates it probably erased log files, at a minimum.
  • The attacks both sniffed traffic and attempted to identify stored card numbers. They targeted data at rest and in motion.
  • I’ve heard rumors from trusted sources that the exfiltrated data was not encrypted or otherwise obfuscated in at least one case.

Just as the TJX hack was based on well known issues with wireless security, these attacks seem to use well known SQL injection techniques. In a way I really hope I’m wrong, and that some new kind of advanced SQL injection attack was involved, but I think we’d see more bigger victims if that were the case. I also find it fascinating that a single individual is at the crux of multiple cases, and used to be a Secret Service informant. I hope more information is revealed about the “hacking platform” that may refer to systems referenced in the Washington Post article back in April.

Finally, does this mean we have two major retailers in violation of breach disclosure laws?

As is almost always the case, preventing these attacks wouldn’t necessarily have required rocket science or millions of dollars in specialized security tools.

Wired also has a good article.

No Related Posts

What an awesome idea! Deploying a custom malware that enables the promiscuite mode and sniffs for some good & valuable data, such as email username & password (to kidnap domains, get FTP and MySQL access, and much more) + credit card numbers, e-banking access and everything else.
Thanks for this idea of a malare that performs sniffing!

By ~

And there also is no spoon.

There’s always a perimeter.  (Rather than get into a Jericho group argument, let me just say they have good points, but adhering to their position feels like tackling security with tunnel vision goggles on. But the position can add value given the right scope.)

By LonerVamp

Undoubtedly these were Windows networks (since the criminals went around to investigate which system each company was using before attacking). Proper network security means using an OS that is hardened against attacks such as SE Linux or BSD on servers and desktops. When will the foolishness of an operating system mono culture end? Just look around, 99% of the security problems you see are Windows related though Linux runs the NYSE, Google, most of the internet (and millions of desktops worldwide.


The perimeter is no perimeter.

By anon

Identify your perimeter.
Defend your perimeter.

Identify your perimeter.
Defend your perimeter.

Identify your perimeter.
Defend your perimeter.

Identify your perimeter.
Defend your perimeter.

...of course, this is just like network defense 15 years ago where so many people were implementing things without a very good understanding at all of the security risks. I’m insinuating that we need to know web app attacks (and defenses) inside-out just like we’ve come to know how to hack networks naked. (I’m preaching to myself as much as anyone, since I’ll admit I’m behind the curve of other web app rock stars.)

By LonerVamp

“More pure-conjecture here, but I wonder if any of the attacks used SQL injection to XSS internal users and download malware into the target organization?”


” I really hope I’m wrong, and that some new kind of advanced SQL injection attack was involved”


By Anonymous

You make a good case for being proactive in tightening security, but proactive security is like buying insurance against a risk of loss.  In challenging economic times, individuals are dropping automobile insurance and organizations are so “tight” that they are squeezing nickels hard enough to make the buffaloes scream.  Doing nothing is cheaper in the short term.  Your vigilance and information is appreciated and I hope it doesn’t fall on deaf ears - but it probably will.  If proper database auditing mechanisms were in place, crimes like this wouldn’t be so hard to identify, isolate, and prosecute.  Oh, but… database auditing… that might involve a little bit of overhead, and overhead flies in the face of server consolidations, cost cutting and performance.  Who needs accountability for access to corporate data assets anyways?  Thanks for your contributions to this community.

Kind regards,

[link removed by management since it was a redirect to a corporate site, without full/normal attribution. We don’t mind product links, but you have to be up front about it -rich]

By Scott Hayes

If you like to leave comments, and aren’t a spammer, register for the site and email us at and we’ll turn off moderation for your account.