AppContainer’s Protecting Effects on Vulnerability-Exploited Web Browsers
Our previous article “Enhanced Protected Mode in Internet Explorer” (published in August 2015) introduced that running the browser with Enhanced Protected Mode in 64-bit mode is effective in the protection against attacks exploiting vulnerabilities. This entry will verify the effect of “AppContainer” against attacks, which is another function related to Enhanced Protected Mode for Windows 8 and later.
AppContainer and Web Browser
AppContainer is a sandbox which runs applications in an isolated environment. Access from AppContainer to an external environment is strictly limited. The biggest difference from Protected Mode (not Enhanced; access control based on Integrity Level) is that even reading is basically prohibited in addition to writing. 
The following Web browsers run within AppContainer:
- Edge for Windows 10
- Internet Explorer 11 in Modern UI (Metro) for Windows 8.1 (Immersive browser)
Flash Player which is integrated in Windows 8.1 and Windows 10 is also compatible with AppContainer.
Internet Explorer 11 for Windows 8.1 Desktop and Windows 10 do not run in AppContainer by default. They can run in AppContainer by selecting “Enable Enhanced Protected Mode” in Internet Options. Internet Explorer 11 on Windows 64-bit mode has an option to “Enable 64-bit processes for Enhanced Protected Mode”, however, this alone does not enable Enhanced Protected Mode. The browser will run in 64-bit mode outside AppContainer unless you enable Enhanced Protected Mode in Internet Options. When Enhanced Protected Mode or 64-bit mode is enabled, add-ons that are not compatible with AppContainer or 64-bit mode will not run. Also, even if Enhanced Protected Mode is enabled, it gets disabled when Protected Mode is disabled, for instance in Trusted Sites Zone.
Tests with Malware Samples Used in Actual Attacks
We conducted some tests to see the effect of AppContainer by using malware samples used in actual attacks exploiting Flash Player vulnerability. We used two kinds of samples. For one of them, we also tested by making modifications to the sample to see potentially derived methods. So, we conducted tests for the following three cases:
- Test 1: See if the sample, which creates and launches executable files by exploiting the vulnerability APSB15-18, runs
- Test 2: Modify the sample in Test 1 so that it launches executable files via DLL, and see if it runs
- Test 3: See if the sample, which executes Windows commands and scripts by exploiting the vulnerability APSB16-15, runs
The tests were conducted using Internet Explorer 11 for Windows 10, and we observed the difference in behaviour depending on the configuration of Enhanced Protected Mode. We have confirmed that the same results were obtained for Windows 8.1 and 10.
Test 1 – Creating and Launching Executable Files
First, as a simple case, we tested AppContainer’s effect by checking if malware is successful in creating and launching executable files with different Enhanced Protected Mode configuration. Table 1 describes the behaviour of the sample after successfully exploiting the vulnerability APSB15-18.
|Internet Options||Creating Malware’s Executable Files||Launching the Created Executable Files|
|Default (Enhanced Protected Mode disabled)||Successful||Successful|
|Enhanced Protected Mode enabled (AppContainer)||Successful||Failed|
|Enhanced Protected Mode enabled + Trusted Websites (Protected Mode disabled)||Successful||Successful|
Whether or not Enhanced Protected Mode is enabled, executable files were successfully created. However, when Enhanced Protected Mode is enabled, it fails to launch the file due to an API error. This means that infection will not occur under Enhanced Protected Mode. However, even if Enhanced Protected Mode is enabled, it is disabled in Trusted Sites Zone, and thus infection cannot be prevented.
Test 2 – Launching Executable Files via DLL
The sample used in Test 1 was a simple one which creates and launches executable files. There could be other kinds of malware using more sophisticated methods. As an example, we took advantage of the fact that DLL can also be loaded in AppContainer, and modified the malware to launch executable files indirectly via DLL. We tested to see if executable files could launch this way (shown in Table 2).
|Internet Options||Launching Malware’s Executable Files|
|Default (Enhanced Protected Mode disabled)||Suspended (Launches if allowing the warning pop-up)|
|Enhanced Protected Mode enabled (AppContainer)||Suspended (Launches if allowing the warning pop-up)|
|Enhanced Protected Mode enabled + Trusted Websites (Protected Mode disabled)||Successful (No warning pop-up)|
Except for the case where Protected Mode is disabled for Trusted Sites Zone, the warning pop-up in Figure 1 appears:
If you choose “Allow” on the pop-up, even under Enhanced Protected Mode, malware is executed without AppContainer’s operation restriction. Please be cautious not to casually allow this message.
Figure 2 to 4 show the Process Explorer screen when executable files were successfully launched. In Figure 3, the “Integrity” for processes running within AppContainer is shown as “AppContainer” instead of its actual Integrity Level. Although the parent-child relationship for processes shown in Figure 2 and 3 are different from that of Figure 4, the process calling for API which launches the malware’s executable file is “iexplorer.exe”, which is listed in the second row from the bottom (iexplorer.exe of child process) in all these figures. Therefore, unlike the case where the malware’s executable file was launched without a warning pop-up and infection occurred (Figure 4), the launched process (sample.exe) will not be a child process of the process calling for API (iexplorer.exe) when execution is allowed at the warning pop-up (Figure 2 and 3).
Test 3 – Launching Windows Command
The last test used samples we recently observed in June 2016, Flash File (SWF) sample of Neutrino Exploit Kit. The sample attempts to create and execute scripts to download and launch malware by leveraging vulnerability APSB 16-15. cmd.exe (Windows command processor) is used to create the scripts, and WScript.exe (Windows Script Host) is used to execute the scripts for downloading and launching the malware. The test results are described in Table 3.
|Internet Options||Launching cmd.exe||Creating Scripts||Downloading and Launching|
|Default (Enhanced Protected Mode disabled)||Successful||Successful||Successful|
|Enhanced Protected Mode enabled (AppContainer)||Successful||Failed||-|
|Enhanced Protected Mode enabled + Trusted Websites (Protected Mode disabled)||Successful||Successful||Successful|
In any case, cmd.exe is successfully launched. Process Explorer at this stage is illustrated in Figure 5. Unlike Test 1 or 2, programs are launched within AppContainer.
As shown, launching programs within AppContainer does not necessarily fail, and Windows command and others can be launched. In this situation, a warning screen as in Figure 1 will not appear. However, functions of the command are limited, since it takes over the conditions within AppContainer. This sample is not compatible with the limited command functions, and so cannot create scripts. Therefore, infection will not occur under Enhanced Protected Mode.
Even if a vulnerability is leveraged, we have verified that further stage of attack can be prevented by running the Web browser within AppContainer. Through access restriction against malicious codes, you can expect to limit the range of affected area by an attack, or even reduce the risk of being infected by malware.
Yet there is something to note regarding this effect. Since AppContainer is just a system to run applications (e.g. Web browsers) in an isolated environment, it cannot prevent attacks targeting information that Web browsers handle. For example, it cannot prevent actions to steal information from memory, such as password hash of proxy servers with authentication. If such information is stolen, it could be used for other attacks. We can utilise AppContainer, but we recommend that users do not rely on it too much – and make sure that basic security measures are in place, such as to avoid using a single password for multiple Web services.
Thank you for reading.
- Kenichi Imamatsu
(Translated by Yukako Uchida)
 FFRI - Windows 8 Security (Japanese)
 Microsoft - AppContainer Isolation
 IBM - A Peek into IE's Enhanced Protected Mode Sandbox
 Black Hat - diving into ie 10's enhanced protected mode sandbox