The Kaspersky report on Carbanak landed yesterday and I have spent the morning reading it twice (Carbanak APT, Kaspersky, February 16, 2015). It is one of the most operationally instructive incident reports I have read in some time, and it changes the threat model I use when scoping financial-services engagements.
The headline number — up to a billion US dollars stolen across roughly a hundred banks in thirty countries since approximately late 2013 — is the figure that will be in tomorrow's papers. The figure that should be in front of every bank CISO is the operational pattern, which is patient, careful, and entirely composed of techniques that have been on the discussion table for years.
Initial access is spear-phishing. Microsoft Office documents with embedded exploits — CVE-2012-0158, CVE-2013-3906, CVE-2014-1761 are the three most cited in the report, all of them old, all of them long since patched, all of them effective against bank workstations because the patching cadence in financial-services back offices remains, on the evidence, dismal. The implant is a backdoor the report calls Carbanak, a derivative of Carberp with bespoke command-and-control. From the implant, the operators reconnoitre. They do not move fast. They identify employees whose duties involve money handling — money mules, payment processing operators, ATM management staff — and they instrument their workstations.
The instrumentation is the part that has me reorganising my notes. They install screen-recording software. They watch the operators do their work. They learn the layouts of the institution-specific software, the procedures for transfers, the timing of approvals, the names of internal counterparties. Then, when they have enough understanding, they impersonate. They use legitimate tools — remote administration, scheduled tasks, PowerShell, the standard battery — to make transfers to accounts under their control, to inflate balances and withdraw the inflated portion through mules, or to instrument ATMs to dispense cash on a schedule that confederates can collect.
What I take from this for the engagement work is twofold. First, the assumption I make in scoping financial-services pen tests — that the threat model centres on customer-facing systems, online banking, card data, the perimeter — is too narrow. Carbanak demonstrates a sustained, profitable, repeatable campaign against the back office. The control surface that matters is the workstation of the payment-operations clerk and the transfer-system terminal she uses, not the public website. I will be rewriting my engagement-scoping templates this week to surface that explicitly.
Second, the report reinforces a thing I have been saying to vCISO clients about visibility on internal accounts. Carbanak operators are in the network for two to four months on Kaspersky's account before they execute. That is two to four months in which a sufficiently observant SOC, with the right baselining on user-of-application behaviour, could have noticed. The signal exists. The question is whether the SOC is looking at the signal that matters, or at the noise floor of perimeter alerts and antivirus events. Most are looking at the noise floor.
Detection opportunities, working from the technical indicators in the appendix:
The C2 domains have a specific pattern; many include obvious bank-themed strings, which is not subtle, and some banks would have caught this on a thirty-second glance at egress logs if anyone had been looking at egress logs. The implant's persistence mechanism uses a service named "MICROSOFT EVENTLOG" with a specific binary path that is identifiable. The screen-recording component drops files in temp directories with a pattern that is signaturable. PsExec usage at scale across non-IT subnets is a strong indicator. So is RDP from workstation to workstation, particularly at unusual hours.
I have pulled the indicator list into a Splunk search pack for our own SOC and for the financial-services customers who run their detection on our platform. The risk of noise in those searches is real — PsExec is used legitimately by many IT teams, RDP is used routinely by support desks — but the searches are tunable, and the alternative is silence.
The reporting question is harder. Kaspersky names no banks. The bank victims have a strong commercial reason not to disclose. That information asymmetry is corrosive: every bank board that reads tomorrow's papers will ask "are we one of the hundred", and the bank's own security team will not, in many cases, know. The report makes peer-effort more difficult than it should be. I do not have a good answer for that — disclosure norms in financial services are governed by regulatory and competitive considerations that are not going to shift on the basis of one Kaspersky paper — but it is the structural problem behind the technical one.
The thing I keep coming back to is the patience. The Carbanak operators are not opportunists. They are running a long-cycle commercial enterprise with research, development, victim cultivation, harvest, and laundering, and they are doing it well enough to keep doing it for over a year against well-resourced targets. The defensive posture has to match that timescale. Annual penetration tests with two-week engagements do not match it. Quarterly red-team work with detection-engineering follow-up does. That is a conversation I am going to be having a lot in March.