35 posts categorized "#Trends in Japan" Feed

Aug 03, 2018

Volatility Plugin for Detecting Cobalt Strike Beacon

JPCERT/CC has observed some Japanese organisations being affected by cyber attacks leveraging “Cobalt Strike” since around July 2017. It is a commercial product that simulates targeted attacks [1], often used for incident handling exercises, and likewise it is an easy-to-use tool for attackers. Reports from LAC [2] and FireEye [3] describe details on Cobalt Strike and actors who conduct attacks using this tool.

Cobalt Strike is delivered via a decoy MS Word document embedding a downloader. This will download a payload (Cobalt Strike Beacon), which will be executed within the memory. Since Cobalt Strike Beacon is not saved on the filesystem, whether a device is infected cannot be confirmed just by looking for the file itself. There is a need to look into memory dump or network device logs.

This article is to introduce a tool that we developed to detect Cobalt Strike Beacon from the memory. It is available on GitHub - Feel free to try from the following webpage:

JPCERTCC/aa-tools · GitHub

https://github.com/JPCERTCC/aa-tools/blob/master/cobaltstrikescan.py

Tool details

This tool works as a plugin for The Volatility Framework (hereafter “Volatility”), a memory forensic tool. Here are the functions of cobaltstrikescan.py:

  • cobaltstrikescan: Detect Cobalt Strike Beacon from memory image
  • cobaltstrikeconfig: Detect Cobalt Strike Beacon from memory image and extract configuration

To run the tool, save cobaltstrikescan.py in ”contrib/plugins/malware” folder in Volatility, and execute the following command:

$python vol.py [cobaltstrikescan|cobaltstrikeconfig] –f <memory.image> ––profile=<profile>

Figure 1 shows an example output of cobaltstrikescan. You can see the detected process name (Name) and process ID (PID) indicating where the malware is injected to.

Figure 1: Execution results of cobaltstrikescan
Fig1

Figure 2 shows an example output of cobalrstrikeconfig. Please refer to Appendix A for configuration details for Cobalt Strike Beacon.

Figure 2: Execution results of cobaltstrikeconfig
Fig2

In closing

Actors using Cobalt Strike continue attacks against Japanese organisations. We hope this tool helps detecting the attack in an early stage.

- Takuya Endo

(Translated by Yukako Uchida)

Reference

[1] Strategic Cyber LLC:COBALT STRIKE ADVANCED THREAT TACTICS FOR PANETRATION TESTERS

https://www.cobaltstrike.com/

[2] LAC: New attacks by APT actors menuPass (APT10) observed (Japanese)

https://www.lac.co.jp/lacwatch/people/20180521_001638.html

[3] FireEye: Privileges and Credentials: Phished at the Request of Counsel

https://www.fireeye.com/blog/threat-research/2017/06/phished-at-the-request-of-counsel.html

[4] Cybereason: Operation Cobalt Kitty: A large-scale APT in Asia carried out by the OceanLotus Group

https://www.cybereason.com/blog/operation-cobalt-kitty-apt

Appendix A
Table A: Configuration format
Offset Length Description
0x00 2 index (Refer to Table B)
0x02 2

Data length

1 = 2 byte, 2 = 4 byte, 3 = as specified in 0x04

0x04 2 Data length
0x06 As specified in 0x04 Data
 
Table B: Configuration
Offset Description Remarks
0x01 BeaconType 0=HTTP, 1=Hybrid HTTP and DNS, 8=HTTPS
0x02 Port number  
0x03 Polling time  
0x04 Unknown  
0x05 Jitter Ratio of jitter in polling time (0-99%)
0x06 Maxdns Maximum length of host name when using DNS (0-255)
0x07 Unknown  
0x08 Destination host  
0x09 User agent  
0x0a Path when communicating HTTP_Header2  
0x0b Unknown  
0x0c HTTP_Header1  
0x0d HTTP_Header2  
0x0e Injection process  
0x0f Pipe name  
0x10 Year Stops operating after the specified date by Year, Month, Day
0x11 Month  
0x12 Day  
0x13 DNS_idle  
0x14 DNS_Sleep  
0x1a HTTP_Method1  
0x1b HTTP_Method2  
0x1c Unknown  
0x1d Process to inject arbitrary shellcode (32bit)  
0x1e Process to inject arbitrary shellcode (64bit)  
0x1f Unknown  
0x20 Proxy server name  
0x21 Proxy user name  
0x22 Proxy password  
0x23 AccessType

1 = Do not use proxy server

2 = Use IE configuration in the registry

4 = Connect via proxy server

0x24 create_remote_thread Flag whether to allow creating threads in other processes
0x25 Not in use  

Jul 06, 2018

Malware “WellMess” Targeting Linux and Windows

Some malware is designed to run on multiple platforms, and most commonly they are written in Java. For example, Adwind malware (introduced in a past article) is written in Java, and it runs on Windows and other OS. Golang is another programming language, and it is used for Mirai controller, which infects Linux systems.

This article introduces the behaviour of WellMess malware based on our observation. It is a type of malware programmed in Golang and cross-compiled to make it compatible both with Linux and Windows. For more details about the malware function, please also refer to the report from LAC [1].

Behaviour of WellMess

Generally, Golang executable files include many required libraries in itself. This usually increases the file size, making WellMess larger than 3 MB. Another feature is that function names for the executable files can be found in the file itself. (Even for stripped files, function names can be retrieved by using tools such as GoUtils2.0 [2].) Below are the function names used in WellMess:

_/home/ubuntu/GoProject/src/bot/botlib.EncryptText
_/home/ubuntu/GoProject/src/bot/botlib.encrypt
_/home/ubuntu/GoProject/src/bot/botlib.Command
_/home/ubuntu/GoProject/src/bot/botlib.reply
_/home/ubuntu/GoProject/src/bot/botlib.Service
_/home/ubuntu/GoProject/src/bot/botlib.saveFile
_/home/ubuntu/GoProject/src/bot/botlib.UDFile
_/home/ubuntu/GoProject/src/bot/botlib.Download
_/home/ubuntu/GoProject/src/bot/botlib.Send
_/home/ubuntu/GoProject/src/bot/botlib.Work
_/home/ubuntu/GoProject/src/bot/botlib.chunksM
_/home/ubuntu/GoProject/src/bot/botlib.Join
_/home/ubuntu/GoProject/src/bot/botlib.wellMess
_/home/ubuntu/GoProject/src/bot/botlib.RandStringBytes
_/home/ubuntu/GoProject/src/bot/botlib.GetRandomBytes
_/home/ubuntu/GoProject/src/bot/botlib.Key
_/home/ubuntu/GoProject/src/bot/botlib.GenerateSymmKey
_/home/ubuntu/GoProject/src/bot/botlib.CalculateMD5Hash
_/home/ubuntu/GoProject/src/bot/botlib.Parse
_/home/ubuntu/GoProject/src/bot/botlib.Pack
_/home/ubuntu/GoProject/src/bot/botlib.Unpack
_/home/ubuntu/GoProject/src/bot/botlib.UnpackB
_/home/ubuntu/GoProject/src/bot/botlib.FromNormalToBase64
_/home/ubuntu/GoProject/src/bot/botlib.RandInt
_/home/ubuntu/GoProject/src/bot/botlib.Base64ToNormal
_/home/ubuntu/GoProject/src/bot/botlib.KeySizeError.Error
_/home/ubuntu/GoProject/src/bot/botlib.New
_/home/ubuntu/GoProject/src/bot/botlib.(*rc6cipher).BlockSize
_/home/ubuntu/GoProject/src/bot/botlib.convertFromString
_/home/ubuntu/GoProject/src/bot/botlib.(*rc6cipher).Encrypt
_/home/ubuntu/GoProject/src/bot/botlib.(*rc6cipher).Decrypt
_/home/ubuntu/GoProject/src/bot/botlib.Split
_/home/ubuntu/GoProject/src/bot/botlib.Cipher
_/home/ubuntu/GoProject/src/bot/botlib.Decipher
_/home/ubuntu/GoProject/src/bot/botlib.Pad
_/home/ubuntu/GoProject/src/bot/botlib.AES_Encrypt
_/home/ubuntu/GoProject/src/bot/botlib.AES_Decrypt
_/home/ubuntu/GoProject/src/bot/botlib.generateRandomString
_/home/ubuntu/GoProject/src/bot/botlib.deleteFile
_/home/ubuntu/GoProject/src/bot/botlib.Post
_/home/ubuntu/GoProject/src/bot/botlib.SendMessage
_/home/ubuntu/GoProject/src/bot/botlib.ReceiveMessage
_/home/ubuntu/GoProject/src/bot/botlib.Send.func1
_/home/ubuntu/GoProject/src/bot/botlib.init
_/home/ubuntu/GoProject/src/bot/botlib.(*KeySizeError).Error

