53 posts categorized "#JPCERT news" Feed

Jun 12, 2017

Research Report Released: Detecting Lateral Movement through Tracking Event Logs

JPCERT/CC has been seeing a number of APT intrusions where attackers compromise a host with malware then moving laterally inside network in order to steal confidential information. For lateral movement, attackers use tools downloaded on infected hosts and Windows commands.

In incident investigation, traces of tool and command executions are examined through logs. For an effective incident investigation, a reference about logs recorded upon tool and command executions would be useful.

JPCERT/CC conducted a research on typical tools and commands that attackers use after intrusion, and traces that they leave on Windows when executed. The result of the research is available on the report below:

Detecting Lateral Movement through Tracking Event Logs

https://www.jpcert.or.jp/english/pub/sr/ir_research.html

This entry will introduce the overview of the report.

Intended Audience

This report is designed for technical staff including those responsible for initial investigation of incidents. Even without forensic software or knowledge in forensics, readers capable of examining event logs and registry entries can understand the contents.

Tools and Commands

44 typical tools and commands have been featured on the report (as described in Appendix A) based on what JPCERT/CC has seen in multiple incident cases. Since these tools and commands are used by multiple attackers, it is likely that analysts encounter some of them during incident investigation.

Need for Detailed Logs

Under the default configuration of Windows, many of these tools and commands are not logged. In order to investigate what attackers did during the incident, preparation for log retention is necessary. The report describes how to record tools and command executions by setting audit policy and installing Sysmon. Other than the methods explained in the report, it is also possible to collect such logs with audit applications or EDR products.

Way Forward

We are planning to examine other tools and commands as well. In addition to event logs and registry entries, we will also look into forensic artifacts such as MFT and journal files.

We welcome any feedback from you at global-cc [at] jpcert.or.jp.

-         Shusei Tomonaga

(Translated by Yukako Uchida)

Appendix A:  Examined Commands and Tools
Table 1: List of Examined Commands and Tools
Attacker's Purpose of Using ToolTool
Command execution PsExec
wmic
PowerShell
wmiexec.vbs
BeginX
winrm
at
winrs
BITS
Obtaining password hash PWDump7
Quarks PwDump
mimikatz
WCE
gsecdump
lslsass
Find-GPOPasswords.ps1
Mail PassView
WebBrowserPassView
Remote Desktop PassView
PWDumpX
Malicious communication relay
(Packet tunneling)
Htran
Fake wpad
Remote login RDP
Pass-the-hash
Pass-the-ticket
WCE
mimikatz
Escalation to SYSTEM privilege MS14-058 Exploit
MS15-078 Exploit
Privilege escalation SDB UAC Bypass
Capturing domain administrator
rights account
MS14-068 Exploit
Golden Ticket (mimikatz)
Silver Ticket (mimikatz)
Capturing Active Directory database
(Creating a domain administrator user or
adding it to an administrator group)
ntdsutil
vssadmin
Adding or deleting a user group net user
File sharing net use
net share
icacls
Deleting evidence sdelete
timestomp
Deleting event log wevtutil
Obtaining account information csvde
ldifde
dsquery

May 12, 2017

Fact-finding Report on the Establishment and Operation of CSIRTs in Japan

Hello, this is Misaki Kimura from Watch and Warning Group.

JPCERT/CC conducted “Survey on the Establishment and Operation of CSIRTs in Japan” in the end of 2015. Following the Japanese report released in 2016, we have just released the English version of the report on JPCERT/CC website to share the outcomes with the information security community member all around the globe. Although the basis of social composition, culture, organizational constitution and so on may differ in each economy, we hope that this document will serve as a useful reference in terms of establishing a CSIRT or comparing the situation with those organizations in overseas.

Here in this blog will cover an executive summary of the report.

Background of the survey

Cyber attacks in recent years have become increasingly diverse in terms of their aims, targets, and TTPs (Tactics, Techniques, and Procedures) used that the impact can be large enough to shake the foundation of a business. One approach that is drawing attention is to establish a Computer Security Incident Response Team (CSIRT) that will serve as the linchpin of an organization to effectively handle security incidents. Cybersecurity Management Guidelines released from Ministry of Economy, Trade and Industry in December 2015 also referred to the need to establish CSIRTs, and this has been boosting the number of CSIRTs in Japan.

Cyber security communities, including the CSIRT community, are quite active in Japan. Nippon CSIRT Association (NCA) is the venue for local CSIRTs to come together for information sharing and joint activities, which has 232 member organizations (as of May 2017). JPCERT/CC conducted the survey targeting 66 organizations which belongs to NCA with an aim to assist those who wish to establish a new CSIRT by compiling the facts of CSIRT activities in various local organizations. The survey took place in December 2015, by means of a questionnaire and interviews, covering questions on organizational structure, scale, functions, policies and other various aspects of CSIRTs. Here below will introduce some interesting findings described in the report.

Items to be defined upon establishing a CSIRT

Business activities, scales, department structures, and anticipated risks differ according to the organization. For this reason, based on the results of the survey, the following six items were identified as matters that organizations should define upon establishing an internal CSIRT.

  • Scope of services provided by CSIRTs
  • Authority granted to CSIRTs
  • Deployment and members of CSIRTs
  • Point(s) of contact (PoC)
  • Reporting structure to effectively communicate the effects of CSIRT activities within the company
  • Periodic review of CSIRT activities

 Among these, I would like to highlight a few findings of the survey, which are considered noteworthy for organizations in overseas as followings;

Scope of services provided by CSIRTs

A CSIRT is required to receive, review and respond to various incident reports. Therefore, scope of its service such as contents, targets, range of responsibility, and so forth need to be considered.

NCA categorizes services offered by CSIRTs roughly into the following three types: reactive services, proactive services, and security quality control services. Of these three categories, the survey results identified the main services provided by CSIRTs in each category as follows;

 - Reactive services
  • More than 80% answered "Incident handling," "Issuing security alerts" "Log Analysis" and "Vulnerability handling" are provided to respond promptly in the event of an incident
 - Proactive services
  • More than 80% answered "Security warning announcement” is provided ahead of an incident
  • Nearly 70% answered "Provision of security related information" and "Intrusion detection" are provided to monitor any signs of an attack
 - Security quality control services
  • More than 70% answered "Conducting awareness raising activity", "Organizing educational programs" and "Consulting security related issues" as a service aimed at increasing the knowledge and skills to respond to cyber security

In some CSIRTs, all of these services are provided whereas some CSIRTs only provide one or two of those. It is not the variety of services they provide that matters to a CSIRT, but the capability to provide the kinds of services that the organization needs.

Also, the results of the survey showed that about 60% of the organizations has documented their service definition, and over 80% of the organizations has defined and documented their security policies that were approved by the management.

Authority granted to CSIRTs

In responding to security incidents, it is necessary as an organization to make appropriate and timely decisions. While CSIRTs are in a position to provide assistance to departments or persons for decision-making, it is important to understand about up to what point a CSIRT authority is granted.

For example, when a system needs to be suspended for risk avoidance in the event of an urgent incident, about 12% of the CSIRTs answered that they themselves have the authority to order the systems to be stopped, while 85% of the CSIRTs answered that they do not have the authority to order but are in a position that allows them to advise on the decision-making.

Figure 1. Authority of the CSIRT in the event of an incident
Figure1

These results show that not so many organizations possess a strong authority in decision-making. However, some CSIRTs answered in the interview that they do not necessarily need to have such a powerful authority as to suspend systems in order to function effectively as a CSIRT. What matters to them is how effectively can the CSIRT collaborate with the management level to expedite accurate and rapid business decision.

Incident handling and Escalation

In case of an incident, an escalation process must be clearly defined, documented and officially approved to ensure that the incident is directed towards appropriate departments. The result shows that 74% of the CSIRTs have these processes implemented towards management, 52% implemented towards public relations department, and 50% implemented towards legal department. This indicates that CSIRTs are working closely with the management level in case of an incident, but more effort can be taken towards other related departments as well.

Information Sharing

It is essential for CSIRTs to share information and cooperates with other departments not only within the organization but also with other external partners such as other CSIRTs. Joining the information sharing framework allows the team to obtain and respond to a cyber threat in an effective way that it ultimately helps to protect the organization.

The result shows that all the survey respondents participate in more than one framework for information sharing. Specific frameworks that they join are WAISE (Watch and Warning Analysis Information for Security Experts - operated by JPCERT/CC), CCI (Counter Cyber Intelligence - operated by National Police Agency), working groups of Financials ISAC Japan, J-CSIP (Initiative for Cyber Security Information sharing Partnership of Japan - operated by Information-technology Promotion Agency, Japan) and so on.

When asked about the primary methods of expression used for sharing information, all the respondents selected text format. At the time when this survey was conducted (December 2015), some CSIRTs have already implemented STIX/TAXII, which is a globally recognized standard for incident information sharing. The protocol has been gradually accepted by an increasing number of CSIRTs over the two years after the survey.

Figure 2. Primary method(s) of expression used for sharing information
Figure2_3

Information sharing and collaboration requires investment of time and technical resources, however, it benefits by far than negatives. Some of the respondents have said in the interview that information sharing with other CSIRTs enables them to acquire knowledge and exchange insights, which helps to keep up the motivation of their CSIRT members. The importance of building trust relationships with other CSIRTs was also pointed out by other interviewees. They spoke of participating NCA and other community activities had provided opportunities to reframe how they interact with their organizations.

Conclusion

The report points to six items that should be defined at the time of establishing an internal CSIRT. However, it does not necessarily mean that fulfilling all these conditions will ensure its activities live up to the expectations of the organization. For the sake of an internal CSIRT to function effectively, it is extremely important that the team shares information and cooperates with other departments within the organization and other CSIRTs. In addition, through day-to-day operations including exercises and training, as well as responding to actual incidents, we believe that newly established CSIRTs develop into a trusted and indispensable part of the organization.

The full report can be downloaded here:

https://www.jpcert.or.jp/english/pub/sr/2015_CSIRT-survey.html

- Misaki Kimura

May 02, 2017

Volatility Plugin for Detecting RedLeaves Malware

Our previous blog entry introduced details of RedLeaves, a type of malware used for targeted attacks. Since then, we’ve seen reports including those from US-CERT that Management Service Providers (MSPs) have been targeted [1] [2]. In the US-CERT report, some instances have been identified where RedLeaves malware has only been found within memory with no on-disk evidence because of the behavior of self-elimination after the infection.

To verify the infection without on-disk evidence, investigation needs to be conducted through memory dump or logs (e.g. proxy logs) stored in network devices.

This article introduces a tool to detect RedLeaves in the memory.

It is available on GitHub:

JPCERTCC/aa-tools · GitHub

https://github.com/JPCERTCC/aa-tools/blob/master/redleavesscan.py

Tool Details

The tool works as a plugin for The Volatility Framework (hereafter “Volatility”), a memory forensic tool. redleavesscan.py has the following functions:

  • redleavesscan: Detect RedLeaves in memory images
  • redleavesconfig: Detect RedLeaves in memory images and extract malware configuration

To run the tool, save redleavesscan.py in ”contrib/plugins/malware” folder within Volatility, and execute the following command:


$python vol.py [redleavesscan|redleavesconfig] –f <memory.image> ––profile=<profile>

Figure 1 shows an example output of redleavesscan. You can see the detected process name (Name), Process ID (PID) and the name of detected malware (Malware Name).

Figure 1: Output of redleavesscan
Fig1

Figure 2 shows an example output of redleavesconfig. For details about RedLeaves configuration, please see our previous blog entry.

Figure 2: Output of redleavesconfig
Fig2

In closing

It has been confirmed that the attacker group who uses RedLeaves also uses PlugX. To detect PlugX in memory, please use the Volatility plugin released by Airbus [3].

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference:

[1] US-CERT: Intrusions Affecting Multiple Victims Across Multiple Sectors

https://www.us-cert.gov/sites/default/files/publications/IR-ALERT-MED-17-093-01C-Intrusions_Affecting_Multiple_Victims_Across_Multiple_Sectors.pdf

[2] PwC: Operation Cloud Hopper

https://www.pwc.co.uk/issues/cyber-security-data-privacy/insights/operation-cloud-hopper.html

[3] Volatility plugin for PlugX

https://bitbucket.org/cybertools/volatility_plugins/wiki/Home

Mar 28, 2017

Board game on Cyber Security for Awareness Raising

Hi this is Sho Aoki from Watch and Warning Group.

Have you ever tried “game-based learning”?

Learning through games is useful since it is not only fun and easy, but also provides opportunities for thinking. It has been applied widely for educational purposes. In the area of cyber security as well, there are board games released from security vendors, and they have been conducted at schools and companies.

Today I would like to introduce “SEC WEREWOLF”.

Board game package
Secwerewolf

This board game was released by Japan Network Security Association (JNSA) [1], which is an NPO consisting of information security related organizations (mainly vendors) in Japan. They aim to raise awareness and provide information security solutions through various activities. One of their Working Group activities is to promote game-based learning, where this board game was developed. JPCERT/CC is also part of this Working Group.

“SEC WEREWOLF” is a board game based on a famous party game “Werewolf” (also known as “Mafia”), which is a communication type game between a group of “villagers” and “werewolves” who attack villagers. Players probe other players in an attempt to find enemies to eliminate. In “SEC WEREWOLF”, “villagers” work as “CSIRT members” in an organisation, while “werewolves” are the evils in the organisation who are engaged in corruption.

STORY

“Corrupt workers” have been stealing confidential information of their organisation with the assistance from “Black hat hackers” and gaining profit out of the information. However, the management finds out about the malicious act. “Corrupt workers”, who have been dissatisfied about the company’s treatment, try to put the blame on other employees and get them fired. A CSIRT is launched to retrieve a peaceful workplace and deal with issues with an aim to get rid of the corrupt workers.

HOW TO PLAY (Overview)

  1. Players pick up a role card to decide which team they belong to (CSIRT or attackers)
  2. All the players have a conversation without disclosing their roles to figure out who are the “corrupt workers”. “Corrupt workers” will also pretend to be a CSIRT member.
  3. Out of the conversation, each player points out the person who they think is the “corrupt worker” at the end of the turn. The person who has the higher number of votes is dismissed from the game. “Corrupt workers” secretly put the blame to a CSIRT member to get them out of the game.

Process 2 and 3 will be repeated until either of the following conditions is met:

a) All the “corrupt workers” are dismissed (CSIRT wins)

b) The number of remaining “corrupt workers” becomes the same as CSIRT members (“Corrupt workers” win)

Among the board games on cyber security, “SEC WEREWOLF” is relatively easy and suitable for beginners since there is not much prerequisite. This game presents the concept of cyber security and roles within CSIRTs (some role cards have different technical skills). Furthermore, it comes with post-game materials to learn about internal fraud by looking back on how a “corrupt worker” would behave and what CSIRT members needed to do about it. It is also a good material to learn what kind of personnel a CSIRT would need to have.

A model of internal fraud “the Fraud Triangle”, was proposed by D.R. Cressey, a criminologist from the US. It suggests that internal fraud can occur when the following three factors are present: Perceived unshareable financial need, Perceived opportunity and Rationalisation [2].

The post-game material provides a review of the game from the above three perspectives. Also, by looking back at the conversation that occurred during the game, the facilitator can guide participants to further discuss lessons learned from the game. Consequently, they can consider what sort of environment they need to establish/maintain to keep their workplace from such fraud.

Facilitator explaining about internal fraud based on the triangle
Facilitator

The Working Group designed this game for people who are not familiar with cyber security. It is often said that cyber security operations are difficult to draw attention from employees unless they are actually involved. Given the current situation where cyber security is a hot topic not only for organisations but also for individuals, it is important to raise security awareness to wide range of employees and users. This board game provides a good opportunity to familiarise the players with the concept of cyber security and the role of CSIRTs.

Role cards
Role_cards
Trial at JPCERT/CC
Trial

To fully utilise this game, it is also important to develop game facilitators. This role is important in presenting the knowhow in cyber security, how CSIRTs work and the components of CSIRT employees, besides just leading the game.

There is another board game about initial response to cyber incidents, which the Working Group is planning to release in the coming Fiscal Year. JPCERT/CC is willing to assist awareness raising activities through the Working Group.

- Sho Aoki

Translated by Yukako Uchida


Reference:

[1] About JNSA

http://www.jnsa.org/en/aboutus/index.html

[2] The Fraud Triangle – The Association of Certified Fraud Examiners

http://www.acfe.com/fraud-triangle.aspx

Mar 23, 2017

Malware Clustering using impfuzzy and Network Analysis - impfuzzy for Neo4j -

Hi again, this is Shusei Tomonaga from the Analysis Center.

This entry introduces a malware clustering tool “impfuzzy for Neo4j” developed by JPCERT/CC.

Overview of impfuzzy for Neo4j

impfuzzy for Neo4j is a tool to visualise results of malware clustering using a graph database, Neo4j. A graph database is a database for handling data structure comprised of records (nodes) and relations among the records. Neo4j provides functions to visualise registered nodes and relations in a graph.

impfuzzy for Neo4j operates in the following sequence:

  1. Calculate the similarity of malware using impfuzzy
  2. Generate a graph (network) based on the similarity
  3. Conduct network analysis over the graph (clustering)
  4. Register and visualise the clustering results on Neo4j database

First, the tool calculates the similarity of malware using impfuzzy; the techniques to estimate the similarity of Windows executables based on a hash value generated from Import API. impfuzzy was introduced in our blog article before, so please take a look for further details.

After that, a graph is generated by connecting nodes that were judged to be similar based on the impfuzzy results. The graph is then analysed using Louvain method [1]. This is one of the methods to cluster network graphs, which outperforms other algorithms in speed. With this analysis, malware is automatically classified into groups.

Finally, the information of analysed malware and its group is registered in Neo4j database.

Figure 1 describes the clustering result of Emdivi malware using impfuzzy for Neo4j.

Figure 1: Clustering result of Emdivi by impfuzzy for Neo4j
Fig1

In this graph, types of malware (pink nodes) that are judged to be similar are connected with lines. From the above visualisation, it is clear that there are several groups of their variants with high similarity.

Since impfuzzy for Neo4j automatically clusters related samples through network analysis, it is possible to extract samples that belong to a specific group. Figure 2 visualises the relationship of a specific group from the example in Figure 1. The numbers on the grey lines (grey edges) between samples indicate the similarity of the malware in the range from 0 to 100 (the higher the number is, the more similar the samples are).

Figure 2: Visualisation results of samples belonging to a specific group
Fig2

How to obtain and use impfuzzy for Neo4j

The tool is available on GitHub. Please refer to the following webpage:

JPCERTCC/aa-tools GitHub - impfuzzy for Neo4j

https://github.com/JPCERTCC/aa-tools/tree/master/impfuzzy/impfuzzy_for_Neo4j

Here are the instructions for using impfuzzy for Neo4j.

1. Obtain and install Neo4j community edition

Download Neo4j community edition from the following webpage and install it:

https://neo4j.com/download/

2. Download impfuzzy_for_neo4j.py

From the following webpage:

https://github.com/JPCERTCC/aa-tools/tree/master/impfuzzy/impfuzzy_for_Neo4j

3. Install the software required for executing impfuzzy_for_neo4j.py

  • Install Python module pyimpfuzzy
$ pip install pyimpfuzzy

For more information on the install procedures, please see:

https://github.com/JPCERTCC/aa-tools/tree/master/impfuzzy/pyimpfuzzy

  • Install Python module py2neo v3
$ pip install py2neo

For more information on the install procedures, please see:

http://py2neo.org/v3/#installation

  • Download Python script pylouvain.py from the following webpage and save it to the same folder as impfuzzy_for_neo4j.py

https://github.com/patapizza/pylouvain

4. Run Neo4j

Run Neo4j by GUI or a command line.

5. Configure a password for Neo4j in impfuzzy_for_neo4j.py

Configure the login password for Neo4j in impfuzzy_for_neo4j.py (change the {password} below).

NEO4J_PASSWORD = "{password}"

How to use impfuzzy for Neo4j

To use impfuzzy for Neo4j, use these options to specify the input of malware to cluster.

  • -f - Specify malware (a file)
  • -d - Specify a folder where malware is stored
  • -l - Specify a CSV file(*) which lists malware

(*) The format of CSV files are the following:

File name, impfuzzy hash value, MD5 hash value, SHA1 hash value, SHA256 hash value

In the following example, malware is stored in the folder ‘Emdivi’ which is passed as a parameter.

Figure 3: impfuzzy for Neo4j execution result
Fig3

Clustering results are registered in Neo4j database. Visualisation is available through the web interface of Neo4j, which is accessible from the URL below (The following is an example of Neo4j installed in a local environment).

http://localhost:7474/

For visualising a graph of clustering results, a Cypher query (a command to operate Neo4j database) needs to be executed through the web interface. Figure 4 is an example of executing a Cypher query through the web interface.

Figure 4: Example of Cypher query execution
Fig4_2

Cypher queries to execute are different depending on what kind of clustering results you would like to visualise. Below are the examples of Cypher queries to visualise different clustering results.

[Example 1] Visualise all clustering results (Figure 1 is the result of the following Cypher query)

$ MATCH (m:Malware) RETURN m

[Example 2] Visualise a group of samples with a specific MD5 hash value (Figure 2 is an example of the following Cypher query)

MATCH (m1:Malware) WHERE m1.md5 = "[MD5 hash value]"
MATCH (m2:Malware) WHERE m2.cluster = m1.cluster

RETURN m2

[Example 3] Visualise all clustering results with impfuzzy similarity level over 90

$ MATCH (m:Malware)-[s:same]-() WHERE s.value > 90 RETURN m,s

Summary

Clustering large amount of malware to distinguish unknown types that needs to be analysed in a quick manner is crucial in malware analysis. We hope that impfuzzy for Neo4j will help such analysis tasks.

In a future entry, we will introduce the clustering and analysis results that we gained through this tool.

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference

[1] The Louvain method for community detection in large networks

http://perso.uclouvain.be/vincent.blondel/research/louvain.html

 

Jan 30, 2017

Anti-analysis technique for PE Analysis Tools –INT Spoofing–

When analysing Windows executable file type (PE file) malware, a tool to parse and display the PE file’s structure (hereafter “PE analysis tool”) is often used. This tool enables referring to a list of APIs that the malware imports (Import API) and functions that it exports. By analysing the data, it is possible to presume the malware’s function as in communicating with external servers or creating registry entries, etc. In this way, PE analysis tools are often used for malware analysis, however, a type of malware which has techniques to disturb operations of PE analysis tools has already been observed [1].

This entry introduces techniques to deceive analysts by displaying incorrect information in the Import API, and measures to implement in PE analysis tools against the issue.

INT (Import Name Table) and IAT (Import Address Table)

PE files contain 2 address tables related to Import API – INT and IAT. INT describes the address of the area which stores API names imported by the PE file. IAT is used when actually calling an API, and writes an entry address of the functions corresponding to the API when the module which exports the function is loaded. For more information about PE file formats, please refer to Microsoft’s website [2].

NT header in a PE file describes various kinds of information required for executing the file. NT header is structured as “IMAGE_NT_HEADERS”, and INT and IAT can be identified by tracing the address in “IMAGE_DATA_DIRECTORY” of Optional Header within the structure (Figure 1) [3].

Figure 1: INT and IAT related section within NT header in a PE file
Pe_formatfig1

The Name field of “IMAGE_IMPORT_BY_NAME” structure, which is referred to by INT, describes importing API names as a string. Generally, IMAGE_IMPORT_BY_NAME lists API names in a sequence as in Figure 2.

Figure 2: Example of IMAGE_IMPORT_BY_NAME
Pe_intfig2

INT Spoofing

IMAGE_IMPORT_BY_NAME contains strings specifying API names. Even if someone tries to alter the API name in IMAGE_IMPORT_BY_NAME to disguise it as another PE file, it would not be executed properly since it would import unintended API when executing the PE file. As the red part in Figure 3 indicates, however, if the PE file is modified by adding new API names at the end of the INT to existing API names within the INT, it will not attempt to load a module since the IAT does not have a field that stores the entry address of the functions corresponding to the added API name. If PE analysis tools display such deliberately added API names, analysts would believe that the PE file has new APIs that is imported, which would confuse the analysis.

Figure 3: Example of INT spoofing
Fake_intfig3

Check for INT-spoofed PE files using PE analysis tools

Many of the existing PE analysis tools refer to only INT when listing Import API, and recognise and display strings in IMAGE_IMPORT_BY_NAME as API names. When handling normal PE files, there is no issues with the behaviour since importing API addresses corresponding to the strings in IMAGE_IMPORT_BY_NAME, are written in the IAT.

However, if INT is spoofed by the above mentioned method, extra APIs are also listed. As an experiment, JPCERT/CC generated some INT-spoofed PE files, and tested how their Import API would be displayed in several PE analysis tools. As a result, many of them displayed extra APIs that are not actually imported.

Figure 4: Analysis examples of INT-spoofed executable files on PE analysis tools (Indicates the number of Import API increased due to INT spoofing)
Test_resultfig4

Countermeasures against INT spoofing

One countermeasure against such spoofing would be to compare INT and IAT on a PE analysis tool and only display APIs that are actually imported (and not display added API names marked in red in the Figure 3). pyimpfuzzy, which was introduced in a past blog entry, is also a tool which performs analysis based on Import API. In its first version, there was an issue where INT-spoofed samples could not be analysed correctly. As such, the tool was updated with a new feature to compare INT and IAT, and only analyse the APIs that are actually imported.

Many PE analysis tools display strings in IMAGE_IMPORT_BY_NAME as they are. However, many debuggers and IDA refer to IATs when displaying Import API, and thus most of them do not seem to be affected by INT spoofing. When referring to the information on Import API in malware analysis, it is recommended to check APIs that are actually loaded in IAT by using a debugger, as well as INT strings.

Summary

JPCERT/CC has not yet observed any INT-spoofed samples, however, this disguising technique could possibly be abused in the near future. Automated analysis tools based on Import API may be affected by INT spoofing. As introduced above, pyimpfuzzy has been updated to a new version – please make sure that you are using the latest version (version 0.02).

Thanks for reading.

- Shusei Tomonaga
(Translated by Yukako Uchida)


References:

[1] Palo Alto Networks - The Dukes R&D Finds a New Anti-Analysis Technique
    http://researchcenter.paloaltonetworks.com/2016/09/unit42-the-dukes-rd-finds-a-new-anti-analysis-technique/

[2] Microsoft - PE Format
    https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx?f=255&MSPPError=-2147217396

[3] Microsoft - IMAGE_NT_HEADERS structure
    https://msdn.microsoft.com/en-us/library/windows/desktop/ms680336(v=vs.85).aspx

Jan 25, 2017

2016 in Review: Top Cyber Security Trends in Japan

Hi, this is Misaki Kimura from Watch and Warning Group.

Another new year has come and gone, and as I look back over about the significant security trends that took place in 2016, it is needless to mention that security threat landscape is ever evolving and increasingly complex. As a basis for what we can prepare for 2017, I’d like to review security headlines in 2016 by referring to the activities carried out in Japan, to look into the expectations to come.

Increase in DDoS built by botnets such as Mirai

Large-scale botnets leveraging Internet of Things (IoT) devices to launch massive DDoS attacks, became a prominent topic worldwide. The Mirai botnet, which was responsible for the series of attacks in recent months, including the DDoS attacks against American journalist’s website “Krebs on Security”, and DNS provider “Dyn”, had brought a huge impact. The word “Mirai” is a Japanese word for “future”, and just as it is interpreted, since the release of Mirai source code last September, it has called a lot of concerns of what poorly secured IoT devices may bring in the future.

In response to this, a technical alert (in Japanese) was released on Japan Vulnerability Notes (JVN) to promote IoT device owners/users in Japan to secure their devices, and organizations were encouraged to place countermeasures towards DDoS attacks. In addition, JPCERT/CC has announced a security alert for awareness raising, and the Information-technology Promotion Agency, Japan (IPA) has also announced an alert (in Japanese) respectively.

Security guidelines concerning IoT were also published from multiple organizations during last year. “IoT Security Guide for Consumers (ver1.0)” (in Japanese) that is intended for readers such as IoT device developers and consumers to take precautions towards IoT devices was published from the Japan Network Security Association (JNSA). Furthermore, “IoT Security Guideline ver1.0” (in Japanese) was announced from the IoT Acceleration Consortium’s IoT Security Working Group, organized by the Ministry of Economy, Trade and Industry (METI) and the Ministry of Internal Affairs and Communications (MIC).

Advanced Persistent Threat (APT) becomes increasingly sophisticated

Since the Japan Pension Service hack in 2015 that led to 1.25 million cases of personal data leak, the Japanese public has been paying attention to targeted attacks than ever before. These types of attacks continued to evolve constantly by developing new tactics, techniques and procedures. Particularly in 2016, we have been observing attacks concerning to malware known as Daserf [1], Asurex [2], Sysget (aka HelloBridge, ZACOM) [3] and Elirks (aka KLURP) [4]. Though the attribution for each malware may differ, a common attack vector is observed - malware infections are attempted by convincing the user to open attachments of spear phishing emails or watering hole attacks.

Amongst all, what specifically grabbed our attention was Daserf. Not only different C2 servers were used for each targeted organization, but the C2 server for each infected device within the organization was also individual. Due to this multiplicity, blacklisting the URLs and IP addresses of C2 servers were no more an effective measure, allowing the threat actors to remain undetected for a long duration of time.

On the other hand, Elirks was also unique in terms of retrieving its C2 server’s IP address – it obtains the IP address by accessing to pre-determined microblog service or SNS. This behavior is deemed to avoid the detection of security products and to flexibly switch the C2 server specified in the content of articles posted on those legitimate services by rewriting the code in it.

In accordance to this situation, at JPCERT/CC, we released a document on “Initial Procedures and Response Guideline for Countering Advanced Persistent Threat” (in Japanese) and also “Report on the Research into Evidence of Attack Tool Execution for Incident Investigation” (released in Japanese, English version will be coming out by the end of first half of 2017 (Title is tentative)). The former aims to enhance effective incident response procedures to deal with APT by providing knowledge on how to detect, analyze and contain the attacks, while the latter aims to promote efficient investigation upon an incident by providing information on actual attack tools used by threat actors and evidence left in log files when executing those tools.

Attack cases on financial theft continues to take place

According to the report (in Japanese) released by the National Police Agency (NPA), financial loss caused by illegal money transfer using Internet banking services that occurred in the first half of 2016 has been greatly reduced both in number of victims and the amount of financial loss of credit unions and corporate accounts. To be more specific, the damage amount in the first half of 2016 was 898 million Japanese yen, which decreased from the second half of 2015 (1.53 billion Japanese yen). However, in terms of personal accounts, the number of victims and amount of financial loss were witnessed at the same level as 2015 on average.

In 2016, Online Banking Trojans that steal IDs and passwords were attached to Japanese written spam emails and sent to Japanese users. Notorious Banking Trojans that were causing damages overseas such as Ursnif (aka: Gozi, Snifula) [5], Shiotob (aka: URLZONE, Bebloh) [6] and KRBANKER [7] (in Japanese), were also beginning to target online users in Japan.

In addition, ransomware continued to keep prevalent this year as well. Based on the report (in Japanese) from TrendMicro, Japanese organizations infected with ransomware in the first half of the year reached to 1,740, which was 7 times higher compared with the same time of 2015. Regarding the amount of financial loss itself, it has become the most significant security threat amongst all to Internet users.

Lastly, one more to note - 2016 was the year for JPCERT/CC to celebrate its 20th anniversary. As long as JPCERT/CC represents as the coordination center for cyber security incidents in Japan, we will continue to endeavor to create cyber space a safer place for all through cooperation and coordination with various partners around the globe. We would like to convey our gratitude for your support and cooperation, and would like to continuously devote the utmost effort in our activities.

Thank you for reading.

- Misaki Kimura


References:

[1] http://www.lac.co.jp/security/report/pdf/cgview_vol2_en.pdf

[2] http://blog.jpcert.or.jp/2016/06/asruex-malware-infecting-through-shortcut-files.html

[3] https://www.fireeye.com/content/dam/fireeye-www/global/en/current-threats/pdfs/wp-operation-quantum-entanglement.pdf

[4] http://researchcenter.paloaltonetworks.com/2016/06/unit42-tracking-elirks-variants-in-japan-similarities-to-previous-attacks/

[5] http://blog.trendmicro.com/trendlabs-security-intelligence/ursnif-the-multifaceted-malware/

[6] http://blog.trendmicro.com/trendlabs-security-intelligence/bebloh-expands-japan-latest-spam-attack/

[7] http://blog.trendmicro.co.jp/archives/13683

Dec 22, 2016

Update from the CyberGreen Project

Hi, this is Moto Kawasaki from Global Coordination Division. It has been a little while since I wrote about the CyberGreen Project last time, and I would like to update the achievements of the Project.

The most impressive news in the first half of this fiscal year 2016 (Apr-Sep in Japan) is the renewal of its web site. Please have a look at the Info site and you'll find nice pages introducing distinguished advisers and board members of the Project, the mission statement and Project goals, and much more.

Figure 1: CyberGreen Info site
Fig_1

It is a good summary and outcome of what we have been aiming for years, and especially the Blog page shows cutting-edge stories around the Project, including investments not only from JPCERT/CC over the years, but also from the newly-joined Foreign & Commonwealth Office of the United Kingdom and Cyber Security Agency of Singapore, which proves the project is well-supported by various organizations.

If you click the Statistics tab, you'll find the Stats site that describes the Beta-2 version of the statistics with a colored map and scores by region and by AS number. These scores are based on the data from the Open Resolver Project and other data sources, as listed in the Data Inventory page. The calculation algorithm is described in the About page, and the score is a kind of density as per the formula: the natural logarithm of the number of open servers found in a region over the natural logarithm of the maximum number of nodes per country in that region, which is expressed by the score between 0 (best) and 100 (worst).

Figure 2: Colored map on Stats site
Fig_2
Figure 3: Scores indicating risks
Fig_3

With these renewed sites, we had several promotions such as CyberGreen Workshop at the APCERT Annual General Meeting & Conference 2016 (please find a blog post on the Conference here), a session on “CyberGreen: Improving Ecosystem Health through Metrics based Measurement and Mitigation Support” at the FIRST Regional Symposium for Arab and African Regions, and another CyberGreen Index proposed as “Measuring CyberGreen Readiness” at the 9th Annual National Conference on Cyber Security, Sri Lanka.

Figure 4: Green Index proposed at the Conference in Sri Lanka
Fig_4

In addition to the continued efforts by the CyberGreen Project team, there was another big news: “CyberGreen Metrics v.2 Method and Report Finalized.” As described in the news page, we will see another revision in the Info and Stats sites, hopefully in early 2017.

As such, we wish you to join CyberGreen to make the Internet safer together.

Thank you very much.

- Moto Kawasaki

Dec 16, 2016

A New Tool to Detect Known Malware from Memory Images – impfuzzy for Volatility –

Hi again, this is Shusei Tomonaga from the Analysis Center. Today I will introduce a tool “impfuzzy for Volatility”, which JPCERT/CC has created for extracting known malware from memory images and utilises for analysis operations.

Malware Detection in Memory Forensics

To judge if a file type malware sample is a known kind, the easiest and fastest way is to check the hash value (e.g. MD5 or SHA 256) of the entire file to see if it matches any of those in malware databases. However, this method is not applicable for memory forensics. This is because executable files loaded on the memory are partially altered by the OS or the malware itself (for example, when an executable file is loaded on the memory, IAT – import address table – is replaced with the API’s address loaded on the memory), and therefore hash values of the file before and after being loaded on the memory do not match.

In this sense, for memory forensics, signature matching using Yara scan is often used for detecting known malware. In order to use this method, however, details of the malware need to be analysed and also its signature needs to be generated beforehand.

Overview and Main Features of impfuzzy for Volatility

“impfuzzy for Volatility” is a tool that solves such issues and enables extracting known malware from memory images. This tool is implemented as a plugin for The Volatility Framework (hereafter “Volatility”), a memory forensics tool. To enable detection even after information in the malware executable file is partially altered when loaded on the memory, the tool uses “impfuzzy” method which compares the similarities of Windows executable files based on hash values generated from Import API. impfuzzy was introduced in a past article on this blog.

impfuzzy for Volatility offers the following functions and is applicable for investigations using imphash [1] as well.

  • impfuzzy – Compares and displays hash values of executable files in memory images using impfuzzy
  • Ÿimphashlist – Displays the imphash value of executable files in memory images
  • imphashsearch – Compares hash values of executable files in memory images using imphash

When executing the following command line, impfuzzy hash values of the executable files and DLL files loaded on the memory will be listed as in Figure 1.

$ python vol.py -f [memory.image] --profile=[profile] impfuzzy -a (-p [PID]) 
Figure 1: Executable files in memory images and their hash values
Acreportimpfuzzy_volatility_01

To search memory images for files which are similar to certain executable files, the following command line can be executed.

$ python vol.py -f [memory.image] --profile=[profile] impfuzzy -e [PE File or Folder] (-p [PID])

The executable file to compare with or the folder where it is stored can be specified as option “-e”.

By executing the above command line, similar executable files can be detected as in Figure 2 (The “Compare” field indicates the similarity by percentage).

Figure 2: Detecting similar files from memory images
Acreportimpfuzzy_volatility_02

Figure 2 demonstrates the example where Citadel, a type of banking malware, is detected. Citadel is usually packed and starts running by injecting unpacked code into Explorer, etc. impfuzzy for Volatility compares executable files loaded on the memory, which makes it possible to calculate hash values of unpacked samples. Therefore, similarities can be judged even for packed malware.

impfuzzy for Volatility can also detect code that is injected into processes, as well as executable files and loaded DLL files. In Figure 2, “INJECTED CODE” in the “Module Name” field indicates that there is code injected into the processes.

The following shows other options that are available in impfuzzy for Volatility.

(Example 1) Compares impfuzzy hash values listed in the file with executable files in the memory, and displays the results:

$ python vol.py -f [memory.image] --profile=[profile] impfuzzy -i [Hash List File] (-p [PID])

(Example 2) Lists imphash values of executable files loaded on the memory

$ python vol.py -f [memory.image] --profile=[profile] imphashlist (-p [PID])

(Example 3) Compares imphash values listed in the file with executable files in the memory, and displays the results that match

$ python vol.py -f [memory.image] --profile=[profile] imphashsearch -i [Hash List] (-p [PID])

Advantages of Using impfuzzy in Memory Forensics

Even though executable files loaded on the memory are partially altered as previously discussed, their Import API remain the same. impfuzzy judges the similarity based on hash values derived from Import API of the executable files. This makes it possible to identify the same file even from executable files loaded on the memory.

Furthermore, since impfuzzy can generate hash values automatically, unlike Yara scan, there is no need to generate signatures manually.

Obtaining and Installing impfuzzy for Volatility

This tool is available on GitHub, a shared web service for software development projects. Feel free to download from the following website for your use:

JPCERTCC/aa-tools GitHub - impfuzzy for Volatility
https://github.com/JPCERTCC/aa-tools/tree/master/impfuzzy/impfuzzy_for_Volatility

In order to use this tool, the following Python module needs to be installed.

  • Ÿpyimpfuzzy

Please see the following website regarding installation of pyimpfuzzy.

https://github.com/JPCERTCC/aa-tools/tree/master/impfuzzy/pyimpfuzzy

When executing, impfuzzy.py needs to be installed from the aforementioned website, stored in the “contrib/plugins” folder in Volatility and then executed. (It is also possible to specify the folder where impfuzzy.py is stored using option “--plugins”.)

Summary

Memory may contain some information including malware that is not left on the hard disk, and therefore memory forensics is important in incident investigations involving malware infection. We hope that this tool is utilised as to effectively conduct investigations on memory forensics in such security incidents.

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference:

[1] FireEye - Tracking Malware with Import Hashing
https://www.fireeye.com/blog/threat-research/2014/01/tracking-malware-import-hashing.html

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)
161025e_0200

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: https://www.apcert.org/apcert2016/program.html)

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

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