Stop SOAPwn: AI Detection for .NET WSDL RCE Attacks

A single “helpful” feature in legacy enterprise stacks—auto-generating SOAP client proxies from WSDL—can become an attacker’s write-anywhere primitive. That’s what the research community has been warning about with SOAPwn, a .NET Framework exploitation path that turns rogue WSDL and HTTP client proxies into arbitrary file writes and, in many deployments, remote code execution (RCE).

What makes SOAPwn uncomfortable isn’t just the mechanics. It’s the real-world shape of the blast radius: RMM tooling, endpoint management platforms, and CMS deployments—exactly the kind of “always-on, highly trusted” systems that attackers love. If your environment still runs .NET Framework-era web services (and many do), you’re not debating whether SOAP is old. You’re deciding whether you can detect abnormal service interactions fast enough to stop a web shell from landing.

This post is part of our AI in Cybersecurity series, so I’m going to take a stance: patching and configuration are necessary but not sufficient for SOAPwn-style abuse. You also need AI-driven threat detection and anomaly analysis that can spot suspicious WSDL consumption, unexpected file writes, and identity leakage patterns—because traditional signature-only rules often show up after the first incident.

What SOAPwn actually enables (and why defenders should care)

SOAPwn enables two core exploitation primitives in .NET Framework SOAP clients that are common inside long-lived enterprise applications:

1. Arbitrary file write via URL scheme abuse in .NET Framework HTTP client proxies.
2. RCE via attacker-controlled WSDL when applications generate SOAP proxies dynamically (notably using classes such as ServiceDescriptionImporter) and fail to validate the generated proxy’s target URL and behaviors.

The defender’s translation is simple: when untrusted input can influence how a SOAP client proxy is created or where it sends/writes data, you’ve created a code-and-file boundary break.

The “file://” problem: when a request becomes a file write

One SOAPwn technique abuses the fact that some .NET Framework proxy behavior can be manipulated into using file system handlers. If an attacker can feed a crafted URL like file://... into a vulnerable SOAP client proxy flow, the “request” can end up written to disk rather than sent over HTTP.

Why that matters:

• Write-anywhere is rarely “just” a write-anywhere. In web apps it often becomes write-to-webroot, which becomes web shell, which becomes RCE.
• Because the attacker controls the full path, this can include overwriting existing files (the kind of thing that turns an annoying bug into an incident).

The UNC twist: identity leakage via SMB and NTLM

A second-order impact highlighted by researchers: if the attacker can coerce a SOAP proxy into writing to a UNC path (for example, file://attacker.server/share/...), the target may attempt SMB access and expose an NTLM challenge/response.

That opens the door to:

• Credential capture workflows
• NTLM relaying opportunities (depending on network controls)

This is one of those patterns AI tends to catch well when it’s looking at behavior sequences, not isolated alerts: “web app process → outbound SMB attempt → authentication handshake to unusual host” is rarely normal in production.

Who’s exposed: why “legacy” .NET still shows up in 2025 incidents

SOAP is old. The problem is that enterprise architecture has a long memory.

Systems often still running .NET Framework SOAP components include:

• Remote Monitoring and Management (RMM) tools
• Endpoint management and IT service management integrations
• Line-of-business apps with internal service-to-service SOAP calls
• CMS and plugin ecosystems that never fully migrated

The research community specifically called out impacts in products like Barracuda Service Center RMM and Ivanti Endpoint Manager, both of which shipped fixes. A separate case—Umbraco 8—is particularly instructive: it reached end-of-life in early 2025, meaning many organizations are effectively forced into compensating controls.

That EoL reality is why “just patch” isn’t a complete answer. You can reduce the attack surface, but you also need detection that assumes exploitation attempts will happen.

Attack paths defenders should model (and monitor)

SOAPwn isn’t one “payload.” It’s a set of primitives that attackers can chain. Here are three practical attack paths worth threat modeling.

1) Rogue WSDL to proxy generation to web shell

Answer first: If an application generates SOAP proxies from an attacker-controlled WSDL, the attacker can steer the proxy behavior and often reach file write → web shell → RCE.

A common pattern looks like this:

1. Application accepts a WSDL URL (directly or indirectly).
2. It generates a client proxy dynamically.
3. The proxy is used in a context where request bodies or outputs can land on disk.
4. Attacker drops an ASPX (or similar) payload and executes it via HTTP.

Where AI helps: correlating “new WSDL source” + “new generated artifacts” + “unexpected write path” + “new web-executable file created” into one high-confidence incident.

2) File write without web shell: overwrites and staged payloads

Answer first: Even if the webroot isn’t writable, arbitrary file write can still enable config tampering, scheduled task abuse, or planting scripts for later execution.

Examples defenders see in practice:

• Overwriting application configs to enable debug endpoints
• Dropping a script into a watched directory (CI/CD, import jobs, plugins)
• Writing to temp locations that later get executed by another component

