Windows Defender Antivirus cloud protection service: Advanced real-time defense against never-before-seen malware
For cybercriminals, speed is the name of the game. It takes newly released malware an average of just four hours to achieve its goal—steal financial information, extort money, or cause widespread damage. In a recent report, the Federal Trade Commission (FTC) said that cybercriminals will use hacked or stolen information within nine minutes of posting in underground forums. Stopping new malware in real-time is more critical than ever.
Approximately 96% of all malware files detected and blocked by Windows Defender Antivirus (Windows Defender AV) are observed only once on a single computer, demonstrating the polymorphic and targeted nature of modern attacks, and the fragmented state of the threat landscape. Hence, blocking malware at first sight is a critical protection capability.
To fight the speed, scale, and complexity of threats, we work to continually enhance Windows Defender AV and other security features built into Windows 10. In our white paper "The evolution of malware prevention" we discussed our advanced, predictive approach to protecting customers from threats that they face today, as well as those that will emerge in the future.
This blog continues that discussion and provides the first detailed account of one way we improve our capability to stop never-before-seen malware with new enhancements to the Windows Defender Antivirus cloud protection service.
In Windows 10 Creators Update, the Windows Defender AV client uploads suspicious files to the cloud protection service for rapid analysis. Our ability to make a swift assessment of new and unknown files allows us to protect customers from malware the first time we see it.
We have built these enhancements on the next-gen security technologies enabling Windows Defender AV to automatically block most new, never-before-seen threats at first sight using the following methods:
- Lightweight client-based machine learning models, blocking new and unknown malware
- Local behavioral analysis, stopping file-based and file-less attacks
- High-precision antivirus, detecting common malware through generic and heuristic techniques
In relatively rare cases, when Windows Defender AV needs additional intelligence to verify the intent of a suspicious file, it sends metadata to the cloud protection service, which can determine whether the file is safe or malicious within milliseconds using the following techniques:
- Precise cloud-based machine learning models that can make an accurate assessment based on signals from the client
- Microsoft Intelligent Security Graph that monitors threat data from a vast network of sensors
In rarer cases still, when Windows Defender AV cloud protection service is unable to reach a conclusive verdict based on metadata, it can request the potential malware sample for further inspection.
In Windows 10 Creators Update, the Windows Defender AV client uploads suspicious files to the cloud protection service for rapid analysis. While waiting for a verdict, the Windows Defender AV client maintains a lock on the dubious files, preventing possible malicious behavior. The Windows Defender AV client then takes action based on the verdict. For example, if the cloud protection service determines the file as malicious, it blocks the file from running, providing instant protection.
In a recent real-life example, a Windows 10 Home customer was tricked into downloading a new variant of the Ransom:Win32/Spora family of ransomware.
The malware was disguised as a font file with the name "Chrome font.exe". It was hosted on an online learning website that had been compromised by an attacker, who attempted to trick people into downloading the malware using a social engineering tactic described by Proofpoint in this blog. In this scheme targeting Chrome users, legitimate websites were compromised to open a pop-up window indicating "The ‘HoeflerText’ font wasn’t found", requiring a supposed update to fix. The customer clicked the "Update" button in the pop-up window, which downloaded the Spora ransomware variant.
The customer’s Windows Defender AV client routinely scanned the file using on-box rules and definitions. Since it had not encountered the file before, Windows Defender AV did not detect it as malicious; however, it recognized the file’s suspicious characteristics, so it temporarily prevented the file from running. The client sent a query to the Windows Defender AV cloud protection service, which used machine-learning-powered cloud rules to confirm that the file was likely malware needing further investigation.
Within 312 milliseconds, the cloud protection service returned an initial assessment. It then instructed the client to send a sample and to continue locking the file until a more definite verdict was given.
In about two seconds, the client finished uploading the sample. By default, it’s set to wait for up to 10 seconds to hear back from the cloud protection service before letting such suspicious files run.
As soon as the sample was uploaded, a backend file-processing system analyzed the sample. A multi-class machine learning classifier determined there was more than a 95% chance that the file was malicious. The cloud protection service created a signature, which it sent back to client. All of this happened in just five seconds.
One second later, the Windows Defender AV client applied the cloud signature and quarantined the malware. It reported the results back to the cloud service; from that point on, this file was automatically blocked, protecting all Windows PC customers.
From the time Windows Defender AV uploaded the sample, the cloud protection service returned the malware signature in just five seconds, as shown by these actual timestamps:
2017-04-20 03:53:21 – Cloud protection service received query from Windows Defender AV client
2017-04-20 03:53:21 – Cloud protection service assessed it hadn’t seen the file and that is was suspicious, so it requested a sample and to keep locking the file
2017-04-20 03:53:23 – Sample finished uploading
2017-04-20 03:53:28 – Cloud protection service determined file as malware, generated signature, and sent that back to client
2017-04-20 03:53:29 – Windows Defender AV client notified that it successfully detected and removed the malwareStay protected with Windows 10 Creators Update
Our many years of in-depth research into malware, cyberattacks, and cybercriminal operations give us insight into how threats continue to evolve and attempt to slip past security solutions. Guided by expert threat researchers, we use data science, machine learning, automation, and behavioral analysis to improve our detection solutions continuously.
In Windows 10 Creators Update, we rolled out important updates to Windows Defender Antivirus, which uses cloud protection service that delivers real-time protection against threats. With these enhancements, we show our commitment to providing unparalleled real-time defense against modern attacks.
Our ability to make a swift assessment of new and unknown files allows us to protect even would-be patient zero against attacks. More importantly, we use this intelligence to protect the rest of our customers, who may encounter these malware in subsequent attacks or similar threats in other cybercriminal campaigns.
Cloud-based protection is enabled in Windows Defender AV by default. To check that it’s running, launch the Windows Defender Security Center. Go to Settings > Virus & threat protection settings, and make sure that Cloud-based protection and Automatic sample submission are both turned On.
In enterprise environments, cloud protection service can be managed using Group Policy or via the Windows Defender Security Center app.
When enabled, Windows Defender AV locks a suspicious file for 10 seconds by default, while it queries the Windows Defender AV cloud protection service. Administrators can configure Windows Defender AV to extend the timeout period up to one minute to give the cloud service time to perform even more analysis and apply additional techniques to detect new malware.
As the threat landscape continues to move towards more sophisticated attacks and malware campaigns that can achieve their goals in hours instead of days, it is critical to be able to respond to new attacks in real-time. With Windows 10 Creators Update and the investments we’ve made in cloud protection service, we’re able to detect brand new threat families within seconds, protect “patient zero”, and disrupt new malware campaigns before they start.
Senior Program Manager, Windows Defender Engineering
Detecting stealthier cross-process injection techniques with Windows Defender ATP: Process hollowing and atom bombing
Advanced cyberattacks emphasize stealth and persistence: the longer they stay under the radar, the more they can move laterally, exfiltrate data, and cause damage. To avoid detection, attackers are increasingly turning to cross-process injection.
Cross-process injection gives attackers the ability to run malicious code that masquerades as legitimate programs. With code injection, attackers don’t have to use custom processes that can quickly be detected. Instead, they insert malicious code into common processes (e.g., explorer.exe, regsvr32.exe, svchost.exe, etc.), giving their operations an increased level of stealth and persistence.
Windows Defender Advanced Threat Protection (Windows Defender ATP) uncovers this type of stealth attack, including ones that use newer forms of injection. In Windows 10 Creators Update, we enhanced Windows Defender ATP’s instrumentation and detection of in-memory injection methods like process hollowing and atom bombing.
Windows Defender ATP is a post-breach solution that alerts security operations (SecOps) teams about hostile activity. As the nature of attacks evolve, Windows Defender ATP continues to advance to help SecOps personnel detect and respond effectively to attacks.
This blog post is the next in a series of blogs about how Windows Defender ATP detects code injection techniques. We tackle process hollowing and atom bombing attacks to illustrate how Windows Defender ATP detects a broad spectrum of nefarious activity, from commodity malware that attempts to hide from plain sight, to sophisticated activity groups that engage in targeted attacks.Process hollowing: Hiding code in legitimate processes
Process hollowing is a code injection technique that involves spawning a new instance of a legitimate process and then “hollowing it out”, i.e., replacing the legitimate code with malware. Unlike most injection techniques that add a malicious feature to an otherwise normally running process, the result of hollowing is a process that looks legitimate on the outside but is primarily malicious on the inside.
While there are few known techniques that achieve process hollowing, the most common variant typically follows four steps to achieve stealthy execution of malicious code:
- The malware spawns a new instance of a legitimate process (e.g., explorer.exe, lsass.exe, etc.), and places it in a suspended state.
- The malware then hollows out the memory section in the new (and still suspended) process that holds the base address of the legitimate code. To do this, the malware uses the NtUnmapViewOfSection routine.
- It allocates read-write-execute (RWX) memory in the suspended process to prepare for the replacement malicious code.
- The malware then copies malicious code into the allocated memory. It changes the target address of the first thread to the malicious program’s entry point.
When the thread resumes, the malicious code starts running, now disguised as a legitimate process. The malware is then free to delete remnants of itself from disk to avoid detection.Atom bombing: New cloak of disguise
Atom bombing is one of the most recent code injection techniques observed in attacks. It is a method that can be used by an attacker who has already compromised a machine and who can execute code to perform stealthy code injection into other processes using lesser known APIs.
In this technique, the malware writes malicious code to the global atom table, which can be accessed by all applications. The malware then dispatches an asynchronous procedure call (APC) to the APC queue of a target process thread using the native NtQueueApcThread API. When executed, this APC forces the target process to call the GlobalGetAtomName function, which retrieves the malicious code from the global atom table and inserts the code into the memory of the target process.
Writing malicious code into the memory space of another process without use of WriteProcessMemory is a clever trick, but the malicious code, when transferred via atom table, is not ready to be executed. An extra step is required to achieve the final goal: one more APC call is used to invoke return-oriented-programming (ROP) and convert the code memory region into RWX. Only then does the malicious code run.Detecting process hollowing and atom bombing with enhanced Windows Defender ATP capabilities
In Windows Defender ATP Creators Update, we have instrumented function calls and built statistical models to detect a broad range of malicious injection techniques used in attacks.
We tested these capabilities against real-world examples of malware that use process hollowing, atom bombing, and other injection methods. In the following sections, we illustrate how Windows Defender ATP uncovers attacks that use code injection to gain stealth and persistence in target networks.Kovter: Classic process hollowing in action
Kovter is a family of click-fraud Trojans that have been around since 2013 but have recently been observed to associate with ransomware families like Locky. In 2016, we discovered Kovter variants that achieved an almost file-less persistence.
Kovter achieves persistence by adding shortcuts (.lnk files) to the startup folder or adding entries to the registry key HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Both methods open a component file with a random file name extension.
It adds two registry entries to the HKEY_USERS hive so that the component file is opened by the legitimate program mshta.exe, which extracts an obfuscated payload from a third registry key.
When the payload is decrypted, a PowerShell script is extracted and added as a new environmental variable. The PowerShell then executes a script referred to in the environmental variable, which injects shellcode into a target process.
Using the shellcode, Kovter employs the process hollowing technique to inject malicious code into legitimate processes. Through process hollowing, this nearly file-less malware can achieve and maintain a stealthy presence, presenting a challenge to traditional AV solutions.
Windows Defender ATP, using enhanced instrumentation and detection capabilities, exposes the function calls used in this technique. Furthermore, through statistical models, Windows Defender ATP zeroes in on malicious functions required to execute process hollowing.
The screenshot below shows the Windows Defender ATP alert for the process injection routine. It shows mshta.exe being used to launch and execute a malicious PowerShell script (1, 2), as well as the hollowed-out process regsvr32.exe that contain malicious code (3, 4).
Figure 1: Windows Defender ATP detection of Kovter performing process hollowing on regsvr32.exe using mshta.exeDridex: Early adopter of atom bombing
Since its release in 2014, Dridex has been a very prolific and nasty banking Trojan. Delivered primarily by phishing emails, Dridex pilfers banking credentials and sensitive information, disables security products, and gives attackers remote access to victim computers.
Over the years, Dridex’s code has gone through several revisions. With its most recent version, Dridex became one of the earliest adopters of the atom bombing injection technique. It maintains stealth and persistence by avoiding the common API calls that are associated with code injection techniques.
When executed, Dridex looks for an alertable thread for a target process. It then ensures that user32.dll is loaded by the target process. It needs user32.dll to access the required atom table functions. Once this requirement is met, Dridex writes its shellcode to the global atom table.
It then forces the target process to copy the malicious code into memory by adding a series of NtQueueApcThread calls for GlobalGetAtomNameW to the APC queue of the target process thread.
Figure 2: NtQueueApcThread calls to GlobalGetAtomNameW added to the APC queue of the target process.
Finally, Dridex calls NtProtectVirtualMemory to transform the memory location (where the malicious code now resides) into executable memory. At this point, Dridex can freely execute its code in the context of the legitimate process.
Windows Defender ATP uncovers the use of the atom bombing technique. The screenshot below shows a Windows Defender ATP alert on Dridex that used atom bombing to inject malicious code into the legitimate process svchost.exe.
Figure 3: Windows Defender ATP detection of Dridex performing atom bombing on svchost.exeConclusion: Windows Defender ATP Creators Update exposes covert cyberattacks
Windows 10 continues to elevate defense capabilities against the full range of modern threats. Attackers respond to this by launching more complex attacks that are increasingly sneakier and more persistent. Kovter and Dridex are examples of prominent malware families that evolved to evade detection using code injection techniques. Inevitably, process hollowing, atom bombing, and other advanced techniques will be used by existing and new malware families.
Windows Defender ATP uses rich security data, advanced behavioral analytics, and machine learning to detect the invariant techniques used in attacks. Windows Defender ATP Creators Update has enhanced instrumentation and detection capabilities to better expose covert attacks.
Windows Defender ATP also provides detailed event timelines and other contextual information that SecOps teams can use to understand attacks and quickly respond. The improved functionality in Windows Defender ATP enables them to isolate the victim machine and protect the rest of the network.
For more information about Windows Defender ATP, check out its features and capabilities and read about why a post-breach detection approach is a key component of any enterprise security strategy. Windows Defender ATP is built into the core of Windows 10 Enterprise and can be evaluated free of charge.
Windows Defender ATP Research Team
On May 12, there was a major outbreak of WannaCrypt ransomware. WannaCrypt directly borrowed exploit code from the ETERNALBLUE exploit and the DoublePulsar backdoor module leaked in April by a group calling itself Shadow Brokers.
Using ETERNALBLUE, WannaCrypt propagated as a worm on older platforms, particularly Windows 7 and Windows Server 2008 systems that haven’t patched against the SMB1 vulnerability CVE-2017-0145. The resulting ransomware outbreak reached a large number of computers, even though Microsoft released security bulletin MS17-010 to address the vulnerability on March 14, almost two months before the outbreak.
This post—complementary to our earlier post about the ETERNALBLUE and ETERNALROMANCE exploits released by Shadow Brokers—takes us through the WannaCrypt infection routine, providing even more detail about post-exploitation phases. It also describes other existing mitigations as well as new and upcoming mitigation and detection techniques provided by Microsoft to address similar threats.Infection cycle
The following diagram summarizes the WannaCrypt infection cycle: initial shellcode execution, backdoor implantation and package upload, kernel and userland shellcode execution, and payload launch.
Figure 1. WannaCrypt infection cycle overview
The file mssecsvc.exe contains the main exploit code, which launches a network-level exploit and spawns the ransomware package. The exploit code targets a kernel-space vulnerability and involves multi-stage shellcode in both kernel and userland processes. Once the exploit succeeds, communication between the DoublePulsar backdoor module and mssecsvc.exe is encoded using a pre-shared XOR key, allowing transmission of the main payload package and eventual execution of ransomware code.Exploit and initial shellcodes
In an earlier blog post, Viktor Brange provided a detailed analysis of the vulnerability trigger and the instruction pointer control mechanism used by ETERNALBLUE. After the code achieves instruction pointer control, it focuses on acquiring persistence in kernel space using kernel shellcode and the DoublePulsar implant. It then executes the ransomware payload in user space.Heap spray
The exploit code sprays memory on a target computer to lay out space for the first-stage shellcode. It uses non-standard SMB packet segments to make the allocated memory persistent on hardware abstraction layer (HAL) memory space. It sends 18 instances of heap-spraying packets, which have direct binary representations of the first-stage shellcode.
Figure 2. Shellcode heap-spraying packetInitial shellcode execution: first and second stages
The exploit uses a function-pointer overwrite technique to direct control flow to the first-stage shellcode. This shellcode installs a second-stage shellcode as a SYSENTER or SYSCALL routine hook by overwriting model-specific registers (MSRs). If the target system is x86-based, it hooks the SYSENTER routine by overwriting IA32_SYSENTER_EIP. On x64-based systems, it overwrites IA32_LSTAR MSR to hook the SYSCALL routine. More information about these MSRs can be found in Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3C.
Figure 3. First-stage shellcode for x86 systems
Originally, the IA32_SYSENTER_EIP contains the address to nt!KiFastCallEntry as its SYSENTER routine.
Figure 4. Original IA32_SYSENTER_EIP value pointing to KiFastCallEntry
After modification by the first-stage shellcode, IA32_SYSENTER_EIP now points to the second-stage shellcode.
Figure 5. Modified IA32_SYSENTER_EIP value points to the main shellcode
The first-stage shellcode itself runs in DISPATCH_LEVEL. By running the second-stage shellcode as the SYSENTER routine, the first-stage code guarantees that the second-stage shellcode runs in PASSIVE_LEVEL, giving it access to a broader range of kernel APIs and paged-out memory. And although the second-stage shellcode delivered with this malware actually doesn’t access any paged pools or call APIs that require running in PASSIVE_LEVEL, this approach allows attackers to reuse the same module for more complicated shellcode.Backdoor implantation
The second-stage shellcode, now running on the targeted computer, generates a master XOR key for uploading the payload and other communications. It uses system-specific references, like addresses of certain APIs and structures, to randomize the key.
Figure 6. Master XOR key generation
The second-stage shellcode implants DoublePulsar by patching the SMB1 Transaction2 dispatch table. It overwrites one of the reserved command handlers for the SESSION_SETUP (0xe) subcommand of the Transaction2 request. This subcommand is reserved and not commonly used in regular code.
Figure 7. Copying packet-handler shellcode and overwriting the dispatch table
The following code shows the dispatch table after the subcommand backdoor is installed.
Figure 8. Substitution of 0xe command handlerMain package upload
To start uploading its main package, WannaCrypt sends multiple ping packets to the target, testing if its server hook has been installed. Remember that the second-stage shellcode runs as a SYSENTER hook—there is a slight delay before it runs and installs the dispatch-table backdoor. The response to the ping packet contains the randomly generated XOR master key to be used for communication between the client and the targeted server.
Figure 9. Code that returns original XOR key
This XOR key value is used only after some bit shuffling. The shuffling algorithm basically looks like the following Python code.
Figure 10. XOR bit-shuffling code
The upload of the encoded payload consists of multiple packets as shown below.
Figure 11. SMB Transaction2 packet showing payload upload operation
The hooked handler code for the unimplemented subcommand processes the packet bytes, decoding them using the pre-shared XOR key. The picture above shows that the SESSION_SETUP parameter fields are used to indicate the offset and total lengths of payload bytes. The data is 12 bytes long—the first four bytes indicate total length, the next four bytes is reserved, and the last 4 bytes are the current offsets of the payload bytes in little-endian. These fields are encoded with master XOR key.
Because the reserved field is supposed to be 0, the reserved field is actually the same as the master XOR key. Going back to the packet capture above, the reserved field value is 0x38a9dbb6, which is the master XOR key. The total length is encoded as 0x38f9b8be. When this length is XORed with the master XOR key, it is 0x506308, which is the actual length of the payload bytes being uploaded. The last field is 0x38b09bb6. When XORed with the master key, this last field becomes 0, meaning this packet is the first packet of the payload upload.
When all the packets are received, the packet handler in the second-stage shellcode jumps to the start of the decoded bytes.
Figure 12. Decoding and executing shellcode
The transferred and decoded bytes are of size 0x50730c. As a whole, these packet bytes include kernel shellcode, userland shellcode, and the main WannaCrypt PE packages.Executing the kernel shellcode
The kernel shellcode looks for a kernel image base and resolves essential functions by parsing PE structures. The following figure shows the APIs resolved by the shellcode:
Figure 13. Resolved kernel functions
It uses ZwAllocateVirtualMemory to allocate a large chunk of RWX memory (0x506d70 in this case). This memory holds the userland shellcode and the main PE packages.
Figure 14. RWX memory allocation through ZwAllocateVirtualMemory
The kernel shellcode goes through processes on the system and injects userland shellcode to the lsass.exe process using an asynchronous procedure call (APC).
Figure 15. APC routines for injecting shellcode to a thread in a userland processUserland shellcode—the start of a new infection cycle
After multiple calls to VirtualProtect and PE layout operations, the shellcode loads a bootstrap DLL using a reflective DLL loading method. The WannaCrypt user-mode component contains this bootstrap DLL for both 64- and 32-bit Windows.
Figure 16. Bootstrap DLL functions
This bootstrap DLL reads the main WannaCrypt payload from the resource section and writes it to a file C:\WINDOWS\mssecsvc.exe. It then launches the file using the CreateProcess API. At this stage, a new infection cycle is started on the newly infected computer.
Figure 17. Dropping main payload to file system
Figure 18. Creating the main payload processMitigating and detecting WannaCrypt
WannaCrypt borrowed most of its attack code from those leaked by Shadow Brokers, specifically the ETERNALBLUE kernel exploit code and the DoublePulsar kernel-level backdoor. It leverages DoublePulsar’s code execution mechanisms and asynchronous procedure calls (APCs) at the kernel to deliver its main infection package and ransomware payload. It also uses the system file lsass.exe as its injection target.Mitigation on newer platforms and upcoming SMB updates
The ETERNALBLUE exploit code worked only on older OSes like Windows 7 and Windows Server 2008, particularly those that have not applied security updates released with security bulletin MS17-010. The exploit was limited to these platforms because it depended on executable memory allocated in kernel HAL space. Since Windows 8 and Windows Server 2012, HAL memory has stopped being executable. Also, for additional protection, predictable addresses in HAL memory space have been randomized since Windows 10 Creators Update.
With the upcoming Windows 10 Fall Creators Update (also known as RS3), many dispatch tables in legacy SMB1 drivers, including the Transaction2 dispatch table (SrvTransaction2DispatchTable) memory area, will be set to read-only as a defense-in-depth measure. The backdoor mechanism described here will be much less attractive to attackers because the mechanism will require additional exploit techniques for unlocking the memory area and overwriting function pointers. Furthermore, SMB1 has already been deprecated for years. With the RS3 releases for Windows 10 and Windows Server 2016, SMB1 will be disabled.Hyper Guard virtualization-based security
WannaCrypt employs multiple techniques to achieve full code execution on target systems. The IA32_SYSENTER_EIP modification technique used by WannaCrypt to run the main shellcode is actually commonly observed when kernel rootkits try to hook system calls. Kernel Patch Protection (or PatchGuard) typically detects this technique by periodically checking for modifications of MSR values. WannaCrypt hooking, however, is too brief for PatchGuard to fire. Windows 10, armed with virtualization-based security (VBS) technologies such as Hyper Guard, can detect and mitigate this technique because it fires as soon as the malicious wrmsr instruction to modify the MSR is executed.
To enable Hyper Guard on systems with supported processors, use Secure Boot and enable Device Guard. Use the hardware readiness tool to check if your hardware system supports Device Guard. Device Guard runs on the Enterprise and Education editions of Windows 10.Post-breach detection with Windows Defender ATP
In addition to VBS mitigation provided with Hyper Guard, Windows Defender Advanced Threat Protection (Windows Defender ATP) can detect injection of code to userland processes, including the method used by WannaCrypt. Our researchers have also added new detection logic so that Windows Defender ATP flags highly unusual events that involve spawning of processes from lsass.exe.
Figure 19. Windows Defender ATP detection of an anomalous process spawned from a system process
While the detection mechanism for process spawning was pushed out in response to WannaCrypt, this mechanism and detection of code injection activities also enable Windows Defender ATP customers to uncover sophisticated breaches that leverage similar attack methods.
Windows Defender ATP Research Team
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 (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
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):
BYTE VictimID[0x3C]; // 60 bytes
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/mmpc/2017/06/08/windows-10-creators-update-hardens-security-with-next-gen-defense/
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
On June 27, 2017 reports of a ransomware infection began spreading across Europe. We saw the first infections in Ukraine, where more than 12,500 machines encountered the threat. We then observed infections in another 64 countries, including Belgium, Brazil, Germany, Russia, and the United States.
The new ransomware has worm capabilities, which allows it to move laterally across infected networks. Based on our investigation, this new ransomware shares similar codes and is a new variant of Ransom:Win32/Petya. This new strain of ransomware, however, is more sophisticated.
To protect out customers, we released cloud-delivered protection updates and made updates to our signature definition packages shortly after. These updates were automatically delivered to all Microsoft free antimalware products, including Windows Defender Antivirus and Microsoft Security Essentials. You can download the latest version of these files manually at the Malware Protection Center.
Windows Defender Advanced Threat Protection (ATP) automatically detects behaviors used by this new ransomware variant without any updates.Delivery and installation
Initial infection appears to involve a software supply-chain threat involving the Ukrainian company M.E.Doc, which develops tax accounting software, MEDoc. Although this vector was speculated at length by news media and security researchers—including Ukraine’s own Cyber Police—there was only circumstantial evidence for this vector. Microsoft now has evidence that a few active infections of the ransomware initially started from the legitimate MEDoc updater process. As we highlighted previously, software supply chain attacks are a recent dangerous trend with attackers which requires advanced defense.
We observed telemetry showing the MEDoc software updater process (EzVit.exe) executing a malicious command-line matching this exact attack pattern on Tuesday, June 27 around 10:30 GMT.
The diagram of the execution chain leading to the ransomware installation is represented in the picture below and essentially confirms that EzVit.exe process from MEDoc, for unknown reasons, at some moment executed the following command-line:
C:\\Windows\\system32\\rundll32.exe\” \”C:\\ProgramData\\perfc.dat\”,#1 30
The same update vector was also mentioned by Ukraine Cyber Police in a public list of indicator of compromise (IOCs) , which includes the MeDoc updater.A single ransomware, multiple lateral movement techniques
Given this new ransomware’s added lateral movement capabilities it only takes a single infected machine to affect a network. The ransomware spreading functionality is composed of multiple methods responsible for:
- stealing credentials or re-using existing active sessions
- using file-shares to transfer the malicious file across machines on the same network
- using existing legitimate functionalities to execute the payload or abusing SMB vulnerabilities for unpatched machines
In the next sections, we’ll dig into the details of each technique.Lateral Movement using credential theft and impersonation
This ransomware drops a credential dumping tool (typically as a .tmp file in the %Temp% folder) that shares code similarities with Mimikatz and comes in 32-bit and 64-bit flavors. Because users frequently log in using accounts with local admin privileges and have active sessions opens across multiple machines, stolen credentials are likely to provide the same level of access the user has on other machines. Once the ransomware has valid credentials, it scans the local network to establish valid connections on ports tcp/139 and tcp/445. A special behavior is reserved for Domain Controllers or servers: this ransomware attempts calls DhcpEnumSubnets() to enumerate DCP subnets all hosts on all DHCP subnets before scanning for tcp/139 and tcp/445 services. If it gets a response, the malware attempts to copy a binary on the remote machine using regular file-transfer functionalities with stolen credentials.
It then tries to execute remotely the malware using either PSEXEC or WMIC tools.
The ransomware attempts to drop the legitimate psexec.exe (typically renamed to dllhost.dat) from an embedded resource within the malware. It then scans the local network for admin$ shares, copies itself across the network, and executes the newly copied malware binary remotely using psexec.
In addition to credential dumping, the malware also tries to steal credentials by using the CredEnumerateW function to get all the other user credentials potentially stored on the credential store. If a credential name starts with “TERMSRV/” and the type is set as 1 (generic) it uses that credential to propagate through the network.
Ransomware code responsible for accessing \\Admin$ shares on different machines
This ransomware also uses the Windows Management Instrumentation Command-line (WMIC) to find remote shares (using NetEnum/NetAdd) to spread to. It uses either a duplicate token of the current user (for existing connections), or a username/password combination (spreading through legit tools).
Screenshot showing launch of malware on a remote machine using WMICLateral movement using EternalBlue & EternalRomance
The new ransomware can also spread using an exploit for previously patched SMB vulnerability CVE-2017-0144 (also known as EternalBlue), which was also exploited by WannaCrypt to spread to out-of-date machines. In addition, Petya also uses a second exploit for CVE-2017-0145 (also known as EternalRomance and still fixed by the same bulletin).
We’ve seen Petya attempt to use these exploits by generating SMBv1 packets (which are all XOR 0xCC encrypted) to trigger these vulnerabilities at the following address of the malware code:
These two vulnerabilities were leaked by a group called Shadow Brokers. However, it is important to note that both of these vulnerabilities have been fixed by Microsoft since March 14, 2017.
Machines that are patched against this exploit (with security update MS17-010) or have disabled SMBv1 are not affected by this particular spreading mechanism. Please refer to our previous blog for details on these exploits and how modern Windows 10 mitigations can help to contain similar threats.Encryption
This ransomware’s encryption behavior depends on the malware process privilege level and the processes found to be running on the machine. It does this by employing a simple XOR-based hashing algorithm on the process names, and checks against the following hash values to use as a behavior exclusion:
- 0x2E214B44 – if a process with this hashed name is found running on the machine then the ransomware will not infect the MBR
- 0x6403527E or 0x651B3005 – if these hashes of process names are found, the ransomware will not carry out any of its network-related actions (such as attempting to exploit the SMBv1 vulnerability)
This ransomware then writes to the master boot record (MBR) and then sets up the system to reboot. It sets up schedule tasks to shut down the machine after at least 10 minutes past the current time. The exact time is random (GetTickCount()). For example:
schtasks /Create /SC once /TN “” /TR “<system folder>\shutdown.exe /r /f” /ST 14:23
Upon successfully modifying the MBR, it displays the following fake system message, noting that your drive contains error and shows the fake integrity checking:
It then displays this ransom note:
Only if the malware is running with highest privilege (i.e., with SeDebugPrivilege enabled), it tries to overwrite the MBR code.
This ransomware attempts to encrypt all files found on fixed drives with the following extensions in all folders, except for C:\Windows:.3ds .7z .accdb .ai .asp .aspx .avhd .back .bak .c .cfg .conf .cpp .cs .ctl .dbf .disk .djvu .doc .docx .dwg .eml .fdb .gz .h .hdd .kdbx .mail .mdb .msg .nrg .ora .ost .ova .ovf .pdf .php .pmf .ppt .pptx .pst .pvi .py .pyc .rar .rtf .sln .sql .tar .vbox .vbs .vcb .vdi .vfd .vmc .vmdk .vmsd .vmx .vsdx .vsv .work .xls .xlsx .xvd .zip
It uses file mapping APIs instead of a usual ReadFile()/WriteFile() APIs, shown in the following code snapshot:
Unlike most other ransomware, this threat not append a new file name extension to encrypted files. Instead, it overwrites the said files.
The AES key generated for encryption is per-machine and it gets exported and encrypted using the embedded 800-bit RSA public key of the attacker.
Embedded RSA public key
Code exporting the per machine AES 128 bit key and encrypting it using embedded RSA public key during export
The unique key used for files encryption (AES) is added, in encrypted form, to the README.TXT file the threat writes under section “Your personal installation key:”.
Beyond encrypting files, this ransomware also attempts to overwrite the MBR and the first sector of the VBR. If the malware is run with SeShutdownPrivilege or SeDebugPrivilege or SeTcbPrivilege privilege, it overwrites the MBR of the victim’s machine. It directly accesses the drive0 \\\\.\\PhysicalDrive0 as described in the following code snapshots:
MBR encryption pseudo code:
Encrypting the first sector of VBR:
After encryption, it drops a text file called README.TXT with the following text:
This ransomware also clears the System, Setup, Security, Application event logs and deletes NTFS journal info.Detection and investigation with Windows Defender Advanced Threat Protection
Windows Defender Advanced Threat Protection (Windows Defender ATP) is a post-breach solution and offers by-design detections for this attack without need of any signature updates. WDATP sensors constantly monitor and collect telemetry from the endpoints and offers machine-learning detections for common lateral movement techniques and tools used by this ransomware, including for example the execution of PsExec.exe with different filename, and the creation of the ‘perfc.dat’ file in remote shares (UNC) paths.
Today, without the need of additional updates, an infected machine may look like this:
The second alert targets the distribution of the ransomware’s dll file over the network. Clicking into this event provides helpful information during investigation as it includes the User context which was used to move the file remotely. This user has been compromised and could represent the user associated with patient-zero:
With Windows Defender ATP, enterprise customers are well-equipped to quickly identify Petya outbreaks, investigate the scope of the attack, and respond early to malware delivery campaigns.Protection against this new ransomware attack
Keeping your Windows 10 up-to-date gives you the benefits of the latest features and proactive mitigations built into the latest versions of Windows.
As another layer of protection, Windows 10 S only allows apps that come from the Windows Store to run. Windows 10 S users are further protected from this threat.
We recommend customers that have not yet installed security update MS17-010 to do so as soon as possible. Until you can apply the patch, we also recommend two possible workarounds to reduce the attack surface:
- Disable SMBv1 with the steps documented at Microsoft Knowledge Base Article 2696547 and as recommended previously
- Consider adding a rule on your router or firewall to block incoming SMB traffic on port 445
As the threat targets ports 139 and 445, you could block any traffic on those ports to prevent propagation either into or out of machines in your network. You can also disable remote WMI and file sharing. These may have large impacts on the capability of your network, but may be suggested for a very short time period while you assess the impact and apply definition updates.
Windows Defender Antivirus detects this threat as Ransom:Win32/Petya as of the 22.214.171.124 update. Windows Defender Antivirus uses cloud-based protection, helping to protect you from the latest threats.
For enterprises, use Device Guard to lock down devices and provide kernel-level virtualization-based security, allowing only trusted applications to run, effectively preventing malware from running.
Monitor networks with Windows Defender Advanced Threat Protection, which alerts security operations teams about suspicious activities. Download this playbook to see how you can leverage Windows Defender ATP to detect, investigate, and mitigate ransomware in networks: Windows Defender Advanced Threat Protection – Ransomware response playbook.Resources
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
Next-generation ransomware protection with Windows 10 Creators Update: https://blogs.technet.microsoft.com/mmpc/2017/06/08/windows-10-creators-update-hardens-security-with-next-gen-defense/Indicators of Compromise
Network defenders may search for the following indicators:
In environments where command-line logging is available, the following command lines may be searched:
- Scheduled Reboot Task: Petya schedules a reboot for a random time between 10 and 60 minutes from the current time
- schtasks /Create /SC once /TN “” /TR “<system folder>\shutdown.exe /r /f” /ST <time>
- cmd.exe /c schtasks /RU “SYSTEM” /Create /SC once /TN “” /TR “C:\Windows\system32\shutdown.exe /r /f” /ST <time>
This may be surfaced by searching for EventId 106 (General Task Registration) which captures tasks registered with the Task Scheduler service.
- Lateral Movement (Remote WMI)
- “process call create \”C:\\Windows\\System32\\rundll32.exe \\\”C:\\Windows\\perfc.dat\\\” #1”
In environments where NetFlow data are available, this ransomware’s subnet-scanning behavior may be observed by looking for the following:
- Workstations scanning ports tcp/139 and tcp/445 on their own local (/24) network scope
- Servers (in particular, domain controllers) scanning ports tcp/139 and tcp/445 across multiple /24 scopes
Windows Defender Research