17 posts categorized "#Vulnerabilities" Feed

Jun 05, 2018

How to Describe Vulnerability Information?

Today, I would like to introduce an activity at the Vulnerability Coordination Group of JPCERT/CC.
It is a method to describe a vulnerability using Vulnerability Description Ontology (VDO).

JPCERT/CC receives software vulnerability information from domestic and overseas reporters, then coordinates them in between the vendor/developer and the reporter. While there is a vulnerability reporting template, vulnerability itself is described in a free format. Reporter can describe about a vulnerability in a way they like. From a vulnerability coordinator's perspective, the following are a few obstacles that we are facing:

1. It is necessary to "understand" the technical aspects

For example, the description in CVE for the vulnerability CVE-2014-8606 is as follows:

Directory traversal vulnerability in the XCloner plugin 3.1.1 for WordPress and 3.5.1 for Joomla! allows remote administrators to read arbitrary files via a .. (dot dot) in the file parameter in a json_return action in the xcloner_show page to wp-admin/admin-ajax.php.

When reading this information, the following technical details can be extracted:

  • (Affected) Products and Versions
    • Xcloner plugin 3.1.1 (for WordPress)
    • Xcloner plugin 3.5.1 (for Joomla!)
  • Vulnerability type: Directory traversal
    • Root cause: the parameter "file" is not validated
    • Attacker: Remote authenticated attacker
    • Impact: Arbitrary file read

There is no unique way to articulate the technical aspects of a vulnerability. A free format allows various reporters to describe a vulnerability using their own way. In some cases, there may be redundant information, or in other cases, not enough information.

2. When the vulnerability description is written in your non-native language, it can be extremely difficult to comprehend

A lot of vulnerability information is published in English, so organizations who do not have any English speaker may have a difficulty in comprehending a vulnerability due to the language barrier. In addition, various sources are now publishing vulnerability information, and lots of non-English vulnerability information are publicly available.
For example, CNNVD in China provides vulnerability information only in Chinese.

To overcome these issues, the National Institute of Standards and Technology (NIST) in US has proposed the creation of Vulnerability Description Ontology (VDO).

VDO provides basic building blocks to describe a vulnerability so that a vulnerability can be described without using a free format.
Below is an example of the vulnerability (CVE-2014-8606 from above) described using the VDO (taken from NIST IR 8138 - Appendix A)

Vulnerability: cve.mitre.org CVE-2014-8606
Provenance: http://www.vapid.dhs.org/advisories/wordpress/plugins/Xcloner-v3.1.1/
Scenario: 1
Type: cve.mitre.org CWE-22
Attack Theater: Remote
  Remote Type: Internet
Barriers: Privilege Required
  Privilege Level: Administrator
    Relating to Context: Application
Context: Application
Entity Roles: Primary Authorization
Entity Roles: Vulnerable
Impact Method: Trust Failure
  Trust Failure Type: Failure to Verify Content
Logical Impact: Read(Direct)
  Scope: Limited
    Criticality: Low
Context: HostOS
  Entity Roles: Secondary Authorization
Impact Method: Code Execution
Logical Impact: Read(Direct)
  Scope: Limited
    Criticality: High

While VDO is still in a draft phase. I believe that it has a huge potential to

  • Provide a common language for understanding and exchanging information on vulnerabilities
  • Provide a format to automatically manage vulnerability information

JPCERT/CC is currently attempting to see if describing vulnerabilities using VDO can make the vulnerability coordination operations more efficient.

The following shows how vulnerability information can be entered into the VDO format using an editor.
Currently, we have implemented a JSON Schema to enter the Noun Groups defined in NISTIR 8138 in a simple manner to test whether this can be used in a practical manner.


More details on this attempt to make vulnerability coordination more efficient through the VDO will be presented at the 30th Annual FIRST Conference.

If you are interested in VDO and its application, please contact us at vultures [at] jpcert.or.jp.

- Masanobu Katagi

Apr 27, 2018

JPCERT/CC Publishes "Vulnerability Coordination and Disclosure Policy"