As mentioned earlier, WellMess has a version that runs on Windows (PE) and another on Linux (ELF). Although there are some minor differences, they both have the same functionality.

The malware communicates with a C&C server using HTTP requests and performs functions based on the received commands. Below is an example of the communication: (User-Agent value varies per sample.)

POST / HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20130401 Firefox/31.0
Content-Type: application/x-www-form-urlencoded
Accept: text/html, */*
Accept-Language: en-US,en;q=0.8
Cookie: c22UekXD=J41lrM+S01+KX29R+As21Sur+%3asRnW+3Eo+nIHjv+o6A7qGw+XQr%3aq+PJ9jaI+KQ7G.+FT2wr+wzQ3vd+3IJXC+lays+k27xd.+di%3abd+mHMAi+mYNZv+Mrp+S%2cV21.+ESollsY+6suRD+%2cx8O1m+%3azc+GYdrw.+FbWQWr+5pO8;1rf4EnE9=+WMyn8+8ogDA+WxR5R.+sFMwDnV+DFninOi+XaP+p4iY+82U.+hZb+QB6+kMBvT9R
Host: 45.123.190.168
Content-Length: 426
Expect: 100-continue
Accept-Encoding: deflate
Connection: Keep-Alive

pgY4C8 8JHqk RjrCa R9MS 3vc4Uk KKaRxH R8vg Tfj B3P,C 0RG9lFw DqF405. i3RU1 0lW 2BqdSn K3L Y7hEc. tzto yKU8 p1,E L2kKg pQcE1. b8V6S0Y 6akx, ggMcrXk 0csao Uwxn. fYVtWD rwt:BJ 5IBn rCMxZoo OsC. :ZXg pKT Re0 cJST1 L0GsC. 9dJZON9 qs29pPB pCTR:8 0hO0FK sK13UUw. jMA hDICL hGK1 qjRj1AY YMjAIeI. g7GEZPh gW:C eNX6 ptq kevfIyP. u,96r7c D:6ZiR fCC IIi cBvq,p. Vt96aEu JFLeu 0XtFJm ee4S 7M2. Uc68sF MArC5v 96ngG 9UvQGt 5:ut. qiE0xQ

Results of command execution are send in HTTP POST request data, which is RSA-encrypted. The data in Cookie header is RC6-encrypted. Below is an example of decrypted data. It contains an identifier for infected hosts (the value in between <;head;> tags).

<;head;>6F3C9B16C16074079AFCFF09C6717B0F07864FFE09C1E1DB003B3627D174913B/p<;head;><;title;>a:1_0<;title;><;service;>p<;service;>

Below is a part of code that decodes data in the Cookie header. (The script is available on Github.)

def decode(data, key):
    sep = ';'

    field = data.split(sep)

    i = 1
    encdata = ""
    while i < len(field):
        value = field[i].split("=")
        encdata += value[1]
        I += 1

    encdata = urllib.unquote(encdata)
    encdata = encdata.replace("+", " ").replace("   ", "=").replace(". ", "").replace(" ", "").replace(",", "+").replace(":", "/")

    maindata = base64.b64decode(encdata)
    s = generateKey(base64.b64decode(key))

    i = 0
    decode = ""
    while i < len(maindata):
        orgi = rc6(maindata[i:i + 16], s)
        decode += orgi
        i += 16

    print("Decrypted String: %s" % decode)

The malware may perform the following functions when receiving commands from a C&C server.

  • Execute arbitrary shell command
  • Upload/Download files

In addition, PE file malware executes PowerShell scripts.

Wellmess Developed in .Net Framework

There is also a version that was developed in .Net Framework. Figure 1 shows the code that generates data contained in the Cookie header upon communicating with a C&C server. It contains the same string as in the Cookie data in the Golang version.

Figure 1: Code to generate data contained in the Cookie
Fig1

We have no clue about why the actors have prepared two different versions, however, it seems that they choose a sample depending on the attack target.

In closing

We have confirmed some cases where WellMess infection was found in Japanese organisations. Attacks using the malware may continue.

We have listed some hash values of the samples in Appendix A. Some of the C&C servers that we have confirmed are also listed in Appendix B. Please make sure that none of your device is accessing such hosts.

- Shusei Tomonaga

(Translated by Yukako Uchida)

Reference

[1] LAC: Cyber Emergency Center Report Vol.3 (Japanese)

https://www.lac.co.jp/lacwatch/pdf/20180614_cecreport_vol3.pdf

[2] GoUtils2.0

https://gitlab.com/zaytsevgu/GoUtils2.0/

Appendix A: SHA-256 Hash value
  • 0b8e6a11adaa3df120ec15846bb966d674724b6b92eae34d63b665e0698e0193 (Golang&ELF)
  • bec1981e422c1e01c14511d384a33c9bcc66456c1274bbbac073da825a3f537d (Golang&PE)
  • 2285a264ffab59ab5a1eb4e2b9bcab9baf26750b6c551ee3094af56a4442ac41 (.Net&PE)
Appendix B: C&C server
  • 45.123.190.168
  • 103.13.240.46
  • 101.201.53.27
  • 185.217.92.171
  • 93.113.45.101
  • 191.101.180.78

Jun 08, 2018

PLEAD Downloader Used by BlackTech

In a past article, we introduced TSCookie, malware which seems to be used by BlackTech[1]. It has been revealed that this actor also uses another type of malware “PLEAD”. (“PLEAD” is referred to both as a name of malware including TSCookie and its attack campaign [2]. In this article, we refer to “PLEAD” as a type malware apart from TSCookie.) PLEAD has two kinds – RAT (Remote Access Tool) and downloader. The RAT operates based on commands that are provided from C&C servers. (Please refer to a blog post from LAC for more information [3].) On the other hand, PLEAD downloader downloads modules and runs it on memory in the same way as TSCookie does.

This article presents behaviour of PLEAD downloader in detail.

Behaviour of PLEAD downloader

PLEAD downloader downloads RC4-encrypted modules from certain sites. Figure 1 shows an example of an encrypted file downloaded from a server.

Figure 1: Example of file download by PLEAD downloader
Fig1

The first 20h of the downloaded file is the RC4 key to decode the file. Once decoded, you can find the module (hereafter referred to as “PLEAD module”), C&C server, encryption keys etc. Figure 2 is an example of a decrypted file.

Figure 2: Decrypting downloaded file
Fig2_en

PLEAD downloader loads PLEAD module (contained in the decrypted data) and executes it. The module will not be saved as a file but only exists on the memory. The following section will explain the details of PLEAD module.

Behaviour of PLEAD module

PLEAD module operates based on commands provided from C&C servers. Communication to/from C&C servers is RC4-encrypted and then compressed with LZO. The RC4 encryption key is a combination of the ones generated by itself and another sent from a C&C server. Figure 3 describes the flow of communication that PLEAD module performs.

Figure 3: PLEAD module communication
Fig3_en

PLEAD module first shares a RC4 key with a C&C server. Below is an example of an HTTP GET request which is sent at the beginning of the communication. Cookie header contains an encrypted RC4 key. In the data sent in Cookie header, “D” and “E” are interchanged. Refer to Table A-1 and A-2 in Appendix A for data format.

GET /index.php?id=1577061168 HTTP/1.1
Cache-Control: no-cache
Accept: */*
Pragma: no-cache
Cookie: 800809D6411C6E2629001900A92309EB26192117C5A59F306E207A8993A2F20121FC3B42B6DF693838
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: [host name]
Connection: Keep-Alive

RC4 key for data encryption is 32 bytes long, divided into 5 blocks (4 byte * 4 + 16 byte * 1). The first block in the key (Key1 in Figure 3) is included in the configuration of PLEAD module. The second and the third block (Key2 and 3) are set to 0 in the HTTP GET request. The fourth block (Key4) is randomly generated and inserted after “id” in the URL. The fifth block (Key5) is generated based on Key4 value.

The data which is sent first contains Key2 value. With that value, the recipient server encrypts Key3 value and send it to C&C server. The data format is described in Table A-3 and A-4 in Appendix A. This way, an RC4 key is generated and used for communication that follows.

