On September 6, Symantec published details of the Dragonfly campaign, which targeted dozens of energy companies throughout 2017. This attack was effectively Dragonfly 2.0, an update to a campaign that began in 2014.
Moving beyond our 2014 analysis of Dragonfly, our current focus looks at the attack’s indicators to determine whether we can glean any further information regarding the source and possible motivations of those behind the campaign. The campaign targets energy companies around the world by leveraging spear-phishing emails that, once successful, allow the attackers to download Trojan software. The Trojans provide access to the victims’ systems and networks.
Going Beyond Energy
Although initial reports showed Dragonfly attacks targeting the energy sector, investigations by McAfee Labs and the Advanced Threat Research team uncovered related attacks targeting the pharmaceutical, financial, and accounting industries. Everything about this campaign points to a well-prepared assault that carefully considers each target, and conducts reconnaissance before taking any measures to exploit compromised targets.
We saw the group use several techniques to get a foothold in victims’ networks, including spear phishing, watering holes, and exploits of supply-chain technologies via previous campaigns. By compromising well-established software vulnerabilities and embedding within them “backdoor” malware, the victims think they are installing software from a trusted vendor, while unaware of the supply-side compromise.
Once the attackers have a foothold, they create or gain user accounts to operate stealthily. Using the remote-desktop protocol to hop among internal or external systems, they connect either to a control server if the risk is minimal or use an internal compromised server to conduct operations.
The last wave of attacks used several backdoors and utilities. In analyzing the samples, we compared these with McAfee’s threat intelligence knowledge base of attack artifacts.
One of the starting points was a Trojan in the 2017 campaign with the following hashes:
- MD5: da9d8c78efe0c6c8be70e6b857400fb1
- SHA-256: fc54d8afd2ce5cb6cc53c46783bf91d0dd19de604308d536827320826bc36ed9
Comparing this code, we discovered another sample from the group that was used in a July 2013 attack:
- MD5: 4bfdda1a5f21d56afdc2060b9ce5a170
- SHA-256: 07bd08b07de611b2940e886f453872aa8d9b01f9d3c61d872d6cfe8cde3b50d4
- Filename: fl.exe
The file was downloaded after a Java exploit executed on the victim’s machine, according to the 2013 attack report. After analyzing the 2013 sample, we noticed that some of the executable’s resources were in Russian.
Comparing the code, we find the 2017 sample has a large percentage of the same code as the backdoor used in the 2013 attacks. Further, some code in the 2017 backdoor is identical to code in the application TeamViewer, a legitimate remote administration tool used by many around the world. By incorporating the code and in-memory execution, the attackers avoid detection and leave no trace on disk.
The correlating hash we discovered that contained the same TeamViewer code was reported by Crysys, a Hungarian security company. In their report on about ‘“TeamSpy,” they mentioned the hash we correlated as well: 708ceccae2c27e32637fd29451aef4a5. This particular sample had the following compile date details: 2011:09:07 – 09:27:58+01:00
The TeamSpy attacks were originally aimed at political and human right activists living in the Commonwealth of Independent States (the former Soviet Union) and eastern European countries. Although the report attributes the attacks to a threat actor or actors and shared tactics and procedures, the motivations behind TeamSpy appear similar to those of the Dragonfly group. With identical code reuse, could the TeamSpy campaign be the work of Dragonfly?
But that’s not all of interest. We also discovered that the 2017 sample contained code blocks associated with another interesting malware family: BlackEnergy. Let’s look at an example of the code similarities we discovered:
A BlackEnergy sample from 2016 (at left) alongside a Dragonfly sample from 2017.
Self-deleting code is very common in malware, but it is usually implemented by creating a batch file and executing the batch instead of directly calling the delete command, as we see in the preceding examples.
The BlackEnergy sample used in our comparison was captured in the Ukraine on October 31, 2015, and was mentioned in our post on the evolution of the BlackEnergy Trojan. It is remarkable that this piece of code is almost identical in both samples, and suggests a correlation between the BlackEnergy and Dragonfly campaigns.
Our analysis of this attack tells a story about the actors’ capability and skills. Their attack precision is very good; they know whom and what to attack, using a variety of efforts. Their focus is on Windows systems and they use well-known practices to gather information and credentials. From our research, we have seen the evolution of the code in their backdoors and the reuse of code in their campaigns.
How well do the actors cover their tracks? We conclude they are fairly sophisticated in hiding details of their attacks, and in some cases in leaving details behind to either mislead or make a statement. We rate threat actors by scoring them in different categories; we have mentioned a few. The Dragonfly group is in the top echelon of targeting attackers; it is critical that those in the targeted sectors be aware of them.
The Dragonfly group is most likely after intellectual property or insights into the sector they target, with the ability to take offensive disruptive and destructive action, as was reported in the 2015 attack on the Ukrainian power grid by a BlackEnergy malware family.
We would like to thank the team at Intezer for their assistance and support during our research.
The post Operation Dragonfly Analysis Suggests Links to Earlier Attacks appeared first on McAfee Blogs.