62 posts categorized "#JPCERT news" 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  

Jun 05, 2018

How to Describe Vulnerability Information?

Today, I would like to introduce an activity at the Vulnerability Coordination Group of JPCERT/CC.
It is a method to describe a vulnerability using Vulnerability Description Ontology (VDO).

JPCERT/CC receives software vulnerability information from domestic and overseas reporters, then coordinates them in between the vendor/developer and the reporter. While there is a vulnerability reporting template, vulnerability itself is described in a free format. Reporter can describe about a vulnerability in a way they like. From a vulnerability coordinator's perspective, the following are a few obstacles that we are facing:

1. It is necessary to "understand" the technical aspects

For example, the description in CVE for the vulnerability CVE-2014-8606 is as follows:

Directory traversal vulnerability in the XCloner plugin 3.1.1 for WordPress and 3.5.1 for Joomla! allows remote administrators to read arbitrary files via a .. (dot dot) in the file parameter in a json_return action in the xcloner_show page to wp-admin/admin-ajax.php.

When reading this information, the following technical details can be extracted:

  • (Affected) Products and Versions
    • Xcloner plugin 3.1.1 (for WordPress)
    • Xcloner plugin 3.5.1 (for Joomla!)
  • Vulnerability type: Directory traversal
    • Root cause: the parameter "file" is not validated
    • Attacker: Remote authenticated attacker
    • Impact: Arbitrary file read

There is no unique way to articulate the technical aspects of a vulnerability. A free format allows various reporters to describe a vulnerability using their own way. In some cases, there may be redundant information, or in other cases, not enough information.

2. When the vulnerability description is written in your non-native language, it can be extremely difficult to comprehend

A lot of vulnerability information is published in English, so organizations who do not have any English speaker may have a difficulty in comprehending a vulnerability due to the language barrier. In addition, various sources are now publishing vulnerability information, and lots of non-English vulnerability information are publicly available.
For example, CNNVD in China provides vulnerability information only in Chinese.

To overcome these issues, the National Institute of Standards and Technology (NIST) in US has proposed the creation of Vulnerability Description Ontology (VDO).

VDO provides basic building blocks to describe a vulnerability so that a vulnerability can be described without using a free format.
Below is an example of the vulnerability (CVE-2014-8606 from above) described using the VDO (taken from NIST IR 8138 - Appendix A)

Vulnerability: cve.mitre.org CVE-2014-8606
Provenance: http://www.vapid.dhs.org/advisories/wordpress/plugins/Xcloner-v3.1.1/
Scenario: 1
Type: cve.mitre.org CWE-22
Products:
  cpe.nist.gov
  cpe:2.3:a:xcloner:xcloner:3.1.1:*:*:*:*:wordpress:*:*
  cpe:2.3:a:xcloner:xcloner:3.5.1:*:*:*:*:joomla\!:*:*
Attack Theater: Remote
  Remote Type: Internet
Barriers: Privilege Required
  Privilege Level: Administrator
    Relating to Context: Application
Context: Application
Entity Roles: Primary Authorization
Entity Roles: Vulnerable
Impact Method: Trust Failure
  Trust Failure Type: Failure to Verify Content
Logical Impact: Read(Direct)
  Scope: Limited
    Criticality: Low
Context: HostOS
  Entity Roles: Secondary Authorization
Impact Method: Code Execution
Logical Impact: Read(Direct)
  Scope: Limited
    Criticality: High

While VDO is still in a draft phase. I believe that it has a huge potential to

  • Provide a common language for understanding and exchanging information on vulnerabilities
  • Provide a format to automatically manage vulnerability information

JPCERT/CC is currently attempting to see if describing vulnerabilities using VDO can make the vulnerability coordination operations more efficient.

The following shows how vulnerability information can be entered into the VDO format using an editor.
Currently, we have implemented a JSON Schema to enter the Noun Groups defined in NISTIR 8138 in a simple manner to test whether this can be used in a practical manner.

GIFアニメーションです

More details on this attempt to make vulnerability coordination more efficient through the VDO will be presented at the 30th Annual FIRST Conference.

If you are interested in VDO and its application, please contact us at vultures [at] jpcert.or.jp.

- Masanobu Katagi

Apr 27, 2018

JPCERT/CC Publishes "Vulnerability Coordination and Disclosure Policy"

JPCERT/CC has been coordinating and disclosing software vulnerabilities under the "Information Security Early Warning Partnership" since 2004. We have coordinated and disclosed over 1,500 vulnerabilities with developers as of the end of 2017. The "Information Security Early Warning Partnership" has a guideline that serves as a framework for how vulnerabilities are coordinated within Japan. An overview of the framework including how reported vulnerabilities are coordinated and disclosed is provided at the following:

Guidelines for Information Security Early Warning Partnership (Summary)

https://www.jpcert.or.jp/english/vh/partnership_guideline2017_summary_en.pdf

While the framework does not explicitly state "only reports from domestic reporters" will be coordinated, JPCERT/CC has mainly coordinated vulnerabilities discovered and reported by reporters in Japan through this framework.

Over the years, there have been vulnerability reports coordinated by JPCERT/CC in cooperation with overseas CSIRTs or directly reported by overseas reporters. As the number of such reports have increased, it became apparent to us that we needed an outward facing policy that states what vulnerability reports will be coordinated and how they will be coordinated. The main goal in publishing this policy is to set expectations on what vulnerability reports may or may not be coordinated to reporters of vulnerabilities to JPCERT/CC.

The policy states the point of contact at JPCERT/CC for vulnerability reports, what we require in a vulnerability report, what reports will be coordinated, what will be published, etc.

For details, refer to the policy that is on the JPCERT/CC website.

JPCERT/CC Vulnerability Coordination and Disclosure Policy

https://www.jpcert.or.jp/english/vh/2018/20180330-vulpolicy.pdf

If you have any questions, please contact us at vultures [at] jpcert.or.jp.

- Taki Uchiyama
JPCERT/CC Member of Technical Committee

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 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)

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