SharkLoader → Cobalt Strike: Why StrikeShark Is a Chain of #7 Events

Kaspersky's StrikeShark investigation describes a campaign in which a previously undocumented loader called SharkLoader ultimately executes Cobalt Strike Beacon. Initial access occurred through exploited internet-facing applications or custom droppers disguised as legitimate software. The Hacker News summarized the research on June 26, 2026, following Kaspersky's publication on June 24.

The conventional headline calls this a "SharkLoader malware campaign." That is useful for recognizing the operation, but it is not a sufficient threat classification.

Through the Top Level Cyber Threat Clusters framework, the relevant question is not which malware family was involved. It is:

That shift exposes the StrikeShark campaign as a sequence of different causes — and, within its execution chain, several consecutive instances of #7 Malware.

The TLCTC verdict

At its simplest, the loader-to-payload segment is:

More descriptively:

That classification follows R-EXEC: whenever Foreign Executable Content (FEC) is interpreted, loaded, or executed, a distinct #7 step must be recorded. Execution cannot be absorbed into the preceding enabling step.

SharkLoader and Cobalt Strike are different executable payloads performing different roles. SharkLoader is the loader; Cobalt Strike Beacon is the subsequently executed implant. The second payload does not become part of the first #7 merely because SharkLoader loads it — it creates another execution event:

The campaign name is not the attack path

"StrikeShark" is a campaign label. "SharkLoader" is a malware-family label. "Cobalt Strike" is a tool name. None of those labels identifies the generic vulnerability exploited by itself. A tool becomes relevant to TLCTC classification only when an attacker performs an action with it.

Cobalt Strike, for example, is dual-use software. Its name does not automatically make an event #7. But when an attacker causes a Beacon payload or attacker-controlled Beacon commands to execute on a target, the environment's designed capability to execute foreign content is being used. That action is therefore #7.

The actor's identity is equally irrelevant to the classification. Kaspersky assessed a possible Chinese-speaking connection with low confidence, while finding no direct overlap with an established group. Under Axiom IV, attribution may enrich the intelligence record, but it cannot determine the threat cluster.

Path 1: Exploitation of public-facing servers

Kaspersky observed exploitation involving Microsoft Exchange, SharePoint, Openfire, GeoServer, Apache Shiro, F5 BIG-IP, FortiOS, Cisco IOS XE and other internet-facing products. These components were processing attacker-controlled inbound requests or stimuli in a server role. The initial generic vulnerability was therefore a server-side implementation flaw.

"Remote code execution" is not the threat classification. RCE is an effect describing what an exploit achieved. The causal classification remains #2. When that exploitation results in foreign code executing, R-EXEC requires:

Kaspersky reported that the attackers established persistence on compromised servers through webshells. A webshell is attacker-controlled executable content, so its execution adds the first #7:

DLL side-loading: #1 → #7

The attackers copied the legitimate Windows application SystemSettings.exe into an attacker-controlled directory and executed it alongside a malicious SystemSettings.dll. The legitimate application then loaded the attacker's DLL through its normal DLL-loading behavior.

This contains two distinct causes. First, the attacker abuses legitimate software behavior without requiring another implementation flaw — #1 Abuse of Functions. Second, the malicious DLL executes — #7 Malware. The correct sequence is therefore:

The legitimate executable is not itself malware. Its designed loading behavior is being misused to enable the execution of foreign content. The path now reads:

This distinction matters operationally. Controls preventing misuse of DLL search behavior address #1; controls preventing the malicious DLL from executing address #7. Treating the entire sequence merely as "malware" collapses two different control objectives.

Inside SharkLoader: repeated #7 execution

Kaspersky's technical analysis shows that SharkLoader is not a single monolithic executable event. After SystemSettings.dll begins executing, it decrypts DscCoreR.mui, reconstructs its PE image in memory, transfers execution to its entry point, and invokes its unpacked code. DscCoreR.mui then decrypts and reflectively loads SyncRes.dat. Additional code loads the MinHook library and prepares a suspended thread containing the decompressed Cobalt Strike Beacon shellcode. The thread is finally resumed, causing the Beacon to execute.

At a compact strategic resolution:

At a forensic resolution, each separately evidenced FEC execution may be represented:

Combining this with the initial compromise produces the full expanded chain:

This is not redundant repetition. Each #7 records a distinct executable-content transition.

"In memory" does not alter the classification

SharkLoader reflectively maps modules and executes them without necessarily writing the reconstructed PE files to disk. Cobalt Strike Beacon is decompressed into a memory buffer and executed by resuming a suspended thread. Disk versus memory is an implementation detail, not a top-level threat distinction.

The generic vulnerability is still the environment's designed ability to execute attacker-controlled instructions: #7. Reflective loading, process injection, API hooking, suspended-thread execution and loader-lock manipulation describe how the content executes. They do not create new strategic clusters. Under TLCTC semantic guardrails, the following are effects, techniques, or internal transitions — never clusters:

• "Process injection" is not a cluster.
• "Defense evasion" is not a cluster.
• "Persistence" is not a cluster.
• "Privilege escalation" is not a cluster.
• "In-memory malware" is not a separate threat class.

Internal boundaries do not independently change classification. A new cluster is added only when a distinct generic vulnerability is separately exploited.

Path 2: The malicious-dropper route

Kaspersky also identified custom executable droppers masquerading as applications such as Google Update and Cisco AnyConnect. Some samples displayed decoy PDF documents intended to persuade a victim that the executable was legitimate. The exact delivery mechanism remained unknown, and not every sample included a lure.

Where psychological manipulation caused a person to execute the dropper, the path begins:

The technical steps following the manipulation must be classified independently. The human manipulation cannot absorb the later execution step. The dropper then wrote the SharkLoader components to disk, copied SystemSettings.exe, created scheduled tasks and caused the side-loading chain to execute. A representative path:

For samples where no human manipulation is evidenced, #9 must not be assumed. The unresolved delivery step should remain unresolved rather than being filled with a convenient "phishing" label:

Persistence is an action, not a cluster

StrikeShark used Registry Run keys and scheduled tasks to launch SystemSettings.exe. In dropper-based infections, one task reportedly executed every five minutes, while another executed every second and was later removed.

"Persistence" describes the intended effect. It does not identify the exploited generic vulnerability. Creating or modifying a scheduled task through its designed administrative interface is #1 Abuse of Functions. When that task later launches attacker-controlled executable content, the execution is #7 Malware:

This reveals two distinct control points:

A single generic "persistence control" label conceals that separation.

Credential theft is not automatically #4

Post-compromise activity included Active Directory enumeration and attempts to obtain credentials from LSASS and the NTDS database. The attackers used built-in commands, Cobalt Strike, the webshell and external tools such as ProcDump.

TLCTC makes a mandatory distinction between credential acquisition and credential use (R-CRED, Axiom X). Credential acquisition maps to the mechanism that made the acquisition possible:

The confidentiality DRE should be added only when credential exposure or acquisition is established, not merely because an attempt occurred. Only subsequent presentation or use of an acquired password, token, ticket or hash to impersonate an identity is #4 Identity Theft. A confirmed continuation would look like:

Credential theft is not collapsed into #4. Acquisition and application are separate events. Note also that cluster #4 never carries a DRE tag — the confidentiality loss is annotated on the acquisition step, not the impersonation step.

Why this is not a supply-chain attack

The victim list included software-development companies. That fact does not make the campaign #10 Supply Chain Attack. A supply-chain attack requires exploitation of a third-party trust dependency at a Trust Acceptance Event — for example, a downstream organization accepting a compromised vendor update, component, service or hardware artifact as authoritative.

In the published StrikeShark evidence, the software companies were targets. There is no reported downstream delivery of compromised trusted software to their customers.

Bow-Tie interpretation

The TLCTC architecture keeps the three lanes connected but semantically separate: attack causes, data events, and organization-specific business consequences.

Control implications

The decomposition shows why "deploy anti-malware" is an incomplete response.

Consequence-side controls begin after compromise: isolate systems, invalidate sessions, rotate exposed credentials, preserve evidence and determine whether a confidentiality, integrity, accessibility or availability event actually occurred. Cause-side controls prevent the compromise; consequence-side controls limit its damage. They should not be treated as interchangeable.

Conclusion

Yes — SharkLoader deploying Cobalt Strike is correctly expressed as #7 → #7. But that is only one segment of the StrikeShark attack path. The broader public-facing-server chain is:

And the expanded forensic execution chain may contain several consecutive #7 steps:

The repetition is the point. TLCTC does not collapse an intrusion into a campaign name, an actor label, an outcome such as "RCE," or a broad category such as "malware attack." It records each causal step according to the generic vulnerability exploited.

That is how a headline becomes an attack path — and how an attack path becomes a defensible control strategy.