54 posts categorized "#JPCERT news" Feed

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)

Feb 19, 2016

Banking Trojan “Citadel” Returns

Hello again, this is You ‘Tsuru’ Nakatsuru from Analysis Center. It has been just about two years since I delivered a talk “Fight Against Citadel in Japan” at CODE BLUE 2013 (an international security conference in Tokyo) about the situation on banking trojans observed in Japan at that time and detailed analysis results on Citadel (See my blog entry here). For the presentation material and audio archive, please see Reference [1].

Since then, various kinds of efforts have been implemented against this malware. Citadel was less and less seen among incident reports to JPCERT/CC, and there had been no reports about it since the first half of 2014. However, in late November 2015, we observed an attempt to infect a host with an upgraded Citadel via Drive-by-Download attack.

In this blog article, I will discuss how this upgraded Citadel (here after tentatively named as “Citadel 101” since the version was set as 0.0.1.1) had changed from Citadel version 1.3.5.1 (hereafter “Citadel 1.3.5.1”) which I presented at CODE BLUE. I will also introduce a decryption tool for Citadel 101 created by JPCERT/CC.

Message Impersonating Brian Krebs Removed

It is widely known that Citadel 1.3.5.1 has a function which is not related to its intended behaviour: When executing with argument “-z”, the following message is displayed.

Figure 1: Dialog box displayed when executing with argument "-z"
1_krebs

This is a message impersonating Brian Krebs, a well-known security researcher of Krebs on Security. He himself actually has written an article about this (See Reference [2]). In Citadel 101, this function has been removed.

Change in Structure

There have been some slight changes in structures used within Citadel. For instance, in BinStrage (used as data format for configuration files), the size of random data at the beginning of the header had been changed from 20 bytes to 32 bytes as in Figure 2.

Figure 2: Random data (in red boxes) at the beginning of BinStrage – in Citadel 1.3.5.1 (upper) and Citadel 101 (lower)
2_binstrage

XOR Operation Added to Encryption Process

As I introduced at CODE BLUE, Citadel 1.3.5.1 encrypts files, registries and communication data, as indicated in Table 1.

Table 1: Objects that Citadel 1.3.5.1 encrypts and its methods
Encryption objectData formatEncryption method
Communication data Report Encrypted BinStrage RC4+
Dynamic Config Encrypted BinStrage AES+
Additional modules Executable files RC4+ * 2
Files Report files StrageArray AES+ using Installed Data
Module backup StrageArray AES+ using Installed Data
Registry Dynamic Config backup Encrypted BinStrage AES+ using Installed Data

Citadel 101 encrypts the same objects and uses the same encryption methods as Citadel 1.3.5.1, however, XOR operation has been added at the beginning of the encryption process and the end of the decryption process. Data retrieved through the same decryption method as Citadel 1.3.5.1 includes XOR key (key2) and encoded data (data), which are used in the XOR decoding process (shown in Figure 3).

Figure 3: XOR decoding process added to Citadel 101
3_xor

The default value of key1, which is one of the XOR keys used here, is hardcoded in Citadel itself. In the incident handling process, this value has to be newly retrieved in order to decrypt data encrypted by Citadel.

Updated Citadel Decryptor Published

Citadel Decryptor is a tool to decrypt data encrypted by Citadel, which I created and presented at CODE BLUE. This time, I expanded its feature so that it can decrypt data encrypted by Citadel 101 as well, and published it on GitHub.

JPCERTCC/aa-tools/citadel_decryptor

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

Major changes are as follows:

  • Added the process to obtain encryption keys, etc., hardcoded in Citadel 101 itself
  • Added XOR decoding process at the end of decryption process

⇒In case it fails to obtain the XOR key, it judges that the version is Citadel 1.3.5.1 and does not perform XOR decoding

  • Made changes to correspond to different structures between Citadel 101 and Citadel 1.3.5.1.

There is no change in its usage. Here below is an example of using the tool to decrypt the configuration file which Citadel 101 receives from a C&C server.

> citadel_decryptor.py -v -d root.xml citadel_main.bin
[*] start to decrypt root.xml
[*] get base config & several params
[*] found base config at RVA:0x000047f0, RA:0x000047f0
[*] found login key: D8F3A28A92E53179A3EC2100B314A5CB
[*] use RC4 key at (base config + 0x000001fd)
[*] found following xor key for AES plus:
[40, 40, 84, 92, 146, 121, 93, 197, 4, 73, 90, 178, 167, 220, 62, 44]
[*] found RC4 salt: 0x5198A7FE
[*] found xor key using after Visual Decrypt: 0x5198A7FE
[*] try to unpack
[*] decrypt data using following key:
[58, 225, (snip.) 50, 247, 122, 107, 114, 177, 190, 29, 60, 230, 186, 94]
[*] try to AES+ decryption
[*] use following AES key:
[181, 55, (snip.) , 252, 170, 168, 99, 231, 208, 131, 229, 244, 121]
[*] parse decrypted data... OK
[*] decompress decrypted data
[*] wrote decrypted data to root_decrypted.bin

Way Forward

Since JPCERT/CC has only seen a small number of Citadel 101 cases so far, there has not yet been enough testing on the Citadel Decryptor. There may be some other changes that are not fully covered in this update. I would like to make improvements based on your feedbacks, including Citadel samples which cannot be decrypted with the Citadel Decryptor. Your pull request is also highly appreciated!

Thank you for reading!

- You Nakatsuru


Reference

[1] ARCHIVE || Lecture of past || CODE BLUE 2013

http://codeblue.jp/2015/en/archive/2013/#speaker-you


[2] Krebs, KrebsOnSecurity, As Malware Memes — Krebs on Security

http://krebsonsecurity.com/2013/05/krebs-krebsonsecurity-as-malware-memes/

Appendix: SHA-256 hash value

dd16014eb3fa62d483758b63b2f412017381e6d9cc03347152dff3eb9f8e6e3b