Below is a part of Python script to decode data.

def decode(key1, key2, key3, key4, data, lzo_header):
    rc4_key = key1 + pack("III", key2, key3, key4)
    for i in xrange(4):
        key4 = ROR(key4 + 1, 5)
        rc4_key += pack("I", key4)
        
    dec = rc4(data, rc4_key)

    try:
        return lzo.decompress(lzo_header + dec)
    except:
        sys.exit("[!] Lzo decompress error.")

After sharing the RC4 key, PLEAD module sends information about an infected host using HTTP POST request. The data format is the same as shown in Table A-1 in Appendix A.

POST /index.php?id=2852129559 HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: [host name]
Content-Length: [data size]
Connection: Keep-Alive
Cache-Control: no-cache

[data]

The data itself contains the host name, OS version, IP address, user account name of the infected host. Figure 4 is an example of decoded data.

Figure 4: Example of decoded data that PLEAD module sends
Fig4

After that, a command will be sent from a C&C server. PLEAD module can execute the following functions based on the commands that are provided.

  • Send file list
  • Arbitrary shell command execution
  • Upload/download files
  • File Operations

(Refer to B-1 in Appendix B for the details of the command)

Conclusion

As we previously described, this actor has been conducting attacks against Japanese organisations using various kinds of malware. As this attack campaign is likely to continue, JPCERT/CC will watch the trend carefully.

We have listed the hash values of the samples that were described in this article in Appendix C. Some C&C servers that are lately confirmed are also listed in Appendix D. Please make sure that none of your devices is accessing these hosts.

- Shusei Tomonaga

(Translated by Yukako Uchida)

Reference

[1] TrendMicro: Following the Trail of BlackTech’s Cyber Espionage Campaigns

https://blog.trendmicro.com/trendlabs-security-intelligence/following-trail-blacktech-cyber-espionage-campaigns/

[2] TrendMicro: Following the Trail of BlackTech’s Cyber Espionage Campaigns

https://documents.trendmicro.com/assets/appendix-following-the-trail-of-blacktechs-cyber-espionage-campaigns.pdf

[3] LAC: Confirmed Attacks against Japanese Organizations by BlackTech Using “PLEAD” (Japanese)

https://www.lac.co.jp/lacwatch/people/20180425_001625.html

Appendix A PLEAD module communication data
Table A-1: Format of data contained in Cookie header
Offset Length Contents
0x00 4 Hash value
0x04 4 RC4 key (Key1)
0x08 2 Data length
0x0A 2 Original length of data with offset 0x0C
0x0C - Encrypted data (RC4+LZO) (Refer to Table A-2)

*In the data contained in Cookie header, “D” and “E” are interchanged.

Table A-2: Format of encrypted data contained in Cookie header
Offset Length Contents
0x00 2 0x0000
0x02 4 RC4 key (Key2)
0x06 - Random numeric

Table A-3: Format of received data
Offset Length Contents
0x00 4 RC4 key (Key2)
0x04 4 Hash value
0x08 4 RC4 key (Key1)
0x0C 2 Original length of data with offset 0x0E
0x0E - Encrypted data (RC4+LZO) (Refer to Table A-4)

Table A-4: Format of encrypted data contained in the received data
Offset Length Contents
0x00 2 0x0001
0x02 4 RC4 key (Key3)
Appendix B PLEAD module commands
Table B-1: List of commands
Value Contents
0x100 Send file list
0x105 Send file size
0x107 Move file
0x109 Delete file
0x10B Upload file
0x10D Execute file
0x10F Execute file (using registry entry value)
0x111 Create directory
0x113 Move file
0x115 Delete directory
0x200 Send file or directory information
0x203 Create directory
0x206 Download file
0x207 Send file information
0x20B Upload file
0x300 Launch remote shell and execute command
0x305 Move current directory
0x307 End remote shell
0x309 Send file list of current directory file
0x30C Delete file or change attribution
0x404 Proxy set up
0x406 Send proxy data
0x408 Receive proxy data
0x40A End proxy
Appendix C SHA-256 hash value of samples

PLEAD

  • bc2c8cc9896cdd5816509f43cb5dca7433198251d754a997a70db7e8ed5cca40
  • a26df4f62ada084a596bf0f603691bc9c02024be98abec4a9872f0ff0085f940
  • 2ddb2030ab3373b9438102b541aa4623b7dfee972850dcef05742ecbe8982e22
  • eec3f761f7eabe9ed569f39e896be24c9bbb8861b15dbde1b3d539505cd9dd8d

PLEAD module

  • 23f554cc5bea9d4ccd62b0bbccaa4599f225ebce4ad956a576cc1a9b2a73dc15
Appendix D List of C&C servers
  • em.totalpople.info
  • office.panasocin.com
  • gstrap.jkub.com
  • woc.yasonbin.info
  • 210.71.209.206

Feb 20, 2018

Identify Mirai Variant Infected Devices from SSDP Response

As it has been discussed in some reports from security researchers, devices infected with Mirai and its variants are forming large-scale botnets, which are often leveraged as a platform for attacks such as DDoS and other malicious activities.

JPCERT/CC has been conducting investigation and analysis of infection activities caused by Mirai variants from 2016 and providing measures to prevent further infection both in Japan and overseas. At the end of October 2017, given the significant increase in the devices infected with Mirai and its variant, JPCERT/CC issued a security alert on 19 December. For the release of this alert, JPCERT/CC coordinated with a device vendor in identifying the infected device models. This entry introduces the approaches that we took for this investigation.

Observation results and initial investigation

In late October 2017, we confirmed through JPCERT/CC’s packet traffic monitoring system (TSUBAME) that devices infected with a Mirai variant were carrying out scans to global IP addresses, targeting Port 23/TCP and 2323/TCP. Further detailed analysis revealed some of the source IP addresses used for the scan activities. [1]

Comparing the IP addresses against the network scan results provided by local/global security organisations, it turned out that most of the affected hosts were accessible directly from the Internet through Simple Service Discovery Protocol (SSDP).

How to Identify MAC address from SSDP response

SSDP is one of the protocols used for Universal Plug and Play (UPnP), which enables searching for devices connected to the network, and Port 1900/UDP is assigned. Communication performed when searching for devices with SSDP is described in Figure 1.

Figure 1: Part of communication for searching devices using SSDP
Fig1_en

In this protocol, a client sends a query (M-SEARCH) to the network, and devices received this query returns a response (NOTIFY).

The NOTIFY response contains information about the device itself, including Universally Unique Identifier (UUID). This is a string to uniquely identify an object on the software. There are 5 versions for UUID [2], and the version 1 is based on the timestamp (when the UUID was generated) and the MAC address of the device. Figure 2 explains the data structure of the UUID version 1.

Figure 2: Structure of UUID version 1
Fig2_en

In this version, the device’s MAC address is inserted in the UUID’s last 12 digits. This means that the device itself can be identified by looking at the NOTIFY payload in response to a SSDP query. The device vendor can also be determined from the vendor ID, which lies in the first 3 octets of the MAC address.

Identify infected devices and take measures

Most of the devices that were found infected with a Mirai variant had been used with SSDP service publicly available on the Internet, and its UUID was version 1. This made us possible to identify the MAC address and consequently the vendor of the affected devices. From the MAC addresses and packet traffic observed through TSUBAME, JPCERT/CC coordinated with the vendor in question and identified the affected device models, which led to the release of the security alert together with some related organisations to raise users’ awareness.

JPCERT/CC continues to coordinate with vendors in investigation on devices and request for security measures, so that the any further infection can be prevented.

Summary

We introduced how we came to identify infected devices. If SSDP port is left publicly accessible on the Internet, it has potential risks to be used for DDoS attacks [3] and other malicious activities leveraging UPnP vulnerability [4] [5]. If you are using UPnP-equipped devices, please make sure that the security measures are properly taken such as 1) keep the firmware up-to-date, 2) not expose UPnP service on the Internet and 3) disable UPnP function if not being used.

If you have any questions, please contact global-cc[at]jpcert.or.jp.

Thanks for reading.

- Tomoaki Tani

(Translated by Yukako Uchida)

Reference

[1] JPCERT/CC Internet Threat Monitoring Report [October 1, 2017 - December 31, 2017] [JPCERT/CC]

https://www.jpcert.or.jp/english/doc/TSUBAMEReport2017Q3_en.pdf

[2] RFC 4122: A Universally Unique IDentifier (UUID) URN Namespace

https://tools.ietf.org/html/rfc4122

