Windows 10 platform resilience against the Petya ransomware attack

The trend towards increasingly sophisticated malware behavior, highlighted by the use of exploits and other attack vectors, makes older platforms so much more susceptible to ransomware attacks. From June to November 2017, Windows 7 devices were 3.4 times more likely to encounter ransomware compared to Windows 10 devices.

The Petya ransomware attack on June 27, 2017 (which we analyzed in-depth in this blog) may have been perceived as an outbreak worse than last month’s WannaCrypt (also known as WannaCry) attack. After all, it uses the same SMB exploit used by WannaCrypt and adds a second exploit and other lateral movement methods. However, our telemetry shows a less widespread attack:

The new Petya variant is highly sophisticated malware, but our telemetry shows it had far less reach than we expected given its worm-like spreading capabilities

The attack started in Ukraine; when the dust settled, more than 70% of the machines that encountered Petya were in Ukraine

It managed to spread to machines in other countries but in significantly lower volumes

The majority of infections were observed in Windows 7 machines

In this follow-up blog entry, we’ll discuss platform protection and mitigation in Windows 10 and Windows 10 S. The security configuration and reduced attack surface of Windows 10 S block this attack by default. As we previously discussed in a white paper, Windows 10 Creators Update has next-gen security technologies that help defend against ransomware attacks.

We will also present new findings from our continued investigation, specifically into the boot sector modification behavior of the ransomware.

Windows 10 protection and mitigation

The new Petya ransomware combines multiple well-known techniques for propagation and infection that are not new to security researchers. The noteworthy aspect is that Petya’s developer(s) took techniques normally used by penetration testers and hackers, and built a sophisticated multi-threaded automation of these techniques inside a single piece of code.

Such attacker techniques are part of the modern threat landscape and are continuously researched by security teams at Microsoft. Resulting new mitigations, hardening or defensive measures are then integrated into our products and operating systems.

Windows 10 follows this philosophy of continuous mitigation improvements. From our analysis of Petya, we were able to measure the defenses provided by Windows 10. Summarized in the diagram below are how mitigations and security features can help disrupt the different stages of this attack.

Petya’s kill-chain diagram with platform defenses able to mitigate or prevent certain techniques in Windows 10

Each mitigation in this diagram is placed on top of the specific malware techniques, which are either fully prevented or mitigated in Windows 10. For an overview and specific details of these mitigations included in Windows 10, see this page. Technical details of how each mitigation can help to block Petya’s techniques are listed below:

Device Guard can enforce strong code integrity policies to allow only trusted signed apps to run. It can thus block the entry vector of Petya (an updater running an untrusted binary) and also the further propagation attempts executing an untrusted DLL, either through PSEXEC or WMI.

Credential Guard uses virtualization-based security to isolate the LSASS process, so it fully protects from the credential dump executed by Petya using the external Mimikatz-like tool. It also protects the domain credentials stored in the Windows Credential Store. Access tokens exposed in memory can still be leveraged by Petya, but this is a less effective propagation mechanism, and it relies on third-party tools and other processes active in memory while Petya executes.

Several exploit mitigations such as better KASLR (randomization of kernel), NX HAL and PAGE POOL (non-executable kernel regions) are included by default in Windows 10 Anniversary and Creators Update, and they help mitigate SMB exploits like EternalBlue and EternalRomance. More mitigations like KCFG (control-flow guard for kernel) and HVCI (kernel code-integrity) are automatically enabled with Device Guard to provide additional resistance also to new exploits. Previousblogs discuss in detail how such mitigations were able to help mitigating unknown zero-day exploits, not effective against Windows 10.

UEFI Secure Boot is the security standard that uses hardware features to protect boot process and firmware against tampering. This protection will stop the dangerous disk encryption executed by Petya with a bootloader. After Petya’s forced reboot, a machine with Secure Boot will detect the anomalous bootloader and prevent further execution, containing the damage and preventing the very dangerous encryption of disk sectors leading to a complete loss of data. A machine in this state will be prevented from booting and can be recovered with the regular repair functionality from the Windows USB/DVD media. NOTE: Individual files encrypted by Petya in the limited time before reboot will remain encrypted and must be recovered from backup copies.

