11 posts categorized "#Incident management" Feed

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

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

Dec 05, 2016

Evidence of Attackers’ Development Environment Left in Shortcut Files

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

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

Information Contained in Shortcut Files

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

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

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

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

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

Classification of Shortcut Files Used in Actual Attacks

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

  • Volume serial number
  • NetBIOS name
  • MAC address

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

Figure 1: Shortcut file clustering
Visualization_eng

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

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

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

Attackers’ Environment Identified from Shortcut Files

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

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

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

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

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

Summary

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

Thank you for reading – see you soon.

- Shusei Tomonaga

(Translated by Yukako Uchida)


References:

[1] Microsoft - [MS-SHLLINK]: Shell Link (.LNK) Binary File Format
  https://msdn.microsoft.com/en-us/library/dd871305.aspx

[2] IETF - RFC 4122 - A Universally Unique IDentifier (UUID) URN Namespace
  https://tools.ietf.org/html/rfc4122.html

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

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

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

Nov 10, 2016

APT workshop and Log analysis training in Jakarta

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

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

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

The first day had come.

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

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

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

All trainees worked on the training seriously
1

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

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

Heated discussion at hands-on training
2

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

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

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

We were deeply impressed by their great answers
3

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

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

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

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

Selamat tinggal!

All of us had a wonderful time at the banquet
4

May 25, 2016

Classifying Malware using Import API and Fuzzy Hashing – impfuzzy –

Hello all, this is Shusei Tomonaga again.

Generally speaking, malware analysis begins with classifying whether it is known malware or not. In order to make comparison with the enormous number of known malware samples in the database in a speedy manner, hash values are used, derived by performing hash functions to the malware sample.

Among the different hash functions, traditional ones such as MD5 and SHA1 derive totally different hash values if the input data is different even by 1 bit. So this would not be useful when you have a sample that is similar to a known malware, and would like to classify it as “known”.

These days, malware used in attacks is mostly customised for each case, so it is ideal to use hash functions which can classify those samples as similar to known ones.

Therefore, fuzzy hash function (of which the hash value for modified codes is close to that of the original codes) is used if modifications are simple and mechanical, and for Windows executable file samples, imphash [1] (import hash) is used, which calculates values from PE (portable executable)’s import table.

One of the known examples of fuzzy hash is ssdeep [2].

However, there are various issues with these methods used for malware classification; hash values derived by ssdeep often do not coincide with the similarity of malware samples, while imphash derives different values once new functions are added to the malware.

This blog article proposes a new method “impfuzzy”, and demonstrates how it can accurately classify similar malware, in comparison to existing methods.

impfuzzy

The proposed method, as in imphash, calculates values from Import API, however, it also uses Fuzzy Hashing to calculate hash values of Import API, in order to supplement the shortcomings of imphash. With this process, a close value will be derived if just a part of Import API was added or modified.

Furthermore, it reduces time for calculation and enables efficient comparison by specifying the object of the hash value calculation to Import API (and not to the Fuzzy Hashing value of the whole executable file).

Implementing impfuzzy

“pyimpfuzzy”, a Python module for calculating and comparing impfuzzy, is available on GitHub (a public web service for software development projects). Feel free to download it from the following URL for your use:

JPCERTCC/aa-tools GitHub - impfuzzy

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

Volatility Plugin is also released on the portal, which searches for similar files based on hash values of executable files loaded from memory images by using impfuzzy.

In order to use pyimpfuzzy, the following tools need to be installed.

For this implementation, ssdeep is used as Fuzzy Hashing.

pyimpfuzzy has the following functions:

  • get_impfuzzy: calculates hash values from selected PE files
  • get_impfuzzy_data: calculates hash values from PE files in a data format
  • hash_compare: compares two hash values and returns the degree of similarity within the range of integer 0-100 (100 when same)

The similarity of the two PE files is calculated as follows:

import pyimpfuzzy
import sys

hash1 = pyimpfuzzy.get_impfuzzy(sys.argv[1])
hash2 = pyimpfuzzy.get_impfuzzy(sys.argv[2])
print "ImpFuzzy1: %s" % hash1
print "ImpFuzzy2: %s" % hash2
print "Compare: %i" % pyimpfuzzy.hash_compare(hash1, hash2)

The following result is derived when executing the above script:

Impfuzzy

Evaluation of impfuzzy

This section describes the results of an experiment of comparing, and evaluating, how the 3 different methods (proposed impfuzzy, imphash and ssdeep) are capable in classifying similar types of malware.

