Dec 05, 2016

Evidence of Attackers’ Development Environment Left in Shortcut Files

A shortcut file, also referred to as a shell link, is a system to launch applications or to allow linking among applications such as OLE. As we introduced in a previous blog post “Asruex: Malware Infecting through Shortcut Files”, shortcut flies are often used as a means to spread malware infection. Generally, shortcut files contain various types of information including the dates and environment that the shortcut file was created. This also applies to shortcut files created by attackers. By extracting and correlating information recorded in the shortcut files used in attacks, it is possible to identify the shortcut files that may have been created by the same attacker.

This blog entry explains how to classify an attack subject through information recorded in the shortcut files used in attacks. Furthermore, the article will also introduce trends in the system environments used by the latest attackers, which JPCERT/CC learned through statistical analysis of information gained from a number of shortcut files used in attacks.

Information Contained in Shortcut Files

Among the various types of information recorded in shortcut files, the following is the list of items that JPCERT/CC focused on for the purpose of this analysis (For the shortcut file format, please refer to the information released by Microsoft [1]).

  • Code page number: Number describing the character encoding configured in the OS where the shortcut file was created
  • ŸVolume serial number: Volume serial number of the drive where the shortcut file was located at the time of creation
  • ŸNetBIOS name: Computer name of the machine where the shortcut file was created
  • ŸMAC address: MAC address of the machine’s network adapter where the shortcut file was created

(Part of the DroidBirth field (GUID value) may contain the MAC address [2]. If neither network nor adapter exists, this will be a random value instead of a MAC address).

JPCERT/CC has confirmed that these types of information are being left in many of the shortcut files used in actual attacks. If these are available, it is possible to presume the system environment that the attackers use.

The following section explains the results of the study and classification of 83 shortcut files that JPCERT/CC collected from actual attack cases.

Classification of Shortcut Files Used in Actual Attacks

Among the above-listed information that shortcut files contain, the following 3 are useful in terms of identifying the system environment used when the shortcut file was created.

  • Volume serial number
  • NetBIOS name
  • MAC address

Shortcut files that have the same information in the above items are likely to be created by the same attacker. The image below illustrates the similarity of the shortcut files in terms of the 3 types of information. The nodes show either a shortcut file, MAC address, NetBIOS name or volume serial number, and represented in different colours – for example gray for shortcut file. For the above 3 types of information, the values are connected to the corresponding nodes with a line if the respective values are contained in the shortcut file.

Figure 1: Shortcut file clustering

Shortcut files used in attacks may contain the same volume serial number, NetBIOS name and MAC address and form a cluster. For example, the shortcut files which infect Asruex (obtained by JPCERT/CC) contained the following information:

  • Volume serial number: 4ec5-2eee
  • NetBIOS name: pc1-pc
  • MAC address: d0:50:99:27:d0:fc
Figure 2: The cluster of shortcut files infecting Asruex

In this way, multiple shortcut files may be correlated by comparing volume serial number, NetBIOS name and MAC address in the shortcut file. The coming section demonstrates the environments that attackers used for creating shortcut files, which can be seen from the analysis of shortcut file information.

Attackers’ Environment Identified from Shortcut Files

The first 3 bytes of MAC address are allocated for the Organizationally Unique Identifier (OUI), which shows the vendor of the product. Vendor names that can be identified from the 3 bytes of the MAC address in the shortcut files used in attacks are listed in Table 1.

Table 1: Results of first 3 bytes of MAC address
First 3 bytes of MAC addressVendor NameNumber
00-0c-29 VMware, Inc. 22
d0-50-99 ASRock Incorporation 15
00-50-56 VMware, Inc. 10
44-37-e6 Hon Hai Precision Ind.Co.Ltd 2
00-15-5d Microsoft Corporation (Hyper-V) 1
08-00-27 CADMUS COMPUTER SYSTEMS (VirtualBox) 1
20-c9-d0 Apple Inc. 1

