StrikeShark & SharkLoader Dissected: Inside the Unattributed APT Campaign Hitting Diplomats, Governments, and Software Firms Across 9 Countries
On June 24, 2026, Kaspersky’s GReAT team published the first public dissection of a campaign they call StrikeShark, and the first thing you notice is what’s missing: a name on the box. No Panda, no Bear, no Kitten, no numbered APT. Diplomats in Indonesia, government agencies in Taiwan, and software shops scattered across seven other countries got hit by the same toolkit, and after pulling the threads, Kaspersky’s verdict was effectively a shrug with a caveat. That shrug is the most interesting thing in the report, and it tells you exactly where modern intrusion tradecraft is heading.
The thesis: commoditization is the camouflage
Here is the argument I want you to leave with. StrikeShark is not unattributed because the operators are wizards who never make mistakes. It is unattributed because they built the entire operation out of parts that anyone can buy, download, or copy-paste. Public CVEs against years-old internet-facing software. A Cobalt Strike Beacon, the most over-deployed C2 framework on earth. Reconnaissance tools pulled straight off GitHub. A loader whose cleverest trick, MinHook-based API hooking, is the same technique taught in every red-team malware-dev course.
When every component is shared, the fingerprint dissolves. Attribution analysts live on overlaps: shared code, reused infrastructure, distinctive operational habits. Strip those away and you get a campaign that hits a diplomatic mission in Jakarta and a government network in Taipei with no thread you can pull back to a known crew. That is not an accident. It is the strategy. And it means that for the rest of us, detection has to shift from “who” to “how,” because the “how” is the only durable signal left.
So let’s get into the how.
Targeting and victimology: a 9-country espionage footprint
Kaspersky documented victims in nine countries, and the pattern reads like an intelligence-collection brief rather than a crimeware spray.
| Country | Sector hit |
|---|---|
| Indonesia | Diplomatic entity |
| Taiwan | Government agencies, software development firms |
| Hong Kong | Software development and other organizations |
| Lebanon | Mixed organizations |
| Syria | Mixed organizations |
| Colombia | An organization running a vulnerable GeoServer |
| North Macedonia | Mixed organizations |
| Nepal | Mixed organizations |
| Serbia | Mixed organizations |
Two clusters stand out. The diplomatic and government targets (Indonesia, Taiwan) scream classic state-aligned espionage. The software-development targets are the part that should keep you up at night, because compromising a software vendor is the front door to a supply-chain operation. Kaspersky was explicit that the campaign’s ultimate objectives remain under research, but the combination of government bodies and software developers is the textbook profile for long-term collection and pre-positioning.
One sober caveat from the report: Kaspersky only sees what Kaspersky’s telemetry sees. The actor leaned heavily on exploitation of public-facing applications, which means the real victim count is almost certainly higher than nine countries. Treat the published footprint as a floor, not a ceiling.
Initial access, path A: exploiting the internet-facing crowd
StrikeShark’s operators don’t pick locks they have to invent. They walk through doors that organizations left propped open for years. The exploitation set is a roll-call of the most reliably unpatched enterprise software on the planet.
| CVE | Product | Bug class | Observed against |
|---|---|---|---|
| CVE-2021-26855 | Microsoft Exchange (ProxyLogon) | SSRF leading to auth bypass and RCE | Indonesian diplomatic entity |
| CVE-2021-27076 | Microsoft SharePoint | Deserialization RCE | Triggered the SystemSettings sideload chain from multiple directories |
| CVE-2023-32315 | Openfire XMPP server | Unauthenticated path traversal to admin RCE | Taiwanese software firms |
| CVE-2024-36401 | GeoServer | OGC filter evaluation RCE | Colombian organization |
Look at the dates. ProxyLogon is a 2021 bug that Microsoft patched out-of-band in March 2021 amid one of the loudest emergency-patching events in recent memory. If you are still exposing an unpatched Exchange box to the internet in 2026, you are not a hard target, you are an open invitation. The Openfire flaw (CVE-2023-32315) is an unauthenticated traversal in the admin console that drops you straight into plugin-upload RCE, fixed in Openfire 4.6.8 and 4.7.5. GeoServer’s CVE-2024-36401 abuses how the OGC filter language evaluates property names, turning a geospatial query parameter into arbitrary code execution.
The post-exploitation move after path A is consistent and worth memorizing, because it’s your best early-stage detection anchor:
- The webshell or exploited process writes a malicious
SystemSettings.dllplus encrypted payload files into the same directory as the legitimateSystemSettings.exe. - The operator launches
SystemSettings.exe, which obediently loads the planted DLL through search-order hijacking. - SharkLoader is now running inside a signed, legitimate Microsoft binary.
In the SharePoint cases tied to CVE-2021-27076, Kaspersky watched the operators kick off SystemSettings.exe from several different directories on the same host, which they read as renewed, hands-on-keyboard activity rather than a fire-and-forget implant. In some incidents the staging directories were named after security-product vendors to blend into the noise of a typical endpoint. That detail matters for hunting, and we’ll come back to it.

