This week, for the first time, the FBI issued a Flash warning about a destructive wiper activity, used in the attack on Sony Pictures Entertainment. Samples of this Destover malware contained configuration files created on systems using Korean language packs.
Since the attack, further information about the malware has surfaced in one form or another, but some details, such as those relating to the previous activity of the prime suspects, are still to be examined.
So, while Sony Pictures silently completes its costly clean-up efforts and prepares to release "The Interview", let's discuss some of the malware functionality, glaring similarities with other wiper events, and some of the suspect group's previous activity.
The first thing to note is that destructive activity targeting the networks of large organizations is clearly becoming more commonplace. Previous major wiper malware is discussed here. For these, most of the related events occurred in the Middle East and the Korean Peninsula. We also noted a separate Eastern European BE2 ICS environment-related wiping event, covered in more detail here. And it's hard to ignore the complete customer data wipe of Code Spaces in Great Britain by a cybercriminal holding them for ransom, as reported here.
The malware involved in the Sony Entertainment attack is called Trojan Destover and is capable of wiping disk drives and MBR.Destover Wiper Functionality
The most interesting aspects of the destructive functionality of the malware are related to the selection and storage/delivery of the drivers that are now used repeatedly in these kinds of sabotage attacks.
The Destover droppers install and run EldoS RawDisk drivers to evade NTFS security permissions and overwrite disk data and the MBR itself. There are implications for data recovery in this. In the case of the DarkSeoul malware, the overwritten data could be restored using a method similar to the restoration of the Shamoon 'destroyed' data. Destover data recovery is likely to be the same.
The chain of intermediary components leading to the destructive payload follows multiple stages (which have previously been described elsewhere), with capabilities set to run in several modes, just like Shamoon:
- The sample is run on a 32-bit OS for the first time.
- The sample is run on a 32-bit OS as a self-installed service, with one of several code paths.
- The sample is run on a 64-bit OS as a self-installed service.
On a first run, it creates the 'Backup and Restore Management' Windows brmgmtsvc service, adds its own executable and sets a startup '-i' switch. It also drops several copies of itself and starts each of them with a different switch: -m, -d, and -w.
-m (mbr overwrite):
This attempts to connect with the three IP addresses. Even if this is unsuccessful, process execution takes place.
It fetches its resource that contains the compressed EldoS RawDisk driver, and writes it out to the temp directory as a 'usbdrv3.sys'.
It then installs the driver as the usbdrv3 service 'USB 3.0 Host Controller'.
After this, it starts the driver service and closes its service handle.
It then creates a filehandle to the driver with write permissions:
and writes to that handle with 64k strings of '0xAAAAAAAA'. ← note that the issue of a lengthy license key (#99E2428…) is discussed in our Shamoon The Wiper - part ii blogpost.
It then creates new threads, each of which attempts to connect to any possible physical drive letter and overwrite them as well.
-d (data overwrite):
This attempts to connect with the same three IP addresses. Again, process execution takes place regardless of communications.
It gets the logical drives and traverses recursively through them, identifying all data files. If it is not .exe or .dll, the process overwrites file contents with '0x0df0adba' in a 20k chunk. This overwrite is completed from user mode, without the EldoS drivers.
It then attempts to delete the data file using the win32 api 'DeleteFileW'. As it recurses through all the system's directories, it attempts to delete .exe and .dll files.
-w (web server):
This attempts to connect with the same three IP addresses. Again, process execution takes place regardless of communications.
It stops the Windows Terminal Services from the cmd line: 'cmd.exe /c net stop termservice /y'
Then finds resource#85, decompresses and writes contents out to 'c:\windows\iissvr.exe'.
It launches the iissvr.exe process and exits.
iissvr is what it seems to be - a web server that maintains an encoded JPG, HTML and WAV file. It listens on Port 80 and serves these files. The full graphic and scrolling green warning can be found later in the article. The decoded jpg here:
Lastly, after a two hour sleep, the original service restarts the machine with a call to ExitWindowsEx(EWX_REBOOT|EWX_FORCE, 0). This forces an exit but delays the shutdown itself while system state file creation occurs.Commonalities Across Wipers
Just like Shamoon, the Destover wiper drivers are commercially available EldoS RawDisk driver files.
Just like Shamoon, the Destover wiper drivers are maintained in the droppers' resource section.
Just like Shamoon, the DarkSeoul wiper event included vague, encoded psuedo-political messages used to overwrite disk data and the master boot record (MBR).
Just like DarkSeoul, the Destover wiper executables were compiled somewhere between 48 hours prior to the attack and the actual day of attack. It is highly unlikely that the attackers spear-phished their way into large numbers of users, and highly likely that they had gained unfettered access to the entire network prior to the attack.
The Shamoon components were compiled in a similarly tight timeframe prior to their deployment. The CompiledOn timestamps all fall within five days of their executables' detonation. Nearly all were compiled on Aug 10, 2012 (between 00:17:23 and 02:46:22) and set to detonate on Aug 15, 2012. That is a tight window to quietly deploy these binaries considering the fact that tens of thousands of machines were destroyed with this payload.
In all three cases: Shamoon, DarkSeoul and Destover, the groups claiming credit for their destructive impact across entire large networks had no history or real identity of their own. All attempted to disappear following their act, did not make clear statements but did make bizarre and roundabout accusations of criminal conduct, and instigated their destructive acts immediately after a politically-charged event that was suggested as having been at the heart of the matter.
Images from the DarkSeoul 'Whois' and Destover 'GOP' groups included a 'Hacked by' claim, accompanied by a "warning" and threats regarding stolen data. Both threatened that this was only the beginning and that the group will be back. It appears that original skeletal artwork was also included in both.
Whois team graphics and warning:
GOP team graphics and warning:
Differences between the Destover and DarkSeoul Wiper attacks include Destover's lack of *nix scripts to erase partitions across Linux systems.
The above list of commonalities does not, of course, prove that the crew behind Shamoon is the same as the crew behind both DarkSeoul and Destover. But it should be noted that the reactionary events and the groups' operational and toolset characteristics all carry marked similarities. And, it is extraordinary that such unusual and focused acts of large scale cyber-destruction are being carried out with clearly recognizable similarities.Network activity
Related beacon destinations were published as:
However, directly related samples perform callbacks to a number of other IP addresses as well. Kaspersky Security Network (KSN) data presents a complete lack of malware being served from any of these addresses in the past:
The connections appear arbitrary and inconsequential to the execution of the malicious package. Some are not currently active. These IPs all appear to be oddly selected.
Some of these addresses are known to have performed RDP Scans in the recent past. In late 2012, 126.96.36.199 was a known RDP brute forcing network scanner. The server is hosted at an IP address in Poland, maintained at that provider since 1996.
In early 2014, 188.8.131.52 was hosted in Italy and served as a 'Hide My Ass' premium and free proxy server over port 443. The malware attempts to connect to that server on ports 8000 and 8080, and currently no resources are available.
184.108.40.206 also previously served as a free SOCKS proxy in 2011 and 2012. Often, these sorts of resources were misused by spammers and blackhat SEO scammers.Previous Backdoors
The DarkSeoul campaigns have been linked to several families of Trojans and backdoors, all used over the course of several years. Some links are much stronger than others:
- Concealment Troy
Trojans:MD5 Size CompiledOn Kaspersky name d1c27ee7ce18675974edf42d4eea25c6 262 kb 2014.11.22 00:06:54 Trojan.Win32.Destover.a 2618dd3e5c59ca851f03df12c0cab3b8 430 kb 2014.11.22 00:05:02 Trojan.Win32.Destover.d 760c35a80d758f032d02cf4db12d3e55 244 kb 2014.11.22 04:11:08 Trojan.Win32.Destover.c b80aa583591eaf758fd95ab4ea7afe39 304 kb 2014.11.24 04:12:55 Trojan.Win32.Destover.b e1864a55d5ccb76af4bf7a0ae16279ba 112 kb 2014.11.13 02:05:35 Backdoor.Win32.DestoverServ.a a3fa8c7eb4f061ab8b9f7829c6741593 111 kb 2014.05.03 07:10:22 Trojan.Win32.Destover.f 2c545b89acdb9877da5cbb96653b1491 53 kb 2014.07.14 13:38:18 Trojan.Win32.Destover.e e904bf93403c0fb08b9683a9e858c73e 90 kb 2014.07.07 08:01:09 Trojan.Win32.Destover.d
6aeac618e29980b69721158044c2e544 (32-bit), signed by the EldoS Corporation
86e212b7fc20fc406c692400294073ff (64-bit), signed by the EldoS Corporation
Certificate (6aeac618e29980b69721158044c2e544 32-bit and
- Exclusive: FBI warns of 'destructive' malware in wake of Sony attack
- Dissecting Operation Troy: Cyberespionage in South Korea, McAfee, 2013 (PDF)
- Darkseoul/Jokra Analysis And Recovery, Fidelis Cybersecurity, 2013 (PDF)
- Analyzing Unknown Malware
- DarkSeoul - Jokra - MBR wiper samples
- Shamoon The Wiper: Further Details (Part II)
Following the release of our report on the Regin nation-state cyber operation, questions were raised about whether anti-malware companies deliberately withheld information -- and detections -- at the request of governments and customers. A similar question was raised by Bruce Schneier in 2013.
Let's get the most important issue out of the way immediately. We have never been asked by a customer or a government entity to whitelist or stop detecting any specific malware sample. We'd never comply with such a request, no matter the source.
This simply does not happen. In some cases, investigations into advanced targeted attacks include NDAs (non-disclosure agreements) with customers and we are bound to maintain confidentiality but that never affects adding detection and protecting our entire customer base from threats.
So, why did it take two years for us to release a report on Regin? Without proper context, it may appear that researchers kept something really important in the dark for an inordinately long time. However, security research -- not unlike law enforcement investigations -- requires meticulous scrutiny and analysis and in many cases, it's important to watch the crime unfold in real-time to build a proper case.
In our case, without unlimited resources and the fact that we're tracking multiple APT actors simultaneously (Careto/Mask, EpicTurla, Darkhotel, Miniduke/Cosmicduke, to name a few), this becomes a process that takes months, even years, to gain a full understanding of a cyber-operation.
Sean Sullivan from F-Secure provided a perfect description of APT research, comparing it to the work of paleontologists that find some bones of a dinosaur. Everyone may have a bone but nobody has the full skeleton.
In the case of Regin, what we first discovered in 2012 was a slightly damaged bone from unknown part of a monster living in a mysterious mountain lake.
(courtesy of southampton.ac.uk)
Someone finding a bone might discard it and keep traveling, but in security research we collect things. The original discovery went to our collection of things stored in the backyard. We have many of these fractured bones from unseen monsters or maybe harmless creatures. Sometimes we hear about other bone fragments being discovered by others and this pushes us to take a closer look but at the early stages, without enough evidence to draw meaningful conclusions, it doesn't make sense to go public about discoveries until you confirm that the monsters are real, big and dangerous.
We keep working in various channels to collect different artifacts that may or may not match some of the pieces in our collection. Sometimes we join efforts with other "paleontologists" and share our discoveries. Once we collect enough of bones from a monster to understand potential size, danger and possible habitat, we can start the next phase which is a real active investigation that might lead us to the mysterious mountain lake.
A comprehensive APT research project consists of several stages:
- Adding detection for known modules
- Collecting samples
- Reversing the samples
- Decrypting sophisticated encryption and compression schemes
- Understanding lateral movement
- Outlining multiple attack stages in the correct order
- Mapping C&C infrastructure
- Setting up sinkholes
- Analyzing collected traffic and communication protocols
- Crawling other hosts that understand the same protocol
- Taking down and acquiring images of C&C servers
- Identifying victims, sending out notifications to victims and global CERTs
- Applying forensic analysis and extracting logs, stolen files, other components
- Collecting and analyzing data from KSN, C&C servers, individual victims who are willing to work with us, sinkholes, crawlers, etc.
- Writing a comprehensive report
If we are lucky we can find a monster in-the-wild that is the best source for scientific study. In most cases, including Regin, we observe and learn from the behavior of a live monster. We record every single step and intention.
At the same time, we can take it down and study it in a lab like zoologists. However, in many research investigations, we can see only a skeleton of a monster. We have to put everything together and reconstruct how the monster moved, what was it habits, what species it attacked, and how these attacks were coordinated. Simply put, this requires time and patience.
In addition, when we analyze the characteristics of a certain creature, we understand that the evolution goes on and there are other species like the subject, live and kicking somewhere in a manner that's not visible at all.
While some of the Regin samples got on our radar early and we continued to find additional samples and artifacts during the research, we are convinced there are others that are currently unknown and undiscovered. Little was known about their life and existence in the past but we know they were out there by finding some tiny fragments over time. And we have to refer to paleontology again, because in the overall picture we have discovered just a small part of the entire beast, but have enough to to release a public alert.
Like Regin, sometimes we find that we had been detecting pieces of malware for several years before realizing that it was a part of global cyber-espionage campaign. One good example is the story of RedOctober. We had been detecting components of RedOctober long before we figured out that it was being used in targeted attacks against diplomatic, governmental and scientific research organizations.
At Kaspersky Lab, we are processing hundreds of thousands of samples every day. The art of figuring out which ones are significant and further yet which ones belong together as part of a big APT attack is akin to finding needles in a huge haystack and then figuring out which ones belong to the same knitting set. We are grateful for every needle we discover, because this makes the world a little safer.