60 posts categorized "#JPCERT news" Feed

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

May 12, 2017

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

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

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

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

Background of the survey

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

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

Items to be defined upon establishing a CSIRT

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

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

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

Scope of services provided by CSIRTs

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

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

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

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

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

Authority granted to CSIRTs

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

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

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

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

Incident handling and Escalation

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

Information Sharing

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

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

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

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

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

Conclusion

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

The full report can be downloaded here:

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

- Misaki Kimura

May 02, 2017

Volatility Plugin for Detecting RedLeaves Malware

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

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

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

It is available on GitHub:

JPCERTCC/aa-tools · GitHub

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

Tool Details

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

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

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


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

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

Figure 1: Output of redleavesscan
Fig1

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

Figure 2: Output of redleavesconfig
Fig2

In closing

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

- Shusei Tomonaga

(Translated by Yukako Uchida)


Reference:

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

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

[2] PwC: Operation Cloud Hopper

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

[3] Volatility plugin for PlugX

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