Kaspersky’s Securelist team published new research on StrikeShark, a campaign using a previously undocumented malware family called SharkLoader to deploy Cobalt Strike Beacon. The key lesson is not just “new loader, new campaign.” It is that exposed enterprise software, stale public-facing services, and installer-themed lures are still giving operators a reliable path from initial access to hands-on-keyboard activity.
For small businesses, MSPs, and government contractors, this is the kind of threat that sits between vulnerability management and incident response. SharkLoader is not the first loader to abuse DLL side-loading, encrypted components, scheduled tasks, and in-memory execution. What makes the campaign worth attention is the combination of broad victimology, publicly exploitable edge systems, and post-compromise tooling that can quickly turn a single internet-facing foothold into a full network investigation.
What Kaspersky reported
Kaspersky says the activity first surfaced during an investigation involving a diplomatic organization in Indonesia, then expanded into additional infections across several regions and sectors. Reported targets included government organizations in Taiwan, software development companies, and entities in Hong Kong, Lebanon, Syria, Colombia, North Macedonia, Nepal, Serbia, and other locations.
The initial access picture is especially important. Kaspersky observed exploitation of internet-facing applications, including Microsoft Exchange, Microsoft SharePoint, Openfire Server, GeoServer, Fortinet FortiOS, Cisco IOS XE Web UI, Zimbra, F5 BIG-IP, Hikvision products, Apache Shiro, and other exposed technologies. The researchers assessed with medium confidence that the actor is primarily using publicly available proof-of-concept exploit code rather than relying on custom exploit development.
That matters because it puts StrikeShark squarely in the “known exposure plus operational discipline” category. The actor does not need a zero-day if the perimeter still has old vulnerabilities, forgotten admin interfaces, or appliances that were patched without a compromise review.
How SharkLoader works
SharkLoader’s infection chain relies on multiple components. Kaspersky described abuse of the legitimate Windows SystemSettings.exe application for DLL side-loading, with a malicious SystemSettings.dll acting as the main loader. The chain then decrypts and reflectively loads encrypted modules, including components that carry Cobalt Strike Beacon and API-hooking functionality.
The campaign also used custom droppers disguised as legitimate software installers or update utilities, including Google Update and Cisco AnyConnect-themed samples. In some cases, decoy PDF documents were displayed to make the execution appear normal while malware components were quietly written into user profile paths.
Persistence was also practical rather than exotic. Kaspersky observed scheduled tasks configured to execute the copied legitimate application from the malware working directory, which then triggered the side-loaded SharkLoader DLL. That gives defenders a concrete place to look: scheduled tasks that launch trusted Windows binaries from unusual paths are worth immediate review.
Why this matters to SMBs and government contractors
Many smaller organizations and contractors do not have a clean separation between vulnerability management, endpoint detection, and server administration. Edge systems get patched when someone remembers, appliances are managed by different vendors, and “internet-facing inventory” often exists as a spreadsheet that is out of date the day after it is created.
StrikeShark punishes that gap. The reported exploitation targets are the same kinds of systems that frequently sit at the boundary of contractor environments: VPNs, collaboration platforms, web UIs, mail servers, remote administration portals, and line-of-business servers exposed for convenience. Once one of those systems is compromised, the attacker can move into a more familiar playbook: webshells, side-loaded DLLs, scheduled tasks, Cobalt Strike, credential access, and lateral movement.
Defensive takeaways
- Rebuild the internet-facing inventory. Do not rely only on asset records. Validate externally exposed systems from the outside, including cloud-hosted management panels, forgotten subdomains, partner-managed appliances, and legacy web applications.
- Patch and then investigate. If a vulnerable Exchange, SharePoint, Fortinet, Cisco IOS XE, Openfire, GeoServer, Zimbra, F5, or similar system was exposed during an exploitation window, treat patching as step one. Review logs, web roots, scheduled tasks, new services, unusual binaries, and outbound traffic.
- Hunt for trusted binaries in strange paths. Look for
SystemSettings.exeor other legitimate Windows binaries running fromProgramData,AppData, temporary directories, or vendor-looking folders that do not match normal software installation paths. - Review scheduled tasks aggressively. Tasks with update-themed names, unusual SIDs, high-frequency triggers, or commands launching signed binaries from user-writable paths should be escalated.
- Watch for Cobalt Strike behavior, not just hashes. SharkLoader components will change. Beacon behavior, suspicious memory allocation, process injection, anomalous DNS/HTTP patterns, and lateral movement tooling are more durable signals.
- Tighten installer trust. If users download VPN clients, update tools, or vendor installers from email links or search results, that is a policy and awareness problem. Provide known-good internal download locations for common business tools.
Bulwark Black assessment
StrikeShark is a good reminder that perimeter exposure remains one of the cheapest paths into serious environments. The malware has interesting engineering, but the business risk is simpler: a neglected edge service can become a Cobalt Strike foothold, and a convincing installer lure can still bypass human trust controls.
For organizations supporting government work, this should trigger a quick control check: current external attack surface inventory, prioritized patch SLAs for internet-facing systems, EDR coverage on servers, scheduled-task monitoring, and a documented process for deciding when a patched edge device needs a rebuild or forensic review. If those pieces are missing, the next “new loader” report will not be the real problem. The real problem will be that the environment gave the loader an easy place to land.
Original source: Kaspersky Securelist — StrikeShark: investigating a new campaign delivering Cobalt Strike through SharkLoader.
