10 posts categorized "#Incident management" Feed

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

    Nov 08, 2013

    Information Security Incident Management Standard under Revision

    Hi, it's Masaki Kubo. I’ve just returned from my trip to Incheon, Korea, where we had an ISO/IEC JTC 1/SC 27 meeting on standardization of IT security techniques. JPCERT/CC has been engaged in this standardization effort through the Japanese national body over the past years, and I participated particularly in the revision work of ISO/IEC 27035:2011 on information security incident management.

    ISO/IEC 27035:2011 was published in 2011 and right after its publication, it was called for the so-called "early revision" [1]. Now the experts have divided the document into 3 parts for review:

    - 27035 Part 1:
        Principles of incident management

    - 27035 Part 2:
        Guidelines to plan and prepare for incident response

    - 27035 Part 3:
        Guidelines for incident response operations

    All 3 parts are now in the 3rd Working Draft (WD) stage, and it was just agreed to go into the 4th stage. Since the WD documents are not official ISO documents yet, we still have the right to propose amendments to them. If the documents pass the 4th WD stage, they will then be proceeded to the 1st Committee Draft (CD) [2].

    27035 Part 1 inherits most of the text from the published standard 27035:2011 and is summarized to address only the principles: what is incident management, what steps should be taken to prepare for incidents and to respond to them, etc. Because this part gives the overall structure for 27035 Part 2 and 3, it should be well elaborated, and in this sense, I think it has achieved good maturity for the 3rd WD stage. Incident management phases mentioned in 27035 Part 1 include the following 6 phases:

        - Plan and Prepare
        - Detection and Reporting
        - Assessment and Decision
        - Responses
        - Post Incident Activity
        - Lessons Learnt

    27035 Part 2 gives guidelines to prepare for incidents. Japan contributed several comments to restructure the overall document, which were well accepted by the editor. Now the structure of Part 2 is in sync with the incident management phases referred to in Part 1. Topics covered in this part include:

        - Establishing information security incident management policy
        - Creating information security incident management scheme.
        - Establishing an Incident Response Team (IRT)
        - Defining technical and other support
        - Creating information security incident awareness and training
        - Testing the information security incident management scheme
        - Lessons Learnt

    Although the structure of the document is getting in better shape, it requires more body text, thus we are seeking for more contribution from the national bodies.

    27035 Part 3 gives a guideline for incident handling operations. This is an operational guideline and the current discussion may not be neutral enough for an ISO document. Also, it still lacks the structure that draws ease of comprehension. However, the overall text is improving and I hope it will settle better before we move on to the CD stage.

    There already exists several best practice guides on incident management, and you may question why another one from ISO. One way to answer is we have standardization projects in SC 27/WG 4 around incidents such as digital forensics, data storage security, SIEM, etc., and cannot omit incident management. Another way to answer is there are people who wish to refer to neutral, standardized guidelines, and ISO is the place to offer them.

    JPCERT/CC wishes to continue making contribution to this project, so that the standardization will be in consistency with the practice of the CSIRT community.

    Last but not least, FIRST (Forum of Incident Response and Security Teams) has also established a liaison relationship with ISO/IEC JTC 1/SC 27. If you are a FIRST Member and would like to contribute to this project, please visit FIRST’s website on ISO Activities for further information. Even if you are not a FIRST Member, there are several ways you can submit your comments to ISO:

    - Your organization may have a person who is already involved in the standardization effort so you can work with that person.

    - You can work with your national standardization body.

    Whichever avenue you choose to use, your contribution will be much appreciated.

    - Masaki Kubo


    [1] According to the standard procedure, all international standards are reviewed at least every five years.

    [2] After going through the CD, the documents will go to the Draft International Standard (DIS) stage, and then to the Final Draft International Standard (FDIS) stage, which then finally become issued as official ISO documents.