Some Thoughts on the Carbanak Attack and Security Control Failures

February 18, 2015 Jacob Ansari

Anyone reading tech news this weekend likely saw the headlines about a malware attack used to track bank employee activity and mount attacks to make fraudulent ATM withdrawals and send money to dummy accounts. Brian Krebs, who started tracking this story late last year, points out that the targeted emails with malware relied on vulnerabilities that Microsoft had previously patched.

The Kaspersky report he cites specifically states that the Carbanak malware used Microsoft Word 97-2003 (.doc) files and Control Panel Applet (.cpl) files and that the specific vulnerabilities date from as far back as 2012. Further, the Kaspersky report states that once attackers gained access to the infected machines “[they] perform a manual reconnaissance of the victim’s networks.”

Using the video captured from the compromised machines, the attackers observed the victim’s user practices and targeted other machines within the institution to learn how the organization interacted with ATMs, made SWIFT transactions, and other means of making financial disbursements. Then, impersonating the legitimate users, the attackers moved money into dummy accounts under their control, withdrew money from ATMs using money mules, issued payment cards to associates, and withdrew funds, often taking pains to avoid fraud alerts by staying below trigger thresholds of amounts withdrawn.

What we learn from the Carbanak attack is that these attackers patiently worked on the victim organizations, sometimes having access for two to four months in a victim institution, and that these attackers learned the uses and controls around various financial mechanisms used by the victim organizations. Further, these attacks often did not attack customer accounts, which would have been similar to attacks against small business and payroll accounts that have come to prominence in the last few years. Instead the attackers focused directly on systems used by financial institutions, in particular the ATM and SWIFT networks.

If we can draw a few lessons from what we learn about this attack, here are perhaps the most apparent:
  • Prioritize aggressive and thorough patch management – The initial attacks did not involve a lot of slick trickery, rather they mainly exploited old vulnerabilities in some old software. Regular, thorough patch applications with some useful independent verification steps could mitigate a lot of attacks, both of the news-worthy sorts and those that attract less media attention.
  • Invest more effort in analysis of and response to log collection and recording. The malicious executables disguised themselves with fairly standard malware camouflage techniques, but searches for anomalous processes running on the affected systems could have at raised some inquiry. People, effort, and brainpower come first – shiny enterprise software second.
  • Limit egress access – This often takes some serious business process re-engineering, but using firewall rules to restrict what can go out has as much importance as limiting what can come in from outside. Doing so often prevents attackers from capitalizing on initial attack successes and attackers will often move on from organizations well defended for easier targets. The Kaspersky report describes the initial attacks as using minimal efforts and proper egress filtering often defeats minimal efforts. Even restricting egress access for key systems like those that service ATMs or process SWIFT transactions (and restricting access to these systems from other internal networks without a clear business need to access them) could have had some benefit against such an attack.
  • Perhaps most importantly, implement controls with an eye to an attacker trying to defeat them. A truism in security assessment and compliance holds that the compliance minimum only suffices if your organization has no worse threat than your auditor. Strongly consider real-world threat scenarios (and research actual threats!), as well as model attacks against them. Make real use of a risk assessment exercise as a sober look at your asset values and threats against them. Implement control measures against threats that loom on the horizon, so that the security architecture remains adequate when these threats become more practical. Look at a more no-holds-barred approach to penetration testing, particularly allowing things like social engineering and phishing schemes. Then buckle up and hold on tight.

In the end, the Carbanak attack represents a measure of sophistication in the cooperation and operations of the criminals responsible, rather than a particularly new or sophisticated technology. This attack so demonstrates that attackers continue to demonstrate an increasing measure of patience and resourcefulness, and that sometimes an attack merits attention not for its technical sophistication, but for the extent of its operations. As such, we need to account for these sorts of adversaries in planning and operating our defenses and controls.

1. The New York Times - Carbanak, Bank Hackers Steal Millions via Malware
2. - Gang Hacked ATMs from Inside Banks

About the Author

Jacob Ansari

Jacob Ansari is a Senior Manager at Schellman & Company. Jacob performs and manages PCI DSS assessments. Additionally, Jacob oversees other Payment Card Industry assessment services, namely PA-DSS, P2PE, and 3DS. Jacob's career spans nearly 20 years of information security consulting and assessment services, including network and application security assessments, penetration testing, forensic examinations, security code review, and assessment of cryptographic systems. Jacob has performed payment card security compliance assessments since the payment card brands operated their own standards prior to the advent of PCI DSS.

More Content by Jacob Ansari
Previous Article
SOC 2: Overview
SOC 2: Overview

What is a SOC 2 examination? How is it different than a SOC 1 examination?

Next Article
The Value of a Readiness Assessment
The Value of a Readiness Assessment

Readiness Assessments are designed to assist service organizations in assessing their preparedness for diff...


First Name
Error - something went wrong!