The media in this post is not displayed to visitors. To view it, please log in.
Introduction
During our research of activity affecting a diplomatic organization in Indonesia, we uncovered a previously undocumented malware family that we have named SharkLoader. What initially appeared to be an isolated case quickly expanded into a broader campaign as we identified additional SharkLoader infections across multiple countries and sectors.
Our investigation revealed that SharkLoader serves as a loader designed to deploy Cobalt Strike Beacon on compromised systems. We observed the threat actor deploying SharkLoader through exploitation of internet-facing applications, including Microsoft Exchange, Microsoft SharePoint, and Openfire Server, as well as through malware-based delivery mechanisms.
Beyond the diplomatic entity in Indonesia, we identified related activity targeting government organizations in Taiwan, software development companies across multiple countries, and entities in other sectors located in Hong Kong, Lebanon, Syria, Colombia, North Macedonia, Nepal, Serbia, and more. The observed victimology suggests a campaign with broad geographic reach and a diverse target set rather than a narrow focus on a specific industry or region.
For now, we are tracking this activity as StrikeShark. Although the operators utilize several open-source post-compromise tools associated with Chinese-speaking developers, we have not identified direct code reuse, infrastructure overlap, or operational similarity to confidently attribute the activity to any known APT or cybercrime group. As a result, attribution remains preliminary and the campaign’s ultimate objectives are still under research.
Initial infection
Our analysis of SharkLoader intrusions indicates that the threat actor employs multiple methods to gain initial access to victim environments. During our investigation, we observed two primary infection vectors: the exploitation of vulnerabilities in internet-facing applications and the deployment of custom dropper samples, some of which were disguised as legitimate software.
Exploitation of public-facing applications
In the incident affecting an Indonesian diplomatic entity, the threat actor exploited Microsoft Exchange vulnerabilities, including CVE-2021-26855 (ProxyLogon), to gain access to the target environment. Similar activity was observed in Taiwan, where software development organizations were compromised through exploitation of Openfire (CVE-2023-32315). In a separate incident affecting a Colombian organization, the threat actor exploited a GeoServer instance vulnerable to CVE-2024-36401.
Beyond these incidents, we identified additional exploitation activity targeting vulnerabilities in multiple internet-facing enterprise applications and network appliances including those listed below:
Remote Code Execution (RCE)
- Apache Shiro: CVE-2016-4437
- Hikvision Products: CVE-2021-36260
- Microsoft SharePoint: CVE-2021-27076
- Zimbra Collaboration Suite: CVE-2022-27925
- Microsoft Exchange Server: CVE-2022-41082
- F5 BIG-IP system: CVE-2023-46747
- Fortinet FortiOS: CVE-2024-21762
- React Server Components: CVE-2025-55182
Authentication Bypass
- Fortinet FortiOS: CVE-2022-40684
- Cisco IOS XE Web UI: CVE-2023-20198
As of the time of writing this article, we haven’t obtained the exploits the attackers used. However, based on the vulnerabilities observed across multiple attacks, we assess with medium confidence that the threat actor primarily relies on publicly available proof-of-concept (PoC) exploits to gain initial access. All the vulnerabilities identified during our investigation have publicly available exploit code, including PoCs hosted on GitHub and other open-source platforms, suggesting the actor leverages existing offensive resources rather than develops custom exploit capabilities. The victim profile also indicates that the activity is largely opportunistic, affecting organizations across various industries, regions, and technology environments without a clear focus on a specific target set. Also, one of the IP addresses associated with the C2 domain was also observed conducting internet-wide scanning activity, potentially aimed at identifying and exploiting vulnerable internet-facing systems at scale.
Following exploitation, the attacker established persistence on compromised servers through the deployment of webshells. Although we were unable to recover the webshell files, a series of commands whose execution we observed in our telemetry along with the detection records of webshells strongly indicate their use for post-exploitation activities.
One of the earliest observed actions involved copying the legitimate Windows application SystemSettings.exe to a new location before executing it.
cd C:\Windows\ImmersiveControlPanel\
copy SystemSettings.exe C:\ProgramData\
cd C:\ProgramData\
SystemSettings.exe
This application was later abused as part of a DLL sideloading chain used to launch SharkLoader, which in this scenario was hidden in the malicious SystemSettings.dll library. We suspect that this DLL along with malicious encrypted files, which we’ll describe further, was uploaded through the webshell to the same directory as SystemSettings.exe.
In another case involving the exploitation of CVE-2021-27076, the threat actor launched SystemSettings.exe triggering the subsequent SharkLoader sideloading chain from different directories on the system, which suggests renewed operational activity in the victim environment. In some of the cases, they used security product vendor names as the directory names, allegedly to appear legitimate.
cd C:\ProgramData\KasperskyLab\
dir
.\SystemSettings.exe
cd %APPDATA%
dir
cd kasperskylab
dir
.\SystemSettings.exe
Dropper-based distribution
In several observed cases, the threat actor distributed SharkLoader through custom dropper executables masquerading as legitimate software installers or applications such as Google Update and Cisco AnyConnect. However, the exact delivery mechanism used to distribute these droppers remains unknown.
The observed dropper filenames include:
GoogleUpdateStepup.exeAnyConnect-win-4.10.04071-predeploy-k9exeAutoUpdate.exe319-pfd-8001-reva_traitement biologique_master.zip
In one of the samples we analyzed, the threat actor used a legitimate Cisco AnyConnect VPN installer as a lure. The custom dropper extracted zlib-compressed data embedded within its resource section, decompressed it into an MSI package, and wrote the file to %APPDATA%\reports\AnyConnect-win-4.msi. The MSI package was a legitimate Cisco AnyConnect VPN installer, which was subsequently executed via the ShellExecuteW API, making the user believe the custom dropper was a legitimate application.
While the Cisco AnyConnect installer was decompressed and executed, SharkLoader components were silently dropped into directories in %APPDATA% different from %APPDATA%\reports\ in the background, executing the malware loader once the installation process completes.
Malicious Cisco Secure Client installer
In addition to installer-themed lures, several SharkLoader droppers use decoy PDF documents to persuade victims to open the malicious file. However, not all samples employ this technique, as some droppers function solely as a delivery mechanism for SharkLoader without presenting any lure content.
Among the samples analyzed, most droppers write the decoy PDF to a subdirectory named aswerf within the %TEMP% directory, while others save the document directly to %TEMP%.
Analysing the sample shows the PDF files are stored within the dropper’s resource section under the resource name TELEMETRY and are compressed with zlib. Upon execution, the dropper extracts and decompresses the embedded PDF, writes it to disk using the same filename as the dropper executable but with a PDF extension, and launches it via cmd.exe /c to display the decoy document to the victim.
The following are examples of PDF documents extracted and displayed by the droppers during the deployment of SharkLoader.
Lure document 1. The document appears to be related to a biological treatment process and was produced by an engineering consultant
Lure Document 2. Translated title: Liquid Rocket Engine Design Program
In one dropper sample, discovered on a machine located in Lebanon (MD5: 1F65544978B8EA0E745E573B8EE9684B), the dropper extracts and decompresses SystemSettings.dll from zlib-compressed data embedded within the binary and writes it to %APPDATA%\xwreg. It also extracts and decompresses DscCoreR.mui and SyncRest.dat from resources named VAULTSVCD and UMRDPRDAT, respectively, and writes them to the same directory.
The dropper extracts SystemSettings.dll from the binary and retrieves encrypted components from the resource section
The dropper then copies the legitimate SystemSettings.exe application from C:\Windows\ImmersiveControlPanel to the target location to facilitate DLL sideloading. Across other SharkLoader dropper samples analyzed, the malware components were observed being written to either %APPDATA%\xwreg or %APPDATA%\xgdf.
SharkLoader installation
SharkLoader is composed of multiple components that work together to load and execute the final implant, a Cobalt Strike Beacon.
| Filename | Description |
| SystemSettings.exe | Legitimate Windows application abused for DLL side-loading of the
malicious DLL SystemSettings.dll. |
| SystemSettings.dll | Main malicious SharkLoader DLL responsible for the core loader functionality. |
| DscCoreR.mui | An encrypted module that contains an embedded Cobalt Strike Beacon and the MinHook library. This module loads SyncRes.dat, installs a couple of API hooks, and executes the Beacon directly in memory. |
| SyncRes.dat | An encrypted DLL that is used to install multiple API hooks. |
While the majority of SharkLoader samples analyzed rely on the sideloading of SystemSettings.dll, other variants leverage alternative DLL side-loading targets, including msedge.dll, PrintDialog.dll, and miracastview.dll, each of them leveraging a corresponding legitimate application.
Across the different variants examined, the encrypted modules were also observed using a variety of filenames, including:
GameInputInboxs32.mui
diagerr.xml
NtfsLog.etl
Ignored.Dat
VistaCompat.nls
The SharkLoader execution flow is as follows:
SharkLoader infection chain observed in the StrikeShark campaign
In the dropper-based infections, after deploying all required SharkLoader components, the dropper creates two scheduled tasks through the Windows Task Scheduler COM interfaces. Task names:
- OneDrive Standalone Update Task-S-1-5-21-4165425321-4153752593-2322023643-1000
- MicrosoftUpdateTaskUserS-1-5-32-2456537112-101246289-228944324-1000
Both tasks are configured to execute the copied SystemSettings.exe from the malware’s working directory (for example, %APPDATA%\xwreg or %APPDATA%\xgdf), triggering the side-loading of the malicious SharkLoader DLL.
The first scheduled task uses a time-based trigger that executes every five minutes, providing long-term persistence.
The second task is configured to execute every second, likely to ensure immediate execution of SharkLoader following deployment.
After a delay of approximately 1.5 seconds, the dropper removes the second scheduled task by using the Task Scheduler COM interfaces, leaving the first task in place to maintain persistence on the system.
SharkLoader DLL – Main implant
For the detailed analysis of the infection chain, we’ll focus on the SharkLoader components deployed by a malicious dropper named 一种异常状况的截图（包括操作系统和输入法版本）.pdf.exe (MD5: 24FCEBDEECBA65004FDB0923763D74FD), which was identified in a campaign targeting a government entity in Taiwan.
| Filename | MD5 |
| SystemSettings.exe | D98F568496512E4F98670C61C97CB07A |
| SystemSettings.dll | AA3086BE652C8B20B0B29B2730D57119 |
| DscCoreR.mui | A514D1BB62D7916475946FE7C07AC0AA |
| SyncRest.dat | 9CBD560F820C95D7C38342CD558CB5C6 |
“PerfectDLL Hijacking” technique
Once the malicious DLL is loaded, SharkLoader implements a technique commonly referred to as “Perfect DLL Hijacking” and originally described by a security researcher named Elliot Killick on his blog. The purpose of this technique is to bypass the Windows loader lock and safely create a malicious thread via the CreateThread API without risking a deadlock.
According to Microsoft’s Dynamic-Link Library Best Practices, the Windows loader holds a synchronization object known as the “loader lock” while executing the DllMain function. This mechanism ensures that only one thread can perform DLL loading and initialization operations within a process at any given time. As a result, invoking APIs such as CreateThread or LoadLibrary from within DllMain can lead to deadlocks because the loader lock remains held throughout the execution of the function.
To avoid this issue, SharkLoader manipulates the process’s internal loader state to release the loader lock before invoking CreateThread from the DllMain execution path. By doing so, it attempts to execute its malicious code without triggering the loader-related deadlocks that can occur when threads are created while the loader lock remains held.
Implementation of the Perfect DLL Hijacking technique to bypass the Windows Loader Lock
Based on the code, SharkLoader first resolves the addresses of several undocumented loader structures within ntdll.dll, including:
LdrpLoaderLock: the critical section object used by the Windows loader to synchronize module loading and initialization operationsLdrpWorkInProgress: an internal loader state variable that tracks whether module initialization is currently in progress
After locating these structures, SharkLoader forcefully releases the loader lock by invoking LeaveCriticalSection on LdrpLoaderLock. It then decrements the value of LdrpWorkInProgress with InterlockedDecrement64, effectively marking the initialization process as complete.
Finally, the malware signals the loader completion event via SetEvent before creating a new thread to execute its malicious functionality. As a result, these actions manipulate the loader’s internal state and cause Windows to treat the DLL initialization process as having completed successfully. This allows SharkLoader to continue execution after forcefully releasing the loader lock, despite still operating from within the DllMain execution path.
Decryption and loading of >DscCoreR.mui
As shown in the previous section, the loader creates a new thread after escaping the Windows loader lock. This thread subsequently spawns a second thread responsible for decrypting and reflectively loading the encrypted file, DscCoreR.mui.
The routine first reads the encrypted file into memory and extracts the first 16 bytes to use as the Blowfish decryption key. It then initializes the Blowfish cipher by using custom P-array and S-box constants embedded in the loader and decrypts the file in ECB mode with the extracted key. Once decryption is complete, the resulting PE file is reflectively loaded into memory and executed without being written to disk.
Structure of the encrypted DscCoreR.mui file containing the 16-byte Blowfish key bytes followed by the encrypted PE bytes
The decrypted DscCoreR.mui file is a packed PE file with its MZ header removed, likely as an anti-analysis measure. After decryption, SharkLoader processes the PE image by parsing its headers, allocating memory for the image, mapping its sections, applying relocations, resolving imported functions, and setting the appropriate memory protections. Once the in-memory PE loading process is complete, the main loader, SystemSettings.dll, transfers execution to the entry point of the mapped image, which contains the packer stub.
The stub then unpacks the protected code, invokes the DLL’s DllMain function, and returns execution to SystemSettings.dll. Finally, SystemSettings.dll calls the exported function SetUserProcessPriorityBoost from the mapped DLL, triggering execution of the fully unpacked next-stage DLL.
DscCoreR.mui and SyncRes.dat DLLs
Within the decrypted and unpacked DscCoreR.mui code, the malware proceeds to load and decrypt a second encrypted file, SyncRes.dat, before reflectively loading the resulting DLL into memory.
The mapped DLL installs multiple API hooks by using Microsoft Detours, which will be discussed in the next section.
After mapping and loading SyncRes.dat for API hooks, the DscCoreR.mui performs installation of the Vectored Exception Handler (VEH) and then creates a thread in a suspended state that is later used to execute the Cobalt Strike Beacon shellcode. Additionally, to facilitate additional API hooks, it decompresses and loads the MinHook library and uses it to install hooks on the VirtualAlloc and Sleep APIs.
The DscCoreR.mui then decompresses the Cobalt Strike Beacon shellcode into the memory region associated with the suspended thread and then the suspended thread is resumed, resulting in execution of the beacon.
Decryption and loading of SyncRes.dat
To decrypt SyncRes.dat, the malware extracts a 16-byte AES-128 key and a 16-byte initialization vector (IV) directly from the file itself. The first 16 bytes of the file contain the AES key, while the subsequent 16 bytes contain the IV. The remaining file content consists of AES-encrypted data, which is decrypted using the extracted key and IV. Once decrypted, the resulting data reveals a PE image with its MZ header removed, similar to DscCoreR.mui.
Structure of the encrypted SyncRes.dat file showing the AES key, IV, and encrypted PE bytes
Similar to the decrypted DscCoreR.mui module, the decrypted SyncRes.dat file is also protected by an unknown custom packer. After decryption, the loader reflectively loads the PE image before transferring execution to the module’s entry point.
The entry point contains a packer stub responsible for unpacking the protected code in memory. Once the unpacking routine is complete, the malware invokes a specific exported function named StartEngineData, which serves as the primary execution routine of the third-stage DLL.
Before continuing with the DscCoreR.mui analysis, we will first discuss SyncRes.dat.
SyncRes.dat decrypted DLL: Multiple API hooks
The decrypted and unpacked SyncRes.dat DLL is primarily responsible for installing multiple Windows API hooks by using the Microsoft Detours library. After attaching all detour hooks, it calls DetourTransactionCommitEx to apply them in one commit.
The following table lists the hooked Windows APIs and their corresponding hook handler functions.
| Hooked Windows APIs | Detour function description |
| CreateProcessA | - Saves all original
CreateProcessA parameters for use in the parent process (PPID) spoofing routine. - Creates a new thread that executes the process creation routine responsible for PPID spoofing.
- Falls back to the original
CreateProcessA if the thread creation fails.
- Identifies an svchost.exe process that has the same security context as the current SharkLoader process.
- Builds an extended startup attribute list to set the selected
svchost.exe as the spoofed parent. - Calls the original
CreateProcessA with the modified parent attribute.
As a result, any new process created by the current process (primarily from the Cobalt Strike beacon) is spawned under svchost.exe instead of the current module process. |
| CreateProcessW | - Saves all original
CreateProcessW parameters for use in the PPID spoofing routine, which is executed through an APC-based mechanism rather than a dedicated thread compared to the CreateProcessA API hook. - Schedules a delayed process creation (10 microseconds) through APC execution using
CreateWaitableTimerW and SleepEx.
- The timer callback performs the svchost.exe PPID spoofing logic, similar to the CreateProcessA spoofing routine.
As a result, new processes created via CreateProcessW by the current process (primarily from the Cobalt Strike beacon) are launched under svchost.exe through an APC-based execution mechanism |
| OpenProcessToken | - Once hooked, the malware initializes jitasm to construct a direct syscall stub for
NtOpenProcessToken at runtime. - Invokes
NtOpenProcessToken through the constructed direct syscall stub, redirecting the original API (OpenProcessToken) call flow.
|
| AdjustTokenPrivileges | - Redirects the API call to a direct
NtAdjustPrivilegesToken syscall stub constructed by jitasm.
|
| OpenProcess | - Redirects the API call to a direct
NtOpenProcess syscall stub constructed by jitasm.
|
| WriteProcessMemory | - Redirects the API call to a direct
NtWriteVirtualMemory syscall stub constructed by jitasm.
|
| NtCreateUserProcess | - Redirects the API call to a direct
NtCreateUserProcess syscall stub constructed by jitasm.
|
| LoadLibraryA | - Redirects the API call to a function that resolves LdrLoadDll API using a ROR13-based API hashing algorithm.
- Uses the original parameters to invoke LdrLoadDll directly.
- If LdrLoadDll resolution or invocation fails, uses
CreateTimerQueue and CreateTimerQueueTimer to schedule a 10-millisecond delayed execution of the original LoadLibraryA, with CreateEventW used for synchronization.
|
| GetModuleHandleA | - Redirects the API call to a custom function that resolves the module base address through the following steps:
- Enumerates loaded modules within the current process using
CreateToolhelp32Snapshot, Module32FirstW, and Module32NextW. - Compares each enumerated module name with the module name provided in the API parameter.
- Returns the module base address if a match is found.
- Falls back to the original
GetModuleHandleA API if the custom resolution routine fails.
|
| GetModuleHandleW | - Similar approach to the
GetModuleHandleA API hooks above.
|
| GetProcAddress | - The original
GetProcAddress parameters are passed to the hook handler. - The hook handler computes a Murmur32 hash of the requested function name.
- The hook handler parses the module’s PE structure and locates the export table.
- Each exported function name is hashed using the same Murmur32 algorithm and compared against the previously generated hash.
- If a hash match is found, the corresponding function address is returned. If no match is found, the call falls back to the original
GetProcAddress.
|
| LoadLibraryExA | - The hook handler redirects the API call to its original address. In short, the hooked
LoadLibraryExA calls the original LoadLibraryExA function.
|
| VirtualAllocEx | - Redirects the API call to a direct
NtAllocateVirtualMemory syscall stub constructed by jitasm.
|
| VirtualProtectEx | - Redirects the API call to a direct
NtProtectVirtualMemory syscall stub constructed by jitasm.
|
| VirtualProtect | - Redirects the API call to a direct
NtProtectVirtualMemory syscall stub constructed by jitasm.
|
| ResumeThread | - Redirects the API call to a direct
NtResumeThread syscall stub constructed by jitasm.
|
| GetThreadContext | - Redirects the API call to a direct
NtGetContextThread syscall stub constructed by jitasm.
|
| OpenThread | - Redirects the API call to a direct
NtOpenThread syscall stub constructed by jitasm.
|
| NtCreateThread | - Redirects the API call to a direct
NtCreateThread syscall stub constructed by jitasm.
|
| NtCreateThreadEx | - Redirects the API call to a direct
NtCreateThreadEx syscall stub constructed by jitasm.
|
| NtQueueApcThread | - Redirects the API call to a direct
NtQueueApcThread syscall stub constructed by jitasm.
|
| NtQueueApcThreadEx | - Redirects the API call to a direct
NtQueueApcThreadEx syscall stub constructed by jitasm.
|
| ExpandEnvironmentStringsA | - The detour redirects the API to a custom function that creates a new thread. That thread executes a routine that calls the
ExpandEnvironmentStringsA API.
|
| CreateFileMappingA | - The detour redirects the API call to a custom function that creates a new thread. Within the thread, it initializes thread-pool and timer objects, sets a threadpool timer for 10 ms and a waitable timer for 0.1 ms, then calls
CreateFileMappingNumaA. - If thread creation fails,
CreateFileMappingNumaA is called directly without creating a thread.
|
| MapViewOfFile | - The detour redirects the API call to a custom function that creates a new thread. The thread runs a similar thread-pool and timer setup to the previous function, resolves
MapViewOfFileEx via GetProcAddress, calls it with zeroed arguments, and stores the return value.
|
| UnmapViewOfFile | - The detour redirects the API to a function that tries to run the unmap (same API) in a new thread.
- The thread creates an event and timer queue, schedules a callback after 10 ms to call
UnmapViewOfFile and signal the event, then waits and cleans up. - If thread creation fails, it calls
UnmapViewOfFile directly.
|
| NtMapViewOfSectionEx | - Redirects the API call to a direct
NtMapViewOfSectionEx syscall stub constructed by jitasm.
|
| NtCreateNamedPipeFile | - Redirects the API call to a direct
NtCreateNamedPipeFile syscall stub constructed by jitasm.
|
| NtReadFile | - Redirects the API call to a direct
NtReadFile syscall stub constructed by jitasm.
|
| NtWriteFile | - Redirects the API call to a direct
NtWriteFile syscall stub constructed by jitasm.
|
| EtwEventWrite | - The detour redirects
EtwEventWrite to a stub that always returns 1, which prevents ETW logging.
|
| EventWriteEx | - The detour redirects
EventWriteEx to a function that always returns 0, which prevents ETW logging.
|
| EventWrite | - The detour redirects
EventWrite to a function that always returns 0, which prevents ETW logging.
|
Upon completing the installation of API hooks via the decrypted SyncRes.dat, the DscCoreR.mui DLL proceeds with the remaining functions, which are discussed below.
VEH registration and access violation handling
Following the installation of the API hooks, the malware registers a Vectored Exception Handler (VEH) to monitor exceptions generated during runtime. The handler specifically checks for access violation exceptions (0xC0000005). When such an exception occurs, it retrieves the faulting memory address from the exception record and calls VirtualProtect to restore read, write, and execute (RWX) permissions to the corresponding memory page before resuming execution.
During our analysis, no access violations were observed. It is possible that this mechanism is intended to handle access violations that may occur under specific runtime conditions.
Thread creation for Cobalt Strike Beacon execution
The malware creates a new thread in a suspended state that is intended to execute the Cobalt Strike Beacon shellcode. The thread entry point is configured to point to a memory buffer that will later contain the beacon shellcode.
At this stage, the buffer does not yet contain the actual Cobalt Strike Beacon shellcode. Instead, the thread is created in a suspended state so that the malware can prepare and inject the shellcode into the buffer before execution. Once the beacon payload has been written into the buffer, the malware resumes the suspended thread using the ResumeThread API, which triggers the execution of the Cobalt Strike beacon.
MinHook DLL, API hooking, and Cobalt Strike beacon
After creating the suspended thread for beacon execution, the malware decompresses a zlib-compressed MinHook PE file embedded within DscCoreR.mui. The MinHook library is used to install API hooks for the VirtualAlloc and Sleep functions. Once the MinHook DLL is decompressed and loaded into memory, the malware resolves the exported functions MH_Initialize and MH_CreateHook, which are then used to install hooks on the VirtualAlloc and Sleep APIs.
After the hooks are installed, the malware invokes a function that decompresses a zlib-compressed Cobalt Strike Beacon shellcode embedded within the malware. The function first decompresses the shellcode into a temporary buffer and then allocates executable memory using VirtualAlloc with RWX permissions. The decompressed beacon is subsequently copied into the allocated memory region.
Because the VirtualAlloc API has already been hooked at this stage, the hook handler captures the address and size of the allocated memory used to store the beacon shellcode. The hook records the addresses and sizes of the first three successful memory allocations and stores these values in global variables to track specific memory regions allocated during execution. These tracked regions are associated with memory buffers used by the Cobalt Strike Beacon during runtime.
The second hook, on the Sleep API, is used when Cobalt Strike Beacon calls Sleep, such as during beacon sleep intervals. It temporarily modifies the memory protection of the tracked allocation regions by using VirtualProtect, changing their protection to PAGE_READWRITE (RW) before invoking the original Sleep function. After the sleep period ends, the malware restores the memory protection of those regions to PAGE_EXECUTE_READWRITE (RWX). This behavior suggests that the malware developer implemented this mechanism to evade memory scanning techniques that identify executable (RWX) code regions in memory.
Finally, after the API hooks are installed and the Cobalt Strike Beacon shellcode has been written to the thread buffer, the malware calls the ResumeThread API to resume the suspended thread and begin execution of the beacon.
Persistence mechanism
While the analyzed SharkLoader implant does not contain a built-in persistence mechanism especially when it comes to cases when it is dropped after the exploitation of a public-facing application, our investigations revealed that the threat actor employs several techniques to maintain access to compromised systems.
Registry Run key: In the incident that affected an organization in Hong Kong, the attacker manually created a registry Run key to launch SystemSettings.exe upon user logon. The following command was used:
reg add HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Run /v "MFUpdate" /t REG_SZ /d "$appdata\Identities\SystemSettings.exe" /f
This technique allows the malware to automatically execute whenever the user logs in, ensuring persistent access.
Scheduled task: In the separate compromise that affected a diplomatic government entity in Indonesia, the attacker established persistence through a scheduled task configured to execute SharkLoader daily. The task, named "\Microsoft\Windows\Edge\Edgeupdate", was configured to run C:\ADriveLogs_Logs\SystemSettings.exe by using the following command:
Schtasks /create /s /u "" /p "" /ru "SYSTEM" /tn "\Microsoft\Windows\Edge\Edgeupdate" /sc DAILY /tr "C:\ADriveLogs_Logs\SystemSettings.exe /F"
Running the task with SYSTEM privileges ensures that SharkLoader executes even if no user is logged in.
Post-compromise activity
Following initial compromise and persistence, the attacker engaged in extensive reconnaissance and credential theft activities.
System information enumeration: The attacker initially gathered basic system information by using the following commands:
systeminfo
ipconfig /all
tasklist /svc
Post-exploitation tools: Our analysis revealed the use of several third-party post-exploitation tools, most of which are open-source and developed by Chinese-speaking developers. These tools included:
| Tool name | Description |
| FScan | Network scanner tool with vulnerability
exploitation modules |
| Searchall | Sensitive information search tool |
| Pillager | Information gathering tool |
We also detected the use of SharpGPOAbuse by the threat actor, a tool designed to modify Group Policy Objects within Active Directory environments.
Active Directory enumeration: In the compromise affecting a diplomatic government entity in Indonesia, the attacker used both Cobalt Strike and a webshell to enumerate the internal Active Directory environment. They executed a series of commands to gather information about the network, users, and groups:
- Network information:
ping -n
netstat -ano
arp -a
net share - User and group information:
query user
nslookup
quser
net group /domain - Specific group membership:
powershell "Get-ADGroupMember -Identity "" -Recursive | Select-Object Name, ObjectClass"
dsquery group -name "" | dsget group -members -expand | dsget user -samid -display -email"
powershell "Get-ADGroupMember -Identity "" -Recursive | Where-Object { $_.ObjectClass -eq "computer" } | Select-Object Name, SamAccountName"
powershell -exec bypass -c "Get-ADUser -Filter * -Prop * | select sAMAccountName
net group "Domain Controllers" /domain
net group "Enterprise Admins" /domain
net group "Organization Management" /domain
net group "domain admins" /domain - Process enumeration:
tasklist /SVC | findstr $selfname.exe - Directory listing:
dir \\c$
dir \\c$\inetpub
dir \\c$\inetpub\custerr
dir \\c$\inetpub\wwwroot\
Credential dumping: The attacker also attempted to dump credentials from the compromised machine by targeting both the LSASS process and the NTDS database file. The following commands were observed:
ntdsutil "ac i ntds" "ifm" "create full $temp" q q
Procdump64.exe -accepteula -ma lsass.exe $temp\lsass.dmp
Dumping the LSASS process allows the attacker to extract in-memory credentials, while accessing the NTDS database enables retrieval of Active Directory account password hashes. This combination of techniques allows the attacker to obtain privileged credentials for lateral movement, privilege escalation, and deeper compromise.
Victimology
The victimology observed in this campaign shows a combination of strategic and opportunistic characteristics. Confirmed victims include government-related entities, such as the ministry in Taiwan and the diplomatic organization in Indonesia, as well as software development companies in Taiwan, Lebanon, and Syria. Additional affected organizations were identified in Hong Kong, Colombia, Macedonia, Nepal, and Serbia.
Targeting of government and software development organizations may indicate a cyber-espionage objective, although our confidence remains low due to the limited post-compromise activity observed, which primarily consisted of credential access, system reconnaissance, and lateral movement. The compromise of government and software development organizations could indicate an interest in gathering political intelligence or intellectual property.
At the same time, the use of SharkLoader and Cobalt Strike, alongside the exploitation of public-facing applications and malicious installers and droppers, suggests the attacker may also be opportunistically targeting vulnerable systems. The absence of clear evidence of data exfiltration thus far does not exclude this possibility, as Cobalt Strike’s file operation and data exfiltration modules could be employed at a later stage.
Although the full scope of the campaign is not yet known, the combination of targeted and opportunistic activity suggests it should continue to be closely monitored.
Attribution
Our investigation reveals no code or infrastructure overlap linking SharkLoader to any existing threat actor at this time. The TTPs employed during the operation also do not align with those of known actors.
However, analysis of the post-exploitation open-source tools used during the campaign revealed that several reconnaissance tools, including FScan, Searchall, and Pillager, were developed by individuals identified as Chinese speaking developers on GitHub.
We assess StrikeShark to be a Chinese-speaking threat actor with low confidence. This assessment is based on limited indicators and should be considered preliminary. Further investigation is required to characterize this cluster more fully, and the possibility remains that other actors may also be utilizing these tools.
Conclusion
Our investigation discovered a previously undocumented intrusion cluster that we are tracking as StrikeShark. The StrikeShark campaign represents a sophisticated malware threat to entities worldwide. The use of SharkLoader to deploy Cobalt Strike, coupled with API hook installation to evade detection, demonstrates a significant level of technical expertise. The campaign’s broad targeting across sectors and geographic regions suggests a potential focus on espionage or information gathering. While the precise objectives remain under investigation, the combination of targeting government entities and software developers warrants heightened vigilance.
Given that our visibility is limited to incidents observed through Kaspersky telemetry, we suspect the actual number of compromises may be significantly higher and extend beyond these victims as the threat actor actively used several exploitations of public facing application.
Indicators of compromise
Additional information about this activity, including indicators of compromise, is available to customers of the Kaspersky Intelligence Reporting Service. If you are interested, please contact intelreports@kaspersky.com.
C559CC68986933200FD5D9E4388E2F58 Installer
B3352B42432DEDC4A519F011DC8B5D5A Dropper
24FCEBDEECBA65004FDB0923763D74FD Dropper
9C872A0D5D5A38950E8B9AC9B488BE3F SharkLoader DLL
AA3086BE652C8B20B0B29B2730D57119 SharkLoader DLL
A514D1BB62D7916475946FE7C07AC0AA Encrypted file
9CBD560F820C95D7C38342CD558CB5C6 Encrypted file
connect-microsoft[.]com
ms-record[.]com
ms-record[.]top
ms-tray[.]top
securelist.com/strikeshark-cam…
Although paperbacks are a much-loved aspect of the literary world, they are not really intended to last the decades the way that hardcover books are. Beyond the typical ravaged covers, paperbacks also tend to suffer from a warped spine, where the formally flat spine gets a definite inwards curve due to the ravages of moisture, temperature, failing glue and the passing of time in general. If this bothers you, then [Book Care Studio] 
The connectivity back to the Internet is effectively the same as any inflight WiFi system. The difference is that passengers are served with cellular connectivity instead of WiFi. Credit: AeroMobile
Note the quality difference between the 16-color CD+G and the 256-color CD+EG images.
An MP-05 running on the Paris Metro. Credit: 
An MP 89 CC consist running on line 6 of the Paris Metro at Corvisart station. These electric multiple units entered service in 1997. Credit: author
Note the guidewheels which run against the vertical guideways built into the track. Credit: author
A bogie from an MP 89 of the Paris Metro, showing the main wheels as well as the guide wheels. Credit: 
Various rubber-tired metro systems have sprung up around the world. The basic concept is usually the same, though exact implementations differ. This system deployed in Sapporo, Japan, relies on a central rail guidance system, and was built by Kawasaki Heavy Industries. Credit: 
Post-annealing SEM scan, showing clear voids. (Credit: I built a thing, Youtube)
The first challenge was to see whether it could be booted at all, with just four metal pads visible on the side of the case. These turn out to correspond to USB pins, but the tablet only briefly tries to turn on with a charger connected. This means that a teardown is required, which ended up involving a hacksaw due to the sealed case.
When one says that they’d like a ‘Linux shell on Windows’, it can be hard to pin down exactly what this means. 
With MSYS2 you can use the same 
