55 posts categorized "#JPCERT news" Feed

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/impfuzzy/tree/master/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/impfuzzy/tree/master/pyimpfuzzy

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

Summary

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

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference:

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

Nov 16, 2016

APCERT Annual General Meeting & Conference 2016 in Tokyo and JPCERT/CC’s 20th Anniversary

Hi all, this is Yuka from Global Coordination Division and also serving as APCERT Secretariat.

We are happy to announce that we have just finished one of the big tasks for this year – the host of APCERT Annual General Meeting & Conference 2016, which was held on 24-27 October at Royal Park Hotel in Tokyo. After the official establishment of APCERT in 2003, its annual conference had never been held in Tokyo. There was, though, a meeting in 2002 as Asia Pacific Security Incident Response Coordination Conference (APSIRC; the predecessor of APCERT) where forming a community for CSIRTs in the Asia Pacific region was discussed. Strangely enough, the Conference in 2002 was also held in the same hotel – we actually booked the venue without knowing the fact. We were so thrilled to know about the chance.

The Conference was run for four days:

24 Oct: Working Group Meetings, Team Building, Welcome Cocktail

25 Oct: TSUBAME Workshop, CyberGreen Workshop, Steering Committee Meeting

26 Oct: Closed Conference, Annual General Meeting, Gala Dinner

27 Oct: Open Conference

(Photo taken during TSUBAME Workshop – trainees working on some hands-on exercise)
161025e_0200

From Day 1 through to 3, sessions for APCERT members and invited guests were conducted, and Day 4 was an open session including the general public. Altogether we had APCERT Operational Members from 23 teams of 18 economies in Asia Pacific, Supporting Members, global partners, sponsors and some local guests – which counted up to approximately 200 people. The Conference was themed “Borderless Cooperation, Seamless Action – Towards a Cleaner, Greener Cyber Space –“, which indeed reflects the aim of this community. The Conference program on the 27th was arranged based on “Call For Papers”, with presentations which covered a wide range of topics on recent technical trends and concluded with a panel discussion on CSIRT operations as below.

- IoT Threat and IoT Botnet

- Protecting CNII against Malware Threats: A Coherent Response through Cooperation Amongst OIC Countries

- APT Campaign Targets Japanese Critical Infrastructure

- Ransomware Tracking and AP Region Footprint

- Who’s That Knocking on My Back Door: A Jboss Case

- Sophisticated Financial Fraud Malware (Mobile) in Korea

- Collaborative Research for Development of CSIRTs in Vietnam

- Best Practices and Common Missteps in Responding to Major Incidents

- Engaging the ISPs in Effective National Network Abuse Handling

