AI Detection for .NET SOAPwn WSDL RCE Attacks

Most companies get this wrong: they treat “legacy” SOAP integrations as boring plumbing, then act surprised when the plumbing turns into an attacker’s express lane.

The newly disclosed SOAPwn research shows how some .NET Framework SOAP client patterns can be pushed into arbitrary file writes and even remote code execution (RCE) when applications ingest attacker-controlled WSDL or allow untrusted inputs to influence SOAP proxy behavior. It’s not just an academic edge case—WatchTowr Labs highlighted real enterprise products impacted (including versions of Barracuda Service Center RMM and Ivanti Endpoint Manager), and the pattern is broad because .NET SOAP client code is broad.

This post is part of our AI in Cybersecurity series, so I’m going to take a stance: patching is necessary, but it’s not enough for vulnerability classes like this. You also need AI-driven monitoring that spots the weirdness before a web shell lands on disk or an NTLM relay turns into domain-wide pain.

What SOAPwn really is (and why it keeps showing up)

SOAPwn is a set of exploitation primitives in .NET Framework SOAP client usage that can turn “make a request” into “write a file” or “execute code.” The detail that matters operationally is not the cleverness of the exploit—it’s the shape of the risk: SOAP clients that accept or derive endpoints and WSDL locations from untrusted inputs.

Two behaviors highlighted in the research are especially relevant:

• HTTP client proxy misuse leading to file writes: If a SOAP proxy can be coerced into using a file:// URL (or similar handler), the “request” can end up written to the filesystem instead of being sent over HTTP.
• WSDL-to-proxy generation without URL validation: Apps that generate proxies from WSDL using .NET classes like ServiceDescriptionImporter may produce a proxy that happily points wherever the attacker wants—creating a pipeline from “rogue WSDL” to “write a payload to disk.”

Why does this keep showing up in 2025? Because SOAP sits in the long tail of enterprise architecture:

• Critical “glue” apps and admin tooling often still rely on SOAP.
• Teams rarely revisit SOAP client code unless something breaks.
• Security reviews focus on inbound HTTP endpoints, while SOAP client behavior (outbound + generated code) gets less scrutiny.

If you’re thinking “we don’t expose SOAP externally,” remember: attackers don’t need a public SOAP service. They need any path where untrusted input can influence a SOAP proxy target, WSDL import, or endpoint value.

How the attack chain plays out in the real world

The common pattern is simple: untrusted input influences a SOAP client’s URL or WSDL import, and .NET does exactly what it was told. From there, the attacker’s goal is either (1) plant something on disk or (2) trick the system into authenticating to them.

Arbitrary file write → web shell or script drop

If the attacker can make the SOAP proxy write to a path they control, they can often turn that into code execution. The research describes dropping artifacts such as ASPX web shells, CSHTML web shells, or PowerShell scripts.

This is why defenders should treat “arbitrary file write” findings as RCE-adjacent in web environments. If the write lands in a directory served or executed by the application (or in a place that a scheduled task reads), the line between file write and RCE gets thin.

UNC paths and NTLM capture/relay

If the SOAP write can be directed to a UNC path (SMB share), Windows authentication can get pulled into the story. A forced authentication to an attacker-controlled SMB server can expose an NTLM challenge/response suitable for cracking or relaying, depending on environment controls.

Operationally, this matters because:

• The “exploit” may look like a benign outbound SMB attempt.
• The impact may jump from a single app server to credential theft and lateral movement.

Why “Microsoft won’t fix it” changes your posture

Microsoft’s reported position—this being “application behavior” and that users shouldn’t consume untrusted input that generates and runs code—means you should plan as if the framework behavior will remain.

So your defense has to be layered:

1. Fix the apps you can (vendor updates, configuration hardening, code changes).
2. Detect the class (AI + rules + telemetry) because you won’t patch every internal SOAP integration before someone tries this.

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

AI helps most when the attack is a chain of “small weird events” that traditional alerting treats as noise. SOAPwn-style exploitation often produces exactly that: odd URL schemes, unusual file writes, and atypical outbound authentication.

Here’s the practical breakdown.

AI is strong at spotting “out-of-pattern” SOAP behavior

If your environment has SOAP clients that typically talk to a small set of internal endpoints, then a sudden connection to:

• a new host,
• a new scheme (like file://), or
• a new network protocol pattern (SMB to an unexpected destination)

…is a great candidate for anomaly detection.

AI models can reduce the tuning burden by learning normal per-app and per-host behavior, then flagging high-confidence deviations. In December change-freeze season (right now), that’s especially useful: legitimate endpoint changes should be rare, so anomalous events are more likely to be malicious.

AI is strong at correlation across layers

SOAPwn isn’t just “a web request.” It’s often:

• An inbound request that sets up parameters
• A WSDL fetch or import behavior
• A proxy call that writes locally or reaches out to SMB
• A suspicious file write in a web directory
• A new child process or script execution (if RCE lands)

AI-assisted detection shines when it correlates these into a single narrative and assigns risk. Traditional tools can catch pieces, but analysts lose time stitching them together.

AI is weak when your telemetry is incomplete

No model can infer what you don’t collect. If you don’t have:

• process creation and command-line logging on the app server,
• file write telemetry in sensitive paths,
• DNS and egress visibility,
• authentication logs that highlight outbound NTLM attempts,

…you’ll miss the sequence or get late alerts.

A blunt truth: AI doesn’t replace logging discipline. It rewards it.

Detection ideas: what to monitor for SOAPwn-style exploitation

You’re looking for three things: suspicious URL schemes, suspicious writes, and suspicious outbound auth. Below are concrete signals you can implement with a mix of rules + AI scoring.

1) WSDL manipulation and risky proxy generation

High-signal indicators include:

• WSDL locations supplied via request parameters, headers, or config values that can be influenced by users
• WSDL imports that reference unexpected hosts or new domains
• Repeated WSDL fetches with slight variations (enumeration/testing)

AI can help by establishing a baseline of “normal WSDL sources” per application and alerting when a new source appears.

2) file:// and UNC patterns in places they shouldn’t exist

Watch for:

• file:// appearing in application logs, proxy configuration, or SOAP client parameters
• UNC usage patterns (e.g., \\host\share or file://host/share) from servers that normally never initiate SMB sessions
• sudden outbound SMB from an app server to a non-fileserver segment

Even if the exploit doesn’t succeed, the attempt often leaves these fingerprints.

3) File writes to web-executable or templating locations

Prioritize monitoring writes to:

• web root directories
• directories that store view templates (CSHTML)
• upload directories that are mistakenly executable
• locations used by scheduled tasks or deployment pipelines

If you’re using AI-based endpoint detection, make sure the model has path sensitivity—writing *.aspx or *.cshtml in the wrong directory should spike risk instantly.

4) Post-write execution behaviors

If SOAPwn becomes RCE, follow-on behaviors may include:

• w3wp.exe (IIS worker) spawning powershell.exe, cmd.exe, mshta.exe, or rundll32.exe
• suspicious PowerShell flags (encoded commands, hidden windows)
• unusual network beacons from the app server right after a file write

These are classic, but in a SOAPwn chain they may be the only obvious indicator if the earlier SOAP telemetry is thin.

Mitigation checklist: reduce exposure without breaking production

The fastest wins are about removing untrusted influence and tightening execution paths. Here’s what I’d do this week if I owned a .NET-heavy estate.

Immediate actions (24–72 hours)

1. Inventory SOAP usage

   • Find apps using generated SOAP proxies or dynamic WSDL imports.
   • Flag any use of ServiceDescriptionImporter or runtime proxy generation.

2. Patch vendor products where fixes exist

   • Apply updates for impacted tools (for example, vendors have released fixes for some affected enterprise products).

3. Block or restrict outbound SMB from application servers

   • If a server doesn’t need SMB outbound, deny it.
   • This directly reduces NTLM capture/relay opportunities.

4. Add detections for risky URL schemes

   • Alert on file:// usage in SOAP proxy contexts.
   • Alert on WSDL retrieval from non-approved hosts.

Engineering fixes (1–4 weeks)

1. Hard-allowlist WSDL sources and endpoints

   • If an app needs a WSDL, it should come from a fixed internal location.

2. Treat WSDL like code

   • Store it with the application or fetch it only from signed, controlled sources.

3. Eliminate dynamic proxy generation where possible

   • Generated-at-build-time proxies are easier to secure and review.

4. Harden file system permissions

   • Web roots should not be writable by the app identity unless absolutely required.
   • Upload directories should not be executable.

What to do about EoL platforms (the Umbraco 8 problem)

If the platform is end-of-life, your mitigation has to be compensating controls or replacement. There’s no comfortable middle.

For EoL web apps that can’t be migrated immediately:

• isolate them (network segmentation, strict egress controls)
• add aggressive monitoring (file integrity + process behavior)
• place them behind strong access controls (VPN, conditional access, IP allowlists)
• schedule a migration date you can defend to leadership

If you’re running EoL internet-facing software in 2025, attackers don’t need AI. They just need patience.

Turning SOAPwn into a practical AI-in-cybersecurity use case

SOAPwn is a clean example of why AI-powered threat detection is moving from “nice to have” to “ops requirement.” The vulnerability class sits at the intersection of app logic, framework behavior, and network authentication. That’s exactly where humans struggle to keep up at scale.

Here’s the operational goal I recommend:

Detect WSDL manipulation and suspicious SOAP proxy behavior within minutes, then automatically prioritize incidents that show file-write or outbound NTLM signals.

If your SOC can do that consistently, SOAPwn becomes a noisy probe instead of a breach.

The bigger question for your 2026 planning cycle is straightforward: how many “legacy” integrations are effectively unmonitored code execution surfaces, and how quickly would your tooling tell you when one starts acting strange?