StrikeShark Campaign: SharkLoader Unleashes Cobalt Strike on Diplomatic Targets
Just came across the report regarding the 'StrikeShark' campaign identified by Kaspersky. They've spotted a new loader family, SharkLoader, acting as the initial vector to deploy Cobalt Strike Beacons. The targeting is quite specific, hitting a diplomatic org in Indonesia and government bodies in Taiwan.
What stands out is that while the loader is new and undocumented, the payload is the industry-standard Cobalt Strike. This suggests the threat actors are confident in their OpSec or are relying on the obfuscation capabilities of the new loader to bypass static detection before the beacon even fires.
Since we don't have full IOCs yet for SharkLoader, I'm leaning heavily on behavioral detection for the Beacon staging and memory anomalies. We've started hunting for suspicious parent-child processes, specifically looking for signed binaries spawning shellcode. For those without advanced EDR, I recommend checking for processes accessing LSASS without standard signatures using this snippet:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663} |
Where-Object {$_.Message -match 'lsass.exe'} |
Select-Object TimeCreated, Message
Given the geopolitical nature of the targets, are we seeing similar loader patterns in other regions, or is this strictly focused on SE Asia for now? How is everyone handling 'unknown' loaders in their SOC queues—heuristics or waiting for signatures?
Interesting find. We've seen a similar trend with custom loaders wrapping CS Beacons to bypass AMSI. Since SharkLoader is undocumented, signature-based AV is likely blind right now. You might want to focus on the network side; Cobalt Strike often leaves a fingerprint in the JA3 signature even with Malleable C2 profiles. I'd suggest correlating high-entropy user-agents with long-duration connections in your firewall logs.
From a blue team perspective, the 'unknown loader' aspect is the scary part. We've had success using Kusto Query Language (KQL) to hunt for the execution patterns rather than the file hashes. This query helps us catch office documents spawning unusual child processes:
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "mshta.exe")
| summarize Count() by DeviceName, FileName, ProcessCommandLine
It catches a lot of noise, but it's effective for these initial access vectors.
State-sponsored or not, using Cobalt Strike is becoming a double-edged sword. It's powerful for them, but security teams have mountains of telemetry on it now. If SharkLoader is just a dropper, the real fight is stopping the beacon from phoning home. Make sure your egress filtering is tight; blocking non-essential ports usually stops these campaigns in their tracks even if the malware executes.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access