It is clear that attackers tend to use a virtual environment for creating files. Many malware analysts use a virtual environment for analysis so that the actual environment does not get infected with malware. For the same reason, malware creators seem to use a virtual environment as well.

We also searched for code page information of shortcut files used in attacks and identified that the information remained in 22 of the artifacts. All of them had the same code page 936, which indicates simplified Chinese language.

For other noteworthy results taken from information left in the shortcut files, please see Appendix A.


Information on attackers’ system environment remains in many shortcut files used in attacks. By utilising the information, classification of the attack subject can be easily conducted. When analysing shortcut files used in attacks, there may be new findings by focusing not only on malicious scripts that attackers intentionally created, but also on evidence that they left unintentionally in the shortcut files.

Thank you for reading – see you soon.

- Shusei Tomonaga

(Translated by Yukako Uchida)


[1] Microsoft - [MS-SHLLINK]: Shell Link (.LNK) Binary File Format

[2] IETF - RFC 4122 - A Universally Unique IDentifier (UUID) URN Namespace

Appendix A: List of information contained in shortcut files used in attacks
Table A-1: List of NetBIOS name (Top 10)
NetBIOS nameNumbers
pc1-pc 15
host-473640c404 8
kitchen 8
lenovo-60ff5341 4
seasbo 4
john-a00bf62302 3
user-1aecf0882a 3
google-329ea5f8 2
microsof-92e057 2
win-qn3bc0dqd7e 2

Table A-2: List of volume serial number (Top 10)
Volume serial numberNumbers
4ec5-2eee 15
3ee4-c3c3 8
78e5-aa39 8
602c-9a8a 7
10bc-fa5f 4
6659-b92f 4
b017-3d5c 4
ac5c-ff44 3
b45e-f641 3
365f-818f 2

Table A-3: List of MAC address (Top 10)
MAC addressNumbers
d0:50:99:27:d0:fc 15
00:50:56:c0:00:08 11
88:3b:a8:bd:d5:37 8
ab:33:5b:4f:99:a0 8
00:0c:29:2c:21:be 3
00:0c:29:34:86:a9 3
00:0c:29:ea:a9:9c 3
00:0c:29:cb:0b:aa 2
44:37:e6:84:72:77 2
00:0c:29:20:d2:d9 1

Nov 16, 2016

APCERT Annual General Meeting & Conference 2016 in Tokyo and JPCERT/CC’s 20th Anniversary

Hi all, this is Yuka from Global Coordination Division and also serving as APCERT Secretariat.

We are happy to announce that we have just finished one of the big tasks for this year – the host of APCERT Annual General Meeting & Conference 2016, which was held on 24-27 October at Royal Park Hotel in Tokyo. After the official establishment of APCERT in 2003, its annual conference had never been held in Tokyo. There was, though, a meeting in 2002 as Asia Pacific Security Incident Response Coordination Conference (APSIRC; the predecessor of APCERT) where forming a community for CSIRTs in the Asia Pacific region was discussed. Strangely enough, the Conference in 2002 was also held in the same hotel – we actually booked the venue without knowing the fact. We were so thrilled to know about the chance.

The Conference was run for four days:

24 Oct: Working Group Meetings, Team Building, Welcome Cocktail

25 Oct: TSUBAME Workshop, CyberGreen Workshop, Steering Committee Meeting

26 Oct: Closed Conference, Annual General Meeting, Gala Dinner

27 Oct: Open Conference

(Photo taken during TSUBAME Workshop – trainees working on some hands-on exercise)

From Day 1 through to 3, sessions for APCERT members and invited guests were conducted, and Day 4 was an open session including the general public. Altogether we had APCERT Operational Members from 23 teams of 18 economies in Asia Pacific, Supporting Members, global partners, sponsors and some local guests – which counted up to approximately 200 people. The Conference was themed “Borderless Cooperation, Seamless Action – Towards a Cleaner, Greener Cyber Space –“, which indeed reflects the aim of this community. The Conference program on the 27th was arranged based on “Call For Papers”, with presentations which covered a wide range of topics on recent technical trends and concluded with a panel discussion on CSIRT operations as below.

