NotPeyta: Why so dangerous?

Another week, another ransomware outbreak. On Tuesday, we saw another variant of ransomware spreading, worm-style, across unsecured networks within large organisations. As with the WannaCry outbreak in May, large global corporations have been affected, and infections have spread from their initially-compromised hosts across internal networks. NotPetya hasn't received as much press as WannaCry did, but from a security perspective it does, at the moment, look far more interesting.

We saw a very straightforward pattern of exploitation with WannaCry; the worm replicated itself across internal networks which had not been patched against the Microsoft MS17-010 vulnerability, encrypted files and demanded a ransom. This new outbreak, dubbed "NotPetya" by Kaspersky is different, more advanced and more dangerous. Security researchers are still analysing the outbreak, but initial reports suggest that this piece of ransomware is far more advanced in its operation.

How it was released

Reports (including from the Ukrainian Cyber Police) have emerged that in addition to traditional phishing emails containing malware-infected documents, the initial infection vector for the worm came from a compromised software update for the accountancy software package MeDoc (required for tax accounting in Ukraine) - something which the vendor has since denied on Facebook.

If this proves to be true when the dust has settled, it shows an advanced pattern of attack; the criminals in this case have compromised the update process for a piece of software widely used within their target population and used this to distribute their malware. Given the way in which software updates generally operate, it's likely that at some point those software updates would have been installed with administrative rights on the affected machines (rather than the standard user rights that would usually be gained by malware opened in a document from a phishing email).

What it does

Where WannaCry spread itself from organisation to organisation across the network, NotPetya remains contained within the internal networks it compromises. It does propagate internally, however, and the way in which it does this is quite interesting. In common with WannaCry, NotPetya does use a modified version of the NSA's EternalBlue SMB exploit to infect other systems. After WannaCry, however, most businesses have patched these vulnerabilities.

NotPetya uses other techniques to spread as well. Once NotPetya has local administrator access to a compromised system, it uses open-source tools such as Mimikatz to inspect the memory on the host.

The memory on a Windows system will generally contain user credentials that can be used to access other systems within the network if the host is part of an Active Directory domain, or passwords are shared between different systems. If a local system within an Active Directory domain has an active session with an Active Directory domain administrator user, an attacker with local administrative privileges will be able to read the system's memory contents and access these credentials. This is a consequence of the architecture which allows a Microsoft domain environment to have single sign-on capabilities, and is commonly used by attackers (and penetration testers!) to achieve privilege escalation within an Active Directory environment.

NotPetya is able to extract those credentials from memory and automate replaying them against other systems in the same internal network to spread across to neighbouring hosts and further the infection. This technique is often used by interactive attackers escalating their privileges across the network; seeing it paired with a ransomware worm in this way is new.

Why it was released

Although the execution of the worm seems to be more advanced than the WannaCry worm, motivations in the face of the NotPetya outbreak are unclear. Unlike many ransomware outbreaks, the payment and recovery infrastructure set up to support ransom payments and recovery of keys does not appear to be robust. The only email address associated with the outbreak has been shut down by the service provider; victims now have no way to contact the instigator of the attack and consequently no way for them to retrieve the keys which would allow them access to their data if the criminals were inclined to release these. As a money-making scheme, then, this has not been well thought out.

It's impossible to know the true motivators of the criminals behind this outbreak right now - we can only speculate. Were they targeting a particular organisation, and was everybody else collateral damage? Were they particularly bad at planning, and expected their payment route to remain open and make money out of the attack? Is the ransomware just a cover to provide plausible deniability for a differently-motivated attack? What seems clear is that for those businesses affected, the consequences of exploitation are likely to be widespread chaos, and there is no realistic prospect of data retrieval from encrypted systems at this time. Without proper backups, as with all ransomware attacks, there is little hope of recovery.

What can we learn?

There are common lessons that can be learned from every ransomware attack: Make sure your systems are fully patched at all times, and try to make sure your users are well-informed of the risks of phishing attacks. When your trusted software package update has been compromised, however, it's difficult to defend against this kind of attack and as a result you need to be prepared to respond and contain an infection.

  • We have said it before, and we will say it again: Without a proper backup regime, covering all critical systems, your business is susceptible to catastrophic damage from this kind of self-replicating attack. You also need to make sure that your backups are segregated from systems which could be compromised; online backups accessible by compromised users could also become encrypted, leaving you without recourse.
  • Adhere to the principle of least privilege. Make sure all users and processes you have operate with the fewest privileges necessary for them to be effective. Your systems administrators should not routinely use their administrative accounts for non-administrative tasks such as browsing the web or reading email, for example. Your normal users should not have administrative rights over their machines. If software updates do not require administrative rights, these processes should be run without those rights. This won't stop a compromise from occurring, but it will certainly help minimise the ease with which an infection can spread across your network.
  • Don't reuse passwords. It's still fairly common for us to see infrastructure environments where passwords are re-used across multiple systems. Maybe all servers share a common password for the local Administrator user. Maybe a standard password tends to be set by the helpdesk for new users. Maybe there are standard password patterns in use which everybody knows. Password reuse is extremely dangerous; compromising one set of credentials allows an attacker to access myriad resources and means that your ability to track accountability for actions is seriously hindered.

If you are operating an Active Directory domain, it is worth repeating that due to the way in which single sign-on systems generally work, once one host within the environment is compromised to a local administrative level, it is only a matter of time before the adversary will be able to gain access to the rest of the environment. Microsoft released a paper some time ago about mitigating credential-passing attacks; the first two mitigations surround restricting administrative domain credentials and restricting administrative local accounts. In defending your corporate environments, you have to be conscious of this and make sure that none of your domain-connected systems are neglected.