from Securelist / All Updates
Operating system security is one of Microsoft’s priorities. The developers of the new generation of Windows have vigorously responded to the most significant and relevant threats that target the Windows platform by developing numerous security technologies that were previously available only in third-party solutions. The system has become better protected, making the life of cybercriminals more difficult.
Nevertheless, in some cases, the tools provided by the operating system are not sufficient – the developers have had to make compromises in a number of areas, which has negatively affected system security and makes it necessary to use third-party IT security tools.
Because it is so widespread, Windows has been, and remains, the target of choice for cybercriminals of all stripes. Each new version is researched thoroughly by thousands of blackhats in search of new moneymaking opportunities. Whitehats, for whom Windows is the main battleground in their fight against the bad guys, also explore it. Naturally, Kaspersky Lab always carries out a painstaking analysis of all changes introduced by Microsoft to the security system in order to provide its users with the best possible protection against cyberthreats.
This review consists of three parts devoted to the most prominent new Windows 10 features that affect security. These are the Microsoft Edge browser, virtualization-based security and an updated built-in anti-malware solution called Windows Defender. All of these features have brought new capabilities to the Windows security system, but, unfortunately, they also come with some weaknesses of their own. In this paper, we use examples to demonstrate how Windows 10 protection technologies work and how they can be complemented by third-party solutions to improve system security.
Microsoft Edge
The latest browser, Microsoft Edge, is intended to replace Internet Explorer. It is included in Windows 10 as the default browser. The company has worked hard to implement numerous new features, some of which are security-related.
Content Security Policy and HTTP Strict Transport Security technologies were introduced to combat cross-site scripting attacks. These technologies are designed not only to lower the chances of a successful attack but also to notify the web service’s owner about the attempt to carry it out.
Microsoft has also come up with ways to protect Edge against exploits, which were the curse of Internet Explorer. Now, by using containers and separating content handling operations into different processes, exploiting vulnerabilities has been made much more difficult. Finally, integration with SmartScreen should prevent users from visiting sites with malicious content.
In addition to supporting new technologies, the security of Edge has been enhanced by retiring vulnerable old ones. The browser no longer supports VML, BHO and ActiveX, which are used by a multitude of advertising apps and malicious browser add-ons.
When it comes to technologies, however, the real security level is only tested by real-world attacks. It is well known that Banker Trojans usually carry out MiTB (Man-in-The-Browser) attacks, injecting their code in the browser process and hooking networking functions, which enables malicious users to perform online banking operations in the name of someone using an infected computer.
Attacks of this type require a browser-specific, and often version-specific, approach, which is why banker Trojans are updated with such regularity. In November 2015, it was reported that the Dyreza Trojan had been given functionality that enabled it to attack Microsoft Edge. However, the activity of that particular botnet fell to zero soon afterwards: updates ceased to be released and the command-and-control servers were taken offline.
Another infamous banker Trojan, Kronos, caught up with Edge in 2016. We checked out its capabilities on a Windows 10 virtual machine. In the code of the new Kronos version we found a function that checks the name and checksum of a process, as well as the hashes of the functions hooked by the malware.
Function that identifies the browser based on the checksum of its process name
Kronos checks the process’s name, converts the string to lower case, calculates its checksum and squares it. The hash obtained in this way is checked against a table – if it is found there, the Trojan will attempt to hook the functions it needs in the browser’s process.
Browser process names known to the Trojan:
| Process name | Checksum |
| iexplore.exe | 0x64302d39 |
| chrome.exe | 0x05d66cc4 |
| firefox.exe | 0x39ace100 |
| opera.exe | 0x9420a4a1 |
| microsoftedge.exe | 0x9b6d5990 |
| microsoftedgecp.exe | 0x949b93d9 |
In order to perform malicious operations that will make money for its owners, Kronos hooks the functions that create and send HTTP requests in the Wininet library.
List of wininet.dll functions hooked:
| API function | Hash |
| HttpOpenRequestA | Y7D4D7E3T2T2A4U3 |
| HttpQueryInfoA | C8C0U1A2G4G5Y2B5 |
| HttpSendRequestA | Y4U1P2F2G7T2A4U3 |
| InternetCloseHandle | A7S3H3X3D5Y7T7F7 |
| InternetConnectA | H0S6D5Q7E8P3P6U5 |
| InternetCrackUrlA | E6F2A3S8Y4C7D5A5 |
| InternetOpenA | B7P8P7T4E3U2H5A5 |
| InternetQueryOptionA | C1Y0B7E2B0P2P3T7 |
| InternetReadFile | D6X2S6E3Q3C5B5X2 |
| InternetSetOptionA | X3Y6Q2T7Q5Q2A5X6 |
Kronos hooks functions using the splicing method, adding a JMP (unconditional jump) instruction at the beginning of the code. Since the malicious code injected into the browser is loaded as a shellcode rather than a library, the Mitigation Policy enabled in the browser will not block it from being executed.
InternetReadFile function hook in MicrosoftEdgeCP.exe
Handler for the hooked function
Successfully hooking these functions enables the Trojan to inject data into web pages. It also enables Kronos to get information about the user, the user’s credentials and bank account balance, to redirect the user to phishing sites, or to include additional entry fields to the bank’s legitimate page (enabling the malware to find out the user’s reply to the secret question, credit card number, date of birth or phone number).
Web injection on a bank’s page
Note that Kronos can only attack Edge on the 32-bit version of Windows 10. But this is not a fundamental constraint – there are now bankers that work with the 64-bit version of Edge, as well.
In the beginning of the year, a new modification of the infamous Gozi banker appeared. Among other things, it was designed to carry out an MiTB attack against Edge under a 64-bit version of Windows 10. The Trojan injects its code into the RuntimeBroker.exe process, launches the browser on behalf of that process and injects its code into the browser’s own processes.
Part of the function that checks process names for injection
As in the case of Kronos, the injected code hooks functions that create and send HTTP requests. However, instead of splicing, it substitutes IAT pointers as well as function addresses in the Export Table.
Part of the function that checks process names to set the right hooks for each browser
HttpSendRequestW hook set by Gozi banker in the MS Edge browser
Note that Windows Defender successfully blocks the current versions of Kronos and Gozi. Nevertheless, new malware and adware will emerge that is capable of using Edge for its own purposes.
Virtualization-Based Security
In the corporate version of Windows 10, Microsoft has implemented a new approach to security that is based on Microsoft Hyper-V, a hardware-assisted virtualization technology. The new paradigm, called Virtualization Based Security (VBS), is based on a whitelisting mechanism that only allows applications that are on the trusted-application list to be executed, and on isolating the most important services and data from other components of the operating system.
VBS depends on the platform and CPU features, which means that the technology needs the following to operate:
- Windows 10 Enterprise.
- UEFI firmware v2.3.1+ with Secure Boot support.
- CPU supporting Intel VT-x/AMD-V virtualization features.
-
- 64-bit architecture.
- CPU with support for the Second Level Address Translation (SLAT) mechanism.
- Intel VT-d/AMD-Vi IOMMU (optional).
- Ability to block some features of the UEFI firmware and its secure updating.
- TPM (optional).
Microsoft uses the Hyper-V hypervisor as its virtualization platform. The less code a hypervisor contains, the fewer attack vectors against it exist. In this aspect, the compactness of Hyper-V is very beneficial for security. Unlike previous Windows versions, the hypervisor starts not as a kernel-mode driver but in UEFI, at an early stage of the computer’s startup.
Hyper-V initialization procedure
In VBS, with the hypervisor active, each virtual CPU is assigned a Virtual Trust Level (VTL) attribute. Two attributes are currently used: VTL 1 (“Secure World”) and VTL 0 (“Normal World”). VTL 1 is more privileged than VTL 0.
Secure Kernel Mode or SKM (Ring 0, VTL 1) includes a minimal kernel (SK), a Code Integrity (CI) module and an encryption module. Isolated User Mode or IUM (Ring 3, VTL 1) includes several isolated services called Trustlets that are isolated not only from the external world but also from each other. In “Normal World” (VTL 0) mode, the traditional kernel, kernel-mode drivers, processes and services work according to the former rules.
Diagram describing the two worlds
When the hypervisor is active, physical RAM pages and their attributes are only controlled by the secure isolated kernel (SK). It can manipulate page attributes, blocking or allowing reading, writing or executing code on specific pages. This makes it possible to prevent execution of untrusted code, malicious modification of trusted application code, as well as to make leaking protected data more difficult.
In this architecture, the only component that controls the execution of any code in the system is the secure isolated Code Integrity (CI) module. The kernel from “Normal World” cannot set the attributes of kernel-mode physical pages.
Credential Guard
Credential Guard is one of the main functional blocks of VBS. It isolates secrets in such a way as to ensure that only trusted code has access to them. This helps to withstand direct memory access (DMA) attacks, as well as pass-the-hash and pass-the-ticket attacks.
System Information. Credential Guard and HVCI
We have tested the technology, attempting to get secret data using direct memory access. We used Mimikatz and Inception hacker tools for this. Nothing worked. These hacker tools were powerless against Credential Guard.
DMA attack using the Inception tool
Device Guard
The Device Guard technology that is part of VBS is the successor of Microsoft AppLocker. It controls the launching and execution of all code: executable files and dynamic libraries, kernel-mode drivers and scripts (e.g., PowerShell). This is based on a code integrity policy created by the system administrator that defines which software is regarded as trusted.
The main difficulty in using Device Guard is in creating a proper policy, which can be difficult even for experienced system administrators. Ideally, the procedure is as follows:
- Enable the necessary Windows 10 VBS mechanisms on a test computer.
- Prepare a master image of Windows OS.
- Install all the necessary software.
- Create a code integrity policy based on certain rules and leave it in audit mode for some time. During this time, software can be added or changed.
- Watch the event log for CI events.
- Perform any necessary policy adjustments, such as signing any software that is not signed.
- Consolidate the original policy with the version created while the policy was in audit mode.
- Disable audit mode in the code integrity policy, replacing it with enforced mode.
- Distribute the prepared policy to end users.
A code integrity policy defines the conditions for executing code both in user mode (User Mode Code Integrity or UMCI) and in kernel mode (Kernel Mode Code Integrity or KMCI). Secure loading of the Windows kernel itself is provided by the Secure Boot technology. The integrity policy needs to be maintained and updated based on the software requirements in place at a specific organization.
In addition to the integrity policy, there are other restrictions on executing code. A physical memory page gets the “executable” attribute only if the certificate is validated. Additionally, a kernel-mode page cannot have “writable” and “executable” attributes at the same time (the W^X restriction), which prevents most exploits and hooks from working in kernel mode. In the event of an attempt to modify the contents of a kernel mode page that has “readable” and “executable” attributes, this will lead to an exception. If it is not handled, Windows will stop and display a BSOD.
As a result, it is impossible to execute unsigned drivers, applications, dynamic libraries, UEFI modules and some script types when the hypervisor and all the security options, such as Secure Boot, TPM, IOMMU, and SLAT are active. Depending on settings, code that is signed but not trusted can also be blocked from being executed.
To protect the policy from unauthorized changes or substitution, Microsoft suggests that it should be signed using a certificate generated by the administrator. To remove a policy or change settings, another policy signed with the same certificate is required. If an attempt is made to remove a policy or ‘plant’ an unsigned policy, the operating system will not start.
Still, Device Guard is not perfect. Increased protection comes at a price – in the form of performance degradation. This is unavoidable due to the presence of a hypervisor. The convoluted process of creating, configuring and maintaining a code integrity policy can be considered a weakness of the technology. The options used by the policy are scattered across the operating system and cannot be managed through a single control panel. As a result, it is easy to make a mistake, leading to weaker protection.
Since Secure Boot plays a key role in this technology, the level of protection very much depends on the quality of UEFI code, which is developed by a third party over which Microsoft has no control. Finally, the absence of protection against exploits in user mode is disappointing.
Testing VBS
If malicious code makes its way onto a computer with VBS by taking advantage of a vulnerability, it will have to elevate its privileges to kernel mode to be able to attack the hypervisor, the “Secure World” or UEFI. We tried to do this using a signed and trusted kernel mode driver.
Kernel mode penetration testing results:
| Test | Result | Test | Result |
| W+X PE section .INIT | + (by design) | Allocate NP/P MEM, hack PTE manually | + (BSOD) |
| W^X PE section .INIT | + (as is) | R+X section, remove WP in CR0 | + (BSOD) |
| W+X PE section | + (no start) | Stack code execution | + (BSOD) |
| Allocate MEM, execute | + (BSOD) | Allocate MEM, hack MDL manually | + (BSOD) |
| R PE section, write, execute | + (BSOD) |
None of the attack methods that we tried was successful. Attacks based on changing Control Registers (CR0-CR8, EFER etc.) and Model-Specific Registers (MSR) did not work either – they all invariably ended in a Privileged Instruction exception (0xC0000096).
We also carried out some tests in user mode, trying to circumvent a code integrity policy in enforced mode. The objective was to execute an unsigned application or load an unsigned dynamic library into a trusted process. We were unable to do this directly, but we found a curious error in the Windows 10 preview release (10154).
The error lies in the fact that, although Device Guard checks whether an application, driver or library is signed, it does not verify that the signature is valid for the application signed with it. This makes it possible to extract a valid signature from any trusted application and insert it into any untrusted application – after this the system will consider the application to be trusted. So, by inserting a signature from another application, we were able to execute an untrusted application and to load an untrusted dynamic library.
We immediately reported the error to Microsoft and it was fixed within a few days. Windows 10 RTM (10240) does not include that error.
We also discovered a denial-of-service error that makes it possible to crash the system and cause a BSOD for the hypervisor from the user space with just one Assembler instruction. A fix for this error was included in Windows 10 TH3 (10586).
The hypervisor’s BSOD
Overall, Microsoft has done a great job in developing new security mechanisms. However, as in previous versions, there are still opportunities for attacks via the firmware. Another problem is that the system administrator needs to be highly qualified to configure protection properly. In the event of faulty configuration or loss of the private certificate, all protection becomes useless. In addition, there is no protection against user-mode vulnerabilities. It is also important to keep in mind that VBS is only available to users of the corporate Windows 10 version.
We have notified Microsoft of all the vulnerabilities discovered during testing.
Built-in Anti-Malware Protection in Windows
Let’s have a look at the Windows component that protects the system against malware in real time. It is enabled by default and, for users who do not install third-party anti-malware solutions, it is the main Windows IT security tool.
The principal purpose of built-in protection is to prevent the installation and execution of malware. It scans files and active processes in real time, identifying those that are malicious by checking them against a regularly updated signature database. In most cases, this protection is sufficient.
However, if you are an active Internet user and often perform critically important operations on your computer – such as managing your bank accounts via online banking – you need multi-tier protection. Even the best anti-malware solution can miss new, as yet unknown malware. In this case, only additional layers of protection can save the day by preventing a Trojan from carrying out malicious activity in the system.
We did some research and found a few real-life examples demonstrating that built-in protection may not be sufficient.
Keystroke Interception
Some banker Trojans intercept data entered on the keyboard to steal the user’s online banking account. Examples of such malware include Qadars, Zbot and Cridex. Many anti-malware solutions, including Kaspersky Internet Security, have a component that detects and blocks attempts by programs to intercept the sequence of keypresses. In some cases, this can be enough to prevent criminals from making money at the victim’s expense, even if they have managed to infect the computer.
We tested the response of built-in protection to keystroke logging with the help of a test application that uses the GetAsyncKeyState WinAPI function (this method is similar to the one used in the latest MRG testing). We were able to intercept the user’s login and password for a PayPal account with Windows Defender enabled.
Logging the user credentials while entering a PayPal account
Unauthorized Web Camera Access
In the next test, we tried to gain unauthorized access to the web camera. This functionality has been increasingly used in Trojans and other hacker tools in the past years. The fact that a surveillance module using the web camera is included in the AdWind Trojan is a telling example of the popularity of this functionality among cybercriminals.
Monitoring victims using their own web cameras can provide a wealth of information about them, which can later be used to make money illegally – for example, by blackmailing a victim with intimate videos.
Some anti-malware solutions can control application access to the camera. In real life, there are practically no situations in which a legitimate application could need to use the camera without notifying the user, which is why providing such notifications is a convenient and widely accepted practice. The user can decide in each specific case whether the application really needs to use the camera or whether this is suspicious activity that should be blocked.
Our test application used a publicly available library called OpenCV (which is what the Rover Trojan does, to give one example). A simple Python script captured video from the web camera and displayed it in a separate window. This means that an application was able to intercept video from the web camera on a Windows 10 machine with protection enabled, without the user being notified of this in any way.
Capturing the screen with a script
Control of Drive-By Downloads
Another problem that is among the most serious issues faced by Windows users is the numerous exploits that can be used to infect the system via vulnerabilities in various applications. We tested the built-in protection with one of the latest exploits for the CVE-2016-1019 vulnerability in Adobe Flash Player.
The exploit’s file is an SWF object compressed using the ZLIB algorithm.
The flash exploit
In this form, the file is recognized by the Windows Defender and quarantined.
Successful detection of a packed exploit
However, if the file is decompressed into the original SWF, the security system will miss it.
Moreover, a compressed file that was detected on the hard drive is downloaded from websites in drive-by attacks and successfully executed from the browser’s context. If a vulnerable version of Adobe Flash Player is installed in the system, an infection can occur, because Windows Defender does not include a drive-by download control component.
Successful download of a Flash exploit that was previously detected on the hard drive
Conclusion
Today, a multi-tier approach is required to provide reliable protection for user systems, combining standard detection methods (signature-based analysis, behavioral analysis, etc.) with additional modules designed to detect attack techniques commonly used by cybercriminals.
As our brief review has demonstrated, in some cases the IT security technologies built into Windows 10 are not sufficient for full-scale protection against malicious attacks. As in previous Windows versions, all possible attack vectors should be blocked using dedicated Internet Security class security solutions.
