Continuous Endpoint Monitoring for Indicators of Compromise— Carbanak APT Case Study

by Al Hartmann

February 20, 2015

access_time 5 min read

Part 1 in a 3 part series

Background of the Carbanak APT

Recent news accounts have highlighted a potential billion dollar bank heist by unknown cybercriminals targeting over a hundred banks in almost thirty nations worldwide. The attacks were well underway by early 2014 and are still expanding to additional countries. In most cases the victim organizations were thoroughly compromised for months across hundreds of endpoints before experiencing financial losses. As most of the victim organizations were experienced financial industry participants, they had taken measures, including deployment of network and endpoint security software, that unfortunately provided little or no warning of or protection against the attacks.

Several security firms have subsequently provided technical reports on these attacks, codenamed as either Anunak or Carbanak, that list observed indicators of compromise. These firms include:

This report serves as a case study of this attack to address the questions:

  1. Why were traditional network and endpoint security ineffective in either preventing or detecting the attacks?
  2. How would continuous endpoint monitoring (as exemplified by Ziften) have provided early warning of the endpoint compromises to interdict the kill chain and avoid losses?

Ineffectiveness of Traditional Network and Endpoint Security

Traditional network and endpoint security are based upon the legacy security model of over-reliance on prevention and blocking, rather than a more balanced reliance across prevention, blocking, detection, and response. Even moderately-resourced cybercriminals can readily afford the effort to pre-test their attack code against the small collection of likely enterprise network and endpoint security products to ensure evasion. In many cases the attackers have performed reconnaissance to identify the specific security products used by the victim organizations and are skilled at evading these products. This is facilitated by the traditional philosophy of use of these products, which is that they only take action upon a conviction, but otherwise remain largely silent—if they fail to convict, they fail to inform. This results in the normal endpoint operation being largely opaque to IT security staff, which effectively masks attack activity (that has already been tested to evade conviction). Once an initial compromise has succeeded, that beachhead can be readily extended by pivoting towards more privileged users and more sensitive endpoints. Often this can be done by credentials theft, with no malware required, and common IT tools (already whitelisted within the victim organization) can be employed by attacker-devised scripts. Thus no telltale malware may be present to flag compromised endpoints (and user/admin accounts), given traditional endpoint security over-reliance on malware research and detection.

Evasion of traditional network security follows a similar approach. Attackers pretest their network activities to avoid detection by widely distributed IPS/IDS rules, and carefully observe normal endpoint operation (on compromised endpoints) to conceal their network activities within normal network traffic patterns and normal transaction periods. Fresh command and control infrastructure is established that is unknown to network address blacklists, either at the domain or IP levels. There is little here to give them away, although more astute network behavioral analysis, especially when correlated with endpoint context as discussed later in this blog series, can be more effective in this hunt.

But there is hope.   How would continuous endpoint monitoring (as exemplified by Ziften) have provided early warning of the endpoint compromises to interdict the kill chain and avoid losses? Stay tuned for part two to find out.