AI-driven anomaly detection is useful here because the “payload” may not match a known signature. The weirdness is in where and how the file is written.

3) UNC coercion for NTLM capture and lateral movement

Answer first: If SOAP requests can be coerced into UNC writes, you can get authentication attempts to attacker infrastructure and pivot into credential attacks.

Signals to watch:

• Web app pools or service accounts initiating outbound SMB
• Spikes in NTLM auth failures/successes tied to unusual destinations
• New DNS lookups for non-corporate file hosts

This is a good place to be opinionated: if your web tier can talk SMB outbound, you’re making attackers’ lives easier.

Controls that actually reduce risk (without rewriting everything)

The strongest mitigation is to remove untrusted influence over proxy generation and URL handling. But most teams need a layered plan they can implement during a normal change window.

Baseline hardening for .NET Framework SOAP clients

Answer first: Cut off the dangerous inputs first—untrusted WSDLs and non-HTTP URL schemes.

Practical steps:

• Never consume untrusted WSDL in production flows. If a WSDL must be dynamic, enforce strict allowlists.
• Block non-HTTP(S) URL schemes (file://, ftp://, and friends) at the point where URLs enter the system.
• Validate and normalize paths and URIs before they reach any proxy/client creation logic.
• Run services under least-privilege identities so “arbitrary write” can’t hit sensitive locations.

Network guardrails that stop the NTLM/SMB side effects

Answer first: Most organizations can prevent UNC-based abuse quickly by restricting outbound SMB and tightening NTLM.

• Block outbound SMB (445) from web and app tiers by default.
• Reduce or disable NTLM where possible; otherwise enforce strong NTLM restrictions and monitoring.
• Require proxy egress controls so unusual destinations are visible and controllable.

Monitoring that doesn’t rely on perfect signatures

Answer first: SOAPwn detection is more reliable when you monitor behaviors and sequences, not just “known bad strings.”

High-signal detections to implement:

• WSDL fetch anomalies: new WSDL domains, unusual user agents, unusual frequency, or WSDL retrieval from internal-only systems that never did it before.
• Unexpected file writes by web processes: especially to web roots, plugin directories, temp-to-webroot patterns, or overwrite attempts.
• Execution after write: a new .aspx, .cshtml, or script file created followed by immediate HTTP requests.
• Outbound SMB from servers: any attempt is suspicious in many environments.

Where AI-driven threat detection fits (and where it doesn’t)

AI can’t patch your servers. It can, however, spot the early indicators that humans and static rules miss, especially in messy enterprise environments.

What AI is good at for SOAPwn-style attacks

Answer first: AI shines when the attacker’s advantage is “this behavior looks normal in isolation.”

In practice, AI-driven security analytics can:

• Build a baseline of normal SOAP/WSDL behavior (who calls what service, from where, at what times).
• Detect novel WSDL sources and suspicious import chains.
• Correlate app telemetry with endpoint signals: “W3WP wrote a new file” + “IIS served it” + “PowerShell spawned” is a clean story.
• Reduce alert fatigue by prioritizing incidents with multi-signal confirmation.

What AI won’t save you from

Answer first: If you allow untrusted dynamic code generation and give the process broad filesystem permissions, you’ve created a high-risk design.

AI is a backstop, not permission to ignore fundamentals. You still need:

• strict input validation
• sane egress policies
• least privilege
• deprecation plans for EoL platforms

A practical “next 7 days” checklist for security teams

Answer first: You can make measurable SOAPwn risk reduction in a week by combining inventory, guardrails, and targeted detections.

1. Inventory where .NET Framework SOAP clients exist (code search for proxy generation, WSDL handling, ServiceDescriptionImporter, legacy web service stacks).
2. Identify any endpoints that accept a WSDL URL or remote service URL from users, tenants, or upstream systems.
3. Add allowlists for service endpoints and WSDL sources; block file:// and UNC patterns at ingestion.
4. Block outbound SMB from web/app tiers (or at least alert aggressively).
5. Deploy detections for suspicious file writes and “write-then-serve” sequences in IIS.
6. Hunt for historical indicators: unusual WSDL fetches, odd .aspx creations, or web-worker initiated network auth attempts.
7. Create an EoL plan for any unsupported platforms (if you can’t patch, you must compensate).

One-liner worth sharing: If your app can generate SOAP proxies from untrusted WSDL, treat it like code execution—because attackers will.

What this means for the AI in Cybersecurity series

SOAPwn is a clean example of why AI-driven threat detection matters in enterprise security: the attack blends application behavior, file activity, and network authentication side effects. A single rule rarely captures that whole chain. Correlation does.

If you’re responsible for .NET application security or SOC coverage, take this as a prompt to pressure-test your visibility: Could you detect a rogue WSDL import, an unexpected file write, and a follow-on web shell request within minutes—not days? If the honest answer is “probably not,” your best move is to tighten the inputs and add AI-assisted anomaly detection where legacy patterns still exist.