- Apr 21, 2016
- 4,374
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:
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:
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
As discussed in our in-depth analysis of the Petya ransomware attack, beyond encrypting files, the ransomware also attempts to infect the Master Boot Record (MBR).
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:
Below snapshot shows threat code that destroys 10 sectors of \\\\.\\PhysicalDrive0, including the MBR sector.
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):
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. Thus, boot process hijack through malicious MBR hasn’t been completed. In this case, booting off a clean installation media, going to recovery console and performing the following commands has good chances of recovering the system and make it boot again (success depends on the specific initial disk sectors layout):
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.
Windows Defender Antivirus and Windows Defender Advanced Threat Protection allows customers to detect, investigate, and respond to ransomware attacks. For enterprises, Device Guard locks down devices and provide kernel-level virtualization based security. Credential Guard protects domain credentials stored in the Windows Credential Store.
To know more about security features in Windows 10, read out white paper “Next-gen ransomware protection with Windows 10 Creators Update”.
To find mitigation steps specific to this new Petya variant, refer to our blog “New ransomware, old techniques: Petya adds worm capabilities”.
Resources
Next-generation ransomware protection with Windows 10 Creators Update: https://blogs.technet.microsoft.com...pdate-hardens-security-with-next-gen-defense/
Download English language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64
Download localized language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64
MS17-010 Security Update: https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
General information on ransomware: https://www.microsoft.com/en-us/security/portal/mmpc/shared/ransomware.aspx
Continue reading...
- The new Petya variant is highly sophisticated malware, but our telemetry shows it had far less reach than we expected (less than 20,000 machines), 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 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. Previous blogs 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.
- Block or restrict access to specific IPs for file-sharing services (SMB)
netsh firewall set service fileandprint
netsh firewall set service RemoteAdmin disable
- Block remote execution through PSEXEC
FOR /F “usebackq tokens=2 delims=:” %a IN (`sc.exe sdshow scmanager`) DO sc.exe sdset scmanager D
D;;0x00040002;;;NU)%a
D;;0x00040002;;;NU)%aLimited 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
As discussed in our in-depth analysis of the Petya ransomware attack, beyond encrypting files, the ransomware also attempts to infect the Master Boot Record (MBR).
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:
Below snapshot shows threat code that destroys 10 sectors of \\\\.\\PhysicalDrive0, including the MBR sector.
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. Thus, boot process hijack through malicious MBR hasn’t been completed. In this case, booting off a clean installation media, going to recovery console and performing the following commands has good chances of recovering the system and make it boot again (success depends on the specific initial disk sectors layout):
<recovery_console> bootrec /fixmbr
<recovery_console> bootrec /fixboot
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.
Windows Defender Antivirus and Windows Defender Advanced Threat Protection allows customers to detect, investigate, and respond to ransomware attacks. For enterprises, Device Guard locks down devices and provide kernel-level virtualization based security. Credential Guard protects domain credentials stored in the Windows Credential Store.
To know more about security features in Windows 10, read out white paper “Next-gen ransomware protection with Windows 10 Creators Update”.
To find mitigation steps specific to this new Petya variant, refer to our blog “New ransomware, old techniques: Petya adds worm capabilities”.
Resources
Next-generation ransomware protection with Windows 10 Creators Update: https://blogs.technet.microsoft.com...pdate-hardens-security-with-next-gen-defense/
Download English language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64
Download localized language security updates: Windows Server 2003 SP2 x64, Windows Server 2003 SP2 x86, Windows XP SP2 x64, Windows XP SP3 x86, Windows XP Embedded SP3 x86, Windows 8 x86, Windows 8 x64
MS17-010 Security Update: https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
General information on ransomware: https://www.microsoft.com/en-us/security/portal/mmpc/shared/ransomware.aspx
Continue reading...