JPCERT/CC has been coordinating and disclosing software vulnerabilities under the "Information Security Early Warning Partnership" since 2004. We have coordinated and disclosed over 1,500 vulnerabilities with developers as of the end of 2017. The "Information Security Early Warning Partnership" has a guideline that serves as a framework for how vulnerabilities are coordinated within Japan. An overview of the framework including how reported vulnerabilities are coordinated and disclosed is provided at the following:

Guidelines for Information Security Early Warning Partnership (Summary)


While the framework does not explicitly state "only reports from domestic reporters" will be coordinated, JPCERT/CC has mainly coordinated vulnerabilities discovered and reported by reporters in Japan through this framework.

Over the years, there have been vulnerability reports coordinated by JPCERT/CC in cooperation with overseas CSIRTs or directly reported by overseas reporters. As the number of such reports have increased, it became apparent to us that we needed an outward facing policy that states what vulnerability reports will be coordinated and how they will be coordinated. The main goal in publishing this policy is to set expectations on what vulnerability reports may or may not be coordinated to reporters of vulnerabilities to JPCERT/CC.

The policy states the point of contact at JPCERT/CC for vulnerability reports, what we require in a vulnerability report, what reports will be coordinated, what will be published, etc.

For details, refer to the policy that is on the JPCERT/CC website.

JPCERT/CC Vulnerability Coordination and Disclosure Policy


If you have any questions, please contact us at vultures [at] jpcert.or.jp.

- Taki Uchiyama
JPCERT/CC Member of Technical Committee

Feb 20, 2018

Identify Mirai Variant Infected Devices from SSDP Response

As it has been discussed in some reports from security researchers, devices infected with Mirai and its variants are forming large-scale botnets, which are often leveraged as a platform for attacks such as DDoS and other malicious activities.

JPCERT/CC has been conducting investigation and analysis of infection activities caused by Mirai variants from 2016 and providing measures to prevent further infection both in Japan and overseas. At the end of October 2017, given the significant increase in the devices infected with Mirai and its variant, JPCERT/CC issued a security alert on 19 December. For the release of this alert, JPCERT/CC coordinated with a device vendor in identifying the infected device models. This entry introduces the approaches that we took for this investigation.

Observation results and initial investigation

In late October 2017, we confirmed through JPCERT/CC’s packet traffic monitoring system (TSUBAME) that devices infected with a Mirai variant were carrying out scans to global IP addresses, targeting Port 23/TCP and 2323/TCP. Further detailed analysis revealed some of the source IP addresses used for the scan activities. [1]

Comparing the IP addresses against the network scan results provided by local/global security organisations, it turned out that most of the affected hosts were accessible directly from the Internet through Simple Service Discovery Protocol (SSDP).

How to Identify MAC address from SSDP response

SSDP is one of the protocols used for Universal Plug and Play (UPnP), which enables searching for devices connected to the network, and Port 1900/UDP is assigned. Communication performed when searching for devices with SSDP is described in Figure 1.

Figure 1: Part of communication for searching devices using SSDP

In this protocol, a client sends a query (M-SEARCH) to the network, and devices received this query returns a response (NOTIFY).

The NOTIFY response contains information about the device itself, including Universally Unique Identifier (UUID). This is a string to uniquely identify an object on the software. There are 5 versions for UUID [2], and the version 1 is based on the timestamp (when the UUID was generated) and the MAC address of the device. Figure 2 explains the data structure of the UUID version 1.

Figure 2: Structure of UUID version 1

In this version, the device’s MAC address is inserted in the UUID’s last 12 digits. This means that the device itself can be identified by looking at the NOTIFY payload in response to a SSDP query. The device vendor can also be determined from the vendor ID, which lies in the first 3 octets of the MAC address.

Identify infected devices and take measures

Most of the devices that were found infected with a Mirai variant had been used with SSDP service publicly available on the Internet, and its UUID was version 1. This made us possible to identify the MAC address and consequently the vendor of the affected devices. From the MAC addresses and packet traffic observed through TSUBAME, JPCERT/CC coordinated with the vendor in question and identified the affected device models, which led to the release of the security alert together with some related organisations to raise users’ awareness.

