Stop SOAP RCE: AI Defense for .NET WSDL Attacks

Most companies still have “quiet critical” systems sitting in the corner: .NET Framework apps talking SOAP to third parties, vendors, and internal services. They rarely get attention—until a researcher shows how a single bad assumption can turn a routine integration into arbitrary file writes, NTLM credential exposure, and remote code execution (RCE).

That’s the story behind SOAPwn: a set of exploitation primitives in .NET Framework SOAP client behavior where attacker-influenced WSDL imports and HTTP client proxies can be pushed into doing things they were never meant to do—like writing SOAP requests to the file system or a remote SMB share. The uncomfortable part isn’t just the technique. It’s that the behavior can look “valid” from the application’s point of view.

This post is part of our AI in Cybersecurity series, so I’ll take a stance: legacy API attack paths are exactly where AI-driven detection earns its keep. Not by waving a magic wand, but by catching the odd combinations (WSDL from new origins, file scheme URLs, unexpected proxy generation, unusual outbound SMB) that rule-based controls often miss.

What SOAPwn changes about .NET SOAP risk

Answer first: SOAPwn matters because it turns “data you consume” (WSDL and SOAP payloads) into “code and files you create,” which collapses the boundary between integration logic and execution paths.

WatchTowr Labs presented SOAPwn as an “invalid cast vulnerability” class of issue impacting multiple enterprise products built on .NET Framework foundations, including Barracuda Service Center RMM, Ivanti Endpoint Manager, and Umbraco 8 (with Umbraco 8 made harder by its end-of-life status).

Two ideas are doing most of the damage:

1. HTTP client proxies can be coerced into using file handlers rather than HTTP handlers.
2. WSDL-driven proxy generation can accept attacker-controlled URLs in ways that lead to file writes and eventually RCE.

If your organization still runs .NET Framework SOAP clients (not .NET “modern” services), assume you have at least one workflow where a WSDL location, import, or endpoint can be influenced indirectly—through configuration, user input, a vendor setting, a database field, or a “helpful” admin UI.

The exploit primitives in plain language

Answer first: The core primitive is forcing a SOAP proxy to treat a URL as a file path (file://...), producing arbitrary file writes that can become a web shell drop.

In practice, this can show up in a few ways:

• A SOAP client proxy is created dynamically and given a URL that’s assumed to be HTTP/HTTPS.
• The proxy accepts a different scheme (like file://) and writes the SOAP request to disk.
• Because the attacker can influence the path, they can overwrite existing files (worst case) or place new files where the web server can execute them.

Once arbitrary file write is on the table, RCE often becomes an operations problem, not a research problem. If the target is IIS and the app pool identity can write into a web-accessible path, dropping something like an ASPX or script payload can be enough.

The under-discussed credential angle: NTLM via SMB write

Answer first: SOAPwn-style behaviors can also enable NTLM challenge capture/relay by pushing SOAP output to attacker-controlled SMB paths.

A common hypothetical path described by researchers looks like this:

• The attacker supplies a UNC-style file://attacker.server/... input.
• The application writes a SOAP request to an SMB share.
• Windows authentication negotiation happens and the attacker can capture an NTLM challenge and attempt to crack it or relay it.

Even if you’ve “blocked inbound 445” at the perimeter, outbound SMB from servers is still surprisingly common in internal networks—especially in older environments where file shares are everywhere.

Who’s exposed (and why “EoL” is a security event)

Answer first: You’re exposed if you run .NET Framework SOAP clients that generate proxies from WSDL dynamically or accept endpoint/WSDL URLs from sources you don’t fully control.

The research called out specific products and fixes:

• Barracuda Service Center RMM addressed related risk in version 2025.1.1 (tracked as CVE-2025-34392, CVSS 9.8).
• Ivanti Endpoint Manager addressed related risk in 2024 SU4 SR1 (tracked as CVE-2025-13659, CVSS 8.8).
• Umbraco 8 remains a concern because it’s end-of-life (EoL) as of February 2025.

Here’s the stance I’d encourage: EoL isn’t a licensing milestone; it’s a control failure you can measure. The moment a platform hits EoL, your security posture shifts from “patchable risk” to “compensating-controls-only risk.” That matters a lot for integration-heavy apps where you can’t easily swap components.

Why Microsoft saying “don’t do that” isn’t comforting

Answer first: “Don’t consume untrusted input that can generate and run code” is correct advice, but it doesn’t match how enterprise software is actually operated.

In real environments:

• WSDL URLs live in config, databases, and admin screens.
• Integrations are updated by ops teams under pressure.
• Vendors ship SOAP features that assume a “trusted network.”
• Attackers don’t need direct user input—just one path to influence settings.

So the practical question becomes: How do you detect and stop exploitation when prevention is imperfect? That’s where AI-driven security monitoring can be genuinely useful.

How AI detection would spot SOAPwn-style exploitation earlier

Answer first: AI anomaly detection is effective here because SOAPwn depends on unusual combinations of “valid” events—events that don’t look malicious in isolation.

Traditional controls tend to key on known-bad payloads or signatures. SOAPwn’s strength is that it abuses expected framework behavior. So instead of hunting for one magic string, you want systems that can learn baselines and flag behavioral outliers.

1) AI anomaly detection on “WSDL retrieval and proxy generation”

Answer first: If your server almost never fetches new WSDLs at runtime, any new WSDL origin is suspicious—AI will catch that drift fast.

Patterns worth modeling:

• New WSDL domains or IPs contacted by app servers
• Spikes in WSDL imports (<wsdl:import>) per hour/day
• WSDL fetches occurring outside change windows
• WSDL sizes and structures that deviate from normal (sudden complexity can be a signal)

This is where AI helps with the messy reality: environments differ, and static allowlists become stale. A good model can say, “This app server has contacted 3 WSDL hosts for 18 months; today it contacted a 4th, and it’s never been seen across the fleet.” That’s actionable.

2) AI-driven detection for “scheme abuse” (file://) and path anomalies

Answer first: file:// in a SOAP endpoint context is almost always wrong, and AI can highlight it even when it’s buried in serialized configs, logs, or telemetry.

Controls you want (with or without AI) include strict URI validation, but detection matters because:

• Validation gets missed in one micro-feature.
• A vendor component might accept unexpected schemes.
• The dangerous input might not appear in a neat HTTP log.

AI models that analyze configuration changes, application logs, and runtime telemetry can surface:

• Endpoint values containing file://
• Sudden appearance of UNC path patterns
• File write activity correlated with SOAP calls

3) AI correlation across network + identity + endpoint signals