For the experiment, 10 different samples for 20 types of malware (200 samples in total) were prepared. For all the combinations that select two samples out of the 200, the similarities of the samples were calculated using the three methods. The two samples were classified as the same if the calculated value was 30 and larger.

For the experiment, packed samples were unpacked beforehand.

Figure 1 shows the results of the experiment.

There were no false positives detected which classified different types of malware as the same.

Figure 1: Success rates of malware type classification among impfuzzy, imphash and ssdeep
Comp_eng

*1 The threshold value for classifying the same malware type is set as 30, for impfuzzy and ssdeep

*2 ssdeep’s target of comparison is the whole executable file

The results reveal that impfuzzy is more capable of classifying the same malware type than the other two methods. For the details of the results, please see Appendix A.

This method judges the samples’ similarities based on Import API, and therefore it is clear that the identification rates are higher for samples whose malware generation tools (builders) are publicly available (e.g. Pony and ZeuS), because their Windows API rarely change. On the other hand, samples whose functions are frequently updated or changed (e.g. Emdivi) have lower rates.

For the experiment, the threshold value for impfuzzy was set as 30, however, it may detect false positives depending on the executable files. We recommend adjusting the threshold value for each executable file.

In case impfuzzy is not applied effectively

Some malware have few Import APIs.

For example, some samples called downloader use only around 5 Windows APIs. For those samples, impfuzzy may not be able to compare the hash values accurately due to the limited size of data to compare. Also, samples generated by .NET Framework have different mechanisms from applications which directly execute Windows API. Therefore, hash values for those samples cannot be calculated.

Summary

In the current situation where huge numbers of malware samples emerge day by day, it is important to efficiently classify malware samples, and identify new ones which need to be analysed. We believe that the method introduced here will be one approach to support this process.

Also, Volatility Plugin that we released together with impfuzzy, is useful for memory forensics to check malware infection.

Since this tool can calculate hash values of samples which are unpacked in the memory, it is capable of judging the similarities of the samples, even if the malware is packed.

This Plugin is available at the following URL. We will introduce this tool on this blog at another occasion.

JPCERTCC/aa-tools GitHub – impfuzzy for Volatility

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

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

[2] Fuzzy Hashing and ssdeep

http://ssdeep.sourceforge.net/

Appendix A

Comparison of impfuzzy, imphash and ssdeep

Table 1: Malware Identification Rate
Typeimpfuzzy (%)imphash (%)ssdeep (%)
Agtid 100 35.6 26.7
BeginX Server 15.6 11.1 11.1
IXESHE 196 44.4 4.4 2.2
IXESHE 2 28.9 6.7 2.2
IXESHE 2sw 100 15.6 17.8
Daserf 35.6 4.4 4.4
Dyre 100 6.7 2.2
Fucobha 44.4 4.4 2.2
Gstatus 60 4.4 2.2
Hikit 64.4 35.6 6.7
Netwire 80 15.6 28.9
NfIpv6 24.4 4.4 4.4
Emdivi t17 37.8 0 0
Emdivi t20 4.4 0 0
plurk 15.6 6.7 11.1
Derusbi 80 8.9 8.9
Pony 95.6 15.6 0
sregister 100 11.1 15.6
Sykipot 8.9 0 2.2
ZeuS 80 35.6 35.6

*Types of malware used in this experiment are those analysed and classified by JPCERT/CC.

Jan 26, 2016

Windows Commands Abused by Attackers

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

In Windows OS, various commands (hereafter “Windows commands”) are installed by default. However, what is actually used by general users is just a small part of it. On the other hand, JPCERT/CC has observed that attackers intruding into a network also use Windows commands in order to collect information and/or to spread malware infection within the network. What is worth noting here is the gap between those Window commands used by general users and by attackers. If there is a huge difference, it would be possible to detect or limit the attackers’ behaviour by monitoring/controlling the Windows command execution.

This entry will demonstrate how to mitigate the attack impact by revealing Windows commands that attackers use on the intruded Windows OS, and by restricting the execution of those commands that are unnecessary for general users.

Malware for remote control (Remote Access Tool/Trojan – RAT) has a function to execute shell commands from a remote environment. With this, attackers can execute Windows commands from a remote environment.

Attackers who successfully installed such malware in a network will attempt to take control of the system within the network in the following sequence in order to collect confidential information, etc.

  1. Initial investigation: Collect information of the infected machine
  2. Reconnaissance: Look for information saved in the machine and remote machines within the network
  3. Spread of infection: Infect the machine with other malware or try to access other machines

Windows commands are used in all of the phases above. Respective Windows commands used in each phase are introduced here below.

Initial Investigation

Table 1 lists the commands that are often used by attackers in an attempt to collect information of the infected machine. “Times executed” is derived from the sum of Windows commands used by 3 different attack groups in their respective C&C servers (Please refer to Appendix A, B and C for details).

Table 1: Initial Investigation (Top 10 commands)
RankingCommandTimes executed
1 tasklist 155
2 ver 95
3 ipconfig 76
4 systeminfo 40
5 net time 31
6 netstat 27
7 whoami 22
8 net start 16
9 qprocess 15
10 query 14

Attackers use commands such as “tasklist”, “ver”, “ipconfig” and “systeminfo”, etc., and collect information of the network, process and OS in order to investigate what kind of machine they succeeded in infecting. This is presumably how they make sure that the machine is not a sandbox for malware analysis purposes and so on.

Reconnaissance

Commands shown in Table 2 are often used to search for confidential information and remote machines within the network.

Table 2: Reconnaissance (Top 10 commands)
RankingCommandTimes executed
1 dir 976
2 net view 236
3 ping 200
4 net use 194
5 type 120
6 net user 95
7 net localgroup 39
8 net group 20
9 net config 16
10 net share 11

Attackers use “dir” and “type” to search for files. Sometimes they collect a list of all the document files in the infected machine by setting appropriate options and arguments for “dir” command.

For searching networks, “net” is used. In particular, the following commands are often seen:

  • net view: Obtain a list of connectable domain resources
  • net user: Manage local/domain accounts
  • net localgroup: Obtain a list of users belonging to local groups
  • net group: Obtain a list of users belonging to certain domain groups
  • net use: Access to resources

Furthermore, the following commands may be used in an environment where Active Directory is used (Please refer to Table 5 in Appendix A). These commands are installed in Windows Server and do not originally exist in client OS such as Windows 7 and 8.1 – but attackers download and install these commands from outside and execute them.

  • dsquery: Search for accounts in Active Directory
  • csvde: Obtain account information in Active Directory

Spread of Infection

To intrude remote machines and spread malware infection within the network, the following commands are often executed:

Table 3: Spread of Infection
RankingCommandTimes executed
1 at 103
2 reg 31
3 wmic 24
4 wusa 7
5 netsh advfirewall 4
6 sc 4
7 rundll32 2

*”wmic” is also used for reconnaissance.

“at” and “wmic” are often used to execute malware on remote machines.

With “at” command, attackers can execute commands on remote machines, by registering tasks to execute files against connectable machines as follows.

at \\[remote host name or IP address] 12:00 cmd /c "C:\windows\temp\mal.exe"

Also, by setting the following options and arguments with “wmic” command, attackers can execute commands on remote machines.

wmic /node:[IP address] /user:”[user name]” /password:”[password]” process call create “cmd /c c:\Windows\System32\net.exe user”

Restricting Execution of Unnecessary Windows Commands

It is fair to say that these Windows commands used by attackers include those that are unused by general users, if carefully selected. With AppLocker and software restriction policy, which restrict such commands from being executed, it would be possible to limit the attackers’ behaviour. For example, if you wish to restrict “net” commands, you can set rules as in Figure 1. (For details of AppLocker configuration, please see Microsoft’s Website [1]).

Figure 1: AppLocker Rules
Figure1

Also, by enabling AppLocker, events where selected Windows commands were executed or attempted but denied will be recorded in the event logs, which can be utilized for investigation on Windows commands that attackers executed after infecting the machine with malware.

Figure 2: Logs of the Processes Restricted by AppLocker
Figure2

AppLocker can also just monitor Windows commands [2]. With this, AppLocker cannot prevent unintended Windows commands from being executed, but the execution history will be recorded in the event log. If the users themselves use Windows commands that may be used for attacks, it is a good idea to set AppLocker just for monitoring purpose. (Windows command execution can also be monitored by activating “Audit Process Creation” in the local security policy.)

Conclusion

In targeted attacks, attackers not only use functions implemented in the malware, but also often use Windows commands to pursue their purposes. If such activities can be hindered, spread of incidents can be prevented in a fairly early stage. However, it may be difficult to limit the usage of Windows commands right away – so our recommendation is to start by collecting logs of executed processes by using AppLocker, etc.

Thank you for reading and best wishes for the New Year!

- Shusei Tomonaga


Reference:

[1] Microsoft - Windows AppLocker
https://technet.microsoft.com/en-us/library/dd759117.aspx

[2] Microsoft – Using Auditing to Track Which Applications Are Used

https://technet.microsoft.com/en-us/library/dd723693%28v=ws.10%29.aspx

Appendix A: List of Executed Commands by respective Attack Groups (Attack Group A)
Table 4: Initial Investigation (Attack Group A)
RankingCommandTimes executedOption
1 tasklist 119 /s /v
2 ver 92
3 ipconfig 58 /all
4 net time 30
5 systeminfo 24
6 netstat 22 -ano
7 qprocess 15
8 query 14 user
9 whoami 14 /all
10 net start 10
11 nslookup 4
12 fsutil 3 fsinfo drives
13 time 2 /t
14 set 1

Table 5: Reconnaissance (Attack Group A)
RankingCommandTimes executedOption
1 dir 903
2 net view 226
3 ping 196
4 net use 193
5 type 118
6 net user 74
7 net localgroup 35
8 net group 19
9 net config 16
10 net share 11
11 dsquery 6
12 csvde 5 /f /q
13 nbtstat 5 -a
14 net session 3
15 nltest 3 /dclist
16 wevtutil 2

Table 6: Spread of Infection (Attack Group A)
RankingCommandTimes executedOption
1 at 98
2 reg 29 add export query
3 wmic 24
4 netsh advfirewall 4
5 sc 4 qc query
6 wusa 2
Appendix B: List of Executed Commands by respective Attack Groups (Attack Group B)
Table 7: Initial Investigation (Attack Group B)
RankingCommandTimes executedOption
1 tasklist 29 /m /svc
2 whoami 6
3 ipconfig 5 /all
4 net start 4
5 netstat 3 -ano
6 nslookup 3
7 ver 2
8 time 1 /t

Table 8: Reconnaissance (Attack Group B)
RankingCommandTimes executedOption
1 dir 62
2 net user 21 /domain /add
3 net view 9 /domain
4 ping 4
5 net localgroup 4 /add
6 tree 3 /F
7 type 2
8 net group 1 /domain

Table 9: Spread of Infection (Attack Group B)
RankingCommandTimes executedOption
1 at 5
2 wusa 5
3 reg 2
4 rundll32 2
Appendix C: List of Executed Commands by respective Attack Groups (Attack Group C)
Table 10: Initial Investigation (Attack Group C)
RankingCommandTimes executedOption
1 systeminfo 16
2 ipconfig 13 /all /?
3 tasklist 7
4 netstat 5 -ano
5 whoami 2
6 net start 2
7 arp 1 -a
8 chcp 1
9 net time 1
10 ver 1

Table 11: Reconnaissance (Attack Group C)
RankingCommandTimes executedOption
1 dir 11
2 net user 1 /all /?
3 net view 1
4 qwinsta 1 -ano

*Commands for “Spread of Infection” by Attack Group C are omitted since they did not spread the infection.

Nov 06, 2015

Emdivi and the Rise of Targeted Attacks in Japan

You may well have heard of the May cyber attack in Japan against the Japan Pension Service – a high-profile case seen in the first half of this year, where 1.25 million cases of personal data was exposed. According to the Japan Pension Service, the data leaked included names and ID numbers, and for some cases, dates of birth and home addresses.

The official reports(1) say that the massive leak was caused by attackers hacking Japan Pension Service staff computers through a malicious email attachment, which was disguised as a legitimate document, but in fact was a malware. According to other various sources, the malware used is said to be “Emdivi.” This classic ploy, or targeted attack, has been around for years – however, Japan is recently experiencing a rise in this attack.

According to the National Police Agency, the number of targeted email attacks they have recognized count up to 492 cases in 2013, 1,723 in 2014 and 1,472 in the first half of 2015 alone.

Figure 1: Number of Targeted Attacks Recognized by the National Police Agency [Click to enlarge image]

Source: Cyberspace Threat Landscape in the first half of 2015 https://www.npa.go.jp/kanbou/cybersecurity/H27_kami_jousei.pdf (Japanese only)

Note: The title/figure have been translated by JPCERT/CC

Figure1en

Emdivi is notoriously used in these targeted attacks, and what is distinct is that it specifically focuses on Japanese targets. The Japan Pension Service indeed drew nationwide attention, but Emdivi has victimized several other government and private organizations. This attack campaign, specifically targeting Japan, is also known as “CloudyOmega” named by Symantec, or “Blue Termite” by Kaspersky.