JPCERT/CC continues to coordinate with vendors in investigation on devices and request for security measures, so that the any further infection can be prevented.


We introduced how we came to identify infected devices. If SSDP port is left publicly accessible on the Internet, it has potential risks to be used for DDoS attacks [3] and other malicious activities leveraging UPnP vulnerability [4] [5]. If you are using UPnP-equipped devices, please make sure that the security measures are properly taken such as 1) keep the firmware up-to-date, 2) not expose UPnP service on the Internet and 3) disable UPnP function if not being used.

If you have any questions, please contact global-cc[at]jpcert.or.jp.

Thanks for reading.

- Tomoaki Tani

(Translated by Yukako Uchida)


[1] JPCERT/CC Internet Threat Monitoring Report [October 1, 2017 - December 31, 2017] [JPCERT/CC]


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


[3] Alert (TA14-017A) UDP-Based Amplification Attacks [US-CERT]


[4] US-CERT Vulnerability Note VU#357851

UPnP requests accepted over router WAN interfaces


[5] CVE-2014-8361 Detail [NIST]


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

Jul 08, 2016

Japan Vulnerability Notes (JVN) Site Update

Hello, Taki here. This is more of an update to my previous entry:

Some coordinated vulnerability disclosures in April 2016


Towards the end of the entry, I had mentioned that we were working on upgrading our systems to get more advisories out on our JVN English site. As of May 16th, the JVN site has been updated so that we can release advisories for vulnerability reports that are directly reported to us from various sources.

When you go to the JVN English site now, there are 2 new categories under the "List of Vulnerability Report" on the right. They are "VN_VU" and "TA". Details on these categories are provided on JVN site, but let me briefly explain here.

"VN_VU" is a section used for reports directly reported to JPCERT/CC, where JPCERT/CC is involved in the coordination process in some manner. Advisories will be published here for such reports and when there is no information source in English that we can find.

"TA" is a section that will be used to warn JVN readers on large scale issues, not just a specific vulnerability. As an example, on the JVN Japanese site, we recently published an alert on "WPAD Name Collision Vulnerability". This was a localization of a US-CERT Technical Alert, which is why it is not on the JVN English Site, but we would like to publish similar information here in the future.

We hope that we can provide more information through JVN that helps our readers.

If you have any questions, please contact us at vultures (at) jpcert (dot) or (dot) jp.

Until next time,

Takayuki (Taki) Uchiyama

May 06, 2016

Some coordinated vulnerability disclosures in April 2016

Hello, Taki here. It has been a long time since I have written here.

Today, I will be writing about some activities within our Vulnerability Coordination Group.

Over the past few years, we have received some coordination requests directly from overseas researchers and other sources, in addition to the reports through the " Information Security Early Warning Partnership".