- IoT Threat and IoT Botnet

- Protecting CNII against Malware Threats: A Coherent Response through Cooperation Amongst OIC Countries

- APT Campaign Targets Japanese Critical Infrastructure

- Ransomware Tracking and AP Region Footprint

- Who’s That Knocking on My Back Door: A Jboss Case

- Sophisticated Financial Fraud Malware (Mobile) in Korea

- Collaborative Research for Development of CSIRTs in Vietnam

- Best Practices and Common Missteps in Responding to Major Incidents

- Engaging the ISPs in Effective National Network Abuse Handling

(Programs available here:

(Team JPCERT/CC after the event – Photo by our colleague)

What made this event special was not only the fact that it was hosted in Tokyo for the first time as APCERT, but also that it coincided with the 20th anniversary for JPCERT/CC.

Being established in October 1996, as one of the oldest CSIRTs in the world, JPCERT/CC has been contributing in creating a safer cyber security environment both in Japan and across the globe. To look back over the activities from internal and external perspectives, a symposium was held on 28 October inviting local partners. The symposium contained presentations from JPCERT/CC staff and partners providing the history of activities and ideas for future plans, which was followed by a social cocktail.

What these two events brought us is the fact that JPCERT/CC has been supported by various partners locally and globally. For the anniversary event, some of our foreign counterpart organisations kindly sent us video messages with the words of celebration. From local communities, we received feedbacks about our activities, some positive evaluations and also encouragement. Indeed, since JPCERT/CC is a “Coordination Center”, our activities require coordination with various entities, and creating a safer cyber space cannot be accomplished without the support of such local and global partners. We hope that both events were good opportunities to show our gratitude for the special partnership for the past 20 years, and we look forward to continuing and developing the relationship for the next 10 years and more.

Thanks for reading.

- Yukako Uchida

Nov 10, 2016

APT workshop and Log analysis training in Jakarta

Selamat pagi!! This is Mariko and Wataru from Watch and Warning Group.

We were in Indonesia for APT (Advanced Persistent Threat) workshop and log analysis training from October 4th to 6th. This was part of JICA’s (Japan International Cooperation Agency) project on “Capacity building for Information security”, which aims to provide practical trainings for information security staff in the ASEAN region.

At first we were a little nervous since we had never conducted trainings overseas, and moreover, there were some new training contents which we hadn’t taught even in Japanese. So we rehearsed even on the airplane. The climate was like summer in Japan, but we spent most of the time in the training room. That was comfortable!!

The first day had come.

Trainees were from Indonesia, Brunei, Cambodia, Laos, Myanmar, Timor Leste and Vietnam. We talked about the overview of APT, especially log conservation based on the APT Guideline. JPCERT/CC published the APT Guideline on our website in 2015, but the guideline is only available in Japanese at this time.

The trainees listened to us seriously and gave us a lot of questions and comments. Discussions included how to conserve logs in a secure way at low cost, such as by using syslog server or SIEM, etc. In addition we recommended to prioritize the logs to conserve.

After that Wataru showed a simple demo of malware infection to help trainees understand typical attack methods.

All trainees worked on the training seriously

On the second day, we held a log analysis hands-on for detecting traces of attacks. Through the hands-on, trainees experienced analyzing sample logs of proxy servers and Active Directory based on an APT attack scenario by using our log-analysis tool.

We also arranged some group discussions so that trainees could have opportunities to discuss with participants from different cultures. Everyone discussed actively, and reached almost perfect answers. We were deeply impressed by their enthusiasm and cooperativeness.

Heated discussion at hands-on training

After that we showed a demo of an attack against Active Directory in order to inform threats and mitigations of the attack. The demo was based on an attack scenario sometimes observed in APT attacks: conduct privilege escalation by leveraging vulnerability in Active Directory and creating a Golden ticket. 

It seemed that some trainees found the demo a little complicated since about half of them weren't familiar with Active Directory. However we were able to draw their interest and some said they became interested in Golden ticket and mimikatz (attack tool against Windows).

We are very glad if the trainees recognized the importance of log analysis and protecting Active Directory through this hands-on. Also there were some feedbacks that trainees wanted to learn more details or use our log-analysis tool, so we’d like to consider deepening and providing such hands-on and demos to various countries.

We were deeply impressed by their great answers

On the last day we conducted a training on network forensics using Wireshark. We prepared various packet data and several questions from basic to advance. The trainees discussed, helped each other and gave us almost perfect answers. Also we showed demos of attacks leveraging famous vulnerabilities: ShellShock and Apache Struts.

After all sessions, we got feedbacks from trainees through questionnaires. Many took interest in all sessions, but especially hands-on and network forensics (advanced) got favorable feedbacks. We believe the discussions and support for each other stimulated their interests and curiosities. As a result they were able to learn deeply.

At night, a banquet was held and all attendees talked about various topics such as security issues in their own countries with nibbles and drinks. That was a great time for all of us. We are very glad if trainees spent a good time during the training, and also hope that the rest of the trainings were also fruitful.

We are grateful for everyone and look forward to meeting you somewhere again. We are sure that we can, since it’s a small world, especially in IT security.

Selamat tinggal!

All of us had a wonderful time at the banquet

Oct 31, 2016

Verification of Windows New Security Features – LSA Protection Mode and Credential Guard

In most of the targeted attack cases, often multiple computers get infected by malware, rather than just a single computer, and attackers continue compromising other computers across the network, including important servers. For this “lateral movement” purpose, password hash is often targeted. In order to enhance protection against such information theft, LSA Protection Mode for Windows 8.1 etc. and Credential Guard for Windows 10 Enterprise have been introduced. In this entry, we will examine the protection effect of these features and the points to consider in reserving the effect.

Overview of LSA Protection Mode

LSA (Local Security Authority) is a subsystem related to Windows security. It manages user rights information and stores password hash etc. in the memory. In OS including Windows 8.1 and others, LSA Protection Mode serves to protect such information from being stolen.

In order to enable LSA Protection Mode, users need to edit the registry as instructed in Technet Library [1] and reboot the OS. Please note that LSA plug-ins which are not compatible with LSA Protection Mode will not function after enabling the mode. Such plug-ins can be identified by using Audit Mode before changing the Protection Mode.

LSA Protection Mode was first introduced in Windows 8.1 and Windows Server 2012 R2. For Windows 10, which was released after that, Build 10240 could not be started up properly with Protection Mode. However, we confirmed that Build 10586 (Version 1511, November Update, TH2) was successfully started up under the mode.

Verification of LSA Protection Mode with Artifacts Used in Actual Attacks

We verified the effect of LSA Protection Mode by attempting hash dump using 4 types of artifacts which have functions to dump password hash. All the artifacts were used in actual attacks. Functions of each artifact are described in Table 1. Figure 1-6 shows the dump results for each artifact, and Table 2 shows the results under LSA Protection Mode.

We conducted the verification using Windows 10 Build 10586 and Windows 8.1, and confirmed that the same results were derived.

Table 1: Artifacts that dump password hash
ArtifactCommand/OptionDumped Information
mimikatz sekurlsa::logonpasswords Logged-on user information
gsecdump -u Logged-on user information
PwDump7 N/A Local user information
QuarksPwDump -dhl Local user information
Table 2: Results of hash dump under LSA Protection Mode
mimikatz Failed (An error occurred)
gsecdump Failed (An error occurred)
PwDump7 Successful
QuarksPwDump Successful

Under LSA Protection Mode, mimikatz and gsecdump observed an error as in Figure 2 and 4, and were unable to dump. On the other hand, when it is disabled, these two types of artifacts are able to dump logged-on domain user information as in Figure 1 and 3. Information of the domain user can be a hint to compromise other computers within the domain (e.g. pass-the-hash attack). LSA Protection Mode protects such domain user information from being stolen, and therefore it is expected to hinder lateral movement.

Figure 1: mimikatz (Protection Mode disabled)
Figure 2: mimikatz (Protection Mode enabled)
Figure 3: gsecdump (Protection Mode disabled)
Figure 4: gsecdump (Protection Mode enabled)
Figure 5: PwDump7
Figure 6: QuarksPwDump

As Figure 5 and 6 demonstrate, dumping with PwDump7 and QuarksPwDump is successful regardless of LSA Protection Mode since they dump information by reading disk devices or using registry API, instead of stealing information from LSA processes. However, the information that these two dump is local user information, not domain user. Note that the results here are derived solely from the commands/options in Table 1. (e.g. mimikatz also has a command to steal local user information just like QuarksPwDump etc.)

Overview of Credential Guard

For Windows 10 Enterprise, you can also use a further advanced system to protect LSA, “Credential Guard”. It is based on a protection environment isolated from the OS by virtualisation using hardware. Therefore, when Credential Guard is enabled, secret data and parts of LSA process that store the secret data are isolated from the OS and then protected [2] [3]. Comparison of LSA Protection Mode and Credential Guard is described in Table 3.

Table 3: Comparison of LSA Protection Mode and Credential Guard
Applicable Windows version, editionProtection mechanismWhether LSA process on the OS stores/manages rights information
LSA Protection Mode Windows 8.1, Windows Server 2012 R2 and others Restrict access to LSA process on the OS Yes
Credential Guard Windows 10 Enterprise only Isolate secrets from OS on Hypervisor No (Isolated parts that protect the secrets do)

Credential Guard can be enabled in Group Policy Management Console. However, if Hyper-V Hypervisor is not enabled in advance, in some cases, Credential Guard may not be enabled until it is first enabled in the Console, and rebooted, and then rebooted again manually. Furthermore, Credential Guard does not function even if it looks enabled on Group Policy Management Console, in case the hardware requirements are not met or required functions are disabled by UEFI (BIOS) configurations. Whether Credential Guard is actually enabled can be checked by displaying system information [2].

Verification of Credential Guard with Artifacts Used in Actual Attacks

We conducted another verification test of hash dumping by using the same artifacts as in Table 1. The results of password hash for each artifact are shown in Table 4. The result outputs are shown in Figure 5-8.

Table 4: Results of password hash dump under Credential Guard
mimikatz Failed (incorrect hash value dumped)
gsecdump Failed (incorrect hash value dumped)
PwDump7 Successful (as in Figure 5)
QuarksPwDump Successful (as in Figure 6)

As Table 4 describes, the dump results are similar to the verification under LSA Protection Mode (Table 2). In Figure 7 and 8, which shows the dump results with mimikatz and gsecdump under Credential Guard, there was no error observed (unlike Figure 2 and 4 under LSA Protection Mode). However, this is due to the fact that the protection mechanism is different in LSA Protection Mode and Credential Guard as in Table 3, and it does not mean that the password hash is stolen.

Figure 7: mimikatz (Credential Guard)
Figure 8: gsecdump (Credential Guard)

Compare Figure 1 which shows the dump results of mimikatz without LSA protection and Figure 7 with Credential Guard, and similarly Figure 3 and 8 for gsecdump. Although the same password is configured for all the cases, you will realise that the password hash value is different and it derives an incorrect password hash value under Credential Guard (Figure 7 and 8). This means that the password hash is not stolen when Credential Guard is enabled.

Local password hash dump using PwDump7 and QuarksPwDump succeeds because it does not use LSA as an information source (as described in the Verification of LSA Protection Mode above), even under Credential Guard.

Point to Consider - 1

If you compare Figure 1 which shows the dump results of mimikatz without LSA protection and Figure 6 of QuarksPwDump with LSA protection, you will see that the password hash (NTLM) for “user1” in Figure 1 and “localuser1” in Figure 6 are identical. This means that these users share the same password, and actually “user1” is a domain user and “localuser1” is a local user. In mimikatz environment, domain users’ password hash can be protected by using LSA Protection Mode or Credential Guard. However, with QuarksPwDump, these two protection features are not effective against password hash dump of local users.

Even under LSA Protection Mode or Credential Guard, local users’ password hash can be stolen using PwDump7 or QuarksPwDump etc. in an environment where a domain user and a local user share the same password, and this raises the risks of the domain being compromised. Make sure to configure a different password for domain users and local users within the domain.

Point to Consider - 2

By using QuarksPwDump which is capable of dumping under LSA Protection Mode or Credential Guard, it is possible to dump domain logon information that was cached on the local disk as follows:

Figure 9: QuarksPwDump –dhdc


This cache is for usage on a laptop PC which is temporally offline from a domain. Neither LSA Protection Mode nor Credential Guard can protect the information in the cache from being stolen. Computers that are constantly connected to the domain do not require cache function, and in such case this function can be disabled. In order to disable cache, edit Group Policy [4] or registry [5].

If you disable cache, domain passwords cannot be found even with QuarksPwDump as shown in Figure 10.

Figure 10: QuarksPwDump –dhdc (Logon cache disabled)

If you cannot disable cache due to the network environment where the computer operates, it is better to configure stronger passwords (length, types of letters, hard to guess from dictionary). The cached password hash has a different format from data stolen from LSA, and it cannot be used for pass-the-hash attacks as is. However, some tools to crack the hash are already available, and it is possible to break weak and simple passwords.


We have verified that LSA Protection Mode and Credential Guard are one of the effective protection features against lateral movement in targeted attacks, by protecting domain password hash from being stolen. In order to enable the features, please make sure that your hardware and software meet the requirements and there is no impact on your driver or plug-ins. Also, it is important to check if your environment does not reduce the protection effect. We hope that these features help in constructing an even more secure Windows domain environment.

-Kenichi Imamatsu

(Translated by Yukako Uchida)


[1] Microsoft - Configuring Additional LSA Protection

[2] Microsoft - Protect derived domain credentials with Credential Guard

[3] FFRI - Windows 10 Research report on effects of reducing security risks - Phase 1 (Japanese only)

[4] Microsoft - Interactive logon: Number of previous logons to cache (in case domain controller is not available)

[5] Microsoft - Cached domain logon information

Aug 29, 2016

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. [1]

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.

Table 1: Creating and Launching Executable Files
Internet OptionsCreating Malware’s Executable FilesLaunching 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).

Table 2: Launching via DLL
Internet OptionsLaunching 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:

Figure 1: Warning Pop-up asking to allow File Execution

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).

Figure 2: Screen when execution is allowed at the warning pop-up (Enhanced Protected Mode disabled)

Figure 3: Screen when execution is allowed at the warning pop-up (Enhanced Protected Mode enabled)

Figure 4: Screen when infected via trusted Websites (Protected Mode disabled)

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.

Table 3: Results for Launching Windows Command, Creating and Executing Scripts
Internet OptionsLaunching cmd.exeCreating ScriptsDownloading 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.

Figure 5: Launched Programs 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)


[1] FFRI - Windows 8 Security (Japanese)

[2] Microsoft - AppContainer Isolation

[3] IBM - A Peek into IE's Enhanced Protected Mode Sandbox

[4] Black Hat - diving into ie 10's enhanced protected mode sandbox