Initial access, path B: trojanized installers and decoy PDFs
Not every victim ran a vulnerable server. For the rest, the operators reached for social engineering dressed up as routine software. Kaspersky observed droppers masquerading as Google Update and Cisco AnyConnect installers.
The Cisco AnyConnect lure is a nice piece of misdirection. The dropper genuinely decompresses and runs a real-looking AnyConnect installer in the foreground while, in the background, it quietly stages SharkLoader components into subdirectories under %APPDATA%. The victim watches a familiar progress bar, the install “completes,” and the loader fires once setup finishes. Nothing looks wrong.
The decoy-document tradecraft is similarly mundane and effective:
- Several droppers carry a decoy PDF to give the victim something to look at. Others skip the lure entirely and exist purely as a delivery shell.
- Most droppers write the decoy PDF into a subdirectory named
aswerfunder%TEMP%. Some drop straight into%TEMP%. - The PDF lives in the dropper’s resource section under the resource name
TELEMETRY, compressed with zlib.
That TELEMETRY resource name and the aswerf temp path are gold for analysts triaging samples, because they’re specific enough to pivot on without being so generic that you drown in false positives. Here’s a parser you can run against a suspect dropper on an isolated analysis box to rip the embedded blob out and check whether it’s a decoy PDF or a follow-on PE:
# SharkLoader dropper: extract the TELEMETRY resource (decoy PDF or staged payload)
# Run only against samples in an isolated analysis environment.
import pefile, zlib
def extract_telemetry_resource(pe_path: str) -> bytes:
pe = pefile.PE(pe_path)
for rsrc_type in pe.DIRECTORY_ENTRY_RESOURCE.entries:
for rsrc_id in rsrc_type.directory.entries:
name = rsrc_id.name.string.decode() if rsrc_id.name else str(rsrc_id.id)
if name.upper() == "TELEMETRY":
for rsrc_lang in rsrc_id.directory.entries:
offset = rsrc_lang.data.struct.OffsetToData
size = rsrc_lang.data.struct.Size
raw = pe.get_memory_mapped_image()[offset:offset + size]
return zlib.decompress(raw)
return b""
# blob = extract_telemetry_resource("suspicious_dropper.exe")
# Check magic bytes: b"%PDF" for decoy, b"MZ" for a staged PE.
SharkLoader deep dive: the four-stage loading chain
SharkLoader is the heart of this campaign and, until June 24, was undocumented. Its job is narrow: get a Cobalt Strike Beacon running in memory without tripping endpoint defenses. It does that across four stages, each of which is a recognizable building block but assembled with some care.
Stage 1: DLL side-loading inside a signed binary
The abused binary is SystemSettings.exe, the Windows Immersive Control Panel that normally lives in C:\Windows\ImmersiveControlPanel\. The malicious SystemSettings.dll gets planted in the loader’s working directory, and Windows search-order behavior loads the attacker DLL ahead of any legitimate one. The payoff is that all of SharkLoader’s subsequent activity unfolds under the cover of a Microsoft-signed process. To a tired SOC analyst, SystemSettings.exe allocating memory and making network calls looks far less alarming than evil.exe doing the same thing.
Stage 2: encrypted module loading
SharkLoader then reads and decrypts additional payload files from disk. These were staged earlier, either uploaded through the webshell (path A) or dropped by the trojanized installer (path B). Filenames vary by incident, but the toolkit’s container files include DscCoreR.mui and a staging file named SyncRes.dat. Keeping the encrypted bytes on disk and decrypting in memory means a static scan of the dropped files turns up high-entropy junk rather than recognizable shellcode.
Stage 3: MinHook API hooking
This is the stage that earns SharkLoader its keep. After spinning up a suspended thread that will eventually run the beacon, the loader decompresses a zlib-packed MinHook PE that is embedded inside DscCoreR.mui. MinHook is a well-known open-source inline-hooking library, the kind of thing you’d normally find in a game trainer or a legitimate instrumentation tool. The loader maps it into memory, resolves the exports MH_Initialize and MH_CreateHook, and installs hooks on two Windows APIs: VirtualAlloc and Sleep.
Here is the logic, annotated for analysts doing triage. This is a behavioral reference, not working malware:
# SharkLoader Stage 3: MinHook hook installation (analyst reference)
# Behavior per Kaspersky GReAT, Securelist 2026-06-24
raw_data = read_file("DscCoreR.mui")
minhook_pe = zlib_decompress(raw_data[mh_off : mh_off + mh_size])
minhook_mod = load_pe_in_memory(minhook_pe) # reflective / manual map
MH_Initialize = resolve_export(minhook_mod, "MH_Initialize")
MH_CreateHook = resolve_export(minhook_mod, "MH_CreateHook")
MH_Initialize()
# Install inline hooks on the two APIs SharkLoader cares about
MH_CreateHook(target=VirtualAlloc, hook=hook_VirtualAlloc, original=&orig_VirtualAlloc)
MH_CreateHook(target=Sleep, hook=hook_Sleep, original=&orig_Sleep)
MH_EnableHook(MH_ALL_HOOKS)
# Beacon shellcode is also zlib-packed inside the same container
beacon_sc = zlib_decompress(raw_data[bc_off : bc_off + bc_size])
# This VirtualAlloc call is now intercepted by hook_VirtualAlloc,
# which records the RWX region's address and size for the operator.
rwx_mem = VirtualAlloc(NULL, len(beacon_sc), MEM_COMMIT, PAGE_EXECUTE_READWRITE)
memcpy(rwx_mem, beacon_sc, len(beacon_sc))
resume_thread(suspended_beacon_thread) # execute from the earlier suspended thread
A note on tooling: MinHook is the library Kaspersky confirmed in its own analysis. Community write-ups of the broader toolset have also mentioned Microsoft Detours, but treat that as possibly belonging to a separate sample variant rather than the same binary GReAT pulled apart. Don’t assume both libraries live in one loader unless your own sample shows it.
Stage 4: Beacon decompression and injection
With hooks live, SharkLoader decompresses the zlib-packed Cobalt Strike Beacon shellcode into a scratch buffer, calls VirtualAlloc to grab an RWX region with PAGE_EXECUTE_READWRITE, copies the beacon in, and runs it via the suspended thread it created back in Stage 3. Because VirtualAlloc is already hooked, the hook handler captures the exact address and size of the beacon’s home in memory before any defensive scanner gets a clean look.

