Detect .NET SOAPwn Attacks Before Rogue WSDL Hits

Most companies treat “old SOAP stuff” as background noise—until it’s the entry point for arbitrary file writes and remote code execution (RCE).

WatchTowr Labs’ research on a .NET Framework behavior they nicknamed SOAPwn is a good example of how enterprise risk actually shows up: not as a flashy zero-day in a new library, but as expected framework behavior that becomes exploitable when applications accept untrusted WSDL or build HTTP client proxies dynamically.

This post is part of our AI in Cybersecurity series, and I’m going to take a stance: if you’re still relying on “patch fast” and a few static rules to protect legacy web services, you’re leaving a gap. AI-driven threat detection and automated response are exactly what you need for this class of exploit—because the signals are subtle, spread across app logs, file writes, and network authentication flows.

What SOAPwn is—and why it keeps showing up in enterprises

SOAPwn is a practical exploitation path where .NET Framework SOAP client behaviors can be abused to pivot from “normal integration traffic” into file system writes and eventually code execution.

Here’s the core issue: some .NET Framework SOAP proxy flows can be manipulated so that SOAP requests are written to a file path instead of being sent over HTTP. If an attacker can influence the URL/path used by the proxy (directly or via a rogue WSDL import), they can steer the write location.

Two details make this ugly in real environments:

• The attacker can control the full write path, which means overwriting is on the table, not just “create new file.”
• Many organizations still run SOAP-based integrations inside “business-critical but unloved” products—RMM platforms, endpoint management suites, CMS plugins, and internal line-of-business tools.

WatchTowr called out exposure in products such as Barracuda Service Center RMM, Ivanti Endpoint Manager (EPM), and Umbraco 8. Barracuda and Ivanti shipped fixes for their specific products, but the broader lesson is bigger: this is a pattern risk across .NET Framework apps that dynamically consume WSDL or generate proxies.

The real risk: “behavior” vulnerabilities don’t get patched away

Microsoft’s position, per the disclosed research, is essentially: this is application behavior; don’t consume untrusted input that generates or runs code.

You can disagree (I do), but operationally it means one thing: you may not get a platform-level fix, so you need compensating controls.

That’s where modern detection and response—especially AI-assisted—matters.

How attackers weaponize rogue WSDL into file writes and RCE

Attackers don’t need magic. They need a place where your app:

1. Accepts a URL or reference to a WSDL (or imports one)
2. Generates/uses a SOAP client proxy from it
3. Sends SOAP requests in a way that can be coerced into writing to disk or a remote file handler

Technique 1: File handler abuse for arbitrary file write

A vulnerable flow can be tricked by supplying a file:// style value instead of an expected http(s):// endpoint. If the SOAP proxy accepts that input, the “request” can be redirected into a file write.

Once an attacker can write files, RCE becomes a deployment problem:

• Write an .aspx web shell into a web root
• Write a .cshtml payload where Razor views are executed
• Write a PowerShell script into a location that a scheduled task or management agent will execute

The exact payload depends on the application and filesystem permissions, but the primitive (write-anywhere) is what matters.

Technique 2: UNC paths and NTLM capture/relay

A second-order impact is using a UNC path to push the write over SMB to an attacker-controlled share, which can trigger NTLM authentication. That can enable NTLM challenge capture and potentially credential cracking or relaying, depending on your environment controls.

This is why SOAPwn shouldn’t be filed as “just another web bug.” It crosses boundaries:

• Application layer (WSDL/proxy generation)
• Host layer (file writes)
• Identity layer (NTLM auth flows)

That multi-surface footprint is exactly why simple signature-based detection often misses it.

Where AI-driven cybersecurity helps (and where it doesn’t)

AI won’t “patch .NET Framework for you.” What it can do is spot the early indicators you’d otherwise miss, correlate them across systems, and kick off response steps before you’re dealing with web shells.

AI is strongest when the exploit chain spans multiple data sources

SOAPwn-style abuse leaves breadcrumbs in different places:

• Web logs showing unusual WSDL URLs, imports, or proxy endpoints
• Endpoint telemetry showing unexpected file creation/modification paths
• Authentication logs showing NTLM attempts to untrusted hosts
• Network telemetry showing SMB traffic that doesn’t match normal patterns

Humans can connect those dots—after the incident. AI-assisted detection can connect them in minutes.

Practical detections that work for rogue WSDL and proxy abuse

If you’re building detections, focus on behaviors rather than exploit-specific strings.

Network and application signals