App Locker can also be used to block execution of certain programs (e.g. PSEXEC) or unsigned binaries (e.g. Petya’s DLL library) for machines that cannot benefit from Device Guard due to lack of the specific hardware requirements or due to older operating systems not supporting new mitigations (e.g. Windows 7).

Finally, administrators of networks with older operating systems like Windows 7 which do not benefit of modern hardware and software mitigations, may consider deploying some hardened configurations that could help to slow down or remove certain lateral movement techniques. Such hardened configurations may impact legitimate functionality such as file-sharing or remote management and so it needs to be evaluated carefully before deployment.

Limited execution time

The impact of Petya’s worm behavior is limited by its design. As part of its execution command, it receives a time that it can run performing lateral movement and exploitation before rebooting the system.

If an argument is not passed, a default of 60mins is assumed. This value is later used to determine the time in the future for the system to reboot.

This means that the threat can only do lateral movement and exploitation of other machines during this limited time. This reduced the reach of the attack, as observed in our telemetry.

Also, the malware’s worm code does not persist across reboot; for example, if an infected machine is successfully rebooted, the worm does not run again.

Conditional behavior and boot sector modification

In addition to modifying the MBR, the malware modifies the second sector of the C: partition by overwriting it with uninitialized buffer, effectively destroying the Volume Boot Record (VBR) for that partition. The screenshot below shows the code that makes these changes:

It is not clear what the purpose of these modifications are, but the code appears to be buggy – it allocates 10 times the amount of memory it requires. In most modern machines, the VBR on the C: partition is not used for booting as there is a separate partition for the boot manager. Generally, for machines running Windows 7 or later that weren’t upgraded from XP, the malware’s VBR changes are unlikely to have any impact.

During malware initialization phase, this malware maintains a global variable that dictates its behavior. It alters its behavior based on the presence of processes related to certain antivirus applications running in the system.

Specifically, it looks for names of processes belonging to Kaspersky Antivirus and Symantec Antivirus and alters its behavior if it finds them. Below are the CRC values that threat checks and their corresponding process names.

CRC value

Matching process name

0x651B3005

NS.exe

0x6403527E

ccSvcHst.exe

0x2E214B44

avp.exe

Information controlling threats behavior is stored in a global variable (gConfig in the screenshots), which is then used to check during MBR modification.

If Kaspersky Antivirus process is found in the system or if the MBR infection is unsuccessful, the malware then proceeds to destroy the first 10 sectors of the hard drive. The code snippet below shows the threat logic:

On the other hand, if Symantec AV process names are found, the threat does not perform SMB exploitation.

We compared this new ransomware’s MBR infection functionality to the original Petya malware. Here are some of our findings:

Although the layout of the code and encrypted data in the sectors following the MBR varies between the two versions, the code itself is functionally very similar. The encryption process is the same: when the malicious MBR starts, it loads additional code from sectors after the MBR, which in turn proceeds to encrypt the Master File Table (MFT). After the encryption process is complete, the user is presented with the following ransom message, which is different from the typical ASCII skull and crossbones shown by the original Petya:

Ransom note from Petya after MBR infection

Interestingly, the first part of the text is the same message used by the WannaCrypt ransomware:

WannaCrypt ransom note

In terms of the malware code itself, there are some differences between the new Petya variant and the original malware. For example, the malware authors changed the constants for the key expansions of the encryption algorithm (Salsa20)— the standard string “expand 32-byte k” was replaced with the custom “-1nvalid s3ct-id”.

The code that is supposed to show the skull and crossbones ransom note is still physically present in the malicious MBR code, but it is only printing empty lines.

The strategy to cause a reboot to trigger the malicious MBR code has also been updated. The original version generated a serious system error by calling NtRaiseHardError with code 0xC0000350 (STATUS_HOST_DOWN), which forced the machine to reboot. The new Petya variant has also added a function to schedule a task that reboots the machine after a pre-configured number of minutes.