Answer first: SOAPwn exploitation often spans layers—HTTP(S) to retrieve WSDL, file I/O to write content, and SMB/NTLM side effects—AI correlation is built for that.

A high-confidence detection story looks like this:

1. App server makes outbound request to a new WSDL host.
2. Shortly after, the server initiates outbound SMB to an unusual destination.
3. The same process identity shows abnormal file writes in a web root or temp compilation directory.
4. A new script or web-executable file appears, followed by suspicious child processes.

Any one of those might be “noise.” Together, they’re a narrative.

Practical mitigations you can deploy this week

Answer first: You reduce SOAPwn risk by (1) removing untrusted WSDL/proxy generation paths, (2) blocking the dangerous side effects (file/SMB), and (3) adding detection that assumes one control will fail.

Here’s a pragmatic checklist that doesn’t require rewriting every legacy app in December.

Application and configuration hardening

• Stop dynamic proxy generation from untrusted WSDL wherever possible. If a feature requires runtime WSDL consumption, treat it like code loading.
• Validate URI schemes for SOAP endpoints and WSDL locations: allow only https:// (and maybe http:// internally if you must), explicitly deny file:// and ambiguous formats.
• Pin WSDL origins: store known-good WSDLs internally, version them, and require change approval.
• Run with least privilege: app pool identities shouldn’t have write access to web roots. This alone can turn “file write” into a contained incident.

Network controls that blunt the worst outcomes

• Block outbound SMB (445) from application servers unless there’s a documented need. If there is a need, scope it tightly to known file servers.
• Monitor for NTLM authentication attempts from servers that shouldn’t be authenticating to random hosts.
• Egress filtering by service role: SOAP integration servers don’t need broad outbound access.

Detection and response (where AI belongs)

• Baseline and alert on new WSDL sources contacted by production servers.
• Alert on rare URI schemes appearing in configuration changes.
• Monitor for suspicious file writes to:
  • web application directories
  • temp compilation paths
  • script-executable locations
• Correlate with process tree anomalies (for example, web worker spawning PowerShell).

If you already have an AI-driven SOC workflow, route these detections into a playbook that does three things automatically: isolate the host (or at least restrict egress), snapshot volatile data, and open a ticket that includes the correlated timeline.

What this teaches about securing legacy APIs with AI

Answer first: SOAPwn is a reminder that “legacy” doesn’t mean “low value”—it means “high trust,” and attackers love high-trust pathways.

SOAP-based APIs and .NET Framework apps persist because they run payroll, device management, customer onboarding, and a hundred other unglamorous processes that keep businesses alive. Replacing them takes quarters, not days. Meanwhile, attackers only need one overlooked integration point.

AI in cybersecurity helps most when defenders stop treating it like an autopilot and start treating it like a pattern amplifier:

• It finds behavior that doesn’t match the environment’s normal rhythm.
• It correlates weak signals across layers into a strong story.
• It helps prioritize patching and compensating controls by showing where exploitation paths are actually forming.

If SOAPwn made you uneasy, that’s useful. Take that discomfort and turn it into inventory: where do you still generate SOAP proxies, where do WSDL URLs come from, and which servers can still talk SMB outbound?

The next question is the one that matters for 2026 planning: if a “valid behavior” exploit path appears in another legacy framework next month, will your monitoring notice the story—or just the individual events?