At the end of March, we published a blog post and a whitepaper about a cyber-espionage campaign dubbed “Volatile Cedar.” This campaign has successfully penetrated targets world-wide, using a variety of attack techniques, in particular, a custom-made malware implant codenamed Explosive.
Let’s recap what we know:
- The Volatile Cedar operation has been active since 2012 and has evaded detection by the majority of AV products. Volatile Cedar constantly monitors its victims’ actions and rapidly responds to detection incidents.
- Explosive is a specially crafted Trojan type of malware, implanted in targets and used to harvest information. New and custom versions are developed, compiled and deployed for specific targets.
- The primary goal of the attackers appears to be data collection, not to cause harm to targets/use their resources or steal financial assets.
- Only a small number (hundreds as opposed to thousands) of targets have been identified to date. We would normally expect that a cyber-crime campaign targeting financial institutions would result in much higher numbers of victims. The limited number of targets may be part of an attempt to avoid unnecessary exposure.
- Identified targets are organizations in the fields of telecommunications, media, web hosting, academia, defense contractors and civil services.
All of these points indicate a highly crafted operation directed at specific and carefully selected targets.
Something Old, Something New
After going public with our findings, we were provided with a new configuration belonging to a newly discovered sample we have never seen before.
The sample itself is the same Explosive v3.0 implant, but it differs in the following aspects:
- A different DGA seed is used (flashplayergetadobe) to create new C2 servers. The only one we have noted so far is registered by the operators as “getadobeflashplayer[.]net”
- All of the victims of this thread are Saudi Arabia-based.
We want to present our attribution case with stronger evidence to back up our claims and provide a more detailed explanation.
There were many questions raised by our colleagues and customers as to how and why we came to the conclusion that this operation originated in Lebanon.
Through careful analysis of the operation, both previously known victims and C2 servers as well as targets infected with the sample containing the newly discovered configuration, we were able to create a heat map of the infections.
Looking at the target map of the operation we see the following:
Although there are infections all over the world, the highest concentration of infections is in the Middle East – specifically in Israel, Lebanon and Saudi Arabia.
So why do we still say that the group behind Volatile Cedar is Lebanese?
If we take a closer look at the targets, we see the distribution of the victims themselves based on industry vertical:
If we dig deeper and look into the distribution of the hacked websites on the hosting services, we notice the following two interesting facts:
- The victim sites on the compromised web services were primarily Middle Eastern web sites. This is true not only for the majority of the infections in Israel, Lebanon and Saudi Arabia, but all over the world as well.
- The majority of the victimized sites themselves belong to different companies that work with national and defense companies.
These observations about the victims allow us to assume that the operators behind this activity maintain high interest in the region and its politics.
Other indications we found about the operators:
The strings inside the binary code in Arabic:
The PE resources inside the malware files are in Lebanese Arabic
Some of the C2 servers are hosted in Lebanon (true for the first Explosive version).
Some of the domains used in the campaign were at some point registered to Lebanese addresses – a fact that was later changed by the operators.
A few words on the attackers’ modus operandi
Disclaimer: Any assumptions made or conclusions drawn are based solely on our analysis of data from a limited group of targeted systems. As our sample size is admittedly restricted, it is possible that the attackers may also exhibit other behaviors that we have not encountered to date.
In the cases in which we have analyzed victim data, we saw the following interesting information:
One site to rule them all
Looking at victim data from the hosting companies, we noticed that the compromise of a single website led to the compromise of almost all the sites hosted by this service.
One is enough
Previously, we described that a typical attack begins with a vulnerability scan followed by a web shell injection to the compromised site. Based on analyzed victim data, we found that only one of the compromised sites per hosting service contained a web shell. The rest of the sites were most likely accessed using stolen admin credentials.
When we reviewed the logs of different victims, we found that version upgrades were almost always automated and occurred within seconds of each other.
In such a highly targeted operation, you would expect the operators to try and cover their tracks as much as possible. However, they left hints about their identity at almost every step of the way (see our earlier case for attribution). In the midst of our investigation of the infected machines, we discovered old tools or old key logging data collected by the malware was not removed, thereby exposing the operation to greater possibilities of discovery.
Hide in plain “site”
Dealing with an operation of this scope, with such carefully chosen targets, we would have expected a higher quality of malware development. These days, even the simplest malwares are packed to avoid detection, do not contain useless functions and code, or use obfuscated strings – all things we have noted to be poorly executed in Explosive and the other tools used in this campaign.
Appendix – Indicators
Web shell hashes
Other tools hashes
Static and Dynamic C&C updater servers