[3] Alert (TA14-017A) UDP-Based Amplification Attacks [US-CERT]

https://www.us-cert.gov/ncas/alerts/TA14-017A

[4] US-CERT Vulnerability Note VU#357851

UPnP requests accepted over router WAN interfaces

https://www.kb.cert.org/vuls/id/357851

[5] CVE-2014-8361 Detail [NIST]

https://nvd.nist.gov/vuln/detail/CVE-2014-8361

Aug 21, 2017

Detecting Datper Malware from Proxy Logs

This is Yu Nakamura from Analysis Center.

This entry is to explain features of Datper, malware used for targeted attacks against Japanese organisations and how to detect it from the logs.

JPCERT/CC has been observing attacks using Datper since around June 2016. Research reports on the adversary are published from LAC [1], SecureWorks [2] and Palo Alto Networks [3]. The adversary had also conducted attacks using Daserf malware in the past, and Symantec refers to them as “Tick” in their report [4].

Attack vectors

We have confirmed that Datper infection occurs by:

  • Drive-by download attacks
  • Exploiting vulnerabilities in asset management software

In the former attack vector, we observed that a vulnerability of Adobe Flash Player (CVE-2016-7892) was leveraged for downloading and executing Datper. For the latter, there were cases where devices also got infected with a downloader called “wali”. Some analysis of this downloader has been published by Kaspersky [5] and Cybereason [6]. We have seen that wali can download several types of malware, and Datper is one of them.

Detailed behaviour

Datper communicates with a C&C server using HTTP protocol and operates based on the received commands. One of the characteristics is that it only communicates within a specific period of time.

Here below is a sample HTTP request that Datper sends to a C&C server. User-Agent is hard-coded in the malware.


