Late in 2023 and during the first half of 2024, we monitored an attack campaign targeting several of our customers in multiple locations. Though the attack attempts dropped a Cobalt Strike payload, which could have led to any number of further activities, the information we were able to glean from our detections causes us to assess with medium confidence that the activity could be traced to a single threat actor.
There were several noteworthy characteristics of the campaign:
- Initial Far East targeting shifted to Sweden
- Use of the Minhook DLL (Minhook is a minimalistic API hooking library for Windows) to detour Windows API calls
- The clean loader was not part of the sideloading package; instead, it was snatched from the infected system
- Use of a compromised (albeit expired) digital signature for the components
- Final payload was Cobalt Strike
The investigation is in our rearview mirror and the knowledge gained continues to deliver results. In this deep dive, we’ll not only see what we learned, but how the hunt unfolded.
Initial incidents in China/Taiwan
We observed two different sideloading scenarios within a day at the same customer. Later we identified a third one at a different customer. We thought that the incidents might be connected — they both used the same file names for the encrypted payload files, and Cobalt Strike was the payload for both — but we were unable to recover the malicious files in those cases.
Undertaking a retrohunt, we found similar incidents at a handful of our customers from China and Taiwan; the first observed signs of samples and reports were seen December 1, 2023. During investigation of this small cluster we saw three separate sideloading attempts, as we’ll detail below.
MiracastView sideloading
Our Shellcode/C2Interceptor mitigation was triggered, and we observed an outgoing C2 connection to a Cobalt Strike server. The executable used for the loader was a Windows 10 component—the Miracast wireless display service.
We identified the following components:
Clean loader:
Path: appdata\\local\\microsoft\\windowsapps\\miracastview.exe Hash: 0bba1b25f7065118fbfd607a123b6c09d8b97ab5be4ca42b56a994188408f7a9
Malicious loader:
Path: appdata\\local\\microsoft\\windowsapps\\miracastview.dll Hash: 402be231f1c9258bb1510962b15c3ea5410e54f97e3269cd6cd4c355822798d1
Payload files:
appdata\\local\\microsoft\\windowsapps\\syncres.dat appdata\\local\\microsoft\\windowsapps\\dsccorer.mui
We observed C2 connections to the following addresses:
note.dnsrd[.]com/list note.googlestaic[.]com/list prdelb.dubya[.]net/list
These are Cobalt Strike C2 servers. The following snippet contains the relevant part of the C2 configuration:
C2Server:note.googlestaic[.]com,/list,note.dnsrd[.]com,/list,prdelb.dubya[.]net,/list UserAgent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) CHrome/117.0.0.0 Safari/537.36 Edg/117.0.2045.31 HTTP_Post_URI:/note
Unfortunately, we were not able to recover the malicious loader and the payload files. Based on the file name, however, we found the following information on VirusTotal:
db7349a2cf678d5ddbbeb989f0893a146ae536c9169c3940c6caac9cafb3de62: SyncRes.dat
In addition to having the same file name, it also featured the StartEngineData exported function that the malicious loader in the second case was looking for, so we think it is the same component by the same threat actor.
PrintDialog sideloading
We found this after hunting or cases involving the payload file dsccorer.mui.
In this case, our telemetry showed that the sideloading activity originated from a seemingly legitimate installer for the LetsTalkApplication tool (under the proper path C:\Program Files (x86)\Letstalk\LetstalkApplication.exe”). It suggests that the initial distribution of this scenario was via this chat application, which is offered by Taiwan-based Letstalk Technology Limited. No further details were available.
Figure 1: Sideloading abuse of the Letstalk application file. In the chart, the abbreviations inside the circle show that letstalkapplication.exe made 200 outgoing IP connections, made changes to the Registry 135 times, and conducted many additional file operations, reading (200 operations) and writing (154 operations) with abandon
We identified the following components:
Clean loader:
Path: appdata\\local\\microsoft\\windows\\printdialog.exe Hash: 138fla466c26675a16b4e9b8660873b89e5d7fc788ce3810bb357db7cb20aee9
Malicious loader:
Path: appdata\\local\\microsoft\\windows\\printdialog.dll Hash: 3f4cac516b8f2ccb6f10042100369c018d8671972fad360977fe522fd47e06c6
Payload files:
Path: appdata\\local\\microsoft\\windows\\syncres.dat Path: appdata\\local\\microsoft\\windows\\dsccorer.mui
SystemSettings side loading
At the same time as the MiracastView case, we observed another sideloading scenario at the same customer. We identified the following components:
Clean loader:
Path: AppData\Local\Microsoft\Windows\SystemSettings.exe Hash: e768ff1f2f31178fe5930f261acd4b19464acc019fb0aa697d0b48686e59050c
Malicious loader:
Path: appdata\\local\\microsoft\\windows\\systemsettings.dll Hash: b72daf654fc83cd6ccccedbf57a102b48af42f410dbc48f69ec5c8c62545dc18
Payload files:
appdata\\local\\microsoft\\windows\\wuapi.dat appdata\\local\\microsoft\\windows\\mprapi.dat
In this case we did recover the malicious loader, so we know that it decompresses the content of wuapi.dat and mprapi.dat, then calls StartEngineData export from both of them.
It also extracts the Minhook DLL from the resources (SHA256: bddd6adaee8ab13eabaa7c73c97718cee1437db2054ca713ec7cc86e8002a300). The DLL from this resource is the same as that available at https://github[.]com/howmp/pyminhook/raw/master/minhook/MinHook.x64.dll .
Figure 2: A look at the Minhook.x64 DLL hex
It uses Minhook to hook the following API functions:
- GetProcAddress
- FreeLibrary
- LdrUnloadDll
Figure 3: Hooks into the API functions
These hooks are used to load the mprapi.dat payload file on triggering.
The Swedish connection
Using the information extracted from the recovered samples, we set up a VirusTotal hunt for eventual new samples. We expected more samples connected to Asian regions. To our surprise, while a new sample indeed showed up, it was apparently targeting Swedish victims.
The new sample was an installer. The installed sideloading components used the same file names for the clean loader and the malicious loader as in the SystemSettings case, but the payload file names are from the MiracastView/PrintDialog scenarios.
Another commonality is the use of the Minhook DLL; however, in this case it is not loaded by the malicious loader, but by the payload file.
Finding this sample allowed us not only to grab and analyze all of the components, but also to establish an additional link between the three earlier scenarios.
We identified the following components:
Clean loader:
Name: GoogleUpdateStepup.exe Hash: f87cb46cac1fa44c9f1430123fb23e179e3d653a0e4094e0c133fa48a924924f
Malicious loader:
Name: SystemSetting.dll Hash: fd93d7a9f884e0b63106e669a10b8faeaaafda49fac05a66d8581c9e9aa31ad3
Payload files:
Name: DscCoreR.mui Hash: bc56676f0da4b0fba57aaa51d390732e40ef713909e5a70bb30264b724a65921 Name: SyncRes.dat Hash: 47f60c25ab5bb07dc3f65694302991a0796a29021b570a2335acda8196dd2b52
Installer
The installer provided another surprise: It was digitally signed. The signature belongs to Gala Lab Corp., a Korean online game developer company. Even though the signature has expired, it checks as valid if the system clock is set back to before the expiration date in early 2023.
Figure 4: A once-valid certificate from Gala Labs has an unsavory afterlife
In other words, it appears that the threat actors somehow obtained a compromised digital signature for this company. It is not, however, clear why the attackers would use an expired certificate, since it will show as invalid if the system clock is correct.
Figure 5: When the system’s clock is properly set, the expired cert is flagged
The samples were compiled well after that 2023 expiration date. The time stamps indicate that they were in fact compiled on January 11, 2024 – so, after the traces we found of the earlier infection on December 1, 2023.
During the attack process, the components are stored in the resources, as shown:
Figure 6: Tucking away the components
It drops the sideloading components into %AppData%\Roaming\xwreg\:
bc56676f0da4b0fba57aaa51d390732e40ef713909e5a70bb30264b724a65921 *DscCoreR.mui 47f60c25ab5bb07dc3f65694302991a0796a29021b570a2335acda8196dd2b52 *SyncRes.dat fd93d7a9f884e0b63106e669a10b8faeaaafda49fac05a66d8581c9e9aa31ad3 *SystemSettings.dll 880dea11f75380e300bfd5c8054a655eacb2aa0da2c0d89fef3c32666df9a533 *SystemSettings.exe
Sideloading files are stored in two compressed (zlib inflate) resources:
UMRDPRDAT (resource ID: 129 extracted to SyncRes.dat) VAULTSVCD (resource ID: 130 extracted to DscCoreR.mui)
The SystemSetting.dll is not in the resource, but in the .data section (also zlib inflate):
Figure 7: Where it shouldn’t be
Interestingly, the clean loader (SystemSettings.exe) is not part of the installer package. Instead, because it is a standard component, it can be grabbed from its legitimate location (%WINDOWS%\ImmersiveControlPanel) and copied along with the malicious sideloading components.
Figure 8: An unusual use of material already on the system
It is a rather unusual approach. Though LOLbins are gaining in popularity (as we’ve discussed elsewhere), usually threat actors of this sort like to make sure that they deliver all components that are needed for the operation.
The TELEMETRY resource seen in Figure 6 is likely the decoy Google Update Setup installer, as shown below.
7b952d83286157163b655917188b2eaf92a50fe3058922810d47b25eaf6eb9fc: legit GoogleUpdateSetup.exe
Figure 9: The installation attempting to be inconspicuous in Swedish. (The load screen above is fairly self-explanatory; the lower screen says “Unable to connect to the Internet. If you are using a firewall, add GoogleUpdate.exe to the approval list [whitelist]”)
During installation, a connection is made by the Cobalt Strike beacon component to the bostik.cmsnet.se C2 server.
Clean loader
Malicious loader
The malicious loader loads (and somewhat unpacks) DscCoreR.mui and jumps to the entry point 0x1020 in the dump, which is the SetUserProcessPriorityBoost export.
The execution chain of the sideloading components goes as follows:
SystemSettings.exe -> sideloads SystemSettings.dll -> unpacks, loads and calls SetUserProcessPriorityBoost export DscCoreR.mui -> unpacks, loads and calls StartEngineData export SyncRes.dat
DscCoreR.mui
The internal name of this component is StartRun.dll . It exports the SetUserProcessPriorityBoost function.
The memory dump contains two compressed images; when unpacked, one is a Minhook DLL, the other is a Cobalt Strike beacon. It loads SyncRes.dat (see next section), then locates and calls the StartEngineData export. After loading the Minhook DLL it will use it to hook the following API functions:
VirtualAlloc Sleep
Figure 10: Hooking the VirtualAlloc function
The hooked API functions from this point will divert to the malicious code in DscCoreR.mui.
Figure 11: The VirtualAlloc function subverted
(The detour functions don’t appear to be doing anything.) If the hooks are successful, it then unpacks the Cobalt Strike beacon and executes it.
Figure 12: In action
Config data:
C2Server - bostik.cmsnet.se,/claim/data/jquery-3.3.1.min.aspx HttpPostUri - /claim/data/jquery-3.3.2.min.aspx
SyncRes.dat
The internal name of this component is Behavior.dll . It exports the StartEngineData function.
It contains an embedded compressed PE that seems to be missing an MZ header.
Conclusion
Ultimately, we didn’t see continued activity after the cluster of cases we documented in early 2024. There isn’t really a conclusion to be drawn from that, but the geographic hop this attack took, plus its clear remixing of components from other attack attempts, hint at a threat actor exploring new ways to accomplish a goal or goals. Taking a sustained look at an eye-catching cluster of events such as this may not be easy in the day-to-day scramble to devise and deliver protections, but it’s always useful to look back on smaller moments such as these to see what might be learned from them.