Following this trend, JPCERT/CC newly added a “targeted attack” category in its Incident Handling Report (April – June 2015), to count the number of targeted attack incidents reported to JPCERT/CC.

Figure 2: Category of Incidents Reported to JPCERT/CC (April – June 2015) [Click to enlarge image]

Source: JPCERT/CC

Figure2

Although targeted attack accounts for a mere 1.4%, the significance and impact of the attack has forced to take as much as half the resource of our Incident Response Group, according to the Group’s Manager. During the quarter, JPCERT/CC notified 66 organizations on the possibility of being victimized by targeted attacks, of which 44 were related to Emdivi. Based on the reports received, JPCERT/CC investigated the malware and attack infrastructures (C&C servers, etc.), and also developed a tool for visualizing the relation of Indicators of Compromise (IOCs) for further analysis. The visualization is shown in Figure 3.

Figure 3: Visualization of the Relation of IOCs [Click to enlarge image]

Source: JPCERT/CC

Figure3_final

This tool aims to sort out various information relating to targeted attacks, and to give an overall picture of what is going on. While various campaigns and attack groups have been observed by security related organizations, the same campaign may have different names (as mentioned above), or different campaigns may have similar attack methods. This could cause confusion when you want to find out where a certain piece of indicator information was observed. This tool was developed to resolve this confusion. By registering the IOCs of respective attack campaigns and incidents, and also the relation of the IOCs, it is designed to visualize the big picture of the attack.

Based on these analyses, JPCERT/CC engages in sharing information with organizations that may potentially become the next target, as well as notifying organizations that are presumed to be victimized already. As Emdivi is also known for cleverly hiding itself, there is a high possibility that still several organizations are unaware of the situation, even if they are already infected. JPCERT/CC will continue to make every effort to address such situations in cooperation with other relevant parties.

In the next blog posts, our Analysis Center will introduce technical knowledge on JPCERT/CC’s tools, developed to detect malware in targeted attacks as well as to analyze Emdivi. See you again there!

- Keishi Kubo and Shiori Kubo


Reference

(1) Official Reports:

Note: The titles of the reports have been translated by JPCERT/CC

    Oct 21, 2015

    The 5th CERT-RO Annual International Conference in Bucharest and Latest Cyber Security Trends in Romania

    Hello again, it’s Yuka at the Global Coordination Division.

    Following my recent trip to Malaysia to join APCERT Annual General Meeting and Conference 2015, I had my first travel to Europe – and that was to Bucharest, Romania to attend a conference hosted by CERT-RO, the National CSIRT of Romania. They host a conference annually, and this year it was the 5th time for this event, held from 5th - 6th October.

    The programme on the first day morning consisted of two panel discussions, with global and Romanian national focus on cyber security. Experts were invited from different stakeholders to exchange ideas on the recent cyber threats, law enforcement and policies, etc. For the afternoon session, the following CSIRTs around the globe including JPCERT/CC, who have partnerships with CERT-RO, delivered a short presentation about their activities.

    ALCIRT (Albania)

    CERT-EE (Estonia)

    CERT.lv (Latvia)

    KrCERT/CC (South Korea)

    South African Government CSIRT (South Africa)

    I myself presented briefly about JPCERT/CC, its organisation overview, the latest incident statistics and some ongoing projects, including TSUBAME and Cyber Green.

    Dscf11911

    (Photo of me speaking: provided by CERT-RO)

    It was interesting to hear each CSIRT’s organisational structure, including which ministry they belong to and different range of authority that each CSIRT has over their local ISPs and users. It was also a great opportunity to build bridges to CSIRTs that are located far away from Japan.

    Through the panel sessions in the morning about local trends in cyber security in Romania, and a presentation provided by a CERT-RO colleague in the afternoon, here below are some things that I learned about cyber-related matters in Romania:

    • CERT-RO, established in 2011, is operated under the Ministry of Communications and Information Society.
    • Following the enactment of Romanian Cyber Security Strategy in 2013, the Romanian government (together with CERT-RO) is now preparing cyber security related laws on ISPs’ responsibilities in case of incidents.
    • CERT-RO has been focusing on awareness raising campaigns and trainings in local communities (e.g. incident handling, malware analysis).
    • CERT-RO provides internship programs for students majoring in cyber security related studies.
    • Most common malware observed in Romania are Downadup and Zeus. Statistics show that about 10% of IP addresses located within Romania are infected with conficker.
    • There are many cases where Romanian IP addresses are used for attacks as proxies.

    One of the outcomes of the collaboration between JPCERT/CC and CERT-RO is that we have provided our “IT Security Inoculation kit” based on our discussion during our previous year’s visit to Bucharest. This is a tool that JPCERT/CC has developed for awareness-raising purposes against targeted email attacks with malicious attachments and the like. Designed for implementation at organisations such as companies, it has a feature to send emails that attract the recipients’ attention by indicating relevant topics such as internal business communications, latest news topics, questionnaires, etc., and attempts to induce them to open attached files or click on URLs (which actually is harmless!). It gives warning to those who were trapped about the risks that may involve, and at the same time, allows examiners to keep track of who actually opened the attachments/links. This feature enables examiners to analyse the tendency of examinees’ behaviours, and also how their performance improves if tested repeatedly. Since CERT-RO has been working on awareness-raising programs in the local community, they found the tool useful and implemented it in several organisations within Romania. We are happy that CERT-RO liked it – and hope to keep collaborating in this field and others!

    We would like to thank CERT-RO colleagues again for their kind hospitality and invitation to the great event.

    Thanks for reading and see you soon.

     - Yukako Uchida

    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.

    Berlinpic1_2

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

    Berlinpic2_3

    (Photo by Hiroshi Kobayashi)

    - Takayuki (Taki) Uchiyama

    Jun 30, 2015

    APWG eCrime 2015 and Phishing Trends in Japan

    Hola!  This is Shoko from Incident Response Team.  Last month I attended the APWG eCrime 2015, held from May 26-29 in Barcelona – the cosmopolitan capital of Spain’s Catalonia region, defined by quirky art and architecture, imaginative cuisine and siesta.

    Today, I’d like to share an overview of the APWG eCrime 2015 and my presentation there on “Phishing Trends in Japan.”

    About APWG and APWG eCrime 2015

    You may well know that APWG, founded in 2003 as the Anti-Phishing Working Group, is the global coalition of industry, government and law-enforcement sectors, focused on unifying the global response to cybercrime.  APWG provides a forum to discuss phishing and cybercrime issues, to consider potential technology solutions, and more, with over 2,000 institutions participating worldwide.

    The APWG eCrime (Symposium on Electronic Crime Research) 2015 is one of APWG’s rotation of global meetings, held in Europe this time, bringing together a variety of participants from the law enforcement, financial institutions, security vendors, CSIRTs and more.

    At the event, I joined a panel session focusing on cybercrime trends from APWG members around the globe, namely from MyCERT, CERT.br and CNNIC, and presented on Japanese phishing trends in 2014.

    Phishing Trends in Japan

    The following graph shows the number of phishing incidents reported to JPCERT/CC since 2012.

    Figure 1: Trend of phishing sites observed at JPCERT/CC
    Figure1_4

    The red block shows the number of overseas brand phishing sites (phishing sites spoofing overseas brand websites), and the blue block shows the number of Japanese brand phishing sites (phishing sites spoofing Japanese brand websites).

    The number of overseas brand phishing sites has always been observed at a certain level, but what is interesting is that the number of Japanese brand phishing sites showed a sharp spike at the end of 2013, and then dropped significantly in August 2014.  There could be several reasons for this, but one noteworthy event is that in November 2014, the Japanese police arrested cyber criminals who had illegally set up malicious infrastructures for phishing purposes.  We assume that the timing of their investigation (prior to the arrest), had some relation to the sudden drop of phishing incidents reported to JPCERT/CC.  At that time, we also worked closely with relevant ISPs to investigate the case, and provided information to relevant parties from a technical standpoint.  This case was also covered in the National Police Agency’s presentation during APWG eCrime 2015. 

    The following graphs show the top categories for overseas and Japanese brand phishing sites.

    Figure 2: Industry breakdown of overseas brand phishing
    Figure2_10
    Figure 3: Industry breakdown of Japanese brand phishing
    Figure3_18

    The top category for both is Financial, but interestingly, Gaming comes second for Japanese brand phishing sites.  This could be one unique observation in Japan, as one of the famous gaming superpowers.

    In Summary

    The APWG eCrime 2015 was a significant place to strengthen collaboration among persons/organizations pursing the same goal, and to have productive and lively conversations.  Throughout this experience, I strongly reconfirmed the importance of close collaboration among relevant parties, which is the key to combat against cyber incidents and criminals.

    Well, of course it was Barcelona – Iberian pork and black paella were wonderful, but I would like to add that “agua con gas” (sparkling water) was also good!

    Thank you for reading my post.

    Barcelona

    - Shoko Nakai