(Programs available here: https://www.apcert.org/apcert2016/program.html)

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

What made this event special was not only the fact that it was hosted in Tokyo for the first time as APCERT, but also that it coincided with the 20th anniversary for JPCERT/CC.

Being established in October 1996, as one of the oldest CSIRTs in the world, JPCERT/CC has been contributing in creating a safer cyber security environment both in Japan and across the globe. To look back over the activities from internal and external perspectives, a symposium was held on 28 October inviting local partners. The symposium contained presentations from JPCERT/CC staff and partners providing the history of activities and ideas for future plans, which was followed by a social cocktail.

What these two events brought us is the fact that JPCERT/CC has been supported by various partners locally and globally. For the anniversary event, some of our foreign counterpart organisations kindly sent us video messages with the words of celebration. From local communities, we received feedbacks about our activities, some positive evaluations and also encouragement. Indeed, since JPCERT/CC is a “Coordination Center”, our activities require coordination with various entities, and creating a safer cyber space cannot be accomplished without the support of such local and global partners. We hope that both events were good opportunities to show our gratitude for the special partnership for the past 20 years, and we look forward to continuing and developing the relationship for the next 10 years and more.

Thanks for reading.

- Yukako Uchida

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

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

Jul 08, 2016

Japan Vulnerability Notes (JVN) Site Update

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

Some coordinated vulnerability disclosures in April 2016

http://blog.jpcert.or.jp/2016/05/some-coordinated-vulnerability-disclosures-in-april-2016.html

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

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

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

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

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

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

Until next time,

Takayuki (Taki) Uchiyama

May 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/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/impfuzzy/tree/master/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
Type impfuzzy (%) 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

 

May 06, 2016

Some coordinated vulnerability disclosures in April 2016

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

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

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

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

The first case is,

JVNVU#92116866 – Published on 2016/4/26
(https://jvn.jp/vu/JVNVU92116866/index.html)

Keitai Kit for Movable Type vulnerable to OS Command Injection.

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

Versions affected are 1.35 through 1.641.

Attacks in the wild leveraging this vulnerability have been confirmed.

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

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

The second case is,

JVNVU#90405898 – Published on 2016/4/27
(https://jvn.jp/vu/JVNVU90405898/index.html)

ManageEngine Password Manager Pro fails to restrict access permissions.

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

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

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

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

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

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

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

- Takayuki (Taki) Uchiyama

Apr 08, 2016

PHP Files in CMS, Targeted for Alteration

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

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

Altered Files

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

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

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

How Altered PHP Files Insert Malicious Codes

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

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

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

Malicious Codes to be Inserted

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

Figure 2: Example of malicious codes to be inserted
Pic2

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

Summary

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

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

- Ayaka Funakoshi

(Translated by Yukako Uchida)


Reference:

[1] Sucuri Inc
WordPress Malware Causes Psuedo-Darkleech Infection
https://blog.sucuri.net/2015/03/pseudo-darkleech-server-root-infection.html

[2] DAVISEFORD.COM
DarkLeech: Finally Under Control?
http://daviseford.com/node/58

[3] JPCERT/CC
JPCERT/CC Incident Handling Report (October 1 – December 31 2015) (English)
http://www.jpcert.or.jp/english/doc/IR_Report2015Q3_en.pdf

Mar 29, 2016

Experience in MNSEC 2015, Ulaanbaatar

Hello all, my name is Shinichi Horata working at Watch and Warning Group. It’s my first time posting here.

It’s already been quite a while ago, but last year I went to Mongolia for the first time in my life. The purpose was to attend MNSEC 2015 (Conference website: Mongolian only), a Mongolian local cyber security conference hosted by MNCERT/CC (Organisation website: Mongolian only) on 29-30 September 2015, where I delivered a talk.

Event Overview

MNSEC is the largest cyber security conference in Mongolia, which has been held annually since 2013. JPCERT/CC has been invited to this event since the first time (See the blog entry from 2014 here). The event attracted about 200 locals who are engaged in cyber security from the Mongolian Government, private entities, ISPs, banks, universities and so on. A wide range of discussions took place including the relations between big data and security, malware involved in online banking and sophisticated cyber attacks. The program was as follows:

29 Sep - Presentations:

  1. “Big data and its security” (Bat-Ulzii B, Director of IT Department of Ulaanbaatar)
  2. “Weak point, threats and violations of E-Bank” (Jung Hyong Chul, Beyond Security)
  3. “FreeBSD Content filter” (Ganbold Ts, Director of MSTRIDE LLC and Head of Mongolian Unix group)
  4. “Current Cyber Threats in Japan” (Shinichi Horata, JPCERT/CC)
  5. Kharuul Zangi 2015 (CTF competition)

30 Sep - Presentations:

  1. “Understanding Exploit Analysis” (Shinichi Horata, JPCERT/CC)
  2. “Information security in cyber environment” (Altangerel. B, Communications Regulatory Commission of Mongolia)
  3. “APT attack” (Otgonpurev M, Cyber security expert)
  4. “Cyber threat and decreasing it” (Andrew Chen, Channel manager of Checkpoint LLC)
  5. “Child security in cyber environment” (Altangerel B, Communications Regulatory Commission of Mongolia)
  6. “DDoS attack” (Enkhsaikhan P, Cyber security researcher)
  7. “About Mongolian cyber emergency response team” (Batjargal B, MNCERT/CC)

MNCERT/CC gave me an opportunity to deliver two presentations entitled “Current Cyber Threats in Japan” and “Understanding Exploit Analysis”.

In the first presentation, I provided an overview of JPCERT/CC activities, especially focusing on our efforts in incident response and early warning. Furthermore, I introduced the current situation of cyber incidents observed in Japan, mainly case studies of illegal money transfer involving banking Trojan, and cases of sophisticated cyber attacks.

The second presentation discussed some of the know-how required for providing early warning information, and software vulnerabilities in Use After Free (CWE-416), taking Adobe Flash Player’s vulnerability (CVE-2015-5119, etc.) as an example. In Mongolia, they are currently focusing on implementing efforts to enhance industrial development and human resource development in cyber security, so it was a good opportunity for us to exchange information and views regarding these topics.

Presenter_1_edit

(Photo of me at the event)

Remarks on the Event

I felt that the key throughout the event was also “human resource development”. On 29 September, there was a CTF competition entitled “Kharuul Zangi 2015”, and there were also some programs running in parallel that gave practical lectures. Aside from the CTF, some exercises were also given to the participants so that everyone could make the most of the event. I saw a lot of youngsters among a wide range of participants. I felt that the participants and the venue were filled with enthusiasm – probably because the conference is a new and young project, and organisers as well as attendees had great motivation.

MNCERT/CC, who has been hosting the conference, says that they consider the discussion on local cyber security among the persons in charge and researchers as a key component of the event. This made me wonder – what about Japan? Is there as much momentum in Japanese cyber security conferences, involving young students and those working at the front line? The event provided me a good opportunity to look back on my own experience too. Actions for cyber security discussions in Mongolia has just started – we look forward to seeing MNCERT/CC’s and Mongolian local CSIRTs’ even stronger involvement in enhancing the industry and its human resources.

Thank you for reading.

- Shinichi Horata

(Translated by Yukako Uchida)