GET /hoge/index.php?fnyup=940785246f0c22b41joikeddfngjokyptui HTTP/1.1
Accept: */*
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: [host name]
Pragma: no-cache
Connection: close

The malware receives a command as a response to the above HTTP request, and it executes functions based on the commands. Functions that Datper can execute are the following:

  • Obtain host names, OS versions etc.
  • Obtain drive information
  • Configure communication intervals
  • Sleep for a set period of time
  • Execute a program
  • Operate on files (Obtain file lists, download, upload, delete)
  • Execute shell commands

After executing these functions, Datper sends the results to a C&C server.

How to detect Datper’s communication

Datper sends HTTP GET requests with two types of query strings as in format 1 and 2 in the following figure.

Figure 1: Query string formats
Figure1

As in the Figure 1, <a>, <b> and <c> in the query strings vary for each communication. If the fixed value which comes after <c> is “1” (as in format 1 in the Figure), it represents a request for commands, while those with “2” (format 2 in the Figure) are sent when sending command execution result to a C&C server. Command execution results are contained in the encrypted data. When the encrypted data is larger than 1024 bytes, POST method is used instead of GET.

Strings as in the above Figure is typical for Datper’s communication and barely observed during usual web browsing. Based on the characteristics, it is possible to detect Datper’s communication by checking for logs that match the format - that strings are aligned in the order of <a>=<b><c> format and <b>’s CRC32 value matches <c>. For easy verification, the following is an example of Python script for checking proxy server logs. Regular expressions need to be modified according to the log format.


import re
import sys
from binascii import crc32
from ctypes import c_uint

filter_1 = re.compile('(http://[\da-z\.-]+\.[a-z\.]{2,6}/[\/\w_\.-]+\?[\da-z]{3,8}=([\da-f]{8})([\da-f]{8})[1-2]{1}\S+)\s', re.IGNORECASE)

def main():
    for line in sys.stdin:
        m1 = filter_1.search(line)
        if m1:
            url = m1.group(1).lower()
            d1 =  m1.group(2).lower()
            d2 =  m1.group(3).lower()
        else:
            continue
        d1_crc32 = "%08x" % c_uint(crc32(d1)).value
        if d1_crc32 == d2:
            print "hit: %s" % line            
if __name__ == '__main__':
    main()

Change in compression algorithm

As mentioned above, Datper’s communication contains encrypted data. More precisely, plain text data is compressed, encrypted and then encoded. As for the compression algorithm, LZNT1 had been used, however, it was replaced with LZRW1/KH around November 2016. Below is the list of compression and encryption methods that Datper uses.

Table 1: List of compression and encryption methods
  Compression algorithm Encryption algorithm Encode algorithm
Datper (Until October 2016) LZNT1 RC4 Base64 (alternative table)
Datper (After November 2016) LZRW1/KH xor + RC4 Base64 (alternative table)

The adversary has often used LZNT1 for attacks using Datper and other types of malware (xxmm/Minzen). While LZNT1 is easy to use with a Windows API “RtlDecompressBuffer”, LZRW1/KH is not covered in Windows API. The reason for this inconvenient choice is unclear, however, this change together with the slight update in the encryption algorithm may be due to the intention of the adversary to disturb the malware analysis processes.

Conclusion

The adversary using Datper had conducted targeted attacks using Daserf malware for a long period of time against Japanese organisations. Activity with Datper is also likely to continue for a while, and we will carefully watch the malware and its attack activity.

- Yu Nakamura

(Translated by Yukako Uchida)

References

[1] CYBER GRID VIEW Vol.2 | Security Information | LAC Co. Ltd. (Japanese)

  http://www.lac.co.jp/security/report/pdf/20160802_cgview_vol2_a001t.pdf

[2] A whole picture of cyber attacks targeting Japanese companies – BRONZE BUTLER (Japanese)

https://www.secureworks.jp/%7E/media/Files/JP/Reports/SecureWorksBronzeButlerReport.ashx

[3] “Tick” Group Continues Attacks

  https://researchcenter.paloaltonetworks.com/2017/07/unit42-tick-group-continues-attacks/

[4] Tick cyberespionage group zeros in on Japan

  https://www.symantec.com/connect/blogs/tick-cyberespionage-group-zeros-japan

[5] Old Malware Tricks To Bypass Detection in the Age of Big Data – Securelist

  https://securelist.com/blog/research/78010/old-malware-tricks-to-bypass-detection-in-the-age-of-big-data/

[6] ShadowWali: New variant of the xxmm family of backdoors | Cybereason

  https://www.cybereason.com/labs-blog/labs-shadowwali-new-variant-of-the-xxmm-family-of-backdoors

Appendix A SHA-256 Hash value of Datper Samples
  • Datper(LZNT1)

efa68fcbd455a72276062fb513b71547ea11fedf4db10a476cc6c9a2fa4f67f7

12d9b4ec7f8ae42c67a6fd030efb027137dbe29e63f6f669eb932d0299fbe82f

331ac0965b50958db49b7794cc819b2945d7b5e5e919c185d83e997e205f107b

90ac1fb148ded4f46949a5fea4cd8c65d4ea9585046d66459328a5866f8198b2

2384e8ad8eee6db1e69b3ee7b6b3d01ae09f99a86901a0a87fb2788c1115090c

7d70d659c421b50604ce3e0a1bf423ab7e54b9df361360933bac3bb852a31849

  • Datper(LZRW1/KH)

7bc042b9a599e1024a668b9921e2a42a02545429cf446d5b3d21f20185afa6ce

1e511c32cdf8abe23d8ba7c39da5ce7fc6c87fdb551c9fc3265ee22ac4076e27

2f6745ccebf8e1d9e3e5284a895206bbb4347cf7daa2371652423aa9b94dfd3d

Aug 04, 2017

What the Avalanche Botnet Takedown Revealed: Banking Trojan Infection in Japan

Internet banking services across the globe have been exposed to the threat by unauthorized money transfers and suffering large-scale losses.

In this landscape, an operation led by international law enforcement agencies has been in effect since November 2016 to capture criminal groups conducting unauthorised online banking transfers and dismantle the attack infrastructure (the Avalanche botnet). JPCERT/CC is one of the many supporters of this operation.

For more information about the operation, please see below:

Europol Press Release:

‘Avalanche’ network dismantled in international cyber operation

https://www.europol.europa.eu/newsroom/news/%E2%80%98avalanche%E2%80%99-network-dismantled-in-international-cyber-operation

Interpol:

‘Avalanche’ network dismantled in international cyber operation

https://www.interpol.int/News-and-media/News/2016/N2016-160

This blog entry presents how JPCERT/CC supports this operation and the current state of malware infection in Japan revealed through our local coordination.

JPCERT/CC’s activities in the operation

Some organizations in support of this operation register domains related to the Avalanche botnet to observe communication between any infected devices and the DNS sinkhole. From all the observed data, CERT-Bund (the National CSIRT of Germany) provides information related to Japanese networks to JPCERT/CC. We then notify administrators of the infected hosts to request investigation and coordination to address the issue.

Characteristics of infected devices in Japan

Figure 1 shows the number of malware infected hosts linked to the Avalanche botnet, which were observed between 5 December 2016 and 31 May 2017. Note that extreme spikes caused by irregularities such as dates without any received data are excluded from the graph.

Figure 1: Number of malware infected hosts in Japan (per day)
Avalanche_01_en

In December 2016, when we first received data on the Avalanche botnet, there was a daily average of about 17,000 hosts communicating with the DNS sinkhole. However, it decreased to about 11,000 hosts per day at the end of May 2017, thanks to cooperation from our local partners.

In addition, multiple malware families have been observed within the Avalanche botnet. From the data, JPCERT/CC received between 5 December and 4 January, the ratio of malware observed in Japan was as follows:

Figure 2: Ratio of malware (linked to the Avalanche botnet) found in infected hosts in Japan
Avalanche_02

Rovnix, KINS, Shiotob (a.k.a. URLZone, Bebloh) are known as malware that harvest credentials for Internet banking services. We have confirmed that Rovnix and Shiotob were distributed as attachments to spam emails written in Japanese in 2016.

Conclusion

Through this operation, many infected hosts in Japan have been isolated from the botnet, which resulted in the decreasing trends as in Figure 1. However, besides the malware families hosted in the Avalanche botnet, other types of banking trojans such as Ursnif (or DreamBot) have also been distributed recently through spam emails written in Japanese. JPCERT/CC continues to alert local constituents about these threats.

- Shintaro Tanaka

(Translated by Yukako Uchida)

Jul 05, 2017

Clustering Malware Variants Using “impfuzzy for Neo4j”

In a past article, we introduced “impfuzzy for Neo4j”, a tool to visualise results of malware clustering (developed by JPCERT/CC). In this article, we will show the result of clustering Emdivi using the tool. Emdivi had been seen until around 2015 in targeted attacks against Japanese organisations. For more information about Emdivi, please refer to JPCERT/CC’s report.

Clustering Emdivi with impfuzzy for Neo4j

Emdivi has two major variants - t17 and t20, and we chose the former for this analysis. Figure 1 shows the output of running impfuzzy for Neo4j.

Figure 1: Emdivi t17’s clustering result using impfuzzy for Neo4j
Fig1

As a result of the analysis, 90 samples were clustered into 4 types. Figure 2 visualises the clustering results. Detailed results are documented in Appendix A. (For detailed instructions on the tool, please see our past blog article.)

Figure 2: Visualised result of Emdivi t17 clustering (Colouring provided for better understanding.)
Fig2

It stood out that each cluster (Type 1 through Type 4) highly corresponds to the compiled date of the malware sample (see Appendix A).

Hash values of malware samples are generated by impfuzzy (Import API), which is then used to calculate the similarity. Therefore, the reason for this type clustering is unknown solely from this analysis. Manual analysis is required to examine what makes Import APIs different in each type.

The following sections will describe the reason why Emdivi t17 samples were clustered into 4 types and how the transition occurred from one type to another.

From Type 1 to 2

The clustering results in Appendix A indicate the transition from Type 1 to 2 occurred around September 2014. We noticed a change in linker versions.

PE files have header information called IMAGE_OPTIONAL_HEADER[1]. This contains MajorLinkerVersion and MinorLinkerVersion, which indicates its linker version. Looking into the linker version used when creating Emdivi t17, Type 1 mainly uses 10.0 (Visual Studio 2010) while Type 2 uses 9.0 (Visual Studio 2008). It is considered that these samples were differentiated due to the change in the linker version, which accordingly changed the Windows APIs that the malware loads.

From Type 2 to 3

It was around November 2014 when Type 2 changed to Type 3, and this transition reflects the change in the method of loading Windows API. Usually, PE file loads Windows API upon execution by specifying an API name in Import Name Table (INT) inside the PE header. (Please refer to a past blog article for more information.)

However, Type 3 samples possess some obfuscated Windows API names and load it when using Windows API. Figure 3 is the results of decoding obfuscated strings in Emdivi t17, which indicates that Type 3 contains some obfuscated Windows API names (marked in red).

Figure 3: Comparison of decoded strings in Emdivi t17 clustered as Type 2 and 3
Fig3_eng

The Windows APIs obfuscated in Type 3 are deleted from its INT. This means that the Windows API that the malware aims to execute cannot be identified by just looking at the INT.

This change in Windows API load method is thought to be the reason for the difference between Type 2 and 3.

From Type 3 to 4

Transition from Type 3 to 4 occurred around May 2015. This is due to a new bot (remote control) function being added. Here is the list of bot functions that Type 4 has. “GOTO” is the new function to Type 4.

  • GOTO
  • DOABORT
  • DOWNBG
  • GETFILE
  • LOADDLL
  • SETCMD
  • SUSPEND
  • UPLOAD
  • VERSION

The added bot function resulted in new Windows APIs being used, which distinguishes Type 4 from 3.

Summary

It is not practical to manually analyse a large number of malware samples. It is rather important to automate malware clustering process to find new types of malware and changes in malware features. With the analysis example, we demonstrated an example of effective malware analysis using impfuzzy for Neo4j by focusing on samples with different features. The tool is available on Github, and we hope this helps your malware analysis.

- Shusei Tomonaga

(Translated by Yukako Uchida)

Reference

[1] Microsoft: IMAGE_OPTIONAL_HEADER structure

Appendix A Emdivi t17 Clustering Results
Table 1: List of Emdivi t17 Clustering Results
No. Compile Time EmdiviVersion LinkerVersion Type SHA256
1 2013-11-21 17:00:52 t17.08.2 10.0 1 6b0192ec4f0290c0c00517eeb75648e340dacc58189d9d6adee844283cda4a5f
2 2013-12-24 12:13:21 t17.08.2 10.0 1 c162df8761e09c95160e9d432d310a4673d53615c2ff837a1a6f322e45038180
3 2014-01-06 11:33:48 t17.08.2 10.0 1 bf8cba80f4d80e13f11c8231477f0b96c3a9e9abc8da798e6cede052f6801aa8
4 2014-01-06 11:48:05 t17.08.2 10.0 1 742c70238ea0b2b0a1d66660913b18deaff2af35c6dc5b19e9d2158249cae433
5 2014-01-19 16:12:41 t17.08.2 10.0 1 18dfb3ff38c802f54c66c7d06380e7aff4834ac7a0c9ea35e50f46cf40266c3a
6 2014-01-21 12:29:03 t17.08.2 10.0 1 08a542fe7f8450d2c66b5e428872860d584bc5be714a50293a10aef415310fe8
7 2014-01-21 20:07:01 t17.08.2 10.0 1 bf9229b342c144970358308ccb017802cb2ff5c2086bf0367d9d72f34556b7c1
8 2014-01-23 16:32:01 t17.08.2 10.0 1 2bf87ec696356a685b081b9e0aec88c3ac3e3353927f712e978db0d2f5a9476b
9 2014-02-28 10:52:43 t17.08.5 10.0 1 396c7766eb8873227c270eae2b13357dbcd68fa7f07053dd280375418eeee614
10 2014-03-13 13:05:13 t17.08.9 10.0 1 138e7c2e5cf0caba02d005752686a66482df23f4b4b648f446f2afada32a5750
11 2014-04-01 12:08:03 t17.08.9 10.0 1 4df19e155cac0735500cffae49007b3d971979cccca779a5af685db489b4b042
12 2014-05-07 13:52:46 t17.08.10 10.0 1 b97ab11d1154fae07d2cfab055cdc6b745a5117fc1d8e557f6a244040ba7cce3
13 2014-05-08 12:22:24 t17.08.10 10.0 1 04b9a6ef5ef6cdaf42e90431039bd56b68082c5056889cf4b9ababc6e0834b56
14 2014-05-11 15:44:46 t17.08.9 10.0 1 83620f29a19a4d372e256d98ebfd2d3e5cb4b8db97b385c2942914298b8d2870
15 2014-06-03 10:41:46 t17.08.9 10.0 1 4422d1568f729c316e8d02a35fe147c4c36c91d650989e9ac3caa6fbbc086b37
16 2014-07-17 10:48:24 t17.08.9 10.0 1 e7ae0995e3d4dd9c3fed51d5bca73ea9fa3edd90e2e87fc0cfac58165afdf4e8
17 2014-07-22 17:40:31 t17.08.9 10.0 1 7875c21473cf5f8d936f1335c049ae6df9e0b0574b263060d7a526f3d53cbf07
18 2014-07-28 18:01:59 t17.08.16 10.0 1 c805af2204c1d8612cd929b93fc5c38a448a03561d410d7a198c313553e47e39
19 2014-08-04 13:57:34 t17.08.16 10.0 1 3243925baa06dc69731da91da49242fd73aea38afe46e171708de4ecd4e53b80
20 2014-08-05 12:51:43 t17.08.18 8.0 1 92860e0a9e7dc49c43a0db87d4fb345294000ac3191af1dc6d702b89628c97eb
21 2014-08-06 09:22:32 t17.08.16 10.0 1 df97dd9607f0fdcc10f9ba99e6c3d01eb8453ceeeab840ef6b965458e24485bc
22 2014-08-12 18:09:41 t17.08.16 10.0 1 d26eb51e2787353b18c8f290f0710510423e3925a796697ff15aafd14fea6f2d
23 2014-08-18 12:21:10 t17.08.16 10.0 1 37f43f9c4298dc41f6b1ed03396cc1f7da664ed25e97c4263e6c360f59f3a51b
24 2014-08-19 20:01:29 t17.08.16 8.0 1 9fc76d0fb4f01819c0d9af09a0357dab6c33a4d5f6e41cafebeb9ef7ae35c99e
25 2014-09-09 13:34:21 t17.08.18 9.0 2 f017218f05d225cdb62f3081c4dac4b09a3fb2b93c01096bd4141b67d3eb3bbf
26 2014-09-18 09:26:42 t17.08.18 9.0 2 139e22abe7aaec635e2b570935636c4894a19a7b284516b77f190b78a369c4d6
27 2014-09-22 09:51:33 t17.08.18 9.0 2 a00e37d1d3fe990ebac26a4805a7ab42bd1dcf7ef65f151906204eee7b0c71fd
28 2014-09-25 10:34:10 t17.08.18 9.0 2 3d084155e6f79b45acba165cd4a17a3bed42daba478c14a795dc2c2809f302b6
29 2014-09-28 20:52:36 t17.08.18 9.0 2 196364b3e78add557b6f0471fb32061468bb2b20e16acd1a7686122234c984a7
30 2014-09-30 12:10:55 t17.08.21 9.0 2 8c3666940afd65835e4251fbd14942d210323d46adf57c5e8f29b61d552fd386
31 2014-10-07 11:50:57 t17.08.21 9.0 2 878937da134339ccd8c6bbc5ac020472c20a42fb1f07b56152cfcc1656077d62
32 2014-10-08 18:31:01 t17.08.21 9.0 2 b99f08be6a476d359820c48345ddf4f2f0fcc1ca041f3630680635c675a1d7be
33 2014-10-21 15:13:53 t17.08.21 9.0 2 1209d8b3c83c72df781b805a2c17a0939c841384aadc32e4e9005536a3bba53f
34 2014-10-24 17:16:08 t17.08.21.3 9.0 2 c89823eba2bdcdfcae33b33fb358154debe3fd88c75c684aa6b510e2d4b3ca53
35 2014-10-27 10:29:00 t17.08.21 9.0 2 884cbc1f0e70efae4815127bda7bab50883a707581d9d4061d268249c154ff2d
36 2014-10-28 12:48:54 t17.08.21 9.0 2 682b6c9d468e8d0ab8b5d4080cecf52a9dd66b59b99936a4941b8190c5f3fff9
37 2014-11-04 19:15:32 t17.08.23 9.0 3 23449109f0d4b07fd8010bb36b3b1084b48d5ac515725b68bf32322b4902397e
38 2014-11-05 21:15:57 t17.08.23 9.0 3 a79cfba79489d45a928ef3794d361898a2da4e1af4b33786d1e0d2759f4924c3
39 2014-11-05 22:00:42 t17.08.23 9.0 3 9801caaf44ce9a6be3f497e706f5b71dcc7c50351374c33dc2c9fcbb55f55e05
40 2014-11-06 13:55:46 t17.08.23 9.0 3 b19a233b07a1342f867aef1b3fb3e473b875bd788832bb9422cacb5df1bda04e
41 2014-11-13 10:52:56 t17.08.23 10.0 1 6c4c3bc7b0dfe531790bfb023b141c23f3c17a9971fed704d1b46e43f97d41c1
42 2014-11-13 11:34:31 t17.08.23 10.0 1 21a51f69d08aaf0aaaeb5b8413bb710c1727d9d08a9a1f46883f6f93691e0870
43 2014-11-14 13:10:40 t17.08.25 9.0 3 28a774235865924a7fec405aaf6463164a03f6e646c9fd964c3191304e59d35b
44 2014-11-18 11:56:13 t17.08.25 9.0 3 29a480579353c85e48b996ebc38cad9313ad6b9e495a3a69bf1519837acab04f
45 2014-12-08 15:19:29 t17.08.25 9.0 3 34bc147423f565bf38100913d25f85057e252755eef622abc1b788d511caf605
46 2014-12-11 18:28:38 t17.08.25 9.0 3 a188b87e495e4b0aad0d0595987677f9758479b120fb2ed3a04fba308a66830a
47 2014-12-16 18:13:13 t17.08.25 9.0 3 e39b1b36a5da4ad0f9c103478ab469b13a0528540ddbd1679eb24349a6726dbf
48 2014-12-24 10:37:26 t17.08.25 9.0 3 037b0dbfc2643a4a4779f6e3a8e5c8c41cbcd64533d2245c9a26dfd1d4f55dd8
49 2015-01-12 11:58:46 t17.08.25 9.0 3 9e74825e251a4f4cef9bc98273082f3b58695a224b1ed16ba6dedaa4c154cb21
50 2015-01-20 11:10:12 t17.08.26 9.0 3 5e221bd0eef231b7a948d8f6a2f660f8d6685cf2711fe50311485227ebcf9e51
51 2015-01-20 11:59:37 t17.08.26 9.0 3 635b43f7c0508f5e2cbf26f81daf0a730a0f0b06303c54c747b780f91430bb7f
52 2015-01-22 11:25:49 t17.08.26 9.0 3 efa57d43145de9a1e3c7541f94837a9c7b76d604b779d9847637d4a55b1ee723
53 2015-01-22 16:06:33 t17.08.26 9.0 3 9ace48ecef568bb9f5ccd462ca3efb4c2fbc15f0316323f1729e88cbe184158d
54 2015-01-23 10:14:46 t17.08.26 9.0 3 42e6b7afe4da672ab9bf647e73201135b3faf2121b629612b35307dc0d8698e4
55 2015-01-26 10:15:10 t17.08.26 9.0 3 9ebef65f00fc6ad70f591f7fb1f39f0f6b1766ff3fd9f47693ce669e70f84abb
56 2015-02-03 11:35:23 t17.08.26 8.0 3 6aed51b108d9f9f197842e17b0f58d4dec3709ca1eae4d42146d0bba0c145eaf
57 2015-03-02 10:18:13 t17.08.27 9.0 3 f6fce0464f1ad8044092e6812bdfb8545e1df5ee23aba828b4dcb86fb6d0e62b
58 2015-03-04 13:08:13 t17.08.27 9.0 3 fca765c535d1870d71ee152e5b004e73515ade1ee1c9a512a0858a508380465d
59 2015-03-05 12:59:51 t17.08.27 9.0 3 eac8441227077edb28adf096c5493710e2ca1978f4e4c4b2b93d481cd482d890
60 2015-03-17 12:50:29 t17.08.27 9.0 3 9f66ad282373b8b0df45dd32723dcdfcd4821e22cba4912678c3c8632e722730
61 2015-03-19 16:03:19 t17.08.27 9.0 3 77fa012060884d17eea1e54d97176a7a88c499f03315dfd602c1e1e17e556ede
62 2015-03-20 11:44:49 t17.08.27 9.0 3 3cade660e227faadad0060d793b69cb778842a514ac6996bc6aaddb6a055f445
63 2015-03-20 13:04:19 t17.08.27 9.0 3 6c3b955ad677ff26428d95a35b3a22ca3d523265674f08b6a0b59df270e6bf19
64 2015-03-24 13:07:23 t17.08.27 9.0 3 400a08b4a067b1e2fb3bee509bf933a746cf3ef2d000bb3181c7176344641a01
65 2015-04-22 12:29:48 t17.08.29 9.0 3 e3a2d62a997d4e9ee581fd86d312ac34caddd3165c07ca30c6741b4c21088d08
66 2015-04-24 12:07:43 t17.08.29 10.0 1 782b3bed336eab77a49df51e697bc64d830f7f11a32ff49abc599fe5b074e0b9
67 2015-05-20 12:52:28 t17.08.30 9.0 4 e03e6f7d98b214b5051b7484e4099ce5bd8c46e49faf44002c8ba146977127ef
68 2015-05-21 16:38:39 t17.08.30 9.0 4 28426751f30de4091dee898c70f49ec2ece607b6b642b45f5dcd9ae73ac38739
71 2015-05-22 12:51:18 t17.08.30 9.0 4 09178fa9c4be32982619a183b8b76bfc2ff57486aac04c8fed654a4d9fe91436
69 2015-05-22 12:51:18 t17.08.30 9.0 4 cb3976965f2105492193889f3f58f2ef2ccfeb8604e2b9448055ec6608d4aa85
70 2015-05-22 12:51:18 t17.08.30 9.0 4 de8759fe34eb2f395574be79479832402aa4d113e102d6945df493abee3d8b34
72 2015-05-28 13:48:14 t17.08.30 9.0 4 05ef4e0de8d57e6cd10d1673fcfca9c03b6e9a271d54028781e96235c4530e15
73 2015-06-02 12:15:26 t17.08.30 9.0 4 07b7041016c16341ea1f35a8c5fb5312d15f089ed5e925f78ffdd2568a8cf17c
74 2015-07-06 11:34:56 t17.08.31 9.0 4 c59ebe1fa6abe52c85f5f56a7da810a35e44c4772746bc829fa7d9e4e6a59477
75 2015-07-10 09:40:15 t17.08.31 9.0 4 3e850306025c231f09fa1922d1bb8e1a40bd8acc142d92219d9e9c8f8911b77d
76 2015-07-10 10:58:16 t17.08.31 9.0 4 008f4f14cf64dc9d323b6cb5942da4a99979c4c7d750ec1228d8c8285883771e
77 2015-07-13 01:23:13 t17.08.31 9.0 4 e919ae6a3bdc6abe6b695215a53b74072a39b86757e049f930866b3f69000957
78 2015-07-13 11:46:27 t17.08.31 9.0 4 567fa6bf28862ce7d14a2f3cf5b718780213fa3ee73f59557c29525f8daa200c
79 2015-07-14 10:57:44 t17.08.31 9.0 4 a94bf485cebeda8e4b74bbe2c0a0567903a13c36b9bf60fab484a9b55207fe0d
80 2015-07-14 11:16:54 t17.08.31 9.0 4 5a30f9010a316cc74ed271e732741c6d5d38f0e1c6f3b547176adcd40cb547ae
81 2015-07-14 18:44:14 t17.08.31 9.0 4 bfcd987ca3e79bd7ba8dde95a392dbba02ffa30242954a0cfa35ec81182f0cc8
82 2015-07-16 10:10:07 t17.08.31 9.0 4 3caf60dd3bb551d4da244dffaeb68fe01b59cd19bd0f0509611b706048b3382f
83 2015-07-28 13:56:35 t17.08.31 9.0 4 280371475442917b782f6a834003313f3aa0e5bb65f0acac5aab673d04336ba4
84 2015-08-05 09:51:31 t17.08.31 9.0 4 3cebf71221af741ea0b0883b45c092f900b513de3a004f81d3c595648311b7e9
85 2015-08-07 10:23:11 t17.08.34 8.0 4 90d07ea2bb80ed52b007f57d0d9a79430cd50174825c43d5746a16ee4f94ea86
86 2015-08-13 09:48:01 t17.08.34 8.0 4 6a331c4e654dd8ddaa2c69d260aa5f4f76f243df8b5019d62d4db5ae5c965662
87 2015-08-13 10:35:15 t17.08.34 8.0 4 17e646ca2558a65ffe7aa185ba75d5c3a573c041b897355c2721e9a8ca5fee24
89 2015-08-19 10:16:01 t17.08.34 8.0 4 22957429e8ab527ff8bb45fbc50aa8400ea643a68de8d43da3fee3239e2159d4
88 2015-08-19 10:16:01 t17.08.34 8.0 4 3553c136b4eba70eec5d80abe44bd7c7c33ab1b65de617dbb7be5025c9cf01f1
90 2015-10-13 10:52:52 t17.08.34 8.0 4 e68e835904aaef2da5b38e9532036117996d58d3fba05cbe454f9d418be60ef4

Jun 12, 2017

Research Report Released: Detecting Lateral Movement through Tracking Event Logs

JPCERT/CC has been seeing a number of APT intrusions where attackers compromise a host with malware then moving laterally inside network in order to steal confidential information. For lateral movement, attackers use tools downloaded on infected hosts and Windows commands.

In incident investigation, traces of tool and command executions are examined through logs. For an effective incident investigation, a reference about logs recorded upon tool and command executions would be useful.

JPCERT/CC conducted a research on typical tools and commands that attackers use after intrusion, and traces that they leave on Windows when executed. The result of the research is available on the report below:

Detecting Lateral Movement through Tracking Event Logs

https://www.jpcert.or.jp/english/pub/sr/ir_research.html

This entry will introduce the overview of the report.

Intended Audience

This report is designed for technical staff including those responsible for initial investigation of incidents. Even without forensic software or knowledge in forensics, readers capable of examining event logs and registry entries can understand the contents.

Tools and Commands

44 typical tools and commands have been featured on the report (as described in Appendix A) based on what JPCERT/CC has seen in multiple incident cases. Since these tools and commands are used by multiple attackers, it is likely that analysts encounter some of them during incident investigation.

Need for Detailed Logs

Under the default configuration of Windows, many of these tools and commands are not logged. In order to investigate what attackers did during the incident, preparation for log retention is necessary. The report describes how to record tools and command executions by setting audit policy and installing Sysmon. Other than the methods explained in the report, it is also possible to collect such logs with audit applications or EDR products.

Way Forward

We are planning to examine other tools and commands as well. In addition to event logs and registry entries, we will also look into forensic artifacts such as MFT and journal files.

We welcome any feedback from you at global-cc [at] jpcert.or.jp.

-         Shusei Tomonaga

(Translated by Yukako Uchida)

Appendix A:  Examined Commands and Tools
Table 1: List of Examined Commands and Tools
Attacker's Purpose of Using ToolTool
Command execution PsExec
wmic
PowerShell
wmiexec.vbs
BeginX
winrm
at
winrs
BITS
Obtaining password hash PWDump7
Quarks PwDump
mimikatz
WCE
gsecdump
lslsass
Find-GPOPasswords.ps1
Mail PassView
WebBrowserPassView
Remote Desktop PassView
PWDumpX
Malicious communication relay
(Packet tunneling)
Htran
Fake wpad
Remote login RDP
Pass-the-hash
Pass-the-ticket
WCE
mimikatz
Escalation to SYSTEM privilege MS14-058 Exploit
MS15-078 Exploit
Privilege escalation SDB UAC Bypass
Capturing domain administrator
rights account
MS14-068 Exploit
Golden Ticket (mimikatz)
Silver Ticket (mimikatz)
Capturing Active Directory database
(Creating a domain administrator user or
adding it to an administrator group)
ntdsutil
vssadmin
Adding or deleting a user group net user
File sharing net use
net share
icacls
Deleting evidence sdelete
timestomp
Deleting event log wevtutil
Obtaining account information csvde
ldifde
dsquery

May 12, 2017

Fact-finding Report on the Establishment and Operation of CSIRTs in Japan

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

JPCERT/CC conducted “Survey on the Establishment and Operation of CSIRTs in Japan” in the end of 2015. Following the Japanese report released in 2016, we have just released the English version of the report on JPCERT/CC website to share the outcomes with the information security community member all around the globe. Although the basis of social composition, culture, organizational constitution and so on may differ in each economy, we hope that this document will serve as a useful reference in terms of establishing a CSIRT or comparing the situation with those organizations in overseas.

Here in this blog will cover an executive summary of the report.

Background of the survey

Cyber attacks in recent years have become increasingly diverse in terms of their aims, targets, and TTPs (Tactics, Techniques, and Procedures) used that the impact can be large enough to shake the foundation of a business. One approach that is drawing attention is to establish a Computer Security Incident Response Team (CSIRT) that will serve as the linchpin of an organization to effectively handle security incidents. Cybersecurity Management Guidelines released from Ministry of Economy, Trade and Industry in December 2015 also referred to the need to establish CSIRTs, and this has been boosting the number of CSIRTs in Japan.

Cyber security communities, including the CSIRT community, are quite active in Japan. Nippon CSIRT Association (NCA) is the venue for local CSIRTs to come together for information sharing and joint activities, which has 232 member organizations (as of May 2017). JPCERT/CC conducted the survey targeting 66 organizations which belongs to NCA with an aim to assist those who wish to establish a new CSIRT by compiling the facts of CSIRT activities in various local organizations. The survey took place in December 2015, by means of a questionnaire and interviews, covering questions on organizational structure, scale, functions, policies and other various aspects of CSIRTs. Here below will introduce some interesting findings described in the report.

Items to be defined upon establishing a CSIRT

Business activities, scales, department structures, and anticipated risks differ according to the organization. For this reason, based on the results of the survey, the following six items were identified as matters that organizations should define upon establishing an internal CSIRT.

  • Scope of services provided by CSIRTs
  • Authority granted to CSIRTs
  • Deployment and members of CSIRTs
  • Point(s) of contact (PoC)
  • Reporting structure to effectively communicate the effects of CSIRT activities within the company
  • Periodic review of CSIRT activities

 Among these, I would like to highlight a few findings of the survey, which are considered noteworthy for organizations in overseas as followings;

Scope of services provided by CSIRTs

A CSIRT is required to receive, review and respond to various incident reports. Therefore, scope of its service such as contents, targets, range of responsibility, and so forth need to be considered.

NCA categorizes services offered by CSIRTs roughly into the following three types: reactive services, proactive services, and security quality control services. Of these three categories, the survey results identified the main services provided by CSIRTs in each category as follows;

 - Reactive services
  • More than 80% answered "Incident handling," "Issuing security alerts" "Log Analysis" and "Vulnerability handling" are provided to respond promptly in the event of an incident
 - Proactive services
  • More than 80% answered "Security warning announcement” is provided ahead of an incident
  • Nearly 70% answered "Provision of security related information" and "Intrusion detection" are provided to monitor any signs of an attack
 - Security quality control services
  • More than 70% answered "Conducting awareness raising activity", "Organizing educational programs" and "Consulting security related issues" as a service aimed at increasing the knowledge and skills to respond to cyber security

In some CSIRTs, all of these services are provided whereas some CSIRTs only provide one or two of those. It is not the variety of services they provide that matters to a CSIRT, but the capability to provide the kinds of services that the organization needs.

Also, the results of the survey showed that about 60% of the organizations has documented their service definition, and over 80% of the organizations has defined and documented their security policies that were approved by the management.

Authority granted to CSIRTs

In responding to security incidents, it is necessary as an organization to make appropriate and timely decisions. While CSIRTs are in a position to provide assistance to departments or persons for decision-making, it is important to understand about up to what point a CSIRT authority is granted.

For example, when a system needs to be suspended for risk avoidance in the event of an urgent incident, about 12% of the CSIRTs answered that they themselves have the authority to order the systems to be stopped, while 85% of the CSIRTs answered that they do not have the authority to order but are in a position that allows them to advise on the decision-making.

Figure 1. Authority of the CSIRT in the event of an incident
Figure1

These results show that not so many organizations possess a strong authority in decision-making. However, some CSIRTs answered in the interview that they do not necessarily need to have such a powerful authority as to suspend systems in order to function effectively as a CSIRT. What matters to them is how effectively can the CSIRT collaborate with the management level to expedite accurate and rapid business decision.

Incident handling and Escalation

In case of an incident, an escalation process must be clearly defined, documented and officially approved to ensure that the incident is directed towards appropriate departments. The result shows that 74% of the CSIRTs have these processes implemented towards management, 52% implemented towards public relations department, and 50% implemented towards legal department. This indicates that CSIRTs are working closely with the management level in case of an incident, but more effort can be taken towards other related departments as well.

Information Sharing

It is essential for CSIRTs to share information and cooperates with other departments not only within the organization but also with other external partners such as other CSIRTs. Joining the information sharing framework allows the team to obtain and respond to a cyber threat in an effective way that it ultimately helps to protect the organization.

The result shows that all the survey respondents participate in more than one framework for information sharing. Specific frameworks that they join are WAISE (Watch and Warning Analysis Information for Security Experts - operated by JPCERT/CC), CCI (Counter Cyber Intelligence - operated by National Police Agency), working groups of Financials ISAC Japan, J-CSIP (Initiative for Cyber Security Information sharing Partnership of Japan - operated by Information-technology Promotion Agency, Japan) and so on.

When asked about the primary methods of expression used for sharing information, all the respondents selected text format. At the time when this survey was conducted (December 2015), some CSIRTs have already implemented STIX/TAXII, which is a globally recognized standard for incident information sharing. The protocol has been gradually accepted by an increasing number of CSIRTs over the two years after the survey.

Figure 2. Primary method(s) of expression used for sharing information
Figure2_3

Information sharing and collaboration requires investment of time and technical resources, however, it benefits by far than negatives. Some of the respondents have said in the interview that information sharing with other CSIRTs enables them to acquire knowledge and exchange insights, which helps to keep up the motivation of their CSIRT members. The importance of building trust relationships with other CSIRTs was also pointed out by other interviewees. They spoke of participating NCA and other community activities had provided opportunities to reframe how they interact with their organizations.

Conclusion

The report points to six items that should be defined at the time of establishing an internal CSIRT. However, it does not necessarily mean that fulfilling all these conditions will ensure its activities live up to the expectations of the organization. For the sake of an internal CSIRT to function effectively, it is extremely important that the team shares information and cooperates with other departments within the organization and other CSIRTs. In addition, through day-to-day operations including exercises and training, as well as responding to actual incidents, we believe that newly established CSIRTs develop into a trusted and indispensable part of the organization.

The full report can be downloaded here:

https://www.jpcert.or.jp/english/pub/sr/2015_CSIRT-survey.html

- Misaki Kimura

May 02, 2017

Volatility Plugin for Detecting RedLeaves Malware

Our previous blog entry introduced details of RedLeaves, a type of malware used for targeted attacks. Since then, we’ve seen reports including those from US-CERT that Management Service Providers (MSPs) have been targeted [1] [2]. In the US-CERT report, some instances have been identified where RedLeaves malware has only been found within memory with no on-disk evidence because of the behavior of self-elimination after the infection.

To verify the infection without on-disk evidence, investigation needs to be conducted through memory dump or logs (e.g. proxy logs) stored in network devices.

This article introduces a tool to detect RedLeaves in the memory.

It is available on GitHub:

JPCERTCC/aa-tools · GitHub

https://github.com/JPCERTCC/aa-tools/blob/master/redleavesscan.py

Tool Details

The tool works as a plugin for The Volatility Framework (hereafter “Volatility”), a memory forensic tool. redleavesscan.py has the following functions:

  • redleavesscan: Detect RedLeaves in memory images
  • redleavesconfig: Detect RedLeaves in memory images and extract malware configuration

To run the tool, save redleavesscan.py in ”contrib/plugins/malware” folder within Volatility, and execute the following command:


$python vol.py [redleavesscan|redleavesconfig] –f <memory.image> ––profile=<profile>

Figure 1 shows an example output of redleavesscan. You can see the detected process name (Name), Process ID (PID) and the name of detected malware (Malware Name).

Figure 1: Output of redleavesscan
Fig1

Figure 2 shows an example output of redleavesconfig. For details about RedLeaves configuration, please see our previous blog entry.

Figure 2: Output of redleavesconfig
Fig2

In closing

It has been confirmed that the attacker group who uses RedLeaves also uses PlugX. To detect PlugX in memory, please use the Volatility plugin released by Airbus [3].

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference:

[1] US-CERT: Intrusions Affecting Multiple Victims Across Multiple Sectors

https://www.us-cert.gov/sites/default/files/publications/IR-ALERT-MED-17-093-01C-Intrusions_Affecting_Multiple_Victims_Across_Multiple_Sectors.pdf

[2] PwC: Operation Cloud Hopper

https://www.pwc.co.uk/issues/cyber-security-data-privacy/insights/operation-cloud-hopper.html

[3] Volatility plugin for PlugX

https://bitbucket.org/cybertools/volatility_plugins/wiki/Home