I would like to introduce some recent cases that we have published on Japan Vulnerability Notes (JVN - https://jvn.jp/) but due to system limitations, are not in English at the moment.

The first case is,

JVNVU#92116866 – Published on 2016/4/26

Keitai Kit for Movable Type vulnerable to OS Command Injection.

An OS command injection vulnerability was reported to us in the Movable Type plugin, Keitai Kit. Leveraging this vulnerability may result in arbitrary OS commands being executed on the server.

Versions affected are 1.35 through 1.641.

Attacks in the wild leveraging this vulnerability have been confirmed.

The vendor has provided an updated version, 1.65 to address the vulnerability. For those that cannot update, emergency patches have been provided for affected versions.

This vulnerability has been assigned, CVE-2016-1204.

The second case is,

JVNVU#90405898 – Published on 2016/4/27

ManageEngine Password Manager Pro fails to restrict access permissions.

An access permission bypass vulnerability was reported to us in ManageEngine Password Manager Pro. Leveraging this vulnerability may result in unauthorized users being able to access password entry records for other users.

Versions affected are 8.3.0 (Build 8303) and 8.4.0 (Build 8400, 8401, 8402).

The vendor has provided an update version, 8.4.0 (Build 8403) to address the vulnerability.

And this vulnerability has been assigned, CVE-2016-1159.

Internally, we are working to upgrade our systems so that we can get this information onto JVN in an advisory format. For the time being, I hope to update through this blog periodically on some of our coordinated disclosures.

If you have a vulnerability report and are having difficulty reaching a vendor or are trying to reach a Japanese vendor and having a language issue, feel free to contact us. While we may not always be successful, we can at least give it our best try to contact and coordinate with a vendor.

For coordination assistance, please contact us at vultures (at) jpcert (dot) or (dot) jp.

- Takayuki (Taki) Uchiyama

Apr 08, 2016

PHP Files in CMS, Targeted for Alteration

JPCERT/CC has been continuously observing cases where websites in Japan created with Content Management Systems (hereafter “CMS”) are defaced in a similar way, and the same kind of cases are also observed overseas [1], [2]. In these cases, part of the PHP files composing the CMS are altered, and this results in defacement of the website contents [3].

Based on the analysis of several cases, this entry today describes the alteration of such files composing CMS.

Altered Files

JPCERT/CC confirmed that the targeted CMS contained partially altered PHP files as components. The CMS names and altered PHP files in each are listed in Table 1.

Table 1: CMS names and altered PHP files
CMS NameAltered PHP Files
WordPress /wp-includes/nav-menu.php
Joomla! /includes/defines.php
Drupal /includes/bootstrap.inc
MODX /manager/includes/protect.inc.php

Our study revealed that malicious codes were dynamically inserted into the response from the website for each access by the visitor, which was a result of the PHP file alteration.

How Altered PHP Files Insert Malicious Codes

Altered PHP files included malicious PHP codes in between “//istart” and “//iend” as in Figure 1 (we noted that malicious codes are obfuscated in some cases).

These malicious PHP codes have a function to insert codes obtained from outside. They receive malicious codes from a specific URL and insert them in a certain place.

Figure 1: Malicious PHP codes in between “//istart” and “//iend”

Malicious Codes to be Inserted

When a visitor accesses such websites, the malicious PHP codes in the altered PHP files obtain malicious codes composed of “div” tag and JavaScript, and insert them in the response to the website visitor. The places to insert the codes differ in each CMS: right after the “body” tag in WordPress, and at the beginning of the HTML in Joomla!, Drupal and MODX.

Figure 2: Example of malicious codes to be inserted

Malicious codes include obfuscated JavaScript, and if this is executed on the visitor’s browser, they generate tags such as iframe, etc., which redirect the visitor to the attacker’s site. Also, if the visitor’s web browser or its plug-in, etc., has certain vulnerability, their PC may be exposed to the risk of being infected with malware such as ransomware.


In such cases where malicious codes are dynamically inserted, it may be difficult for website administrators to realise that their websites are providing malicious contents. We recommend the administrators to confirm that there are no malicious PHP codes (as in Figure 1) in the PHP files described in Table 1 and others in their websites. We have not yet confirmed how these PHP files are altered, but vulnerabilities in the CMS or the plug-ins used by CMS may be leveraged for the alteration. We also recommend updating the CMS and plug-ins to the latest version.

Other than the instances introduced here, JPCERT/CC has been seeing cases where Japanese websites are defaced, and then leveraged as an entrance to the attacker’s website. We hope that each website administrator takes actions as updating the software and properly managing passwords, and be mindful that their website would not be abused for such attacks.

- Ayaka Funakoshi

(Translated by Yukako Uchida)


[1] Sucuri Inc
WordPress Malware Causes Psuedo-Darkleech Infection

DarkLeech: Finally Under Control?

JPCERT/CC Incident Handling Report (October 1 – December 31 2015) (English)

Sep 30, 2015

VPN Servers Altered by Attacker Leading to Scanbox, a Reconnaissance Framework

Hi, it’s Shusei Tomonaga again from the Analysis Center. JPCERT/CC has confirmed several attack cases around May 2015, which attempt to steal information of computers leveraging specific network devices featuring VPN server functions. The target of the reconnaissance varies from installed software to keylogs, and it is presumed that the attacker has aimed to steal such information from computers which attempt to login to VPN servers through altered login pages. In this post, I’d like to introduce the details of the attack and effective countermeasures you may take.


Through our analysis, we were able to reveal the mechanism of how VPN account information could be stolen, using a framework called Scanbox. The Scanbox consists of (1) JavaScript code to be sent to the browser, (2) the server to receive the collected information and (3) tools to analyze information collected in the server. The overall flow of attack is shown in Figure 1.

Figure 1: Overall Flow of Attack [Click to enlarge image]

In this attack, the attacker somehow alters VPN service login pages of such network devices and embeds scripts, which leads the user to access a different server in addition to its originally intended behaviour. The JavaScript code of Scanbox, which collects information of users’ computers, is placed in the accessed server, and computers accessing the altered login page are led to download and execute it. This JavaScript code steals information such as the computer’s IP address, installed software and information entered by the user in the VPN session, and keeps sending the information to the Scanbox information collection server until the browser is closed.


Through our analysis, we confirmed that login pages of specific network devices with VPN server functions were altered in several cases. As of now, we have not been able to specify the method of alteration, but there is possibility that a network device vulnerability was leveraged.

The altered login page was embedded with a script tag as shown in Figure 2. When the user accesses the Web SSL VPN login page via the browser, the user is unknowingly entrapped into the Scanbox due to this script.

Figure 2: A Script embedded Web Page redirecting to an Altered Website [Click to enlarge image]


The Scanbox, set up at the redirected site, is a framework to steal information, often used in targeted attacks. Attacks by Scanbox start by downloading and executing a JavaScript code. This JavaScript code collects the computer information such as installed applications and IP address, etc., and sends them to the Scanbox information collection server. (Note that the Scanbox JavaScript code can not only collect computer information, but can also add functions to infect the computer with malware by leveraging a vulnerability.)

Table 1 lists Scanbox’s information collection function which we confirmed in this attack.

Table 1: Information collected by Scanbox
ItemFunctionCollected Information
1 Software Scan Information of installed software (anti-virus software, Windows patch, etc.)
2 Flash Scan Adobe Flash Player versions
3 Office Scan Microsoft Office versions
4 Adobe reader scan Adobe Reader installation status
5 FireFox Extentions scan Firefox and plugin installation status
6 Java scan Java versions
7 IP scan IP address information (function for Chrome)
8 Keylogs Keystrokes within the browser (sent every 5 seconds)
9 Ip list IP address information HTTP_X_FORWARDED_FOR
10 Drives scan Drive information

As shown in Item 8 in the above table, Scanbox can also collect such information as entered in Web forms. As such, information entered in the login site may possibly leak. For keystrokes within the browser, the Scanbox JavaScript code sends the collected information to the server every 5 seconds until the browser (tab) reading the JavaScript code is closed. Other information in Table 1 is sent to the Scanbox information collection server upon respective functions’ startup. (For further information on Scanbox, please visit the AlienVault Blog (Reference [1]) for detailed explanation.)

Furthermore, Scanbox has a Web interface for the attacker to analyze the collected information. As shown in Figure 3, the collected information can be browsed on the Website. Information collected by Scanbox can also be customized from the Website as shown in Figure 4.

Figure 3: Screen for browsing information collected in Scanbox [Click to enlarge image]
Figure 4: Screen for customizing information collected in Scanbox [Click to enlarge image]


As of now, the method of the VPN server login page alteration is unknown. However, we presume that there is high possibility that a known vulnerability was leveraged, so we recommend users to apply patches and update firmware. We also recommend users to check if there are any scripts that are unintentionally embedded in the login pages.

Although attacks using Scanbox do not involve malware infection, it needs caution as it steals computer information and information entered in the browser. There is possibility that the attacker is planning for the next phase of attack based on the collected information, therefore, it is necessary to endeavor to detect the attack in an early stage, as well as to keep a close watch over the attacker’s next move and to strengthen protection against it.

Last but not least, an effective countermeasure against Scanbox is to avoid executing JavaScript in your browser downloaded from a Website which is not trusted on your browser.

Thank you for reading and see you again.

- Shusei Tomonaga


[1] AlienVault - Scanbox: A Reconnaissance Framework Used with Watering Hole Attacks


Aug 28, 2015

Enhanced Protected Mode in Internet Explorer

Hi, it’s Shusei Tomonaga again from the Analysis Center. My previous post discussed the mitigation effects against damages caused by malware infection by enabling Internet Explorer’s (hereafter “IE”’s) Protected Mode. In this article, I’d like to introduce an even stronger security function called “Enhanced Protected Mode”, which is a feature of IE 10 and 11 - its overview and preventive effects against damages caused by malware infection.


Unlike Protected Mode, Enhanced Protected Mode is turned off by default. To enable it, you must tick the “Enable Enhanced Protected Mode” option in the Security section of IE’s Tools > Internet Options > Advanced tab, and then restart IE.

Figure 1: Enhanced Protected Mode setting screen (IE 11 for Windows 8.1)

This feature is available in the following OS:

  • Windows 10 (32-bit/64-bit)
  • Windows 8.1 (32-bit/64-bit)
  • Windows 8 (32-bit/64-bit)
  • Windows 7 (64-bit) *Not available on 32-bit OS

When Enhanced Protected Mode is enabled, IE will run in the following mode:

  • 64-bit mode (only in a 64-bit mode Windows)
  • A sandbox environment called AppContainer (only on Windows 8, 8.1 and 10)

Even on a 64-bit Windows, IE will run in 32-bit mode if the Enhanced Protected Mode is turned off. On a 64-bit Windows, IE will run in 64-bit mode by enabling the Enhanced Protected Mode, plus in case of IE 11 for Windows 8 and later, by checking the “Enable 64-bit processes for Enhanced Protected Mode” in “Internet options”. Furthermore, IE that is launched from Window Store applications in Windows 8, etc., will run in 64-bit mode. Also, Microsoft “Edge”, the all new web browser introduced with Windows 10, will run in 64-bit mode by default.

AppContainer is a sandbox environment introduced in Windows 8, which limits process operations more strictly than does the Integrity Level (in Protected Mode). In a widely known case, the Windows Store applications runs in an AppContainer environment, and an Enhanced Protected Mode designated IE also runs in an AppContainer environment.

Figure 2: IE Integrity Level (confirmed with Process Explorer)


In order to validate how Enhanced Protected Mode is effective in reducing damage by malware infection through IE, we analysed using an exploit code that leverages CVE-2014-6332 (vulnerability in IE)which runs PowerShell to attempt to execute an unauthorized code. The verification was conducted on IE 11 for Windows 8.1.

As shown in Figure 3, the attack was successfully conducted in IE running in 32-bit with the Enhanced Protected Mode turned off; the PowerShell is running.

Figure 3: Behaviour of Unauthorized Code on IE 11 (32-bit) for Windows 8.1

Furthermore, Figure 4 shows the verification of IE running in 32-bit with the Enhanced Protected Mode enabled. It shows that the attack was successfully conducted under this condition as well, and the PowerShell is running.

Figure 4: Behaviour of Unauthorized Code on IE 11 (32-bit) for Windows 8.1 with Enhanced Protected Mode enabled

On the other hand, in IE running in 64-bit with the Enhanced Protected Mode enabled, the Powershell fails to run, and IE shut down unexpectedly, as shown in the following figure.

Figure 5: Behaviour of Unauthorized Code on IE 11 (64-bit) for Windows 8.1 with Enhanced Protected Mode enabled

The reason for IE’s unexpected shutdown in 64-bit mode is that the exploit code executed in the IE process was created exclusively for a 32-bit environment. All the exploit codes leveraging vulnerability in IE that JPCERT/CC has analyzed so far were created exclusively for 32-bit OS. Therefore, if IE is running in 64-bit mode, these exploit codes fail to execute as intended by the attacker.

Note that AppContainer is not supported in Windows 7; therefore IE just runs in 64-bit mode when Enhanced Protected Mode is enabled. In this case, the attack also fails, similarly to the test results in Windows 8, etc.


Running IE in 64-bit mode with Enhanced Protected Mode enabled is a strongly effective countermeasure against attacks targeting IE, until an exploit code for 64-bit emerges. Furthermore, I did not touch on the functions of AppContainer in this verification, but when AppContainer is enabled, it basically only allows access to limited resources such as files created in IE, favorites folders (%UserProfile%Favorites), etc. Therefore, even if malware infection occurs, we can expect a higher mitigation effect than that of the Protected Mode which I touched upon in the previous post.

Last but not least, please note that when you enable Enhanced Protected Mode, not only the malware but also incompatible browser extensions such as add-ons, ActiveX controls, etc., may not work correctly. So I would recommend users to check the compatibility before actually enabling the Enhanced Protected Mode.

Thank you for reading and see you again.

- Shusei Tomonaga


[1] Understanding Enhanced Protected Mode


Jul 10, 2015

The 27th FIRST Annual Conference in Berlin

Hello, Taki here, and its currently rainy season in Japan.

Just recently, I attended the 27th FIRST Annual Conference, held on June 14-19 , 2015 in Berlin – a city that I visited for the first time.


(Photo by Hiroshi Kobayashi)

I would like to go over some activities that JPCERT/CC was involved in during the conference.

This year I attended together with 3 colleagues, Yurie Ito, Koichiro (Sparky) Komiyama and Hiroshi Kobayashi. The conference was themed “Unified Security: Improving the Future”, focusing attendees’ collective efforts on improving the future of security together. As usual, it was great to catch up with the various people that work in the industry and also getting to know some new people as well. Many discussions around work over the past year and prospective collaboration over the next year were had.

JPCERT/CC was involved in 3 different presentations at the conference and I would like to take the time to briefly introduce each of them.

First, Yurie's presentation was titled, "A Proposal for Cybersecurity Metrics Through Cyber Green". Cyber Green, currently led by JPCERT/CC, is a project that aims to measure the health of the Internet by aggregating data sets of key risk factors, enabling comparisons over time and around the world, in order to identify what can be improved to make the Internet a better place. The presentation centered around the overview of the project, along with some details on the methods as to how the data is collected, analyzed and shown.

I was a co-presenter in a talk titled, "VRDX-SIG: Global Vulnerability Identification" along with Mr. Art Manion of CERT Coordination Center (CERT/CC) and Dr. Masato Terada of the Hitachi Incident Response Team (HIRT). The FIRST VRDX-SIG (Vulnerability Reporting and Data eXchange Special Interest Group) was chartered in 2013 to study existing practices on how vulnerabilities are identified, tracked and exchanged, and to develop recommendations on how to better the existing practices across disparate vulnerability databases (including Vulnerability Notes Database by CERT/CC, Japan Vulnerability Notes (JVN) by JPCERT/CC and Information-technology Promotion Agency, Japan (IPA), Open Sourced Vulnerability Database (OSVDB) and other vendor security advisories). This talk presented results of the work of the VRDX-SIG, including the creation of a vulnerability database catalog and some findings about vulnerability identification and tracking.

The last presentation that JPCERT/CC was involved in was a presentation by Hiroshi titled, "Keeping Eyes on Malicious Websites - “ChkDeface” Against Fraudulent Sites". He first talked about some noteworthy features of defaced websites reported to JPCERT/CC, and then introduced a tool called "ChkDeface", developed and implemented at JPCERT/CC, to collect various information on the defaced websites through a secure and efficient monitoring method. JPCERT/CC is planning to share the source code of this tool with some CSIRTs in the FIRST community, and eventually to open source the tool so that it can be practically utilized to trigger deeper discussion among security experts about more precise detection methods ― so here's hoping for a follow-up blog entry when that happens.

JPCERT/CC was a part of a few working groups as well, including the Energy-SIG, Vulnerability Coordination-SIG and CVSS-BoF in addition to the aforementioned VRDX-SIG. While I am unable to provide any insight about what was actually discussed, I believe that the work being done is worthwhile and when there is any output provided, I hope to notify through this blog or some other forms of communication.

Lastly, Berlin was a wonderful city, a little colder than I had expected, and hope to create a chance to visit again.

That's all for today.

Thank you for reading.


(Photo by Hiroshi Kobayashi)

- Takayuki (Taki) Uchiyama