During a meeting last week in Belgium with Koen Van Impe, a security analyst with federal cyber emergency team, CERT.be, he recommended I look at a report involving a cyber espionage case involving the firm RUAG. “From a tech point-of-view… the persistence (and patience) of the attacker to get and maintain access and do lateral movement is an interesting read,” said Van Impe.
Two years ago, CERT.be security analysts discovered an Advanced Persistent Threat (APT) at RUAG rm, a Swiss government-owned defense technology company. For over a year, the analysts detected and cracked the layers of software, encryption, and reconnaissance techniques used by the attackers.
The cat and mouse game of cyber espionage and counterespionage came to an end in March 2016 when several reports appeared in the press about the incident. The leaked reports brought enough exposure to end the investigation (and, presumably, the infiltration) at RUAG.
Once the cat was out of the bag, the Federal Council of the Swiss Confederation released a detailed analysis of the cyber espionage at RUAG. The report makes for informative and, dare I say, exciting reading. The report’s prescription for recommended security practices and countermeasures is as good as any I’ve seen. I’ll touch on a few of their key recommendations in a bit.
APT Infection and Signaling Architecture
The attackers were using variants of the Turla malware family. Specific malware elements came from the Carbon, Snake, and Tavdig (also called Epic) malware projects. These initially included 32-bit and 64-bit kernel-level rootkits for Windows. When RUAG upgraded to versions of Windows that required signed kernel drivers, the attackers switched to userland process nodes instead, which gave them a benefit for a much larger encrypted virtual file system. These changes took place over months, showing the persistence and patience of the attackers.
The initial infiltration vector is unknown, as the RUAG logs only go back two years. However, the analysts were able to map a three-stage infection process that included tricks like JavaScript injectors designed as Google Analytics scripts.
The attackers moved laterally throughout the RUAG network via credentials that collected from a cornucopia of tools that included mimikatz and ShareEnum.exe. Ultimately they created a three-tier malware node architecture. A small, selected group of nodes near the firewall were designated as the communication proxies and did little more than pass information and workload tasks into the network and results back out. These proxies help prevent the other nodes evade the detection that would occur if they had to signal out to external command-and-control servers individually.
In total, the APT threat actor exfiltrated 23Gb of data (including signaling) over the nearly two-year period they were tracked.
So, who did it?
The security analysts decline to attribute the APT to a particular actor, other than to say:
“The [RUAG] cyber attack is related to a long-running campaign of the threat actor around Epic/Turla/Tavdig. The actor has not only infiltrated many governmental organizations in Europe, but also commercial companies in the private sector in the past decade. “
There are many in the security community who hold to the philosophy that attribution doesn’t matter. Regarding the proof of attribution, the reports says:
“First, it is nearly impossible to find enough proof for such claims. Secondly, we think it is not that important, because—unfortunately—many actors use malware and network intrusions for reaching their intentions. To our belief, nothing justifies such actions, and we support taking steps to ban such attacks instead of accepting them as inevitable.”
Those in the security community who hold to the tenet of non-attribution stress that information-sharing, specifically around the methods and taxonomy of APT, is crucial in raising the stakes to threat actors, and forcing them to choose their targets more selectively.
Recommendations and Countermeasures for APT
The report delivers five pages of security posture recommendations and countermeasures against APTs, divided into categories. Readers are encouraged to view the original report for the full list, but here’s a sample of them:
• Network Level: All Internet access must pass through a proxy that logs all headers and cookies for every single outbound connection.
• System Level: Consider using Microsoft AppLocker, which allows an administrator to lock down binaries and paths based on group policy. Linux has a similar technology: SELinux profiles.
• Microsoft Active Directory: Discourage the use of LM/NTLM hashes (of course). But also, Microsoft Premiere customers should do regular A
D RAPs.
• DNS Level: Don’t let clients resolve their own addresses; force them to go through the organization’s proxy. Use Response Policy Zones (RPZ) and PassiveDNS wherever appropriate.
• Instrumentation: Log information for the long term (2+ years). Don’t just accept default log settings, and log user-agent.
I highly recommend a lunchtime reading of the report, even for administrators that would not consider their organizations probable targets of an APT attack. Consider the report not just as the after-action analysis of a specific event, but as representative of advanced cyber attack patterns. Many of the countermeasures recommended by the report are not cost-intensive, and the recommendations around security processes can be applied to any organization large enough to have an incident response team.
Related: Attack on Swiss Defense Firm Linked to Turla Cyberspies