Fake victim ID

Below is the structure of the malware configuration stored by threat at Sector 32 (0x20):

typedef struct

{

BYTE Null;

BYTE SalsaKey[0x20];

BYTE SalsaIV[0x08];

BYTE BitcoinAddress[0x22];

BYTE Empty[0x5E];

BYTE VictimID[0x3C]; // 60 bytes

BYTE Empty2[0x11B];

}

The VictimID shown to the user is randomly generated using CryptGenRandom() and does not correspond to the MFT encryption, so the ID shown is of no value and is also independent from the per-drive file encryption ID written on README.TXT.

Below is a sample disk sector 32 written by the malware. Unlike the original Petya malware, elliptic curve data is empty.

Boot recovery options

Petya causes some damage to the operating system’s boot code. In certain cases, recovery to boot the infected machine to a clean state is possible.

Case 1: If machine is equipped with secure boot + UEFI

If an infected machine shows the message below, it means the threat couldn’t hijack the boot process and encrypt MFT. In this case, booting off a clean installation media and performing Startup Recovery can fix the issue, and the machine can be booted.

Case 2: If system is non-UEFI, installed with Kaspersky Antivirus, and in a state where boot completely fails

The ransomware attempts to destroy the first 10 sectors of the \\\\.\\PhysicalDrive0 if Kaspersky Antivirus is found or if the MBR infection is unsuccessful. Thus, boot process hijack through malicious MBR hasn’t been completed so the MFT (Master File table) contents are intact and not encrypted by the threat. In this case, the partition table information is destroyed by the threat. Given that it stores critical information needed in the booting process, a traditional boot repair process may not work. Rebuilding the partition table may require consultation with an expert.

Case 3: if a ransom message like below is seen, recovery is not possible

The image is shown if the machine reboots and the malicious MBR is executed successfully. In this case, it is likely that the malware successfully encrypted the MFT, a vital structure of the NTFS file system. Unfortunately, recovery is not possible, and the machine is not capable of booting anymore. One can take the hard disk to another clean system, use disk recovery tools to recover any recoverable personal files, and reimage the system.

Protection against ransomware attacks

The new Petya ransomware variant we saw this week is significantly more complex than the original. It also improved on WannaCrypt‘s spreading mechanisms by using a second exploit and adding more propagation methods. These lateral movement capabilities make this ransomware a higher risk for networks with an infected machine. Furthermore, the boot sector modification behavior discussed in this blog gives this ransomware more potential to cause damage to machines.

This Petya outbreak exemplifies the ever-increasing sophistication of ransomware attacks. A multi-layer defense stack is needed to protect computers and networks. At Microsoft, we strive to continuously enhance Windows 10 with next-generation features to protect customers. As described in this blog, Windows 10 has defenses that can mitigate ransomware attacks like Petya.

Featured Posts

In the first blog post of this 3-part series, we introduced what rapid cyberattacks are and illustrated how rapid cyberattacks are different in terms of execution and outcome. In the second blog post, we provided some details on Petya and how it worked. In this final blog post, we will share: Microsoft’s roadmap of recommendations...

The word strategy has its origins in the Roman Empire and was used to describe the leading of troops in battle. From a military perspective, strategy is a top-level plan designed to achieve one or more high-order goals. A clear strategy is especially important in times of uncertainty as it provides a framework for those...

Last week the technology industry and many of our customers learned of new vulnerabilities in the hardware chips that power phones, PCs and servers. We (and others in the industry) had learned of this vulnerability under nondisclosure agreement several months ago and immediately began developing engineering mitigations and updating our cloud infrastructure. In this blog,...

For several years now, policymakers and practitioners from governments, CERTs, and the security industry have been speaking about the importance of public-private partnerships as an essential part of combating cyber threats. It is impossible to attend a security conference without a keynote presenter talking about it. In fact, these conferences increasingly include sessions or entire...