Why hook VirtualAlloc and Sleep specifically
The choice of those two APIs is not arbitrary, and understanding the reasoning tells you where your detection blind spots are.
Hooking VirtualAlloc gives the loader a front-row seat to its own memory allocations. Modern EDRs lean heavily on memory scanning: they look for RWX regions that contain shellcode signatures, unbacked executable memory, beacon configuration patterns, and so on. By intercepting VirtualAlloc from inside the process, the malware controls the moment of allocation. The hook handler knows precisely which region holds the beacon, which means the operator can monitor it, re-protect it, or otherwise manage it to stay ahead of a scanner that only wakes up periodically. The hook turns a noisy, signature-rich event into something the malware orchestrates on its own terms.
Hooking Sleep is the oldest sandbox-evasion trick that still works. Automated sandboxes have a time budget, so many of them fast-forward or skip Sleep calls to get the sample to detonate quickly. A malware sample that times its own sleep can notice when wall-clock time doesn’t match the requested delay, conclude it’s in a sandbox, and bail before doing anything incriminating. Hooking Sleep lets SharkLoader insert that timing logic cleanly into a single chokepoint.
The defender takeaway is blunt: if your detection strategy relies on user-mode hooks of VirtualAlloc, you are playing on the malware’s home turf, because SharkLoader is hooking the same function you are. The reliable signal lives below user mode, in kernel-sourced telemetry like ETW Threat Intelligence, which we’ll get to.
Post-exploitation: FScan, Searchall, Pillager, and the Beacon
Once the beacon is live, the operators reach for off-the-shelf reconnaissance and collection tooling rather than anything bespoke.
| Tool | Role |
|---|---|
| FScan | Internal network scanning and service enumeration |
| Searchall | File and credential search across hosts |
| Pillager | Credential harvesting and data collection |
| Cobalt Strike Beacon | C2, lateral movement, exfiltration |
All three recon utilities are open-source projects, and Kaspersky’s analysis found they were authored by developers identified as Chinese-speaking on GitHub. Hold that thought, because it’s the load-bearing detail in the entire attribution discussion, and it carries less weight than it first appears.
C2 infrastructure: what is public and what is not
Here is where I have to be straight with you about the limits of what’s public. The Securelist post does not publish StrikeShark’s C2 domains. The Cobalt Strike Beacon configurations, including the C2 servers and malleable profiles, are gated behind the Kaspersky Intelligence Reporting Service. I’m not going to invent domains to fill the gap, and you shouldn’t trust any write-up that does. In particular, do not recycle C2 indicators from older Sophos research on a related toolset, because that is a separate, earlier cluster and bolting its infrastructure onto StrikeShark would be a clean way to poison your own threat intel.
What you can do generically is hunt the beacon’s behavior rather than its addresses: regular-interval HTTPS callbacks (jittered) from a process like SystemSettings.exe, beaconing that survives the host’s idle periods, and outbound connections from a signed binary that has no legitimate reason to talk to the internet.
Attribution analysis: why this stays unattributed
Now the centerpiece. Kaspersky was careful, and you should be too. Their assessment is that StrikeShark is possibly a Chinese-speaking threat actor, with low confidence. Low confidence. That phrase is doing a lot of work and it deserves respect.
The reasoning behind the low-confidence call rests on three gaps:
- No code reuse. SharkLoader shares no recognizable code with any catalogued malware family. There is no inherited crypter, no telltale string-decode routine, no reused packer that ties it to a known group.
- No infrastructure overlap. The C2 infrastructure does not overlap with any actor Kaspersky tracks. No shared servers, no reused TLS certificates, no hosting patterns that map to a known cluster.
- Dual-use, open-source tooling. FScan, Searchall, and Pillager are public. Anyone can clone them. The fact that their authors are Chinese-speaking tells you something about the tools’ provenance, not necessarily about the operator wielding them.
That third point is the trap, and it’s why the assessment is low confidence rather than medium or high. “These tools were written by Chinese-speaking developers” is a statement about GitHub, not about the people running the campaign. Plenty of actors, including ones with every incentive to look like someone else, reach for the same public Chinese-language offensive tooling precisely because it’s good and because it muddies attribution. Treating tool provenance as actor identity is exactly the analytic shortcut that leads to false flags and burned reputations.
So when you write up StrikeShark internally, or when you cite it, mirror Kaspersky’s discipline. The honest statement is: an unattributed actor, broad espionage-shaped targeting, low-confidence Chinese-speaking hypothesis, objectives still under investigation. Anything firmer than that is you adding confidence the evidence doesn’t support.

IOCs: what is public, what is gated
Kaspersky reserved the full indicator set for IRS customers, so the public, citable observables are behavioral and filename-based rather than a tidy list of hashes and domains.
| Type | Indicator | Confidence note |
|---|---|---|
| Sideload binary | SystemSettings.exe from a non-standard path | Legitimate name, malicious context |
| Malicious DLL | SystemSettings.dll planted beside the EXE | High value when path is abnormal |
| Container file | DscCoreR.mui (zlib MinHook + payload) | Legit-looking name; weight by directory |
| Staging file | SyncRes.dat (encrypted payload) | Related toolset filename |
| Dropper resource | Resource named TELEMETRY, zlib-compressed | Strong sample-triage pivot |
| Decoy path | %TEMP%\aswerf\ and %APPDATA%\<vendor-name>\ | Hunt for unexpected creation |
| Tooling | FScan, Searchall, Pillager, Cobalt Strike | Dual-use, corroborate with context |
Hashes and C2 domains: partial set only, full IOCs are behind the Kaspersky Intelligence Reporting Service. Don’t fabricate the rest.
YARA for SharkLoader: detecting the observable mechanics
This rule is author-constructed from the technical observables documented in Kaspersky GReAT’s public Securelist report. It is not an official Kaspersky signature. Test it, expect to tune it, and pair string matches with path and parent-process context before you act on a hit.
rule SharkLoader_Candidate_Observables {
meta:
description = "Patterns consistent with SharkLoader per Kaspersky GReAT (Securelist 2026-06-24)"
author = "GenXCyber Research - author-constructed, not an official Kaspersky signature"
reference = "https://securelist.com/strikeshark-campaign/120326/"
date = "2026-06-25"
confidence = "medium"
strings:
$mh_init = "MH_Initialize" ascii wide
$mh_hook = "MH_CreateHook" ascii wide
$mh_enable = "MH_EnableHook" ascii wide
$fn1 = "DscCoreR.mui" ascii wide nocase
$fn2 = "SyncRes.dat" ascii wide nocase
$fn3 = "SystemSettings" ascii wide nocase
$res_name = "TELEMETRY" ascii wide
$drop_path = "\\reports\\" ascii wide
$tmp_aswerf = "\\aswerf\\" ascii wide
$zlib_magic = { 78 9C }
condition:
uint16(0) == 0x5A4D and filesize < 20MB and (
(2 of ($mh_*) and 1 of ($fn1, $fn2)) or
($res_name and ($drop_path or $tmp_aswerf)) or
($fn3 and $fn1 and $zlib_magic)
)
}
Known false-positive vectors to document before you deploy: legitimate MinHook-using security and instrumentation tools will trip the $mh_* strings, so never fire on those alone. DscCoreR.mui is a real Windows resource filename in some builds, so the directory and parent process are what separate signal from noise. The high-confidence shape is a PE that contains both MinHook exports and a DscCoreR.mui reference while sitting in an abnormal directory, especially an %APPDATA% subfolder named after a security vendor.
Detection and defense: where to actually catch this
The whole point of dissecting a loader is to turn its mechanics into telemetry you can hunt. SharkLoader leaves marks at every stage if you’re collecting the right events.
Sysmon events that matter
| Event ID | Hunt for |
|---|---|
| 1 (Process Create) | SystemSettings.exe spawned by w3wp.exe, java.exe, or a webshell process, or from any path outside C:\Windows\ImmersiveControlPanel\ |
| 7 (Image Load) | SystemSettings.dll or other DLLs loaded from %APPDATA% subdirectories, especially vendor-named ones |
| 3 (Network Connect) | Outbound HTTPS from SystemSettings.exe or injected processes to unfamiliar FQDNs |
| 8 (CreateRemoteThread) | Beacon injection into a remote process |
| 10 (Process Access) | LSASS handle opens from the sideload chain (Pillager credential theft) |
| 11 (File Create) | Drops of SystemSettings.dll, DscCoreR.mui, SyncRes.dat, or decoy PDFs to %TEMP%\aswerf\ |
| 25 (Process Tampering) | Shellcode-injection signals around the hooked RWX region |
ETW providers that beat the hooks
Because SharkLoader hooks VirtualAlloc in user mode, your most reliable detection comes from kernel-sourced telemetry it cannot reach from inside the process.
| Provider | Why |
|---|---|
| Microsoft-Windows-Threat-Intelligence (ETWTI) | Flags RWX VirtualAlloc from unusual callers, the single best counter to the hooking trick |
| Microsoft-Windows-Kernel-Process | DLL image-load visibility independent of user-mode hooks |
| Microsoft-Windows-DNS-Client | C2 domain resolution telemetry |
| AMSI | Shellcode scanning at allocation time |
Sigma rule for the sideload chain
title: SharkLoader - Suspicious SystemSettings.exe DLL Sideload
status: experimental
description: >
Detects SystemSettings.exe running from a non-standard path or spawned by a
suspicious parent, consistent with SharkLoader (Kaspersky GReAT, 2026-06-24).
references:
- https://securelist.com/strikeshark-campaign/120326/
tags:
- attack.defense_evasion
- attack.t1574.002
- attack.t1055
logsource:
category: process_creation
product: windows
detection:
selection:
Image|endswith: '\SystemSettings.exe'
filter_legitimate:
ParentImage|startswith: 'C:\Windows\ImmersiveControlPanel\'
CurrentDirectory|startswith: 'C:\Windows\ImmersiveControlPanel\'
condition: selection and not filter_legitimate
fields:
- Image
- ParentImage
- CommandLine
- CurrentDirectory
- User
level: high
Hardening priorities
The unglamorous truth is that path A would close almost entirely if organizations patched. Prioritize accordingly:
- Critical: Patch Exchange (CVE-2021-26855) and SharePoint (CVE-2021-27076). These are multi-year-old bugs. An unpatched, internet-facing instance in 2026 is negligence, not bad luck.
- Critical: Patch Openfire to 4.6.8 or 4.7.5 and later to kill CVE-2023-32315.
- High: Patch GeoServer for CVE-2024-36401.
- High: Use application allowlisting to forbid
SystemSettings.exefrom ever executing out of%APPDATA%. - Medium: Hunt for unsigned or out-of-place DLLs in
%APPDATA%directories named after security vendors, and alert on%TEMP%\aswerf\creation. - Medium: Segment the network so a single compromise plus FScan doesn’t translate into free lateral movement.
- Low: Sweep Exchange and SharePoint log paths (
\inetpub\,\OWA\,\scripts\) for webshell artifacts.

MITRE ATT&CK mapping
| Tactic | Technique | StrikeShark specifics |
|---|---|---|
| Initial Access | T1190 Exploit Public-Facing Application | CVE-2021-26855, CVE-2021-27076, CVE-2023-32315, CVE-2024-36401 |
| Initial Access | T1566.001 Spearphishing Attachment | Trojanized Google Update / Cisco AnyConnect droppers with decoy PDFs |
| Execution | T1204.002 User Execution: Malicious File | Victim runs the trojanized installer |
| Execution | T1059 Command and Scripting Interpreter | Hands-on-keyboard via Cobalt Strike Beacon |
| Persistence / Defense Evasion | T1574.002 DLL Side-Loading | SystemSettings.exe plus malicious SystemSettings.dll |
| Defense Evasion | T1055 Process Injection | Beacon shellcode in RWX VirtualAlloc region |
| Defense Evasion | T1562.001 Impair Defenses | MinHook hooks on VirtualAlloc and Sleep to defeat memory scanning and sandboxing |
| Defense Evasion | T1027 Obfuscated/Compressed Files | zlib-packed MinHook, beacon, and decoy PDF |
| Discovery | T1046 Network Service Discovery | FScan internal scanning |
| Credential Access | T1003 OS Credential Dumping | Pillager, LSASS access |
| Collection | T1005 Data from Local System | Searchall file and credential search |
| Command and Control | T1071.001 Web Protocols | Cobalt Strike Beacon over HTTP/HTTPS |
Where defenders are blind, and what to do Monday morning
The detection gap that lets StrikeShark run is a stack of small ones. User-mode hook-based EDR is partially blinded by SharkLoader hooking the same VirtualAlloc it watches. Signed-binary execution lowers analyst suspicion. zlib-packed payloads defeat naive static scanning. And the attribution machinery, built to recognize known actors by their reused parts, has nothing to grip when every part is public. None of these gaps is exotic on its own. Stacked together, they produce a campaign that compromised diplomats and governments across nine countries and still doesn’t have a name.
If you run an internet-facing Exchange, SharePoint, Openfire, or GeoServer instance, your action this week is boring and decisive: confirm the patch level against the four CVEs above, then go look for SystemSettings.exe running anywhere it shouldn’t. That one query catches the moment SharkLoader steps out of the exploited service and into a signed binary, and it’s the same chokepoint whether the operators turn out to be Chinese-speaking, someone borrowing their tools, or someone else entirely.
Key takeaways
- StrikeShark is unattributed by design, not by luck. Public CVEs, off-the-shelf Cobalt Strike, and GitHub recon tools leave no fingerprint to trace.
- Treat “Chinese-speaking, low confidence” as exactly that. Tool provenance is not actor identity, and Kaspersky’s own caution is the model to follow.
- SharkLoader’s edge is MinHook hooking of
VirtualAllocandSleep, which defeats user-mode memory scanning and sandbox timing. Counter it with kernel telemetry (ETWTI), not more user-mode hooks. SystemSettings.exerunning outsideImmersiveControlPanelis your single best detection anchor. Build the alert today.- Patching closes path A almost entirely. ProxyLogon in 2026 is unforgivable. The full IOC set sits behind Kaspersky’s IRS, so build behavioral detections rather than waiting on a hash list.
Related Tutorials
- Phishing Campaign Design: Pretexting, Lures, and Target Profiling
- APT Profiling: How to Build a Comprehensive Adversary Profile from Open-Source Intelligence