Targeted Ransomware Attacks in Taiwan

Introduction

Following reports of suspected ransomware attacks against various organizations in Taiwan, this report summarizes what is known of the threats thus far as well as providing recommendations for those that either operate in the targeted industries or region. Whilst official details of these ransomware attacks remain vague, likely only shared between the victim and their investigative partners, open-source intelligence combined with publicly released statements have allowed Cyberint Research to provide some insight into these recent incidents.

Based on news reports, two organizations operating in the petrochemical industry were subjected to cyberattacks during the first week of May 2020, CPC Corporation on Monday 4 May, and Formosa Petrochemical Corporation (FPCC) on Tuesday 5 May. These incidents appeared to align with reported attacks against Powertech Technology, also on Monday 4 May, and at least two other non-disclosed organizations operating within the semiconductor industry.

Whilst no one has claimed responsibility for these attacks, the malicious files samples observed by Cyberint Research thus far appear consistent across victims and therefore suggest that the attacks were orchestrated by the same threat actor or group. Technical analysis of the threats deployed in these incidents identifies the initial use of a PowerShell-based loader that uses ‘reflection’ to execute a ransomware payload in memory. Subsequently, this ransomware payload encrypts both user files and databases present on local, removable and network drives. Notably however, the presence of a file check, which if found results in the ransomware process terminating, provides an effective ‘kill switch’ and could allow victims to contain or prevent the spread of this threat.

Unlike other financially-motivated ransomware campaigns employing the ‘steal, encrypt and leak’ tactic, as conducted by organized cybercriminal gangs such as ‘Maze’ and ‘Revil Ransomware Team’, those behind these seemingly industry-targeted attacks may be lower-sophistication threat actors or they have alternate motivations. As more reports of these ransomware attacks continue to surface, organizations operating in Taiwan, and especially those in the petrochemical and semiconductor industries, should remain vigilant for campaigns exhibiting similar traits.

Key Findings

• Organizations operating in the petrochemical and semiconductor industries in Taiwan seemingly being subjected to targeted ransomware attacks.
• Ransomware dropped from a PowerShell script which loads the threat into memory.
• The ransomware includes a `File.Exists` test that results in the process terminating if the file is found and could allow the creation of a ‘kill switch’ file to prevent data encryption.
• These incidents **do not** appear to be ‘steal, encrypt and leak’ campaigns conducted by sophisticated cybercriminal gangs such as ‘Maze’ and ‘Revil Ransomware Team’.

Publicly Disclosed Incidents

Petrochemical Industry

CPC Corporation, a Taiwan state-owned gasoline, natural gas and petroleum company headquartered in Kaohsiung City, confirmed on Monday 4 May 2020 that it had suffered from a ransomware attack resulting in the shutdown of its IT systems.

Whilst the incident did not impact production, CPC’s gas stations were unable to manage revenue records or accept customer payments via CPC payment cards or mobile payment apps. Unconfirmed open sources suggest that this incident may have commenced with the introduction of an infected USB storage device, subsequently propagating to other systems that were affected when restarted, although no corroborating evidence of this infection vector can be found at this time.

Following this incident, employees of Formosa Petrochemical Corporation (FPCC), a Taiwanese oil refiner and producer second only to CPC Corporation, were reportedly placed on “*high alert*” and subsequently noticed “*irregularities*” in their own network at around 1100hrs (local time) on Tuesday 5 May 2020.

To aid in their investigation, all FPCC IT systems were reportedly shutdown leading to the discovery of an unspecified malicious threat which, much like CPC, did not affect production but did prevent their gas stations from calculating daily income. In addition to no reported data loss at FPCC, reports suggest that customers were not impacted by the incident, unlike CPC’s, and that they are currently working on restoring all their systems to normal.

Whilst many reports have linked these incidents at CPC and FPCC together, FPCC have not, as yet, provided official details of any ransomware threat and reports suggest the discovery of file infector malware that typically attempts to propagate by infecting executable files.

The Taiwanese Ministry of Justice Investigation Bureau (MJIB) are reportedly investigating both incidents to determine if they are related and, according to press reports quoting an unnamed national security official, these could be “*trial run”* cyberattacks on the run up to President Tsai Ing-wen’s second term that commences on 20 May 2020.

Semiconductor Industry

Taiwanese semiconductor assembly, packaging, and testing company ‘Powertech Technology’ were also reportedly subjected to a ransomware incident on Monday 4 May 2020, potentially suggesting a trend in attacks against Taiwanese organizations. Based on reports of Powertech’s incident, servers in their Hsinchu factory were infected with an unspecified ransomware threat that has since been removed and their company data reportedly remains unaffected.

Whilst details have not been shared publicly, closed sources indicate that at least two other Taiwanese semiconductor organizations have suffered similar attacks using the same ransomware variant during the first week of May 2020, as such it would appear that these attacks are somewhat targeted in nature, focused on the petrochemical and semiconductor industries in Taiwan.

Ransomware Threat

Analysis of the ransomware threat was initially conducted on malicious samples obtained from publicly shared file hashes believed to originate from the ransomware incident at CPC. Pivoting on these malicious samples allowed additional samples to be gathered, albeit their origin, other than Taiwan, cannot be determined without each victim publicly releasing details of their ransomware incidents.

Initial Infection Vector

Other than unconfirmed open sources suggesting that an infected USB storage device may have been the initial infection vector for one victim, perhaps an unlikely scenario for all of the suspected victims, malicious threats are commonly delivered through lures sent to employees, such as emails containing malicious attachments or links and targeted communications sent through social media.

Conversely, as seen in the ‘steal, encrypt and leak’ ransomware campaigns orchestrated by organized cybercriminal gangs, higher-sophistication threat actors exploit vulnerabilities in an organization’s internet-facing infrastructure to gain access to their internal network before stealing data and then deploying a ransomware threat to make financial gains.

PowerShell Loader

Aside from a yet unconfirmed delivery and execution method, the initial threat presented as a PowerShell loader, observed as being dropped with the filename lc.tmp.

Upon execution, this PowerShell loader first decodes a base64 encoded .NET assembly and then uses the ‘Assembly.Load’ method (Figure 1) to execute this code with the same trust level at which the script is run.

 

 

 

 

Figure 1 – PowerShell loader

Reflective DLL Loading

The base-64 decoded ransomware payload is a dynamic link library (DLL) named LE.dll that has been encrypted and obfuscated using the open-source .NET application protector ‘ConfuserEx’ (Figure 2).

Figure 2 – ConfuserEx identifier

Protectors such as ConfuserEx are commonly used to thwart and complicate analysis, albeit in this case Cyberint Research were able to decompile the .NET application to gain an understanding of its operation. Please note, all methods and variables are generically named by ConfuserEx and therefore have been renamed during this analysis to reflect their content rather than being the malware author’s original names.

This DLL is subsequently executed in memory, rather than from disk, based on the PowerShell script using system reflection and referencing the ‘lc’ namespace and class (Figure 3).

Figure 3 – Ransomware payload entry point

Initial Configuration 7 Evasion

Once the ransomware payload has been executed, `lc.StartAction` calls the main ransomware method. Having first created a mutual exclusion object (mutex), `8c861dd7-ef9b-41c6-b59c-c7cd94434d01`, to prevent multiple instances of the threat from executing simultaneously, a number of discovery and configuration steps are performed, along with loading predefined settings, to prepare for the encryption phase.

Furthermore, steps are taken to evade detection with both system notifications and Microsoft Defender (also known as Windows Defender) being disabled.

System notifications, such as those displayed in the Windows ‘Action Center’ are disabled by first modifying the `PushNotifications` registry key and setting the `ToastEnabled` value to `0` (the value will be created if it does not already exist) and then restarting the ‘Windows Push Notifications User Service’ `wpnuserservice` (Figure 4).

Figure 4 – System notifications disabled

Subsequently, Microsoft Defender, the anti-malware solution shipped with modern Windows versions by default, is disabled by creating a RunspaceFactory object to execute a PowerShell command which in turn disables both real-time and behavioural monitoring as well as preventing malware samples from being submitted to Microsoft by changing the SubmitSamplesConsent to 2 for ‘never’ (Figure 5).

Figure 5 – Microsoft Defender anti-malware disabled

Disabling real-time protection will prevent Microsoft Defender from detecting known or generic threats when they are executed whilst disabling behavioral monitoring will prevent the detection of suspicious behaviors such as the widespread file changes resulting from a ransomware threat.

Notably, this process is performed after first disabling notifications to prevent the victim from being notified of the reduced security configuration.

Time Check

Prior to performing any encryption process two checks are performed, the first of which is a time check to ensure the ransomware only operates during a predefined time window (Figure 6).

Figure 6 – Time check method

File Check/Kill Switch

The second of the two checks performed by the ransomware is potentially useful to defenders as it offers an opportunity to implement a ‘kill switch’ and prevent the victim system from being encrypted.

Presumably to prevent the ransomware from executing on an already infected system, a test for the presence of a file name readme.tmp in the %SYSTEMDRIVE%\ProgramData directory is performed (Figure 7).

Figure 7 – File Check

Should the file not exist, a text file is created and contains the explicit message You’re getting f*cked!, and then the encryption process commences. Given the presence of another ransom note,this file is likely just an internal flag and is not necessarily intended to be viewed by the victim.

In the event of this file already being present, the ransomware terminates using the Environment.Exit(0) method with no further action. As such, the simple creation of a text file named readme.tmp in this location would function as a ‘kill switch’ and prevent the victim system from being encrypted, even if the initial PowerShell script were to be executed and the .NET DLL launched.

Whilst this method may work for those that consider themselves to be at high risk of, or impacted by, this current campaign, it would presumably be trivial for the threat actor to recompile the .NET code with an enhanced file check method.

Stopping Database Services

In preparation for file encryption, the ransomware kills any running Microsoft Outlook process as well as checking for the presence of the following database services that, if found, are also stopped (Figure 8):

• MariaDB
• Microsoft SQL
• Microsoft Exchange Information Store
• MySQL
• Oracle

Figure 8 – Stopping database services and Outlook processes

This process will ensure that any open database, or Microsoft Outlook, data files are closed prior to encryption which, aside from preventing file corruption, would prevent any file locks from preventing the encryption process.

Whilst most ‘end-user’ systems will not host database applications, the encryption of database servers or Microsoft Exchange mail servers could result in incremental data loss, arising from changes made since the last full backup, if not devastating data loss if an organization fails to maintain suitable backups.

Encryption File Targets

Following a discovery process, the ransomware determines if a target directory meets the criteria for its file content to be encrypted (Figure 9):

• Target directory name must not appear in the predefined list of ‘excluded paths’;
• Target directory must contain less than 100 files.

Target directory’s last write time must be more recent than 1 January 2018.

 

 

 

 

 

 

       

 

Figure 9 – Encryption file targets

Subsequently, having found an acceptable directory, the extension of each file is compared against the predefined list of ‘target file extensions’ and ‘excluded file extensions’ to determine if the file is to be encrypted.

The predefined configuration, for both path/file extension exclusions and target file extensions, appears to ensure that the system remains stable after encryption and appears to focus on productivity, database and development-related (source code) file types (Figure 10).

Figure 10 – Embedded configuration

In addition to selecting common document, email, image and multimedia files for encryption, Windows shortcut files (.lnk) also appear to be encrypted and this would presumably prevent a user from launching applications from the Windows Start Menu.

Encryption Process

Once an appropriate file has been selected, the encryption method (Figure 11) uses the RijndaelManaged class to encrypt the data using the Advanced Encryption Standard (AES) Cipher Block Chaining (CBC) cipher mode which introduces ‘feedback’. The use of CBC and this ‘feedback’ ensures that as each unencrypted block is processed, it is combined with the cipher text of the previous block using a bitwise XOR operation and ensures that identical blocks of unencrypted data do not appear alike in the final encrypted output.

Figure 11 – Encryption method

The encryption key used for this process appears to be generated by taking a random 32-byte string (Figure 12) which is then encrypted using an embedded RSA public key value (Figure 13) and SHA256 hashed.

Figure 12 – Encryption key generation

Figure 13 – Embedded RSA public key value

Having then successfully encrypted the target file, a .locked file extension is appended to the filename.

Ransom Notes

The victim is finally notified of the ransomware’s presence by the desktop wallpaper being changed and text files being created in various directories.

The wallpaper is embedded within the ransomware binary as a base64 encoded PNG file which advises the victim to read the ransomware note (Figure 14) and is configured, via the Windows registry, to replace any existing desktop wallpaper whilst stretching to fill the screen (Figure 15).

Figure 14 – Ransom wallpaper

Figure 15 – Wallpaper registry modification

Subsequently, the ransom notes (Figure 16), named How To Unlock Files.txt , are dropped into the following locations:

• %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\How To Unlock Files.txt
• %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Startup\How To Unlock Files.txt
• %PUBLIC%\Desktop\How To Unlock Files.txt
• %HOMEPATH%\Desktop\How To Unlock Files.txt

 

Figure 16 – Ransom note

The ransom note includes contact information for the threat actor in the form of two email addresses registered on free encrypted webmail services, although, of those observed, these do not appear to relate to any known threat group. In the case of CPC incident, consistent with the above ransomware threat, the following email addresses were observed in the ransom note:

Additionally, discussions on the popular Taiwanese forum ‘PTT BBS’ regarding these recent incidents included a screenshot (Figure 17) of a ransom note within a thread discussing the FPCC incident. Whilst FPCC have not confirmed a ransomware incident, this ransom note is also consistent with the above ransomware threat albeit with different contact email addresses from those observed at CPC.

Figure 17 – Ransom note screenshot potentially linked to FPCC

Final Comments

Unlike recently observed high-profile ransomware campaigns using the ‘steal, encrypt and leak’ tactics, such as those orchestrated by sophisticated cybercriminal groups like ‘Maze’ and ‘Revil Ransomware Team’, these incidents appear somewhat less sophisticated, lack any explicit financial demand and there does not appear to have been any public exposure or demands issued by a threat actor or group.

Given this, consideration should be given as to the true motives of these seemingly targeted attacks, whilst these could be the actions of a cybercriminal threat actor with an interest in particular Taiwanese industries for financial gain, alternate motivations could be at play such as a nation-state, or other, threat actor seeking to cause disruption or distract from other activity.

Indicators of Compromise (IOC)

Email addresses

The following threat actor email addresses have been observed in ransom notes potentially linked to the incident at CPC:

• aleksanderemelianenko[@]protonmail[.]com
• aleksanderemelianenko[@]tutanota[.]com

Whilst the following are potentially linked to the unconfirmed incident at FPCC:

• fedoremelianenko1976[@]protonmail[.]com
• fedoremelianenko[@]tutanota[.]com

Malicious File Hashes

The following file hashes relate to this ransomware threat, those with a lc.tmp filename being the PowerShell loader used to deliver the LE.dll ransomware payload. Whilst most antivirus vendors label these threats with ‘generic’ detections including terms such as ‘PowerShell’ or ‘Ransom’, TrendMicro specifically label this threat as ‘COLDLOCK’.

MD5	SHA1	SHA256	FILENAME
28991de4ef6d97b324503991adb6bc0b	9d6feb6e246557f57d17b8df2b6d07194ad66f66	c5108344e8a6da617af1c4a7fd8924a64130b4c86fa0f6d6225bb75534a80a35	le.dll
234d17d8978717d33bf53015760878ea	08677a3dac3609d13dc4a2a6868ee2f6c1334f4579356d162b706a03839bb9ff	75e49120a0238749827196cebb7559a37a2422f8	lc.tmp
7aab677263be856a668dc3d38334fcd8	a2046f17ec4f5517636ea331141a4b5423d534f0	2a51d33fb9458f9d5b8cb6720e01c060b841c9c1974b504228979ae474e57f33	lc.tmp
234d17d8978717d33bf53015760878ea	75e49120a0238749827196cebb7559a37a2422f8	08677a3dac3609d13dc4a2a6868ee2f6c1334f4579356d162b706a03839bb9ff	lc.tmp

Paths/Filenames

Aside from the ransomware threat existing in memory, the following files are dropped:

• %ALLUSERSPROFILE%\readme.tmp
• %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\How To Unlock Files.txt
• %ALLUSERSPROFILE%\Microsoft\Windows\Start Menu\Programs\Startup\How To Unlock Files.txt
• %PUBLIC%\Desktop\How To Unlock Files.txt
• %HOMEPATH%\Desktop\How To Unlock Files.txt

Mutexes

The following mutual exclusion object was observed during the execution of this ransomware threat:

• 8c861dd7-ef9b-41c6-b59c-c7cd94434d01

 

MITRE ATT&CK

 

TECHNIQUE	TACTIC
T1091 – (Potentially) Replication Through Removable Media	Initial Access
T1064 – Scripting	Defense Evasion, Execution
T1060 – Registry Run Keys / Startup Folder	Persistence
T1083 – File and Directory Discovery	Discovery
T1486 – Data Encrypted for Impact	Impact

Recommendations

Whilst the initial attack vector has not been publicly confirmed, organizations should consider steps to reduce their attack footprint to minimize the risk from this, and other, threats. Regular technical assessments, such as the discovery of open ports and running services on external-facing infrastructure, as well as measuring employee readiness, such as through phishing simulations and training, will allow organizations to determine their current cybersecurity status and enable the creation of plans for improvement.

Given that users are often directly targeted by nefarious campaigns, user education and regular cybersecurity reminders should be provided to ensure they are aware of the dangers of opening suspicious links or files. Furthermore, users should not be permitted to use unsanctioned removable media devices, such as USB flash drives, with controls, where possible, being implemented to prevent their use, be that enforcement at a hardware/BIOS level or through the configuration of a Windows Group Policy (such as configured through Computer Configuration > Administrative Templates > System > Removable Storage Access).

In the case of infrastructure vulnerabilities being exploited to download and install ransomware components, such as seen in other targeted ransomware attacks, it is essential that external-facing servers and other devices are regularly patched to minimize the risk of compromise. Furthermore, activity such as outbound network communications and requests being sent to suspicious or anomalous IP addresses or domains may provide an early indication of compromise, especially when the compromised host does not normally communicate externally. As such, due consideration should be given to hardening infrastructure, limiting communications and monitoring network activity for potential signs of compromise or exploit.

As with all ransomware attacks, the ability to successfully restore known-good data relies on having adequate backups; organizations should take steps to ensure that their disaster recovery plans are robust, tested and in-place before a worst-case scenario occurs.

To both prevent or reduce the propagation of malicious code across an organization’s network and to limit the impact of a malicious process, user and workstation permissions should be assigned on a ‘least privileges’ basis. Furthermore, local administrative permissions should be disabled and access to administrative tools such as exe and wmic.exe denied to prevent their abuse by malicious code. Administrators requiring elevated permissions or access to administrative tools should use an elevated account only for the duration of that task and utilize ‘normal’ user permissions for day-to-day operations.

The use of ‘application whitelisting’ should be considered to prevent files being executed from suspicious directories such as %TEMP%, directories such as this are common ‘drop’ locations for malicious binaries.

Given the use of a file presence check during the execution of the ransomware payload, those that consider themselves to be at heightened risk of, or currently impacted by, this current campaign could consider the creation of the ‘kill switch’ file in %SYSTEMDRIVE%ProgramDatareadme.tmp to contain the threat.