All this EternalPetya stuff makes me WannaCry
Credit to Author: Adam McNeil| Date: Thu, 06 Jul 2017 18:15:09 +0000
Another week goes by and yet again we have another ransomware family spreading via the reported NSA toolkit that was published months ago by the notorious hacking group that goes by the name ShadowBrokers.
Security researchers can’t seem to catch a break when it comes to holidays and significant malware variants being unleashed to the wild. While many of us may have been enjoying the nice summer holiday or celebrating American Independence Day by blowing up small pieces of it, @hasherezade was hard at work deconstructing this particular piece of code and filling us in on the technical details and discoveries as they were being made.
We’ll take what we know and what we’ve learned and try to summarize the mind-boggling technical information into a simple structure that even my dear mother will be able to understand (love you, Mom!).
So What Happened?
Sometime prior to June 27th, Ukrainian software company M.E.Doc was reportedly infiltrated by an unknown group of hackers. The attackers managed to remain undetected within the company network for an (as of yet) unknown period of time and were able to leverage a number of resources to eventually grant themselves access to the source code and update mechanisms of the widely used M.E.Doc software.
M.E.Doc makes and distributes accounting software that is targeted primarily towards Ukrainian residents and business entities, as well as a few others outside of the national boundaries. There are reports that this software is government mandated within Ukraine, although we can find no factual reference for this claim. Regardless, the software is used by a significant percentage of the Ukrainian population and a number of organizations outside of Ukraine.
Using the systemwide access afforded with the previous breach of the M.E.Doc system, the attackers were able to spend some time to understand the network infrastructure and to become familiar with the M.E.Doc sourcecode.
On June 27th, the attackers used the software update mechanisms of the M.E.Doc software to distribute a newly compiled version of the popular accounting software that contained malicious code which infected systems with a ransomware variant. Any system configured to automatically perform updates would have been infected without any user interaction required.
Once infection occurs, the code is configured to use the same EternalBlue and DoublePulsar modules that were used in the WannaCry incident to spread to other vulnerable systems on the network. This allows the malicious code to infect not only machines utilizing the M.E.Doc software but also any other machine on the network.
In addition to EternalBlue and DoublePulsar, 3rd party researchers uncovered the use of an additional NSA derived exploit, EternalRomance, being used to infect any machine that connects to the affected network. This particular exploit uses two built-in Windows administrative tools, called PSExec and WMI, to help execute malware on remote connections. In essence, this allows the malware to infect all machines that it can – which would include any home machine connected to the enterprise server via VPN.
After susceptible machines have been infected with the ransomware, the Master File Table (MFT) and the Master Boot Record (MBR) of the computer are encrypted and the MBR is overwritten to display the ransom note.
Both the Master File Table and the Master Boot Record are used to provide instructions to the PC on what to do after the power button is pressed and where important files are located on disk. Without proper configuration of both of these files, computer systems can’t boot properly and thus will fail to do so.
Why the strange name for the malware?
As researchers began understanding the code, all sorts of various names were thrown out as a means to name the malware family. NotPetya, Expetr, EternalPetya, and even simply Petya have all been used to describe the malware. It seems strange that so many researchers came up with a similar naming convention, but here is where this particular infection gets interesting.
This specific methodology of infection is synonymous with the Petya ransomware family. Furthermore, the language of the ransom note, plus information within the decompiled malware code led researchers to initially suspect the same malware author had been responsible for both variants. But as researchers further dissected the code, a few key differences began to emerge.
First, Petya differed from EternalPetya in the fact that the newly discovered code was utilizing the NSA derived EternalBlue, DoublePulsar, and EternalRomance modules to spread to connected machines on the network. This would have been a new evolution in the propagation methodology of the original Petya.
Second, the malware appeared to be an edited version of the Petya ransomware rather than a newly compiled version. @hasherezade did a terrific job of breaking this all down in the post titled EternalPetya Yet Another Stolen Piece in the package.
In the post, @hasherezade explains that the original Petya ransomware code has been craftily modified, rather than complied from scratch, to allow reuse of previous malware code. This has a number of advantages for the new author such as a decreased workload in writing ransomware from the ground up and helping to misdirect attribution by (among other things) excluding possible language clues that we have seen with other strains.
Third, the self-proclaimed author of the original Petya ransomware family, @JanusSecretary, posted to a dormant Twitter account claiming “we’re back havin a look in “notpetya” maybe it’s crackable with our privkey”
This, along with the information that the original malware had been edited rather than compiled, leads to the conclusion that Janus was not likely involved with the dissemination of the code, but rather merely a scapegoat for the EternalPetya authors.
If not @JanusSecurity, who can we blame?
As is typical with these sorts of malicious malware strains, attribution can be difficult if not impossible. Malware authors take significant steps to cover their tracks and utilize a number of anonymizing services to hide their origin, intent, and methodologies.
TOR, proxies, and VPN’s are used to conceal identifying connection information. Bitcoin and other digital currencies are used to conceal payment information. Cryptocurrency tumblers are used to mix up digital currency transactions thus confusing the trail back to the original source. And in at least this case, a well-known ransomware family was ripped off as a means to confuse the original author.
While we can’t fully rule out involvement in EternalPetya by @JanusSecretary, the information indicates this probably not to be the case. There would have been no need to go through the trouble of modifying the original malware variant when a new variant could more easily be compiled with the new information.
So who else could it have been?
It’s all the rage these days to blame Russia for any and everything related to malicious activity and the Ukrainian government wasted no time in doing so.
On July 1st, the Ukraine State Security Service, SBU, claimed that the same hackers who attacked its power grid in December 2016 were also responsible for the EternalPetya outbreak. The Ukrainian government was quick to blame Russia for the EternalPetya attack, but a spokesman for the Kremlin dismissed the claims as “unfounded blanket accusations”. The Russian government also pointed out that its own companies were impacted by the attack including Russia’s state-owned oil company, Rosneft, and Russian steel maker, Evraz.
Indeed, we have found no indications that EternalPetya was a Russian, or state-sponsored attack and we have seen no Indicators of Compromise (IOC’s) to indicate otherwise.
Rather, the most plausible explanation is that a group of sophisticated attackers managed to gain access to a widely used software company and used that access to distribute a modified version of a known ransomware variant as a means to extort payments from infected users.
While this is little more than speculation at this point, all indicators point to this being the most plausible explanation.
unoptimized code is an indicator of re-use
Can the encrypted files be retrieved?
In short, it’s probably not likely. As with the WannaCry outbreak, the authors of this malware variant made some critical mistakes in the payment and decryption methodologies. As @hasherezade points out in the post titled EternalPetya and the lost Salsa20 key, ‘after being read and used for the encrypting algorithm, the stored Salsa key is erased from the disk’.
In previous Petya versions, the Salsa key, basically the key that can lock or unlock the contents, was encrypted with the attackers public key and converted to a hashed string. This meant that although the Salsa key is erased from disk as we’ve seen with EternalPetya, the key was still available to the attackers who had the private key to decrypt it.
In essence, the authors of the EternalPetya variant erased the key that was vital in decrypting the files, thus leaving the decryption of files highly unlikely.
This flaw with the decryption key is what caused the initial contradiction of this particular malware variant in being called a ‘wiper’ vs ‘ransomware’. Regardless of the designation, victims are paying a ransom with the hopes of obtaining their files. There is no guarantee that payment will successfully restore files and those who pay always gamble with this risk. This is by very definition the behavior of ransomware.
In addition to that, the email address that the attackers configured the malicious code to display has since been terminated by the email provider. This leaves no ability for infected users to contact the attackers and arrange for the decryption of files.
So unless a future decryptor emerges that utilizes a masterkey or a flaw in the encryption routine, it remains unlikely that infected users have a means to restore their files.
So Then, What’s Next?
On July 3rd, the head of Ukraine’s Cyber Police suggested that M.E.Doc is under investigation and will potentially face charges related to the incident. As reported by APNews: Col. Serhiy Demydiuk, the head of Ukraine’s National Cyber Police unit, said in an interview with The Associated Press that Kiev-based M.E. Doc’s employees had blown off repeated warnings about the security of their information technology infrastructure.
“They knew about it,” he told the AP. “They were told many times by various anti-virus firms. … For this neglect, the people in this case will face criminal responsibility.”
On July 4th, Ukrainian federal police seized several computer servers used by M.E.Doc. Video quickly appeared online reportedly showing the Ukrainian federal police storming the M.E.Doc facility and establishing control over the property. While I admittedly don’t speak Ukrainian, and for all I know these guys could be talking about rescuing kittens, I believe this video to accurately depict the raid on the M.E.Doc facility.
Additionally, as of this writing, the M.E.Doc website is offline as are the other domains listed as using the same IP. For all intents and purposes, at least for the time being, M.E.Doc may be done operating as a software entity.
It would be important to note that current M.E.Doc users shouldn’t use or upgrade the software until further notice, but with the developments surrounding the confiscation of the M.E.Doc servers, I’m not sure users should be holding their breath in anticipation.
What Did We Learn?
Apparently we learned little from the WannaCry outbreaks of months past. While the crafty infection of the M.E.Doc servers indeed provided a unique distribution method, the successful use of the NSA derived exploits leaves little excuse for the infection of network connected machines.
It begins to get difficult to have sympathy for apathetic I.T. admins who have failed to apply available updates to address the vulnerabilities targeted within the EternalBlue, DoublePulsar, and EternalRomance exploits. These issues have been thoroughly discussed and have garnered worldwide attention.
Mitigation techniques exist for all of the exploit-driven distribution methodologies and include everything from applying Microsoft updates to manually disabling SMB functionality.
We could recommend to these I.T. admins that had they been equipped with Malwarebytes Endpoint Protection, which includes anti-exploit and anti-ransomware technologies, they would have protected their users from this sort of attack – but honestly, I’m not sure they would listen even if we did.
So instead, we’ll focus our message towards the loyal readers of this blog and to people like my dear mother who need understand that malicious attacks can come from any avenue and at any time. Never under estimate the security of the data on your machine, as you may wake up one morning to find all of your most valuable documents either held ransom or worse, completely unrecoverable no matter how much money is paid.
Ensure that valuable documents are routinely backed up and saved to offline or cloud storage solutions. And ensure that you use a reliable and technically advanced security product such as Malwarebytes to help protect your sensitive information and ensure you don’t fall victim to this sort of devastating attack.
While it may not be the most ideal solution, a strong defensive strategy is best in the current age of highly evolving and sophisticated malware that is capable of destroying all of your most important files in a matter of seconds.
The post All this EternalPetya stuff makes me WannaCry appeared first on Malwarebytes Labs.