SOAPwn in .NET: How AI Spots Rogue WSDL RCE Early

A critical .NET exploitation pattern is making the rounds in enterprise circles because it’s not “a bug in your app” so much as dangerous framework behavior that becomes exploitable in real products. WatchTowr Labs dubbed it SOAPwn: a way to turn WSDL imports and .NET SOAP client proxies into arbitrary file writes, NTLM credential exposure, and potentially remote code execution (RCE).

If your first reaction is “We don’t use SOAP anymore,” I get it. But many organizations still run SOAP-based integrations in ITSM, endpoint management, RMM tools, legacy line-of-business apps, and internal middleware. Those systems often sit close to privileged networks. That’s exactly why SOAPwn matters.

This post is part of our AI in Cybersecurity series, and I’m going to take a clear stance: SOAPwn is a perfect example of why signature-only defenses keep losing. The winning move in 2025 is combining sound engineering controls (input validation, egress restrictions, patching) with AI-powered threat detection that notices behavior that simply shouldn’t happen—like a SOAP client “sending” requests to file://.

What SOAPwn is (and why it keeps showing up in real products)

SOAPwn describes exploitation primitives in .NET Framework SOAP tooling—especially HTTP client proxies and dynamic proxy generation from WSDL—that can be abused when applications accept attacker-influenced WSDL or endpoint URLs.

Here’s the core idea: some SOAP client implementations can be tricked into treating a URL not as http(s)://… but as a file system handler. With the wrong inputs, a SOAP “request” can be written to disk (or to a network path) instead of being sent over HTTP.

That might sound theoretical until you translate it into attacker outcomes:

• Arbitrary file write: if the attacker controls the write path, they may overwrite existing files.
• Web shell drop / script drop: if the write lands in a web-accessible directory (ASPX/CSHTML) or a script execution path (PowerShell), you’ve got an RCE chain.
• NTLM exposure via UNC paths: writing to file://attacker-server/share/... can trigger SMB authentication attempts and leak NTLM material useful for cracking/relay.

WatchTowr Labs highlighted real affected products, including Barracuda Service Center RMM and Ivanti Endpoint Manager, with fixes released by those vendors. They also noted that Umbraco 8 remains exposed in many environments because it hit end-of-life in early 2025.

The uncomfortable part: “expected behavior” can still be a breach path

Microsoft reportedly chose not to change .NET Framework behavior, framing it as an application responsibility: don’t consume untrusted input that generates or runs code.

From a defender’s perspective, that’s not satisfying—but it is clarifying. It means the burden shifts to you:

• Identify where SOAP proxy generation happens.
• Prove whether untrusted input can influence WSDL locations or proxy endpoints.
• Put detection in place for abnormal SOAP behaviors you’ll never catch with a simple “known bad” list.

How the attack works in practice: the behaviors to hunt

Attack chains vary by product, but SOAPwn-style exploitation tends to produce distinct operational signals. That’s good news: detection doesn’t require you to predict the attacker’s exact payload.

1) From “SOAP request” to “file write”

The simplest primitive is coercing a SOAP client proxy to use a file:// URL. Instead of sending data over HTTP, the proxy interacts with a file handler.

Defender translation: a process that normally makes outbound HTTP calls suddenly starts creating or overwriting files with SOAP-shaped XML content.

Signals that are often visible in telemetry:

• A service process that rarely writes to web roots suddenly drops .aspx / .cshtml
• Unusual writes under:
  • wwwroot, application content folders
  • temp folders followed by execution
  • directories mapped to dynamic compilation or plugin loading
• File write events whose contents begin with SOAP envelope patterns (even partial)

2) UNC path coercion and NTLM capture

A more subtle path is providing a UNC-style location such as file://attacker.server/poc/poc, causing a write to an SMB share controlled by the attacker. That can force Windows authentication flows and expose NTLM challenges.

Defender translation: a server that shouldn’t talk SMB to the internet is suddenly authenticating outward.

Signals:

• Outbound SMB (TCP/445) from application servers
• Authentication attempts to unknown hosts
• Spikes in NTLM events correlated with unusual application activity

3) Rogue WSDL imports and proxy generation leading to RCE

The higher-impact vector described involves generating HTTP client proxies from attacker-controlled WSDL using classes like ServiceDescriptionImporter, where URL validation is insufficient.

Defender translation: your application fetches a WSDL from an unexpected location, generates code or a proxy, then starts behaving like it’s running attacker logic.

Signals:

• WSDL retrieval from new domains/IPs
• New assemblies or dynamic compilation artifacts on disk
• Process spawning patterns that don’t belong (web service spawning powershell.exe is a classic)

Why AI-powered threat detection fits this problem (and where it doesn’t)

SOAPwn is messy for traditional defenses because:

• It can be “valid” from the framework’s perspective
• It’s often context-dependent (paths, permissions, deployment model)
• The payload can be a bland XML write that becomes catastrophic only because of where it lands

This is where AI in cybersecurity actually earns its keep—when it focuses on behavioral anomaly detection and correlation, not “magic guessing.”

AI wins when you need correlation across weak signals

A single event like “file write happened” is noisy. Even “SOAP request happened” is normal. The value comes from stitching together:

1. A SOAP proxy making an unusual request to a never-before-seen endpoint
2. A file:// scheme or an SMB path showing up where HTTP is expected
3. A file write to a sensitive directory
4. A follow-on execution signal (IIS loading a new ASPX, PowerShell script block logs, abnormal module loads)

An ML model or modern detection engine can score the sequence and context:

• Is this server historically an SMB client? If not, why now?
• Does this app typically fetch WSDL from internal registries only?
• Are we seeing a new child process tree from a web service?

That kind of “many weak signals become one strong alert” approach is exactly what SOAPwn demands.

Where AI doesn’t help: if you haven’t instrumented the basics

If you’re missing endpoint telemetry, outbound network visibility, and basic Windows logging, “AI” won’t save you. The fastest path to better outcomes is still:

• Strong logging (process, network, file, auth)
• Sensible baselines
• Controls that make exploitation harder even if detection fails

Defensive playbook: practical steps you can take this week

If you run .NET Framework enterprise applications (or products that embed them), here’s a pragmatic order of operations.

1) Inventory where SOAP is still alive

You don’t need a six-month program. Start with a 2–3 day sprint:

• Search repos for: ServiceDescriptionImporter, Add Service Reference, svcutil, HttpWebClientProtocol, Web Services namespaces
• Identify third-party tools that include SOAP integrations (RMM, EPM, ITSM connectors)
• Map the systems that accept a “WSDL URL” or “service endpoint URL” from users or configs

If you find any place where an external party can influence the WSDL location or SOAP endpoint, treat it as high risk.

2) Patch vendor products that already shipped fixes

Two real-world fixes were called out publicly:

• Barracuda Service Center RMM fixed in 2025.1.1 (tracked as CVE-2025-34392, CVSS 9.8)
• Ivanti Endpoint Manager fixed in 2024 SU4 SR1 (tracked as CVE-2025-13659, CVSS 8.8)

If those products exist anywhere in your estate, patching them is the fastest risk reduction you’ll get.

3) Stop treating URLs as “strings”

Most companies get this wrong: they validate “it looks like a URL” and call it done.

For SOAP endpoints and WSDL locations, enforce:

• Allow-list schemes: only https:// (and maybe http:// internally if you must)
• Block file:// entirely
• Block UNC patterns and SMB paths
• Allow-list hosts/domains where WSDL can be fetched from

Also: don’t generate proxies dynamically at runtime from untrusted sources. If you need dynamic behavior, do it with an internal registry and strict controls.

4) Put guardrails on outbound traffic (this kills entire exploit branches)

Network egress controls are boring, and they work.

• Block outbound SMB (TCP/445) from servers that don’t explicitly need it
• Restrict outbound HTTP(S) from application servers to known dependencies
• Monitor and alert on first-seen destinations for sensitive tiers

SOAPwn’s UNC/NTLM path becomes far less useful when SMB egress is dead on arrival.

5) Add AI-assisted detections that focus on “impossible” sequences

If you’re building detections (or working with an MDR/SOC), prioritize rules and ML models that flag combinations like:

• SOAP client activity + file:// usage
• WSDL download from new/rare external destinations
• Unexpected file writes into web roots by service identities
• Any IIS worker process or app service spawning:
  • powershell.exe
  • cmd.exe
  • compilers/dynamic build tools
• Outbound SMB authentication attempts from web/app tiers

A solid one-liner for your detection strategy: “Alert when integration code touches the filesystem or SMB.”

“People also ask” style answers your team will want

Does this affect .NET (modern) or just .NET Framework?

The research centers on .NET Framework web services tooling commonly found in legacy enterprise applications. Many organizations still run it indirectly via vendor products and long-lived internal apps.

If Microsoft won’t fix it, what’s the real mitigation?

Treat it as a secure design requirement: never allow untrusted input to control WSDL imports or SOAP proxy endpoints, and block dangerous URL schemes. Pair that with egress controls and behavioral detection.

How do we know we’re exposed if we don’t have source code?

Start from runtime signals:

• Does the product allow configuring a WSDL URL?
• Can you observe outbound WSDL fetches?
• Do you see SOAP proxy assemblies or dynamic compilation artifacts?

Even without code, you can test exposure in a staging environment by validating that only allow-listed https:// endpoints are accepted.

Your next step: treat SOAPwn as a detection drill, not just a patch

SOAPwn isn’t scary because SOAP is old. It’s scary because enterprise systems trust integrations—and attackers love hiding inside “normal” workflows.

If you want a practical way to advance your AI in cybersecurity program, use SOAPwn as a tabletop exercise:

• Can you detect a SOAP proxy attempting file://?
• Can you detect outbound SMB from an app server?
• Can you correlate WSDL fetch → file write → execution into a single incident?

That’s the bar for 2025: fast, behavior-based detection that doesn’t depend on a specific payload.

What’s one legacy integration in your environment that nobody wants to touch—but the business can’t live without? That’s where attackers will aim next.