Listen to this Post

Introduction
The cybersecurity landscape has witnessed the emergence of a sophisticated new threat campaign tracked as StrikeShark, which deploys a previously undocumented malware loader named SharkLoader to deliver the notorious Cobalt Strike Beacon payload onto compromised Windows systems. Initially discovered during an investigation targeting a diplomatic organization in Indonesia, this campaign has rapidly expanded to infect entities across government, software development, and various other sectors in countries including Taiwan, Lebanon, Syria, Colombia, North Macedonia, Nepal, and Serbia. What sets StrikeShark apart is its blend of targeted victimology with opportunistic exploitation, employing a multi-stage infection chain that leverages DLL sideloading, advanced API hooking, and stealthy in-memory execution to maintain persistence and evade detection.
Learning Objectives
- Understand the complete infection chain of the StrikeShark campaign and the role of each SharkLoader component.
- Master the technical analysis of the “Perfect DLL Hijacking” technique and the in-memory execution flow of Cobalt Strike Beacon.
- Learn to detect, mitigate, and respond to SharkLoader infections using practical Linux/Windows commands, YARA rules, and EDR configuration strategies.
1. Decoding the SharkLoader Infection Chain
SharkLoader is not a single malicious file but a multi-component loader designed to execute Cobalt Strike Beacon entirely in memory. The infection chain begins with initial access, which the threat actor achieves through two primary vectors: exploitation of public-facing applications and dropper-based distribution.
Step-by-Step Breakdown of the Infection Chain:
- Initial Access: The attacker exploits vulnerabilities in internet-facing systems such as Microsoft Exchange (CVE-2021-26855, CVE-2022-41082), Microsoft SharePoint (CVE-2021-27076), Openfire Server (CVE-2023-32315), GeoServer (CVE-2024-36401), and others. Alternatively, they deploy custom droppers masquerading as legitimate software like Cisco AnyConnect or Google Update.
-
Malware Delivery: The dropper extracts and writes SharkLoader components—typically `SystemSettings.dll` (malicious), `DscCoreR.mui` (encrypted payload), and `SyncRes.dat` (encrypted hooking module)—to directories like `%APPDATA%\xwreg` or
%APPDATA%\xgdf. It then copies the legitimate `SystemSettings.exe` from `C:\Windows\ImmersiveControlPanel` to the same location. -
DLL Sideloading: The dropper creates scheduled tasks to execute the legitimate
SystemSettings.exe, which in turn loads the malicious `SystemSettings.dll` via DLL sideloading. Other variants have been observed usingmsedge.dll,PrintDialog.dll, and `miracastview.dll` as sideloading targets. -
Loader Execution: Once loaded, `SystemSettings.dll` decrypts and reflectively loads `DscCoreR.mui` using a Blowfish cipher with a key extracted from the file. `DscCoreR.mui` then decrypts and loads `SyncRes.dat` using AES-128.
-
Defense Evasion: `SyncRes.dat` installs multiple API hooks using Microsoft Detours and the MinHook library to intercept critical Windows APIs for process creation, memory allocation, and ETW logging. It also registers a Vectored Exception Handler (VEH) to manage access violations.
-
Payload Execution: The malware creates a suspended thread, writes the decrypted Cobalt Strike Beacon shellcode into its memory buffer, and then resumes the thread to execute the Beacon.
-
Post-Exploitation: The attacker uses open-source tools like FScan (network scanner), Searchall (sensitive info search), Pillager (info gathering), and SharpGPOAbuse for Active Directory enumeration and credential theft.
Linux/Windows Commands for Detection:
- Windows (Process and DLL Monitoring):
Get-Process | Where-Object { $_.ProcessName -eq "SystemSettings" } tasklist /m SystemSettings.dll - Windows (Scheduled Task Inspection):
Get-ScheduledTask | Where-Object { $<em>.TaskName -like "OneDrive" -or $</em>.TaskName -like "MicrosoftUpdate" } schtasks /query /fo LIST /v | findstr "SystemSettings" - Windows (File System Artifacts):
dir /s %APPDATA%\xwreg dir /s %APPDATA%\xgdf
2. The “Perfect DLL Hijacking” Technique Explained
To safely execute malicious code from within `DllMain` without causing a deadlock, SharkLoader employs a technique known as “Perfect DLL Hijacking,” originally described by researcher Elliot Killick. The Windows loader holds a synchronization object called the “loader lock” while executing DllMain, preventing other threads from performing DLL operations. SharkLoader manipulates the loader’s internal state to bypass this restriction.
Step-by-Step Technical Walkthrough:
- Resolve Undocumented Structures: The malware resolves the addresses of `LdrpLoaderLock` (the critical section object) and `LdrpWorkInProgress` (an internal state variable) within
ntdll.dll. -
Forcefully Release the Lock: It calls `LeaveCriticalSection` on `LdrpLoaderLock` to release the loader lock prematurely.
-
Mark Initialization as Complete: It decrements `LdrpWorkInProgress` using `InterlockedDecrement64` and signals the loader completion event via
SetEvent. -
Create Malicious Thread: With the loader state manipulated, the malware safely calls `CreateThread` from within `DllMain` to execute its payload without triggering a deadlock.
Code Snippet (Conceptual C++):
// Resolve loader structures (pseudo-code)
PCRITICAL_SECTION LdrpLoaderLock = ResolveSymbol("ntdll.dll", "LdrpLoaderLock");
PLONG LdrpWorkInProgress = ResolveSymbol("ntdll.dll", "LdrpWorkInProgress");
// Forcefully release the loader lock
LeaveCriticalSection(LdrpLoaderLock);
// Mark loader initialization as complete
InterlockedDecrement64(LdrpWorkInProgress);
SetEvent(hLoaderCompletionEvent);
// Now safe to create a thread
CreateThread(NULL, 0, MaliciousThread, NULL, 0, NULL);
Detection Guidance:
- Monitor for unusual calls to `LeaveCriticalSection` and `SetEvent` originating from `DllMain` contexts.
- Use EDR solutions that track loader state manipulation and thread creation patterns.
3. Advanced API Hooking and Evasion Tactics
SharkLoader’s `SyncRes.dat` module installs an extensive array of API hooks to evade detection, spoof parent processes, and intercept critical system calls. These hooks redirect API calls to direct syscall stubs constructed using the jitasm library, bypassing user-mode hooking detection mechanisms.
Key Hooked APIs and Their Purposes:
| Hooked API | Purpose |
|||
| `CreateProcessA` / `CreateProcessW` | Spoofs the parent process to `svchost.exe` to hide malicious child processes. |
| OpenProcessToken, `AdjustTokenPrivileges` | Redirects to direct syscalls to bypass token manipulation monitoring. |
| WriteProcessMemory, `VirtualAllocEx` | Intercepts memory writes and allocations to hide injection activities. |
| EtwEventWrite, EventWriteEx, `EventWrite` | Disables ETW logging to prevent security telemetry. |
| `Sleep` | Temporarily changes memory protection of Beacon regions from RWX to RW during sleep intervals to evade memory scanners. |
Windows Commands for Hook Detection:
- Check for Detours and MinHook Libraries in Memory:
Get-Process | ForEach-Object { Get-Process -Module -Id $<em>.Id | Where-Object { $</em>.ModuleName -match "detours|minhook" } } - Monitor for Syscall Redirection (using Sysmon):
- Enable Sysmon event ID 10 (ProcessAccess) and event ID 8 (CreateRemoteThread) to detect injection attempts.
- Look for unusual `CreateProcess` calls where the parent process is not the expected parent.
4. Persistence Mechanisms and Post-Compromise Activity
The threat actor employs multiple persistence techniques to maintain access to compromised systems, often combining registry modifications with scheduled tasks.
Persistence Techniques Observed:
- Registry Run Key: In one incident, the attacker created a Run key to launch `SystemSettings.exe` upon user logon.
– Command Used:
reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Run" /v "SystemSettings" /t REG_SZ /d "C:\path\to\SystemSettings.exe"
- Scheduled Task: In another case, a task named `\Microsoft\Windows\Edge\Edgeupdate` was configured to run `SystemSettings.exe` daily with SYSTEM privileges.
– Command Used:
schtasks /create /tn "\Microsoft\Windows\Edge\Edgeupdate" /tr "C:\ADriveLogs_Logs\SystemSettings.exe" /sc daily /ru SYSTEM
Post-Compromise Reconnaissance and Credential Theft:
The attacker uses a combination of built-in Windows commands and third-party tools to enumerate the environment and steal credentials.
- System Information Enumeration:
systeminfo ipconfig /all netstat -ano whoami /all
-
Active Directory Enumeration:
net user /domain net group "Domain Admins" /domain nltest /dclist:domain
-
Credential Dumping:
- Targeting LSASS:
rundll32.exe C:\windows\System32\comsvcs.dll, MiniDump PID lsass.dmp full
- Targeting NTDS.dit:
ntdsutil "ac i ntds" "ifm" "create full C:\temp" q q
Detection and Mitigation:
- Monitor registry Run keys and scheduled tasks for suspicious entries.
- Enable PowerShell logging and Script Block Logging to detect malicious AD enumeration commands.
- Implement LSA Protection (RunAsPPL) to prevent LSASS dumping.
- Restrict access to NTDS.dit and monitor for unusual `ntdsutil` or `vssadmin` executions.
- Cobalt Strike Beacon Evasion: The Sleep and Memory Protection Trick
One of the most sophisticated evasion techniques employed by SharkLoader involves hooking the `Sleep` API to manipulate memory protections of the Cobalt Strike Beacon during its sleep intervals. This technique aims to evade memory scanners that flag executable (RWX) memory regions.
Step-by-Step Evasion Flow:
- Hook VirtualAlloc: The MinHook library hooks `VirtualAlloc` to track the addresses and sizes of the first three memory allocations used to store the Beacon shellcode.
-
Hook Sleep: The `Sleep` API is also hooked. When the Beacon calls `Sleep` (e.g., during its callback interval), the hook handler triggers.
-
Change Memory Protection: The handler uses `VirtualProtect` to change the protection of the tracked Beacon memory regions from `PAGE_EXECUTE_READWRITE` (RWX) to `PAGE_READWRITE` (RW).
-
Execute Original Sleep: The original `Sleep` function is called, allowing the Beacon to remain dormant.
-
Restore Protection: After the sleep period ends, the handler restores the memory protection back to RWX.
Detection Guidance:
- Monitor for `VirtualProtect` calls that change memory protection from RWX to RW and back on the same memory regions within short timeframes.
- Use memory scanning tools that can detect Beacon patterns even in RW memory regions.
- Employ YARA rules targeting in-memory Beacon shellcode signatures.
Sample YARA Rule for Cobalt Strike Beacon Detection:
rule CobaltStrike_Beacon_Shellcode {
meta:
description = "Detects Cobalt Strike Beacon shellcode in memory"
author = "Threat Hunter"
strings:
$beacon1 = { 48 8B 05 ?? ?? ?? ?? 48 31 C0 48 8B 40 20 }
$beacon2 = { E8 ?? ?? ?? ?? 48 8B 45 08 48 89 45 F8 }
$beacon3 = "beacon" wide
condition:
uint16(0) == 0x5A4D or ( $beacon1 and $beacon2 ) or $beacon3
}
6. Victimology and Attribution Analysis
The StrikeShark campaign exhibits a hybrid profile, blending targeted espionage-like objectives with opportunistic exploitation. Confirmed victims span government entities (a diplomatic organization in Indonesia, a ministry in Taiwan), software development companies (in Taiwan, Lebanon, Syria), and organizations in Hong Kong, Colombia, North Macedonia, Nepal, and Serbia.
Key Observations:
- Targeted Indicators: The presence of government and software development victims suggests potential cyber-espionage motives, possibly aimed at political intelligence or intellectual property theft.
- Opportunistic Indicators: The use of publicly available exploits (CVE-2021-26855, CVE-2023-32315, etc.) and internet-wide scanning activities indicates a broad, opportunistic approach.
- Attribution Challenges: While the operators use open-source post-compromise tools associated with Chinese-speaking developers (FScan, Searchall, Pillager), researchers have not found sufficient code reuse, infrastructure overlap, or operational similarity to confidently attribute the campaign to any known APT or cybercrime group.
What Undercode Say:
- Key Takeaway 1: StrikeShark is a sophisticated, multi-stage attack that leverages a combination of public exploits, DLL sideloading, and advanced API hooking to deliver Cobalt Strike Beacon entirely in memory, making detection challenging for traditional signature-based AV.
- Key Takeaway 2: The campaign’s dual nature—targeted government entities alongside opportunistic exploitation of vulnerable internet-facing systems—underscores the need for organizations to prioritize patch management, network segmentation, and robust endpoint detection and response (EDR) capabilities.
- Analysis: The technical complexity of SharkLoader, particularly its use of “Perfect DLL Hijacking” and extensive API hooking, indicates a highly skilled threat actor. The reliance on open-source tools and publicly available PoC exploits suggests that this actor is more opportunistic than a dedicated APT group, but the campaign’s global reach and persistence mechanisms warrant continued monitoring. Organizations should focus on detecting the behavioral patterns of the infection chain rather than relying solely on known IOCs, as the malware’s components are heavily encrypted and loaded in memory.
Prediction:
- -1: The StrikeShark campaign is likely to expand further, targeting additional sectors and geographies as the threat actor continues to refine its tooling and exploit new vulnerabilities.
- -1: The use of “Perfect DLL Hijacking” and direct syscall redirection will become more prevalent among malware families, challenging existing EDR solutions that rely on user-mode hooking.
- +1: The cybersecurity community’s response, including the publication of detailed analyses and detection rules, will lead to improved defensive measures and faster identification of SharkLoader infections.
- +1: Organizations that adopt proactive threat hunting, implement robust patch management, and deploy advanced EDR with memory scanning capabilities will be better positioned to detect and mitigate similar attacks.
- -1: The blending of espionage and opportunistic motives makes attribution difficult, potentially allowing the threat actor to operate with impunity and avoid sanctions or countermeasures.
- +1: The open-source nature of many post-compromise tools used in this campaign will enable defenders to study and develop countermeasures more effectively.
- -1: As the threat actor continues to exploit publicly known vulnerabilities, organizations that fail to patch promptly will remain at high risk.
- +1: Collaboration between security vendors and researchers, as seen with the Securelist report, will enhance collective defense and threat intelligence sharing.
- -1: The campaign’s persistence mechanisms, including scheduled tasks and registry Run keys, will continue to be effective against environments with weak monitoring.
- +1: Increased awareness and training on DLL sideloading and API hooking techniques will empower security teams to detect and respond to such threats more effectively.
▶️ Related Video (78% Match):
🎯Let’s Practice For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
IT/Security Reporter URL:
Reported By: Flavioqueiroz Strikeshark – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅


