AI Detection Lessons From Ink Dragon’s ShadowPad Attacks

A government perimeter can be “patched” and still be wide open.

Ink Dragon (also tracked as Jewelbug, CL-STA-0049, Earth Alux, and REF7707) is a China-aligned cluster that’s been hitting government and telecom environments across Europe, Asia, and Africa in 2025. What makes this campaign worth your attention isn’t only the malware names—ShadowPad and FINALDRAFT—it’s the operating model: compromised servers become part of the attacker’s infrastructure, and familiar Microsoft and IIS telemetry becomes camouflage.

If you work in government IT, a regulated enterprise, or a SOC supporting either, here’s the stance I’ll take: you won’t “IOC your way” out of this. Ink Dragon’s tradecraft is built to outlast point fixes and signature-based detection. The practical answer is AI-driven anomaly detection plus disciplined containment—because the fastest clue often isn’t a known hash, it’s behavior that doesn’t fit.

What Ink Dragon’s intrusion chain looks like (and why it’s hard to spot)

Ink Dragon’s playbook is effective because it’s modular, repeatable, and blends into normal operations.

Step 1: Internet-facing app exploitation to get a foothold

The campaign has used vulnerable internet-exposed web applications (notably IIS/SharePoint paths) to drop web shells, then stage additional tooling (for example, Cobalt Strike) for command-and-control (C2), discovery, lateral movement, and data exfiltration.

Why defenders miss it: a web shell on an IIS host can generate traffic that resembles admin activity—especially in environments where change control is loose or where “temporary fixes” became permanent.

Step 2: ViewState deserialization via predictable ASP.NET machine keys

A particularly nasty theme: the abuse of mismanaged or predictable ASP.NET machine key values to conduct ViewState deserialization attacks. Once a server is abused this way, Ink Dragon can deploy a custom ShadowPad IIS Listener module.

Why this matters: this isn’t just initial access—it’s a path to turning your server into a relay.

Step 3: Turning victims into a relay network (the mesh problem)

Check Point’s reporting highlights an architecture where the compromised IIS servers don’t just beacon out; they become part of the adversary’s broader ShadowPad relay network—proxying commands and traffic.

A useful mental model: Ink Dragon tries to erase the line between “infected endpoint” and “attacker infrastructure.”

Operational impact: even if you contain one host, the attacker may still have other “hops” through other victims’ infrastructure. That creates resilience, reduces reliance on easily-blocked dedicated C2 domains, and makes takedown much harder.

ShadowPad + FINALDRAFT: why these tools work in government networks

Ink Dragon isn’t betting on a single backdoor. It’s betting on a toolkit and an operational rhythm.

ShadowPad: mature, modular, and ideal for long-haul access

ShadowPad is a known, modular malware family used in multiple espionage campaigns. In this reporting, ShadowPad shows up with loaders and listener components designed to:

• Decrypt and run core modules in memory
• Provide flexible control over an IIS host
• Support relay-style routing through compromised servers

Defense implication: detections that rely on “file on disk” are frequently late.

FINALDRAFT: living off Microsoft APIs for command delivery

FINALDRAFT (also called Squidoor in some tracking) has been described as capable of targeting both Windows and Linux. An updated variant is noted as having better stealth and higher exfiltration throughput.

One of the most uncomfortable details for defenders: FINALDRAFT can abuse Outlook and the Microsoft Graph API for C2, pushing encoded command documents into a victim mailbox and having the implant pull, decrypt, and execute them.

Why this is brutal: many SOCs treat Microsoft 365/Graph activity as “trusted business exhaust.” Attackers know it.

The real lesson: this is a detection problem, not just a patching problem

Patching matters. Hardening matters. But the deciding factor in campaigns like this is usually time-to-detect and time-to-contain.

Ink Dragon’s chain includes classic post-exploitation actions:

• Scheduled tasks and services for persistence
• LSASS dumping and registry hive extraction
• Firewall rule modifications to allow outbound traffic
• Lateral movement via RDP tunnels and SMB operations

One reported scenario describes the actor finding an idle RDP session for a Domain Administrator and using SYSTEM-level access to extract token material from memory, enabling authenticated SMB actions and eventually domain-wide escalation.

Here’s what I’ve seen repeatedly in real environments: the “first weird thing” wasn’t malware—it was identity behavior. A privileged identity doing work at the wrong time, from the wrong host, in the wrong sequence.

That’s where AI in cybersecurity earns its budget.

How AI-driven anomaly detection could catch Ink Dragon earlier

AI doesn’t replace fundamentals. It reduces the time it takes to notice fundamentals are failing.

1) Behavioral baselines for IIS and SharePoint servers

Answer first: AI can flag IIS behavior that’s technically “allowed” but operationally abnormal.

Examples of high-signal anomalies AI models can learn:

• A SharePoint front end spawning unusual child processes (for example, w3wp.exe relationships that don’t match your baseline)
• New or rare IIS modules being loaded (like a custom listener module)
• Sudden outbound connections from servers that historically had minimal egress
• Web shell-like request patterns (bursty POSTs to uncommon endpoints, odd user agents, strange referrers)

This is especially relevant in government environments where legacy SharePoint/IIS systems linger for years. The “normal” is stable—making deviations easier for models to spot.

2) Graph API and mailbox C2 detection (the new SOC blind spot)

Answer first: AI can correlate mailbox artifacts with endpoint execution to expose Graph-based C2.

What to look for:

• Unusual spikes in Graph API calls for a specific user or service principal
• Rare combinations: mailbox item creation followed by endpoint process execution patterns
• Encoded or consistently structured “documents” appearing in mailboxes that don’t normally receive automation payloads

A practical detection approach pairs:

• Identity analytics (who/what used Graph, from where, at what rate)
• Endpoint behavioral telemetry (process trees, memory injection signals, abnormal DLL loads)
• Sequence modeling (Graph activity → endpoint decryption → command execution)

3) Privileged access anomaly detection for lateral movement

Answer first: AI models are excellent at spotting “privilege choreography” that humans miss.

Ink Dragon’s reported use of disconnected admin RDP sessions and credential material in memory points to detections like:

• Domain Admin tokens present on hosts that shouldn’t hold them
• RDP sessions that remain disconnected but “active” beyond policy
• SMB writes to administrative shares from atypical source hosts
• Access to NTDS.dit or registry hives outside your standard admin workflow windows

Even a simple model that learns “who normally touches what” can cut dwell time dramatically.

Practical defensive moves you can take this quarter

You don’t need a moonshot project. You need tighter controls where Ink Dragon lives.

Harden the IIS/SharePoint attack surface

• Audit ASP.NET machine key management across IIS/SharePoint estates; eliminate shared, predictable, or stale keys
• Reduce internet exposure: front with WAF, restrict admin endpoints, and remove dead services
• Monitor for new IIS modules and configuration changes as high-priority events

Kill relay potential with network guardrails

• Apply strict egress controls for servers that don’t require outbound internet
• Alert on “server becomes proxy” behavior: high connection fan-out, unusual TLS destinations, or non-standard ports
• Segment SharePoint/IIS from domain controllers and sensitive management networks

Modernize your detection posture with AI where it actually helps

If you’re evaluating AI-powered threat detection, I’d prioritize capabilities that map directly to this campaign style:

1. Entity behavior analytics for servers, admins, and service accounts
2. Cross-domain correlation (email/Graph + endpoint + network)
3. Automated triage that can answer: Is this new? Is this rare? Is it risky given this asset’s role?
4. Containment automation for obvious bad states (new web shell + suspicious module + outbound egress spike)

The goal isn’t to auto-remediate everything. It’s to shrink the attacker’s timeline by making stealth expensive.

What to ask your SOC team after reading about Ink Dragon

If you want a fast read on readiness, these questions surface gaps quickly:

• Can we enumerate every internet-exposed IIS/SharePoint instance and its patch level in 24 hours?
• Do we alert on IIS module changes and treat them like a security event, not a sysadmin ticket?
• Can we detect Graph API abuse beyond “impossible travel” alerts—specifically command-and-control patterns?
• Do we have Domain Admin session hygiene (timeouts, logoff enforcement, credential isolation) actually enforced?
• If a server becomes a relay, can we spot and block it without waiting for threat intel?

If any answer is “not really,” you’ve got a clear action list.

Where this fits in the “AI in Cybersecurity” series

This Ink Dragon campaign is a clean example of why AI in cybersecurity isn’t about flashy dashboards—it’s about behavioral detection and faster decisions when attackers hide inside legitimate tools.

ShadowPad relays, ViewState deserialization, and Graph API-based C2 all share a theme: the attacker’s traffic can look boring. That’s precisely when machine learning detection, entity analytics, and automated correlation pull their weight.

If you’re responsible for government or critical infrastructure defense, the question worth sitting with is simple: If Ink Dragon used your servers as a relay node tomorrow, would your team notice before another victim’s traffic started flowing through your network?