• Outbound requests to new or rare WSDL locations (especially internet-hosted) from servers that usually only talk to internal services
• SOAP client traffic where the destination scheme changes (e.g., endpoint values resembling file:// or other non-HTTP schemes)
• A spike in WSDL imports, schema downloads, or “service discovery” activity outside normal deployment windows

Host and filesystem signals

• Creation or modification of web-executable files: .aspx, .ashx, .cshtml, .ps1, or suspicious DLL drops
• File writes into web roots, temp folders used by web services, or application directories that typically don’t change at runtime
• Overwrite patterns (same filename rewritten multiple times within a short period)

Identity signals

• NTLM authentication attempts to non-standard SMB targets
• Server workloads initiating SMB sessions they don’t normally initiate

AI-based anomaly detection earns its keep here because it can baseline “normal” per app server and flag the weird stuff that rules don’t anticipate.

What AI won’t solve (so you still need engineering controls)

AI can reduce time-to-detect and time-to-contain, but it can’t replace:

• Input trust boundaries (don’t accept arbitrary WSDL URLs from users or low-trust systems)
• Protocol allowlists (only allow https:// for endpoints; block file:// and UNC patterns)
• Least privilege (web services shouldn’t be able to write to web roots)
• Egress control (servers shouldn’t talk SMB to the internet, period)

If your environment can’t enforce these, you’re betting the company on detection alone.

A defensive playbook: what to do this week

If you’re responsible for .NET Framework apps (or products built on it), you want a fast triage plan that doesn’t require rewriting half your stack.

1) Inventory where WSDL is consumed dynamically

Answer first: Find every place WSDL can be supplied or imported dynamically, and treat it as untrusted input.

Start with:

• Integrations that “configure” a SOAP endpoint via admin UI
• RMM/management tooling plugins
• Legacy middleware that generates proxies on demand
• Any code using classes like ServiceDescriptionImporter (or similar proxy generation patterns)

If you can’t locate this quickly, AI can help in a very practical way: use code-aware search and summarization to map “WSDL ingestion paths” across repos and configs. That’s not hype—it’s speed.

2) Put guardrails on destinations and protocols

Answer first: If the endpoint isn’t https:// (or your explicit internal http://), block it.

Concrete guardrails:

• Validate and normalize endpoint URLs
• Enforce allowlists (hostnames, certificates, or service discovery IDs)
• Explicitly reject:
  • file://...
  • UNC patterns
  • loopback and link-local where not required

3) Reduce file write blast radius

Answer first: Assume a file-write primitive exists somewhere and make it hard to turn into RCE.

Practical steps:

• Ensure service identities can’t write to web roots
• Separate upload directories from executable directories
• Disable script execution where possible (especially for upload/temp paths)
• Monitor for writes of executable web content (ASPX/CSHTML) on servers that shouldn’t change often

4) Add AI-assisted correlation rules for the full chain

Answer first: You catch SOAPwn faster by correlating “odd WSDL” + “odd file write” + “odd NTLM/SMB” within the same window.

If you have an AI-enabled SIEM/XDR/SOAR stack, tune it to:

• Create an incident when an app server:
  1. Fetches a rare external WSDL or schema
  2. Then writes a web-executable file or overwrites config
  3. Then initiates NTLM/SMB auth to an unusual host

Even if each event alone is “medium,” the combination is high-confidence.

5) Patch the vendor apps you can—and isolate the ones you can’t

Answer first: Patch product-level fixes immediately, but treat unpatchable/EoL apps as hostile terrain.

In the disclosed cases:

• Barracuda Service Center RMM fixed a critical issue (CVSS reported as 9.8) in version 2025.1.1.
• Ivanti EPM fixed a high/critical issue (CVSS reported as 8.8) in version 2024 SU4 SR1.
• Umbraco 8 reached end-of-life in early 2025, which means many deployments won’t receive fixes.

For EoL systems, your “patch” is isolation:

• Put them behind strict reverse proxies
• Limit outbound traffic (especially SMB)
• Increase monitoring sensitivity
• Plan migration with a deadline, not “someday”

The lead-generation reality: executives care about outcomes, not SOAP

If you need to justify investment (new monitoring, AI SOC tooling, managed detection, etc.), frame SOAPwn in outcomes:

• RCE risk on systems tied to endpoint management or remote operations is business-impactful fast.
• Arbitrary file writes can become persistence, data tampering, or credential theft.
• NTLM capture/relay paths create lateral movement opportunities that don’t look like “malware” at first.

My rule: if a bug chain can plausibly turn into a web shell plus credential exposure, it deserves the same urgency as an internet-facing auth bypass.

What to do next—and the question to ask your team

SOAPwn is a reminder that enterprise security isn’t only about new CVEs. It’s also about the dangerous edge where “supported behavior” meets “untrusted input.” That edge is where attackers live.

If you want one concrete next step from this AI in Cybersecurity series: use AI-driven anomaly detection to baseline what your SOAP clients and app servers normally do, then alert aggressively on deviations that match the exploit chain—especially rare WSDL fetches, suspicious file writes, and unexpected NTLM/SMB.

What would you rather explain in January: a blocked WSDL import that triggered a false positive, or a “legacy integration” that quietly dropped an ASPX shell during the holiday change-freeze window?