Fasten your seatbelts, this is going to be a long one. And perhaps my most important EE Journal article yet, though I will leave that determination to you and the perspective of time.
“I found the Duqu and Flame cyber espionage attacks more interesting AND more unnerving [than Stuxnet]. Duqu and Flame were arguably the most sophisticated malware attacks ever undertaken.”
From Silicon Valley—7 January 2015
“This story does not end with Flame. It’s highly likely there are other similar attacks already underway that we haven’t detected yet.”
Mikko Hypponen (security vendor F-Secure)—1 June 2012
“[Carbanak] is likely the most sophisticated attack the world has seen to date in terms of the tactics and methods that cybercriminals have used to remain covert.”
Chris Doggett (security vendor Kaspersky Labs)—14 February 2014
“Hackers are bleeding banks dry, stealing as much as $1 billion from more than 100 financial institutions in a string of attacks that borrow heavily from targeted attacks against sensitive government and industrial targets. The [Carbanak] attacks date back two years.”
Michael Mimoso—16 February 2015
My last blog post discussed the recent Anthem breach and made three modest recommendations vis-à-vis mitigations. News of the Carbanak attacks broke quite literally as I was writing that post; I read the preliminary news reports less than an hour after publishing on 14 February. In what in retrospect was a massive understatement, I wrote:
“The above are just three steps on the road to proper security; more needs to be done for effective defense against a determined adversary.”
Per Mr. Doggett’s comment above, my recommendations would not stand up against the very, VERY determined adversaries of the Carbanak Gang. In the interest of keeping you reading through to the very end of this article, however, the next sentence remains accurate with regard to what it takes to stop such complex attacks:
“Every bit of that technology exists today. “
No scrolling to the end, folks! Stick with me through the details and I’ll explain the above good news before wrapping up. The fasten seatbelts sign will remain lit through what will certainly be a new “longest article” mark for me.
Flame (2012)
I am going to start with Flame—I know all of you took my advice and read Countdown to Zero Day—to establish context using an intensely studied and well-documented attack.
Flame’s initial attack vector was spear (targeted) phishing email. That is, an email that appeared to come from a reputable source with an attachment that appeared harmless sent to any number of people on the attackers’ to-do list. All of the major anti-virus engines failed to catch the infected attachment, rather shocking given that:
“When we went digging through our archive for related samples of malware, we were surprised to find that we already had samples of Flame, dating back to 2010, that we were unaware we possessed. They had come through automated reporting mechanisms, but had never been flagged by the system as something we should examine closely. Researchers at other antivirus firms have found evidence that they received samples of the malware even earlier.”
Mikko Hypponen
Anti-virus companies get truckloads of potential malware, and there is just not enough time to examine all of it. As you will see, however, Flame was one of the most damaging pieces of malware ever constructed … so how could it not be examined and identified?
When it came to avoiding detection, Flame was obsessive compulsive: one of its first tasks upon infecting a machine was to hook/redirect a key Windows DLL entry point to one of the Flame modules; there it recreated the execution environment of the legitimate DLL, making its behavior appear normal.
This initial Flame infection was—no exaggeration—only the tip of the iceberg. After all, one can only stuff so much malware into a file attachment … so Flame phoned home. The attackers behind Flame set up almost 100 command-and-control (C&C) servers at hosting companies around the world. The infected machine would establish an SSL connection—they were way ahead of my “SSL Everywhere” recommendation—to a C&C server and download the next malware payload. This included keylogger and screen capture modules that recorded all activity on the machine for a number of days before uploading the results to a C&C server.
And here is where Flame gets really, REALLY scary.
Those recorded files from infected machines? They were reviewed by people; not computers, PEOPLE. And the amount of recorded data was staggering: security forensics experts found data dumps as large as 6 GBytes from single target machines. Based on the contents of the data dumps, those people decided on next steps on a machine-by-machine basis. Flame would NOT infect other machines on its network unless it was instructed to do so. If the target machine looked interesting enough, the human ‘operator’ would upload a package specifically tailored to infect other machines on the network.
Flame spread across a chosen network using multiple tactics, from tried-and-true USB drive infections to a particularly alarming zero-day exploit (which I will not describe here because you really ought to read Countdown to Zero Day). Suffice it to say, Flame was very effective once the operator decided to infect the network in question. Each newly infected machine would contact the C&C server and repeat the process, as directed by the attack team.
Team? That sounds paranoid! Who said anything about a team? Security experts at Kaspersky Labs and Symantec would later dissect the C&C code from actual servers and document the entire command-and-control operation:
Source: Symantec
Having infected large swaths of the network under attack, the attack team would upload specific modules to perform specific tasks on specific machines. No speculation here: security experts would later perform detailed forensic examination of the entire cornucopia of Flame modules (weighing in at well over 20 Mbytes). Beyond the aforementioned keylogger and screen capture capabilities, Flame was directed to:
- Map network topology
- Sniff network traffic for usernames and password hashes
- Record audio from a laptop’s built-in microphone
- Use a laptop’s Bluetooth to scan nearby devices, then grab names and phone numbers
- Copy files: documents, spreadsheets … anything that might be valuable information
- Like any good program, update its modules to the latest versions
Well, here we are, a thousand words into the article … and I believe I have your full and undivided attention. Which is perfect, as you are now familiar with the brave new world of Advanced Persistent Threats (APTs).
Carbanak (2015)
Everything you read above? Put it on steroids—in the hands of criminals hell bent on stealing hundreds of millions of dollars—and you’ve got Carbanak.
Carbanak’s initial attack vector? Spear phishing email, that APPEARED to be legitimate in-house communications, sent to employees at over a hundred major banks. With infected attachments, naturally.
First malware installed? Keylogger and screen capture modules.
Command and control servers? Absolutely, with people interpreting the incoming data and directing the attacks.
That scary bulleted list (above) of attack vectors? Check. Oh, and thanks to the march of progress, Carbanak can use a laptop’s camera to record video.
Patience? Plenty of it. The Carbanak Gang would study employee actions over months, to learn the specific procedures of each specific institution.
I know what you’re thinking: “Espionage is stealing information. You implied the Carbanak Gang is stealing actual money.” Indeed, I did imply that. And indeed, they did steal hundreds of millions of dollars from roughly fifty banks around the world. After patiently learning the detailed procedures of a target bank, the attack team:
- Created fraudulent debit cards, that were used to withdraw money
- Initiated wire transfers and e-payments to external shell accounts, from which the money was then withdrawn
- Programmed bank ATMs to dispense cash at pre-determined times and at pre-determined locations, where people were waiting for the machines to literally spit out money
Source: Kaspersky Labs
Some of this (wire transfers) sounds all-too James Bond, while other aspects seem so impossible as to border on comedy (ATMs spitting out cash). All of it is true. Tremendous kudos are in order to Kaspersky Labs, who have done the heavy lifting in terms of the deeply technical detective work. With that said, I am certain other “cyber special ops teams” such as Mandiant are involved … but they have not been mentioned, as their clients have them under the world’s strongest NDAs. None of the targeted banks have yet been named, as that would be very bad for business.
Kaspersky Labs (and the yet-to-be-mentioned cybersecurity companies) are working around the globe with banks, law enforcement agencies and computer emergency response teams. According to Kaspersky Labs, they “were asked not to share any details until it was safe to do so.” So while the entire Carbanak operation is still a very active investigation—and if there are ongoing attacks, they are not being discussed—one hopes that the news going public this week is a positive sign.
Addressing APTs
I know what you’re thinking (again): “Holy *%#@! Can anything stop these &@#*ing APTs?” Take a few deep breaths and remember what I wrote:
“Every bit of that technology exists today.”
Some of the technology has been around for ages; we’ve just chosen not to utilize it. The S/MIME standard, for example, provides strong cryptographic email authentication and optionally encryption; the functionality is most likely in your email client (Microsoft Outlook, Mac Mail, iOS Mail, Thunderbird) at this very moment. All you need is a signed digital certificate—which costs between FREE and $30 per year—and less than half an hour.
S/MIME all but eliminates email spoofing, though it does not prevent a compromised machine from sending you a legitimate email with an infected attachment. This is such low-hanging fruit that I will take the unusual step of my first-ever tutorial—walking you through S/MIME—in a future blog post.
Switching gears for a moment: much of what passes for computer security is a tradeoff between productivity and “security theater” in an IT sense. Some companies epoxy USB ports closed to eliminate that particular vector, but where does that leave your field employees when they are working with a customer? Many companies implement aggressive URL filtering on their corporate proxy servers to cut off access to online storage services (Box, Dropbox, Google Docs, Zocalo), but that becomes a complete mirage the moment a laptop makes a non-corporate network connection.
Tradeoffs aside, these “security theater” measures can only reduce the probability of infection, at the cost of user productivity. And an unproductive user will go to unusual and potentially risky lengths that may increase the probability of infection. As illustrated above by both Flame and Carbanak, a single point of infection—one laptop, operating on a home network, clicking on one malicious URL—is all it takes for an APT to open the gates of the corporate network. Please do not get the wrong idea: contemporary IT policies and measures are necessary; but no one should operate under any illusion that they are sufficient. Not even the most onerous degree of client protection can defend against the most determined adversary.
An entirely different approach is needed above and beyond contemporary IT policies and measures: a behavioral approach that swiftly identifies the ‘shape’ of an attack, quarantines the impacted resources, analyzes the threat and upon confirmation, stops the attack immediately and completely.
Here too, I know what you’re thinking: “Is this another one of your grand-unified security solution concepts?” Hell, I wish this was my idea; it is actually a genuine, available, proven set of products from a company called FireEye. (I have no connection to, nor monetary interest in FireEye; though clearly I do find the company exceedingly interesting.)
FireEye technology begins at the edge of the network with an exceptionally novel method of preventing malware from reaching clients. For example, all inbound email is scanned for attachments and suspicious URLs. Attachments are first checked against known-malware signatures, as in a conventional anti-virus engine. And as in a conventional anti-virus engine, this methodology would not defend against Flame (zero-day exploits) or Carbanak (known, but not patched exploits) from doing their mischief. Here is the extraordinarily clever bit that I really, REALLY wish I had thought of first: attachments are ‘opened’ in a secure virtual machine (VM) and the FireEye box ‘observes’ the results.
If the attachment is an EXE file, it is executed; a ZIP file is uncompressed; a DOCX file is opened in Word; URLs are opened in a browser … all inside a completely secure—and heavily instrumented—VM … and all inside the FireEye box before the email is delivered to the client. The key term here is “heavily instrumented”: the VM observes everything that happens when the attachment is opened and identifies malicious behavior patterns.
For example, modifying an operating system file—as did both the Flame and Carbanak spear phishing attacks—is obviously malware. Ditto buffer overflows—obviously malware (or a bug). It is a brilliant approach: thoroughly effective at catching even zero-day attacks, but not prone to many false positives. FireEye hint that they catch a multitude of less obvious, multifaceted behavior patterns; I suspect quite a bit of intellectual property and value-added differentiation is behind this particular curtain.
I implied earlier that I frown on epoxying USB ports, so to be fair, that attack vector would not be stopped by behavioral network analysis. Ditto opening aforementioned infected email at home, as the FireEye box would not be in the loop. Under either of these easy-to-imagine scenarios, the client would be infected by the APT (I’ll call this “Client Zero” below). Expanding on my earlier “necessary but not sufficient” declaration, it is completely impractical to prevent every attack vector in a corporate environment.
Accepting the fact that some clients will be infected, what steps can be taken to defend against an APT at the corporate level? Apply behavioral techniques on the corporate network. FireEye (and other companies) build sophisticated network analyzers that sniff/monitor traffic on the corporate network, looking for patterns of malicious behavior.
FireEye, for one, gathers a tremendous amount of state over the entire corporate network. In other words, their network analysis is not based on single events in isolation; they are looking at patterns of activity across the network and over time. Back to Client Zero: imagine it was on a home network when infected by Flame or Carbanak; the malware spends the first few days gathering keylogs and screen captures. It may even communicate with the C&C server from the home network. All of this is not good, but so far we have a nasty bit of malware that has not developed into an APT. The data on Client Zero may have been compromised, but the adversary has not been able to launch the APT proper.
At some point, Client Zero will be on the corporate network when it connects to the C&C server; that outbound data dump will be recorded by the FireEye box, as will the subsequent inbound payload. At some point, Client Zero will attempt to infect other machines: for example, mapping network topology. Taken in aggregate, these actions clearly have the ‘shape’ of an attack. The FireEye box takes immediate action to isolate Client Zero, intercedes on the inbound and outbound C&C traffic and, of course, alerts IT to the threat so they can physically remove the client from the network … and bash the machine into tiny bits (just kidding).
The greatest potential danger is the APT accessing corporate servers. This was the ultimate objective of both Flame and Carbanak; patience and prolonged intelligence gathering enabled them to compromise both file servers and databases, gaining access at the admin level. ‘Patience’ is the key, as vividly illustrated by Carbanak; bank procedures were studied and documented over the course of months of intelligence gathering. That pattern of activity could readily avoid detection—hell, at 50+ banks it did successfully avoid detection—by conventional event-driven network security measures. Integrated over time, however, the fingerprints of an APT would be far, FAR clearer; the ‘shape’ of the attack could be identified and stopped during the intelligence gathering phase.
Having failed to identify Carbanak during the very patient intelligence gathering phase, all bets were off when it came time for the actual stealing money phase of the operation:
“The attackers abused the aforementioned services by impersonating legitimate local users who had the permissions to perform the actions later reproduced by the cybercriminals.”
Kaspersky Labs, Carbanak APT report—16 February 2015
While Kaspersky Labs have documented the methods of the Carbanak attack, as mentioned earlier, NONE of the banks have been identified. We do not know what cyber defenses worked and did not work against this APT. I have read the remarkable, detailed and fascinating Carbanak APT report; I am rather knowledgeable on malware detection techniques, both conventional and behavioral. In case you have not already reached this conclusion, in the interest of full transparency, my Carbanak analysis is based on very well-educated conjecture.
If you consider my previous blog post as a modest set of recommendations, I hope that this more sobering piece serves as a full and proper call-to-arms. As stated by Kaspersky Labs at the top of this post, Carbanak “is likely the most sophisticated attack the world has seen to date.” It is likely that the Carbanak Gang learned from Flame to ‘advance’ APT state-of-the-art; it is likely that the next attack will build on top of Carbanak with an even greater level of sophistication. The next attack may not target your bank; it may target intellectual property inside your company. It is high time that we take full and appropriate measures to defend against these advanced persistent threats. From Silicon Valley.
6 thoughts on “Barbarians at—damn, make that INSIDE—the Gate”