Talos Elaborates on Nyetya’s Connection to Ukranian Software MeDoc
On June 27 an attack that was originally described as ransomware hit multiple companies in Ukraine and spread globally. A “motivated attacker” used a software exploit to deliver arbitrary code to victim endpoints. The attack then encrypted critical files while providing no way of decrypting them, which would normally be the case with a common ransomware attack.
Cisco’s Talos threat intelligence group has dubbed the malware Nyetya. Other firms and news articles have referred to the attack as ExPetr, NotPetya and others for its similarities to the Petya ransomware variant. It’s clear because of the attack methods that the malware’s goal is not to make money, but is rather looks to deny access to files through encryption. For this reason, most are calling the malware a wiper, and not ransomware.
Security intelligence partners enlisted the help of the Talos threat intelligence team as it was apparent the attack was spreading quickly, at least at first. The Ukranian Cyberpolice confirmed there were 2,000 cases in Ukraine alone, and other threat intelligence agencies reported up to 12,000 infections worldwide. It’s unclear how many total infections have occurred since the initial event.
From the early stages of their investigation, researchers at Talos wrote in a blog, it appeared this attack was both destructive in nature, and not strictly limited to agencies tied to Ukraine.
Talos researchers also discovered a clear tie to M.E.Doc, which is a popular accounting software program in the Ukraine.
By observing logs from a compromised webserver, Talos researchers discovered an unknown actor had stolen administrator credentials from an employee at M.E.Doc and used them to obtain root privileges and modify an NGINX server configuration file.
The modification changed the server “so that any traffic to upd.me-doc.com.ua would be proxied through the update server and to a host in the OVH IP space with an IP of 184.108.40.206.”
From there the threat actor proxied traffic to the server hosted by OVH for several hours, and within 10 hours had restored the original NGINX configuration and wiped the OVH server.
As for what comes next, Talos says it is pretty certain the actor “burned a significant capability of the attack” to prevent being identified. But that does not mean the attack is over.
“This is a significant loss in operational capability,” the researchers wrote. “And the Threat Intelligence and Interdiction team assesses with moderate confidence that it is unlikely that they would have expended this capability without confidence that they now have or can easily obtain similar capability in target networks of highest priority to the threat actor.”
To read the rest of the events leading to this attack and the in-depth technical analysis, see the post from Talos here.Tags: