Stealing the LIGHTSHOW (Part Two) — LIGHTSHIFT and LIGHTSHOW
Mandiant
Written by: Mandiant Intelligence and Consulting
In part one on North Korea's UNC2970, we covered UNC2970’s tactics, techniques and procedures (TTPs) and tooling that they used over the course of multiple intrusions. In this installment, we will focus on how UNC2970 utilized Bring Your Own Vulnerable Device (BYOVD) to further enable their operations.
During our investigation, Mandiant consultants identified most of the original compromised hosts, targeted by UNC2970, contained the files %temp%\_SB_SMBUS_SDK.dll
and suspicious drivers, created around the same time on disk.
At the time Mandiant initially identified these files, we were unable to determine how they were dropped or the exact use for these files. It wasn't until later in the investigation, during analysis of a forensic image, where the pieces started falling into place. A consultant noticed multiple keyword references to the file C:\ProgramData\USOShared\Share.DAT
(MD5: def6f91614cb47888f03658b28a1bda6
). Upon initial glance at the Forensic Image, this file was no longer on disk. However, Mandiant was able to recover the original file, and the initial analysis of the sample found that Share.DAT
was a XORed data blob, which was encoded with the XOR key 0x59
.
The decoded payload (MD5: 9176f177bd88686c6beb29d8bb05f20c
), referred to by Mandiant as LIGHTSHIFT, is an in-memory only dropper. The LIGHTSHIFT dropper distributes a payload (MD5: ad452d161782290ad5004b2c9497074f
) that Mandiant refers to as LIGHTSHOW. Once loaded into memory, LIGHTSHIFT invokes the exports Create
then Close
in that order. The response from Close
is written as a hex formatted address to the file C:\Windows\windows.ini
.
Figure 1: LIGHTSHIFT preparing to load LIGHTSHOW
LIGHTSHOW is a utility that makes use of two primary anti-analysis techniques used to hinder both dynamic and static analysis. To deter static analysis, LIGHTSHOW was observed being packed by VM-Protect. In an effort to thwart dynamic analysis, LIGHTSHOW is targeted to a specific host and requires a specific SHA256 hash corresponding to a specific computer name or the sample will not fully execute. Once FLARE completed the analysis of LIGHTSHOW, we were able to understand how the files %temp%\_SB_SMBUS_SDK.dll
and drivers were created on disk.
LIGHTSHOW is a utility that was used by UNC2970 to manipulate kernel data-structures and represents an advancement in DPRK’s capabilities to evade detection. To accomplish this, LIGHTSHOW drops a legitimate version of a driver with known vulnerabilities, with a SHA256 hash of 175eed7a4c6de9c3156c7ae16ae85c554959ec350f1c8aaa6dfe8c7e99de3347
to C:\Windows\System32\Drivers
with one of the following names chosen at random and appended with mgr
:
circlass
dmvsc
hidir
isapnp
umpass
LIGHTSHOW then creates the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\
where is the same as the chosen filename without appended mgr
. It then creates a registry key with the value name ImagePath
, which points to the path of the driver. The sample then loads the driver using NtLoadDriver
. LIGHTSHOW drops and loads a dummy DLL %temp%\_SB_SMBUS_SDK.dll
to register itself to the driver as a legitimate caller.
Using the vulnerable driver, LIGHTSHOW can perform arbitrary read and write operations to kernel memory. LIGHTSHOW uses this read/write primitive to patch different kernel routines, which are related to the type of facilities an Endpoint Detection and Response (EDR) software may use, to enable evasion of said EDR software. After the read and write operations to kernel memory, the sample unloads and deletes %temp%\<random\>_SB_SMBUS_SDK.dll</random\>
.
Examining the chain of execution, we see further obfuscation techniques being employed in LIGHTSHOW. UNC2970 has a concerted effort towards obfuscation and employs multiple methods to do this throughout the entire chain of delivery and execution.
Figure 2: LIGHTSHOW Obfuscation
LIGHTSHOW is another example of tooling that looks to capitalize on the technique of BYOVD. BYOVD is a technique that utilizes the abuse of legitimate and trusted, but vulnerable drivers, to bypass kernel level protections. This technique has been utilized by adversaries ranging from financial actors, such as UNC3944, to espionage actors like UNC2970, which shows its usefulness during intrusion operations. AHNLab recently released a report on activity tracked as Lazarus Group that focused largely on the use of BYOVD. While Mandiant did not observe the hashes included in the AHNLab report, the use of SB_SMBUS_SDK.dll
as well as other similarities, such as the exported functions Create
and Close
, indicate an overlap between the activity detailed in this blog post and those detailed by AHNLab.
Throughout several incidents we responded to in 2022 that involved UNC2970, we observed them utilizing a small set of vulnerable drivers. This includes the Dell DBUtil 2.3 and the ENE Technology device drivers. UNC2970 utilized both of these drivers in an attempt to evade detection. These two drivers, and many more, are found in the Kernel Driver Utility (KDU) toolkit. With this in mind, it is likely that we will continue to see UNC2970 abuse vulnerable drivers from other vendors.
Mandiant has worked to detect and mitigate BYOVD techniques for a number of years and has worked closely with industry allies to report vulnerabilities when discovered. During research being carried out on UNC2970 we discovered a vulnerable driver that the actor had access to, but did not know was vulnerable - essentially making it a 0day in the wild but not being actively exploited. This was verified through our Offensive Task Force who subsequently carried out a notification to the affected organization and reported the vulnerability to MITRE, which was assigned CVE-2022-42455.
Outlook and Implications
Mandiant continues to observe multiple threat actors utilizing BYOVD during intrusion operations. Because this TTP provides adversaries an effective means to bypass and mitigate EDR, we assess that it will continue to be utilized and adapted into actor tooling. The continued targeting of security researchers by UNC2970 also provides an interesting way that the group can potentially continue to expand their toolset to gain an upper hand with BYOVD.
Mitigations
Because attestation signing is a legitimate Microsoft program and the resulting drivers are signed with Microsoft certificates, execution-time detection is made much more difficult as most EDR tools and Anti-Viruses will allow binaries signed with Microsoft certificates to load. The recent blog post released by Mandiant on UNC3944 driver operations details multiple techniques that can be used by organizations to hunt for the abuse of attestation signing. If you haven't already, don't forget to read part one on North Korea's UNC2970. Additionally, Microsoft recently released a report detailing how organizations can harden their environment against potentially vulnerable third-party developed drivers.
Indicators of Compromise
Signatures
LIGHTSHIFT
rule M_Code_LIGHTSHIFT
{
meta:
author = "Mandiant"
description = "Hunting rule for LIGHTSHIFT"
sha256 = "ce501fd5c96223fb17d3fed0da310ea121ad83c463849059418639d211933aa4"
strings:
$p00_0 = {488b7c24??448d40??48037c24??488bcfff15[4]817c24[5]74??488b4b??33d2}
$p00_1 = {498d7c01??8b47??85c075??496345??85c07e??8b0f41b9}
condition:
uint16(0) == 0x5A4D and uint32(uint32(0x3C)) == 0x00004550 and
(
($p00_0 in (750..11000) and $p00_1 in (0..8200))
)
}